पहले निष्कर्ष बता दें: फ्रंटएंड में शब्द-दर-शब्द रेंडरिंग की रुकावट, नब्बे प्रतिशत मामलों में नेटवर्क की समस्या नहीं होती, बल्कि मॉडल गेटवे लेयर में SSE प्रोटोकॉल का सामान्यीकरण (normalization) न होना होता है, और विभिन्न बड़े मॉडलों की स्ट्रीमिंग चंकिंग रणनीतियाँ सीधे ब्राउज़र तक पहुँच जाती हैं। यह समस्या हमने एक इंटेलिजेंट कस्टमर सर्विस प्रोजेक्ट में झेली है, और लगातार तीन दिन तक जाँच-पड़ताल की।
सरल शब्दों में, SSE (Server-Sent Events) वह तंत्र है जिसमें सर्वर एक साथ डेटा उत्पन्न करता है और क्लाइंट की ओर धकेलता है। बड़े मॉडल API द्वारा लौटाया गया स्ट्रीमिंग डेटा मूल रूप से SSE इवेंट्स की एक श्रृंखला होता है। समस्या यह है कि विभिन्न विक्रेताओं की "कब धकेलना है, कितना बड़ा टुकड़ा धकेलना है" की परिभाषा पूरी तरह से अलग है। GPT-4o API Token के आधार पर बैच में धकेलने की प्रवृत्ति रखता है, एक बार में कुछ Token निकालता है; Claude API में पहले Token से पहले एक मौन अवधि होती है, जो लंबी होने पर दो-तीन सेकंड तक पहुँच सकती है; Qwen API और DeepSeek API की चंकिंग ग्रैन्युलैरिटी भी एक-दूसरे से भिन्न है। यदि फ्रंटएंड सीधे इन कच्चे फ़ॉर्मेट का उपभोग करता है, तो रेंडरिंग की लय स्वाभाविक रूप से कभी तेज़ कभी धीमी हो जाएगी।
जाँच का पहला कदम: पहले नेटवर्क लेयर को बाहर करें
हमें शुरू में संदेह था कि लिंक में उतार-चढ़ाव है, दो दिन तक TCP राउंड-ट्रिप विलंब और पैकेट लॉस दर को कैप्चर किया, डेटा बिल्कुल साफ़ था। curl से सीधे एक मॉडल से कनेक्ट किया, प्रतिक्रिया के टाइमस्टैम्प प्रिंट किए, पता चला कि एक ही उत्तर में, पहले तीन इवेंट्स का अंतराल 800 मिलीसेकंड था, और बाद में अचानक हर 20 मिलीसेकंड में एक हो गया। यह नेटवर्क से समझाया नहीं जा सकता, यह सर्वर की पुश रणनीति का ही असमान होना है।
जाँच का दूसरा कदम: SSE चंकिंग रणनीति के अंतर का पता लगाना
पाँच मॉडलों की कच्ची स्ट्रीम कैप्चर करके तुलना की, अंतर बहुत स्पष्ट था। कैरेक्टर के आधार पर धकेलने वाले मॉडल, एक चीनी अक्षर एक इवेंट, इवेंट्स की संख्या विस्फोटक रूप से बढ़ जाती है; Token बैच में धकेलने वाले मॉडल, एक बार में चार-पाँच Token जमा करके ही भेजते हैं; कुछ मॉडलों में पहले Token से पहले लंबी मौन अवधि होती है, फ्रंटएंड को कोई डेटा नहीं मिलता, उपयोगकर्ता कर्सर को स्थिर देखता है और सोचता है कि अटक गया है। तीनों रणनीतियाँ एक ही कस्टमर सर्विस सिस्टम में मिली-जुली हों, तो फ्रंटएंड के लिए एक समान लय में रेंडर करना असंभव है।
जाँच का तीसरा कदम: गेटवे लेयर में प्रोटोकॉल अनुवाद की कमी
मूल कारण यहीं है। हमारा मॉडल गेटवे उस समय केवल अनुरोध अग्रेषण (forwarding) और API Key प्रबंधन करता था, प्रतिक्रिया पक्ष पर प्रोटोकॉल का सामान्यीकरण नहीं करता था, विभिन्न मॉडलों का कच्चा SSE फ़ॉर्मेट सीधे फ्रंटएंड तक पहुँच जाता था। यह ऐसा है जैसे पाँच अलग-अलग बोलियाँ बोलने वाले लोग एक साथ आपको रिपोर्ट कर रहे हों, आप अनुवाद नहीं करते, तो सुनने वाला स्वाभाविक रूप से भ्रमित होगा।
बाद में हमने token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म को एकीकृत आउटलेट के रूप में जोड़ा, इसके OpenAI-संगत इंटरफ़ेस ने प्रोटोकॉल सामान्यीकरण पर तीन काम किए, जिन्हें विस्तार से बताना उचित है।
पहला, SSE इवेंट फ़ॉर्मेट का एकीकरण। नीचे चाहे किसी भी मॉडल को कॉल किया जाए, आउटलेट हमेशा मानक OpenAI फ़ॉर्मेट में होता है: data: {...} और अंत में data: [DONE]। फ्रंटएंड केवल एक प्रोटोकॉल पहचानता है, हर मॉडल के लिए अलग पार्सिंग लॉजिक लिखने की ज़रूरत नहीं। बहु-मॉडल एकीकृत एक्सेस का मूल्य, एक बड़ा हिस्सा यहीं प्रकट होता है।
दूसरा, पहले Token के टाइमआउट के लिए बैकअप। गेटवे पक्ष पर पहले Token की प्रतीक्षा के लिए एक थ्रेशोल्ड सेट है, थ्रेशोल्ड पार होने पर पहले एक हार्टबीट इवेंट धकेला जाता है, ताकि फ्रंटएंड लंबे समय तक खाली न रहे। यह क्रिया बहुत छोटी है, लेकिन कस्टमर सर्विस परिदृश्य में उपयोगकर्ता की अनुभूति में बहुत अंतर आता है।
तीसरा, चंकिंग बफ़र रणनीति। कैरेक्टर के आधार पर धकेलने वाले मॉडलों के लिए बैचिंग, बैच में धकेलने वाले मॉडलों के लिए फ़्रेम विभाजन, इवेंट के अंतराल को यथासंभव एक स्थिर सीमा में समतल करना। वास्तविक परीक्षण में, फ्रंटएंड की शब्द-दर-शब्द रेंडरिंग की लय स्पष्ट रूप से एकरूप हो गई, अब रुक-रुक कर होने की स्थिति नहीं आती।
यहाँ एक डेटा तुलना जोड़ें: सुधार से पहले, फ्रंटएंड को पाँच मॉडलों की कच्ची स्ट्रीम का उपभोग करने के लिए पाँच सेट SSE पार्सिंग शाखाओं को बनाए रखना पड़ता था, कोड की मात्रा लगभग 400 पंक्तियाँ थी। सुधार के बाद token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म के OpenAI-संगत इंटरफ़ेस से जुड़े, पार्सिंग शाखाएँ एक सेट में सिमट गईं, कोड लगभग 80 पंक्तियों तक कम हो गया। रखरखाव लागत लगभग अस्सी प्रतिशत कम हुई।
गड्ढों से बचने की चेतावनी: गेटवे लेयर पर केवल अग्रेषण न करें, प्रतिक्रिया पक्ष पर प्रोसेसिंग भी करें। कई टीमें सोचती हैं कि base_url बदल देना ही काफी है, नतीजा यह होता है कि स्ट्रीमिंग अनुभव के सारे गड्ढे फ्रंटएंड में रह जाते हैं। प्रोटोकॉल सामान्यीकरण अनिवार्य रूप से गेटवे में होना चाहिए, क्लाइंट के बैकअप पर निर्भर नहीं रह सकते।
शुरुआत में उल्लिखित उस कस्टमर सर्विस सिस्टम पर वापस आते हैं, समस्या हल होने के बाद हमने एक और राउंड प्रेशर टेस्ट किया। token8341 बड़े मॉडल API एग्रीगेशन प्लेटफ़ॉर्म एक ही Key से GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao आदि प्रमुख मॉडलों को कॉल करने का समर्थन करता है, मॉडल बदलते समय फ्रंटएंड कोड में शून्य बदलाव, यह मॉडल रूटिंग और A/B टेस्टिंग करने वाली टीमों के लिए काफी सुविधाजनक है। उपभोग-आधारित बिलिंग मोड में, हमने बिल की तुलना की, लागत प्रत्येक को सीधे कनेक्ट करने से कुछ कम है।
यदि आप भी AI API एग्रीगेशन या स्व-निर्मित मॉडल गेटवे बना रहे हैं, तो सलाह है कि SSE सामान्यीकरण को प्राथमिकता वाली आवश्यकता के रूप में डिज़ाइन करें, न कि फ्रंटएंड के अटकने के बाद वापस आकर इसे पूरा करें।
लेखक: झाओ चिमिंग
प्रकाशन तिथि: 29 अक्टूबर 2026