मुख्य सामग्री पर जाएं
FlexInference OpenAI-संगत अनुरोधों को स्वीकार करता है। आधिकारिक OpenAI SDK या curl का उपयोग करें, बेस URL को FlexInference पर सेट करें, अपनी flex_live_ key से प्रमाणित करें, और प्रत्येक अनुरोध पर आवश्यक start_within फ़ील्ड भेजें। इसे छोड़ देने पर आपको 400 missing_start_within मिलेगा।
FlexInference चार POST endpoints का समर्थन करता है और प्रत्येक कॉलर के आकार को प्लानर द्वारा चयनित प्रोवाइडर सतह में अनुवादित करता है:
  • POST /v1/responses: the Responses API
  • POST /v1/chat/completions: the Chat Completions API
  • POST /v1/interactions: the Interactions API (works with OpenAI, Gemini, and Anthropic models)
  • POST /v1/messages: the Anthropic Messages API (works with any model)
प्रत्येक endpoint वैकल्पिक क्रमबद्ध provider array को भी स्वीकार करता है ताकि रूट को पिन किया जा सके; नीचे रूट को पिन करना देखें। OpenAI SDK /v1/responses और /v1/chat/completions को कवर करता है। यह /v1/interactions या /v1/messages को उजागर नहीं करता है, इसलिए उन तक curl या FlexInference native SDKs (Python, TypeScript) के साथ पहुँचें।

क्लाइंट को कॉन्फ़िगर करें

start_within पास करना

start_within FlexInference को बताता है कि अनुरोध को परिणाम देना शुरू करने के लिए उसे कितनी देर तक इंतजार करना पड़ सकता है। एक मिनट के लिए 00h-01m-00s जैसी अवधि का उपयोग करें। एक अवधि flex race चलाती है: प्लानर उस बजट के भीतर एक सस्ता flex tier आज़माता है, फिर जब flex समय पर शुरू नहीं हो पाता है तो standard पर चला जाता है। OpenAI SDKs start_within को टाइप नहीं करते हैं, इसलिए इसे Python में extra_body और Node में एक untyped request object के साथ पास करें।
मानों के पूर्ण सेट के लिए Deadline routing देखें।

flex परिणाम पढ़ना

रिस्पॉन्स बॉडी में service_tier और x-flexinference-flex-* रिस्पॉन्स हेडर पढ़ें। x-flexinference-flex-applied बताता है कि क्या flex ने रिस्पॉन्स दिया। x-flexinference-flex-reason मशीन-पठनीय परिणाम देता है, जिसमें flex_committed और flex_lost_race शामिल हैं। एक अवधि जो flex race नहीं चला सकती है, 400 flex_unsupported_for_anthropic या 400 flex_model_not_capable लौटाती है। हेडर कैसे पढ़ें, इसके लिए Deadline routing और पूरी सूची के लिए Errors देखें।

स्ट्रीमिंग

stream: true सेट करें और OpenAI की तरह इवेंट्स का उपभोग करें। स्ट्रीमिंग रूटिंग को नहीं बदलती है। FlexInference पहले एक tier के लिए प्रतिबद्ध होता है, फिर उस tier के जवाब देना शुरू करने के बाद टोकन स्ट्रीम करता है।

टाइमआउट

start_within यह निर्धारित करता है कि अनुरोध कब शुरू होता है, न कि कुल जनरेशन समय। FlexInference HTTP रिस्पॉन्स को तब तक रोके रखता है जब तक एक tier प्रतिबद्ध नहीं हो जाता। flex के प्रतिबद्ध होने के बाद, यह पूरा होने तक चलता है; FlexInference एक प्रतिबद्ध अनुरोध को standard पर स्विच नहीं करता है क्योंकि जनरेशन धीमा है। अपने क्लाइंट टाइमआउट को प्रतीक्षा विंडो और मॉडल को जवाब देने के लिए आवश्यक समय को कवर करने के लिए सेट करें। OpenAI SDK डिफ़ॉल्ट रूप से 10 मिनट के टाइमआउट पर सेट होता है, जो सबसे लंबी अनुमत start_within से मेल खाता है। यदि जनरेशन एक लंबी विंडो के अंत के करीब शुरू हो सकता है, तो टाइमआउट को डिफ़ॉल्ट से ऊपर बढ़ाएँ। एक छोटा टाइमआउट FlexInference द्वारा परिणाम लौटाने से पहले अनुरोध को रद्द कर सकता है। client_closed_request देखें।
FlexInference native SDKs (Python, TypeScript) इसे स्वचालित रूप से संभालते हैं। वे start_within से पहले-रिस्पॉन्स की प्रतीक्षा का आकार निर्धारित करते हैं, idle timeout के साथ अटकी हुई स्ट्रीम को कैप करते हैं, और कुल कैप के बिना स्ट्रीम छोड़ देते हैं ताकि लंबे जवाब पूरे हो सकें। नॉन-स्ट्रीमिंग कॉल कुल बजट बनाए रखते हैं। प्रत्येक टाइमआउट क्लाइंट पर और प्रति अनुरोध कॉन्फ़िगर करने योग्य है।

