Requesty ट्यूटोरियल: ऑटोमैटिक फेलओवर वाला यूनिफाइड LLM गेटवे

आपका AI अनुप्रयोग OpenAI के साथ बेहतरीन चलता है—जब तक कि महीने का बिल $2,000 नहीं हो जाता। आप बेहतर रीज़निंग के लिए Anthropic और लागत बचत के लिए Google जोड़ते हैं, और अब आप तीन अलग-अलग API सँभाल रहे हैं—हर एक का अलग बिलिंग और मॉनिटरिंग। जब OpenAI डाउन होता है, आपका ऐप टूट जाता है। जब आप रेट लिमिट पर पहुँचते हैं, आपके उपयोगकर्ताओं को त्रुटियाँ दिखती हैं। आपको एक अधिक भरोसेमंद तरीका चाहिए।

Requesty इसे एक यूनिफाइड गेटवे के माध्यम से हल करता है, जिसमें ऑटोमैटिक फेलओवर और लागत अनुकूलन टूल्स होते हैं। डैशबोर्ड में एक बार फेलओवर चेन और कैशिंग प्रेफरेंसेज़ कॉन्फ़िगर करें—फिर हर API अनुरोध उन नीतियों का स्वतः पालन करेगा। 

जब कोई प्रदाता डाउन होता है, Requesty आपके बैकअप मॉडल पर स्विच कर देता है। जब आप Anthropic जैसे समर्थित प्रदाताओं पर कैशिंग सक्षम करते हैं, तो दोहराए जाने वाले प्रश्नों पर लागत कम हो जाती है।

इस ट्यूटोरियल में, मैं Requesty की मुख्य क्षमताएँ कवर करूँगा। मैं यूनिफाइड गेटवे के जरिए बुनियादी API कॉल और रिस्पॉन्स स्ट्रीमिंग से शुरू करूँगा। फिर हम गारंटीड अपटाइम के लिए ऑटोमैटिक फेलओवर कॉन्फ़िगर करेंगे, दोहराए जाने वाले प्रश्नों पर लागत घटाने के लिए प्रोवाइडर कैशिंग सक्षम करेंगे, और खर्च की निगरानी व उपयोग को अनुकूलित करने के लिए एनालिटिक्स डैशबोर्ड का उपयोग करेंगे। चाहे आप पहला AI प्रोटोटाइप बना रहे हों या बड़े पैमाने पर प्रोडक्शन सिस्टम डिप्लॉय कर रहे हों—ये फीचर्स एक जैसे काम करते हैं।

Requesty क्या है?

Requesty एक यूनिफाइड LLM गेटवे है जो OpenAI, Anthropic, Google, Meta, और AWS जैसे प्रदाताओं के 300+ मॉडलों से एक ही API के जरिए जोड़ता है। यह एक मैनेज्ड सर्विस है, इसलिए आपको कुछ होस्ट नहीं करना पड़ता।

ओवरव्यू और मुख्य विशेषताएँ

Requesty रूटिंग नीतियाँ कोड या कॉन्फ़िग फाइलों के बजाय डैशबोर्ड से कॉन्फ़िगर करता है। आप वेब इंटरफ़ेस में फेलओवर चेन, लोड बैलेंसिंग वेट्स और कैशिंग प्रेफरेंसेज़ सेट करते हैं, और ये नीतियाँ सभी API अनुरोधों पर स्वतः लागू होती हैं।

डैशबोर्ड-आधारित कॉन्फ़िगरेशन से ये संभव होता है:

• प्रोवाइडर-नेटिव कैशिंग: Anthropic और Gemini जैसे समर्थित प्रदाताओं पर कैशिंग सक्षम करें ताकि प्रॉम्प्ट के हिस्सों का पुन: उपयोग हो सके और बार-बार आने वाले अनुरोधों की लागत घटे।
• तेज़ ऑटोमैटिक फेलओवर: जब किसी प्रदाता में दिक्कत आती है, प्लेटफ़ॉर्म स्वतः बैकअप मॉडलों पर स्विच कर देता है, 99.99% SLA गारंटी के साथ।
• रियल-टाइम एनालिटिक्स: एकीकृत डैशबोर्ड के माध्यम से सभी अनुरोधों में टोकन, लागत, लेटेंसी परसेंटाइल, कैश हिट रेट और फेलओवर की आवृत्ति ट्रैक करें।

