आपने इसे OpenAI के API पर बनाया। फिर आप Claude भी आज़माना चाहते हैं, और Gemini से तुलना करना चाहते हैं। लेकिन हर प्रोवाइडर का SDK, request का ढाँचा, और error का व्यवहार अलग होता है। हर बदलाव का मतलब है कोड फिर से लिखना, responses को बदलना, और हर vendor के लिए अलग retry logic बनाए रखना — जल्द ही "vendor-specific plumbing" आपकी ऐप के हर कोने में रिस जाती है। और जब तक आप एक ही प्रोवाइडर से बँधे हैं, जिस पल उस कंपनी में outage होता है, दाम बढ़ते हैं, या कोई मॉडल बंद होता है, आपकी ऐप उसके साथ ही ठप हो जाती है

जो चीज़ यह पूरी plumbing अपने ज़िम्मे ले लेती है वह है LLM gateway (AI gateway), जिसे LLM proxy भी कहते हैं। यह एक रिले है जो आपकी ऐप और प्रोवाइडर्स के बीच बैठता है, हर मॉडल तक पहुँचने के लिए एक ही API (आमतौर पर OpenAI-compatible) पेश करता है, और cross-cutting कामों को संभालता है — fallback, cost tracking, caching, rate limiting। यह गाइड बताती है कि gateway आपके लिए क्या करता है, self-hosted, hosted, और SDK प्रकारों में फ़र्क क्या है, LiteLLM, OpenRouter, और Vercel AI SDK में से कैसे चुनें, और वे सीमाएँ जो आपको जाननी चाहिए ताकि आप बाद में परेशान न हों।

30 सेकंड का जवाब

अगर आप सिर्फ़ एक ही बॉक्स पढ़ें

यह क्या है
आपकी ऐप और प्रोवाइडर्स के बीच का एक रिलेएक ही API से हर मॉडल तक पहुँचें।
यह मदद क्यों करता है
आज़ादी से बदलें, तुलना करें, और fallback करें। cost और rate limits को एक ही जगह मैनेज करें।
पहले कौन-सा चुनें
Self-host = LiteLLM / तुरंत hosted = OpenRouter / TS ऐप = Vercel AI SDK

ध्यान दें: gateway कोई मुफ़्त की चीज़ नहीं है। इसकी कीमत है — एक hop latency, शुल्क, और कुछ फ़ीचर का नुकसान (§8)।

1. आपको LLM gateway की ज़रूरत क्यों है

अगर आप सिर्फ़ एक ही प्रोवाइडर को एक ही SDK के ज़रिए कॉल करते हैं, तो आपको gateway की ज़रूरत नहीं। ज़रूरत उसी पल पड़ती है जब आप एक से ज़्यादा मॉडल इस्तेमाल करना चाहें। तीन क्लासिक तकलीफ़ों को देखें।

🔗 Vendor lock-in और बिखरा हुआ कोड

हर प्रोवाइडर के SDK, parameter नाम, response structures, और error codes अलग होते हैं। हर बदलाव का मतलब है अपनी ऐप फिर से लिखना

⚡ Outages, दाम बढ़ना, बंद होना

पूरी तरह एक कंपनी पर निर्भर रहें और उसका outage या दाम में बदलाव आपकी downtime बन जाता है। आपको एक बचाव का रास्ता (fallback) चाहिए।

🔀 तुलना करें, बदलें, mix and match करें

सबसे अच्छा मॉडल हर टास्क के लिए अलग होता है। आप ड्राफ़्ट के लिए सस्ता मॉडल और निखार के लिए स्मार्ट मॉडल इस्तेमाल करना चाहते हैं — लेकिन plumbing आड़े आ जाती है।

इन सबमें साझा है वह ढाँचा जहाँ SDK की बंदिशें एक अनिवार्य रूप से रणनीतिक फ़ैसले को तय कर देती हैं — कौन-सा मॉडल इस्तेमाल किया जाए। gateway उस plumbing को आपकी ऐप से बाहर निकाल देता है। आपकी ऐप को सिर्फ़ एक endpoint जानना होता है; उसके पीछे किसे कॉल करना है, किस पर fail over करना है, और आपने कितना खर्च किया है — यह gateway का काम है। चूँकि AI agent या agent framework बनाना लगभग हमेशा कई मॉडल मानकर चलता है, इसकी माँग बस बढ़ती ही जाती है।

