Wie plant man GPU-Kapazität und Autoscaling für LLMs?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Dimensionieren Sie die Gesamtkapazität anhand des gemessenen Throughput bei der erforderlichen Latency. Prüfen Sie dann, ob jedes Replikat die vorgesehene Zahl aktiver Sequenzen aufnehmen kann. Verwenden Sie reale Verteilungen der Prompt- und Ausgabelängen. Runden Sie auf vollständige Serving-Replikate auf, einschließlich aller GPUs, die für Tensor- oder Pipeline-Parallelismus erforderlich sind.
Speicher vor Throughput prüfen
Bei einem konventionellen Cache-Layout mit vollständiger Attention benötigt Llama 3.1 70B für eine Sequenz mit 4,096 Tokens 1.25 GiB FP16-KV-Daten. Ein hypothetisches KV-Speicherbudget von 40 GiB reicht daher für höchstens 32 solcher Sequenzen, bevor zusätzlicher Speicherbedarf durch den Allocator und die Runtime berücksichtigt wird. Bei 131,072 Tokens belegt eine Sequenz die gesamten 40 GiB.
Zählen Sie Eingabe- und generierte Tokens zusammen. Für Architekturen wie MLA und Sliding-Window-Attention ändert sich die Formel; die Speicherzuweisung pro Gerät hängt vom Sharding ab. Das ist eine Speichergrenze, keine Vorhersage der Batchgröße, die die Latency-Ziele erfüllt. Die KV-cache-Berechnung im Leitfaden zeigt die Annahmen und eine ausführbare Berechnung.
Ganze Replikate berechnen
Angenommen, Messungen haben gezeigt, dass ein Replikat mit zwei GPUs bei der erforderlichen TTFT und TPOT für eine feste Workload dauerhaft 1,200 Ausgabe-Tokens pro Sekunde verarbeiten kann. Der erwartete Spitzenbedarf liegt bei 4,000 Ausgabe-Tokens pro Sekunde. Ein hypothetischer Sicherheitsfaktor von 1.3 ergibt:
Fünf Replikate mit jeweils zwei GPUs benötigen zehn GPUs. Diese Zahlen veranschaulichen die Berechnung; sie sind keine Hardware-Benchmark-Ergebnisse. Messen Sie erneut, wenn sich das Model, die Kontextverteilung, die Topologie oder das SLO ändert. Ein Faktor von 1.3 bedeutet vor dem Aufrunden 30% mehr Throughput als benötigt, nicht 30% ungenutzte Kapazität.
Skalieren, bevor Zeitvorgaben verletzt werden
Kombinieren Sie Warteschlangenlänge und Wartezeit mit KV-Nutzung, Preemptions und SLO-konformem goodput. Die GPU-Auslastung kann hoch bleiben, nachdem der Dienst bereits überlastet ist. vLLM dokumentiert diese Serving-Metriken; leiten Sie die Schwellenwerte aus Load Tests ab.
Messen Sie Image-Downloads, das Laden der Model Weights, die Model-Initialisierung und das Warmup, bevor Sie Autoscaling-Schwellenwerte festlegen. KEDAs Steuerung der Deployment-Skalierung kann Workloads bis auf null herunterfahren, beseitigt aber nicht die Latency beim Model-Start. Halten Sie betriebsbereite Kapazität vor, wenn Anfragen nicht auf den Start warten können.
Lesen Sie Kapazitätsplanung und Autoscaling im Leitfaden, um die damit verbundenen Hardware- und Zulassungsentscheidungen nachzuvollziehen.