मुख्य सामग्री पर जाएं
start_within हर FlexInference अनुरोध पर आवश्यक है। यह निर्धारित करता है कि राउटर अनुरोध शुरू होने के लिए कितनी देर तक प्रतीक्षा कर सकता है। जब आप सीधे किसी प्रोवाइडर टियर को चाहते हैं, तो default, priority, या auto का उपयोग करें। जब आप चाहते हैं कि FlexInference पहले flex-सक्षम मॉडल पर flex को आज़माए, फिर यदि flex समय पर शुरू नहीं हो पाता है तो standard में वृद्धि करे, तो एक अवधि का उपयोग करें। फ़ील्ड के चार रूप हैं।

चार रूप

प्रोवाइडर के standard रीयल-टाइम टियर पर standard मूल्य निर्धारण पर रूट करता है: OpenAI का default, Gemini का standard, या Anthropic का standard_only। किसी भी मॉडल के साथ काम करता है।
default, priority, और auto किसी भी मॉडल को उसके प्रोवाइडर (OpenAI, Gemini, या Anthropic) को प्रॉक्सी करते हैं। केवल एक अवधि flex race का अनुरोध करती है। यदि मॉडल flex का उपयोग नहीं कर सकता है, तो एक अवधि 400 (flex_unsupported_for_anthropic या flex_model_not_capable) लौटाती है; इसके बजाय एक टियर मान का उपयोग करें।
flex race Claude पर उपलब्ध नहीं है क्योंकि Anthropic का कोई flex टियर नहीं है। claude-* मॉडल पर एक अवधि start_within 400 flex_unsupported_for_anthropic लौटाती है। Anthropic अभी भी default, priority, और auto टियर प्रॉक्सी अनुरोधों के साथ काम करता है।
एक अवधि start_within को native-only Chat Completions पैरामीटर जैसे logprobs या seed के साथ नहीं जोड़ा जा सकता है। उन पैरामीटरों को हटा दें, या इसके बजाय default, priority, या auto का उपयोग करें।

flex रेस

एक अवधि के साथ, FlexInference पहले प्रोवाइडर के flex टियर (OpenAI या Gemini) का प्रयास करता है। Flex को standard दर के आधे पर बिल किया जाता है, लेकिन क्षमता best-effort होती है। राउटर आपके विंडो के भीतर अपस्ट्रीम अनुरोध शुरू होने की प्रतीक्षा करता है:
1

flex को फायर करें

FlexInference आपके अनुरोध को flex टियर पर भेजता है और प्रोवाइडर द्वारा इसकी पूर्ति की पुष्टि करने की प्रतीक्षा करता है, यह सब आपके द्वारा निर्धारित समय के भीतर होता है।
2

flex के लिए प्रतिबद्ध

यदि प्रोवाइडर समय पर अनुरोध शुरू करता है, तो FlexInference प्रतिबद्ध होता है। आपकी प्रतिक्रिया सामान्य रूप से स्ट्रीम होती है, जिसे flex दरों पर बिल किया जाता है। प्रतिक्रिया "service_tier": "flex" दिखाती है।
3

standard में वृद्धि करें

यदि flex समय पर शुरू नहीं हो पाता है, तो FlexInference इसे रद्द कर देता है और अनुरोध को standard पर भेजता है। यह सस्ते flex से standard तक की वृद्धि है, न कि downgrade। प्रतिक्रिया "service_tier": "default" (OpenAI) या "standard" (Gemini) दिखाती है।
standard में वृद्धि केवल flex शुरू होने से पहले होती है, जब flex 429 (कोई क्षमता नहीं), कोई 5xx, प्री-स्टार्ट विफलता, या समय-सीमा से पहले कोई शुरुआत नहीं लौटाता है। flex-से-standard स्विच एकमात्र टियर परिवर्तन है जो FlexInference करता है। एक प्रोवाइडर फ़ॉलबैक, जहाँ आप एक वैकल्पिक provider array सेट करते हैं और FlexInference एक रूट के अस्थायी रूप से विफल होने के बाद अगले रूट का प्रयास करता है, रूट को बदलता है, टियर या मॉडल को कभी नहीं। आपके द्वारा नामित किसी भी रूट के लिए एक गुम key एक अस्थायी विफलता के बजाय एक कॉन्फ़िगरेशन त्रुटि है, इसलिए यह फ़ॉल-थ्रू होने के बजाय 400 लौटाता है। provider routing देखें।
सबसे लंबी अवधि चुनें जिसे आपका UX सहन कर सकता है। लंबी विंडो flex को जीतने के लिए अधिक समय देती हैं, जिससे सस्ती दर पर सेवा दिए गए अनुरोधों का हिस्सा बढ़ जाता है।

