OpenRouter प्रोवाइडर रूटिंग: मॉडल गुणवत्ता, टोकन सीमाएं और वास्तविक लागत

OpenRouter प्रोवाइडर रूटिंग तय करती है कि आपके अनुरोध का उत्तर कौन सी इन्फरेंस सेवा देगी। एक ही मॉडल नाम से की गई दो कॉल भी एंडपॉइंट सीमाओं, समर्थित पैरामीटरों, सर्विंग सॉफ़्टवेयर और रूटिंग प्राथमिकताओं पर निर्भर रहती हैं। उत्तर छोटे हो जाएं या टूल कॉल विफल हों, तो क्वांटाइजेशन को दोष देने से पहले इन अंतर की जांच करें।

मुख्य बातें #

• प्रिसीजन लेबल संख्यात्मक प्रारूप बताते हैं, सटीकता स्कोर नहीं।
• एंडपॉइंट सीमाएं उपलब्ध कॉन्टेक्स्ट, आउटपुट लंबाई और फीचर सपोर्ट तय करती हैं।
• स्पष्ट रूटिंग के लिए प्रोवाइडर प्राथमिकता के साथ फॉलबैक नीति भी चाहिए।
• Auto Exacto गुणवत्ता संकेतों से प्रोवाइडर चयन सुधारता है और बिना टूल वाले अनुरोधों के लिए ऑप्ट-इन रूट देता है।
• प्रभावी लागत में आउटपुट, कैश व्यवहार, रिट्राई और सफल टास्क पूरा होना शामिल है।

आवश्यकताएं: JSON अनुरोधों की जानकारी और अपने ऐप की OpenRouter कॉन्फ़िगरेशन तक पहुंच। एंडपॉइंट जांच सार्वजनिक API का उपयोग करती है। मॉडल अनुरोध भेजने के लिए API कुंजी चाहिए और उपयोग शुल्क लगता है। तारीख वाले उदाहरण को दोहराने से पहले एंडपॉइंट मेटाडेटा फिर जांचें।

समय और कठिनाई: शुरुआती कॉन्फ़िगरेशन समीक्षा में लगभग 20 मिनट। मध्यम स्तर। प्रोवाइडर की उपयोगी तुलना के लिए प्रतिनिधि प्रॉम्प्ट के साथ अतिरिक्त परीक्षण चाहिए।

आपके मॉडल नाम में क्या नहीं दिखता #

मॉडल पहचानकर्ता मांगे गए मॉडल का चयन करता है। प्रोवाइडर मॉडल इम्प्लीमेंटेशन, टोकन सीमाओं और टूल-कॉल पार्सर सहित इन्फरेंस सेवा चलाता है। मॉडल स्तर का बेंचमार्क उन सभी सेवाओं को सत्यापित नहीं करता जो इन वेट्स को होस्ट करती हैं।

बेसलाइन रूटिंग स्वस्थ उम्मीदवारों में कम कीमत को प्राथमिकता देती है। OpenRouter कीमत के उलटे वर्ग वाली वेटिंग बताता है। उसके सरल उदाहरण में 1 डॉलर वाले उम्मीदवार को 3 डॉलर वाले उम्मीदवार से नौ गुना चयन वजन मिलता है। यह सापेक्ष वजन है, अगले अनुरोध की गारंटी नहीं। स्पष्ट क्रम, सॉर्टिंग, कैशिंग और गुणवत्ता रूटिंग भी चयन को प्रभावित करते हैं। प्रोवाइडर रूटिंग दस्तावेज देखें।

मूल्य वेटिंग आपके वर्कलोड का बिल सबसे सस्ता होगा, यह सिद्ध नहीं करती। दस्तावेजित उदाहरण इनपुट और आउटपुट का कोई सार्वभौमिक मिश्रण नहीं बताता। केवल इनपुट कीमत से प्रोवाइडर की चयन संभावना न निकालें।

प्रिसीजन को संदर्भ में पढ़ें #

क्वांटाइजेशन संख्यात्मक मानों को छोटे प्रतिनिधित्व में स्टोर करता है। इसका प्रभाव मॉडल, विधि और इन्फरेंस इम्प्लीमेंटेशन पर निर्भर करता है। कम प्रिसीजन के लिए परीक्षण चाहिए, पर लेबल अकेले यह नहीं दिखाता कि प्रोवाइडर ने मूल वेट्स बदले हैं।

GPT-OSS एक ठोस उदाहरण देता है। OpenAI का gpt-oss-120b रिलीज दस्तावेज बताता है कि mixture-of-experts वेट्स MXFP4 इस्तेमाल करते हैं और मूल्यांकन में भी वही क्वांटाइजेशन था। इन वेट्स का चार-बिट लेबल प्रकाशित रिलीज से मेल खाता है। यह प्रोवाइडर की अतिरिक्त गिरावट का प्रमाण नहीं।

