ഒരു മാസക്കാലം ഞങ്ങൾ ഗേറ്റ്വേ ലേറ്റൻസിയിൽ (Gateway Latency) ശ്രദ്ധ കേന്ദ്രീകരിച്ചു
LLM ഗേറ്റ്വേ ഓവർഹെഡ് (overhead) അളക്കുന്നതിനായി ഞാൻ ഒരു മാസം ചെലവഴിച്ചു. പ്രോക്സി ലേറ്റൻസി (proxy latency) മൈക്രോസെക്കൻഡ് വരെ ഞാൻ നിരീക്ഷിച്ചു. സെക്കൻഡിൽ 500, 1000, 5000 റിക്വസ്റ്റുകൾ എന്ന നിരക്കിൽ ഞാൻ ലോഡ് ടെസ്റ്റുകൾ നടത്തി.
അപ്പോൾ ഒരു സഹപ്രവർത്തകൻ ചോദിച്ചു: "ആകെ റിക്വസ്റ്റ് സമയത്തിന്റെ എത്ര ശതമാനമാണ് ഗേറ്റ്വേ എടുക്കുന്നത്?"
ഞാൻ അത് പരിശോധിച്ചു. ഉത്തരം 0.3% ആയിരുന്നു.
നിലവിൽ LLM API കോളുകൾക്ക് എത്രത്തോളം ലേറ്റൻസി ആവശ്യമാണെന്ന് താഴെ നൽകുന്നു:
• GPT-4o: 850ms TTFT | 2-8s Total • Claude Sonnet 4: 900ms TTFT | 3-15s Total • Claude Fable 5: 147s TTFT | 155s Total • GPT-4.1: 1,100ms TTFT | 3-12s Total • Gemini 2.5 Flash: 500ms TTFT | 1-5s Total
ഇനി ഗേറ്റ്വേകൾ എത്രത്തോളം അധികം സമയം കൂട്ടുന്നു എന്ന് നോക്കൂ:
• Direct API call: 0ms • Python proxy: 8-40ms • Go/Rust proxy: 1-11ms
3,000ms മുതൽ 155,000ms വരെ എടുക്കുന്ന ഒരു കോളിൽ 8ms കൂട്ടുന്നതാണോ അതോ 1ms കൂട്ടുന്നതാണോ എന്നതിനെക്കുറിച്ചുള്ള തർക്കമാണിത്. ഒരു സാറ്റലൈറ്റിൽ നിന്ന് ഫയൽ ഡൗൺലോഡ് ചെയ്യുമ്പോൾ വേഗതയേറിയ ഒരു USB കേബിളിനെക്കുറിച്ച് തർക്കിക്കുന്നത് പോലെയാണിത്.
ചില ബെഞ്ച്മാർക്കുകൾ "50 മടങ്ങ് വേഗതയേറിയ ലേറ്റൻസി" (50x faster latency) എന്ന് അവകാശപ്പെടുന്നു. ഇത്തരം ടെസ്റ്റുകൾ പലപ്പോഴും പരിമിതമായ വിഭവങ്ങളുള്ള ചെറിയ മെഷീനുകളിലാണ് നടത്താറുള്ളത്. പ്രൊഡക്ഷനിൽ (production), നിങ്ങൾ ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ് (horizontal scaling) ആണ് ഉപയോഗിക്കുന്നത്. ഒന്നിലധികം ഇൻസ്റ്റൻസുകൾ ഉപയോഗിക്കുമ്പോൾ ലേറ്റൻസി കുറയുന്നു.
യഥാർത്ഥ LLM കോൾ ഗേറ്റ്വേയേക്കാൾ 50 മുതൽ 1000 മടങ്ങ് വരെ കൂടുതൽ സമയം എടുക്കുന്നു. നിങ്ങളുടെ ലേറ്റൻസി വരുന്നത് മോഡലിൽ നിന്നാണ്, പ്രോക്സിയിൽ നിന്നല്ല.
ഞങ്ങളുടെ കാര്യത്തിൽ യഥാർത്ഥത്തിൽ മാറ്റം വരുത്തിയത് ഇവയാണ്:
- മോഡൽ തിരഞ്ഞെടുപ്പ്: ലളിതമായ ജോലികൾക്കായി GPT-4o-യിൽ നിന്ന് Gemini 2.5 Flash-ലേക്ക് മാറിയത് ലേറ്റൻസി 60% കുറച്ചു.
- ലേറ്റൻസി അടിസ്ഥാനമാക്കിയുള്ള റൂട്ടിംഗ്: ലഭ്യമായതിൽ ഏറ്റവും വേഗതയേറിയ മോഡലിലേക്ക് റിക്വസ്റ്റുകൾ റൂട്ട് ചെയ്തത് ഞങ്ങളുടെ P99 ലേറ്റൻസി 40% കുറച്ചു.
- കാഷിംഗ് (Caching): ഇത് ഞങ്ങളുടെ വർക്ക്ഫ്ലോയിലെ ആവർത്തന കോളുകൾ (redundant calls) 30% കുറച്ചു.
- പ്രോംപ്റ്റ് നീളം: സിസ്റ്റം പ്രോംപ്റ്റുകൾ 2000 ടോക്കണുകളിൽ നിന്ന് 800 ടോക്കണുകളായി കുറച്ചത് മറുപടികൾ 35% വേഗത്തിലാക്കി.
- ഫെയിലോവർ (Failover): തകരാറുകൾ സംഭവിക്കുമ്പോൾ മറ്റ് പ്രൊവൈഡർമാരിലേക്ക് ഓട്ടോമാറ്റിക്കായി മാറുന്നത് നിങ്ങളുടെ സേവനം തടസ്സമില്ലാതെ മുന്നോട്ട് കൊണ്ടുപോകാൻ സഹായിക്കുന്നു.
നിങ്ങൾ ഒരു LLM ഗേറ്റ്വേ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, പകരം ഇവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക:
- പ്രൊവൈഡർ കവറേജ്: നിങ്ങൾക്ക് ആവശ്യമുള്ള മോഡലുകൾ ഇത് പിന്തുണയ്ക്കുന്നുണ്ടോ?
- റൂട്ടിംഗും ഫെയിലോവറും: തകരാറുകൾ (outages) ഇത് കൈകാര്യം ചെയ്യുന്നുണ്ടോ?
- കോസ്റ്റ് ട്രാക്കിംഗ്: ഏത് ഉപയോക്താക്കളാണ് കൂടുതൽ ടോക്കണുകൾ ഉപയോഗിക്കുന്നത് എന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയുമോ?
- ഇക്കോസിസ്റ്റം: പ്രശ്നങ്ങൾ ഉണ്ടാകുമ്പോൾ സഹായിക്കാൻ ഒരു കമ്മ്യൂണിറ്റി ഉണ്ടോ?
- എക്സ്റ്റൻസിബിലിറ്റി (Extensibility): നിങ്ങൾക്ക് എളുപ്പത്തിൽ കസ്റ്റം ലോജിക് ചേർക്കാൻ കഴിയുമോ?
മൈക്രോസെക്കൻഡുകളിലുള്ള ഗേറ്റ്വേ ഓവർഹെഡ് എന്നത് ഒരു മാർക്കറ്റിംഗ് തലക്കെട്ട് മാത്രമാണ്. അത് പ്രൊഡക്ഷനിൽ ഒരു പ്രശ്നമല്ല. 1ms മാത്രം കൂട്ടുന്നതും എന്നാൽ എനിക്ക് വിവരങ്ങൾ ഒന്നും നൽകുന്നില്ലാത്തതുമായ ഒരു ഗേറ്റ്വേയേക്കാൾ, 40ms കൂട്ടുമെങ്കിലും എന്റെ ചിലവുകൾ ട്രാക്ക് ചെയ്യുന്ന ഒരു ഗേറ്റ്വേയാണ് ഞാൻ ആഗ്രഹിക്കുന്നത്.
നിങ്ങളുടെ LLM ഇൻഫ്രാസ്ട്രക്ചറിലെ ഏറ്റവും വലിയ ബുദ്ധിമുട്ട് എന്താണ്?
ഐച്ഛികമായ പഠന സമൂഹം: https://t.me/GyaanSetuAi