2. LLM gateway क्या है

LLM gateway एक proxy है जो आपकी ऐप और एक या अधिक LLM प्रोवाइडर्स के बीच बैठता है। अधिकांश एक ही API पेश करते हैं जो OpenAI के chat-completions endpoint जैसा दिखता है और उस cross-cutting काम को एक ही जगह इकट्ठा कर देते हैं जो वरना आपके कोड में बिखर जाता — routing, retries और fallback, caching, rate limiting, cost tracking, और access control।

आपकी ऐप
सिर्फ़ एक API जानती है
(OpenAI-compatible)
LLM gateway
routing / fallback
cost / cache / control
प्रोवाइडर्स
OpenAI / Anthropic
Google / local…
आपकी ऐप को एक ही खिड़की दिखती है — gateway। यह किसे कॉल करता है, वह पर्दे के पीछे बदलता रहता है।

मुद्दा है खिड़की को एक ही बना देना। आपका ऐप कोड बस एक string model को पास करता है। anthropic/claude-opus-4.8 लिखें और आपको Claude मिलता है; openai/gpt-5.5 लिखें और आपको GPT मिलता है — ऐप में और कुछ नहीं बदलता। "जब यह मॉडल ठप हो तो दूसरे पर fail over करो" या "यही एक जैसा सवाल cache से लौटा दो" जैसे फ़ैसले सब gateway की तरफ़ तय होते हैं। किसी local LLM को इस तरह मिलाना कि "संवेदनशील डेटा local रहे, बाक़ी सब cloud पर जाए" — वह भी उसी तरह लिखा जाता है।

3. यह आपके लिए क्या संभालता है

gateway जो cross-cutting काम अपने ज़िम्मे लेता है, वह मोटे तौर पर इन छह खानों में बँटता है। टूल्स इस बात में अलग होते हैं कि वे किसमें अच्छे हैं, लेकिन दिशा एक ही है।

🔌 Unified API

हर प्रोवाइडर को एक ही फ़ॉर्मैट में कॉल करें (आमतौर पर OpenAI-compatible)। ऐप से vendor के फ़र्क मिटा देना ही मुख्य फ़ीचर है।

🔁 Fallback और retry

जब primary मॉडल में error हो, overload हो, या timeout हो, तो अपने-आप दूसरे पर स्विच हो जाता है। business continuity का दिल।

💰 Cost tracking और virtual keys

हर यूज़र, टीम, या प्रोजेक्ट के हिसाब से खर्च देखेंscoped virtual keys बाँटें जो असली keys को छिपा दें।

⚡ Caching

एक जैसे या मिलते-जुलते requests को याद रखें और तुरंत लौटा दें। API बिल और latency दोनों घटाता है।

🚦 Rate limiting और load balancing

हर key पर token और request की सीमाएँ, साथ ही कई keys और instances में load balancing

📊 Observability और guardrails

सभी requests में logs, latency, और success rate मापें। कुछ टूल्स आपको input/output guardrails डालने भी देते हैं।

💡 "Fallback" का मतलब "सुरक्षित" नहीं है। जिस मॉडल पर आप fail over करते हैं उसके output की आदतें, token counts, और समर्थित फ़ीचर अलग होते हैं। fallback कॉन्फ़िगर करते ही सुरक्षित नहीं हो जाता — यह तभी काम करता है जब आपने इसे सचमुच चला कर टेस्ट किया हो। पहले से हमेशा जाँच लें कि स्विच के बाद आपका prompt टूट तो नहीं जाता।

4. तीन प्रकार: self-hosted, hosted, SDK

"LLM gateway" को एक ही लेबल की तरह इस्तेमाल किया जाता है, लेकिन यह कहाँ चलता है इसके आधार पर यह तीन काफ़ी अलग-अलग चरित्रों में बँट जाता है। इसे गलत समझा तो गलत चुनाव कर बैठेंगे।

प्रकार कहाँ चलता है उदाहरण किसके लिए उपयुक्त
① Self-hosted proxy आपके सर्वर (अलग process) LiteLLM / Portkey (OSS) डेटा घर में और शासित रखें
② Hosted (SaaS) प्रोवाइडर का cloud OpenRouter / Cloudflare तुरंत इस्तेमाल करें, ज़ीरो ops
③ SDK / library आपके ऐप कोड के अंदर Vercel AI SDK TS/JS में जल्दी abstract करें

① Self-hosted एक स्वतंत्र process (एक proxy server) है जिसे आप अपने ही इन्फ़्रास्ट्रक्चर पर खड़ा करते हैं। चूँकि prompts किसी बाहरी SaaS से नहीं गुज़रते, यह governance और audit में मज़बूत है — लेकिन इसे आप खुद चलाते हैं। ② Hosted में प्रोवाइडर proxy चलाता है, इसलिए यह अपनाने में सबसे तेज़ है, पर requests किसी तीसरे पक्ष से गुज़रते हैं। ③ SDK कोई अलग process खड़ा नहीं करता; यह प्रोवाइडर के फ़र्क को आपके ऐप कोड के अंदर सोख लेता है — यह नेटवर्क रिले नहीं बल्कि एक "abstraction layer" है, और इसे ① या ② के साथ मिलाया जा सकता है।

5. मुख्य टूल्स की तुलना

यहाँ सुझाए गए क्रम में तीन मुख्य टूल हैं, साथ ही दो और जिन्हें जानना ज़रूरी है। आँकड़े जुलाई 2026 तक हर vendor के आधिकारिक पेजों पर आधारित हैं (offerings बदलते रहते हैं, इसलिए ताज़ा जानकारी हमेशा प्राथमिक स्रोत से पक्की करें)।

LiteLLM — मानक self-hosted proxy

LiteLLM (BerriAI द्वारा) एक open-source Python लाइब्रेरी और self-hosted gateway है। यह आपको एक ही OpenAI-compatible API के ज़रिए 100+ प्रोवाइडर और 2,500+ मॉडल कॉल करने देता है (आधिकारिक repo के अनुसार)। इसे proxy के रूप में खड़ा करें और आपको मिलता है cost tracking, virtual keys, rate limiting, fallback, load balancing, Redis caching, और observability (Langfuse/Prometheus/Datadog integrations)। यह उन संगठनों की पहली पसंद है जो prompts को घर में रखना चाहते हैं।

OpenRouter — एक key से, तुरंत, multi-provider

OpenRouter बिना ops वाला hosted gateway है। एक ही OpenAI-compatible API और एक API key के साथ, यह आधिकारिक साइट के अनुसार 400+ मॉडल तक पहुँच देता है। इसका pricing डिज़ाइन खास है: आधिकारिक साइट कहती है "हम inference tokens पर कोई मार्कअप नहीं लगाते (catalog दाम हर प्रोवाइडर के प्रकाशित दामों के बराबर हैं)", जबकि क्रेडिट खरीद पर 5.5% प्लेटफ़ॉर्म शुल्क लेती है (openrouter.ai/pricing के अनुसार)। "बस चालू कर दो" और "एक key से हर vendor आज़मा लो" के लिए यह बेहद तेज़ है।

Vercel AI SDK — TypeScript में कोड से abstract करें

Vercel AI SDK (2026 में बस "AI SDK") एक open-source TypeScript toolkit है। एक अलग proxy process के बजाय, यह एक abstraction layer है जो प्रोवाइडर के फ़र्क को आपके ऐप कोड के अंदर सोख लेता है। docs जिसे "architectural core" कहते हैं वह है provider abstraction: OpenAI से Anthropic पर स्विच करने का मतलब है एक import और एक model string बदलना — आपका generation, streaming, और tool-calling कोड पूरी तरह जस का तस रहता है। इसे hosted Vercel AI Gateway के साथ मिलाएँ और आप 100+ मॉडल तक पहुँच जाते हैं। इम्प्लीमेंटेशन के विवरण और कोड के लिए, हमारी पूरी Vercel AI SDK गाइड देखें।

