2026-03-13 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

LLM Ingenieursgids: 45 concepten voor Inference, training, architectuur en operationele beheer

Productiesystemen LLM halen tegelijkertijd informatie uit GPU hardware, systeemontwerp en ML-theorie. Hetzelfde aantal kernconcepten is van toepassing, of je nu TTFT afstelt voor een chatbot of DeepSpeed ZeRO configureert voor een fine-tuning-run. Deze gids verzamelt al deze concepten op één plek.

TL;DR: Deze gids behandelt 45 concepten in acht delen, van hardware en inference tot aan training, deployment, en dagelijkse operaties. Elke beschrijving definieert het betreffende concept, legt uit wat de praktische gevolgen zijn, geeft waar nodig cijfers om de schaal duidelijk te maken, en vermeldt gerelateerde onderdelen. De genoemde gegevens omvatten de periode van 2024 tot begin 2026.

Deze gids gaat uit van kennis van de basisprincipes van ML (backpropagatie, gradientdescent en softmax), evenals van enkele systemenkennisgebieden (geheugenhiërarchieën en basisprincipes van netwerken).

[!NOTE] Een opmerking over het bereik

Dit is een uitgebreide referentie, geen lineair tutorial. Gebruik de tabel hieronder om direct te gaan naar het gedeelte dat overeenkomt met uw huidige beslissing.

Hoe je deze handleiding kunt gebruiken als centraal punt

Deze pagina is bewust breed opgezet. Gebruik haar als een overzichtskaart en ga pas verder naar de meer gedetailleerde artikelen zodra de beslissing concreet is geworden.

De meest rendabele aanpak is doorgaans: begrijp de bottleneck, kies de kleinste stack die deze ondersteunt, benchmark onder reële werklast, en voeg pas complexiteit toe wanneer de cijfers dat rechtvaardigen.

Deel I — Hardwarefundamenten

De hier besproken concepten — rekenintensiteit, de GPU geheugenhiërarchie en de hardwaretermen — komen overal anders in deze gids voor.

1. Geheugenbeperkt versus rekenkrachtbeperkt en de roofline model

Het uitgangspunt voor de prestaties van LLM is de aritmetische intensiteit: voor elk byte aan gegevens dat door de GPU uit het geheugen wordt geladen, hoeveel bruikbare berekeningen worden er uitgevoerd? Die verhouding bepaalt of een operatie compute-bound is (wachten op de processor) of memory-bound (wachten op het laden van gegevens).

Elk GPU beschikt over een drempelwaarde voor “kritische intensiteit”, waarbij de rekenkracht precies in balans is met de geheugensnelheid. Voor een NVIDIA H100 (Specificatiesblad, 2023):

$\frac{989 \text{ TFLOPS}}{3,35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

De twee fasen van LLM inference bevinden zich aan tegenovergestelde kanten van deze drempel:

• Decode is gebonden aan het geheugen. Het genereren van tokens één voor één betekent dat de meergigabyte grote weight matrix uit het geheugen moet worden geladen om deze te vermenigvuldigen met een enkele nieuwe token. In een vereenvoudigde 16-bits analyse waarbij per batch slechts één berekening wordt uitgevoerd, bedraagt de rekenkracht ongeveer 1 FLOP/byte, wat bijna 300 keer lager ligt dan de drempelwaarde van de H100. Dit verschil verklaart waarom decode in dit scenario niet tot de maximale rekenkracht van throughput kan komen.
• Prefill is gebonden aan de rekenkracht. Het verwerken van de invoer prompt vereist dat weights één keer wordt geladen, maar vervolgens worden er tegelijkertijd honderden of duizenden tokens mee vermenigvuldigd. De belasting stijgt hierdoor aanzienlijk boven de 295 en zorgt ervoor dat de rekenonderdelen verzadigd raken.

Om decode te versnellen, is het nodig om aan de geheugensnelheid te werken: verklein de weights door quantization, de KV-memorybelasting verminderen met GQA en PagedAttention, en verhoog de intensiteit met batchverwerking. Om prefill te versnellen, moet er gewerkt worden aan ruwe berekening: snelere GPUs en FP8 verwerking.

2. GPU geheugenhiërarchie

Een GPU beschikt over vier geheugelaagjes die zijn gerangschikt als een piramide: een groot, maar traag hoofdgeheugen (HBM) aan de onderkant, en zeer kleine, maar zeer snelle registers aan de bovenkant. Het verplaatsen van gegevens omhoog en omlaag door deze piramide vormt het grootste verkeersopstoppingpunt. De meest belastende bottleneck bevindt zich tussen HBM en SRAM, waarbij SRAM ongeveer 10 keer sneller is.

Van snelst tot langzaamst op een H100:

1. Registers — het snelste geheugen, dat rechtstreeks is verbonden aan de verwerkingsthreads. Hier vindt de daadwerkelijke rekenwerkzaamheid plaats; gegevens moeten hier worden geladen zodat de Tensor Cores ze kunnen gebruiken.
2. SRAM (Shared Memory) — het werkgeheugen met een snelheid van ongeveer 33 TB/s.
3. L2 Cache — een tussenlaag (50 MB) met een snelheid van rond de 12 TB/s. Deze fungeert als buffer zodat wanneer meerdere SM’s toegang hebben tot dezelfde weights, ze niet allemaal hoeven te halen uit HBM.
4. HBM3 — het 80 GB grote hoofdgeheugen dat model weights en KV cache bevat, met een snelheid van ~3,35 TB/s.

De fusie van FlashAttention en kernel, evenals PagedAttention, verminderen allemaal het verkeer tussen deze lagen. Hierdoor blijft de gegevenslengere tijd op de snelle SRAM opgeslagen, waardoor herhaalde overdrachten naar HBM worden voorkomen.

3. GPU hardwareglossarium

De onderstaande termen komen herhaaldelijk voor in de rest van deze gids.

HBM (High Bandwidth Memory) — Gestapelde DRAM-chips die via through-silicon vias (TSVs) met elkaar zijn verbonden en direct naast de GPU-chip binnen het pakket zijn geplaatst. Generaties: HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s), HBM3e (H200/B200, 4,8–8 TB/s). Waarom dit belangrijk is voor LLMs: decode wordt beperkt door de geheugenbandbreedte, waardoor de bandbreedte van HBM rechtstreeks de TPOT bepaalt.

GDDR (Graphics DDR) — Traditionele grafische geheugens (GDDR6, GDDR6X) die worden gebruikt in consumentenGPUs (RTX 4090, L40S). Ze hebben een lagere bandbreedte dan HBM, maar zijn goedkoper per GB. GDDR6X op RTX 4090 Het levert ongeveer 1 TB/s op, vergeleken met de 3,35 TB/s van de HBM3 in de H100.

SM (Streaming Multiprocessor) — De basisrekenonderdelen van NVIDIA GPUs. Elke SM bevat CUDA cores, Tensor Cores, gedeelde geheugen (SRAM) en een warp scheduler. H100 beschikt over 132 SM’s; De A100 beschikt over 108.

Tensor Cores — Gespecialiseerde eenheden voor matrix-multiply-accumulate die zich binnen elke SM bevinden. Zij versnellen matmuls-operaties in gemengde precisie (FP16, BF16, FP8, INT8), die een centrale rol spelen bij de berekening van transformers. De Tensor Cores van de H100 zorgen voor een aanzienlijke versnelling 989 TFLOPS in TF32 tegenover ongeveer 67 TFLOPS die alleen al worden gegenereerd door de CUDA cores.

CUDA Cores — Algemene eenheiden voor vlakke getallen en gehele getallen. Zij voeren elementgewijze operaties uit, activation functies en andere taken dan matmul. Tensor Cores zorgen voor de zwaarste berekeningen bij LLMs; CUDA cores behandelen alle overige taken.

Warp — Een groep van 32 threads die synchroon worden uitgevoerd op een SM. De kleinste planningseenheid bij NVIDIA GPUs. Warp-specialisatie Het kent verschillende warps toe aan verschillende taken (dataloading versus berekening) voor het opzetten van een pipeline.

NVLink — Een hoge-snelheids GPU-naar-GPU interconnect binnen een node. NVLink 4.0 (H100) levert een bidirectionele bandbreedte van 900 GB/s; NVLink 5.0 (B200) bereikt 1,8 TB/s. Dit is essentieel voor tensorparallelisme, waarbij GPUs op elke laag activations moet uitwisselen.

InfiniBand — Een hoge-snelheidsnetwerkstructuur voor communicatie tussen nodes via GPU. NVIDIA ConnectX-7 Het levert 400 Gb/s per poort op. Het wordt gebruikt voor pipeline-paralleliteit en gedistribueerd trainen over meerdere nodes.

RDMA (Remote Direct Memory Access) — Het maakt het mogelijk voor één GPU om de geheugeninformatie van een andere machine te lezen of te schrijven zonder de tussenkomst van de CPU, waardoor latency tot een minimum wordt beperkt. GPUDirect RDMA Maakt directe overdrachten van GPU naar GPU tussen nodes mogelijk. Wordt gebruikt in gedecentraliseerde serving-architecturen voor het uitvoeren van KV cache-transfers.

NVMe (Non-Volatile Memory Express) — Een hoge-snelheids-SSD-interface die wordt gebruikt voor het afleiden van KV cache naar externe hardware. ZeRO-Infinity Parameteroffloading wanneer de GPU/CPU-geheugenruimte onvoldoende is. De sequentiële leessnelheden liggen tussen 5 en 7 GB/s per schijf (PCIe Gen 4), terwijl nieuwere Gen 5-schijven snelheden van 10 tot 14 GB/s kunnen bereiken.

TFLOPS / PFLOPS — Tera/Peta bewerkingen met vloeiende komma’s per seconde. 1 TFLOPS = 10¹² FLOPS. De standaardeenheid voor het meten van de GPU rekenkracht van throughput. De H100 levert 989 TFLOPS (TF32) op; de FlashAttention-3 bereikt ongeveer 1,2 PFLOPS in FP8.

Deel II — Inference fundamenten

Inference vormt het deel van het systeem dat door gebruikers daadwerkelijk wordt waargenomen. Latency, de KV cache, de tweefasige uitvoering model, attention en quantization bepalen samen hoe snel, hoe goedkoop en hoe betrouwbaar de dienstverlening kan plaatsvinden.

4. Latency: TTFT, TPOT en percentielen

Time to First Token (TTFT) is de vertraging vanaf het indienen van een verzoek tot de eerste uitvoer token. Deze wordt bepaald door de prefill fase: de model moet eerst de gehele prompt verwerken voordat er iets wordt gegenereerd, waardoor langere prompts-tijden doorgaans leiden tot een hogere TTFT-waarde. De doelwaarden zijn productspecifiek; MLPerf Inference v5.0 Het maakt gebruik van een P99 TTFT-limiet van $\leq$ 450 ms voor zijn interactieve scenario met Llama 2 70B.

Tijd per uitvoer Token (TPOT) is de gemiddelde tijd tussen opeenvolgende tokens na de eerste. Dit correspondeert met de decode-fase, waarin elke stap wordt beperkt door de geheugensnelheid:

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

De gemiddelde leessnelheid van volwassenen in het Engels bij stille lezing ligt rond de 238 woorden per minuut voor niet-fictie.Brysbaert, 2019). De streamingdoelwaarden moeten nog steeds afkomstig zijn uit producttesten; MLPerf hanteert voor zijn interactieve scenario een P99 TPOT-limiet van $\leq$ 40 ms.

P50 versus P99 latency is belangrijk omdat de mediaan de uiteinden van de verdeling verbergt. Een systeem met een goede P50 maar een slechte P99 kan last hebben van problemen als batchverwerking, preemption, queuing of workload-skew; traces zijn nodig om deze situaties van elkaar te onderscheiden.

5. Throughput: tokens per seconde en de latency-compromis

Throughput wordt gemeten in uitvoer tokens per seconde voor meerdere gelijktijdige verzoeken. Het aantal verzoeken per seconde alleen is minder betrouwbaar, omdat een respons van 10-token en een respons van 1.000-token zeer verschillende kosten met zich meebrengen. De gepubliceerde benchmark cijfers verschillen afhankelijk van model, de nauwkeurigheid, de hardware, prompt en de lengte van de uitvoer, de gelijktijdigheid en de SLO’s. Vergelijk ze dus zorgvuldig. vLLM, SGLang, en TensorRT-LLM met één harness in plaats van hun hoofdresultaten te combineren.

Het compromis: bij lage parallelle verwerking krijgt elke vraag een hoge latency, maar wordt de GPU onvoldoende benut. Het vergroten van de batchgrootte zorgt voor een bijna lineaire stijging van throughput totdat de rekenkracht verzadigd is; daarna stijgt latency drastisch. Goodput, oftewel het aandeel aanvragen dat voldoet aan uw SLO-doelstellingen, is de metriek die de brute throughput verbindt met de daadwerkelijke tevredenheid van de gebruikers.

6. KV cache: de bottleneck achter de meeste andere bottlenecks

Tijdens de autoregressieve generatie houdt elk nieuwe token rekening met alle voorgaande token. De KV cache slaat de Key- en Value-projecties van elke token op elke laag op, zodat er geen $O(n^2)$-dure herberekening nodig is. Zonder deze structuur zou het genereren van token voor $n$ instellingen vereisen dat de model opnieuw wordt uitgevoerd voor alle $n-1$ voorgaande tokens.

De KV cache vormt meestal de belangrijkste oorzaak van geheugenpressie, aangezien deze lineair toeneemt naarmate de sequentielengte, batchgrootte en het aantal lagen toenemen:

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{bytes}$

waar:

• $L$ = aantal lagen
• $h_{kv}$ = aantal KV-koppen
• $d_h$ = dimensie van de kop
• $s$ = lengte van de sequentie
• $B$ = batchgrootte