अपकास्टिंग स्टोर किए गए मानों को व्यापक प्रतिनिधित्व में बदलती है। पहले से क्वांटाइज किए गए चेकपॉइंट को BF16 में बदलने से क्वांटाइजेशन में हटाई गई जानकारी वापस नहीं आती। मूल रूप से अधिक प्रिसीजन वाले चेकपॉइंट को चार बिट में बदलना अलग बदलाव है, जिसका मूल्यांकन जरूरी है।

समान लेबल क्वांटाइजेशन के अंतर को भी नहीं मिटाते। वे यह नहीं बताते कि कौन से टेंसर क्वांटाइज हुए, कौन सा कैलिब्रेशन इस्तेमाल हुआ या कौन से execution kernels चल रहे हैं। बिट डेप्थ को गुणवत्ता रैंकिंग मानने के बजाय पूरे एंडपॉइंट का परीक्षण करें।

टोकन बजट जांचें #

curl --fail --silent --show-error \
  'https://openrouter.ai/api/v1/models/openai/gpt-oss-120b/endpoints' \
  | jq '.data.endpoints[] | {
      name,
      provider_name,
      context_length,
      max_completion_tokens,
      supported_parameters,
      quantization,
      pricing
    }'

एंडपॉइंट API एक मॉडल के प्रोवाइडर मेटाडेटा को दिखाती है। इस कमांड के लिए curl और jq चाहिए। सेवा चुनने से पहले live gpt-oss-120b एंडपॉइंट प्रतिक्रिया देखें। गायब या null फ़ील्ड को अज्ञात मानें, असीमित नहीं। परिणामों की तुलना करते समय तारीख वाला स्थानीय स्नैपशॉट बचाएं।

5 अक्टूबर 2026 की जांच में gpt-oss-120b के लिए ये घोषित सीमाएं मिलीं। ये मेटाडेटा मान हैं, मापी गई completion लंबाई नहीं। प्रोवाइडर इन्हें समय के साथ बदलते हैं।

कॉन्टेक्स्ट लंबाई और आउटपुट लंबाई अलग सीमाएं हैं। लंबे कॉन्टेक्स्ट वाले मॉडल को भी उत्तर के लिए पर्याप्त जगह चाहिए। बातचीत का इतिहास, सिस्टम निर्देश और टूल परिभाषाएं उपयोगकर्ता के दस्तावेज के साथ जगह लेती हैं।

रीज़निंग टोकन समर्थित रीज़निंग मॉडल में जनरेशन बजट भी लेते हैं। छोटा बजट अधूरी रीज़निंग, कम दिखाई देने वाला आउटपुट या अंतिम उत्तर से पहले समाप्ति का जोखिम बढ़ाता है। हर छोटे उत्तर को कमजोर वेट्स का संकेत मानने के बजाय उपयोग और finish reason देखें। OpenRouter रीज़निंग टोकन दस्तावेज में यह बजट समझाता है।

स्पष्ट max_tokens राउटर को ऐसा मांगा गया आउटपुट आकार देता है जिसे प्रोवाइडर सपोर्ट से मिलाया जा सके। इसे मापी गई टास्क जरूरत और उपलब्ध कॉन्टेक्स्ट से चुनें। बहुत बड़ी वैल्यू पात्रता घटाती है और लंबा या बेहतर उत्तर सुनिश्चित नहीं करती।

अपने पैरामीटर अनिवार्य करें #

{
  "model": "openai/gpt-oss-120b",
  "messages": [
    {"role": "user", "content": "Explain the failure modes of a retry loop."}
  ],
  "max_tokens": 8192,
  "provider": {
    "require_parameters": true
  }
}

require_parameters का डिफ़ॉल्ट false है। डिफ़ॉल्ट रूटिंग में असमर्थित पैरामीटर किसी एंडपॉइंट को हमेशा बाहर नहीं करते। OpenRouter बताता है कि प्रोवाइडर अज्ञात पैरामीटरों को अनदेखा करते हैं। इसे true करने पर घोषित सपोर्ट के आधार पर रूटिंग फ़िल्टर होती है।

सपोर्ट मेटाडेटा व्यवहार की गारंटी नहीं देता। seed सपोर्ट बताने वाले एंडपॉइंट को भी रिप्रोड्यूसिबिलिटी परीक्षण चाहिए। टूल-सक्षम एंडपॉइंट को स्कीमा वैलिडेशन और एप्लिकेशन परीक्षण चाहिए। यह फ़िल्टर ज्ञात असंगतियों को उम्मीदवार सेट में आने से रोकता है।

प्रोवाइडर को सोच-समझकर पिन करें #

