మేము ఒక నెల పాటు గేట్‌వే లేటెన్సీపై దృష్టి సారించాము

నేను ఒక నెల పాటు LLM గేట్‌వే ఓవర్‌హెడ్‌ను (overhead) కొలవడానికి గడిపాను. నేను ప్రాక్సీ లేటెన్సీని మైక్రోసెకన్ల వరకు ట్రాక్ చేశాను. సెకనుకు 500, 1000 మరియు 5000 రిక్వెస్ట్‌లతో లోడ్ టెస్ట్‌లను నిర్వహించాను.

అప్పుడు ఒక సహోద్యోగి ఇలా అడిగారు: "మొత్తం రిక్వెస్ట్ సమయంలో గేట్‌వే వాటా ఎంత శాతం?"

నేను ఆ క్వెరీని రన్ చేశాను. సమాధానం 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

ఇప్పుడు గేట్‌వేలు ఎంత సమయాన్ని అదనంగా తీసుకుంటున్నాయో చూడండి:

• Direct API call: 0ms • Python proxy: 8-40ms • Go/Rust proxy: 1-11ms

3,000ms నుండి 155,000ms సమయం తీసుకునే కాల్‌కు మీరు 8ms లేదా 1ms అదనంగా జోడిస్తారా అనేదే ఇక్కడ అసలు చర్చ. ఇది శాటిలైట్ నుండి ఫైల్ డౌన్‌లోడ్ అవుతున్నప్పుడు, వేగవంతమైన USB కేబుల్ గురించి వాదించడం లాంటిది.

కొన్ని బెంచ్‌మార్క్‌లు "50x వేగవంతమైన లేటెన్సీ" అని పేర్కొంటున్నాయి. ఈ పరీక్షలు తరచుగా పరిమిత వనరులు ఉన్న చిన్న మెషీన్లపై జరుగుతాయి. ప్రొడక్షన్‌లో, మీరు హారిజాంటల్ స్కేలింగ్ (scale horizontally) చేస్తారు. మీరు మల్టిపుల్ ఇన్‌స్టెన్స్‌లను ఉపయోగించినప్పుడు, లేటెన్సీ తగ్గుతుంది.

అసలైన LLM కాల్ గేట్‌వే కంటే 50x నుండి 1000x ఎక్కువ సమయం తీసుకుంటుంది. మీ లేటెన్సీ మోడల్ వల్ల వస్తుంది, ప్రాక్సీ వల్ల కాదు.

మాకు నిజంగా ఫలితాన్ని ఇచ్చిన అంశాలు ఇవే:

మీరు LLM గేట్‌వేని ఎంచుకుంటే, దానికి బదులుగా ఈ అంశాలపై దృష్టి పెట్టండి:

మైక్రోసెకన్లలో గేట్‌వే ఓవర్‌హెడ్ గురించి చెప్పడం అనేది కేవలం మార్కెటింగ్ హెడ్‌లైన్ మాత్రమే. అది ప్రొడక్షన్ సమస్య కాదు. 1ms మాత్రమే జోడించి, నాకు ఏమీ తెలియకుండా వదిలేసే గేట్‌వే కంటే, 40ms అదనంగా తీసుకున్నా నా ఖర్చులను ట్రాక్ చేసే గేట్‌వేనే నాకు కావాలి.

మీ LLM ఇన్‌ఫ్రాస్ట్రక్చర్ పరంగా ఎదుర్కొంటున్న అతిపెద్ద సమస్య ఏమిటి?

మూలం: https://dev.to/paultwist/we-obsessed-over-gateway-latency-for-a-month-then-we-looked-at-the-actual-numbers-1kgk

ఐచ్ఛిక అభ్యాస సమూహం: https://t.me/GyaanSetuAi