Concreet voorbeeld met FP16 en een batchgrootte van 1: Llama 3 8B bij 8.192 tokens gebruikt ongeveer 1,0 GB aan KV cache; bij 128K tokens is dat 16 GB. Llama 3 70B heeft bij 128K tokens ongeveer 40 GB nodig voor één enkele sequentie, wat de helft is van de VRAM van een H100. Bij productiebatchgroottes overschrijdt KV cache gemakkelijk de model weight aan beschikbare geheugenruimte. Naïeve implementaties verspillen door fragmentatie 60–80% van het toegewezen KV-geheugen, wat het kernprobleem vormt. PagedAttention is ontworpen om dit probleem op te lossen.

De belangrijkste optimalisaties zijn GQA (minder KV-koppen), KV cache quantization (FP8/INT8), PagedAttention (blokgebaseerde toewijzing met <4% afval), en het overdragen van KV cache naar CPU of NVMe.

7. Prefill versus decode: twee fasen, twee bottlenecks

De prefill-fase verwerkt de invoer prompt parallel en vult de KV cache op. De grote matrixvermenigvuldigingen maken deze fase rekenintensief, waardoor prefill grotendeels bepaalt wanneer de eerste token wordt berekend (TTFT). De decode-fase genereert één token per keer. Bij elke stap worden de model weights en de KV cache gelezen uit HBM, het maken van decode tot een beperking door de geheugenbandbreedte, wat de belangrijkste oorzaak is van de tijd per uitvoer token (TPOT).

Geblokkeerde prefill-verdelingen splitsen de prompt op in blokken van vaste grootte chunks (bijvoorbeeld 512 tokens), in plaats van deze allemaal tegelijk te verwerken. Een lange prefill blokkeert niet langer lopende decode-aanvragen, en rekenwerk en geheugenintensief werk worden samen gepland op dezelfde GPU, waardoor vLLM benchmarks een +50% throughput-verbetering laten zien.Agrawal et al., 2024). De kosten voor de nieuwe aanvraag zijn iets hoger, TTFT.

Gescheiden serving plaatst prefill en decode in aparte GPU pools, zodat elke pool kan worden ingesteld op een andere bottleneck. Splitwise en DistServe Beschrijf het patroon. De pools overdragen KV-cachegegevens via een snelle interconnect, zoals RDMA, Hierdoor wordt de communicatiekost onderdeel van het ontwerp.

8. GQA en MQA: het verkleinen van KV cache

Standaard Meerhoofdige Attention (MHA) Elke query-head krijgt zijn eigen K- en V-head. Meervoudige query’s Attention (MQA) Er wordt één enkele KV-head gedeeld tussen alle query-heads, wat een zeer grote vermindering betekent. Gegroepeerde query Attention (GQA) Dit vormt de praktische compromisoplossing: groepen query-heads delen één enkele KV-head.

Llama 3 70B maakt gebruik van 64 query-heads, maar slechts 8 KV-heads, wat neerkomt op een 8x KV cache vermindering ten opzichte van dezelfde architectuur waarbij er één KV-head per query-head is. Llama 3.1 405B gebruikt 128 query-heads en 8 KV-heads, wat volgens dezelfde berekening resulteert in een 16x vermindering.Meta, 2024). Ainslie en collega’s melden dat de kwaliteit van GQA dicht bij die van MHA ligt in hun geteste models, terwijl de snelheid zich nadert aan MQA. Een kleinere KV cache kan grotere batches verwerken, maar de behaalde verbeteringen op het gebied van latency en throughput hangen nog steeds af van de kernel en de werklast.

9. Quantization: het ruilen van bits voor snelheid en geheugen

Quantization verlaagt de precisie van model weights en/of activations. De belangrijkste afwegingen:

AWQ (Activation-Aware Weight Quantization) identificeert het <1% van de opvallende weights door te kijken naar de groottes van activation en past schaling per kanaal toe om deze te beschermen. Het heeft slechts 128–1.024 calibration tokens nodig en won de MLSys 2024 Best Paper Award. GPTQ Gebruikt informatie uit de tweede-orde Hessian voor laagsgewijze quantization en heeft meer calibration data nodig. bitsandbytes De bibliotheek van Tim Dettmers voert tijdens het laden via model quantisatie uit zonder een aparte voorverwerkingsstap; zijn NF4-formaat draagt bij aan QLoRA fine-tuning. FP8 op hardware van het Hopper-type vermindert het gebruikte geheugen met respectievelijk weight ten opzichte van FP16/BF16, maar de kwaliteit en snelheid hangen nog steeds af van de model, calibration en kernel.

De serving kernel kan even belangrijk zijn als de quantization-algoritme. In de vergeleking die hier wordt besproken Section 10, Dezelfde gequantificeerde weights verschillen met 2,6 keer in throughput** binnen kernels.

Deel III — optimalisaties van Inference

Dit gedeelte gaat over de softwaretechnieken die een functionerend inference-systeem omtoveren in een snel systeem. Elke techniek is gericht op een specifiek bottleneck: FlashAttention maakt gebruik van het SRAM-HBM verschil, PagedAttention verwijdert KV cache-fragmentatie, en continuous batching houdt de GPU bezig.

10. Fusie van CUDA kernels en kernel

Een CUDA kernel is een functie die is geschreven voor de GPU en die parallel wordt uitgevoerd over duizenden threads. Wanneer de CPU een kernel aanroept, verdeelt de GPU het werk over deze threads. SM’s: Elke SM voert meerdere warps uit met 32 threads per warp, en elke thread verwerkt een deel van de gegevens. Elke operatie in LLM inference, van matrixvermenigvuldiging tot token-sampling, is uiteindelijk een kernel-startopdracht. Eén enkele forward pass door een 70B model zorgt voor honderden tot duizenden kernel-startopdrachten, en het verschil tussen een naïeve kernel-implementatie en een geoptimaliseerde kan bepalen of uw systeem aan zijn latency-SLO’s voldoet.

De belangrijkste kernel categorieën in LLM serving:

• GEMM kernels voor matrixvermenigvuldiging, die zowel de prefill- als de decode-berekeningen domineren.
• Attention kernels zoals FlashAttention, die berekeningen in velden verdelen om binnen beperkingen te blijven. SRAM in plaats van dat er gegevens worden gelekt naar HBM.
• Gefuseerde kernels constructies die meerdere operaties (zoals optellen + layer norm of QKV-projectie) combineren in één enkele uitvoering, zodat de tussentijdse HBM heen-en-weerreizen worden vermeden.
• Stroomsampling kernels technieken die logits omzetten in token ID’s door middel van top-k-, top-p- of temperatuurstroomsampling.

Kernel Kwaliteit is vaak belangrijker dan de quantization algoritme. Hetzelfde INT4-gekwantiseerd weights verstrekt via Marlin Een geoptimaliseerde FP16xINT4 kernel bereikt een snelheid van 712 tokens/s, vergeleken met 276 tokens/s voor de standaardversie GPTQ, wat een 2,6x throughput groter verschil oplevert dankzij een betere GPU benutting. Marlin bereikt dit door asynchrone geheugentoegang en gedeelde geheugenqueues die de Tensor Cores continu van gegevens voorzien, in plaats van te wachten op HBM. Triton Het verlaagt de drempel om aangepaste kernels te schrijven door het programmeren met GPU via Python mogelijk te maken in plaats van rechtstreeks in het ruwe CUDA C++, waardoor optimalisaties op kernel-niveau toegankelijk worden voor ML-engineers en niet alleen voor GPU-specialisten. De meeste optimalisaties die later in dit gedeelte worden besproken (FlashAttention, gefuseerde kernels, PagedAttention) zijn in essentie of betere kernels-methoden of slimme manieren om het starten van kernel te coördineren.

Kernel Fusion combineert sequentiële operaties tot één GPU kernel en slaat de tussentijdse HBM opslagen over. Veel voorkomende vormen van fusion omvatten QKV-projectie, attention gecombineerd met softmax, en optellen gecombineerd met RMSNorm.FlashNorm), en SwiGLU activation (DeepFusionKernel). Triton Maakt deze kernels toegankelijk via Python. De exacte toename van het aantal uitvoeringen en de verbetering in gebruik hangen af van het model-grafiek, de compiler, GPU en de serving framework, dus profileer de geïmplementeerde stack in plaats van te vertrouwen op een universeel percentage.

11. FlashAttention: het tilen van attention zodat deze in SRAM kan worden opgeslagen

Standaard attention maakt de volledige $N \times N$ attention matrix in HBM tastbaar, waardoor er $O(N^2)$ aan geheugen wordt vereist en er veel geheugentransport optreedt. Het concept achter FlashAttention is om deze matrix helemaal niet tastbaar te maken. Hierbij worden de Q-, K- en V-matrices opgedeeld in blokken die in het beschikbare geheugen passen. SRAM, Er wordt een gedeeltelijke attention berekend binnen elk tile, waarbij de resultaten worden gefuseerd met behulp van een online softmax-algoritme (waarbij het maximale en sommatieve resultaat stapsgewijs per blok wordt bijgehouden). Het geheugenverbruik daalt van $O(N^2)$ naar $O(N)$, en de kosten voor HBM nemen met een factor tien af.

Elke versie is gericht op de bottleneck van zijn GPU generatie:

• FlashAttention v1 (A100, 2022) heeft aangetoond dat het concept van tiling gecombineerd met online-softmax werkt. Er is een 2–4x versnelling ten opzichte van standaard attention, maar de GPU benutting ligt slechts op 25–40%, omdat het kernel-scheduling veel SM’s idle laat. FlashAttention v2 De (A100, 2023)-versie heeft de parallelisatie herwerkt zodat deze zich over de sequentiële dimensie verspreidt in plaats van over batches en heads. Hierdoor werd een 50–73% utilisatie bereikt op de A100, wat ongeveer 2 keer sneller is dan de v1-versie.
• FlashAttention v3 (H100 Hopper, 2024) kent nu een specialisatie voor warp‑structuur (afzonderlijke warps voor gegevensverplaatsing en wiskundige berekeningen) en pipelining van GEMM-softmax, zodat geheugenladingen en berekeningen op elkaar kunnen worden afgestemd. Er wordt een 75–85% benutting van de H100 bereikt en zijn er maximaal ~1,2 PFLOPS beschikbaar in FP8. In het nieuws op NeurIPS 2024. FlashAttention versie 4 (B200 Blackwell, 2026) behandelt een nieuw bottleneck: op Blackwell schalen tensorcore throughput zo snel dat niet-matmul-operaties (softmax-exponentiëlen, rescalen) de beperkende factor worden. De FA4-software emuleert de exponentiële functie met polynoombenaderingen op FMA-eenheden, maakt gebruik van conditioneel rescalen om overhead te verminderen, en slaat tussentijdse resultaten op in Blackwells speciale tensorgeheugen (TMEM) in plaats van in registers. Het resultaat is 1.605 TFLOPS/s op de B200 in BF16, wat 1,3 keer sneller is dan cuDNN 9.13 en 2,7 keer sneller dan Triton.

Bij elke generatie werd een ander hardwarebeperking tegen gekomen, en elke versie van FlashAttention werd vanaf kernel opnieuw ontworpen om deze beperking aan te pakken.

12. FlashDecoding: parallelisering van de decode bottleneck

De standaard FlashAttention houdt de GPU bezig door het werk op te delen over de batch size en de query length. Tijdens decode genereert de model precies 1 token per keer (query length = 1). Als de batch size vermenigvuldigd met het aantal attention heads kleiner is dan het totale SM-aantal van de GPU (108 op een A100), blijven de meeste GPU-eenheden idle, terwijl enkele eenheden sequentieel door de token-geschiedenis werken.

FlashDecoding Het probleem wordt opgelost door een nieuwe dimensie voor parallelisatie toe te voegen: de lengte van de KV-sequentie zelf. Hierdoor wordt de KV cache opgedeeld in kleinere chunks, die vervolgens over alle andersmaal lege GPU processoren worden verspreid om parallel te worden verwerkt. Daarna worden de tijdelijke resultaten samengevoegd met behulp van een log-sum-exp-reductie.

Het resultaat kan tot wel 8 keer beter zijn op end-to-end-niveau. decode versnelling** bij lange sequenties (64K context) en vrijwel constante prestaties decode tijd per token. Genereren token 60.000 stays loopt vrijwel even snel als genereren token 100.

13. Continuous batching versus statische batchverwerking

Statische batchverwerking wacht erop dat elke sequentie in een batch is afgerond voordat de volgende wordt gestart, waardoor korte sequenties na het bereiken van het einde van de sequentie onnodig GPU cycli verspillen door te wachten. Continuous batching (geïntroduceerd door de Orca-paper, (OSDI 2022) werkt op een iteratieniveau: bij elke decode stap worden voltooide sequenties verwijderd en nieuwe sequenties ingevoegd.

Bij Anyscale’s OPT-13B benchmark leverde geoptimaliseerd statisch batchen een prestatieverhoging op van 4 keer ten opzichte van de eenvoudige referentiestandaard, continuous batching bereikte 8 keer, terwijl vLLM in combinatie met continuous batching en PagedAttention een resultaat opleverde van 23 keer.Anyscale, 2023). Continuous batching verhoogt bovendien de druk op de toewijzing van KV-paren, en daarom wordt het vaak gecombineerd met paginair geheugenbeheer.

14. PagedAttention: virtuele geheugen voor KV cache

‘s PagedAttention van vLLM Het toepast het concept van virtuele geheugen van het besturingssysteem op de beheer van KV cache. De KV cache wordt opgedeeld in blokken met een vaste grootte (meestal 16 tokens); deze blokken worden op verzoek toegewezen naarmate tokens worden gegenereerd. Logische (sequentiële) posities worden via bloktabellen gekoppeld aan fysieke (verspreide) geheugelocaties. Meerdere verzoeken die een prefix delen (system prompts, beam search) kunnen naar dezelfde fysieke blokken verwijzen.

Eerdere systemen verspilden 60–80% van de KV cache-geheugenruimte aan fragmentatie en voorafgaande toewijzing. PagedAttention brengt dit terug naar <4%, waardoor throughput zich kan verhogen met 2–4 keer bij dezelfde latency, en zelfs tot 24 keer vergeleken met HuggingFace Transformers.vLLM Blog, 2023).