{
  "model": "openai/gpt-oss-120b",
  "messages": [
    {"role": "user", "content": "Summarize the supplied incident report."}
  ],
  "max_tokens": 8192,
  "provider": {
    "order": ["REPLACE_WITH_VERIFIED_PROVIDER_SLUG"],
    "allow_fallbacks": false,
    "require_parameters": true
  }
}

प्लेसहोल्डर बदलें। मॉडल की प्रोवाइडर सूची से कॉपी किया गया प्रोवाइडर स्लग इस्तेमाल करें। वास्तविक अनुरोध में रिपोर्ट दें। यह टेम्पलेट कॉन्फ़िगरेशन समीक्षा के लिए है। प्लेसहोल्डर बदलने तक यह चलने योग्य अनुरोध नहीं।

order प्राथमिकता तय करता है। अकेले यह अन्य प्रोवाइडर के फॉलबैक को चालू रखता है। इसे allow_fallbacks: false के साथ रखने पर रूटिंग सूचीबद्ध प्रोवाइडर तक सीमित रहती है। कोई प्रोवाइडर अनुरोध पूरा न करे या उपलब्ध न रहे, तो अनुरोध विफल होगा।

एंडपॉइंट वेरिएंट पर ध्यान दें। मूल प्रोवाइडर स्लग दस्तावेजित matching नियमों के अनुसार कई वेरिएंट से मेल खाता है। किसी खास सेवा कॉन्फ़िगरेशन को परीक्षण करते समय विशिष्ट वेरिएंट स्लग इस्तेमाल करें। हर प्रतिक्रिया में बताए गए प्रोवाइडर की फिर जांच करें।

quantizations नामित प्रारूपों की allowlist है, संख्यात्मक न्यूनतम नहीं। "fp8" वाला array मेल खाते FP8 एंडपॉइंट चुनता है। इसमें BF16 या अधिक बिट वाले सभी प्रारूप अपने आप शामिल नहीं होते। पहले मूल चेकपॉइंट की तुलना करें, फिर तभी फ़िल्टर लगाएं जब आपका मूल्यांकन इसे उचित ठहराए।

गुणवत्ता रूटिंग चालू रखें #

{
  "model": "openai/gpt-oss-120b:exacto",
  "messages": [
    {"role": "user", "content": "Compare the two supplied incident reports."}
  ],
  "max_tokens": 8192,
  "provider": {
    "require_parameters": true
  }
}

Auto Exacto कम प्रदर्शन वाले प्रोवाइडर की प्राथमिकता घटाने के लिए throughput, टूल-कॉल टेलीमेट्री और बेंचमार्क इस्तेमाल करता है। OpenRouter की मार्च 2026 की घोषणा GLM-5 टूल-कॉल त्रुटियों में 88% गिरावट बताती है, लगभग 8% से लगभग 1% तक। इसमें gpt-oss-120b के 5.6% से 3.5% तक जाने की भी रिपोर्ट है।

ये प्रोवाइडर द्वारा रिपोर्ट किए गए rollout परिणाम हैं, आपके ऐप की गारंटी नहीं। टूल-कॉल वैधता JSON, नाम और स्कीमा मापती है। सिंटैक्टिक रूप से सही कॉल में भी टास्क के सही आर्ग्युमेंट और कार्रवाई चाहिए।

टूल वाले अनुरोधों को पर्याप्त प्रोवाइडर कवरेज होने पर डिफ़ॉल्ट रूप से Auto Exacto मिलता है। अन्य अनुरोधों के लिए :exacto गुणवत्ता रूटिंग चालू करता है। वर्तमान दस्तावेज टूल उपयोग के साथ सारांश और चैट में भी गुणवत्ता रूटिंग का समर्थन करते हैं।

sort: "price", :floor suffix और अकाउंट-स्तरीय डिफ़ॉल्ट price sort Auto Exacto को बंद करते हैं। ऐप सेटिंग और अकाउंट प्राथमिकताएं साथ देखें। रूटिंग नियंत्रण मिलाने से पहले Auto Exacto दस्तावेज पढ़ें।

अपने वर्कलोड की लागत निकालें #

केवल इनपुट कीमत अधूरी तुलना है। इन उदाहरणी दरों को डॉलर प्रति दस लाख टोकन में लें। ये गणित दिखाती हैं, वर्तमान प्रोवाइडर कोट नहीं।

Workload: 6 million input tokens + 1 million output tokens

A = 6 × $0.03 + 1 × $16.00 = $16.18
B = 6 × $0.42 + 1 × $1.32  =  $3.84

Per million combined input and output tokens:
A = $16.18 / 7 = $2.31
B =  $3.84 / 7 = $0.55

