GPU-Kapazitätsplanung für eine LLM-Plattform: wann der nächste Server nötig ist und wie Sie darüber entscheiden

LLM-Kapazitätsplanung: wann der nächste GPU-Server nötig ist

Bei der GPU-Kapazitätsplanung für eine LLM-Plattform planen Sie den nächsten GPU-Server ein, wenn die gemessene Last der Spitzenstunde, mit Ihrer Nutzungsprognose fortgeschrieben, eine Reserveschwelle überschreitet, die Sie für die Kapazität bei Ausfall eines Servers festlegen. Die Eingangsdaten sind die Metriken der Plattform in der stärksten Stunde jedes Arbeitstages (Anfragen und Token, KV-Cache-Belegung, Wartezeit und das 95. Perzentil der Zeit bis zum ersten Token) und eine Prognose der Nutzer und Anwendungsfälle je Quartal. Modellentscheidungen wie ein größeres Modell, ein längerer deklarierter Kontext, Reasoning oder Agenten verändern die Last in Sprüngen, oft stärker als eine neue Abteilung. On-premise ist Kapazität ein Kauf; die Entscheidung gehört daher in ein Review je Quartal und sollte früh fallen.

Das Rechenbeispiel in diesem Artikel ist eine Plattform für 2.000 Mitarbeiter mit gpt-oss-120b bei deklarierten 32K Kontext und einem 16-Bit-KV-Cache. Es verwendet die Beispielwerte unseres Leitfadens zu privaten ChatGPT-Servern nach Unternehmensgröße: 40 Prozent der Mitarbeiter in der stärksten Stunde aktiv, je 6 Anfragen pro Stunde, 30 Sekunden je Anfrage und ein Spitzenfaktor von 2. Mit diesen Werten beträgt die Spitzenzahl der Anfragen in Bearbeitung 4 Prozent der Mitarbeiter mit Zugang, nach unserer Rechnung 80 für alle 2.000.

Eingangsdaten: Metriken der Spitzenstunde und eine Nutzungsprognose

Die Dokumentation von vLLM hält fest: „Diese Metriken werden über den Endpunkt /metrics auf dem OpenAI-kompatiblen API-Server von vLLM bereitgestellt.“ Die Kapazitätsplanung nutzt die Gauges vllm:num_requests_running, vllm:num_requests_waiting und vllm:kv_cache_usage_perc, die Histogramme für die Zeit bis zum ersten Token und die Wartezeit der Anfragen sowie die Token-Zähler vllm:prompt_tokens und vllm:generation_tokens, die Prometheus mit dem Suffix _total anzeigt. Was jede Metrik misst und welche Alarme wir darauf vorschlagen, steht in unserem Leitfaden zu LLM-Serving-Metriken in Prometheus. Führen Sie mindestens ein Jahr lang je Arbeitstag eine Zeile mit der Spitze aus laufenden plus wartenden Anfragen in der Spitzenstunde, der höchsten KV-Cache-Belegung, dem Anteil der Anfragen, die gewartet haben, dem 95. Perzentil der Zeit bis zum ersten Token am Gateway und den erzeugten Token.

DCGM-Exporter stellt laut NVIDIAs Dokumentation, aktualisiert am 27. Mai 2026, „GPU-Metriken an einem HTTP-Endpunkt (/metrics) für Monitoring-Lösungen wie Prometheus bereit“, standardmäßig auf Port 9400. Seine Werte für Leistungsaufnahme und Temperatur gelten je GPU. Die Leistungsaufnahme des ganzen Servers, Prozessoren und Lüfter eingeschlossen, kommt vom BMC oder von der Rack-PDU, und beide zeigen, wie viel von Rack-Zuleitung und Kühlung der nächste Server noch nutzen kann. Belegter Speicher ist unter vLLM kein Lastsignal, denn dort legt --gpu-memory-utilization „den Anteil des GPU-Speichers, der für den Model Executor verwendet werden soll“ fest, standardmäßig 0,92. Die Engine belegt ihren Anteil beim Start, und der Cache in diesem Anteil füllt und leert sich mit dem Verkehr. Die GPU-Auslastung ist laut der Dokumentation von nvidia-smi der „Prozentsatz der Zeit im vergangenen Abtastzeitraum, in der ein oder mehrere Kernel auf der GPU ausgeführt wurden“, unabhängig davon, welchen Anteil der GPU diese Kernel nutzen.

Die Prognose kommt aus den Fachabteilungen. Halten Sie für jeden Anwendungsfall je Quartal fest, wie viele Mitarbeiter Zugang erhalten, welchen Anteil davon Sie in der stärksten Stunde erwarten, die Anfragen pro Stunde, die Token je Anfrage, das Modell und den deklarierten Kontext.

Kapazität je Server: Speicher und Latenz

