हमने एक महीने तक गेटवे लेटेंसी (Gateway Latency) पर गहरा शोध किया

मैंने एक महीने तक LLM गेटवे ओवरहेड को मापने में बिताया। मैंने प्रॉक्सी लेटेंसी को माइक्रोसेकंड तक ट्रैक किया। मैंने प्रति सेकंड 500, 1000 और 5000 अनुरोधों (requests) पर लोड टेस्ट चलाए।

फिर एक टीम के साथी ने पूछा: "कुल अनुरोध समय (total request time) का कितना प्रतिशत गेटवे का है?"

मैंने क्वेरी चलाई। उत्तर था 0.3%।

वर्तमान में LLM API कॉल्स में लेटेंसी की लागत कुछ इस प्रकार है:

• GPT-4o: 850ms TTFT | 2-8s कुल • Claude Sonnet 4: 900ms TTFT | 3-15s कुल • Claude Fable 5: 147s TTFT | 155s कुल • GPT-4.1: 1,100ms TTFT | 3-12s कुल • Gemini 2.5 Flash: 500ms TTFT | 1-5s कुल

अब देखें कि गेटवे कितना अतिरिक्त समय जोड़ते हैं:

• डायरेक्ट API कॉल: 0ms • Python प्रॉक्सी: 8-40ms • Go/Rust प्रॉक्सी: 1-11ms

बहस इस बात पर है कि क्या आप उस कॉल में 8ms या 1ms जोड़ रहे हैं जिसमें 3,000ms से 155,000ms तक का समय लगता है। यह सैटेलाइट से फाइल डाउनलोड होने के दौरान एक तेज़ USB केबल के बारे में बहस करने जैसा है।

कुछ बेंचमार्क "50x तेज़ लेटेंसी" का दावा करते हैं। ये टेस्ट अक्सर सीमित संसाधनों वाली छोटी मशीनों पर चलते हैं। प्रोडक्शन में, आप हॉरिजॉन्टल स्केलिंग (scale horizontally) करते हैं। जब आप कई इंस्टेंस का उपयोग करते हैं, तो लेटेंसी कम हो जाती है।

वास्तविक LLM कॉल में गेटवे की तुलना में 50x से 1000x अधिक समय लगता है। आपकी लेटेंसी मॉडल से आती है, प्रॉक्सी से नहीं।

यहाँ वे चीज़ें दी गई हैं जिन्होंने वास्तव में हमारे लिए बड़ा बदलाव लाया:

यदि आप एक LLM गेटवे चुनते हैं, तो इसके बजाय इन चीज़ों पर ध्यान दें:

माइक्रोसेकंड में गेटवे ओवरहेड एक मार्केटिंग हेडलाइन है। यह प्रोडक्शन की समस्या नहीं है। मैं ऐसे गेटवे को प्राथमिकता दूँगा जो 40ms जोड़ता है लेकिन मेरी लागतों को ट्रैक करता है, बजाय एक ऐसे गेटवे के जो 1ms जोड़ता है लेकिन मुझे अंधेरे में रखता है।

आपकी सबसे बड़ी LLM इंफ्रास्ट्रक्चर संबंधी समस्या (pain point) क्या है?

स्रोत: https://dev.to/paultwist/we-obsessed-over-gateway-latency-for-a-month-then-we-looked-at-the-actual-numbers-1kgk

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi