ഒരു LLM ദീർഘമായ ഒരു മറുപടി തയ്യാറാക്കുന്നത് കാണുകയും, തുടക്കത്തിലെ വേഗതയ്ക്ക് ശേഷം അത് എന്തുകൊണ്ടാണ് ഇത്ര സാവധാനത്തിലാകുന്നത് എന്ന് ചിന്തിക്കുകയും ചെയ്തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഒരു ഹാർഡ്വെയർ തടസ്സം (hardware bottleneck) നേരിട്ടുകൊണ്ടിരിക്കുകയാണ്. മിക്ക ഡെവലപ്പർമാരും ഇതിന് കാരണം അവരുടെ Python കോഡ്, ഫ്രെയിംവർക്ക്, അല്ലെങ്കിൽ മോഡലിന്റെ വലിപ്പം എന്നിവയാണെന്ന് കരുതാറുണ്ട്. അവർ ഫംഗ്ഷനുകൾ പ്രൊഫൈൽ ചെയ്യുന്നു, ഒപ്റ്റിമൈസറുകൾ മാറ്റുന്നു, പ്രീപ്രോസസ്സിംഗിലെ मिलीസെക്കൻഡുകൾ കുറയ്ക്കാൻ ശ്രമിക്കുന്നു. എന്നാൽ ഇവയൊന്നും യഥാർത്ഥ പ്രശ്നത്തെ പരിഹരിക്കുന്നില്ല. വേഗതയുടെ പരിധി നിങ്ങളുടെ സോഫ്റ്റ്വെയറിലല്ല, മറിച്ച് സിലിക്കണിലാണ് (silicon).
ഓരോ ലാർജ് ലാംഗ്വേജ് മോഡൽ ഇൻഫറൻസ് ജോലിയും നിങ്ങളുടെ സെർവറിലുള്ള GPU-വിന്റെ രണ്ട് ഭൗതിക സവിശേഷതകളെ ആശ്രയിച്ചിരിക്കുന്നു: അതിന് എത്ര വേഗത്തിൽ കണക്കുകൂട്ടലുകൾ നടത്താൻ കഴിയും (crunch numbers), കൂടാതെ ആ കണക്കുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനായി എത്ര വേഗത്തിൽ നീക്കാൻ കഴിയും.
കണക്കുകൂട്ടലുകൾ എളുപ്പമാണ്, എന്നാൽ ഡാറ്റ നീക്കുന്നത് അത്ര എളുപ്പമല്ല
GPU മാർക്കറ്റിംഗ് കമ്പനികൾ കമ്പ്യൂട്ടിനെ (compute) കുറിച്ച് സംസാരിക്കാൻ ഇഷ്ടപ്പെടുന്നു. സെക്കൻഡിൽ ട്രില്യൺ കണക്കിന് ഫ്ലോട്ടിംഗ്-പോയിന്റ് ഓപ്പറേഷനുകൾ. ആ സംഖ്യകൾ അതിശയിപ്പിക്കുന്നതാണ്. എന്നാൽ കമ്പ്യൂട്ട് എന്നത് കഥയുടെ പകുതി മാത്രമാണ്. ബാക്കി പകുതി മെമ്മറി ബാൻഡ്വിഡ്ത്ത് (memory bandwidth) ആണ്; അതായത്, ഹൈ-ബാൻഡ്വിഡ്ത്ത് മെമ്മറിയിൽ നിന്ന് യഥാർത്ഥ ഗണിതക്രിയകൾ നടക്കുന്ന കമ്പ്യൂട്ട് കോറുകളിലേക്ക് ഡാറ്റ സഞ്ചരിക്കുന്ന നിരക്ക്.
ഈ രണ്ട് കണ്ണികളിൽ ഏതാണോ ദുർബലമാകുന്നത്, അതിനേക്കാൾ വേഗത്തിൽ ഒരു LLM-ന് പ്രവർത്തിക്കാൻ കഴിയില്ല. ഇരുപത് വിദഗ്ധരായ പാചകക്കാർ ഉള്ള ഒരു വാണിജ്യ അടുക്കള സങ്കൽപ്പിക്കുക. അടുപ്പുകൾ ചൂടാണ്, കത്തികൾ മൂർച്ചയുള്ളതാണ്, ഓരോ പാചകക്കാരനും തയ്യാറാണ്. എന്നാൽ പച്ചക്കറികൾ സൈക്കിളിൽ ഓരോ കുട്ടകളായിട്ടാണ് വരുന്നത്. അടുക്കളയുടെ പ്രവർത്തനം തടസ്സപ്പെടുന്നു. കൂടുതൽ പാചകക്കാരെ ചേർക്കുന്നത് ഇത് പരിഹരിക്കില്ല. വേഗതയേറിയ അടുപ്പുകൾ വാങ്ങുന്നതും ഇതിന് പരിഹാരമല്ല. തടസ്സം റോഡിലാണ്.
ആധുനിക ഡാറ്റാസെന്റർ GPU-കളിൽ, ഗണിത യൂണിറ്റുകൾ (arithmetic units) അത്രത്തോളം ശക്തമാണ്, അതിനാൽ അവ പലപ്പോഴും കണക്കുകൂട്ടലുകൾ വേഗത്തിൽ പൂർത്തിയാക്കി, മെമ്മറിയിലൂടെ വെയ്റ്റ്സുകളും (weights) ആക്ടിവേഷനുകളും (activations) ഒഴുകിയെത്തുന്നത് വരെ വെറുതെ ഇരിക്കുകയാണ് ചെയ്യുന്നത്. ഈ അസന്തുലിതാവസ്ഥ നിങ്ങളുടെ കോഡിലെ ഒരു പിശകല്ല. അത് ചിപ്പുകൾ നിർമ്മിച്ചിരിക്കുന്ന രീതിയുടെ ഭൗതിക യാഥാർത്ഥ്യമാണ്. മെമ്മറി ബാൻഡ്വിഡ്ത്ത് കമ്പ്യൂട്ടിന്റെ വേഗതയ്ക്കൊപ്പം എത്താൻ കഴിഞ്ഞിട്ടില്ല. LLM-കൾക്ക് ഈ അസന്തുലിതാവസ്ഥ കൂടുതൽ പ്രയാസകരമാണ്, കാരണം അവയുടെ ഫോർവേഡ് പാസുകൾക്ക് (forward passes) ഓരോ ഔട്ട്പുട്ട് ടോക്കണിനും എല്ലാ പാരാമീറ്ററുകളും പരിശോധിക്കേണ്ടതുണ്ട്.
പ്രോംപ്റ്റുകൾ വേഗതയുള്ളതായും ജനറേഷൻ സാവധാനത്തിലായും തോന്നുന്നത് എന്തുകൊണ്ട്?
LLM ഇൻഫറൻസ് രണ്ട് വ്യത്യസ്ത ഘട്ടങ്ങളായി തിരിയുന്നു, അവ ഹാർഡ്വെയറിനെ തികച്ചും വ്യത്യസ്തമായ രീതിയിലാണ് സമ്മർദ്ദത്തിലാക്കുന്നത്.
Prefill സംഭവിക്കുന്നത് നിങ്ങളുടെ പ്രോംപ്റ്റ് ആദ്യമായി മോഡലിൽ എത്തുമ്പോഴാണ്. എല്ലാ ടോക്കണുകളും ഒരേസമയം എത്തുന്നു. വലിയ മാട്രിക്സ്-മാട്രിക്സ് മൾട്ടിപ്ലിക്കേഷനുകൾ (matrix-matrix multiplications) ഉപയോഗിച്ച് GPU-വിന് അവയെ സമാന്തരമായി പ്രോസസ്സ് ചെയ്യാൻ കഴിയും. ആയിരക്കണക്കിന് ഗണിത യൂണിറ്റുകൾ ഒരേസമയം പ്രവർത്തിക്കുന്നു, അതിനാൽ വർക്ക് ലോഡ് വളരെ സാന്ദ്രമാണ്. ഈ ഘട്ടം കമ്പ്യൂട്ട്-ബൗണ്ട് (compute-bound) ആണ്. തുടക്കത്തിൽ നിങ്ങൾ കാണുന്ന ആ പെട്ടെന്നുള്ള വേഗത? അത് GPU അതിന്റെ പൂർണ്ണ ശേഷിയിൽ പ്രവർത്തിക്കുന്നത് കൊണ്ടാണ്.
Decode ഘട്ടത്തിലാണ് കാര്യങ്ങൾ പ്രയാസകരമാകുന്നത്. മോഡൽ അടുത്ത ടോക്കൺ നിർമ്മിക്കുമ്പോൾ, അത് ഓരോ ടോക്കണുകളായിട്ടാണ് ചെയ്യുന്നത്. ഈ ഘട്ടം മാട്രിക്സ്-വെക്റ്റർ ഓപ്പറേഷനുകളെ (matrix-vector operations) ആശ്രയിച്ചിരിക്കുന്നു, ഇത് GPU-വിന്റെ സമാന്തര ശേഷിയുടെ വളരെ ചെറിയൊരു ഭാഗം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ. ഇതിലും മോശമായ കാര്യം, ഓരോ പുതിയ ടോക്കൺ വരുമ്പോഴും മുഴുവൻ മോഡൽ വെയ്റ്റ്സുകളും മെമ്മറിയിൽ നിന്ന് വീണ്ടും ലോഡ് ചെയ്യാൻ GPU നിർബന്ധിതമാകുന്നു എന്നതാണ്. ഗണിത യൂണിറ്റുകൾക്ക് ജോലി ആവശ്യമാണ്, എന്നാൽ പകരം അവ കാത്തുനിൽക്കുകയാണ് ചെയ്യുന്നത്. അതിനാൽ Decode എന്നത് മെമ്മറി-ബൗണ്ട് (memory-bound) ആണ്. ഗണിത എൻജിനുകൾ വിശ്രമിക്കുമ്പോൾ, മെമ്മറി ബസിലൂടെ പാരാമീറ്ററുകൾ അങ്ങോട്ടുമിങ്ങോട്ടും എത്തിക്കുന്ന ഒരു വിലകൂടിയ ട്രാഫിക് കൺട്രോളറുടെ പങ്ക് മാത്രമാണ് GPU ഇവിടെ നിർവഹിക്കുന്നത്. അതുകൊണ്ടാണ് തുടക്കത്തിലെ പ്രോംപ്റ്റ് വിശകലനം പെട്ടെന്ന് നടന്നുവെങ്കിലും, നൂറോളം വാക്കുകളുള്ള ഒരു മറുപടി ലഭിക്കാൻ പത്ത് സെക്കൻഡ് വരെ എടുക്കുന്നത്.
KV cache ഈ പ്രക്രിയയെ കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നു. Decode സമയത്ത്, ഓരോ മുൻപത്തെ ടോക്കണിനും വേണ്ടി മോഡൽ കീ (key), വാല്യൂ (value) ടെൻസറുകൾ സംഭരിക്കുന്നു, അങ്ങനെ ഓരോ തവണയും അറ്റൻഷൻ (attention) വീണ്ടും കണക്കുകൂട്ടേണ്ടി വരുന്നില്ല. സീക്വൻസിന്റെ നീളം കൂടുന്നതിനനുസരിച്ച് ഈ കാഷെയും വളരുന്നു. ഇത് മെമ്മറിയിലാണ് നിലനിൽക്കുന്നത്. അതിനാൽ ഇപ്പോൾ GPU വെയ്റ്റ്സുകൾ മാത്രം റീലോഡ് ചെയ്യുകയല്ല; ഓരോ ഫോർവേഡ് പാസിലും വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു കാഷെ വായിക്കുകയും എഴുതുകയും ചെയ്യുന്നു. കമ്പ്യൂട്ട് കോറുകൾ കാര്യമായി അധ്വാനിക്കുന്നില്ലെങ്കിലും മെമ്മറി ബസ് കഠിനമായി ജോലി ചെയ്യുന്നു.
മെമ്മറി വാളിനെ (Memory Wall) നേരിടൽ
ഡാറ്റയുടെ നീക്കം കുറയ്ക്കുന്നതിനോ അല്ലെങ്കിൽ ഡാറ്റ നീക്കുന്നതിനുള്ള ചിലവ് കുറയ്ക്കുന്നതിനോ വേണ്ടി എഞ്ചിനീയർമാർ ചില സാങ്കേതിക വിദ്യകൾ വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്.
Batching ആണ് ഏറ്റവും ലളിതമായ മാർഗ്ഗം. ഒരു ഉപയോക്താവിന്റെ അഭ്യർത്ഥന മെമ്മറിയിൽ നിന്ന് മുഴുവൻ വെയ്റ്റ്സുകളും ലോഡ് ചെയ്യാൻ പ്രേരിപ്പിക്കുന്നുണ്ടെങ്കിൽ, എട്ട് അല്ലെങ്കിൽ പതിനാറ് അഭ്യർത്ഥനകൾ ഒരേസമയം പ്രോസസ്സ് ചെയ്യുന്നത് ആ ലോഡ് എല്ലാ അഭ്യർത്ഥനകളിലുമായി വിഭജിക്കാൻ GPU-യെ സഹായിക്കുന്നു. വെയ്റ്റ്സുകൾ ഒരിക്കൽ മാത്രം വായിക്കുന്നു, അത് ബാച്ചിലെ ഓരോ സീക്വൻസിനും വീണ്ടും ഉപയോഗിക്കുന്നു. പ്രൊഡക്ഷൻ സാഹചര്യങ്ങളിൽ, സങ്കീർണ്ണമായ ഷെഡ്യൂളിംഗ് സിസ്റ്റങ്ങൾ അഭ്യർത്ഥനകളെ ഡൈനാമിക് ആയി ഗ്രൂപ്പ് ചെയ്യുന്നു (ഇതിനെ continuous അല്ലെങ്കിൽ in-flight batching എന്ന് വിളിക്കുന്നു), അങ്ങനെ GPU അപൂർവ്വമായി മാത്രമേ നിർത്തിനിൽക്കുന്നുള്ളൂ. ഒരേ റൂട്ടിലൂടെ പോകുന്ന ഒരു ബസും പതിനാറ് പ്രത്യേക കാറുകളും തമ്മിലുള്ള വ്യത്യാസം പോലെയാണിത്.
Quantization attacks the bandwidth problem directly. Model weights are usually stored in sixteen-bit floating-point formats. By compressing them down to eight-bit or even four-bit integers, you literally cut the amount of data traveling across the bus by half or more. The model still needs enough precision to produce coherent output, but modern post-training quantization methods can shrink a model’s memory footprint dramatically without destroying quality. Less data in flight means less time spent waiting at the memory controller.
FlashAttention restructures the attention mechanism to keep intermediate results inside the GPU's fast on-chip memory. Standard attention had to write large attention matrices out to slow external memory and then read them back. FlashAttention breaks the calculation into smaller tiles that fit in SRAM, performs the softmax and scaling steps on-chip, and only writes the final outputs back to high-bandwidth memory. It trades a bit of extra compute for far fewer round trips to main memory, which is almost always a winning bet.
PagedAttention solves a different kind of memory waste. During decode, the KV cache grows unpredictably. Traditional systems allocate fixed, contiguous chunks of memory for each sequence, leaving large holes as some sequences end early and others expand. PagedAttention borrows the concept of virtual memory from operating systems. It stores KV cache entries in fixed-size blocks that can be allocated non-contiguously and mapped through an indirection table. This stops memory from sitting idle inside reserved but half-empty buffers and allows larger batch sizes, which in turn improves overall throughput by keeping the memory bus busy with useful work instead of fragmentation overhead.
Shift the Question
When latency spikes, too many teams ask whether they should switch to a smaller model or rewrite their inference server. Those questions matter, but they are secondary. The first question should be about the hardware itself. Is your GPU actually busy computing, or is it starved for data?
Look at your utilization metrics. Profile memory bandwidth saturation alongside GPU compute occupancy. If you see high memory contention and low arithmetic intensity during decode, you do not have a model architecture problem. You have a physics problem. The solution will not come from cleaner Python. It will come from batching more aggressively, quantizing your weights to squeeze through the pipe faster, restructuring attention to stay on-chip, and managing the KV cache so you can fit larger batches without running out of room.
Once you see inference through this lens, optimization becomes mechanical. You stop chasing myths about model intelligence slowing things down and start making engineering decisions grounded in what the hardware can actually deliver. That is the shift that separates production systems that scale from those that merely function.