परिणाम पढ़ना

सफल 200 प्रतिक्रियाओं में स्ट्रीमिंग और नॉन-स्ट्रीमिंग दोनों कॉल के लिए हर endpoint पर Flex परिणाम हेडर शामिल होते हैं। त्रुटि प्रतिक्रियाएं इसके बजाय त्रुटि बॉडी का उपयोग करती हैं। लाइव x-flexinference-flex-reason मान हैं:
एक अवधि जो flex race नहीं चला सकती है, 400 लौटाती है (claude-* मॉडल पर flex_unsupported_for_anthropic, गैर-flex-सक्षम OpenAI/Gemini मॉडल पर flex_model_not_capable); हेडर कारण केवल उन अनुरोधों का वर्णन करते हैं जिन्होंने flex चलाया या इसका अनुरोध नहीं किया।

जब flex पूल अनुपलब्ध हो

flex टियर साझा, best-effort क्षमता का उपयोग करता है। अनुरोध शुरू होने से पहले, flex 429 लौटा सकता है जब कोई क्षमता नहीं होती है, कोई 5xx लौटा सकता है, प्री-स्टार्ट विफल हो सकता है, या समय-सीमा चूक सकता है। FlexInference तब अनुरोध को standard पर भेजता है। दुर्लभ मामलों में, flex अनुरोध स्वीकार किए जाने और स्ट्रीमिंग शुरू होने के बाद विफल हो जाता है। FlexInference उस विफलता को उजागर करता है। एक स्ट्रीमिंग अनुरोध पर आपको एक टर्मिनल response.failed इवेंट मिलता है। एक नॉन-स्ट्रीमिंग अनुरोध पर आपको 502 मिलता है। यह प्रतिबद्धता के बाद पुनः प्रयास नहीं करता क्योंकि इससे एक अधूरा अनुरोध मास्क हो सकता है। यदि आप इससे टकराते हैं, तो पुनः प्रयास करें, या flex को छोड़ने के लिए default, priority, या auto का उपयोग करें।

ट्रांसपोर्ट पुनः प्रयास

flex race यह तय करता है कि कौन सा टियर आपके अनुरोध को सेवा देगा। ट्रांसपोर्ट पुनः प्रयास यह तय करता है कि जब वह टियर शुरू होने में विफल रहता है तो क्या होता है। एक वैकल्पिक retry ऑब्जेक्ट जोड़ें और FlexInference प्रतीक्षा करता है और एक अस्थायी अपस्ट्रीम विफलता पर सेटल किए गए टियर को फिर से हिट करता है, बजाय इसके कि आपको त्रुटि लौटाए।
एक अमान्य retry 400 invalid_retry लौटाता है। FlexInference केवल सेटल किए गए टियर से एक वास्तविक प्री-कमिट ट्रांसपोर्ट विफलता को पुनः प्रयास करता है: एक वास्तविक 429, एक वास्तविक 5xx, या एक कनेक्शन जो कभी नहीं खुला (upstream_unavailable)। यह क्लाइंट 4xx, एक अपस्ट्रीम auth विफलता (upstream_auth_failed), एक अपस्ट्रीम timeout (upstream_timeout), या क्लाइंट द्वारा रद्द किए गए अनुरोध को पुनः प्रयास नहीं करता है। वे या तो पुनः हिट पर उसी तरह विफल होते हैं या इसका मतलब है कि कॉलर पहले ही चला गया है। पुनः प्रयास उस टियर को फिर से हिट करता है जिसने आपके अनुरोध को सेटल किया, न कि flex लेग को। default, priority, या auto अनुरोध पर वह टियर है जिसे आपने नामित किया था। एक अवधि अनुरोध पर जो flex race हार जाता है, वह standard टियर है जिस पर आपने वृद्धि की थी। flex प्रयास और वृद्धि flex race का अपना काम है और count के विरुद्ध कभी नहीं गिना जाता है। एक टियर को ऊपर बढ़ाना और उसी टियर को पुनः प्रयास करना अलग-अलग चरण हैं जो श्रृंखला बनाते हैं: flex standard से हार जाता है, फिर standard खुद को पुनः प्रयास कर सकता है। जब प्रोवाइडर Retry-After हेडर भेजता है, तो FlexInference बैकऑफ़ शेड्यूल के बजाय उतनी देर प्रतीक्षा करता है, जिसे 60 सेकंड तक सीमित किया जाता है ताकि एक खराब मान आपके अनुरोध को पार्क न कर सके।
पुनः प्रयास केवल प्री-कमिट होता है। यह उस क्षण रुक जाता है जब एक टियर प्रतिबद्ध होता है, जो स्ट्रीमिंग और नॉन-स्ट्रीमिंग दोनों कॉल के लिए 200 स्टेटस लाइन है। एक बार जब पहला बाइट आप तक पहुंच जाता है, तो FlexInference कभी पुनः प्रयास नहीं करता है, वही नियम जो flex race प्रतिबद्धता के बाद पालन करता है। एक मिड-स्ट्रीम विफलता, या एक प्रतिबद्ध 200 के बाद एक नॉन-स्ट्रीमिंग 502, आप तक पहुंच जाती है।
सर्वर-साइड retry आपके क्लाइंट में किसी भी पुनः प्रयास लूप से अलग है, और दोनों स्टैक होते हैं। FlexInference SDK पुनः प्रयास नहीं करते हैं, लेकिन एक स्टॉक OpenAI या Anthropic SDK डिफ़ॉल्ट रूप से दो बार पुनः प्रयास करता है। एक क्लाइंट जो सर्वर count के 3 के ऊपर दो बार पुनः प्रयास करता है, छह अपस्ट्रीम प्रयासों तक चलाता है, क्योंकि प्रत्येक क्लाइंट प्रयास एक पूर्ण सर्वर बजट चलाता है। जब आप retry सेट करते हैं, तो FlexInference प्रतिक्रिया पर x-flexinference-retries को उन पुनः हिट की संख्या के साथ स्टैंप करता है जिन्हें उसने चलाया था, ताकि आप अपने क्लाइंट के max_retries को कम कर सकें।

