Wie tauscht die Batch-Verarbeitung von Home-KI Latenz gegen Durchsatz ein?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Batching von KI-Aufgaben im Heimnetz erhöht den Gesamtdurchsatz, indem kompatible Aufgaben gebündelt werden. Allerdings kann jede Anfrage länger warten oder sich langsamere Iterationen mit anderen Nutzern teilen.

Ein einzelner Prompt kann sofort einen ungenutzten Beschleuniger verwenden, während ein Familienserver häufig gleichzeitig Chats, Dokument-Prompts, Sprachanfragen und Hintergrundaufgaben erhält. Die Laufzeit kann eine Anfrage kurz zurückhalten, um einen Batch zu bilden, zwischen Decodierungsiterationen neue Sequenzen hinzuzufügen oder lange Prefills in kleinere Abschnitte aufzuteilen. Diese Entscheidungen halten den Beschleuniger besser ausgelastet, verändern jedoch auch die Zeit bis zum ersten Token, die Verzögerung zwischen Tokens und die Fairness. Die folgenden Abschnitte erklären, wann Batching hilft und ab welchem Punkt höhere Durchsatzwerte die interaktive Nutzung nicht mehr verbessern.

Batching wandelt freie Beschleunigerkapazität in gemeinsam verarbeitete Aufgaben um

Eine einzelne Anfrage nutzt möglicherweise nicht jede parallele Ausführungsspur effizient, insbesondere bei kleinen Matrixoperationen oder kurzen Sequenzen. Durch das Kombinieren mehrerer Anfragen entstehen größere Tensoroperationen, die den Beschleuniger effektiver nutzen können.

Orca führte Scheduling auf Iterationsebene ein. Dadurch können Anfragen zwischen Generierungsiterationen hinzukommen und ausscheiden, statt einen festen Batch zu erzwingen, der zusammenbleibt, bis jede Sequenz abgeschlossen ist.

Der Zugewinn wird anhand abgeschlossener Tokens oder Anfragen pro Zeiteinheit gemessen. Er garantiert nicht, dass ein einzelner Nutzer schneller ein Token erhält.

Ein Batch-Zeitfenster fügt vor dem Beginn der Berechnung Wartezeit hinzu

Eine Laufzeit, die auf weitere Anfragen wartet, kann einen größeren und effizienteren Batch bilden. Die erste Anfrage muss diese Wartezeit jedoch in Kauf nehmen, selbst wenn der Beschleuniger verfügbar war.

Der Zielkonflikt zwischen Durchsatz und Latenz wird sichtbar, wenn größere Batches die Geräteeffizienz verbessern, gleichzeitig aber die Warte- oder Iterationszeit verlängern.

Interaktive KI im Heimnetz benötigt normalerweise ein kurzes oder adaptives Batch-Zeitfenster. Hintergrundaufgaben zur Erstellung von Embeddings können mehr Wartezeit tolerieren, weil für sie die Menge abgeschlossener Arbeit wichtiger ist als eine dialogorientierte Antwort.

Lange Prefills können kurze Decodierungsaufgaben ausbremsen

Die Promptverarbeitung führt ein großes, rechenintensives Prefill durch, während aktive Gespräche wiederholt speichergebundene Decodierungsschritte ausführen. Werden beide in einem Batch gemischt, kann eine kurze interaktive Decodierung hinter einem langen Dokument-Prompt warten.

DistServe isoliert die Interferenz zwischen Prefill und Decodierung, da beide Phasen unterschiedliche Ressourcen- und Latenzeigenschaften haben.

Chunked Prefill ist ein Kompromiss: Ein langer Prompt wird aufgeteilt, sodass Decodierungsanfragen zwischen den Abschnitten ausgeführt werden können. Das Dokument benötigt dadurch jedoch mehr Scheduling-Runden bis zum Abschluss.