15. Speculatieve decodering: meerdere tokens per forward pass

Een kleine draft model genereert $K$ kandidaat tokens, waarna de grote target model alle $K$ tokens in één enkele forward pass controleert. Correcte tokens worden geaccepteerd; de eerste onjuiste wordt afgewezen. De kwaliteit van de uitvoer is wiskundig identiek aan die van de target model alleen, waardoor dit een verliesloze versnelling oplevert.

Het werkt omdat LLM decode beperkt wordt door de geheugenbandbreedte: het controleren van $K$ tokens kost ongeveer evenveel tijd als het genereren van 1, aangezien beide alle model weights één keer laden. Typische versnellingen liggen tussen 1,5x en 3x, met methoden zoals EAGLE-3 tot wel 6,5x. Er zijn verschillende varianten beschikbaar Medusa (extra voorspellingsheads, zonder aparte model), prompt-gebaseerde lookup-decodering (vrije n-grammenovereenkomst met de invoer) en EAGLE (extrapolatie op feature-niveau).

Bij hoge batchgrootte kan het extra benodigde ontwerpproces en de verificatiewerkzaamheden de voordelen tenietdoen; een genoemd evaluatierapport rapporteert een vertraging van 1,4–1,8 keer in zulke omstandigheden. Speculatieve decodering is het meest belovend wanneer de serving batch klein genoeg is en de acceptatiegraad van de ontwerpen hoog ligt.

16. Prefix caching en KV cache worden hergebruikt

In plaats van de KV cache weg te gooien zodra een verzoek is afgerond, houdt prefix caching deze bij voor hergebruik in nieuwe verzoeken die dezelfde prefix tokens delen. Hierdoor wordt het overbodige aanmaken van prefill voor system prompts, short-shot voorbeelden, RAG-context en een gespreksgeschiedenis met meerdere turns verminderd.

‘s Automatische Prefix Caching van vLLM Hashes de KV-blokken en maakt gebruik van een globale hash-tabel voor opzoekwerk. SGLang’s RadixAttention Het behoudt een radixboom van gecacheerde KV-tensors met een granulariteit op token-niveau. Beide methoden zijn afhankelijk van herhaalde token-identieke prefixen, dus geef de hitratio weer samen met latency of throughput.

17. Streamen in de praktijk

Streamen stuurt tokens naar de client zodra deze zijn gegenereerd, in plaats van te wachten op het volledige antwoord. Veel serving frameworks maken dit beschikbaar via Server-Sent Events: de client opent een langlevende HTTP-verbinding, en de server stuurt elke token of token batch als data: Gebeurtenis. TTFT bepaalt wanneer de gebruiker voor het eerst output ziet; TPOT helpt bij het bepalen van de soepelheid van de ervaring. Stel het doel in door middel van producttesten en de gekozen interactiemethode model.

Aan de kant van de client forceert streaming beslissingen met betrekking tot buffering. Het weergeven van token door token kan leiden tot visuele trillingen, vooral bij markdown of codeblokken die meerdere token contexten nodig hebben om correct te worden geformateerd. Veelvoorkomende patronen zijn buffering op woordniveau (het accumuleren van tokens tot aan een witruimtegrens), buffering op regelniveau (wachten op een nieuwe regel voordat er wordt weergegeven) en adaptieve buffering (onmiddellijk weergeven voor proza, maar buffering voor codeblokken). stream_options: {"include_usage": true} De parameter in OpenAI-compatibele APIs geeft in het eindresultaat van de SSE-evenementen token-aantallen weer, waardoor een nauwkeurige kostenregistratie van gestreamde responsen mogelijk is.

Geblokkeerde prefill Dit is wat ervoor zorgt dat streaming onder belasting standhoudt. Zonder dit kan één lange prefill de token levering vertragen voor alle andere gelijktijdig gebruikende gebruikers.

Deel IV — Model-architectuur

Hoe LLMs worden gebouwd: de transformer-blok, tokenization, omgang met context, en de architectonische varianten die uiteindelijk de standaard werden. Deze elementen vormen de basis zowel voor inference als voor het trainen.

18. Belangrijkste aspecten van de Transformer-architectuur

Een moderne decoder-only transformer (zoals GPT en Llama) bestaat uit een stapel identieke lagen, waarbij elke laag twee subblokken bevat: attention en feed-forward. Elk subblok is omgeven door een residuele verbinding en normalisatie. De belangrijkste componenten zijn:

Multi-Head Attention — het mechanisme dat het mogelijk maakt voor elke token om naar alle andere token te kijken om te bepalen wat relevant is. De invoer wordt geprojecteerd in drie matrices: Queries (waar ben ik naar op zoek?), Keys (wat bevat ik?) en Values (welke informatie draag ik bij me?). Vervolgens worden de Attention-scores berekend als volgt:

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

Het schaalproduct $QK^T$ meet de gelijkenis tussen elk paar tokens. Door te delen door $\sqrt{d_k}$ voorkomt men dat de schaalproducten te groot worden (wat zou ertoe leiden dat de softmax terechtkomt in gebieden met verdwijnende gradienten). De softmax zet de scores om in waarschijnlijkheden, en de vermenigvuldiging met $V$ levert een gewogen combinatie op van waardevectoren. Het uitvoeren hiervan parallel in meerdere heads maakt het mogelijk voor de model om tegelijkertijd aandacht te besteden aan verschillende relaties (één head voor syntaxis, een andere voor coreferentie, enzovoort).

Feed-Forward Network (FFN) — zodra attention heeft bepaald welke tokens relevant zijn, beslist de FFN wat er met die informatie moet gebeuren. Moderne LLMs implementaties gebruiken SwiGLU in plaats van de oorspronkelijke twee-matige ReLU FFN:

$\text{SwiGLU}(x) = \text{Swish}(xW_1) \otimes xW_2$

SwiGLU maakt gebruik van drie weight-matrices in plaats van twee, en van een soepele Swish activation in plaats van ReLU. Het wordt toegepast door model-families zoals Llama, Mistral, Qwen en Gemma. De FFN beslaat doorgaans ongeveer twee derde van de totale model-parameters, hoewel het exacte aandeel afhankelijk is van de architectuur.

Residuele verbindingen — elke subblok voegt zijn uitvoer weer toe aan zijn invoer: $\text{Uitvoer} = \text{Invoer} + \text{Sublaag}(\text{Invoer})$. Zonder deze sprongverbinding verdwijnen de gradienten bij backpropagatie door 80–128 lagen. De residu creëert een pad waardoor informatie en gradienten rechtstreeks van vroege lagen naar latere lagen kunnen stromen.

RMSNorm — komt veel voor in moderne LLM-families. LayerNorm normaliseert door het gegeven materiaal opnieuw te centreren (door de gemiddelde waarde af te trekken) en opnieuw te schalen (door te delen door de standaardafwijking). RMS-norm Het stelt de aftrek van het gemiddelde uit en schaalt enkel opnieuw in; het bijbehorende artikel rapporteert 7–64% snelheidsverbeteringen bij alle geteste models, zonder dat dit negatieve gevolgen heeft voor de prestaties in die experimenten. Een pre-normalisatie-strategie, waarbij normalisatie eerst plaatsvindt vóór attention of de FFN, komt eveneens veel voor, omdat deze de stabiliteit van de gradients verbetert.

Schatting van het aantal parameters voor een decoder alleen model:

$\text{Totaal} \approx V \times d + 12 \times L \times d^2$

Waarbij $V$ de grootte van het woordenschat is, $d$ de verborgen dimensie en $L$ het aantal lagen. De term $V \times d$ staat voor de invoer embedding-matrix; de term $12 \times d^2$ benadert de attention-structuren en FFN weights-modules in elke laag. Voor Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$) bedraagt de geschatte waarde ongeveer $0{,}53B + 6{,}44B = 6{,}97B$ parameters. De gepubliceerde totale waarde van 8,03B is hoger, omdat deze benadering architectonische details zoals de exacte breedte van de FFN en de afzonderlijke uitvoerprojectie weglaat.

19. Waarom decoder-gebaseerde architecturen domineren

De oorspronkelijke versie Transformer In (2017) beschikte het model zowel over een encoder als over een decoder. Sindsdien is het veld opgesplitst in drie architectuurfamilies, waarvan één de standaard is geworden voor generatieve AI.

Alleen encoder models (BERT, RoBERTa) maken gebruik van bidirectionele attention: elke token houdt rekening met elke andere token in beide richtingen. Dit levert rijke representaties op voor begripstaakken (classificatie, NER, semantische similariteit), maar het is niet mogelijk om tekst op autoregressieve manier te genereren. Alleen-encodermodellen models blijven de dominante keuze als kerncomponent voor embedding models, rerankers, en lichte classificatoren (bijvoorbeeld de op BERT gebaseerde routers) RouteLLM).

Encoder-decoder models (T5, BART, de oorspronkelijke Transformer) scheidt het begrijpen van het genereren. De encoder verwerkt de volledige invoer met bidirectionele attention, waarna de decoder de uitvoer autoregressief genereert terwijl hij rekening houdt met de representaties van de encoder via cross-attention. Dit bood een natuurlijk voordeel voor sequence-to-sequence-taken zoals vertaling, waarbij invoer en uitvoer fundamenteel verschillende sequenties zijn. Google’s T5 toonde aan dat elke NLP-taak als text-to-text kan worden geformuleerd, en encoder-decoder models wordt nog steeds gebruikt in sommige gespecialiseerde systemen (zoals Whisper voor spraakherkenning en FLAN-T5 voor instructievolging).

Alleen decoder models (GPT, Llama, Mistral, Gemini) maakt gebruik van causale (eenrichtings-) attention relatieën: elke token let alleen op de voorgaande tokens elementen. Ze formuleren alles als een voorspelling voor het volgende token element: de “invoer” vormt het begin van de sequentie en de “uitvoer” is de vervolging daarvan. Er zijn vier redenen waarom deze architectuur de overhand heeft gekregen:

1. KV cache efficiëntie. De KV cache uit de vorige tokens blijft geldig zodra er nieuwe tokens worden gegenereerd, zodat u deze nooit hoeft te verwerpen of opnieuw te berekenen. Encoder-decoder models moeten twee aparte attention caches bijhouden (self-attention plus cross-attention voor de encoder-output), wat leidt tot extra geheugenbelasting en architectonische complexiteit.

2. Eenvoud van training. Het trainingsdoel bestaat uit een eenvoudige voorspelling van het volgende token op ruwe tekst. Er is geen gepaard gebracht invoer-/uitvoerdata nodig (zoals bij vertaling models), noch gemaasde token reconstructie (zoals BERT vereist). Je kunt trainen met vrijwel elke tekst uit het internet, boeken en code, zonder speciale voorverwerking – wat een enorm voordeel is wanneer je de hoeveelheid data uitbreidt tot triljoenen tokens.

3. Architectonische eenvoud. Één module doet alles: dezelfde transformer-blok, herhaald $L$ keren. Geen encoder-decoder cross-attention lagen, geen aparte encoder-stapel. Hierdoor zijn parallelismestrategieën eenvoudiger toe te passen (Sectie 33), en verkleint daarmee het te optimaliseren technische domein. FlashAttention, quantization, en speculatieve decodering hoeven slechts één attention-patroon te bestrijken.

4. In-context learning. Decoder-only models modellen zijn van nature zeer geschikt voor few-shot learning, aangezien voorbeelden, instructies en de query allemaal tokens voorkomen in dezelfde sequentie. De model maakt geen onderscheid tussen “input” en “output”; hij voorspelt de volgende token op basis van alles wat eraan voorafgaat. GPT-3 toonde dit voor het eerst op grote schaal, waardoor decoder-only models modellen een uitstekende keuze werden voor de rol van alomtegenwoordige assistent.

20. Mengeling van experts

MoE vervangt de dichte FFN in elke transformerlaag door meerdere kleinere expert FFNs in combinatie met een lichtgewicht gating router. De router berekent een score voor elk expert (meestal een softmax op basis van geleerde lineaire projecties) en selecteert de beste $k$ experts volgens token. Alleen de geactiveerde experts worden verwerkt, zodat een model een enorme totale capaciteit kan hebben zonder dat de kosten per token hoog uitvallen. Dit is sparselijke conditionele verwerking: de totale parameters bepalen wat de model kan weergeven, terwijl de actieve parameters bepalen wat de uitvoeringskosten zijn.

De gedeelde expert in DeepSeek-V3 wordt geactiveerd voor elke token. Hij levert een basisrepresentatie die de gerouteerde experts kunnen gebruiken om zich verder te specialiseren.

Bij het trainen van MoE komen drie terugkerende problemen voor: belastingonevenwicht, expertkolaps en communicatie-overhead. expertparallelisme. Traditionele MoE models-methoden voegen een hulploss toe om onevenwichtige routing-situaties te bestraffen, maar deze loss kan concurreren met het hoofddoel. DeepSeek-V3 In plaats daarvan maakt het systeem gebruik van bias-termen buiten de backpropagatie: het verlaagt de score van overbelaste experts en verhoogt de score van ondergebruikte experts. Het artikel rapporteert een betere routing balans zonder de afweging met behulp van een hulploss in de opzet.

21. Tokenization: BPE, SentencePiece en tiktoken

LLMs Zij zien geen tekst, maar sequenties van gehelegetal token IDs. Een tokenizer splitst de ruwe tekst op in tokens (subwoordfragmenten) en koppelt elk daarvan aan een ID. De keuze voor de tokenizer heeft invloed op de kwaliteit van model, de snelheid van inference en de gelijkwaardigheid bij meertalige toepassingen.

Byte Pair Encoding (BPE) Dit is de gangbare algoritme. Het fuseert iteratief de meest voorkomende aangrenzende paren in het trainingscorpus. Een vereenvoudigd voorbeeld:

