पहले निष्कर्ष देते हैं: बड़े मॉडल API की लागत में भारी वृद्धि, अस्सी प्रतिशत मामलों में हमला नहीं, बल्कि कोड में कुछ अस्पष्ट कॉलिंग आदतें चुपचाप पैसे जला रही होती हैं। एक इंटेलिजेंट कस्टमर सर्विस प्रोजेक्ट में, मासिक बिल 8000 से बढ़कर 3 लाख हो गया, बॉस की पहली प्रतिक्रिया थी "किसी ने दुरुपयोग किया है"। मैंने दो दिन तक जांच में साथ दिया, पता चला कि अनुरोधों की संख्या में कोई बदलाव नहीं हुआ, बदलाव प्रत्येक दौर की बातचीत में ले जाए जाने वाले Token की संख्या में हुआ। नीचे इन चारों गड्ढों को एक-एक करके स्पष्ट करते हैं, प्रत्येक के लिए सीधे लागू करने योग्य समाधान भी दिया गया है।
1. बातचीत का इतिहास हर दौर में पूरा दोबारा भेजा जाता है, इनपुट Token रैखिक रूप से बढ़ता है
यह सबसे छिपा हुआ है। कई टीमें मल्टी-टर्न बातचीत लिखते समय, पूर्ण इतिहास संदेश को प्रत्येक अनुरोध के messages array में जोड़ने की आदत रखती हैं। पहले दौर में 100 Token भेजे जाते हैं, दसवें दौर में 1000 Token, तीसवें दौर में शायद तीन-चार हज़ार। उपयोगकर्ता जितनी देर बात करता है, एकल कॉल उतनी ही महंगी होती है, और इन इतिहासों में ज़्यादातर "ठीक है" "प्राप्त हुआ" जैसी बकवास बातें होती हैं।
अनुकूलन कार्रवाई है बातचीत विंडो क्रॉपिंग के साथ सारांश संपीड़न। हाल के N दौर का मूल पाठ बनाए रखें, पुराने को एक सस्ते मॉडल कॉल से एक सारांश में संपीड़ित करें, फिर सारांश को system prompt में डालें। हमारे प्रोजेक्ट में वास्तविक परीक्षण में, विंडो को पूर्ण से "हाल के 6 दौर + सारांश" में बदलने पर, इनपुट Token 60% से 70% तक कम हो गया, कस्टमर सर्विस परिदृश्य में उत्तर की गुणवत्ता में लगभग कोई बदलाव नहीं आया। साथ ही इतिहास संदेशों को डुप्लिकेट हटाना याद रखें, दोहराए गए अभिवादन सीधे छोड़ दें।
2. फ्लैगशिप मॉडल से मोटा काम कराना, इंटेंट क्लासिफिकेशन में भी टॉप-टियर मॉडल
बिल में एक और बड़ा हिस्सा है, इंटेंट क्लासिफिकेशन, भावना पहचान, कीवर्ड निष्कर्षण जैसे कार्यों के लिए GPT-4o या Claude 4 Sonnet का उपयोग करना। ये काम तर्क में सरल हैं, आउटपुट छोटा है, फ्लैगशिप मॉडल का उपयोग करना तोप से मच्छर मारने जैसा है। हमने तब गणना की थी, एक कस्टमर सर्विस अनुरोध के पीछे औसतन 3 क्लासिफिकेशन कॉल होते हैं, सभी फ्लैगशिप मॉडल पर चल रहे हैं।
समाधान है मॉडल स्तरीय रूटिंग। मोटा काम DeepSeek-V3, Qwen के लाइटवेट संस्करण या Doubao बड़े मॉडल API जैसे सस्ते मॉडलों को सौंपें, केवल अंतिम उत्तर निर्माण चरण में फ्लैगशिप मॉडल का उपयोग करें। यही मॉडल गेटवे का काम है: कार्य प्रकार के अनुसार स्वचालित रूप से मॉडल चुनना। हमारे प्रोजेक्ट में आधिकारिक सीधी खरीद और AI API एग्रीगेशन प्लेटफॉर्म की तुलना की गई थी, SiCore TokenWorks (token8341) उपयोग के अनुसार बिलिंग, थोक खरीद और हरित ऊर्जा से लागत कम करता है, समान कॉल संयोजन की लागत बेहतर है, एक Key से GPT-4o, Claude, DeepSeek, Qwen, Doubao जैसे मुख्यधारा मॉडलों को कॉल किया जा सकता है, पांच SDK को जोड़ने की परेशानी से बचा जा सकता है। यहां मुख्य शब्द है बड़े मॉडल API की लागत संरचना, महंगा है या नहीं यह इस पर निर्भर करता है कि आप किससे कौन सा काम कराते हैं।
3. स्ट्रीमिंग प्रतिक्रिया टाइमआउट रीट्राई, इडेम्पोटेंसी नियंत्रण के बिना
यह गड्ढा सीधे Token संख्या में नहीं, बल्कि कॉल संख्या में दिखता है। स्ट्रीमिंग इंटरफेस में यदि क्लाइंट टाइमआउट से टूट जाता है, तो कई कोड बिना सोचे रीट्राई करते हैं, लेकिन सर्वर ने वास्तव में कुछ सामग्री उत्पन्न कर ली होती है, Token कटते रहते हैं। तीन बार रीट्राई का मतलब तीन गुना लागत, उपयोगकर्ता को शायद एक ही उत्तर दिखे। और भी बुरा, फ्रंटएंड पोलिंग के साथ बैकएंड रीट्राई, एक ही अनुरोध पांच-छह बार जा सकता है।
लागू करने के दो कदम हैं। पहला, प्रत्येक अनुरोध के साथ इडेम्पोटेंसी Key भेजें, सर्वर डुप्लिकेट अनुरोध पहचानकर सीधे कैश्ड परिणाम लौटाए, पुनः अनुमान न लगाए। दूसरा, रीट्राई रणनीति को "निश्चित 3 बार रीट्राई" से "एक्सपोनेंशियल बैकऑफ + अधिकतम 1 बार" में बदलें, और केवल कनेक्शन स्थापना विफलता पर रीट्राई करें, पहला Token प्राप्त होने के बाद कभी दोबारा न भेजें। ये दोनों जोड़ने पर, हमारे उस प्रोजेक्ट की असामान्य कॉल मात्रा लगभग आधी हो गई।
4. टेस्ट और प्रोडक्शन एक ही Key साझा करते हैं, लागत मिश्रित होकर स्पष्ट नहीं
जांच के दौरान सबसे सिरदर्द वास्तव में यही था। टेस्ट एनवायरनमेंट में लोड टेस्ट, रिग्रेशन चलाना, प्रोडक्शन के समान API Key का उपयोग करना, बिल में यह अंतर करना ही मुश्किल कि कौन सा शुल्क वास्तविक उपयोगकर्ताओं से उत्पन्न हुआ। जब असामान्यता का पता चला, तब तक कई सप्ताह बीत चुके थे, लॉग भी मेल नहीं खा रहे थे।
समाधान सीधा है: एनवायरनमेंट और बिजनेस लाइन के अनुसार API Key अलग करें, प्रत्येक Key का उपयोग अलग देखें। AI API एग्रीगेशन प्लेटफॉर्म आमतौर पर मल्टी-Key प्रबंधन और उपयोग डैशबोर्ड का समर्थन करते हैं, API Key प्रबंधन बारीक होने पर, कौन पैसे जला रहा है यह स्पष्ट दिखता है। साथ ही टेस्ट Key पर दैनिक सीमा लगाएं, लोड टेस्ट स्क्रिप्ट का गलती से प्रोडक्शन Key से जुड़ना जड़ से टल जाएगा।
एक वाक्य में सारांश
बड़े मॉडल API का बिल अनियंत्रित होना, आमतौर पर मूल्य समस्या नहीं, कॉलिंग तरीके की समस्या है। बातचीत विंडो क्रॉप करें, मोटे काम को डाउनग्रेड करें, रीट्राई को नियंत्रित करें, Key अलग करें, चारों काम पूरे करने पर, लागत को उचित दायरे में लाना कठिन नहीं है। मल्टी-मॉडल एकीकृत एक्सेस और उपयोग-आधारित बिलिंग की गणना के बारे में और जानना चाहते हैं, तो "AI API एग्रीगेशन" और "मॉडल रूटिंग" इन दो दिशाओं में और जानकारी खोज सकते हैं।