GPU-Server für ein 70B-Modell dimensionieren: ein Rechenbeispiel von den Gewichten bis zur Steckdose

Die Anfrage

Ein Fertigungsunternehmen will einen internen Assistenten auf Llama 3.3 70B: Fragen zu Dokumenten, Entwürfe, Zusammenfassungen. Dreißig Personen nutzen ihn möglicherweise gleichzeitig, Gespräche kommen auf rund 8.000 Token Kontext, und die Antworten müssen in Lesegeschwindigkeit streamen. Nichts verlässt das Gebäude. Das ist die Anfrage, die wir am häufigsten sehen, hier also das Arbeitsblatt zur Dimensionierung in der Reihenfolge, in der unser Engineering-Partner Vixen.UNO es durchgeht.

Schritt 1: die Gewichte

Llama 3.3 70B hat 70,6 Milliarden Parameter. Die Bytes pro Parameter bestimmen den Platzbedarf: zwei in FP16, eines in FP8 und 0,5625 in NVFP4, weil sich jeweils sechzehn Werte eine FP8-Skala teilen.

Quellen: Llama-3-Paper und Modellkarten, NVIDIA-Checkpoint-Karten auf Hugging Face, technischer NVFP4-Blog von NVIDIA.

FP16 sind 132 GiB: Allein die Gewichte füllen eine H200 NVL mit rund 9 GiB Rest, was kein Platz für dreißig Nutzer ist, und auf eine 96-GB-Karte passen sie gar nicht; das ist ein Job für zwei oder vier Karten oder ein anderes Modell. FP8 und NVFP4 sind die echten Kandidaten, und die Wahl zwischen ihnen gehört demjenigen, der den Evaluationssatz verantwortet: Zwei Punkte im MMLU sind nichts für einen Zusammenfasser und alles für ein Compliance-Werkzeug.

Schritt 2: der KV-Cache

Jedes Token eines laufenden Gesprächs hält seine Keys und Values für die gesamte Sitzung im GPU-Speicher. Die Größe pro Token ist 2 × Schichten × KV-Heads × Head-Dimension × Bytes. Für Llama 3 70B sind das 2 × 80 × 8 × 128 = 163.840 Werte: 320 KiB pro Token in FP16, 160 KiB in FP8. Moderne Server halten den Cache in FP8.

Dreißig Nutzer mit je 8.192 Token: 30 × 8.192 × 160 KiB = 37,5 GiB. Dazu rund 10 % für Aktivierungen, den CUDA-Kontext und Fragmentierung, und der Speicherplan sieht so aus.

TP = tensor-parallel über zwei Karten. Die Summen enthalten rund 8 GiB Overhead (10 GiB bei zwei Karten) für Aktivierungen, den CUDA-Kontext und Fragmentierung. Die Kapazitäten sind das, was der Treiber meldet: nvidia-smi zeigt 97.887 MiB (95,6 GiB) für die RTX PRO 6000 und 143.771 MiB (140,4 GiB) für die H200 NVL.

Das ist die Tabelle, die die meisten Dimensionierungsanfragen beantwortet. Die 96-GB-Karte ist für diese Arbeitslast nur in NVFP4 eine Ein-Karten-Lösung, und bei 90 % Auslastung bleibt wenig Platz für einen längeren Kontext oder fünf weitere Nutzer; das ist eine Pilotkonfiguration, kein Produktionsendpunkt. Die H200 NVL nimmt das FP8-Modell mit rund 26 GiB Reserve auf. Zwei Blackwell-Karten nehmen es in FP8 mit 75 GiB Reserve auf, auf Kosten von Tensor-Parallel-Verkehr über PCIe, da diese Karten kein NVLink haben.

Schritt 3: Ist es schnell genug?

