Hoe plan je GPU-capaciteit en autoscaling voor LLMs?
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Bepaal de totale capaciteit op basis van gemeten throughput bij de vereiste latency en controleer vervolgens of elke replica de beoogde actieve sequenties kan bevatten. Gebruik echte verdelingen van prompt- en uitvoerlengtes. Rond naar boven af op volledige serving-replica’s, inclusief alle GPUs die nodig zijn voor tensor- of pipeline-parallelisme.
Controleer het geheugen vóór de throughput
Bij een conventionele cache-indeling met volledige attention heeft Llama 3.1 70B 1.25 GiB aan FP16-KV-data nodig voor een sequentie van 4,096 tokens. Een hypothetisch KV-geheugenbudget van 40 GiB biedt daarom ruimte voor maximaal 32 van zulke sequenties, vóór de overhead van de allocator en runtime. Bij 131,072 tokens gebruikt één sequentie de volledige 40 GiB.
Tel invoertokens en gegenereerde tokens bij elkaar op. De formule verandert voor architecturen zoals MLA en sliding-window attention, en de toewijzing per apparaat hangt af van sharding. Dit is een geheugenlimiet, geen voorspelling van de batchgrootte die aan de latency-doelen voldoet. De KV-cache-berekening in de gids toont de aannames en een uitvoerbare berekening.
Bereken volledige replica’s
Stel dat metingen laten zien dat een replica met twee GPUs bij de vereiste TTFT en TPOT voor een vaste workload 1,200 uitvoertokens per seconde kan blijven leveren. De verwachte piekvraag is 4,000 uitvoertokens per seconde. Een hypothetische veiligheidsfactor van 1.3 geeft:
Vijf replica’s met elk twee GPUs vereisen tien GPUs. Deze cijfers illustreren de berekening; het zijn geen hardware-benchmarkresultaten. Meet opnieuw als het model, de contextverdeling, de topologie of de SLO verandert. Een factor van 1.3 betekent vóór het afronden 30% meer throughput dan de vraag, geen 30% ongebruikte capaciteit.
Schaal voordat tijdslimieten worden overschreden
Combineer de wachtrijlengte en wachttijd met KV-gebruik, preëmpties en goodput die aan de SLO voldoet. De GPU-bezetting kan hoog blijven nadat de dienst overbelast raakt. vLLM documenteert deze serving-meetwaarden; leid drempelwaarden af uit load tests.
Meet het downloaden van images, het laden van model weights, de initialisatie van het model en de opwarmfase voordat je autoscaling-drempelwaarden kiest. KEDA’s instellingen voor deployment-scaling kunnen workloads tot nul terugschalen, maar nemen de latency bij het opstarten van het model niet weg. Houd capaciteit gereed wanneer verzoeken niet op het opstarten kunnen wachten.
Lees capaciteitsplanning en autoscaling in de gids voor de bijbehorende beslissingen over hardware en het toelaten van verzoeken.