ये क्षमताएँ लचीली रूटिंग नीतियों (फॉलबैक चेन, लोड बैलेंसिंग, लेटेंसी ऑप्टिमाइज़ेशन), PII और प्रॉम्प्ट इंजेक्शन के लिए बिल्ट-इन सुरक्षा गार्डरेल, और विस्तृत लागत ट्रैकिंग के साथ मिलती हैं।

OpenRouter कई LLMs तक समान यूनिफाइड पहुँच देता है, पर रूटिंग बेसिक है और कोई एनालिटिक्स डैशबोर्ड नहीं। LiteLLM तुलनीय फीचर्स देता है, लेकिन सेल्फ-होस्टिंग और रूटिंग नीतियों के लिए मैन्युअल YAML कॉन्फ़िगरेशन की आवश्यकता होती है। Requesty इन दोनों के बीच बैठता है—डैशबोर्ड-ड्रिवन कॉन्फ़िगरेशन के साथ मैनेज्ड सर्विस के रूप में।

मुझे Requesty कब उपयोग करना चाहिए?

यदि आप सख्त अपटाइम आवश्यकताओं वाले एंटरप्राइज़ सिस्टम चला रहे हैं, तो 99.99% SLA मायने रखता है। आपका ऐप डाउन होता है तो आप पैसा खोते हैं। PII रिडैक्शन और प्रॉम्प्ट इंजेक्शन डिटेक्शन जैसी बिल्ट-इन सुरक्षा सुविधाएँ अनुपालन आवश्यकताओं को संभालती हैं—बिना आपको खुद ये सिस्टम बनाने पड़े। GDPR के तहत काम करने वाली टीम्स EU होस्टिंग सक्षम कर सकती हैं ताकि डेटा सही अधिकार क्षेत्रों में रहे।

प्रोडक्शन AI ऐप्स बनाने वाली डेवलपमेंट टीमें कोड फिर से लिखने के बजाय कॉन्फ़िगरेशन के जरिए प्रदाताओं के बीच स्विच कर vendor lock-in से बचती हैं। ऑटोमैटिक फेलओवर का मतलब है कि आपको कस्टम रीलायबिलिटी इंफ्रास्ट्रक्चर नहीं बनाना पड़ता।

बजट-सम्वेदनशील प्रोजेक्ट्स प्रदाता कैशिंग और रणनीतिक लोड बैलेंसिंग से लाभ उठाते हैं। ऑप्टिमाइज़ेशन लॉजिक खुद लिखने के बजाय, आप नीतियाँ एक बार कॉन्फ़िगर करें और लागत घटाने का काम Requesty पर छोड़ दें।

पूर्वापेक्षाएँ

अपना डेवलपमेंट वातावरण सेट करें। इसमें लगभग 5 मिनट लगते हैं और इसमें Python पैकेज, API की, और बुनियादी कॉन्फ़िगरेशन शामिल है।

आपके सिस्टम पर Python 3.7 या नया संस्करण इंस्टॉल होना चाहिए। अपना संस्करण जाँचें:

import sys
print(f"Python {sys.version_info.major}.{sys.version_info.minor}")संचालित द्वारा

आवश्यक पैकेज pip या uv से इंस्टॉल करें:

pip install openai python-dotenv
# or with uv: uv add openai python-dotenvसंचालित द्वारा

Requesty के API से इंटरैक्ट करने के लिए आपको openai पैकेज चाहिए। python-dotenv पैकेज एनवायरनमेंट वेरिएबल्स को सुरक्षित रूप से हैंडल करता है।

Requesty खाता बनाएँ: app.requesty.ai पर। लॉगिन करने के बाद API Keys सेक्शन में जाएँ और नई कुंजी जनरेट करें। प्रमाणीकरण के लिए इस कुंजी को कॉपी करें। अपने खाते में कुछ डॉलर जोड़ना न भूलें।

अपनी API कुंजी को अपने प्रोजेक्ट डायरेक्टरी में .env फाइल में सहेजें:

REQUESTY_API_KEY=your_api_key_hereसंचालित द्वारा

इससे क्रेडेंशियल्स आपके कोड से बाहर रहते हैं और आप सीक्रेट्स उजागर किए बिना अपना प्रोजेक्ट साझा कर सकते हैं।

एनवायरनमेंट वेरिएबल्स लोड करके और API कुंजी उपलब्ध है या नहीं, यह जाँचकर सब कुछ सत्यापित करें:

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
api_key = os.getenv("REQUESTY_API_KEY")

