64K-ടോക്കൺ പ്രോംപ്റ്റുകളിൽ vLLM, SGLang-നെ മറികടക്കുന്നു; എന്നാൽ 8-GPU B300 സെർവറിൽ കോൺടെക്സ്റ്റ് 200K എത്തുമ്പോൾ SGLang മുന്നിലെത്തുന്നു. ടോക്കൺ വിൻഡോകൾ വികസിക്കുമ്പോൾ, പ്രീഫിൽ (prefill) ജോലിയല്ല, മറിച്ച് ഡീകോഡ് ഘട്ടത്തിലെ (decode-stage) തടസ്സങ്ങളാണ് (bottlenecks) പ്രകടനം നിർണ്ണയിക്കുന്നത് എന്ന് ഈ മാറ്റം കാണിക്കുന്നു.

ഈ ബെഞ്ച്മാർക്ക് പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ചാറ്റ് അസിസ്റ്റന്റുകൾക്കും, കോഡ് അസിസ്റ്റന്റുകൾക്കും, ലക്ഷക്കണക്കിന് ടോക്കണുകൾ മെമ്മറിയിൽ സൂക്ഷിക്കേണ്ടി വരുന്ന മറ്റേതൊരു ആപ്പിനും ലോംഗ്-കോൺടെക്സ്റ്റ് ഇൻഫറൻസ് (long-context inference) വലിയ ചെലവ് വരുത്തിവെക്കുന്നു. വലിയ പാരാമീറ്ററുകളുള്ള Kimi-K3 മോഡൽ, ഇത്തരത്തിലുള്ള വിൻഡോകളെ സുഗമമായി കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന ആദ്യത്തെ ഓപ്പൺ-വെയ്റ്റ് LLM-കളിൽ ഒന്നാണ്. എന്നാൽ ഇത് പ്രവർത്തിപ്പിക്കുന്ന എൻജിനാണ് ഒരു റിക്വസ്റ്റ് സെക്കൻഡുകൾക്കുള്ളിൽ തീരുമോ അതോ മിനിറ്റുകൾ എടുക്കുമോ എന്ന് തീരുമാനിക്കുന്നത്.

vLLM-ഉം SGLang-ഉം ഉയർന്ന ത്രൂപുട്ട് (high-throughput) ഇൻഫറൻസ് വാഗ്ദാനം ചെയ്യുന്നുണ്ടെങ്കിലും, ഡീകോഡ് ഘട്ടത്തിൽ അവ വ്യത്യസ്തമായ സമീപനങ്ങളാണ് സ്വീകരിക്കുന്നത്. Decode Context Parallelism (DCP) വരുത്തുന്ന അധിക സിൻക്രണൈസേഷൻ (synchronization) ഒഴിവാക്കി vLLM ഡീകോഡ് പാത്ത് ലളിതമായി നിലനിർത്തുന്നു. SGLang, DCP ഉപയോഗിച്ച് കീ-വാല്യൂ (KV) കാഷെ റീഡുകളെ (cache reads) ഒന്നിലധികം GPU-കളിലായി വിന്യസിക്കുന്നു; അധിക കമ്മ്യൂണിക്കേഷൻ ചിലവ് വരുത്തിയാലും മെമ്മറി ബാൻഡ്‌വിഡ്ത്ത് കാര്യക്ഷമമായി ഉപയോഗിക്കാൻ ഈ സാങ്കേതികവിദ്യ സഹായിക്കുന്നു.

ടെസ്റ്റ്‌ബെഡ് (The testbed)

  • Hardware: ഒരേ മെമ്മറിയുള്ള എട്ട് NVIDIA B300 GPU-കൾ അടങ്ങിയ ഒരു സെർവർ.
  • Workloads: രണ്ട് കോൺടെക്സ്റ്റ്-ലെങ്ത് ക്രമീകരണങ്ങൾ – 64K ടോക്കണുകൾ ("ലോംഗ് കോൺടെക്സ്റ്റ്"-ന്റെ താഴ്ന്ന പരിധി), 200K ടോക്കണുകൾ (പല ഗവേഷണ ഡെമോകളും ലക്ഷ്യമിടുന്ന ഉയർന്ന പരിധി).
  • Metrics: നിശ്ചിത ബാച്ച് പ്രോംപ്റ്റുകൾ പ്രോസസ്സ് ചെയ്യാനുള്ള ആകെ സമയം; സമയവ്യത്യാസത്തിൽ നിന്നാണ് ത്രൂപുട്ട് കണക്കാക്കുന്നത്.

