Prefill vs decode – dimensionera din lokala LLM efter verklig arbetslast

Prefill (läsa kontext) och decode (generera) är olika flaskhalsar. Dimensionera lokal LLM efter verklig arbetslast, inte bara tokens/sekund.

Publicerad
Uppdaterad
Lästid
6 min

Kort sagt

Många utvärderar lokala språkmodeller efter “tokens per sekund” vid generering. I praktiken är prefill (att läsa in systemprompt, kodbas eller dokument) ofta den verkliga begränsningen för agentiska och iterativa arbetsflöden.

En modell som är snabb på att skriva kan ändå kännas seg om den tar lång tid att “läsa” varje gång innan den svarar.

När är detta användbart?

  • När du kör lokala modeller för kodning, research eller agentarbete.
  • När du jämför hårdvara (Apple Silicon, NVIDIA, mini-PC, moln) för lokala AI-uppgifter.
  • När du vill undvika att köpa/optimera för fel sak (t.ex. bara jaga högre VRAM utan att titta på bandbredd och prefill).
  • För att avgöra när lokal inferens faktiskt ger värde jämfört med moln.

Två olika flaskhalsar

Prefill (context loading)

  • Modellen läser in all kontext (systemprompt, tidigare meddelanden, dokument, kod) innan den börjar generera.
  • Kräver mycket minnesbandbredd och beräkning.
  • Mycket viktigt för agentiska flöden där varje steg börjar med stor kontext.

Decode (token generation)

  • Modellen genererar ett token i taget.
  • Mäter ofta i tokens/sekund.
  • Viktigt för långa svar, men mindre avgörande för många interaktiva användningsfall.

Arbetslasten avgör rätt val

  • Interaktiv kodutveckling / agenter: Kräver låg prefill-latens + bra decode. Molnmodell kan vara bättre för långa resonemangskedjor.
  • Batch-jobb, transkribering, klassificering: Kan acceptera högre startlatens. Lokal modell ofta att föredra för integritet och kostnad.
  • Stora kontexter (hela kodbaser, långa dokument): Prefill blir dominerande. MoE-modeller och smart KV-cache kan hjälpa, men flyttar inte alltid problemet helt.

Vanliga missuppfattningar

  • “Större modell = bättre” – inte om den inte får plats eller är för långsam på prefill.
  • “Hög tokens/sekund räcker” – irrelevant om varje svarsrunda börjar med 10–30 sekunders prefill.
  • “SSD-offloading löser allt” – det sparar VRAM men kan försämra prefill-hastighet ytterligare.

Gör så här – praktisk utvärdering

  1. Definiera dina återkommande arbetsflöden (t.ex. “refaktorera funktion + förklara”).
  2. Mät prefill-tid + total svarstid på representativ kontextstorlek.
  3. Jämför energiförbrukning, integrationsfriktion och faktisk användningsfrekvens under en vecka.
  4. Välj modell/hårdvara baserat på vad som faktiskt används, inte vad som ser bäst ut i demo.

Koppling till tidigare material

Detta bygger vidare på agentroller, minne och styrning samt praktisk AI-användning. En agent som ska vara snabb och pålitlig behöver en inferensstack som är dimensionerad efter de verkliga stegen – inte bara efter modellstorlek.

Nästa steg

  • Välj 1–2 återkommande uppgifter du gör med AI.
  • Mät prefill och totaltid på din nuvarande setup.
  • Dokumentera vad som faktiskt känns användbart i vardagen.

Källor

  • Wiki-sammanfattning 2026-09-12: Lokal LLM: prefill, MoE och arbetslast
  • Wiki-sammanfattning 2026-09-07: Lokal LLM-infrastruktur: kapacitet, hastighet och drift
  • Relaterade klipp från Rob Braxman Tech, Kai m.fl. (sekundära källor).

Källor