# Check your setup
if api_key:
   print("✓ API key loaded")
   client = OpenAI(
       api_key=api_key,
       base_url="https://router.requesty.ai/v1"
   )
   print("✓ Client configured")
else:
   print("✗ API key not found")संचालित द्वारा

यदि आपको दोनों चेकमार्क दिखते हैं, तो आप अपनी पहली रिक्वेस्ट करने के लिए तैयार हैं।

Requesty के साथ शुरुआत: अपनी पहली API कॉल करना

वातावरण कॉन्फ़िगर हो जाने और API कुंजी तैयार होने के बाद, आप अपनी पहली API कॉल कर सकते हैं। Requesty, OpenAI SDK का ड्रॉप-इन रिप्लेसमेंट की तरह काम करता है। यदि आपने पहले OpenAI का उपयोग किया है, तो यह परिचित लगेगा। एकमात्र अंतर है कि आप अपने क्लाइंट को Requesty के राउटर की ओर इंगित करते हैं।

क्लाइंट सेट अप करने का तरीका यहाँ है:

import os
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(
   api_key=os.getenv("REQUESTY_API_KEY"),
   base_url="https://router.requesty.ai/v1"
)संचालित द्वारा

यह base_url पैरामीटर आपकी रिक्वेस्ट को सीधे OpenAI के बजाय Requesty के जरिए रूट करता है। आप इसे GPT-5 पर कॉल करके टेस्ट कर सकते हैं:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(response.choices[0].message.content)संचालित द्वारा

आउटपुट:

Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.संचालित द्वारा

मॉडल पैरामीटर का फॉर्मैट provider/model-name होता है। यहाँ यह openai/gpt-5 है, जो OpenAI के नवीनतम मॉडल तक पहुँच देता है, जिसमें नेटिव रीज़निंग क्षमताएँ और बेहतर प्रदर्शन कोडिंग और गणितीय कार्यों में मिलता है। मॉडल फॉर्मैट और बेस URL के अलावा, SDK OpenAI के समान ही काम करता है।

नोट: हर API कॉल का खर्च होता है। Requesty, प्रदाता की बेस प्राइसिंग के ऊपर 5% मार्कअप जोड़ता है, इसलिए GPT-5 की लागत OpenAI को सीधे कॉल करने की तुलना में Requesty के जरिए थोड़ी अधिक होगी। आप विश्वसनीयता, फेलओवर क्षमताओं और यूनिफाइड डैशबोर्ड के लिए भुगतान कर रहे हैं। खर्च ट्रैक करने के लिए Requesty डैशबोर्ड से अपनी उपयोगिता मॉनिटर करें।

रिस्पॉन्स ऑब्जेक्ट में सिर्फ संदेश सामग्री से आगे भी उपयोगी मेटाडेटा होता है:

print(f"Model used: {response.model}")
print(f"Total tokens: {response.usage.total_tokens}")
print(f"Response: {response.choices[0].message.content}")संचालित द्वारा

आउटपुट:

Model used: gpt-5-2025-08-07
Total tokens: 108
Response: Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.संचालित द्वारा

टोकन काउंट लागत ट्रैक करने में मदद करता है, क्योंकि प्राइसिंग आमतौर पर प्रति टोकन होती है।

मॉडल नाम बदलकर किसी अन्य प्रदाता पर स्विच करें:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(f"Claude says: {response.choices[0].message.content}")संचालित द्वारा

आउटपुट:

Claude says: Recursion is a programming technique where a function calls itself to solve a problem by breaking it down into smaller, similar subproblems until it reaches a base case that stops the repetition.संचालित द्वारा

Claude 4 विस्तृत कॉन्टेक्स्ट विंडो और बेहतर रीज़निंग प्रदान करता है, जो जटिल कोड विश्लेषण के लिए इसे खास तौर पर मज़बूत बनाता है। सभी उपलब्ध मॉडल उसी provider/model-name पैटर्न का पालन करते हैं:

# OpenAI GPT-4o
model = "openai/gpt-4o"

# Anthropic Claude
model = "anthropic/claude-sonnet-4"
Wrap your API calls in error handling before moving to production:
try:
   response = client.chat.completions.create(
       model="openai/gpt-5",
       messages=[{"role": "user", "content": "Hello!"}]
   )
   print(response.choices[0].message.content)
except Exception as e:
   print(f"Error: {e}")संचालित द्वारा

यह नेटवर्क टाइमआउट, अमान्य API कुंजी, या अनुपलब्ध मॉडल जैसी स्थितियों को आपके ऐप के क्रैश हुए बिना पकड़ लेता है।