दो और जिन्हें जानना ज़रूरी है

एक managed, edge पर चलने वाला विकल्प। बस अपने मौजूदा प्रोवाइडर कॉल्स को इसके ज़रिए भेजें और आपको न्यूनतम कोड बदलाव के साथ caching, rate limiting, analytics, logging, और fallback मिलते हैं (docs के अनुसार)। अगर आप पहले से Cloudflare पर चलते हैं तो बढ़िया मेल।

🛡️ Portkey

एक control plane जो gateway में production-grade governance, guardrails, और prompt management जोड़ता है। आधिकारिक साइट कहती है कि यह एक ही API से 1,600+ LLM से जोड़ता है। OSS संस्करण को self-host भी किया जा सकता है।

टूल प्रकार खिड़की फ़ोकस Pricing विचार
LiteLLM ① self-host OpenAI-compatible API Governance, virtual keys, observability OSS मुफ़्त + आपकी ops लागत
OpenRouter ② hosted OpenAI-compatible API तुरंत, एक key से 400+ मॉडल inference पर कोई मार्कअप नहीं; खरीद पर 5.5%
Vercel AI SDK ③ SDK TS functions कोड से बदलें, type-safe SDK मुफ़्त + हर vendor की बिलिंग
Cloudflare AI Gateway ② hosted (edge) Pass-through Caching, observability Cloudflare pricing
Portkey ① / ② दोनों Unified API Governance, guardrails OSS + SaaS plans
आँकड़े और pricing जुलाई 2026 तक हर vendor के आधिकारिक पेजों के अनुसार। ये बदलते रहते हैं — अपनाते समय प्राथमिक स्रोत से फिर से पक्की करें।

6. न्यूनतम सेटअप (कोड)

देखने में यह डराने वाला लगता है, लेकिन स्विच करने की असली जड़ बस एक ही जगह है — endpoint (या model string) बदल दें। यहाँ तीनों प्रकारों के लिए न्यूनतम उदाहरण है।

② Hosted: OpenRouter (बस endpoint बदलें)

अपना सामान्य OpenAI SDK रखें; सिर्फ़ base_url और key बदलें और 400+ मॉडल तक पहुँच जाएँ।

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",  # बस यही एक बदलाव है
    api_key="sk-or-...",                       # आपकी OpenRouter key
)

resp = client.chat.completions.create(
    model="anthropic/claude-opus-4.8",  # "openai/gpt-5.5" में बदलें और आपने स्विच कर लिया
    messages=[{"role": "user", "content": "नमस्ते"}],
)
print(resp.choices[0].message.content)

① Self-hosted: LiteLLM (अपना proxy खड़ा करें)

अपने मॉडल एक config फ़ाइल में सूचीबद्ध करें, और एक कमांड localhost:4000 पर एक OpenAI-compatible gateway खड़ा कर देती है। आपकी ऐप बस वहीं की ओर इशारा करती है।

# config.yaml
model_list:
  - model_name: claude
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: gpt
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY
# शुरू करें (http://localhost:4000 पर एक OpenAI-compatible API चलाता है)
litellm --config config.yaml

③ SDK: Vercel AI SDK (कोड में model string बदलें)

import और function रखें; स्विच करने के लिए सिर्फ़ model string बदलें।

import { generateText } from 'ai';

const { text } = await generateText({
  model: 'anthropic/claude-opus-4.8',  // 'openai/gpt-5.5' में बदलें
  prompt: 'नमस्ते',
});
console.log(text);

हर मामले में आपने ऐप logic की एक भी लाइन नहीं छुई। यही gateway/abstraction का असर है। Fallback और caching इसके ऊपर configuration के ज़रिए जोड़े जाते हैं (सटीक syntax के लिए हर vendor के docs सबसे तेज़ रास्ता हैं)।

7. कैसे चुनें

"कौन-सा सबसे अच्छा है" से नहीं, बल्कि कौन-सा आपकी बंदिशों में फ़िट बैठता है से चुनें। इन्हें इसी क्रम में लागू करें और आप शायद ही कहीं फँसेंगे।

