AI के लिए प्रॉक्सी

हर प्रमुख AI प्लेटफ़ॉर्म आपके भेजे जाने वाले रिक्वेस्ट की संख्या को सीमित करता है। OpenAI, Anthropic, Google, DeepSeek — ये सभी प्रति अकाउंट, प्रति मिनट, प्रति दिन के हिसाब से उपयोग को कैप करते हैं। जब आप प्रोडक्ट बना रहे हों, ऑटोमेशन चला रहे हों, या बड़े पैमाने पर डेटा प्रोसेस कर रहे हों, तो एक अकाउंट और एक IP से सीमा जल्दी ही पूरी हो जाती है। आपको 429 एरर मिलने लगते हैं, कतार में रिक्वेस्ट जमा होने लगते हैं, और आपकी पाइपलाइन रुक जाती है।

एक AI proxy सर्वर आपके एप्लिकेशन और AI प्रदाता के बीच बैठता है। आप proxy को रिक्वेस्ट भेजते हैं, और यह उन्हें कई API keys में वितरित करता है, जिनमें से प्रत्येक अपने अलग IP एड्रेस से जाती है। प्रदाता को एक ओवरलोडेड अकाउंट की जगह अलग-अलग यूज़र दिखाई देते हैं। आपकी कुल क्षमता कई गुना बढ़ जाती है जबकि प्रत्येक key सुरक्षित रूप से सीमा के अंदर रहती है। व्यवहार में, एक अच्छी तरह से कॉन्फ़िगर किया गया proxy प्रति रिक्वेस्ट केवल 15–30ms की लेटेंसी जोड़ता है — बैच प्रोसेसिंग के लिए नगण्य और रियल-टाइम चैट एप्लिकेशन में भी मुश्किल से ध्यान देने योग्य, जहाँ मॉडल का अपना जनरेशन टाइम 500–3000ms पर हावी रहता है।

यह इसलिए काम करता है क्योंकि AI प्लेटफ़ॉर्म रेट लिमिट को अकाउंट से जोड़ते हैं, IP से नहीं — लेकिन वे IP पैटर्न की निगरानी ज़रूर करते हैं। यदि एक एड्रेस तेज़ी से 10 अलग-अलग API keys को साइकल करता है, तो यह एक रेड फ़्लैग है। प्रति key अलग डेडिकेटेड प्रॉक्सी सब कुछ स्वाभाविक बनाए रखती हैं। आपको एक failover रणनीति भी चाहिए: हर key की एरर रेट को मॉनिटर करें, और यदि कोई विशिष्ट IP लगातार 429 या 403 एरर देने लगे, तो उसे स्वचालित रूप से पूल से हटा दें और उस key के ट्रैफ़िक को बैकअप IP के माध्यम से रूट करें। हर 60 सेकंड में प्रत्येक key-IP जोड़ी पर हेल्थ चेक समस्याओं को बड़ा होने से पहले पकड़ लेते हैं।

प्रैक्टिस में सेटअप कैसा दिखता है

ज़्यादातर AI API प्रॉक्सी सेटअप प्रोवाइडर चाहे कोई भी हो, एक ही पैटर्न फ़ॉलो करते हैं। आप एक लाइटवेट प्रॉक्सी सर्वर रन करते हैं (FastAPI, Node, Go — आपका स्टैक जो भी हो) जिसमें API कीज़ का एक पूल होता है। जब कोई रिक्वेस्ट आती है, तो प्रॉक्सी अगली उपलब्ध की उठाती है, रिक्वेस्ट को उस की के असाइन किए गए IP से रूट करती है, और रिस्पॉन्स लौटाती है। अगर किसी की को 429 (रेट-लिमिट एरर) मिलता है, तो प्रॉक्सी अगली की पर चली जाती है। यहाँ FastAPI और httpx:

import httpx, itertoolsfrom fastapi import FastAPI, Request, Response

@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)

नोट: यह न्यूनतम उदाहरण सरलता के लिए itertools.cycle का उपयोग करता है, लेकिन यह 429 एरर पर स्वचालित रूप से retry नहीं करता। प्रोडक्शन में, retry लॉजिक जोड़ें जो थ्रॉटल की गई key को स्किप करे और कॉलर को एरर लौटाने से पहले अगली उपलब्ध key-IP जोड़ी को आज़माए। चूँकि लगभग हर AI प्रदाता अब OpenAI API फ़ॉर्मेट को सपोर्ट करता है, एक ही proxy हर AI प्रदाता द्वारा आवश्यक फ़ॉर्मेट ट्रांसलेशन को हैंडल कर सकता है — सही प्रदाता की ओर रूट करें, और आपके एप्लिकेशन को अंतर जानने की ज़रूरत नहीं। प्रति प्रदाता base URL और key पूल बदलें, और वही 20-लाइन का सर्वर OpenAI, Anthropic, Google, और DeepSeek को कवर कर लेता है।