Die beste Einstellung hängt davon ab, ob der Server eine einzelne lange Analyseaufgabe oder mehrere Nutzer priorisiert, die bereits gestreamte Antworten erhalten.

Unterschiedliche Sequenzlängen machen jeden Batch unausgewogen

Anfragen unterscheiden sich in Prompt-Länge, Ausgabelänge, Abbruchbedingungen und Modellfunktionen. Einige werden schnell abgeschlossen, während andere aktiv bleiben, sodass sich die Zusammensetzung des Batches kontinuierlich verändert.

vLLM verwendet kontinuierliches Batching mit paged KV-Cache, um neue Anfragen aufzunehmen, sobald Kapazität verfügbar wird, statt auf eine feste Batch-Grenze zu warten.

Selbst bei effizienter Speicherverwaltung belegt eine sehr lange Antwort über viele Iterationen hinweg Decodierungsslots und KV-Cache. Die Batch-Größe sollte daher anhand von Token- und Speicherbudgets festgelegt werden, nicht nur anhand der Anzahl der Anfragen.

Größere Batches können die Tokenrate pro Nutzer senken

Die Gesamtzahl der Tokens pro Sekunde kann steigen, während jeder Nutzer einen kleineren Anteil der Decodierungsiterationen erhält. Ein Dashboard mit höherem Gesamtdurchsatz kann daher gleichzeitig ein langsameres sichtbares Streaming anzeigen.

Der Leitfaden von ZimaSpace zu gleichzeitiger Nutzung durch Familien erklärt, warum Benchmarks mit nur einem Nutzer keine Rückschlüsse auf die Latenz mehrerer gleichzeitig geführter Gespräche zulassen.

Misst neben dem Gesamtdurchsatz auch die Zeit bis zum ersten Token, die Zeit zwischen den Tokens und die Abschlusszeit jeder Anfrage. Andernfalls wird das Batching möglicherweise auf eine Kennzahl optimiert, die Nutzer nicht unmittelbar wahrnehmen.

Legt unterschiedliche Batch-Richtlinien für interaktive und Hintergrundaufgaben fest

Reserviert kurze Warteschlangenfenster, begrenzte Parallelität und höhere Priorität für Sprache und Chat. Erlaubt größere Batches und eine niedrigere Priorität für Embeddings, Indizierung, Zusammenfassungen und Offline-Transformationen.

Die Forschung zu fairem LLM-Serving verwendet tokenbasierte Fairness, damit der lange Input oder Output einer Anfrage nicht dauerhaft einen unverhältnismäßig großen Anteil der Ressourcen belegt.

Testet unter einer realistischen Familienauslastung und nicht nur bei maximaler Batch-Größe. Die sinnvolle Konfiguration bietet den höchsten Durchsatz, der gleichzeitig die Zielwerte für die Zeit bis zum ersten Token und die Streaming-Latenz des interaktiven Pfads erfüllt.

Wenn ein einzelner Beschleuniger beide Aufgabentypen nicht bewältigen kann, sind getrennte Worker oder Zeitpläne möglicherweise einfacher als eine universelle Batching-Richtlinie.

FAQ

Erhöht Batching immer die Latenz?

Nein. Effizientes Batching kann die Zeit zum Abarbeiten der Warteschlange verkürzen und eine Überlastung verhindern. Das Warten auf einen Batch und das Teilen längerer Iterationen kann jedoch die Latenz einer einzelnen Anfrage erhöhen.

Ist die Batch-Größe gleich der Anzahl der Nutzer?

Nicht genau. Laufzeiten können das Budget anhand aktiver Sequenzen, Tokens, KV-Blöcke oder des Gesamtaufwands festlegen, und ein Nutzer kann mehrere parallele Anfragen erzeugen.

Sollten Sprachanfragen mit Embeddings gebatcht werden?

Normalerweise nicht unter derselben Latenzrichtlinie. Sprache ist interaktiv, während Embedding-Aufgaben warten und bei freier Kapazität größere Batches nutzen können.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.