इस मिश्रण में एंडपॉइंट A लगभग 4.2 गुना महंगा है भले ही उसकी इनपुट कीमत कम है। A का 533 से 1 वाला आउटपुट/इनपुट मूल्य अनुपात दो दरों का अनुपात है, उपयोगकर्ता की कुल लागत का गुणक नहीं। इनपुट और आउटपुट का अलग अनुपात तुलना बदल देता है।

API की मूल्य इकाइयां तुलना तालिकाओं से अलग हैं। एंडपॉइंट API टोकन कीमत को प्रति टोकन व्यक्त करती है। ऊपर की दरों से तुलना करने से पहले इसे दस लाख से गुणा करें।

प्रॉम्प्ट कैशिंग एक और चर जोड़ती है। कैश रीड, कैश राइट और बिना कैश वाला इनपुट प्रोवाइडर के बिलिंग नियम के अनुसार अलग गणना चाहते हैं। दोहराया गया टेक्स्ट कैश हिट की गारंटी नहीं देता। प्रॉम्प्ट कैशिंग दस्तावेज में रिपोर्ट किए गए कैश्ड टोकन और लागत देखें।

रूटिंग कैश निरंतरता को प्रभावित करती है। OpenRouter कैशिंग के लिए sticky routing बताता है, जबकि मैन्युअल प्रोवाइडर क्रम को प्राथमिकता मिलती है। Auto Exacto प्रोवाइडर क्रम बदलता है और कभी-कभी warm cache बाधित करता है। नीति बदलने से पहले कैश बचत की तुलना गुणवत्ता और रिट्राई लागत से करें।

स्वीकृत परिणाम की लागत ऐप का उपयोगी मेट्रिक है। रिट्राई और विफल प्रयास सहित कुल खर्च को स्वीकार्य परिणामों की संख्या से विभाजित करें। लागू गैर-टोकन शुल्क अलग शामिल करें। कम टोकन दर बार-बार विफल टास्क की भरपाई नहीं करती।

असंगत उत्तर का निदान करें #

प्रतिक्रिया के साथ आया generation ID बचाएं। OpenRouter की generation metadata API प्रोवाइडर पहचान, उपयोग, लागत और समाप्ति जानकारी दिखाती है। session ID जुड़े काम को समूहित करती है, पर एक अनुरोध की जांच के लिए generation ID का स्थान नहीं लेती।

generation ID के साथ अनुरोध भी बचाएं। मॉडल, प्रोवाइडर प्राथमिकताएं, मांगे पैरामीटर, समय और प्रतिक्रिया उपयोग को साथ रखें। रूटिंग, कीमत या एंडपॉइंट मेटाडेटा बदलने के बाद भी बाद की गुणवत्ता या लागत तुलना दोहराई जा सकेगी।

समान परिस्थितियों में एंडपॉइंट की तुलना करें। समान प्रॉम्प्ट, टूल, रीज़निंग सेटिंग और टोकन बजट रखें। कई प्रतिनिधि टास्क पर दोहराएं। अधूरे उत्तर, अमान्य टूल कॉल और गलत उत्तर को एक अस्पष्ट गुणवत्ता स्कोर में न मिलाएं।

बेंचमार्क की अनिश्चितता महत्वपूर्ण है। Epoch AI का बेंचमार्क विश्लेषण इम्प्लीमेंटेशन, सैंपलिंग और एजेंट स्कैफोल्ड से होने वाले अंतर बताता है। एक निराशाजनक उत्तर स्थायी प्रोवाइडर दोष या उसका कारण सिद्ध नहीं करता।

एंडपॉइंट रूटिंग वॉकथ्रू #

आगे देखें: OpenRouter एंडपॉइंट गुणवत्ता और रूटिंग चर्चा । विशिष्ट कीमत, सीमा या प्रोवाइडर तुलना लागू करने से पहले एंडपॉइंट सूची फिर जांचें।

अगले कदम #

1. एक मॉडल के एंडपॉइंट जांचें और अपने वर्कलोड से जुड़ी सीमाएं दर्ज करें।
2. रूटिंग नीति चुनें जिसमें पैरामीटर आवश्यकताएं और फॉलबैक व्यवहार स्पष्ट हों।
3. प्रतिनिधि टास्क का परीक्षण करें और उम्मीदवार एंडपॉइंट तथा गुणवत्ता रूटिंग की तुलना करें।
4. स्वीकृत परिणाम की लागत दर्ज करें साथ में लेटेंसी, कैश उपयोग और विफलता श्रेणियां भी रखें।
5. मॉडल संस्करण, सर्विंग व्यवहार या प्रोवाइडर कीमत बदलने के बाद फिर जांचें।

AI की व्यापक बुनियादी जानकारी के लिए, AI की मूल अवधारणाएं पढ़ें। एजेंट अनुमतियों और वैलिडेशन नियंत्रणों के लिए AI सिस्टम सुरक्षित करना पढ़ें।