अस्थायी अपस्ट्रीम विफलताओं को पुनः प्रयास करना

एक वैकल्पिक retry ऑब्जेक्ट जोड़ें ताकि आपके अनुरोध को सेवा देने वाले tier को फिर से हिट किया जा सके जब वह एक अस्थायी 429 या 5xx के साथ शुरू होने में विफल रहता है। इसे उसी तरह पास करें जैसे आप start_within पास करते हैं।
count 1 से 5 तक चलता है, backoff "exponential" (डिफ़ॉल्ट) या "linear" होता है, और jitter डिफ़ॉल्ट रूप से true होता है। पुनः प्रयास केवल रिस्पॉन्स प्रतिबद्ध होने से पहले ही फिर से हिट करता है, प्रोवाइडर के Retry-After का सम्मान करता है, और आपके क्लाइंट SDK के अपने पुनः प्रयासों के साथ स्टैक करता है। पूर्ण व्यवहार और x-flexinference-retries रिस्पॉन्स हेडर के लिए Deadline routing देखें।

रूट को पिन करना

एक वैकल्पिक क्रमबद्ध provider array यह पिन करता है कि कौन सा प्रोवाइडर रूट आपके अनुरोध को सेवा देता है। यह प्रत्येक endpoint पर लागू होता है: /v1/responses, /v1/chat/completions, /v1/interactions, और /v1/messages। एलिमेंट 0 प्राथमिक रूट और एकमात्र flex gate है; एलिमेंट 1 से n तक समान-मॉडल फ़ॉलबैक चेन हैं, जिन्हें रूट के अस्थायी रूप से विफल होने पर क्रम में आज़माया जाता है। इसे छोड़ देने पर FlexInference मॉडल के native रूट का उपयोग करता है। इसे उसी तरह पास करें जैसे आप start_within पास करते हैं। आपके द्वारा नामित प्रत्येक रूट को पहले अपनी key कॉन्फ़िगर करने की आवश्यकता है। एक गुम key उस रूट के लिए 400 लौटाती है और कभी भी अगले पर नहीं जाती है, इसलिए इसे नाम देने से पहले डैशबोर्ड में प्रत्येक रूट की key जोड़ें। provider routing देखें।
google, openai, और anthropic सीधे रूट हैं। vertex (Gemini) और bedrock (Claude) क्लाउड रूट हैं जो Google Vertex AI और Amazon Bedrock पर समान मॉडल को सेवा देते हैं; प्रत्येक को उस क्लाउड की अपनी BYOK key की आवश्यकता होती है। एक अमान्य array 400 invalid_provider_chain लौटाता है, एक रूट जो मॉडल को सेवा नहीं दे सकता है वह 400 provider_model_mismatch लौटाता है, और क्लाउड रूट के साथ एक अवधि start_within पहले 400 flex_unsupported_on_cloud लौटाता है। FlexInference native SDKs provider को टाइप करते हैं और अनुरोध आपके प्रोसेस से निकलने से पहले स्थानीय रूप से उसके आकार की जाँच करते हैं; OpenAI SDK इसे टाइप नहीं करता है, इसलिए इसे extra_body या एक untyped object के माध्यम से पास करें। वैध-चेन मैट्रिक्स के लिए provider routing देखें।

चैट कंप्लीशन

चैट कंप्लीशन समान start_within नियमों का उपयोग करता है। जब अनुरोध canonical Responses के माध्यम से रूट हो सकता है तो एक अवधि flex race चलाती है। OpenAI चैट अनुरोध canonical Responses के माध्यम से रूट होते हैं जब तक कि एक native Chat parameter को OpenAI Chat passthrough की आवश्यकता न हो; native-only Chat parameters को एक अवधि start_within के साथ संयोजित नहीं किया जा सकता है।

इंटरैक्शन

