GPU-Kapazität für ein Modell planen, das Ihr Team selbst betreibt

Was eine einzelne Replika begrenzt

Der GPU-Speicher hält die Modellgewichte und den KV-Cache, der mit der Kontextlänge und der Zahl gleichzeitig laufender Sequenzen wächst. Sind die Gewichte geladen, bestimmt der KV-Cache, wie viele Anfragen eine Replika bündeln kann, und die Bündelung bestimmt den Durchsatz. Das PagedAttention-Paper hinter vLLM zeigte, dass verschwendeter KV-Cache-Speicher die Batchgrößen begrenzt hatte und dass eine seitenweise Verwaltung den Durchsatz bei gleicher Latenz erhöhte.

In vLLM bestimmt gpu_memory_utilization, wie viel Speicher die Instanz belegt, laut aktueller Dokumentation standardmäßig 0,92, und max_model_len sowie max_num_seqs begrenzen Kontext und Parallelität. Reicht der KV-Cache nicht, unterbricht vLLM Anfragen und berechnet sie neu, was laut Dokumentation die Latenz verschlechtern kann. Quantisierte Gewichte oder ein kleinerer Datentyp für den KV-Cache schaffen Platz für mehr gleichzeitige Anfragen, zu einem Qualitätspreis, den Sie testen müssen.

Die Arbeitslast beschreiben, bevor Sie benchmarken

Ein Benchmark mit synthetischen Prompts fester Länge beantwortet eine Frage, die niemand gestellt hat. Halten Sie vor dem Messen fest:

• Ankünfte pro Sekunde nach Stunde und Wochentag, mit den verkehrsreichsten fünf Minuten statt des Stundenmittels
• Die Verteilung von Ein- und Ausgabetoken pro Anfrage, weil wenige lange Anfragen einen großen Teil des KV-Cache belegen
• Latenzziele pro Funktion, etwa p95 für die Zeit bis zum ersten Token und für die Zeit pro Ausgabetoken
• Welche Arbeit interaktiv ist und welche warten kann, etwa nächtliche Dokumentverarbeitung

Eine Replika bei Ihrem Latenzziel benchmarken

Der Serving-Benchmark von vLLM kann einen eigenen Datensatz Ihrer Prompts mit gewählter Anfragerate abspielen, mit einstellbarer Burstiness und optionaler Begrenzung der Parallelität, und Goodput ausweisen: die Anfragen, die Ihre Ziele für erstes Token, Zeit pro Token und Gesamtzeit erreicht haben. Erhöhen Sie die Rate schrittweise, bis der Goodput unter den nötigen Anteil fällt. Diese Rate ist die Kapazität der Replika für diese Arbeitslast. Der Offline-Durchsatz-Benchmark beantwortet eine andere Frage, nämlich die nach maximalen Token pro Sekunde ohne Latenzziel, und eignet sich für die Bemessung von Batch-Jobs.

Beobachten Sie während des Benchmarks die Metriken des Servers, werten Sie sie aber als Hinweise. Steigende Warteschlangenzeit bei fast vollem KV-Cache deutet auf Speicherdruck hin, langsamere Generierung bei freiem Cache auf Rechenleistung, doch beides kann zusammen auftreten, und Scheduler-Einstellungen beeinflussen beides. Prüfen Sie, bevor Sie die Grenze benennen, die Zahl der Preemptions, die Auslastung von GPU-Rechenleistung und Speicherbandbreite sowie die Zahl laufender Anfragen, und wiederholen Sie den Lauf mit kontrollierten Änderungen an Parallelität und Kontextlänge, um zu sehen, welche das Ergebnis verschiebt.

Von einer Replika zur Flotte: ein Rechenbeispiel

Alle Zahlen sind hypothetisch. Ein interner Assistent erreicht werktags morgens Spitzen von 18 Anfragen pro Sekunde und fällt nachts und am Wochenende auf 2. Mit echten Prompts hält eine Replika auf einer GPU bis 5 Anfragen pro Sekunde 99 Prozent Goodput. Bei 6 drückt die Warteschlangenzeit den Goodput auf 93 Prozent.

1. 1

   Repliken für die Spitze

   18 geteilt durch 5 ergibt 3,6, also tragen 4 Repliken die Spitze.

2. 2

   Reserve für Ausfälle

   Eine weitere Replika deckt einen ausgefallenen Knoten oder ein rollendes Deployment ab, macht 5.

3. 3

   Ruhige Stunden

   Bei 2 Anfragen pro Sekunde genügt 1 Replika, plus 1 Reserve.

4. 4

   Zeitpläne vergleichen

   Fünf Repliken rund um die Uhr verbrauchen etwa 3.650 GPU-Stunden pro Monat. Fünf für 12 Stunden an 22 Werktagen und 2 für die übrigen Stunden verbrauchen etwa 2.250, rund 38 Prozent weniger.

Der Zeitplan funktioniert nur, wenn die Repliken vor dem morgendlichen Anstieg bereitstehen. Ein Modell lädt nicht sofort, skalieren Sie also nach Fahrplan hoch, statt zu warten, bis Warteschlangen wachsen. vLLM dokumentiert Wege, wiederholte Starts zu verkürzen, etwa die Wiederverwendung des Compile-Cache. Nächtliche Batch-Arbeit kann dann auf der Reserve-Replika laufen statt auf einer eigenen Flotte.

Festlegen, was Traffic über dem Plan auffängt

Kein Plan deckt jede Spitze ab. Wählen Sie vorab zwischen drei Optionen. Eine begrenzte Warteschlange hält die Latenz berechenbar und weist überzählige Last früh ab. Ein gehostetes Modell als Überlauf hält Antworten im Fluss, sofern es dieselben Qualitätstests bestanden hat und Ihre Datenvorgaben es zulassen. Das Verschieben nicht dringender Arbeit nimmt Batch-Jobs aus der Spitze. Jede Wahl hat ihren Preis, und wer ihn vor dem Start festlegt, vermeidet den Reflex, GPUs für eine Spitze zu kaufen, die zweimal im Jahr auftritt.