Requesty में रियल-टाइम रिस्पॉन्स के लिए स्ट्रीमिंग

जब आप लंबे उत्तर के लिए अनुरोध करते हैं, तो मॉडल हज़ारों टोकन जनरेट करता है और स्क्रीन कुछ सेकंड के लिए फ्रीज़ हो जाती है। फिर सब कुछ एक साथ आ जाता है। 

उपयोगकर्ता खाली स्क्रीन को घूरते रहते हैं, सोचते हुए कि कुछ हो भी रहा है या नहीं।

स्ट्रीमिंग इसे हल करती है—जैसे ही मॉडल टेक्स्ट जनरेट करता है, रिस्पॉन्स छोटे-छोटे हिस्सों में आता है, ताकि उपयोगकर्ता शब्दों को क्रमशः उभरते हुए देखें—बिल्कुल ChatGPT की तरह। यह खासकर लंबे उत्तरों (जैसे व्याख्या, कोड जनरेशन, या रचनात्मक लेखन) में ऐप को प्रतिक्रियाशील महसूस कराता है।

Requesty में स्ट्रीमिंग सक्षम करने के लिए stream पैरामीटर को True पर सेट करें:

response = client.chat.completions.create(
   model="openai/gpt-4o",
   messages=[
       {"role": "user", "content": "Explain recursion like I'm five years old"}
   ],
   stream=True
)

for chunk in response:
   if chunk.choices[0].delta.content is not None:
       print(chunk.choices[0].delta.content, end="", flush=True)संचालित द्वारा

रिस्पॉन्स शब्द-दर-शब्द स्ट्रीम होता है:

Okay! Imagine you have a big basket of toys, and you're trying to find your favorite teddy bear. 
But instead of looking through the whole basket all at once, you call your little sibling and say, 
"Can you look in here and find my teddy bear? If you see more baskets inside, ask someone else to help in the same way!" …संचालित द्वारा

stream=True पैरामीटर रिस्पॉन्स को एकल ऑब्जेक्ट से बदलकर एक इटेरेटर बना देता है जो हिस्सों में डाटा देता है। हर चंक में टेक्स्ट का एक भाग delta.content में होता है। end="" पैरामीटर चंक्स के बीच नई पंक्तियाँ आने से रोकता है, और flush=True बफरिंग के बजाय तुरंत डिस्प्ले को बाध्य करता है।

प्रोडक्शन ऐप्स में अक्सर स्ट्रीमिंग अनुभव के साथ-साथ लॉगिंग या विश्लेषण के लिए पूरा टेक्स्ट भी चाहिए होता है। एक हेल्पर फ़ंक्शन दोनों हैंडल करता है:

def stream_and_capture(model, messages):
   """Stream response to user while capturing complete text."""
   response = client.chat.completions.create(
       model=model,
       messages=messages,
       stream=True
   )
  
   complete_text = ""
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           text = chunk.choices[0].delta.content
           complete_text += text
           print(text, end="", flush=True)
  
   print()  # Final newline
   return complete_text

# Use it
full_response = stream_and_capture(
   "anthropic/claude-sonnet-4",
   [{"role": "user", "content": "Write a haiku about debugging code at 3 AM"}]
)

print(f"\nCaptured {len(full_response)} characters")संचालित द्वारा

आउटपुट:

Blinking cursor waits
Coffee cold, eyes burning red,
One missing bracket.

Captured 74 charactersसंचालित द्वारा

स्ट्रीमिंग हमेशा सही विकल्प नहीं होती। छोटे उत्तरों या JSON जैसे संरचित आउटपुट के लिए, साधारण अनुरोध सरल और तेज़ होते हैं—क्योंकि चंक्स प्रोसेस करने का ओवरहेड उपयोगकर्ता अनुभव के लाभ से अधिक हो सकता है।

स्ट्रीम बीच में नेटवर्क समस्याओं, रेट लिमिट, या प्रदाता आउटेज के कारण असफल हो सकती हैं। अपने स्ट्रीमिंग कोड को बुनियादी त्रुटि हैंडलिंग में लपेटें:

try:
   response = client.chat.completions.create(
       model="openai/gpt-4o",
       messages=[{"role": "user", "content": "Explain quantum entanglement in one sentence"}],
       stream=True
   )
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           print(chunk.choices[0].delta.content, end="", flush=True)
except Exception as e:
   print(f"\nError: {e}")संचालित द्वारा