1. Begin met een woordenschat op karakterniveau: [l, o, w, e, r, _]
2. Het meest voorkomende paar is (l, o) → samenvoegen met lo → Woordenschat: [l, o, w, e, r, _, lo]
3. Het op een na meest voorkomende paar is (lo, w) → samenvoegen met low → Het woordenboek wordt uitgebreid. low
4. Ga door totdat het woordenschatgrootte het gewenste niveau heeft bereikt (bijv. 128K tokens)

Alledaagse woorden zoals “the” worden omgezet in één tokens, terwijl zeldzame woorden zoals “defenestration” worden opgesplitst in subwoordfragmenten. ["def", "en", "est", "ration"]De afweging betreft de omvang van het woordenboek versus de lengte van de sequentie.

Drie implementaties van tokenizer dekken het grootste deel van de productiegebruikssituaties:

• SentencePiece het behandelt de invoer als een ruwe bytestroom zonder taalspecifieke voorverwerking (geen voorverwerking door tokenization zoals spaties of interpunctie), waardoor het taalonafhankelijk is en dit van groot belang is voor niet-Latijnse schriften. Het ondersteunt zowel BPE als unigrammen. Het wordt gebruikt door Llama 1/2, T5 en Mistral. tiktoken Is OpenAI’s op Rust gebaseerde tokenizer gebruikmakend van byte-niveau BPE? Zijn gecompileerde Rust-core is 3–6 keer sneller dan alternatieven die op Python zijn gebaseerd. Llama 3 is overgestapt van SentencePiece naar de algoritme van tiktoken.
• Hugging Face Tokenizers Het is een veelgebruikte bibliotheek gebaseerd op Rust die BPE, WordPiece en Unigram ondersteunt.

De omvang van de woordenschat is gestaag toegenomen, met belangrijke gevolgen voor de efficiëntie:

Fertility (tokens per woord) geeft de compressie-efficiëntie weer. Hoe lager, hoe beter: minder tokens betekent kortere sequenties, lagere kosten en meer inhoud die past in de context window. In het Engels ligt dit doorgaans rond de 1,0–1,3 tokens per woord, maar niet-Latijnse schriften (Chinees, Japans, Koreaans, Arabisch) kunnen 2–4 keer hoger zijn wanneer er een Engels-gerichte woordenschat wordt gebruikt. Dezelfde inhoud kost 2–4 keer meer in tokens voor gebruikers die geen Engels spreken, wat een blijvend probleem op het gebied van gelijkheid is dat alleen gedeeltelijk kan worden opgelost door grotere, meer gevarieerde woordenschappen.

22. Context windows en positionele coderingen

De context window geeft het maximale aantal tokens aan dat een model in één enkele forward pass kan verwerken. Deze waarde is aanzienlijk gestegen:

Er is hier een fundamenteel probleem: het attention-mechanisme behandelt de invoer als een verzameling, en niet als een sequentie. Het beschikt niet over een ingebouwd concept van woordvolgorde. Zonder positie-informatie zouden zinnen als “de kat zat op de mat” en “de mat zat op de kat” tot identieke representaties leiden. Positieve coderingen voegen juist deze volgorde toe, zodat het model weet waar elke token zich bevindt.

Drie veelvoorkomende benaderingen zijn:

• RoPE (Rotatiepositie Embeddings) codeert de positie van elke token door diens query- en key-vectoren te draaien met een hoek die evenredig is met de positie. Tokens die dicht bij elkaar liggen ondergaan vergelijkbare rotaties, waardoor hun schaalproduct (attention-score) hoog blijft. Tokens die ver uit elkaar liggen ondergaan zeer verschillende rotaties, wat de relatieve afstand weergeeft. RoPE is het standaardmodel voor bijna alle moderne open LLMs-modellen (Llama, Mistral, Qwen), omdat het relatieve posities goed kan verwerken en bovendien weinig rekenkracht vereist.

• ALiBi Met (Attention en lineaire biases) worden embedding-aanpassingen genegeerd en wordt er direct een straf toegevoegd aan de scores van attention: hoe groter de afstand tussen twee tokens is, des te groter is de negatieve bias. Er zijn geen aangeleerde parameters nodig en er vindt geen extra berekening plaats. Dit maakt het mogelijk om enige extrapolatie te doen buiten de trainingslengte, maar de prestaties verslechteren aanzienlijk bij een trainingscontext die 2 keer of meer is dan de oorspronkelijke.

• YaRN (Een nog andere RoPE-uitbreiding) breidt de mogelijkheden van RoPE model uit buiten zijn oorspronkelijke trainingscontext. Hierbij worden frequentie‑dimensies in drie categorieën ingedeeld, waarvan elke categorie op een andere manier wordt geschaald. Het artikel rapporteert 10 keer minder fine-tuning tokens en 2,5 keer minder trainingsstappen vergeleken met de baseline die gebruikmaakt van positie‑interpolatie.

Deel V — Trainen en aligneren

Training vormt de basis waarop capaciteiten worden opgebouwd. Dit gedeelte behandelt pretraining, efficiënte fine-tuning (LoRA, gemengde precisie), schaalwetten en aligneringsmethoden.

23. Pretraining, fine-tuning, en alignement

Pretraining betreft zelfgesuperviseerde voorspelling van de volgende token stap op een groot corpus. De benodigde rekenkracht hiervoor is spans vele ordes van grootte hoger; Llama 3 405B, Bijvoorbeeld wordt er gebruik gemaakt van $3{,}8 \times 10^{25}$ FLOPs. Gebonden fine-tuning (SFT) past de vooraf getrainde model aan op taakspecifieke, gelabelde gegevens. RLHF / RLAIF maakt gebruik van voorkeursgegevens om gedrag vorm te geven: een conventionele RLHF pipeline verzamelt vergelijkingen, traint een beloningsfunctie model en optimaliseert vervolgens het beleid. RLAIF vervangt sommige menselijke oordelen door feedback die is gegenereerd met AI.

De berekening is afhankelijk van de grootte van model, de lengte van de sequentie, het datavolume, de optimizer en de methode. PPO bevat bovendien meer model-toestanden dan SFT, omdat een typische configuratie een policy, referentie, beloning en critic models omvat. Ik heb de volledige fine-tuning-beslissingsproces framework behandeld in LLM Fine-Tuning Gids.

24. LoRA en QLoRA: parameter-efficiënt fine-tuning

LoRA Het vriest de voorverwerkte weights in en injecteert traintbare lage-rangmatrices $A$ ($r \times k$) en $B$ ($d \times r$), zodat de bijgewerkte weight gelijk is aan $W_0 + BA$. In het artikel over LoRA werd GPT-3 175B in de beschreven configuratie teruggebracht tot ongeveer 18 miljoen traintbare parameters. De rang is een afstelmingsparameter en geen regel die de complexiteit van een taak bepaalt; deze moet worden geselecteerd door middel van een kwaliteits- en geheugenscan. Na de training kunnen LoRA adapters worden geïntegreerd in de basis weights, om zo een aparte adapterweg bij inference te vermijden.

QLoRA Tijdens het trainen van LoRA adapters in BF16 wordt de basis model geladen in 4-bit NF4 quantization. NormalFloat4 plaatst meer quantization waarden dicht bij nul, waar de weight dichtheid het hoogst is. In het artikel werd een 65B model op één enkele 48 GB GPU gefine-tuned, met resultaten die dicht in de buurt lagen van de resultaten van de 16-bit baselines. De balans tussen de runtime en het geheugenverbruik is specifiek voor de geteste technologiestack.

25. Trainen met gemengde precisie

Elk format voor getallen met vlotkomma verdeelt zijn bits over drie onderdelen: teken (altijd 1 bit), exponent (die de dynamische bereik bepaalt) en mantisse (die de precisie bepaalt). Meer bits voor de exponent zorgen voor een groter bereik aan representeerbare waarden; meer bits voor de mantisse maken het mogelijk om nauwkeuriger onderscheid te maken tussen naburige waarden. Gehelegetalformaten hebben helemaal geen exponent en weergeven alleen gelijkmatig gespreide gehele getallen binnen een vast bereik.

BF16 heeft dezelfde bereik als FP32, aangezien het bereik wordt bepaald door het exponentieveld. BF16 behoudt bovendien alle 8 exponentiebitjes van FP32. In plaats daarvan worden er mantissabitjes opgeofferd (7 tegenover 23), waardoor de precisie wordt opgeofferd ten gunste van een halvering van het geheugenverbruik, terwijl tegelijkertijd de problemen met overflow en underflow die voorkomen bij het trainen van FP16 worden vermeden. FP16 beschikt slechts over 5 exponentiebitjes, waardoor zijn bereik wordt begrensd tot ongeveer 65K. Gradienten overschrijden dit bereik regelmatig, en daarom heeft het trainen van FP16 verliesschaling nodig: het verlies moet eerst worden vermenigvuldigd met een grote constante vóór de backpropagatie, om daarna de gradienten te delen. BF16 maakt verliesschaling overbodig.

Gehelegetallenformaten komen zelden voor in de hoofdtrainingsrekeningen, omdat backpropagatie een grote dynamische bereik vereist. Ze worden wel veel gebruikt voor inference, waarbij gefroren weights-waarden kunnen worden gekoppeld aan gecalibreerde schalen. INT4, weight en quantization zorgen ervoor dat een 7B grote model-model van ongeveer 14 GB wordt teruggebracht tot 3,5 GB, rekening houdend met de bijkomende kosten van runtime; de kwaliteit moet worden geëvalueerd op basis van de gekozen model en methode.

FP8 training op de H100 via Transformer-engine Het systeem maakt gebruik van E4M3 wanneer precisie cruciaal is, en van E5M2 wanneer een groter bereik vereist is. Volgens NVIDIA leidt dit tot een snelheidstoename van tot wel 75% in vergelijking met conventionele oplossingen, gemeten in een geteste configuratie met 175 miljard parameters. DeepSeek-V3 Voor de laatste trainingsrun werd FP8 met gemengde precisie gebruikt, waardoor er ongeveer 5,6 miljoen dollar aan rekenkracht werd verbruikt die gelijkstaat aan huurkosten, exclusief uitgaven voor onderzoek en ontwikkeling en infrastructuur.

26. Gradient checkpointing

Elk laagje van de forward pass genereert een tussentijds resultaat dat een activation wordt genoemd:

$\text{Invoer} \rightarrow [\text{Laag 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Laag 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Laag 3}] \rightarrow \text{uitvoer}$

Doorgaans moeten alle activations in het geheugen blijven, omdat backpropagatie ze nodig heeft om gradienten te berekenen. Bij een diepe transformer kan de opgeslagen activations meer geheugen in beslag nemen dan de model weights zelf.

Gradient checkpointing biedt een compromis tussen rekenkracht en geheugen door het grootste deel van die activations weg te gooien en ze op het moment van backpropagation opnieuw te berekenen. De standaardstrategie (Chen e.a., 2016) Het verdeelt een netwerk met $n$ lagen in $\sqrt{n}$ gelijkmatig gespreide segmenten en slaat alleen de grens activation van elk segment op. Deze opgeslagen grenzen vormen de “checkpoints.” Alle intermediëre activations binnen een segment worden onmiddellijk weggelaten.

Wanneer de backward pass een laag binnen een segment bereikt, worden de activations opnieuw berekend aan de hand van de dichtstbijzijnde checkpoint. Hierdoor daalt het gebruik van activation geheugen van $O(n)$ naar $O(\sqrt{n})$, wat in de praktijk leidt tot een vermindering van 60–70%, ten koste van ongeveer één extra forward pass (ongeveer 20–33% meer rekenwerk). FlashAttention past hetzelfde principe toe binnen attention door de volledige attention matrix niet te materialiseren. Schakel dit in HuggingFace in met gradient_checkpointing=True.

27. DeepSpeed ZeRO-fasen

Bij standaard dataparalleliteit bevat elke GPU een volledige kopie van de model weights, de gradients en de toestandsinformatie van de optimizer. Voor Adam neemt elk parameter 2 bytes in beslag voor de FP16 weight, 4 bytes voor de FP32 master weight, 4 bytes voor de momentum, 4 bytes voor de variatie en 2 bytes voor de gradient – dit levert 16 bytes per parameter op. Een model met 7,5 miljard parameters heeft ongeveer 120 GB nodig per GPU, en elke GPU bevat dezelfde informatie. Op 64 GPUs betekent dit dus 64 identieke kopieën van 120 GB elk. Dat is aanzienlijke verspilling.

DeepSpeed ZeRO (Zero Redundancy Optimizer) verwijdert deze duplicatie door deze componenten over GPUs te verspreiden in plaats van ze te repliceren:

• Fase 1 — optimalisatorenstaten worden ook opgedeeld. Elke GPU slaat slechts 1/N van de optimalisatorenstaten op (de momentum- en variantiewaarden van Adam, 8 bytes/per parameter). Wanneer een GPU een weight moet bijwerken, wordt alleen diens desbetreffende deel bijgewerkt en wordt het resultaat verspreid. Hierdoor daalt het geheugenverbruik van ongeveer 120 GB naar ongeveer 31 GB per GPU.
• Fase 2 — gradiënten worden eveneens opgedeeld. De gradiënten (2 bytes/per parameter) hoeven niet langer volledig naar elke GPU te worden verzonden. Elke GPU ontvangt enkel het benodigde deel van de gradiënten via de reduce-scatter-methode. Het geheugenverbruik daalt hierdoor tot ongeveer 16 GB per GPU.
• Fase 3 — de model weights wordt ook opgedeeld. Elke GPU bevat slechts 1/N van de FP16 weights. Vóór de forward- of backward-pass van een laag roept de GPU de all-gather-functie aan om tijdelijk de volledige laag weights te reconstrueren aan de hand van alle andere GPUs, berekent deze en gooit de verzamelde weights vervolgens weg. Hierdoor daalt het geheugenverbruik tot ongeveer 1,9 GB per GPU.

