Was verursacht Lücken bei der GPU-Auslastung während kontinuierlicher LLM-Batch-Verarbeitung?

Lücken bei der GPU-Auslastung treten meist auf, wenn der Scheduler für kontinuierliches Batching keine ausführbare Arbeit zusammenstellen oder den Beschleuniger nicht versorgen kann, ohne dass eine Abhängigkeit den Ablauf blockiert.

Ein LLM-Server für zu Hause kann einen hohen Durchsatz melden und dennoch zwischen Decode-Iterationen regelmäßig Einbrüche bei der GPU-Auslastung zeigen. Kontinuierliches Batching entfernt abgeschlossene Sequenzen und nimmt neue auf, kann jedoch keine Arbeit erzeugen, wenn Anfragen nur sporadisch eintreffen, KV-Blöcke nicht verfügbar sind, lange Prefills den Decode-Vorgang blockieren oder die CPU-Laufzeitumgebung Batches zu langsam vorbereitet. Synchronisierung und Speicherbewegungen können selbst bei einer vollständig gefüllten Anfragewarteschlange Lücken verursachen.

Anfragezufuhr und Sequenzwechsel können einen Batch leeren

Kontinuierliches Batching ersetzt abgeschlossene Sequenzen an den Iterationsgrenzen. Wenn Anfragen stoßweise eintreffen, Ausgaben gleichzeitig fertig werden oder Zulassungsgrenzen Anfragen außerhalb der ausführbaren Warteschlange zurückhalten, kann die Zahl aktiver Tokens unter den effizienten Betriebsbereich der GPU fallen.

Benchmarks zur Mitgliedschaft in kontinuierlichen Batches vergleichen die statische und kontinuierliche Anfragezugehörigkeit bei unterschiedlichen Eingabelängen, Ausgabelängen und Ankunftszeiten. Charakteristisch ist eine geringe Anzahl ausführbarer Tokens während der Auslastungslücken trotz eines gesunden Beschleunigers und ohne Speicherfehler.

Eine tatsächlich leere Warteschlange ist kein Fehler des Schedulers. Vergleichen Sie Ankunftsrate, zugelassene Sequenzen und pro Iteration geplante Tokens, bevor Sie jedes Leerlaufintervall als verlorene Kapazität interpretieren. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Prefill, Decode und KV-Zuweisung erzeugen Scheduler-Lücken

Beim Prefill werden viele Prompt-Tokens mit rechenintensiven Kernels verarbeitet, während Decode jede Sequenz um ein Token voranbringt und häufig speichergebunden ist. Die Vermischung der Phasen kann den Decode-Vorgang verzögern, und das Reservieren oder Freigeben von KV-Blöcken kann die Aufnahme zwischen den Iterationen pausieren.

Das Design der Chunked-Prefill-Planung verwendet ein aufgeteiltes Prefill, um zu verhindern, dass lange Prompts die Serving-Iterationen monopolieren. Sein Mechanismus identifiziert Lücken, die mit Prefill-Grenzen, KV-Zuweisung oder der Verdrängung von Anfragen zusammenhängen, statt mit einer zu geringen Nachfrage. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Wenn GPU-Lücken mit der Prompt-Länge zunehmen, nicht aber mit der Ausgabelänge, ist die Prefill-Planung die wahrscheinlichere Ursache. Folgen sie hingegen dem Cache-Druck oder Auslagerungen, ist die Speicherzulassung verantwortlich, selbst wenn die Warteschlange voll bleibt. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

CPU-Versorgung und geräteübergreifende Synchronisierung können Kernels aushungern

Tokenisierung, Sampling, Scheduler-Entscheidungen, Tensor-Metadaten, Kopien vom Host zum Gerät, verteilte Kollektivoperationen und Protokollierung finden außerhalb der Haupt-Kernels statt. Ein ausgelasteter CPU-Thread oder eine blockierende Synchronisierung kann dazu führen, dass die GPU zwischen ansonsten gültigen Batches wartet. Die praktische Folge zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Forschungen zu Interferenzen zwischen Prefill und Decode trennen Prefill- und Decode-Ressourcen, um Interferenzen zu verringern und Latenzziele einzuhalten. Das Ergebnis bestätigt, dass ein einzelnes Auslastungsdiagramm das Verhalten von Scheduler, Host, Kommunikation und Beschleuniger zusammenfasst. Diese Abhängigkeit sollte in der finalen Benutzeroberfläche ausdrücklich erhalten bleiben.

Die Fehlergrenze ist ein kurzes Abtastintervall, das normale Kernel-Grenzen als null Auslastung meldet. Bestätigen Sie Lücken mit einem Trace oder Hardwarezählern; die Mittelwertbildung im Dashboard kann scheinbare Täler erzeugen, die den Durchsatz in Tokens pro Sekunde nicht verringern.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Warteschlangen-, Scheduler- und Kernel-Zeitverläufe abgleichen

Wiederholen Sie kontrollierte gleichmäßige und stoßweise Anfragen und zeichnen Sie wartende, zugelassene und laufende Anfragen, Prompt- und Decode-Tokens pro Iteration, freie KV-Blöcke, Verdrängungen, CPU-Zeit des Schedulers, Tokenisierung, Sampling, Kopien, Kollektivoperationen, Lücken beim Kernel-Start, GPU-Taktfrequenzen und Ausgabedurchsatz auf.

Vergleichen Sie das Muster mit dem Verhalten des kontinuierlichen Batchings und variieren Sie anschließend nacheinander Ankunftsrate, Prompt-Länge, Größe des aufgeteilten Prefills, Cache-Budget und CPU-Affinität. Behalten Sie Modell, Quantisierung und Latenzziel unverändert bei. Das Ergebnis muss daher mit den ursprünglichen Belegen abgeglichen werden.

Klassifizieren Sie jedes Tal vor der Optimierung als fehlende Nachfrage, Zulassungsstillstand, Prefill-Interferenz, Cache-Druck, Host-Mangel oder Synchronisierung. Optimieren Sie die verantwortliche Grenze; ein erzwungener größerer Batch kann weder eine leere Warteschlange noch einen blockierten Host-Thread beheben.