बैकएंड और AI एप्लिकेशन डेवलपमेंट करने वाले साथियों, लगभग सभी ने इस पल का अनुभव किया होगा: महीने के अंत में क्लाउड बिल खोलते ही पता चलता है कि बड़े मॉडल API का खर्च बजट से 3 गुना है। न हमला हुआ, न व्यवसाय में अचानक उछाल आया, बस ऑनलाइन चल रही कन्वर्सेशन सर्विस चुपचाप पैसा जला रही है। यह लेख इंजीनियरिंग दृष्टिकोण से बताता है कि पैसा आखिर कहाँ से लीक हो रहा है, और तकनीकी उपायों से इसे कैसे रोका जाए।
जाल एक: कॉन्टेक्स्ट विंडो का अनियंत्रित विस्तार
मल्टी-टर्न कन्वर्सेशन में सबसे अधिक नज़रअंदाज़ होने वाला लागत स्रोत है पूरे इतिहास संदेशों का पूर्ण रूप से वापस भेजना। मान लीजिए एक कस्टमर सर्विस परिदृश्य, प्रत्येक टर्न में औसतन 800 token कॉन्टेक्स्ट, उपयोगकर्ता 20वें टर्न तक बात कर लेता है, तो एक बार के अनुरोध का इनपुट लगभग 16000 token हो जाता है। GPT-4o इनपुट $2.5/1M token के हिसाब से, एक अनुरोध की इनपुट लागत लगभग $0.04, दिन में 50,000 कॉल तो $2000। असली परेशानी यह है कि इन 16000 token में शायद 70% तीन टर्न पहले की अप्रासंगिक बातचीत है।
अनुकूलन का तरीका है स्लाइडिंग विंडो + सारांश संपीड़न। हाल के N टर्न का मूल पाठ रखें, पुरानी बातचीत को हल्के मॉडल से 200 token के भीतर सारांश में बदलें। हमारे प्रोजेक्ट में विंडो को "पूर्ण" से "हाल के 6 टर्न + सारांश" में बदलने पर, एक बार का इनपुट token 12000 से घटकर लगभग 3500 हो गया, इनपुट लागत सीधे सत्तर प्रतिशत कट गई। ध्यान रखें कि सारांश भी सस्ते मॉडल से बनवाना चाहिए, फ्लैगशिप मॉडल से सारांश बनाना तो बचत न करने के बराबर है।
जाल दो: फ्लैगशिप मॉडल से मोटा काम करवाना
यह सबसे आम और सबसे बेकार बर्बादी है। इंटेंट क्लासिफिकेशन, सेंटिमेंट जजमेंट, कंटेंट सारांश, फॉर्मेट कन्वर्ज़न, ये काम DeepSeek-V3 या Qwen-Max से 95% से अधिक सटीकता के साथ हो सकते हैं, लेकिन कई टीमें सुविधा के लिए सब कुछ Claude 4 Sonnet या GPT-4o से करवाती हैं। कीमत का अंतर कितना? फ्लैगशिप मॉडल की इनपुट कीमत अक्सर हल्के मॉडल से 10 से 20 गुना होती है।
मॉडल स्तरीय कॉलिंग का मूल है रूटिंग। काम आते ही स्वचालित रूप से जटिलता का आकलन हो, वर्गीकरण हल्के मॉडल से, जटिल तर्क ही फ्लैगशिप पर। SiCore TokenWorks कार्य के अनुसार स्वचालित रूप से इष्टतम मॉडल चुनने का समर्थन करता है, हमारे प्रोजेक्ट में उपयोग करने पर, वर्गीकरण कार्यों को हल्के मॉडल पर स्थानांतरित करने के बाद लागत स्पष्ट रूप से घटी। ऐसे AI API एग्रीगेशन प्लेटफ़ॉर्म का मूल्य यही है कि आपको प्रत्येक मॉडल के लिए अलग SDK और Key बनाए रखने की ज़रूरत नहीं, एक OpenAI-संगत इंटरफ़ेस से स्विच कर सकते हैं। नीचे न्यूनतम बदलाव का उदाहरण है:
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # एक लाइन बदलें, OpenAI SDK से संगत
)
# हल्के कार्य सस्ते मॉडल से
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "इस समीक्षा की भावना का निर्धारण करें: लॉजिस्टिक्स बहुत तेज़ था लेकिन पैकेजिंग क्षतिग्रस्त थी"}],
max_tokens=16
)
print(resp.choices[0].message.content)रूटिंग रणनीति में पहले नियम अपनाएँ: कार्य प्रकार को टैग करें, वर्गीकरण/सारांश/निष्कर्षण हल्के मॉडल से, कोड जनरेशन/जटिल तर्क फ्लैगशिप से। कुछ समय चलाने के बाद प्रत्येक मॉडल की वास्तविक हिट दर के आँकड़े लेकर समायोजित करें, शुरुआत में ही जटिल सिमेंटिक रूटिंग न अपनाएँ, रखरखाव लागत बचत से अधिक हो सकती है।
जाल तीन: रीट्राई तंत्र का अनियंत्रित होना
टाइमआउट रीट्राई एक अदृश्य एम्प्लीफायर है। कई SDK डिफ़ॉल्ट रूप से 2 से 3 बार रीट्राई करते हैं, अगर टाइमआउट थ्रेशोल्ड बहुत छोटा सेट हो (जैसे 10 सेकंड), जबकि वास्तविक P99 विलंबता 25 सेकंड है, तो बहुत सारे अनुरोध टाइमआउट के बाद रीट्राई होंगे, एक कॉल तीन हो जाएगी। और बुरा यह है कि रीट्राई अनुरोध स्वयं भी समवर्तीता घेरते हैं, रेट लिमिट ट्रिगर हो सकती है, रेट लिमिट फिर रीट्राई ट्रिगर करती है, हिमस्खलन बन जाता है।
हमने एक बार यह भोगा: किसी इंटरफ़ेस की P99 विलंबता 28 सेकंड, टाइमआउट 15 सेकंड, रीट्राई 3 बार, वास्तविक कॉल वॉल्यूम व्यवसाय का 2.4 गुना था। बाद में टाइमआउट थ्रेशोल्ड P99 से 30% ऊपर सेट किया, रीट्राई को एक्सपोनेंशियल बैकऑफ़ और अधिकतम 1 बार किया, कॉल वॉल्यूम 1.1 गुना पर आ गया। साथ ही रीट्राई में त्रुटि प्रकार का अंतर करें, 429 और 5xx पर ही रीट्राई करें, 400 पैरामीटर त्रुटि पर दस हज़ार बार रीट्राई करने से भी कुछ नहीं होगा।
जाल चार: उपयोग एकत्रीकरण और अलर्ट का अभाव
यह सबसे मूलभूत समस्या है। कई टीमें प्रोजेक्ट या Key के अनुसार मोटे तौर पर आँकड़े रखती हैं, लेकिन यह नहीं जानती कि विशेष रूप से कौन सी सुविधा, कौन सा उपयोगकर्ता, कौन सा Prompt पैसा जला रहा है। बिल आने पर ही पता चलता है कि किसी टेस्ट एनवायरनमेंट की Key बंद नहीं हुई थी, या किसी उपयोगकर्ता के अति-लंबे सत्र ने बजट खा लिया।
तरीका है आयाम के अनुसार टैगिंग: प्रत्येक कॉल में team, feature, user_id तीन टैग लगाएँ, लॉग या टाइम-सीरीज़ डेटाबेस में डालें। AI API गेटवे को एकीकृत प्रवेश द्वार बनाने का लाभ यही है, सभी कॉल एक प्रॉक्सी परत से गुज़रती हैं, टैग और उपयोग एकत्रीकरण गेटवे पक्ष पर पूरा होता है, प्रत्येक व्यवसाय पक्ष के कोड बदलने की ज़रूरत नहीं। अलर्ट थ्रेशोल्ड दो स्तरों में सेट करने की सलाह है, दैनिक उपयोग बजट के 60% पर चेतावनी, 85% पर डिग्रेडेशन ट्रिगर (जैसे स्वचालित रूप से गैर-मुख्य सुविधाओं को हल्के मॉडल पर स्थानांतरित करना)।
लागत तुलना और चयन संदर्भ
उपरोक्त चारों बिंदुओं को लागू करने के बाद, हमने तीन प्रकार के एक्सेस तरीकों की तुलना की: आधिकारिक सीधा कनेक्शन एकल मॉडल, स्व-निर्मित रूटिंग, एग्रीगेशन प्लेटफ़ॉर्म। आधिकारिक सीधा कनेक्शन सबसे सरल है लेकिन मॉडल स्तरीकरण संभव नहीं, लागत कठोर; स्व-निर्मित रूटिंग लचीली है लेकिन कई Key, कई SDK, कई बिलिंग लॉजिक बनाए रखने पड़ते हैं, कम से कम दो व्यक्ति-महीने; एग्रीगेशन प्लेटफ़ॉर्म में मॉडल स्विचिंग और उपयोग एकत्रीकरण की तैयार क्षमता है, उपयोग के अनुसार बिलिंग, लागत बेहतर। चयन करते समय तीन बातों पर ध्यान दें: OpenAI SDK से संगतता (माइग्रेशन लागत), घरेलू मॉडलों की पूर्ण कवरेज का समर्थन (अनुपालन और लागत), उपयोग एकत्रीकरण इंटरफ़ेस की उपलब्धता (अवलोकनीयता)।
लागत अनुकूलन एक बार का काम नहीं, निरंतर अवलोकन और समायोजन की प्रक्रिया है। पहले उपयोग एकत्रीकरण शुरू करें, स्पष्ट देखें कि पैसा कहाँ खर्च हो रहा है, फिर एक-एक करके कॉन्टेक्स्ट, मॉडल स्तरीकरण, रीट्राई रणनीति का अनुकूलन करें। क्रम न बदलें, अन्यथा आप आधा दिन अनुकूलन करते रहेंगे, और जिसका अनुकूलन कर रहे हैं वह शायद मुख्य हिस्सा ही नहीं है।
लेखक: चेन जिंगशिंग
प्रकाशन तिथि: 3 अक्टूबर 2026