ബാച്ച് സൈസ്, മോഡൽ വെയ്റ്റുകൾ, മെമ്മറി ഉപയോഗം എന്നിവ ഞങ്ങൾ മാറ്റമില്ലാതെ നിലനിർത്തി. ഓരോ റണ്ണിനും ഇടയിൽ ഞങ്ങൾ മാറ്റം വരുത്തിയത് ഇൻഫറൻസ് എൻജിനിൽ മാത്രമാണ്.

കണക്കുകൾ

കോൺടെക്സ്റ്റ് എൻജിൻ സമയം (സെക്കൻഡ്) താരതമ്യ വേഗത
64 K vLLM 100.5 –
SGLang 150.8 vLLM ≈ 1.5× വേഗതയിൽ
200 K vLLM 295.2 –
SGLang 225.3 SGLang ≈ 1.31× വേഗതയിൽ

കോൺടെക്സ്റ്റ് വർദ്ധിച്ചപ്പോൾ vLLM-ന്റെ ത്രൂപുട്ട് (സെക്കൻഡിൽ ടോക്കണുകൾ) ഗണ്യമായി കുറഞ്ഞു: 64K-ൽ നിന്ന് 200K-ലേക്ക് എത്തുമ്പോൾ 3.29× കുറവ് രേഖപ്പെടുത്തി. എന്നാൽ SGLang-ന്റെ ത്രൂപുട്ട് ഇതേ പരിധിയിൽ 1.25× മാത്രമേ കുറഞ്ഞുള്ളൂ.

വ്യത്യാസം എവിടെ നിന്ന് വരുന്നു

പ്രീഫിൽ ഘട്ടത്തിൽ (പ്രോംപ്റ്റ് KV കാഷെയിലേക്ക് ലോഡ് ചെയ്യുന്നത്) രണ്ട് എൻജിനുകളും ഏകദേശം ഒരേ സമയം തന്നെയാണ് ചെലവഴിക്കുന്നത്. എന്നാൽ മോഡൽ ഓരോ ടോക്കണുകളായി ജനറേറ്റ് ചെയ്യുന്ന ഡീകോഡ് ഘട്ടത്തിലാണ് ഇവ തമ്മിലുള്ള വ്യത്യാസം പ്രകടമാകുന്നത്.

  • 64K ടോക്കണുകൾ: ഇന്റർ-GPU കമ്മ്യൂണിക്കേഷൻ ആണ് ഇവിടെ പ്രധാന ഘടകം. vLLM-ന്റെ സിംഗിൾ-GPU ഡീകോഡ് പാത്ത് DCP ആവശ്യപ്പെടുന്ന അധിക സിൻക്രണൈസേഷൻ ഒഴിവാക്കുന്നതിനാൽ ഏകദേശം 1.5× വേഗത്തിൽ ജോലി പൂർത്തിയാക്കാൻ സാധിക്കുന്നു.
  • 200K ടോക്കണുകൾ: KV കാഷെ വളരെ വലുതാകുന്നതിനാൽ അത് റീഡ് ചെയ്യുന്നത് ഒരു തടസ്സമായി മാറുന്നു. SGLang-ന്റെ DCP (സൈസ് 8 ആയി ക്രമീകരിച്ചത്), ഈ റീഡുകളെ എട്ട് GPU-കളിലായി വിഭജിക്കുന്നു. കമ്മ്യൂണിക്കേഷൻ ചിലവിനേക്കാൾ കൂടുതൽ ബാൻഡ്‌വിഡ്ത്ത് ലാഭം ലഭിക്കുന്നതിനാൽ SGLang വ്യക്തമായ മുന്നേറ്റം നടത്തുന്നു.

മെമ്മറി സമ്മർദ്ദത്തെക്കുറിച്ചുള്ള (memory pressure) മറ്റൊരു പ്രായോഗിക നിരീക്ഷണം കൂടിയുണ്ട്. 0.95 മെമ്മറി ഉപയോഗം ലക്ഷ്യമിട്ട് രണ്ട് എൻജിനുകൾ പ്രവർത്തിപ്പിച്ചപ്പോൾ B300-കളിൽ ഔട്ട്-ഓഫ്-മെമ്മറി (OOM) റീട്രൈകൾ (retries) ഉണ്ടായതായി കണ്ടു. ലക്ഷ്യം 0.92 ആയി കുറച്ചപ്പോൾ റീട്രൈകൾ ഒഴിവാകുകയും റൺടൈം സ്ഥിരത കൈവരിക്കുകയും ചെയ്തു; എന്നാൽ ഇത് ലേറ്റൻസിയിൽ (latency) നേരിയ വർദ്ധനവിന് കാരണമായി.