बिलिंग

BYOK के साथ, FlexInference आपके संग्रहीत एन्क्रिप्टेड प्रोवाइडर key का सर्वर-साइड उपयोग करता है; आप प्रति अनुरोध प्रोवाइडर key नहीं भेजते हैं। आपका प्रोवाइडर आपके खाते को उस टियर की दर पर बिल करता है जिसने अनुरोध को सेवा दी थी। जब flex प्रतिबद्ध होता है तो आप flex दरें और वृद्धि के बाद standard दरें चुकाते हैं। एक flex प्रयास विफल होने से पहले कुछ token जला सकता है। आपका प्रोवाइडर उस उपयोग को उसी तरह बिल करता है जैसे वह सीधे flex को कॉल करने पर करता, और FlexInference इसे उपयोग में शामिल करता है। FlexInference आपके token पर कोई मार्कअप नहीं जोड़ता है। यह आपके द्वारा बचाए गए पैसे का 20% चार्ज करता है, और जब कोई बचत नहीं होती है तो कुछ भी चार्ज नहीं करता है।

FlexInference क्या बदलता है

FlexInference टियर को बदल सकता है। यह आपके अनुरोध के अर्थ या प्रोवाइडर के परिणाम को नहीं बदलता है। यह प्रोवाइडर की स्थिति या संदेश को कभी भी फिर से नहीं लिखता है। यह केवल त्रुटि लिफाफे को सामान्य करता है: एक त्रुटि आपके द्वारा बुलाए गए endpoint (responses और chat पर OpenAI, messages पर Anthropic, interactions पर Google) के आकार में लौटाई जाती है, जिसमें प्रोवाइडर की स्थिति और संदेश होता है, ताकि आपका SDK इसे पार्स कर सके। Errors देखें।
start_within आवश्यक है। इसके बिना, अनुरोध 400 missing_start_within लौटाता है, जिसमें हमारे बेस URL पर इंगित एक सादा OpenAI SDK भी शामिल है। यदि आप एक ऐसा मान भेजते हैं जिसे FlexInference पढ़ नहीं सकता है, तो आपको invalid_start_within मिलता है। वैध मान "default", "priority", "auto", या "00h-00m-30s" जैसी अवधि हैं। केवल standard शब्द पहले अनुमत था और अब नहीं है, इसलिए इसके बजाय default भेजें। पूरी सूची के लिए Errors देखें।