यदि स्ट्रीम असफल होती है, तो आप त्रुटि पकड़ लेते हैं और मैन्युअली दोबारा प्रयास कर सकते हैं या किसी अन्य मॉडल पर फॉलबैक कर सकते हैं।

भरोसेमंदता के लिए ऑटोमैटिक फेलओवर

प्रोडक्शन ऐप्स डाउनटाइम बर्दाश्त नहीं कर सकते। पीक समय में जब OpenAI रेट लिमिट पर टकराता है, आपके उपयोगकर्ताओं को त्रुटियाँ दिखती हैं। जब Anthropic में आउटेज होता है, आपका चैटबोट काम करना बंद कर देता है। बाहरी प्रदाताओं पर निर्भर होने पर ये विफलताएँ अनिवार्य हैं।

Requesty इसे ऑटोमैटिक फेलओवर के जरिए संभालता है। जब आपका प्राइमरी मॉडल फेल होता है, Requesty 50 मिलीसेकंड से भी कम में आपके बैकअप पर स्विच कर देता है।

फेलओवर क्या है और यह क्यों ज़रूरी है

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

Requesty इस सिस्टम के जरिए 99.99% अपटाइम की गारंटी देता है। इसका मतलब प्रति माह अधिकतम लगभग 4 मिनट का डाउनटाइम—जबकि बिना बैकअप के एकल प्रदाता पर निर्भर होने पर यह घंटों भी हो सकता है।

तीन पॉलिसी प्रकार तय करते हैं कि फेलओवर कैसे काम करें:

• फॉलबैक चेन: मॉडलों को क्रम में आज़माएँ। पहला फेल हो तो दूसरा, वह भी फेल हो तो तीसरा। जब आपके पास पसंदीदा मॉडल हो लेकिन बैकअप भी चाहिए हों, यह अच्छा काम करता है।
• लोड बैलेंसिंग: ट्रैफ़िक को प्रतिशत के अनुसार कई मॉडल्स में बांटें। आप 70% GPT-5 और 30% Claude Sonnet 4 को भेज सकते हैं ताकि किसी एक प्रदाता पर लोड कम हो। जब कोई मॉडल अनुपलब्ध हो, Requesty सारा ट्रैफ़िक स्वतः काम कर रहे मॉडलों को भेज देता है।
• लेटेंसी: अनुरोधों को सबसे तेज़ रिस्पॉन्स वाले मॉडल पर रूट करें। Requesty रिस्पॉन्स समय मापता है और सबसे कम लेटेंसी विकल्प को ट्रैफ़िक भेजता है। यह लागत पर गति को प्राथमिकता देता है।

अधिकांश टीमें फॉलबैक चेन से शुरू करती हैं क्योंकि यह पूर्वानुमेय होती है। पसंदीदा मॉडल उपलब्ध हो तो वही मिलता है, और अनुपलब्ध होने पर स्वतः बैकअप काम करते हैं।

फॉलबैक चेन कॉन्फ़िगर करना

फेलओवर सेटअप Requesty डैशबोर्ड में होता है। API Keys सेक्शन में जाएँ, फिर Policies पर क्लिक करें। नई फॉलबैक चेन पॉलिसी बनाएँ। आपको एक फ़ॉर्म दिखेगा जहाँ आप पसंद के क्रम में मॉडल जोड़ते हैं।

यहाँ एक उदाहरण चेन है जो गुणवत्ता, लागत, और उपलब्धता का संतुलन बनाती है:

1. openai/gpt-5

2. anthropic/claude-sonnet-4

3. deepseek/deepseek-r1:free

यह चेन पहले GPT-5 आज़माती है क्योंकि यह तेज़ और सक्षम है। यदि यह फेल हो, तो समान गुणवत्ता के लिए Claude Sonnet 4 आज़माती है। यदि दोनों प्रीमियम मॉडल डाउन हों, तो यह DeepSeek R1 पर गिरती है, जो मुफ़्त है और लगभग हमेशा उपलब्ध रहता है।

एक बार जब आप इस पॉलिसी को सेव कर लेते हैं और अपनी API कुंजी से जोड़ते हैं, तो कोड में कोई बदलाव किए बिना फेलओवर हो जाते हैं:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[{"role": "user", "content": "Explain how DNS works"}]
)

print(f"Model used: {response.model}")
print(response.choices[0].message.content)संचालित द्वारा

