Waarom wordt LLM-decode beperkt door geheugen en prefill door rekenkracht?
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
LLM-decode wordt vaak beperkt door geheugen, omdat een kleine batch elke model weight maar een paar keer hergebruikt voordat de volgende weights worden geladen. Prefill met lange prompts of voldoende grote batches hergebruikt weights voor veel prompt-tokens, waardoor de matrixberekening de beperkende factor kan worden. Dit zijn omstandigheden van de werklast, geen vaste eigenschappen van de afzonderlijke fasen.
Rekenintensiteit helpt bepalen of je gegevensverplaatsing moet verminderen of de uitvoering van matrixberekeningen moet verbeteren.
Berekeningen vergelijken met verplaatste bytes
Rekenintensiteit is het aantal uitgevoerde drijvendekommaoperaties per byte die uit het geheugen wordt overgedragen. Het roofline-model vergelijkt dit met de maximale rekenkracht gedeeld door de geheugenbandbreedte.
De specificaties van de NVIDIA H100 SXM vermelden ongeveer 989 TFLOPS voor dichte FP16/BF16-berekeningen op Tensor Cores en 3.35 TB/s geheugenbandbreedte. Het vermelde getal van 1,979 TFLOPS gaat uit van gestructureerde sparsiteit. De verhouding is ongeveer 295 FLOPs per byte. Dit is een theoretische grens op basis van bij elkaar passende hardwarespecificaties.
Een vereenvoudigde vermenigvuldiging van een dichte matrix met een vector voert ongeveer twee bewerkingen uit per weight van twee bytes: ongeveer één FLOP per byte. Een decoder met batchgrootte één kan onder deze omstandigheden de maximale matrix-throughput van de GPU niet benutten. Grotere batches laten een geladen weight bijdragen aan berekeningen voor meerdere tokens. Prefill hergebruikt weights op dezelfde manier voor prompt-tokens. Splitwise beschrijft deze verschillende kenmerken van de fasen.
Een wijziging kiezen op basis van de gemeten beperking
| Waarneming | Te onderzoeken wijziging | Wat winst kan verhinderen |
|---|---|---|
| Decode met kleine batches besteedt tijd aan het verplaatsen van weights | Ondersteunde weight-quantization; grotere decode-batches | Quantization-kernels, kwaliteitsverlies, latency-limieten |
| Decode met lange context besteedt tijd aan het lezen van de attention-geschiedenis | Minder KV-heads; ondersteunde KV-quantization; efficiënte attention | Modelarchitectuur en ondersteuning van de cacheprecisie |
| Grote prefill benut matrixeenheden intensief | Efficiënte matrix-kernels; ondersteunde berekeningen met lagere precisie | Korte prompts, kleine batches, andere bewerkingen |
| Veel korte kernels laten onderbrekingen in de GPU-uitvoering ontstaan | Fusie of minder overhead bij het starten | Extra gebruik van registers en gedeeld geheugen |
Meet na elke wijziging zowel de latency tot de eerste token als de intervallen tussen latere tokens. Een grotere batch kan het totale aantal tokens per seconde verhogen en tegelijk elke aanvraag vertragen. De hardwareverhouding wijst op een mogelijke beperking; een trace laat zien op welke resource jouw werklast daadwerkelijk wacht.
Engineering Guide: inference beperkt door geheugen of rekenkracht bevat het roofline-diagram en optimalisaties per fase.