De afweging ligt bij de communicatie. Fase 1 levert minimale overhead op, fase 2 vervangt all-reduce door reduce-scatter (met een vergelijkbare kostenstructuur), maar fase 3 vereist all-gather-oproepen vóór elke laag zowel tijdens de voorwaartse als achterwaartse berekeningen, wat resulteert in ongeveer 1,5 keer zoveel communicatieverkeer vergeleken met standaard data parallelism.

ZeRO-Infinity Stage 3 wordt uitgebreid door gepartitioneerde toestanden op te slaan in CPU RAM en zelfs NVMe SSD’s, waardoor het trainen van models met biljoenen parameters mogelijk wordt op beperkte GPU clusters. Het nadeel is een grote daling van de snelheid (NVMe is ongeveer 500 keer langzamer dan HBM), dus ZeRO-Infinity wordt gebruikt wanneer de model echt niet past in de GPU + CPU geheugenruimte.

28. FSDP: PyTorch-gebaseerd op native sharding

Volledig geschaard data-parallel (FSDP) Het is het ingebouwde antwoord van PyTorch op DeepSpeed ZeRO-3. Het verdeelt parameters, gradients en optimizer-toestanden over GPUs volgens hetzelfde fundamentele principe. De werking per laag bestaat uit een eenvoudige lus:

1. Voer een all-gather uit om alle parameters van alle GPUs bijeen te brengen (reconstrueer tijdelijk de volledige laag).
2. Bereken de forward- of backward-pass voor die laag.
3. Maak de verzamelde parameters onmiddellijk vrij. Elke GPU bewaart alleen zijn eigen deel.
4. Voer een reduce-scatter uit op de gradients zodat elke GPU alleen zijn toegewezen gradient-slice ontvangt.

Aangezien FSDP inherent is aan PyTorch, integreert het zich direct met de debuggereertools, profielscanners en PyTorch van dit platform. torch.compile. De prestaties ten opzichte van DeepSpeed ZeRO-3 hangen af van de wrapping-politiek, de communicatietopologie, de offload-instellingen en de grootte van model; vergelijk ze daarom op dezelfde cluster.

FSDP2 (2024–2025) is een herschrijving die de prestaties verbetert. torch.compile Integratie voor een betere kernel fusie, met toevoeging van FP8 trainingsondersteuning via TorchAO, en vereenvoudigt de API. Zowel FSDP als DeepSpeed zijn toegankelijk via HuggingFace Accelerate, wat het mogelijk maakt om tussen hen over te schakelen met slechts één configuratiewijziging.

29. Schaalwetten en de Chinchilla-val

Chinchilla-scaling (DeepMind, 2022) ontdekte onder de gestelde aannames een rekenkrachtig optimale verdeling van ongeveer 20 trainings tokens per parameter. Dat doelstelling omvat niet de bijbehorende kosten van downstream serving. Als een kleinere model die is getraind op meer gegevens de vereiste kwaliteit bereikt, kan dit op de lange termijn minder kostbaar zijn tijdens een grootschalig inference levenscyclus.

De oplossing is om kleinere models-modellen te overtrainen met een stuk grotere hoeveelheid gegevens. De vooruitgang is opvallend:

Voor een model die in grote hoeveelheden wordt geleverd, kan het investeren in meer rekenkracht voor een kleinere model de levenscycluskosten verlagen. Llama 3 8B illustreert deze strategie, maar of deze werkelijk voordelig is, hangt af van de vereiste kwaliteit en de verwachte inference-omvang. “Chinchilla-optimal” duidt op de efficiëntie van de gebruikte rekenkracht tijdens het trainen, wat een ander doel is dan de minimisatie van de levenscycluskosten.

30. RLHF, DPO, GRPO, en het aligneringslandschap

Alignment stuurt een vooraf getrainde model richting de gewenste instructies, voorkeuren en veiligheidsrichtlijnen. Het garandeert op zichzelf noch waarheidsgetrouwheid noch veilig gedrag. De hieronder beschreven methoden bieden een afweging tussen implementatiecomplexiteit, gegevensvereisten, exploratie en trainingsstabiliteit.

De klassieke RLHF pipeline: SFT → verzamelen van menselijke voorkeursparen → trainen van een belonings model op die paren → fijnafstellen van het beleid met PPO (Proximal Policy Optimization). PPO bewaart tegelijkertijd 4 model kopieën in het geheugen (beleid, referentie, critic/value model, beloning model), is gevoelig voor hyperparameters en vatbaar voor reward hacking, waarbij de model misbruik maakt van bijzonderheden in de beloning model (zoals uitgebreide, zelfverzekerde antwoorden) in plaats van daadwerkelijk de kwaliteit te verbeteren.

DPO (Direct Preference Optimization) omzeilt de geleerde beloning model en de online RL-loop door rechtstreeks een verliesfunctie te optimaliseren op basis van voorkeursparen. Hierdoor wordt het trainen pipeline vereenvoudigd. De standaard DPO-methode is offline: ze traint op een vaste dataset en onderzoekt geen nieuwe reacties tijdens de update-loop. Of deze beperking van belang is, hangt af van de taak en de dekking van de gegevens.

GRPO (Group Relative Policy Optimization, DeepSeek) verwijdert de door PPO geleerde critic door meerdere voltooieningen per prompt te genereren en groepsgewijze relatieve beloningen als basis te gebruiken. Hierdoor wordt de last van de model-toestand verminderd ten opzichte van een typische PPO-inrichting. In tegenstelling tot DPO is GRPO on-policy: de model genereert tijdens het trainen nieuwe reacties. DeepSeek-R1 Het combineert GRPO met RLVR (versterkingsleren op basis van te verifiëren beloningen), waarbij er controle wordt uitgeoefend via onder andere wiskundige antwoorden, compilatie van code en eenheidstests. Deze beloningen zijn eenvoudiger te controleren dan een geleerde voorkeursscore, maar onvolledige tests en vervangende doelstellingen kunnen nog steeds worden misbruikt.

31. Distillatie: het comprimeren van kennis over models

Kennisdistillatie overdraagt capaciteiten van een grote ‘leraar’ naar een kleinere ‘leerling’. Logit-gebaseerde distillatie traint de leerling om de uitvoerverdeling van de leraar na te bootsen. Gegevensgebaseerde distillatie laat de leraar voorbeelden genereren die de leerling verder kan afstemmen. Gegevensgebaseerde methoden worden vaak gebruikt voor LLMs, omdat ze werken ongeacht de architectuur en zelfs met leraars die alleen API gebruiken. Hun effectiviteit wordt echter beperkt door de kwaliteit van de leraar, de dekking van de gegevens, het filteren en de kosten van generatie.

DeepSeek-R1 Er zijn 800.000 reasoning voorbeelden gegenereerd en gebruikt om Qwen2.5 en Llama 3 models te ontwikkelen, waarbij het aantal parameters werd verhoogd van 1,5 miljard naar 70 miljard. Volgens de evaluatie in het artikel:

• DeepSeek-R1-Distill-Qwen-32B behaalt 72,6% op AIME 2024 en 94,3% op MATH-500, wat hoger is dan de door het onderzoek gerapporteerde cijfers voor OpenAI o1-mini.
• DeepSeek-R1-Distill-Qwen-7B scoort 55,5% op AIME 2024, wat ook hoger ligt dan het resultaat van QwQ-32B-Preview uit hetzelfde onderzoek, met een kleiner model.

In de kleine experimenten met DeepSeek-R1-model bleek distillatie beter te presteren dan directe GRPO op de geteste basismodelle models. Dit resultaat ondersteunt het gebruik van distillatie voor deze configuratie; het bepaalt echter geen algemene rangorde tussen distillatie en RL.

32. Generatie van synthetische data

LLM-Gegenereerde trainingsgegevens worden gebruikt in verschillende herhalende patronen:

• Zelf-instructie Het systeem start met een klein beginset aan door mensen geschreven instructies: de LLM genereert nieuwe instructies, invoer en uitvoer, die vervolgens gefilterd worden en opnieuw toegevoegd aan de pool. Alpaca Het project maakte gebruik van 52.000 voorbeelden afkomstig van 175 verschillende bronnen en rapporteerde een generatiekost van ongeveer 600 dollar; de vergelijking met GPT-3.5 vormde slechts een beperkte evaluatie van het project en geen volledige equivalentie.
• Evol-Instruct (WizardLM) neemt bestaande instructies en ontwikkelt deze iteratief langs complexiteitsassen (door beperkingen toe te voegen, reasoning verder te verdiepen en problemen concreter te maken) om steeds moeilijkere trainingsvoorbeelden te genereren.
• Microsoft’s Phi-4** (14B) maakte voor een groot deel gebruik van synthetische gegevens tijdens pretraining, waaronder generatie, evaluatie, zelfherziening en omkering van instructies. Het technische rapport vergelijkt de resulterende prestaties op het gebied van STEM en programmeren met die van grotere models op de geselecteerde benchmarks.

Het risico dat hier van belang is, is model collapsie: wanneer models recursief worden getraind op synthetische gegevens uit eerdere generaties, verdwijnen de uiteinden van de oorspronkelijke verdeling geleidelijk. De model overschat veelvoorkomende patronen en mist zeldzame, maar belangrijke variaties.Shumailov e.a., 2024). Een apart onderzoek van Ahrefs classificeerde 74,2% van de nieuw gemaakte webpagina’s in zijn steekproef van 900.000 pagina’s als tekst die is gegenereerd door AI; dit is een resultaat van een classificatiemethode van de leverancier, en geen volledige inventarisatie van het web. Het verminderen van dit probleem begint met het combineren van synthetische en echte gegevens, filtering en traceerbaarheid van de oorsprong, zodat recursief gegenereerd materiaal kan worden gemeten.

Deel VI — Schalen en deployment

Het schalen van één GPU naar een cluster houdt in dat de werklast over meerdere apparaten wordt verdeeld. Dit gedeelte behandelt strategieën voor parallelisme, serving frameworks, de selectie van GPU en routing.

33. Vier vormen van parallelisme

Tensor Parallelism (TP) verdeelt afzonderlijke weight matrices over GPUs en communiceert doorgaans na elk laagje. Snelle intra-node verbindingen zoals NVLink maken dit zeer praktisch binnen één node. Meer shards verminderen de geheugengebruik en rekenkracht per apparaat, maar verhogen de communicatiekosten; daarom dient men het aantal shards te kiezen op basis van een latency benchmark.

Pipeline Parallelisme (PP) verdeelt lagen sequentieel over GPUs, waarbij activations van het ene stadium naar het andere wordt doorgegeven. Het communicatiepatroon kan worden toegepast tussen nodes, maar pipeline-effecten en ongelijke verwerkingstijden tussen de stadia verminderen de benutting. Grote deployments-systemen combineren vaak TP binnen één node met PP tussen verschillende nodes.

Data Parallelism (DP) maakt kopieën van de serving model zodat elke kopie onafhankelijke verzoeken kan verwerken zonder dat er voor elk verzoek communicatie tussen de verschillende kopieën nodig is. Het is efficiënt wanneer de model voldoende ruimte biedt en het verkeer goed kan worden gebalanceerd. Tijdens het trainen wordt DP vaak gecombineerd met ZeRO of FSDP om de staat op te delen in meerdere delen.

Expert Parallelism (EP) verdeelt MoE experts over GPUs door middel van all-to-all communicatie voor token routing. De prestaties hiervan hangen af van de token balans, de plaatsing van de experts en de topologie van de onderlinge verbindingen; het all-to-all verkeer kan de dominante bottleneck factor worden.

Een heuristiek voor het starten van parallelisme:

• Model past op één GPU: begin met afzonderlijke replicaten en meet de schaling van DP.
• Model past binnen één node: test TP binnen de node en herhaal de groep indien de verkeersintensiteit dat vereist.
• Model spans nodes: test een combinatie van TP en PP tegen de interconnect en het latency-doel.
• Mengvorm van experts: voeg EP alleen toe wanneer de plaatsing van experts dat noodzakelijk maakt.

34. Vergelijking van Serving en frameworks

vLLM Het biedt paginatiegebaseerde toewijzing van KV-paren, continuous batching, een OpenAI-compatibele API, en verschillende parallelismomodi. De ondersteuning voor zijn model en hardware verandert regelmatig, dus controleer de gewenste model tegen de meest recente compatibiliteitsmatrix.

SGLang Het combineert RadixAttention voor hergebruik van prefixen, een aangepaste scheduler en gestructureerde generatie. De behaalde prestaties van de gepubliceerde throughput hangen af van de werklast en configuratie; vergelijk deze met vLLM en TensorRT-LLM door gebruik te maken van identieke prompts-instellingen, uitvoerresultaten, hardware en SLO’s.

TensorRT-LLM Het doel is om de kosten per enkele verzoek te verlagen via graffusie en kernel-optimalisatie voor latency tot CUDA, met ingebouwde ondersteuning voor FP8/FP4. De gepubliceerde cijfers zijn specifiek voor bepaald hardware en model, dus moet men deze vergelijken met de andere frameworks op één harness. Het nadeel hiervan is een steilere leercurve en een meer NVIDIA-specifieke deployment-omgeving.

TGI Het integreert zich met het Hugging Face-ecosysteem en ondersteunt verschillende hardware backends-oplossingen. Controleer eerst de huidige onderhouds- en functionaliteitsstatus van het repository voordat u het kiest voor een nieuwe deployment.

Ollama Het benadrukt een eenvoudige lokale model workflow. Gebruik het voor ontwikkelingsgemak; voor een benchmark andere serving stack wanneer hoge parallelle verwerking of expliciete SLO-beheersing van belang zijn.

llama.cpp Het is een portabele C/C++ runtime die ondersteuning biedt voor ARM-, x86-, Metal-, CUDA-, ROCm- en Vulkan-platformen. GGUF ondersteunt meerdere quantization-niveaus. De prestaties verschillen sterk afhankelijk van de model-, quantization-, contextuele factoren en backend-, dus gebruik de lokale benchmark-tool voor de desbetreffende machine.

35. GPU selectie voor inference

De tabel geeft de hardware- en cloudprijzen voor maart 2026 weer snapshot. De precisielabels geven de mogelijkheden van de leverancier weer, en de prijzen verschillen per aanbieder, regio, contractduur en beschikbaarheid; controleer deze voordat u koopt.