बस चालू करना है / अकेले, PoC, छोटी टीमOpenRouter। एक key, ज़ीरो ops, हर vendor के मॉडल आज़माएँ। 5.5% शुल्क को खुद न चलाने की कीमत मानें।

TypeScript / Next.js में बना रहे हैंVercel AI SDK। कोड से type-safe abstraction, साथ ही पूरी streaming UI kit। इम्प्लीमेंटेशन के लिए, पूरी गाइड पर जाएँ।

डेटा बाहर नहीं जाने देना / संगठन-भर की governance चाहिएLiteLLM self-host करें (या Portkey OSS)। टीमों को virtual keys बाँटें और cost तथा logs एक ही जगह रखें।

पहले से Cloudflare पर बना हैCloudflare AI Gateway: अपने मौजूदा कॉल्स इसके ज़रिए भेजें और caching तथा observability जोड़ें।

संयोजन व्यवहार में सामान्य हैं। मिसाल के लिए, "ऐप को Vercel AI SDK से लिखें, पर इसके पिछले दरवाज़े को किसी LiteLLM proxy की ओर मोड़ दें ताकि कंपनी-भर की cost और keys एक जगह हो जाएँ" — यह दो-स्तरीय सेटअप ठीक इसीलिए काम करता है क्योंकि SDK और proxy प्रकार अलग-अलग layers हैं। निर्भरता जोखिम के विरुद्ध बीमे के तौर पर, किसी local LLM को एक fallback target के रूप में जोड़ना भी मानक बनता जा रहा है।

8. सावधानियाँ और सीमाएँ — मुफ़्त नहीं है

gateway सुविधाजनक है, पर चूँकि यह एक layer जोड़ता है, इसकी हमेशा कोई कीमत होती है। किसी को अपनाने से पहले इन चारों को ध्यान में रखें।

⏱️ एक hop latency

बीच में एक रिले होने से latency थोड़ी बढ़ जाती है। Hosted प्रकार भौगोलिक दूरी को खास तौर पर महसूस करते हैं। Caching अक्सर इसकी भरपाई कर देती है, पर बहुत-कम-latency वाले उपयोग के लिए, माप लें।

🎯 एक नया single point of failure

आप प्रोवाइडर outages के लिए मज़बूत हो जाते हैं, पर अगर gateway ही ठप हो जाए, तो सब कुछ ठप हो जाता है। redundancy, health checks, और सीधी-कॉल वाला बचाव का रास्ता बनाएँ।

💸 शुल्क और ops लागत

Hosted प्रकार एक शुल्क जोड़ते हैं (OpenRouter खरीद का 5.5% है); self-hosted server ops लागत जोड़ता है। break-even scale के साथ बदलता है।

🧩 फ़ीचर का नुकसान

OpenAI-compatible साझा हर-निम्नतम पर सिमटने का मतलब है कि हर vendor के अनूठे फ़ीचर (extended thinking, खास tool formats) शायद पास न हों या देर से आएँ।

एक और बात जो अक्सर अनदेखी रह जाती है: privacy। किसी hosted gateway से गुज़रने का मतलब है कि आपके prompts और responses किसी तीसरे पक्ष के इन्फ़्रास्ट्रक्चर से होकर जाते हैं। अगर आप संवेदनशील डेटा संभालते हैं, तो बिचौलिए की data-handling नीति जाँच लें, या पहले से ही किसी self-hosted प्रकार (जैसे LiteLLM) से prompts घर में रखें। किसी संगठन में production के लिए, gateway की अपनी keys और logs को भी least privilege और isolation का विषय मानें — यही सुरक्षित पक्ष है।

सारांश

  • LLM gateway आपकी ऐप और प्रोवाइडर्स के बीच का एक रिले है। यह आपको एक ही API से हर मॉडल तक पहुँचने देता है।
  • यह छह काम अपने ज़िम्मे लेता है: unified API, fallback, cost tracking, caching, rate limiting, observability
  • तीन प्रकार हैं — ① self-hosted (LiteLLM) / ② hosted (OpenRouter) / ③ SDK (Vercel AI SDK)। बंदिश के हिसाब से चुनें।
  • कैसे चुनें: तुरंत = OpenRouter / TS निर्माण = Vercel AI SDK / governance = LiteLLM। संयोजन सामान्य हैं।
  • लागतों को न भूलें: एक hop latency, gateway का अपना failure point, शुल्क, फ़ीचर का नुकसान, privacy
  • Fallback सिर्फ़ कॉन्फ़िगर करने से काम नहीं करता — इसे सचमुच चलाएँ और पक्का करें कि आपका prompt टूटता नहीं।