Interactions endpoint OpenAI, Gemini, और Anthropic मॉडलों के लिए एक और कॉलर फॉर्मेट है। start_within उसी तरह लागू होता है। input को एक स्ट्रिंग, भागों के content-array, या एक मल्टी-टर्न स्टेप लिस्ट के रूप में भेजें। system_instruction, tools, और response_format समान अपस्ट्रीम सुविधाओं से मैप होते हैं।
रिस्पॉन्स एक interaction ऑब्जेक्ट है। आउटपुट steps में है। usage इनपुट, आउटपुट, थॉट, कैश्ड, टूल-यूज़ और कुल में टोकन काउंट को विभाजित करता है।
status requires_action होता है जब एक स्टेप function_call होता है, incomplete होता है जब आउटपुट छोटा होता है, त्रुटि पर failed होता है, और अन्यथा completed होता है। generation_config.thinking_level reasoning.effort से मैप होता है। अतिरिक्त generation_config.* keys Gemini मॉडलों पर पास होती हैं। गैर-Gemini मॉडलों पर, कोई भी गैर-मैप की गई generation_config.* key unsupported_generation_config के साथ विफल हो जाती है। एक कॉलर-आपूर्ति service_tier को service_tier_not_allowed के साथ अस्वीकार कर दिया जाता है; Errors देखें। FlexInference start_within से tier चयन प्राप्त करता है। यदि आप service_tier भेजते हैं, तो अनुरोध service_tier_not_allowed के साथ विफल हो जाता है। फ़ील्ड को हटा दें और start_within के माध्यम से tier को व्यक्त करें। पूरी सूची और उदाहरण बॉडी के लिए Errors देखें।

संदेश

Messages endpoint Anthropic Messages अनुरोध और रिस्पॉन्स आकार का उपयोग करता है। यह किसी भी मॉडल के साथ काम करता है क्योंकि FlexInference canonical फॉर्म के माध्यम से अनुवाद करता है। start_within आवश्यक है। Anthropic को max_tokens की आवश्यकता होती है; FlexInference इसे तब आगे बढ़ाता है जब आप इसे सेट करते हैं और जब आप इसे छोड़ देते हैं तो डिफ़ॉल्ट को संश्लेषित नहीं करता है। messages को {role, content} टर्न के रूप में भेजें, जिसमें content एक स्ट्रिंग या content blocks का एक array हो। system, tools, tool_choice, और thinking समान अपस्ट्रीम सुविधाओं से मैप होते हैं।
रिस्पॉन्स एक Anthropic message ऑब्जेक्ट है। आउटपुट content में text, thinking, और tool_use ब्लॉक्स के रूप में है। usage.service_tier सेवा दिया गया tier है, या तो flex या standard।
stop_reason सामान्य समाप्ति पर end_turn होता है, छोटा होने पर max_tokens, जब मॉडल एक टूल को कॉल करता है तो tool_use, और जब यह मना करता है तो refusal होता है। thinking प्रति मॉडल reasoning.effort से मैप होता है। Claude मॉडलों पर, native Anthropic फ़ील्ड जैसे top_k, stop_sequences, cache_control ब्लॉक्स, उद्धरण, और document या file content ब्लॉक्स पास होते हैं। OpenAI या Gemini मॉडलों पर, base64 स्रोतों वाले document और file content ब्लॉक्स canonical input_file में अनुवादित होते हैं और अस्वीकृत नहीं होते हैं। रिमोट URL दस्तावेज़ अभी भी लक्ष्य प्रोवाइडर के अपने समर्थन पर निर्भर करते हैं। अन्य Anthropic-native फ़ील्ड, जिनमें top_k, stop_sequences, cache_control ब्लॉक्स, और उद्धरण शामिल हैं, क्रॉस-प्रोवाइडर unsupported_parameter के साथ विफल हो जाते हैं। एक कॉलर-आपूर्ति service_tier हमेशा service_tier_not_allowed के साथ विफल हो जाता है; Errors देखें।

बाकी सब कुछ अपरिवर्तित रहता है

टूल कॉलिंग, संरचित आउटपुट (response_format), विजन, और रीजनिंग चयनित प्रोवाइडर को पास होते हैं। उन सुविधाओं के लिए प्रोवाइडर के सामान्य फ़ील्ड का उपयोग करें।
चैट-native पैरामीटर OpenAI मॉडलों पर पास होते हैं जब native Chat passthrough की आवश्यकता होती है: presence_penalty, frequency_penalty, logit_bias, logprobs, top_logprobs, seed, stop, prediction, audio, गैर-टेक्स्ट modalities, और web_search_options। Gemini या Claude मॉडलों पर, इनमें से किसी भी फ़ील्ड को वास्तविक मान पर सेट करने पर unsupported_parameter के साथ विफल हो जाता है। चैट कंप्लीशन n > 1 हमेशा unsupported_value के साथ विफल हो जाता है। canonical पाथ पर वेब खोज के लिए, Responses web_search टूल का उपयोग करें।