Kies eerst op basis van de geheugencompatibiliteit, en vervolgens op basis van de gemeten throughput op het latency-doel. De 141 GB capaciteit van de H200 kan het verwerken van grote model deployments-werkloads vereenvoudigen, terwijl de B200 extra FP4-ondersteuning, 192 GB HBM3e en een nieuwere generatie NVLink biedt. Kleinere GPUs-kaarten die gebruikmaken van GDDR kunnen economisch voordelig zijn voor gequantiseerde models-modellen, mits hun geheugen- en interconnectbeperkingen overeenkomen met de werklast.

Native hardware quantization ondersteuning heeft een grote invloed op de prestaties. AWQ en GPTQ (met INT4 weights) kunnen efficiënt draaien op elke architectuur door te worden gedecompileerd naar FP16 registers, maar echte native versnelling via Tensor Cores hangt af van de generatie. De Hopper (H100/H200) en Ada (L40S/4090) versnellen FP8 op native manier, terwijl de Blackwell (B200) native FP4 Tensor Cores biedt voor grote throughput verbeteringen. Alle genoemde GPUs ondersteunen INT8 matrixoperaties.

LLM decode wordt vaak beperkt door de geheugenbandbreedte, waardoor de capaciteit en bandbreedte van HBM belangrijker kunnen zijn dan de maximale TFLOPS voor serving werklasten. Vergelijk GPUs met model, waarbij de precisie, batchverdeling, contextlengte en het latency doel constant blijven.

36. Model-cascade-effecten en routing

Model routing kiest op basis van de voorspelde complexiteit of capaciteit welke LLM elke query zal verwerken. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) rapporteert een 85% lagere kosten voor de configuratie van MT-Bench, zonder dat de kwaliteitsnorm van GPT-4 met meer dan 5% daalt. Of routing zich zal terugverdienen, hangt af van de huidige prijzen, de samenstelling van het verkeer, router-fouten en de minimale vereiste kwaliteit.

Routers variëren van lichte classificatoren tot LLM-gebaseerde judges. Kaskadering is de sequentiële variant: een zoekopdracht begint met een goedkopere model en schaalt op wanneer een scorefunctie het antwoord afwijst. FrugalGPT De geëvalueerde model-pool vertoont kosten die tot wel 98% lager zijn, of een nauwkeurigheid die tot wel 4% hoger ligt. Een productieomgeving cascade vereist afgestemde escalatiecriteria en monitoring voor de query’s die de goedkope model incorrect verwerkt.

Deel VII — Toepassingen

Op applicatieniveau voorkomende patronen die ruwe model-capaciteiten omzetten in bruikbare systemen. De kracht van Embeddings ligt in retrieval, waarbij RAG antwoorden baseert op externe kennis, agents meerdere stappen in een workflows-proces coördineert, en prompt engineering alles met elkaar verbindt.

37. Embedding models versus generatieve models

Embedding models zet tekst om in vectoren met een vaste dimensie die de semantische betekenis weergeven. In tegenstelling tot generatieve decoderen models die token-sequenties produceren, geven ze één enkele dichte vector uit (met 768–4.096 dimensies) voor de hele invoer. De meeste embedding models maken gebruik van transformators die uitsluitend een encoder bevatten (bidirectionele attention), in plaats van een decoder. De encoder verwerkt alle invoer tokens tegelijkertijd en genereert een contextueel gerelateerde representatie voor elk token. Vervolgens reduceert een pooling-laag deze per-token representaties tot één enkele vector, meestal door middel van mean pooling (het gemiddelde nemen van alle token embeddings) of CLS pooling (door gebruik te maken van de uitvoer van een speciale classificatie-token). De model wordt daarna gefine-tuned met contrastieve learning: semantisch vergelijkbare teksten worden dichter bij elkaar in de vectorruimte geplaatst, terwijl onvergelijkbare teksten verder uit elkaar worden geduwd.

Geselecteerde embedding models en hun gerapporteerde scores (2025–2026):

De tabel combineert rapporten van model met versies van benchmark, waardoor het om een shortlist gaat in plaats van om een strikte ranglijst. Sommige nieuwere embedding systemen maken gebruik van decoderbackbones met bidirectionele attention-technieken en pooling. Andere systemen genereren output met lagere precisie of in multimodale embeddings-vorm. Beoordeel de vereiste taal, modaliteit, taak, dimensie en serving-kosten op basis van één retrieval-set.

Matryoshka-representatiereductie (MRL, Kusupati et al., NeurIPS 2022) Maakt de embedding-dimensies flexibel. Genoemd naar Russische poppen in elkaar, organiseert MRL een embedding zodat zijn eerste $m$ dimensies even veel informatie bevatten als een apart getrainde $m$-dimensionale model. Tijdens het trainen wordt in plaats van één enkele verliesfunctie voor de volledige embedding, meerdere verliesfuncties gelijktijdig berekend op logaritmisch gespreide dimensies (64, 128, 256, 512, 1024, 2048, 3072). Het samengevoegde verlies zorgt ervoor dat de voorkomende dimensies grove semantische informatie dragen, terwijl de latere dimensies meer detail toevoegen.

Na het trainen kan een MRL embedding worden ingekort tot een ondersteunde prefixdimensie. Volgens OpenAI presteert text-embedding-3-large met 256 dimensies beter dan text-embedding-ada-002 met 1.536 dimensies in de genoemde MTEB-vergelijking. Dit leidt tot een vermindering van 6 keer in de opslagruimte voor de ruwe vectoren; de kosten voor zoekopdrachten latency en databases hangen eveneens af van de index, metadata, filtering en hardware.

De embedding model is een belangrijk onderdeel in een RAG pipeline, Naast parsing omvatten deze processen chunking, zoekopdrachten, reranking, en generatie. Als er geen relevante bewijsstukken worden teruggevonden, kan zelfs een krachtigere generator deze niet betrouwbaar herstellen.

38. RAG-architectuur in productieomgevingen

Retrieval-Augmenteerde generatie voorziet een LLM van documenten die op het moment van de zoekopdracht worden opgehaald. Hierdoor kan actueel of privé bewijs worden geleverd dat afwezig is in model weights, maar retrieval garandeert niet dat het antwoord dit bewijs correct gebruikt. Een productiesysteem van type RAG is een meestages pipeline waarbij elke fase apart moet worden geëvalueerd.

De pipeline vindt offline plaats. Ruwe documenten (PDF’s, HTML, Markdown, databases) worden eerst geanalyseerd tot schone tekst, wat lastiger is dan het klinkt: alleen al bij het analyseren van PDF’s kunnen tabellen, koppen en opmaakverwijderd raken. Vervolgens wordt de tekst opgesplitst in chunks, die apart worden geïntegreerd en gearchiveerd.

Chunking heeft invloed zowel op de retrieval recall als op de context die beschikbaar is voor de generator. De geschikte groottes hangen af van de documentstructuur, de granulariteit van de query, de beperkingen van de embedder en de reranker limieten. Veelgebruikte methoden zijn vaste groottes met overlap, recursieve splitsing langs de documentgrenzen, en semantische chunking bepaling op basis van embedding-gelijkenis. Vergelijk deze methoden aan de hand van relevantielabels op pagina- of sectieniveau, in plaats van één universele token-bereik te hanteren.

Elk chunk wordt vervolgens geïntegreerd met een model, vergelijkbaar met die in Paragraaf 37 en opgeslagen in een vector database (Pinecone, Weaviate, Qdrant, pgvector en dergelijke).

De retrieval pipeline wordt uitgevoerd tijdens het verwerken van een query. Begin met een meetbare basiswaarde en voeg vervolgens stappen toe wanneer de foutanalyse aantoont dat deze daadwerkelijk bijdragen aan het oplossen van fouten.

• Hybride zoekopdracht combineert dichte vectoren retrieval met spaarzame retrieval methoden zoals BM25, en wordt vaak gecombineerd via Reciprocal Rank Fusion (RRF). Dichte zoekopdrachten kunnen semantische parafrasen verwerken, terwijl spaarzame zoekopdrachten exacte identificatoren, foutcodes en afkortingen detecteren. Leveranciers van benchmarks melden verbeteringen ten opzichte van baselines die alleen vectoren gebruiken, maar de grootte van het resultaat hangt af van het corpus en de relevantie-etiketten.
• Reranking stuurt de teruggevonden kandidaten door een model mechanisme dat zowel de zoekopdracht als het document beoordeelt. Dit kan de fijne relevantie verbeteren, ten koste van een extra aanroep van model. Het aantal kandidaten, het aantal behouden kandidaten en latency moeten samen worden afgesteld. Ik heb het volledige meervoudige stappenproces van pipeline in Het opbouwen van een moderne zoekrankingsstack.
• Query transformation herschrijft de query van de gebruiker vóór retrieval om de recall te verbeteren. HyDE (Hypothetical Document Embeddings) maakt gebruik van LLM om een hypothetisch antwoord te genereren, dat vervolgens wordt geïntegreerd en gebruikt voor retrieval. Multi-query expansion genereert meerdere varianten van dezelfde vraag. Step-back prompting stelt eerst een meer algemene vraag om een breder context te verkrijgen.

De meest voorkomende foutmodi:

• Retrieval falen — het juiste document bestaat wel, maar wordt niet opgehaald. Test chunking, query-transformatie, hybride zoekopdrachten en metadata-filtering bij dit probleem.
• Contextvervuiling — irrelevante, opgehaalde chunks-gegevens leiden de LLM af. Test reranking, contextfilters en kleinere, geselecteerde datasets.
• Verloren in het midden — de LLM negeert relevante contextinformatie die zich bevindt in het midden van een lange prompt.Liu et al., 2024 Het bleek dat models vooral aandacht besteedde aan het begin en het einde van de context window).

GraphRAG (Microsoft, 2024) verrijkt de vector retrieval met een geëxtraheerd entiteiten- en relatiegrafiek. Hierdoor kan het om vragen op corpusniveau gaan die veel relaties bevatten en die een eenvoudige chunk retrieval mogelijk over het hoofd ziet. De nadelen hiervan zijn de extra werkzaamheden die nodig zijn voor extrahering, indexeren, opslag en evaluatie.

Gidsen voor praktijkspecialisten geven de bereiken van latency aan voor embedding, zoekfuncties, reranking en generatie, maar deze cijfers verschillen per regio, corpus, hardware en model. Meet elke fase in traces en beoordeel de kwaliteitsverandering voordat je de toegevoegde latency accepteert.

39. Agent-architecturen en hulpprogramma’s voor aanroepen

LLM agents Gebruik models om tool calls te selecteren en te sequenceren rondom een veranderende toestand. Er zijn drie nuttige orchestration patronen:

• ReAct — Het mengt actiekeuze met observaties. Het kan zich na elke tool result aanpassen, maar een steeds langer historisch verloop verhoogt de kosten van token en latency. ReWOO — plannen tool calls met placeholders, voeren onafhankelijke taken parallel uit en synthetiseren vervolgens het resultaat. De bijbehorende studie rapporteert token besparingen ten opzichte van ReAct, maar een vaste planning vereist een expliciete herstelroute wanneer een hulpmiddel faalt.
• Planner-executor — scheidt planning van de uitvoering en maakt het mogelijk om na een fout een her-planning-strategie toe te passen. Het stelt model specialisatie mogelijk, maar brengt wel extra orchestration-toestanden en nog een beslissingspunt met zich mee.

Function calling is een veelgebruikt mechanisme voor het oproepen van tools. Door APIs te gebruiken, worden de definities van tools gemaakt en worden gestructureerde argumenten teruggegeven, waardoor er minder behoefte is om vrije tekst te parseren. Argumenten die voldoen aan het schema kunnen desondanks nog steeds de verkeerde tool kiezen of ongeldige waarden bevatten. Parallelle function calling uitvoering kan de aantal heen-en-weerreizen verminderen wanneer de operaties onafhankelijk van elkaar zijn.

Structured output en constrained decoding zorgen voor naleving van een schema door de tokens die op elke generatiestap beschikbaar is te beperken. Engines zoals xgrammar, Wordt gebruikt in vLLM en SGLang, en kan veel syntaxis- en parsingfouten met weinig overhead verhelpen in ondersteunde configuraties. Ze garanderen echter niet dat de geëxtraheerde waarden of beslissingen correct zijn. Schema-gestuurde Reasoning (SGR) maakt gebruik van de volgorde van velden en de schemastructuur om de tussentijdse staat controleerbaar te maken voordat er een definitieve beslissing wordt genomen. De drie patronen hiervoor zijn Cascade (sequentiële stappen), Routing (unietypen als semantische schakelaars), en Cycle (gebonden lijsten).

De kwaliteit van de hulpmiddelselectie, de end-to-end latency en de token kosten verslechteren doorgaans naarmate het aantal beschikbare hulpmiddelen en de diepte van de uitgevoerde acties toenemen. Meet deze curves aan de hand van de daadwerkelijke beschrijvingen van de hulpmiddelen en de distributie van fouten. Frameworks zoals LangGraph Men kan de toestandsinformatie en herstelpaden expliciet maken, maar dit vermindert niet de belasting die gepaard gaat met de evaluatie.

40. Prompt engineering voor productieomgevingen

Productieprompting vormt een evaluatieprobleem: verander één onderdeel van prompt of de context, en meet daarna de kwaliteit van de taak en de mogelijke foutpatronen. De hieronder beschreven technieken vormen gebruikelijke uitgangspunten, maar geen universele volgorde.

Voorbeelden met weinig data zijn vaak effectief om het uitvoerformaat te sturen. Begin met 3–5 voorbeelden die lege invoeren, ambiguë vragen en meervoudige antwoorden omvatten, en meet daarna het resultaat op een apart gehouden testset. De voorbeelden moeten span overeenkomen met de werkelijke invoerverdeling, en niet alleen het ‘ideale’ scenario weerspiegelen. Meer voorbeelden verbruiken context en garanderen geen verdere verbeteringen.