अगर आप कई मॉडलों के साथ काम कर रहे हैं, तो gateway "अच्छा होता तो सही" नहीं बल्कि plumbing को एक ही जगह इकट्ठा करने का बुनियादी साज़ो-सामान बनता जा रहा है। शुरुआत करें OpenRouter से base_url बदल कर या Vercel AI SDK से एक model string बदल कर — वह छोटा कदम एक ही vendor की lock-in को घोल देता है और तुलना तथा fallback दोनों को अचानक व्यावहारिक बना देता है। सटीक, ताज़ा specs के लिए, हर vendor का प्राथमिक स्रोत पक्की करें (LiteLLM / OpenRouter / AI SDK)।

FAQ

Q. क्या LLM gateway और LLM proxy अलग-अलग चीज़ें हैं?

A. इन्हें लगभग एक-दूसरे की जगह इस्तेमाल किया जाता है। दोनों आपकी ऐप और प्रोवाइडर्स के बीच खड़े एक रिले को संदर्भित करते हैं। अगर फ़र्क बताएँ तो, "proxy" तंत्र (ट्रैफ़िक रिले करना) की ओर झुकता है, जबकि "gateway" भूमिका (cost management और governance समेत) की ओर झुकता है।

Q. अगर OpenRouter में "कोई मार्कअप नहीं" है, तो यह महँगा कैसे पड़ सकता है?

A. per-token inference दर हर प्रोवाइडर का प्रकाशित दाम है (कोई मार्कअप नहीं), पर आधिकारिक साइट के अनुसार क्रेडिट खरीद पर 5.5% प्लेटफ़ॉर्म शुल्क है। आपकी टॉप-अप जितनी छोटी होगी, वह हिस्सा उतना ज़्यादा काटेगा, इसलिए प्रभावी लागत को "मॉडल का दाम + कुछ प्रतिशत" मान कर आँकें। ताज़ा जानकारी openrouter.ai/pricing पर पक्की करें।

Q. Vercel AI SDK या LiteLLM — मुझे कौन-सा इस्तेमाल करना चाहिए?

A. ये अलग-अलग layers हैं, इसलिए ये आपस में मुक़ाबला नहीं करते। Vercel AI SDK कोड-के-अंदर abstraction है (TS/JS के लिए); LiteLLM एक अलग-process proxy है (भाषा-निरपेक्ष, governance-केंद्रित)। पहले से TS ऐप जल्दी बनाएँ; दूसरे से कंपनी-भर की cost, keys, और logs एक जगह रखें। दोनों को एक साथ रखना आम है।

Q. क्या gateway जोड़ने से चीज़ें धीमी हो जाती हैं?

A. एक रिले जोड़ने से थोड़ी latency ज़रूर बढ़ती है। पर जहाँ caching काम करती है, वहाँ अक्सर उल्टा तेज़ हो जाता है। अगर बहुत-कम latency ज़रूरी है, तो किसी self-hosted प्रकार को पास रखें, caching पर टिकें, और अहम रास्तों के लिए सीधी-कॉल वाला बचाव रखें ताकि असर सीमित रहे।

Q. क्या मुझे gateway चाहिए भले ही मैं सिर्फ़ एक प्रोवाइडर इस्तेमाल करूँ?

A. ज़रूरी नहीं। पर अक्सर सिर्फ़ cost की दृश्यता, virtual keys से access control, caching, और observability से भी फ़ायदा होता है। अगर आगे चल कर आप मॉडल जोड़ सकते हैं या इसे किसी टीम में इस्तेमाल कर सकते हैं, तो इसे जल्दी लगा देना migration आसान बना देता है।