Für die Planung ist die Kapazität eines Servers der kleinere von zwei Werten. Der eine ist die Zahl der Gespräche, die sein KV-Cache beim deklarierten Kontext neben den Gewichten hält; vLLM gibt sie beim Start aus, und unsere Schätzungen setzen sie für das Beispielmodell bei 19 je RTX PRO 6000 und 55 je H200 NVL an. Der andere ist die Zahl der Anfragen in Bearbeitung, bei der ein Lasttest mit Ihren eigenen Prompts die Ziele für die Zeit bis zum ersten Token und für die Token pro Sekunde je Nutzer noch einhält.

NVIDIAs Leitfaden zum NIM-Benchmarking, aktualisiert am 20. Juli 2026, beschreibt, warum der zweite Wert oft niedriger ist: „Mit steigender Zahl gleichzeitiger Anfragen steigen die gesamten TPS des Systems, während die TPS je Nutzer sinken, da die Latenz zunimmt.“ Der Gesamtdurchsatz steigt, bis der Server „die verfügbaren GPU-Rechenressourcen sättigt“, und der Leitfaden ergänzt: „Jenseits dieses Punkts können die TPS sinken.“ Führen Sie den Lasttest auf dem GPU-Typ durch, den die Produktion nutzt, und wiederholen Sie ihn nach jedem Upgrade der Engine, jedem Modellwechsel und jeder Änderung der Kontextlänge.

Planungsschwellen und Maßnahmen

Planungsschwellen liegen unter Alarmschwellen. Ein Alarm sagt dem Betrieb, dass Nutzer jetzt warten; eine Planungsschwelle sagt Ihnen, dass über den nächsten Server entschieden werden sollte, solange die vorhandenen die Last noch bewältigen. Lesen Sie jeden Wert in der Spitzenstunde ab, an den meisten Arbeitstagen eines Monats, nicht als Mittelwert über den Tag.

Die Schwellwerte sind unsere Beispielwerte, nicht die von vLLM oder NVIDIA; legen Sie eigene fest und halten Sie sie schriftlich fest. Metriknamen aus der Metrik-Dokumentation von vLLM (latest, abgerufen am 10. Oktober 2026); Leistungsaufnahme des Servers vom BMC oder von der Rack-PDU, Leistungsaufnahme der GPUs von DCGM-Exporter.

Die Alarmbeispiele im Monitoring-Leitfaden feuern bei einem KV-Cache über 0,9 für 15 Minuten, während der Planungswert hier bei 0,8 in der Spitzenstunde liegt. Eine Warteschlange bei noch freiem Platz im Cache deutet auf eine Einstellung des Schedulers hin, wie der Monitoring-Leitfaden erklärt.

Reserveregel und N+1-Kapazität

Eine Reserveregel legt fest, wie viel der Kapazität die prognostizierte Spitze nutzen darf. Unsere Beispielregel erlaubt 80 Prozent der Kapazität, die bei Ausfall des größten Servers bleibt, als Spielraum für einen Spitzenfaktor, der nur eine Schätzung ist, und für eine Latenz, die steigt, bevor der Cache voll ist. N+1 bedeutet, dass die übrigen Server die Spitze tragen, während einer wegen eines Ausfalls oder eines Updates nicht verfügbar ist, und unser Leitfaden zur LLM-Hochverfügbarkeit mit zwei GPU-Knoten zeigt die Health Checks und das Failover dahinter.

Jeder Server muss jedes Modell des Dienstes allein vorhalten, einschließlich des Embedding-Modells und des Rerankers eines RAG-Assistenten. Im Beispiel mit 2.000 Mitarbeitern halten zwei Server mit je fünf RTX PRO 6000 bei Ausfall eines Servers 95 Sitzungen. Das deckt die Spitze von 80, aber 80 sind 84 Prozent von 95 und liegen damit über der Beispielgrenze. Zwei Server mit je zwei H200 NVL halten 110 und bleiben innerhalb der Grenze.

Wachstumspfad von einem über zwei auf vier Server

Die Tabelle folgt der Beispieleinführung von einer Abteilung bis zu allen 2.000 Mitarbeitern, mit einer Kopie des Modells je Karte hinter einem Load Balancer und Servern derselben Bauart; die Alternativen in der letzten Phase behalten zwei Server.

Unsere Schätzungen: Spitzen aus den Beispielwerten unseres Leitfadens zur Unternehmensgröße; Sitzungen von gpt-oss-120b bei 32K mit 16-Bit-KV-Cache, 19 je RTX PRO 6000 und 55 je H200 NVL, eine Kopie je Karte; 80 Prozent ist unsere Beispielgrenze; RAG-Modelle brauchen zusätzlich Platz auf jedem Server.

