Warum werden Antworten lokaler LLMs bei gleichzeitiger Auslastung kürzer?

Lokale LLM-Antworten werden unter Last kürzer, wenn die Serving-Schicht durch Limits, Deadlines, Preemption oder fehlgeschlagene Anfragen das Generierungsbudget zugunsten höherer Nebenläufigkeit reduziert.

Das Modell entscheidet sich nicht automatisch für eine knappere Antwort, nur weil ein weiterer Benutzer hinzugekommen ist. Bei identischem Prompt und Sampling-Zustand sollte sich die Nebenläufigkeit hauptsächlich auf Warteschlangen- und Token-Timing auswirken. Kürzere Antworten deuten darauf hin, dass die Laufzeitumgebung, das Gateway, der Client oder der Speichermanager eine effektive Abbruchbedingung geändert, die Verarbeitung abgebrochen oder nach Überschreiten eines Belastungsschwellenwerts einen unvollständigen Stream zurückgegeben hat.

Höhere Nebenläufigkeit erweitert den KV-Speicherbedarf und aktiviert Serving-Limits

Jede aktive Sequenz enthält KV-Cache-Blöcke, die mit dem beibehaltenen Kontext und den generierten Tokens wachsen. Wenn sich mehrere Anfragen einen Beschleuniger teilen, kann die Laufzeitumgebung die maximale Ausgabe reduzieren, die Zulassung verweigern, eine Sequenz vorzeitig unterbrechen oder Blöcke auslagern, damit der Batch innerhalb der Speicherkapazität bleibt.

Ein Serving-Design auf Grundlage der seitenweisen KV-Cache-Zuweisung verwendet seitenweise KV-Blöcke, um Fragmentierung zu reduzieren und eine höhere Nebenläufigkeit zu ermöglichen. Dieser Mechanismus verbessert die Kapazität, macht jedoch auch deutlich, dass jede aktive Sequenz bis zum Abschluss oder zur Verdrängung eine wachsende Speicherzuweisung beansprucht.

Ein Gateway kann ein separates Token-Budget pro Anfrage oder global festlegen. Wenn dieses Budget aus der verfügbaren Kapazität, der Priorität oder der Warteschlangentiefe abgeleitet wird, erhalten identische Prompts eine unterschiedliche maximale Ausgabe, obwohl Modellgewichte und Sampling-Parameter unverändert erscheinen.

Deadlines und Preemption können eine gültig wirkende Teilantwort zurückgeben

Interaktive Systeme setzen häufig Zeitlimits, Timeouts für inaktive Streams oder eine Client-seitige Abbruchfunktion durch. Eine unter Last langsamere Ausgabe von Token zu Token erreicht diese Grenzen früher innerhalb der inhaltlichen Antwort, und manche APIs geben die bereits ausgegebenen Tokens statt eines offensichtlichen Fehlers zurück.

Die Methode des Chunked Prefill teilt die Prompt-Verarbeitung in kleinere Abschnitte auf, damit lange Prefills die Decodierung nicht blockieren. Diese Arbeit zeigt, wie sich Änderungen der Ablaufplanung bei gemischter Anfragelast auf die Zeit bis zum ersten Token und die Latenz zwischen Tokens auswirken. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Preemption kann eine Anfrage zur späteren Fortsetzung bewahren, sie neu starten oder sie je nach Engine abbrechen. Wenn die Verbindung des Clients während der Pause getrennt wird, kann der Server eine Abmeldung protokollieren, während die Oberfläche ein grammatikalisches, aber unvollständiges Präfix als fertige Antwort anzeigt.

Sampling allein sollte nicht zuverlässig mit der Last korrelieren

Stochastisches Decoding erzeugt naturgemäß unterschiedliche Längen, wenn Temperatur und Zufalls-Seed abweichen. Diese Variation kann sich in kleinen Stichproben mit der Last überschneiden, aber Nebenläufigkeit besitzt kein direktes semantisches Signal, sofern nicht ein gemeinsamer Zustand, eine adaptive Richtlinie oder ein Softwarefehler den Decoding-Pfad verändert.

Die Forschung zu SLO-bewusster Ablaufplanung modelliert Routing und Scheduling unter Wahrung der Zeitziele zwischen Tokens. Die Trennung zwischen Durchsatz, TTFT und Decoding-Deadlines zeigt, warum die Kapazitätsrichtlinie unabhängig von der Ausgabequalität des Modells gemessen werden muss. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf aufbaut.

Die Fehlergrenze liegt darin, den Scheduler zu beschuldigen, bevor die Stop-Metadaten geprüft wurden. End-of-Sequence-Tokens, explizite Längenlimits, Abbrüche durch den Client, Server-Deadlines, OOM-Fehler und Verbindungsabbrüche beim Transport sind unterschiedliche Ursachen. Nur wiederholte, kontrollierte Längenänderungen mit übereinstimmenden Stop-Gründen stützen die Annahme eines lastbedingten Mechanismus.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Länge und Stop-Grund bei festen Nebenläufigkeitsstufen vergleichen

Gib feste Prompts und Seeds mit einer, zwei, vier und acht gleichzeitig laufenden Anfragen erneut aus. Erfasse die angeforderte maximale Token-Anzahl, die tatsächliche Anzahl der Ausgabetokens, den Abschlussgrund, die Wartezeit, TTFT, die Latenz zwischen Tokens, die Deadline für die gesamte Laufzeit, die Trennung des Clients, die Anzahl der Preemptions, die KV-Byte-Anzahl, den freien VRAM und den Serverfehler.

Setze das Speicherverhalten in Beziehung zu den Grenzen gleichzeitiger Workloads und wiederhole den Test anschließend ohne Gateway-Timeouts und mit einem festen Zulassungslimit. Behalte Prompts, Templates, Sampling und Client-Code unverändert, sodass die Nebenläufigkeit die einzige beabsichtigte Änderung ist. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Behandle kürzere Ausgaben als Serving-Fehler, wenn Abschlussrate oder semantische Abdeckung vor Erreichen des beworbenen Budgets sinken. Wenn nur die Latenz steigt, während die Abschlussgründe EOS bleiben, führe weitere Tests mit festen Seeds durch. Wenn Timeouts oder Limits dominieren, müssen diese Richtlinien explizit offengelegt und dimensioniert werden.