response.model फ़ील्ड दिखाता है कि वास्तव में किस मॉडल ने आपका अनुरोध संभाला। डैशबोर्ड फेलओवर की आवृत्ति ट्रैक करता है ताकि आप देख सकें कि बैकअप मॉडल कब उपयोग हो रहे हैं।

आउटपुट:

Model used: gpt-5-2025-08-07
DNS (Domain Name System) translates human-readable website addresses like "google.com" into IP addresses (like 142.250.80.46) that computers use to locate and connect to servers. This translation happens through a hierarchical system of DNS servers that cache and distribute this information globally for fast lookups.संचालित द्वारा

यदि आपकी चेन के सभी मॉडल फेल होते हैं, तो Requesty प्रत्येक को आज़माने के बाद त्रुटि लौटाता है। आपको मानक API त्रुटि रिस्पॉन्स मिलेगा जो दर्शाता है कि कोई मॉडल उपलब्ध नहीं था। यह दुर्लभ है, लेकिन व्यापक आउटेज के दौरान संभव है।

फेलओवर चेन बनाते समय कुछ दिशानिर्देश अच्छे काम करते हैं:

• अलग-अलग प्रदाता उपयोग करें: यदि आप अपनी चेन में openai/gpt-5 और openai/gpt-4o रखते हैं, तो OpenAI आउटेज में दोनों डाउन हो सकते हैं। बेहतर विश्वसनीयता के लिए प्रदाताओं को मिलाएँ।
• क्रम पहले गुणवत्ता, फिर लागत के आधार पर रखें: अपना श्रेष्ठ मॉडल पहले रखें। उपलब्ध न हो तो अगले सर्वश्रेष्ठ को आज़माएँ। अंतिम फॉलबैक सबसे विश्वसनीय होना चाहिए, भले ही गुणवत्ता कम हो या वह मुफ़्त हो।
• कम से कम तीन मॉडल शामिल करें: एकल बैकअप का मतलब दो विफलता बिंदु। तीन या अधिक मॉडल बेहतर कवर देते हैं।
• अपनी चेन का परीक्षण करें: कुछ अनुरोध करें और एनालिटिक्स डैशबोर्ड देखें कि कौन से मॉडल ट्रैफ़िक संभाल रहे हैं। इससे आपकी पॉलिसी की पुष्टि होती है।

जहाँ LiteLLM में फेलओवर के लिए मैन्युअल YAML कॉन्फ़िगरेशन चाहिए, वहीं Requesty सब कुछ डैशबोर्ड पॉलिसीज़ के जरिए संभालता है।

लागत घटाने के लिए कैशिंग

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

कुछ प्रदाता स्वाभाविक रूप से प्रॉम्प्ट कैशिंग सपोर्ट करते हैं। Anthropic और Gemini आपको प्रॉम्प्ट के न बदले हुए हिस्सों को कैश करने और अनुरोधों में पुन: उपयोग करने देते हैं। जब पैटर्न दोहरते हैं, तो यह लागत काटता है—क्योंकि आप सिर्फ नए भागों के लिए पूरी कीमत देते हैं।

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

extra_body फ़ील्ड में नेस्टेड requesty ऑब्जेक्ट के साथ auto_cache पास करें:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": "You are a helpful documentation assistant. You answer questions about Python's asyncio library based on the official docs. Be concise and include code examples."},
       {"role": "user", "content": "How do I create a basic event loop?"}
   ],
   extra_body={
       "requesty": {
           "auto_cache": True
       }
   }
)

print(response.choices[0].message.content)संचालित द्वारा

सिस्टम प्रॉम्प्ट अनुरोधों में समान रहता है। auto_cache: True के साथ, Anthropic इसे पहली रिक्वेस्ट के बाद कैश कर देता है। बाद की रिक्वेस्ट वही कैश्ड प्रॉम्प्ट पुन: उपयोग करती हैं और केवल उपयोगकर्ता प्रश्न प्रोसेस होता है।

कैशिंग पैरामीटर तीन मान स्वीकार करता है:

• True: इस अनुरोध के लिए कैशिंग सक्षम करें
• False: भले ही प्रदाता सपोर्ट करे, स्पष्ट रूप से कैशिंग बाइपास करें (संवेदनशील डेटा या समय-संवेदी सामग्री के लिए, जहाँ आप सुनिश्चित करना चाहते हैं कि नई प्रोसेसिंग हो)
• इसे छोड़ दें: डिफ़ॉल्ट व्यवहार (जब तक ग्लोबली कॉन्फ़िगर न हो, कोई कैशिंग नहीं)