ആര് ജയിക്കുന്നു, ആര് തോൽക്കുന്നു

  • ചെറിയതോ ഇടത്തരമോ ആയ കോൺടെക്സ്റ്റുകൾ ഉപയോഗിക്കുന്ന ഡെവലപ്പർമാർ (≤ 64K ടോക്കണുകൾ) vLLM-ന്റെ ലളിതമായ ഡീകോഡ് പാത്തിൽ നിന്ന് കൂടുതൽ പ്രയോജനം നേടുന്നു. വേഗത്തിലുള്ള പ്രകടനം ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് ബില്ലുകൾ കുറയ്ക്കാനും മികച്ച യൂസർ എക്സ്പീരിയൻസ് നൽകാനും സഹായിക്കുന്നു.
  • ആഴത്തിലുള്ള വിശകലനത്തിനോ ഗവേഷണത്തിനോ വേണ്ടിയുള്ള ടൂളുകൾ നിർമ്മിക്കുന്ന ടീമുകൾ ലക്ഷക്കണക്കിന് ടോക്കണുകൾ കോൺടെക്സ്റ്റിൽ സൂക്ഷിക്കേണ്ടതുണ്ടെങ്കിൽ, DCP പ്രവർത്തനക്ഷമമാക്കിയ SGLang തിരഞ്ഞെടുക്കുന്നതാണ് ഉചിതം. ഇതിന്റെ സ്ഥിരതയുള്ള ത്രൂപുട്ട് ടൈം-ഔട്ട് സാധ്യത കുറയ്ക്കുകയും മെമ്മറി ആവശ്യകത കൂടുമ്പോഴും GPU ഉപയോഗം ഉയർന്ന നിലയിൽ നിലനിർത്തുകയും ചെയ്യുന്നു.
  • ഹാർഡ്‌വെയർ പ്ലാനർമാർ ശ്രദ്ധിക്കേണ്ട കാര്യം, വെറും GPU എണ്ണം മാത്രം ഉണ്ടെന്നതുകൊണ്ട് കാര്യങ്ങൾ എളുപ്പമാകില്ല എന്നതാണ്. KV ബാൻഡ്‌വിഡ്ത്ത് ഒരു തടസ്സമാകുമ്പോൾ, DCP വഴിയോ ഭാവിയിലെ മെമ്മറി-സബ്സിസ്റ്റം അപ്‌ഗ്രേഡുകൾ വഴിയോ കാഷെ റീഡുകളെ പാരലൽ (parallelize) ചെയ്യാൻ കഴിയുന്ന ആർക്കിടെക്ചറുകൾക്ക് മാത്രമേ ഒരേ ഹാർഡ്‌വെയറിൽ നിന്ന് കൂടുതൽ മൂല്യം ലഭിക്കുകയുള്ളൂ.

മറ്റൊരു വശം: vLLM ഈ വ്യത്യാസം കുറയ്ക്കുമോ?

പുതിയ വിവരങ്ങൾ ലഭ്യമാകുന്നതുവരെ, നിലവിലെ കണക്കുകളാണ് ഏറ്റവും മികച്ച താരതമ്യം.

ഇനി ശ്രദ്ധിക്കേണ്ടത്

  • വലിയ കോൺടെക്സ്റ്റ് വിൻഡോകൾ KV ബാൻഡ്‌വിഡ്ത്തിന് കൂടുതൽ സമ്മർദ്ദം ചെലുത്തും, ഇത് SGLang-ന്റെ മുന്നേറ്റം വർദ്ധിപ്പിക്കാൻ സാധ്യതയുണ്ട്.

ചുരുക്കത്തിൽ

ഒരു B300 ക്ലസ്റ്ററിൽ ലോംഗ്-കോൺടെക്സ്റ്റ് റിക്വസ്റ്റുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ, നിങ്ങളുടെ ടോക്കൺ വിൻഡോയ്ക്ക് അനുയോജ്യമായ എൻജിൻ തിരഞ്ഞെടുക്കുക. 64K ടോക്കൺ വർക്ക്ലോഡുകൾക്ക് vLLM ഏകദേശം 1.5× വേഗത്തിലുള്ള ഇൻഫറൻസ് നൽക