Mehr Server mit je zwei Karten verlieren bei einem Ausfall einen kleineren Teil der Kapazität, in der letzten Phase ein Viertel, und jeder Kauf ist ein kleiner Schritt. Sie brauchen aber auch mehr Rack-Plätze, Stromzuleitungen, Switch-Ports und Knoten, die gepatcht werden müssen. Weniger, größere Server halten die Zahl der Knoten niedrig, aber jeder Schritt ist größer, und bei zwei Servern ist in der Spitze die Hälfte aller Karten Reserve. Einen Server von zwei auf vier oder acht Karten zu erweitern, funktioniert nur, wenn er für die endgültige Zahl bestellt wurde, wie unser Leitfaden zur Planung eines GPU-Servers für Wachstum erklärt; legen Sie den Pfad deshalb bei der ersten Bestellung fest.

Wir bauen KI-Server mit 2 bis 8 GPUs je Knoten und liefern jeden weiteren Server unter einem EU-Vertrag und auf einer Rechnung. Schicken Sie uns Ihre Werte aus der Spitzenstunde und Ihre Einführungsprognose über das Formular unten, und wir legen den nächsten Schritt danach aus.

Sprünge durch Modellentscheidungen, nicht nur durch Nutzer

Nutzer erhöhen die Last allmählich, eine Modellentscheidung verändert sie an dem Tag, an dem sie live geht. Jede solche Änderung gehört mit ihrem geplanten Datum in die Prognose.

Unsere früheren Schätzungen und illustrativen Beispiele, im Text verlinkt; keine davon ist eine Messung, und ein Pilot oder Lasttest mit Ihren Prompts ersetzt jede davon.

Unser Leitfaden zur Hardware für Reasoning-Modelle leitet die Reasoning-Zeile aus der Zeit in Bearbeitung her, und unser Leitfaden zum GPU-Sizing für KI-Agenten zeigt, warum bei Agenten die Zeit je Schritt stärker als der Speicher die Hardware bestimmt. Bevor eine solche Änderung live geht, wiederholen Sie den Lasttest und zählen die Kapazität je Server neu.

Quartalsweises Kapazitätsreview und die Kaufentscheidung

Kubernetes beschreibt seinen Horizontal Pod Autoscaler mit diesen Worten: „Horizontale Skalierung bedeutet, dass die Reaktion auf erhöhte Last darin besteht, weitere Pods bereitzustellen.“ Auf einem festen Bestand an GPU-Servern braucht ein neuer vLLM-Pod eine GPU oder MIG-Instanz des passenden Typs, die kein anderer Pod belegt; Autoscaling kann also GPUs zwischen Modellen verschieben, fügt aber keine hinzu. Der nächste Server ist eine Kaufentscheidung, und ein Review je Quartal ist dafür ein praktikabler Rhythmus.

1. Exportieren Sie die Zeilen der Spitzenstunden des Quartals und vergleichen Sie sie mit den Schwellwerten der ersten Tabelle.
2. Zählen Sie die Kapazität bei Ausfall des größten Servers neu, auf Basis des letzten Lasttests und der aktuellen Engine-Version.
3. Aktualisieren Sie die Prognose mit den Fachabteilungen: neue Abteilungen, neue Anwendungsfälle und geplante Änderungen an Modell, Kontext oder Reasoning-Stufe.
4. Schreiben Sie die Spitze Quartal für Quartal für das nächste Jahr fort und markieren Sie das erste Quartal, das die Reserveregel überschreitet.
5. Überschreitet ein Quartal sie, wählen Sie den Schritt (Karten in Servern, die dafür bestellt wurden, ein weiterer Server oder eine andere Karte) und starten Sie die Bestellung zusammen mit den Prüfungen von Rack, Strom und Netzwerk.
6. Halten Sie die Schwellwerte, die Entscheidung und ihre Begründung fest, damit das nächste Review dort ansetzt.

Treffen Sie die Entscheidung in dem Review, in dem die Prognose die Regel zum ersten Mal überschreitet, denn der neue Server braucht außerdem einen Rack-Platz, eine Stromzuleitung, Netzwerkports, die Installation und einen Lasttest, bevor er Verkehr trägt.

Wir liefern Konfiguration und Angebot innerhalb eines Werktages und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie den Schritt, auf den Ihr letztes Review hingewiesen hat, im Formular unten.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. Zu den Karten gehören die RTX PRO 6000 Server Edition, die H200 NVL mit NVLink-Bridges, die L40S und die L4 aus unserem Sortiment professioneller NVIDIA-GPUs, und Lizenzen für NVIDIA AI Enterprise und vGPU kommen auf dieselbe Rechnung. Bei einem vorhandenen Server prüfen wir Plattform, Stromversorgung und Kühlung, bevor Sie Karten nachrüsten. Was darauf läuft, die privaten LLMs, RAG und MLOps, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