Zwei Geschwindigkeiten zählen. Die erste ist, was eine einzelne Person sieht: Die Generierung im Einzelstrom ist bandbreitenlimitiert, und die Obergrenze ist Bandbreite geteilt durch die pro Token gelesenen Gewichts-Bytes. Für das FP8-Modell sind das rund 68 Token pro Sekunde auf der H200 NVL (4.800 GB/s) und rund 23 auf einer RTX PRO 6000 (1.597 GB/s); für NVFP4 auf der Blackwell-Karte rund 40. Lesegeschwindigkeit liegt unter 10 Token pro Sekunde, also bestehen alle drei für einen Nutzer.

Die zweite ist der Gesamtdurchsatz unter Last mit einem Latenzversprechen. Das interaktive Szenario von MLPerf Inference v6.0 für Llama 2 70B begrenzt die Zeit bis zum ersten Token auf 450 ms und die Zeit pro Token auf 40 ms. Acht H200 NVL in einem Dell XE7740 erreichten 16.344 Token pro Sekunde, rund 2.040 pro Karte; ein System mit acht RTX PRO 6000 erreichte 6.238, rund 780 pro Karte (beides Ergebnisse von Acht-GPU-Systemen, durch acht geteilt). Dreißig Nutzer, die mit 10 Token pro Sekunde lesen, brauchen 300 Token pro Sekunde in Summe, mit Spitzen darüber. Eine Karte jeder Art trägt das; die H200 NVL trägt es mit dem FP8-Modell und zweieinhalbfacher Reserve.

Läuft auf demselben Server auch nächtliche Batch-Arbeit, zählt der FP4-Durchsatz der Blackwell-Karte: NVIDIAs TensorRT-LLM-Tabelle zeigt 1.724 Ausgabe-Token pro Sekunde je RTX PRO 6000 bei diesem Modell in FP4 mit Prompts von 1.000 Token, und 296 mit Prompts von 8.192 Token. Lange Prompts sind überall teuer.

Schritt 4: der Server um die Karte herum

Herstellergrenzen stammen aus aktuellen Product Guides; die Regeln zu Systemspeicher und Storage sind unsere Engineering-Praxis, keine Herstellerspezifikation.

Zwei Zeilen verdienen einen Kommentar. Der Lenovo SR650a V4 nimmt vier L40S mit 350 W auf, aber nur zwei H200 NVL mit 600 W, sodass dasselbe 2U, das vier Steckplätze verspricht, zwei der Karten fasst, die dieses Design will. Und die H200 NVL bringt eine fünfjährige NVIDIA-AI-Enterprise-Subscription mit, die diese Installation für den Inferenz-Stack nutzen wird; die RTX PRO 6000 nicht, und diese Lizenz ist eine eigene Position im Angebot.

Was wir bestellen würden

Für dreißig Nutzer, 8k Kontext und ein FP8-Modell wie spezifiziert: eine H200 NVL in einem 2U mit einem freien zweiten Steckplatz, an einer 16-A-Zuleitung, in einer Halle mit 25 °C oder weniger. Sie passt mit rund 26 GiB Reserve, sie trägt die interaktive Last mit Spielraum, und die Lizenz kommt mit.

Akzeptiert der Evaluationssatz NVFP4 und ist das Budget eine Blackwell-Karte: Eine RTX PRO 6000 Server Edition erledigt denselben Job bei gleicher Leistungsaufnahme mit fast keinem freien Speicher, was für einen Pilot in Ordnung und für einen Dienst, der wachsen muss, falsch ist; der ehrliche Plan sind zwei davon von Anfang an, in FP8, mit 75 GiB frei. Wächst der Kontext für alle auf 32k, ändern sich beide Pläne, weil allein der Cache 150 GiB wird und das Gespräch zu vier Karten oder zu einem kleineren Modell wandert.

Dieser letzte Satz ist der Sinn des Arbeitsblatts. Die Karte ist nie die erste Entscheidung; die Kontextlänge und die Zahl der Nutzer sind es, und das sind die beiden Zahlen, ohne die die meisten Anfragen bei uns ankommen.

FAQ