Wie beeinflusst kontinuierliches Batching die Fairness auf einem KI-Heimserver?

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.

Kontinuierliches Batching verbessert die Auslastung, indem aktive Batches wieder aufgefüllt werden. Die Fairness hängt jedoch davon ab, wie Nutzer im Laufe der Zeit Zugriff, Tokenverarbeitung und Speicher erhalten.

Ein KI-Server für zu Hause kann mehrere Unterhaltungen gleichzeitig verarbeiten, ohne darauf zu warten, dass jede Sequenz gemeinsam abgeschlossen wird. Abgeschlossene Anfragen werden entfernt, neue Anfragen kommen hinzu, und aktive Nutzer teilen sich wiederholte Inferenziterationen. Das erhöht den Durchsatz, doch die Anfragen sind nicht gleich: Ein Nutzer sendet möglicherweise einen kurzen Befehl, ein anderer ein langes Dokument und ein weiterer einen Agenten, der Hunderte von Tokens generiert. Ein fairer Scheduler muss festlegen, welche Arbeitseinheit zählt, wie neue Anfragen aufgenommen werden und wie Prioritäten mit unvorhersehbaren Ausgabelängen zusammenspielen.

Kontinuierliches Batching ändert die Planungseinheit von einem festen Batch zu Iterationen

Statisches Batching hält eine Gruppe zusammen, bis sie vollständig abgeschlossen ist, und verschwendet Kapazität, wenn kurze Anfragen früh fertig werden. Kontinuierliches Batching kann die freien Plätze zwischen den Generierungsiterationen wieder auffüllen.

Orca führte Scheduling auf Iterationsebene ein, sodass Anfragen beitreten und die Verarbeitung verlassen können, während sich ihr Sequenzzustand ändert.

Das verbessert die Auslastung, bedeutet aber auch, dass Nutzer wiederholt um einen Platz in der nächsten Iteration konkurrieren, anstatt einen unteilbaren Anfrageplatz zu erhalten.

Die Reihenfolge der Aufnahme bestimmt, wer zuerst Rechenzeit sammelt

Eine Anfrage außerhalb des aktiven Batches erhält keinen Modellfortschritt. Der Scheduler kann nach Eingangszeit, geschätzter Länge, Priorität, verfügbaren KV-Blöcken oder einem Fairness-Zähler aufnehmen.

vLLM kombiniert kontinuierliche Aufnahme mit der Verwaltung eines ausgelagerten KV-Caches, sodass Speicher zugewiesen werden kann, während Sequenzen wachsen.

First-come, first-served ist einfach, aber eine Warteschlange mit langen Anfragen kann spätere kurze Haushaltsbefehle verzögern, selbst wenn diese schnell abgeschlossen wären.

Die Gleichbehandlung von Anfragen kann zu ungleicher Accelerator-Nutzung führen

Eine Antwort mit fünf Tokens und eine Antwort mit fünfhundert Tokens sind jeweils eine Anfrage, belegen jedoch eine sehr unterschiedliche Anzahl an Dekodierungsiterationen. Auch unterschiedliche Prompt-Längen verursachen unterschiedlich viel Prefill-Arbeit.

Der Virtual Token Counter definiert tokenbasierte Fairness, weil die Anzahl der Anfragen allein den von heterogenen LLM-Workloads verbrauchten Dienst nicht abbildet.

Eine Richtlinie für den Haushalt sollte festlegen, ob Fairness gleiche Tokenarbeit, gleiche Wartezeit, gleiche Abschlusschancen oder eine Priorität für latenzempfindliche Aufgaben bedeutet.

Keine einzelne Kennzahl wird jedem Workload gerecht. Ein Sprachbefehl und eine Zusammenfassung im Hintergrund sollten nicht unbedingt identisch behandelt werden.

-15% OFF

Unbekannte Ausgabelängen erschweren die Vorhersage der künftigen Verarbeitung