Chain-of-thought (CoT) prompten vragen aan een model om tussentijdse reasoning-resultaten openbaar te maken voordat er wordt geantwoord. Kojima en collega’s meldden verbeteringen door het gebruik van de toevoeging “Laten we stap voor stap nadenken” bij hun geteste reasoning-taken, maar het effect verschilt per model en nieuwere reasoning APIs-systemen tonen mogelijk geen verborgen traces-informatie. Voor productieomgevingen is het raadzaam een goed te controleren taakontbinding of een beknopte motivering te gebruiken wanneer dit nuttig is voor de evaluator. Zelfconsistentie (Wang et al., 2023) Het test verschillende reasoning-paden en combineert de resultaten, waarbij het bereid is extra inference-kosten te betalen voor meer betrouwbaarheid bij geschikte taken.

Structured output met expliciete JSON-schemasSection 39) Het verwijdert veel fouten bij de parsing. Constrained decoding Engines zoals xgrammar kunnen tijdens het genereren de ondersteunde grammatica opleggen; echter vereisen feitelijke nauwkeurigheid en semantische geldigheid nog steeds evaluatie, en onondersteunde schema-eigenschappen moeten mogelijk nog wel worden afgehandeld.

Prompt chaining verdeelt een taak in gerichte fasen, bijvoorbeeld intent classificeren → context ophalen → antwoord genereren → uitvoer valideren. Hierdoor kunnen fouten worden gelokaliseerd, kunnen er per fase verschillende models worden gebruikt, en kan een tussentijdse staat die in de cache kan worden opgeslagen worden gecreëerd. Bovendien worden er interfaces en latency toegevoegd, waardoor het verschil met een enkele oproep als referentie kan worden vergeleken.

Temperatuur beïnvloedt de steekproefverdeling. Lage waarden vormen een redelijke uitgangspunt voor classificatie of extractie; hogere waarden kunnen de diversiteit vergroten bij het genereren van nieuwe ideeën. Het exacte gedrag verschilt per model APIs en is afhankelijk van de interactie met top_p, top_ken de standaardinstellingen van de provider, zodat alle ondersteunde instellingen voor de taak worden doorlopen in plaats van slechts één bereik te kopiëren.

Scheiding tussen systeem- en gebruikersberichten zorgt ervoor dat de permanente beleidsregels gescheiden blijven van de inhoud per verzoek. Chattemplates en instructietuningen geven aan deze rollen een verschillende prioriteit, maar ze maken een systeembericht nog geen grens voor het opleggen van regels. Plaats stabiel gedrag in het systeembericht, houd onbetrouwbare gegevens in de gebruikers- of hulpinhoud, en voer strenge beperkingen zoals het verwijderen van PII ook buiten model uit.

Context engineering breidt het werk van prompt uit tot de samenstelling van opgehaalde documenten, tool results, gespreksgeschiedenis en voorbeelden. Liu et al. ontdekten een ‘lost-in-the-middle’-effect in de lange-context models die zij testten; daarom moet positie onderdeel zijn van de evaluatie in plaats van als irrelevant te worden beschouwd. Ik heb de bredere workflow behandeld in Context Engineering voor AI Agents.

Deel VIII — Productieoperaties

Dit gedeelte behandelt rate limiting, foutmodi, monitoring, kostenoptimalisatie en capaciteitsbeheer planning onder echte verkeersbelasting.

41. Snelheidsbeperking voor verzoeken met variabele kosten

Traditionele rate limiting op basis van verzoeken per seconde gaat uit van een ongeveer gelijke kosten per verzoek. LLMs Ontkennen van die aanname. Een 10-token classificatie prompt en een 100K-token De analyse van documenten liep op hetzelfde probleem vast. API De endpoints verschillen weliswaar in kosten met vier ordes van grootte. Door limieten op het aantal verzoeken per seconde (RPS) in te voeren, worden dure verzoeken soms ongecontroleerd doorgelaten, terwijl goedkope verzoeken onnodig worden beperkt.

Productiesystemen hebben token-gebaseerde rate limiting nodig op meerdere dimensies. OpenAI Vraag documenten aan en bekijk de token-limieten per gebruiksniveau. Anthropic Het scheidt de invoer-token en uitvoer-token limieten van elkaar. De exacte quota’s en algoritmen kunnen veranderen, dus beschouw de documentatie van de provider als de bron van waarheid; het architectonische doel is om verzoeken en tokens op afzonderlijke manier te budgetteren.

Het praktische implementatiepatroon bestaat uit een meerdimensionale hiërarchie van beperkingen (gebruiker → applicatie → organisatie → wereldwijd), waarbij er verschillende prioriteitsniveaus zijn voor premium-toegang. Op het niveau van de verzoek is de belangrijkste techniek de budgetreservering met token: bereken de totale tokens (invoer + max_tokens) Bij het accepteren van een verzoek wordt eerst een bedrag afgetrokken uit de beschikbare capaciteit, waarna bij voltooiing van het verzoek de capaciteit wordt aangepast aan de daadwerkelijke gebruikssituatie. Dit voorkomt dat een grote hoeveelheid verzoeken met lange verwerkingstijden de beschikbare capaciteit uitputten voordat ze zelfs maar output kunnen genereren.

Voor zelf gehoste deployments wordt het equivalent gerealiseerd door throughput te provisioneren: door specifieke GPU capaciteit te reserveren voor de gewenste token tarieven. Voor vLLM deployments betekent dit dat er toegangsbeheer wordt geconfigureerd op basis van actieve decode slots en KV cache druk, in plaats van uitsluitend op basis van het aantal verzoeken. Section 5 Het wordt uitgelegd dat zowel throughput als de toegang beperkingen nodig hebben die rekening houden met token.

42. Foutmodi waar tegen ontworpen moet worden

LLM serving voegen foutmodi toe die verband houden met een variabele sequentielengte, KV-geheugen en langdurige decode uitvoeringen. Ontwerp en voer belastingtests uit op de beschermingsmaatregelen voordat het productietraffic erop gaat vertrouwen.

Out-of-Memory (OOM) is een veelvoorkomende fout. Een 70B FP16 model heeft alleen al ongeveer 140 GB nodig voor weights, en KV cache kan bij een enkele sequentie met een contextgrootte van 128K ongeveer 40 GB extra verbruiken, op basis van de genoemde aannames. Section 6. De kloof tussen ‘past in het geheugen’ en ‘OOM onder belasting’ is kleiner dan het lijkt, omdat een groep verzoekjes met lange contexten meer KV-geheugen kan verbruiken dan verwacht. Preventie vereist zowel een goed gemeten geheugenreservering als quantization en paginatie van de KV-toewijzing. Voor werkloads met hoge KV-druk, LMCache Het is mogelijk om KV-data af te leveren naar het geheugen of de schijf van CPU; de gepubliceerde resultaten kunnen dienen als uitgangspunt voor benchmark en de lokale geheugenhiërarchie.

Preemption treedt op wanneer druk van KV cache de scheduler dwingt om werk te verwijderen of opnieuw te berekenen. De exacte strategie hangt af van de versie en configuratie van serving. Voor de gebruiker blijkt dit zich uit in een hogere totale latency, zonder dat er een duidelijke applicatiefout optreedt. Houd de aantallen preemptions in de gaten en relateer deze aan het gebruik van KV’s, de diepte van de queue en de lengte van de verzoeken.

Tail latency kan stijgen wanneer grote voorwaarden het uitvoeren van decode vertragen. Gedeeltelijke prefill (Section 7) En door een planning te gebruiken die rekening houdt met de lengte, kan deze interferentie worden verminderd. De artikelen over de Learning-to-Rank scheduler en CascadeInfer rapporteren aanzienlijke verbeteringen ten opzichte van hun baselines, maar het exacte resultaat hangt af van de verdeling van de vraaglengtes en de configuratie van de scheduler.

Kaskadefalen kunnen optreden wanneer trage verzoeken de wachtrij vergroten, upstream-klanten een tijdslimiet bereiken en herproberingen nog meer belasting veroorzaken. Beschermingsmaatregelen omvatten toegangsbeheer, limieten voor gelijktijdige verwerking per gebruiker, maximale uitvoerhoeveelheden, herprobeerbudgetten en circuit breakers bij gateways. Gedecentraliseerde prefill en decode pools kunnen van pas komen wanneer load tests aanhoudende faseinterferentie vertoont.

43. Monitoring van LLM-systemen

Monitoring van LLM verschilt op enkele fundamentele punten van de traditionele API monitoring. Elke aanvraag heeft een variabele kostenstructuur, kent twee duidelijk afgebakende fasen met verschillende bottlenecks waarden, en vereist een geheugengebruik dat afhankelijk is van zowel de lengte van de invoer als die van het generatieresultaat. Standaardmetrieken zoals het aantal aanvragen latency en de foutkans geven weinig inzicht in de werkelijk belangrijke aspecten.

Goodput geeft het aantal verzoeken per seconde weer dat voldoet aan alle gedefinieerde SLO-thresholds, zoals TTFT, TPOT en het totale latency. Dit is een nuttige gecombineerde maatstaf, omdat de ruwe throughput-waarde er gezond uit kan zien terwijl de latency-SLO’s niet worden nageleefd: een systeem dat 100 verzoeken per seconde verwerkt maar op 40% daarvan de thresholds niet haalt, heeft een goodput van 60. Door te optimaliseren voor goodput blijft de prestatiedistributie zichtbaar, in plaats van alleen de gemiddelde waarde te rapporteren.

vLLM biedt een Prometheus-eindpunt aan /metrics Met lopende en wachtende verzoeken, KV cache-gebruik, distributies van de generatie-lengte en statistieken van de prefix-cache. De namen van de metrics kunnen per release verschillen, dus koppel de dashboards aan de geïmplementeerde versie. Een typische stack maakt gebruik van Prometheus voor metrics, Grafana voor visualisatie, en OpenTelemetry-compatibele traces binnen zowel de applicatie als de serving-componenten.

Useful waarschuwingspatronen omvatten de volgende. Bepaal de drempelwaarden hiervoor op basis van load tests in plaats van deze voorbeelden ongewijzigd over te nemen:

• Stijging van het aantal preemptions — verzoeken worden weggehaald en opnieuw gestart; gebruikers ondervinden een stille verdubbeling van latency.
• De KV cache-utilisatie nadert het geteste preemptiongebied — voeg capaciteit toe of verminder de belasting voordat er items worden weggehaald cascade.
• De diepte van de wachtrij blijft consequent boven de geteste batchgrens — het toelatingsbeheer moet beginnen met het weigeren of downprioriteren van verzoeken.
• TTFT neemt toe terwijl TPOT constant blijft — deze afwijking wijst eerder op problemen met de wachtrij, het toelatingsbeheer, het netwerk of prefill-druk dan op decode throughput. Gebruik traces en metrieken voor de wachtrij om ze van elkaar te onderscheiden.

44. Kostenoptimalisatie: een versterkende strategie

Aangezien het om een verouderde snapshot uit maart 2026 gaat, varieerden de API-prijzen op verschillende model-niveaus aanzienlijk. De exacte prijzen veranderen snel, dus gebruik voor een aankoopbeslissing altijd de huidige rekenmachine van de aanbieder. Het belangrijkste punt is dat de keuze van model en de lengte van het resultaat al vóór infrastructuuroptimalisaties een grote invloed kunnen hebben op de kosten.

In het rapport van maart 2026 snapshot dat voor dit gedeelte is gebruikt, bedroeg de kosten van tokens meerdere keren de kosten van de invoer tokens voor de genoemde model niveaus. Die asymmetrie weerspiegelt het sequentiële decode werk dat hier wordt beschreven. Section 7. Voor dergelijke prijsstructuren kan het verminderen van onnodige uitvoer meer effect hebben dan het verkleinen van dezelfde hoeveelheid invoer tokens.

Meerdere benaderingen kunnen op elkaar worden gestapeld, maar alleen nadat is vastgesteld welke van toepassing zijn op de werklast:

1. Quantization van FP16 tot INT4 vermindert het gebruik van weight geheugen met 75%. Of dit de kosten verlaagt, hangt af van de snelheid van kernel, de grootte van de batch en de benutting van de hardware.Section 9).
2. Model routing stuurt geschikte verkeerstromen naar goedkopere models. Een Maxim AI-casestudy van de leverancier Er werd gemeld dat de maandelijkse rekening met $42.000 is gedaald tot$29.000; reproduceer eerst de kwaliteitscontrole voordat je de routing share gebruikt.Paragraaf 36).
3. Prompt caching verminderd het aantal keren dat een herhaald prefix moet worden verwerkt. Aanbieders verlagen hun prijzen en passen hun beperkingen op het aantal aanvragen regelmatig aan, dus combineer de gemeten hitratio met de huidige voorwaarden.Section 16).
4. Batch APIs maakt het mogelijk om niet‑realtime taken zoals evaluaties, generatie van synthetische data en grootschalige classificatie te verwerken. Controleer de huidige prijzen en de benodigde tijd voor voltooiing.
5. Self-hosting kan voordelig zijn bij een constante gebruiksniveau, maar er bestaat geen universele breukpunt voor token-volume. Naast de huurkosten voor GPU moeten ook engineeringkosten, orchestration, observability, capaciteitsruimte en kosten voor nachtdiensten in aanmerking worden genomen.

Het vermenigvuldigen van de illustratieve factoren levert een grote theoretische verlaging op, maar de invoerwaarden zijn niet onafhankelijk: quantization beïnvloedt throughput, routing verandert de kwaliteitscombinatie, en caching en batching zijn alleen van toepassing op geschikte verkeersstromen. Stel de schatting op basis van gemeten verkeersverdelingen op en valideer deze tegenover de factuur.

A 2024-rapport van de leverancier van TrueFoundry De meeste kosten van deployment in het bijbehorende voorbeeld zijn gerelateerd aan ML-werkzaamheden in plaats van aan rekenwerk. Beschouw deze cijfers als een prompt om arbeidskosten en operationele uitgaven mee op te nemen in de model, en niet als een universele verhouding.

