हर प्रदाता आपको एक key देता है। तीसरे के बाद, keys सुविधा होना बंद कर देती हैं और एक ऐसा सिस्टम बन जाती हैं जिसे आपको बनाना और बनाए रखना पड़ता है। आपके पास N प्रदाता हैं, प्रत्येक का अपना base URL, अपना auth header, अपनी rate limit semantics, अपने error codes, अपना billing page। जिस क्षण आप किसी request को "सबसे अच्छे उपलब्ध मॉडल" पर route करना चाहते हैं, बजाय "जिसे मैंने hardcode किया है", उस क्षण यह एक routing समस्या बन जाती है, और यही वह चीज़ है जिसे एक gateway हल करता है।
समस्या API नहीं, operations है
कच्ची API कॉल्स आसान हैं। यह उनके आस-पास की हर चीज़ है जो जटिल होती जाती है:
•Credential का फैलाव। प्रत्येक प्रदाता के लिए एक key, अलग-अलग समय-सारणी पर rotate की जाती है, अलग-अलग secret managers में संग्रहीत की जाती है।
•Rate limits। प्रत्येक प्रदाता अलग तरीके से throttle करता है, और उनकी error responses एक समान नहीं होतीं, इसलिए आपके retry logic को प्रत्येक के लिए special-case करना पड़ता है।
•Usage visibility। प्रत्येक प्रदाता का अपना dashboard होता है। कोई एक जगह नहीं है जो उन सब में कुल खर्च दिखाए।
•Failover। यदि प्रदाता A बंद हो जाता है, तो traffic को प्रदाता B पर ले जाने का मतलब है नई key और नए endpoint के साथ redeploy करना।
इनमें से कुछ भी किसी demo में दिखाई नहीं देता। यह production में रात 2 बजे दिखाई देता है जब कोई प्रदाता बंद होता है और आपकी retry queue भरने लगती है।
एक gateway वास्तव में क्या है
एक gateway आपके application और model providers के बीच बैठता है। आपका app एक endpoint से एक key के साथ बात करता है। Gateway auth, routing, rate limiting, usage accounting, और fallback संभालता है। आपके code के लिए यह बिल्कुल एक single LLM API जैसा दिखता है।
+------------------+
| Your app |
+--------+---------+
| one key, one base URL
v
+--------+---------+
| LLM gateway |
| auth / routing |
| rate limiting |
| usage metering |
+--+-----+----+----+
| | |
v v v
Provider A B C
(GPT-4o) (DeepSeek) (Qwen)महत्वपूर्ण design निर्णय यह है कि gateway inbound पक्ष पर OpenAI-compatible protocol बोलता है। इसका मतलब है कि आपके मौजूदा SDK code को नई client library की आवश्यकता नहीं है। आप base URL और key बदलते हैं, और आप सामान्य chat.completions.create कॉल्स लिखते रहते हैं।
एक key, एक endpoint, कई मॉडल
यहाँ client पक्ष पर पूरा integration है:
from openai import OpenAI
client = OpenAI(
base_url="https://api.token8341.com/v1",
api_key="sk-one-key-for-everything",
)
for model in ["gpt-4o", "claude-3-5-sonnet", "deepseek-chat", "qwen-max"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Reply with the word 'ok'"}],
)
print(model, "->", resp.choices[0].message.content)एक ही key catalog के हर मॉडल को authorize करती है। आप चार accounts provision नहीं करते या चार balances track नहीं करते। आप एक metered bill का भुगतान करते हैं, और usage मॉडल के अनुसार विभाजित होता है ताकि आप देख सकें कि tokens वास्तव में कहाँ गए।
Gateway routing को code परिवर्तन के बजाय एक config निर्णय बनाता है। उच्च-मात्रा lane के लिए सस्ता मॉडल और कठिन lane के लिए frontier मॉडल चाहते हैं? यह एक ही जगह पर एक mapping है:
ROUTES = {
"summarize": "deepseek-chat",
"reason": "qwen-max",
"frontier": "gpt-4o",
}और fallback एक multi-vendor integration के बजाय सामान्य control flow बन जाता है:
def call_with_fallback(prompt, primary, backup):
try:
return ask(primary, prompt)
except Exception:
return ask(backup, prompt)आपको gateway की आवश्यकता कब है, और कब नहीं
यदि आपको इसकी आवश्यकता नहीं है तो gateway एक अतिरिक्त बोझ है जिसे आपको नहीं उठाना चाहिए। यदि आप एक प्रदाता और एक मॉडल का उपयोग करते हैं और आपकी कोई failover आवश्यकता नहीं है, तो सीधी key अधिक सरल है और यही सही निर्णय है। critical path में एक अतिरिक्त hop और एक अतिरिक्त vendor जोड़ने की एक कीमत होती है।
एक gateway अपनी जगह तब कमाता है जब इनमें से कम से कम एक सत्य हो:
•आप दो या अधिक मॉडलों का उपयोग करते हैं और उनके बीच स्वतंत्र रूप से स्विच करना चाहते हैं।
•आपको fallback की आवश्यकता है जब कोई प्रदाता बंद हो या rate limited हो।
•आप एक single bill और मॉडल के अनुसार खर्च देखने के लिए एक ही जगह चाहते हैं।
•आप बिना redeploy किए live traffic पर मॉडलों का A/B test करना चाहते हैं।
यदि इनमें से कोई भी लागू होता है, तो operational बचत अतिरिक्त hop से अधिक है। एक अच्छी तरह से चलाए जाने वाले gateway की वास्तविक अतिरिक्त latency कुछ milliseconds है, इतनी कम कि यह model inference time के आगे गायब हो जाती है।
Managed या self-hosted?
एक निर्णय जिसे जानबूझकर लेना उचित है वह यह है कि आप अपना खुद का gateway चलाएँ या किराए पर लें। LiteLLM और one-api जैसे self-hosted routers उत्कृष्ट हैं और आपको routing tables, keys, और logging पर पूरा नियंत्रण देते हैं। वे आपको एक सेवा भी देते हैं जिसे चलाना, monitor करना, patch करना, और highly available रखना है, जो वास्तव में वही operational बोझ है जिसे आप हटाना चाहते थे।
एक managed gateway इस सौदे को उलट देता है। आप आंतरिक चीज़ों पर नियंत्रण छोड़ देते हैं और यह प्राप्त करते हैं कि आपको उन्हें operate नहीं करना पड़ता: कोई और endpoint को चालू रखता है, upstream keys rotate करता है, और provider outages को सहन करता है। एक छोटी टीम के लिए यह आमतौर पर सही सौदा है। staff पर एक platform समूह वाली बड़ी टीम के लिए, self-hosting अकेले auditability के लिए इसके लायक हो सकती है। किसी भी तरह से, inbound contract को OpenAI-compatible रखें ताकि विकल्प प्रतिवर्ती रहे।
SiCore TokenWorks इसी विचार के इर्द-गिर्द बनाया गया है: one API key, https://api.token8341.com/v1 पर एक OpenAI-compatible endpoint, और एक catalog जो GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark, और Pangu तक फैला है, metered billing और प्रति मॉडल विभाजित usage के साथ।