Der Scheduler kennt bei der Aufnahme die Prompt-Größe, weiß aber normalerweise nicht genau, wie viele Ausgabetokens das Modell generieren wird. Eine Anfrage kann deutlich länger aktiv bleiben als erwartet.

Die Fairness-Forschung hebt unvorhersehbare Anfrage­längen als besondere Herausforderung bei der Bereitstellung von LLMs hervor.

Wenn die Verarbeitung nach den tatsächlich verarbeiteten Tokens abgerechnet wird, muss man sich nicht vollständig auf eine ungenaue Längenschätzung verlassen. Dennoch kann eine lange Anfrage weiterhin über viele Iterationen hinweg Speicher belegen.

Große Prefills können Nutzer stören, die bereits Tokens erhalten

Ein neuer Dokumenten-Prompt kann eintreffen, während mehrere Nutzer ihre Antworten dekodieren. Sein rechenintensiver Prefill kann die Iteration verlängern, auf die aktive Unterhaltungen warten müssen.

Sarathi-Serve nutzt Scheduling ohne Unterbrechungen, um große Prefills aufzuteilen und ihre Auswirkungen auf die laufende Dekodierungslatenz zu verringern.

Ein Scheduler, der nur Dekodierungstokens zählt, kann dennoch unfair sein, wenn ein Nutzer wiederholt große Prefills einführt, die die gestreamte Ausgabe aller anderen verzögern.

Eine faire Abrechnung sollte daher sowohl die Eingabeverarbeitung als auch die generierten Tokens berücksichtigen.

Speicherdruck kann Fairnessprobleme verursachen, bevor die Rechenleistung ausgelastet ist

Jede aktive Unterhaltung benötigt einen KV-Cache, und längere Kontexte verbrauchen mehr Blöcke. Ein Nutzer mit einem einzigen großen Kontext kann die Anzahl der anderen Anfragen verringern, die in den aktiven Batch passen.

Die Multi-User-Analyse von ZimaSpace verknüpft Konkurrenz im Haushalt mit gemeinsam genutztem Modellspeicher und Scheduler-Entscheidungen.

Das Präemptieren oder Auslagern einer Anfrage kann Kapazität schaffen, doch der unterbrochene Nutzer muss später möglicherweise eine Neuberechnung, das erneute Laden des Caches oder eine längere Abschlusszeit in Kauf nehmen.

Speicheraufnahme und Rechenplanung müssen daher derselben Fairness-Richtlinie folgen, anstatt als voneinander unabhängige Grenzen zu funktionieren.

Prioritäten benötigen Alterung, Kontingente und für Nutzer sichtbare Messwerte

Sprachsteuerung, Barrierefreiheitstools und kurze interaktive Chats können eine höhere Priorität als Embeddings oder nächtliche Zusammenfassungen verdienen. Reines Prioritäts-Scheduling kann Arbeit mit niedriger Priorität jedoch dauerhaft verdrängen.

Llumnix nutzt dynamisches Scheduling, um die Platzierung von Anfragen und Ressourcenentscheidungen an veränderte Bedingungen bei der Bereitstellung anzupassen.

Füge Alterung, Kontingente pro Nutzer, maximale Kontext- oder Ausgabelimits und einen reservierten Anteil für Hintergrundaufgaben hinzu. So reagieren bevorzugte Aufgaben schnell, ohne alles andere auf unbestimmte Zeit zu blockieren.

Miss Warteschlangenzeit, Zeit bis zum ersten Token, Verzögerung zwischen Tokens, Abschlusszeit, bereitgestellte Tokens und Präemption nach Nutzer oder Workload-Klasse. Kontinuierliches Batching ist nur dann fair, wenn die beobachtete Verteilung der Richtlinie des Haushalts entspricht, nicht bloß dann, wenn die Gesamtzahl der Tokens pro Sekunde hoch ist.

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.