वर्तमान में केवल Anthropic और Gemini प्रॉम्प्ट कैशिंग सपोर्ट करते हैं। अन्य प्रदाताओं के साथ auto_cache उपयोग करना बिना त्रुटि के सामान्य प्रोसेसिंग पर शांतिपूर्वक वापस आ जाएगा।

कैशिंग का उपयोग कब करें

कैशिंग तब सबसे अच्छी तरह काम करती है जब आपके पास लंबे सिस्टम प्रॉम्प्ट हों जो अनुरोधों में समान रहें। डॉक्युमेंटेशन बॉट और कोडिंग असिस्टेंट अच्छे उदाहरण हैं। FAQ बॉट और कस्टमर सपोर्ट सिस्टम तब भी लाभान्वित होते हैं जब उपयोगकर्ता समान प्रश्न पूछते हैं। बड़े संदर्भ दस्तावेज़ों वाले नॉलेज बेस—जो अक्सर नहीं बदलते—एक और मज़बूत उपयोग मामला हैं।

जब हर अनुरोध को ताज़ा डेटा चाहिए, तब कैशिंग छोड़ दें। मौसम ऐप और स्टॉक कीमतें इस श्रेणी में आते हैं। प्रत्येक उपयोगकर्ता के लिए अनन्य प्रॉम्प्ट्स वाले वैयक्तिकृत अनुशंसाएँ लाभ नहीं देंगी। रियल-टाइम मॉनिटरिंग और लाइव फीड बहुत बार बदलते हैं, इसलिए कैशिंग से लाभ नहीं मिलता।

यह उदाहरण एक Python लाइब्रेरी के लिए डॉक्युमेंटेशन चैटबॉट दिखाता है। सिस्टम प्रॉम्प्ट में पूरा API संदर्भ शामिल है। उपयोगकर्ता अलग प्रश्न पूछते हैं, लेकिन सिस्टम प्रॉम्प्ट समान रहता है:

# Simulate a long API documentation string
long_api_documentation = """
Python AsyncIO Library Reference:
- asyncio.run(): Execute async functions
- asyncio.create_task(): Schedule coroutines
- asyncio.gather(): Run multiple tasks
... (this continues for 5,000+ tokens)
"""

# First request - cache miss, pays full price
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "How do I authenticate?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 5,247 (full processing)संचालित द्वारा

समान सिस्टम प्रॉम्प्ट वाली दूसरी रिक्वेस्ट कैश को हिट करती है:

# Second request - cache hit, reduced cost
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "What are rate limits?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 312 (only new content processed, 5,000 tokens served from cache)संचालित द्वारा

कैश रीड फीस कैश्ड हिस्सों पर खर्च 50 से 90% तक घटा देती है।

Requesty डैशबोर्ड के Analytics सेक्शन में अपना कैश हिट रेट जाँचें। यदि यह 40% से कम है, तो आपके प्रॉम्प्ट बहुत बार बदल रहे हैं, इसलिए कैशिंग का लाभ कम होगा. 

ऐसे पैटर्न ढूँढें जहाँ आप सिस्टम प्रॉम्प्ट मानकीकृत कर सकें या वैरिएबल सामग्री को यूज़र मैसेज में निकाल सकें। डैशबोर्ड प्रदाता और मॉडल के अनुसार कैशिंग से हुई कुल बचत भी दिखाता है, ताकि आपको पता चले कि आपके अनुकूलन प्रयास कहाँ फल दे रहे हैं।

Requesty लागत ट्रैकिंग और एनालिटिक्स

अभी आपका डैशबोर्ड लगभग खाली है। आपने कुछ टेस्ट रिक्वेस्ट की हैं, शायद $0.10 खर्च हुआ है। अभी विश्लेषण करने को बहुत कुछ नहीं। यह सेक्शन बताता है कि अभी क्या सेट करना है और प्रोडक्शन में जाने पर क्या उपयोगी हो जाता है।

स्पेंडिंग लिमिट सेट करना परीक्षण के लिए भी अच्छी प्रैक्टिस है। अपने डैशबोर्ड में API Keys सेक्शन पर जाएँ, अपनी कुंजी पर क्लिक करें, और “API Limits” ढूँढें। $5 मासिक बजट थ्रेशोल्ड सेट करें। Requesty आपको उस सीमा के 50%, 75%, और 90% पर अलर्ट करेगा। कड़ी सुरक्षा के लिए, एक उपयोग सीमा सेट करें जो सीमा छूने पर सभी अनुरोधों को रोक दे। यह परीक्षण के दौरान दुर्घटनाओं को रोकता है और प्रोडक्शन में आपकी सुरक्षा करता है।