45. Capaciteit planning en autoscaling

De capaciteit planning voor LLM serving moet rekening houden met wisselende aanvraagkosten, langdurige decode verwerkingen, en geheugen dat afhankelijk is van de uitvoeringsvolgorde. Afhankelijk van de werklast kan de beperkende factor het KV-geheugen, het geheugenbandbreedte, de rekenkracht of de interconnect zijn.

Het harde plafond voor gelijktijdige verzoeken is het geheugenbudget van KV cache, en niet de FLOPS:

$\text{maximaal aantal gelijktijdige sequenties} = \frac{\text{GPU geheugen} - \text{model weights} - \text{overhead}}{\text{grootte per sequentie KV cache}}$

In een vereenvoudigd voorbeeld van Llama 3 70B INT4 zijn er ongeveer 35 GB aan weights nodig op een 80 GB H100, waardoor na het reserveren van extra overhead ongeveer 40 GB overblijven. Bij een contextgrootte van 4K leidt een geschatte grootte van 160 MB per sequentie tot een theoretisch maximum van ongeveer 250 sequenties; bij 128K context daalt dit getal door dezelfde berekening naar ongeveer vijf. De werkelijke capaciteit is lager wanneer rekening wordt gehouden met het gedrag van de allocator, runtime buffers, variaties in de lengte van de verzoeken en de latency SLO’s. Dit is ook de reden waarom GPU selectie en KV cache optimalisatie op directe manier de capaciteitsplanning sturen.

De formule voor het bepalen van de capaciteit bij het dimensioneren van een vloot:

$\text{vereiste GPUs} = \frac{\text{piekwaarde tokens per minuut} \times \text{gemeten veiligheidsmarge}}{\text{per GPU throughput bij het doelstellingssnelheidsniveau}}$

Het belangrijke detail is dat dit ‘bij het gewenste SLO’ ligt. Piekwaarde token throughput en SLO-geschikt throughput De verschillen kunnen sterk toenemen naarmate de parallelle verwerking toeneemt. Benchmark met de echte prompt en de verdeling van de uitvoerlengte bij de vereiste TTFT- en TPOT-thresholds, in plaats van gebruik te maken van een theoretisch maximum.

De GPU-utilisatie is onvoldoende als enige signaal voor autoscaling, aangezien deze waarde hoog kan blijven zowel tijdens normale verwerking als bij overbelasting. Combineer deze met de queue depth, de KV cache-utilisatie en de goodput-degradatie. Stel de drempelwaarden in via load tests; waarden zoals 80% KV-utilisatie dienen slechts als uitgangspunt en vormen geen universele limieten. Deze metrics worden geïntroduceerd in Section 43.

Het schalen naar nul is geschikt voor ontwikkel- en stagingomgevingen waarin de servers lange tijd niet worden gebruikt. Serverless inference-platformen en op Kubernetes gebaseerde autoscalers zoals KEDA kunnen overtollige capaciteit weghalen, maar de besparingen en de tijd die nodig is voor een ‘cold start’ hangen af van de model-grootte, het gebruik van afbeeldingen en weight-caching, evenals van de infrastructuur. Meet eerst de starttijd voordat je dezelfde strategie toepast op productietraffic die gevoelig is voor latency.

Het onderling verbonden systeem

Deze 45 concepten vormen geen willekeurige verzameling. Ze maken deel uit van een onderling verbonden systeem. De grootte van KV cache bepaalt de batchgrootte, waardoor de rekenintensiteit wordt bepaald. De rekenintensiteit bepaalt op zijn beurt of decode door geheugenbeperkingen wordt belemmerd, wat weer invloed heeft op de TPOT-waarde. TPOT bepaalt vervolgens throughput. Door GQA te verkleinen, wordt KV cache kleiner, waardoor grotere batches mogelijk worden. Dit leidt tot een hogere rekenintensiteit en daarmee tot een betere benutting van GPU. FlashAttention maakt gebruik van het kloofje in de bandbreedte tussen SRAM en HBM. Continuous batching lost het probleem van lage rekenbenutting op, maar veroorzaakt tegelijkertijd geheugenfragmentatie, wat juist door PagedAttention wordt opgelost. Gecompartimenteerde prefill-aanpakken plannen rekenintensieve en geheugenintensieve taken samen; de roofline-theorie van model verklaart waarom deze complementariteit werkt.

Op het gebied van training kan de levenscycluskost gunstig zijn voor het trainen van een kleinere model op meer tokens, zoals blijkt uit Llama 3 8B. GRPO vermindert de belasting op de critic-state van PPO. In de geteste kleine-model configuratie van DeepSeek-R1 presteerde distillatie beter dan directe RL. Dit zijn ontwerpoplossingen die geëvalueerd moeten worden, en geen enkele vaste trainingsmethode.

Het operationele patroon is stabielere dan elke prijscurve: routing, caching, quantization en hardware met de juiste specificaties hebben pas echt effect wanneer ze allemaal worden geëvalueerd op basis van dezelfde kwaliteitsnormen en het latency-doel.

Belangrijkste principes

1. LLM inference Het kent twee duidelijk verschillende fasen. In het algemeen serving regimes prefill heeft de voorkeur voor computergestuurde verwerking decode richting de geheugenbandbreedte; de vorm van de werklast kan deze grens verplaatsen.
2. De KV cache Dit vormt vaak een cruciale beperking. De grootte heeft invloed op de capaciteit voor batchverwerking en op de geheugendruk. GQA, paginatiegebonden toewijzing, en KV quantization doelstellingen stellen voor verschillende onderdelen van die beperking.
3. De GPU De geheugenhiërarchie verklaart veel van de optimalisaties. FlashAttention en kernel Fusion verminderd de kostbare gegevensverplaatsing in plaats van de configuratie aan te passen. modelDe functie van .
4. Continuous batching en PagedAttention Samenwerken. Een gepubliceerd vergelijkingsrapport geeft een verhouding van 23x aan. throughput ten opzichte van zijn eenvoudige referentiepunt; meet de verbetering in uw serving stack.
5. Chinchilla-optimal is niet inference-optimaal.** Llama 3 8B is bijvoorbeeld getraind met ongeveer 1.875 tokens Voor elke parameter kan er meer rekenkracht worden besteed aan training om de kosten te verlagen. inference.
6. GRPO En door destillatie is het alignment-hulppakket veranderd. DeepSeek-R1 liet een sterkere prestatie zien bij kleine datasets.model De resultaten zijn het beste verkregen door destillatie dan door directe RL-experimenten.
7. Kostenoptimalisatie wordt alleen toegepast op geschikte verkeersstromen. Model quantization, routingcaching en batchverwerking APIs Er moeten aparte metingen van de dekking en de kwaliteit worden uitgevoerd voordat de besparingen vermenigvuldigd kunnen worden.
8. Serving-hardware moet overeenkomen met de bottleneck. Werklasten die veel Decode vereisen, profiteren vaak van voldoende HBM-capaciteit en bandbreedte; werklasten die veel prefill vereisen, leggen meer druk op de rekenkracht door het gebruik van weight.

Verder lezen

Gerelateerde diepgravende artikelen van deze blog, gegroepeerd per onderwerp:

• LLM Fine-Tuning Gids — Wanneer te fine-tunen versus RAG versus prompt engineering
• Open-source varianten en bestandsformaten van LLM — het afstemmen van model-varianten en gequantificeerde formaten op de hardware LoRAX Serving Gids — serving duizenden LoRA adapters in productieomgevingen
• Schalen van grote taalmodellen Models — strategieën voor meerdere GPU-instellingen en meerdere nodes Lokale LLMs op macOS — praktische opstelling met llama.cpp en Ollama AI Agent Reasoning Lussen in 2026 — een diepgaande analyse van ReAct, ReWOO, en de planner-executor lussen
• AI Agent Memory Architectuur in 2026 — checkpoints, vector stores, en documenteer het geheugen voor stateful agents

Referenties

Gecategoriseerd per onderwerpgebied; sectienummers tussen haakjes wanneer van toepassing.

Inference en attention

• FlashAttention: Een snelle en geheugen-efficiënte exacte Attention die rekening houdt met I/O-activiteit. - Dao et al., NeurIPS 2022 FlashAttention-2: Snellere Attention dankzij betere parallelisatie en werkverdeling - Dao, 2023
• FlashAttention-3: Snelle en nauwkeurige Attention uitvoering dankzij asynchrone verwerking en lage precisie - Shah et al., NeurIPS 2024 Flash-Decoding voor lange contexten inference - Dao et al., 2023
• Efficiënt geheugenbeheer voor grote taalmodellen Model Serving met PagedAttention - Kwon et al., SOSP 2023
• Orca: Een gedistribueerd Serving systeem voor transformer gebaseerde generatieve Models processen - Yu et al., OSDI 2022
• GQA: Training van gegeneraliseerde multi-query Attention - Ainslie et al., 2023
• Triton: een intermediaire taal en compiler voor berekeningen in neurale netwerken - Tillet et al., MAPL 2019
• FlashNorm: Snelle normalisatie voor LLMs - 2024
• Deep Kernel Fusion voor Transformers - DeepFusionKernel, 2026

Speculatieve decodering

• EAGLE-3: Schalen van de Inference versnelling voor grote taalmodellen Models - Li et al., NeurIPS 2025 Medusa: Eenvoudige LLM Inference versnelling Framework met meerdere decoderingskoppen - ICML 2024

Quantization

• AWQ: Activation-aware Weight Quantization voor LLM compressie en versnelling - MLSys 2024 Beste Paper GPTQ: Precieze Post-Training Quantization voor generatieve voorgetrainde Transformers - Frantar et al., ICLR 2023
• Marlin: Gemengde precisie (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Training en fine-tuning

• LoRA: Lage-rangadaptatie van grote taalmodellen Models - Hu et al., ICLR 2022 QLoRA: Efficiënt fijnafstellen van gequantiseerde LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Geheugenoptimalisaties voor het trainen van modellen met miljarden parameters Models - Rajbhandari et al., SC20 ZeRO-Infinity: Het doorbreken van de GPU-muur voor geheugen bij diep leer op extreem grote schaal - Rajbhandari et al., 2021
• Self-Instruct: Het afstemmen van de taal Models op zelf gegenereerde instructies - Wang et al., ACL 2023
• WizardLM: Het in staat stellen van grote taalmodellen Models om complexe instructies op te volgen - Xu et al., ICLR 2024 Technisch rapport Phi-4 - Microsoft, 2024 AI models krimpen wanneer getraind op recursief gegenereerde gegevens - Shumailov et al., Nature 2024

Alignement

• Directe voorkeursoptimalisatie: Uw taal Model is in werkelijkheid een beloning Model - Rafailov et al., NeurIPS 2023 DeepSeekMath: Het maximaliseren van de mogelijkheden van wiskundige Reasoning in openbare Models talen - GRPO is geïntroduceerd.
• DeepSeek-R1: Stimulering van de Reasoning-capaciteit in LLMs door middel van versterkingsleren - DeepSeek, 2025

Schalen en architectuur

• De Llama 3 Herd van Models - Meta, 2024 LLaMA: Een open en efficiënte basis-taalmodel Models - Touvron et al. (Meta), 2023
• Llama 2: Open Foundation en gefineerde chatversie Models - Touvron et al. (Meta), 2023 Technisch rapport Qwen3 - Qwen Team (Alibaba), 2025 Training van compute-optimale grote taalmodellen Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Een geavanceerde Transformer met rotatieve positiebeheersing Embedding - Su et al., 2021
• YaRN: Een efficiënte Context Window uitbreiding voor grote taal Models modellen. - Peng et al., ICLR 2024 SGLang: Efficiënte uitvoering van programma’s in gestructureerde taal Model - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka-representatiereductie - Kusupati e.a., NeurIPS 2022 pplx-embed-v1: Diffusion-voorgetrainde dense en contextuele Embeddings - Perplexiteit AI, 2026

Agent architectuurpatronen

• ReAct: Synergiëren tussen Reasoning en handelen in taal Models - Yao et al., ICLR 2023
• ReWOO: Het loskoppelen van Reasoning van observaties voor efficiënte versterkte talen Models - Xu et al., 2023

Routing

• RouteLLM: Leren om LLMs te routeren met voorkeursgegevens - Ong et al., ICLR 2025

Benchmarks

• Resultaten MLPerf Inference v5.0 - MLCommons, april 2025

Serving-architecturen

• SARATHI: Efficiënte LLM Inference door decodes te benutten die zijn voorzien van gechunkte prefills - Agrawal et al., 2023 (In delen opgesplitste Prefill) Splitwise: Efficiënte generatieve LLM Inference via faseverdeling - Patel et al., ISCA 2024 (Gesplitste Serving)
• DistServe: Ontleding van Prefill en decodering voor Goodput-geoptimaliseerde grote taalmodellen Model Serving - Zhong et al., OSDI 2024 (Gesplitste Serving)

Serving frameworks

• vLLM - PagedAttention-gebaseerde serving motor SGLang - RadixAttention en gestructureerde generatie
• TensorRT-LLM - NVIDIA-geoptimaliseerd inference
• llama.cpp - Portabele C/C++ inference
• DeepSpeed - Microsoft-distributielib voor getrainde modellen
• Ollama - Lokale LLM uitvoerder

Operaties

• Efficiënte LLM-scheduling door leren rangschikken - Fu et al., NeurIPS 2024 (vLLM-LTR) CascadeInfer: Lage Latency en gelijkmatig belaste LLM Serving dankzij lengtebewuste planning - 2024
• De Goodput-metriek als maat voor de ML-productiviteit - Google Cloud, 2024 vLLM Optimalisatie en afstelling - vLLM Documentatie vLLM Metrieken - vLLM Documentatie
• LMCache: KV Cache-beheer voor LLM Serving - KV cache afhandeling naar een externe processor Rate limits van OpenAI - OpenAI API Documentatie Anthropic-ratebeperkingen - Anthropic API Documentatie