जैसे-जैसे आपका उपयोग बढ़ता है, Requesty पाँच प्रमुख मेट्रिक्स ट्रैक करता है:

• टोकन उपयोग: हर अनुरोध में कितने टोकन खपत हुए
• लागत ट्रैकिंग: प्रति मॉडल और प्रदाता सटीक खर्च
• लेटेंसी मेट्रिक्स: P50, P95, P99 रिस्पॉन्स समय
• कैश प्रदर्शन: हिट रेट जो लागत बचत दिखाएँ
• फेलओवर आवृत्ति: बैकअप मॉडल कितनी बार उपयोग हुए

कुछ हफ्तों के प्रोडक्शन ट्रैफ़िक के बाद ये मेट्रिक्स ऐसे पैटर्न दिखाते हैं जो अनुकूलन में मदद करते हैं। डैशबोर्ड का उपयोग करके महंगे वर्कफ़्लोज़ ढूँढें और सस्ते मॉडलों पर स्विच करें, दोहराए जाने वाली क्वेरी पहचानें और auto_cache: true के साथ कैशिंग सक्षम करें, और फेलओवर पैटर्न मॉनिटर करके अपनी फॉलबैक चेन समायोजित करें। एक डॉक्युमेंटेशन चैटबॉट ने, डैशबोर्ड में 70% समान क्वेरी दिखने के बाद, कैशिंग सक्षम करके लागत $500 से $200 प्रति माह कर ली।

जैसे-जैसे आप प्रोटोटाइप से प्रोडक्शन की ओर बढ़ते हैं, मॉनिटरिंग, स्केलिंग, और ऑपरेशनल सर्वोत्तम प्रथाएँ अहम हो जाती हैं। LLMOps पूरा जीवनचक्र कवर करता है—प्रोडक्शन वातावरण में बड़े भाषा मॉडलों के प्रबंधन का—जिसमें Requesty के बिल्ट-इन एनालिटिक्स के पूरक लागत अनुकूलन स्ट्रैटेजीस भी शामिल हैं।

निष्कर्ष

आपने सीखा कि Requesty एकल API के जरिए 300+ AI मॉडलों के लिए यूनिफाइड गेटवे के रूप में कैसे काम करता है। सेटअप सरल है: OpenAI SDK इंस्टॉल करें, उसे Requesty के बेस URL की ओर इंगित करें, और आप कनेक्टेड हैं। इसके बाद, स्ट्रीमिंग प्रोग्रेसिव रिस्पॉन्स देती है, फेलओवर चेन प्रदाता फेल होने पर भी अपटाइम की गारंटी देती हैं, और बार-बार आने वाले प्रॉम्प्ट्स को संभालते समय कैशिंग आपकी लागत को आधा कर सकती है।

Requesty, LiteLLM, और OpenRouter के बीच चुनाव आपकी प्राथमिकताओं पर निर्भर है। यदि आपको ऑटोमैटिक फेलओवर और बिल्ट-इन एनालिटिक्स के साथ मैनेज्ड इन्फ्रास्ट्रक्चर चाहिए, तो Requesty आपके लिए जटिलता संभालता है। जो टीमें सेल्फ-होस्टिंग में सहज हैं और सूक्ष्म नियंत्रण चाहती हैं, वे LiteLLM के ओपन-सोर्स दृष्टिकोण का उपयोग कर सकती हैं। OpenRouter बुनियादी यूनिफाइड एक्सेस प्रदान करता है—जब आप मैन्युअल मॉडल चयन में सहज हों और उन्नत रूटिंग नीतियों की आवश्यकता न हो।

तीन अलग-अलग प्रदाताओं के मॉडलों के साथ एक फॉलबैक चेन कॉन्फ़िगर करने से शुरू करें, फिर दोहराए जाने वाले सिस्टम प्रॉम्प्ट्स वाली रिक्वेस्ट पर कैशिंग सक्षम करें। और उन्नत उपयोग मामलों के लिए, Claude Sonnet 4 की रीज़निंग क्षमताएँ एक्सप्लोर करें या प्रोडक्शन डिप्लॉयमेंट के लिए LLMOps प्रैक्टिसेस लागू करें।