Lokaler KI-Server: So berechnen Sie die tatsächliche Parallelität, bevor Sie dem gesamten Team einen privaten Assistenten versprechen

Die Zahl aus der Demo ist nicht die Kapazität des Dienstes

Dass ein Modell für eine einzelne Person schnell Text erzeugt, belegt noch nicht, dass es für ein Team ausreichend Kapazität hat. Eine isolierte Demo basiert häufig auf einer kurzen Anfrage ohne Warteschlange, bei bereits warmem Cache und Prozess sowie ohne weitere Gespräche, die Speicher belegen. Ein gemeinsam genutzter Dienst arbeitet unter anderen Bedingungen: Anfragen treffen unregelmäßig ein, Ein- und Ausgaben sind unterschiedlich groß, sie konkurrieren um GPU-Speicher und warten, wenn das System sie nicht sofort ausführen kann.

Nutzbare Kapazität sollte nicht als einzelne Tokens-pro-Sekunde-Zahl kommuniziert werden. Sinnvoller ist eine bedingte Zusage: Bei definierten Ein- und Ausgabeszenarien hält eine bestimmte Parallelität Ziele für Zeit bis zum ersten Token, gesamte Antwortzeit sowie Zurückweisungs- oder Wartequote ein. Diese Formulierung macht es möglich, ein internes Versprechen mit einem wiederholbaren Test abzugleichen, und verhindert Hochrechnungen aus einer günstigen Demo.

Beim Serving generativer Modelle gibt es getrennte Metriken für Wartezeit in der Queue, Zeit bis zum ersten Token, Generierungszeit, Latenz zwischen Tokens und Ende-zu-Ende-Latenz. Diese Trennung ist wichtig, weil zwei Konfigurationen mit derselben durchschnittlichen Leistung sehr unterschiedliche Erfahrungen liefern können: Eine beginnt früh zu antworten, beendet die Antwort aber langsam; eine andere verzögert den Beginn wegen aufgestauter Arbeit. Leitfäden zu lokalen Modellen und Vergleiche von Runtimes sollten diese Dimensionen getrennt behandeln, bevor sie eine Konfiguration empfehlen.

Die betriebliche Frage lautet auch nicht einfach: „Wie viele Personen gibt es im Unternehmen?“ Sie lautet: „Wie viele aktive Anfragen welcher Größe müssen gleichzeitig mit welchem Latenzziel getragen werden?“ Dreißig Personen mit gelegentlicher Nutzung können geringe Parallelität bedeuten. Dagegen können wenige Automatisierungen, die lange Dokumente anhängen oder umfangreiche Antworten erzeugen, denselben Server auslasten. Die Messung muss diese Lasten abbilden, nicht einen abstrakten Begriff von Nutzenden.

Definieren Sie den Dienst, bevor Sie Hardware auswählen oder erweitern

Beschreiben Sie den erwarteten Bedarf zunächst in Einheiten, die der Server beobachten kann. Erfassen Sie die Zahl aktiver Anfragen, nicht nur registrierter Nutzender; die Verteilung der Eingabetokens; die erlaubte maximale Ausgabelänge; die Aufgabenart; die Ankunftsrate; sowie Ziele für Verfügbarkeit und Latenz. Wenn kein historischer Verkehr vorliegt, formulieren Sie Annahmen ausdrücklich und testen Sie konservative Szenarien. Eine Schätzung wird nicht dadurch zur Tatsache, dass sie mit präzisen Zahlen formuliert ist.

Trennen Sie mindestens drei Arbeitsklassen. Kurzer Chat hat meist wenige Eingaben und moderate Ausgaben. Eine Anfrage mit Retrieval-Augmented Generation kann Dokumentfragmente enthalten und eine große Eingabe haben, obwohl die Antwort kurz bleibt. Das Verfassen, Extrahieren oder Generieren von Code kann lange Ausgaben erfordern und das Gespräch länger aktiv halten. Diese Fälle in einem einzigen Durchschnitt zusammenzufassen, verdeckt die Fälle, die mehr Speicher verbrauchen oder die Warteschlange blockieren.

Definieren Sie für jede Klasse ein Budget: typische und maximale Eingabetokens, typische und maximale Ausgabetokens, erwartete gleichzeitige Anfragen und Grenzen für die Nutzungserfahrung. Das Latenzziel sollte mindestens die Zeit bis zum ersten Token und die Zeit bis zum Abschluss enthalten. Entscheiden Sie außerdem, ob Nutzende eine Generierung abbrechen können, was bei einem Limit geschieht und ob priorisierte Klassen existieren. Ohne diese Regeln hängt die Kapazität von impliziten Entscheidungen ab, die die Runtime unter Druck trifft.

Der Vergleich lokaler Modelle ist erst sinnvoll, nachdem dieser Dienstvertrag festgelegt wurde. Ein kleineres Modell kann auf derselben Hardware höhere Parallelität oder besser vorhersehbare Antworten ermöglichen; ein anderes Modell kann wegen seiner Qualität für eine bestimmte Last gerechtfertigt sein, aber strengere Grenzen verlangen. Es gibt keine universell ausreichende Konfiguration: Die Entscheidung muss die erforderliche Qualität mit Ergebnissen verbinden, die unter dem eigenen Nutzungsmuster gemessen wurden.

Erstellen Sie ein Speicherbudget, aber verwechseln Sie es nicht mit einer Garantie

Der verfügbare Speicher für das Serving eines Modells reduziert sich nicht auf die veröffentlichte Größe seiner Gewichte. Neben geladenen Gewichten müssen der Schlüssel-Wert-Cache aktiver Gespräche, Buffer und temporärer Ausführungsspeicher, Runtime-Strukturen sowie eine Reserve für Schwankungen und Wiederherstellung Platz finden. Die genaue Aufteilung hängt vom Modell, der Quantisierung, Runtime, Hardware und Konfiguration ab; eine allgemeine Formel sollte daher nicht als universelle Messung ausgegeben werden.

Der KV-Cache ist für die Parallelität entscheidend. Er bewahrt den Aufmerksamkeitszustand, der zum Fortsetzen einer Sequenz nötig ist, und wächst mit den verarbeiteten Tokens. In einem Dienst ändert sich seine Belegung je Anfrage: Ein langes Gespräch, eine umfangreiche abgerufene Eingabe oder eine lange Ausgabe kann über deutlich längere Zeit einen relevanten Anteil des Speichers binden als eine kurze Frage. Die Forschung zu PagedAttention nennt die Verwaltung dieses Caches, einschließlich Fragmentierung und Duplizierung bei bestimmten Mustern, als Faktor, der die effektive Batchgröße begrenzt.

Für die Planung ist ein Arbeitsbudget sinnvoll, solange es als Schätzung gekennzeichnet wird. Messen Sie zuerst den Basisspeicher bei geladenem Modell ohne Verkehr. Beobachten Sie danach, wie er sich je Szenario bei kontrollierten Längen und steigender Parallelität verändert. Reservieren Sie Kapazität, die nicht der Nominallast zugeteilt wird. Prüfen Sie schließlich, ob die Zulassungsrichtlinie verhindert, dass ein Laststoß das Limit überschreitet. Entscheidend ist das beobachtete Verhalten in der konkreten Konfiguration, nicht eine isolierte Berechnung.

Metriken der Runtime können die Auslastung des KV-Caches, laufende und wartende Anfragen sowie Maße für Prefill und Decode ausgeben. Diese Beobachtungen erlauben eine vorsichtigere Zuordnung eines Vorfalls: Sie beweisen für sich allein keine einzelne physische Ursache, helfen aber dabei, eine wachsende Queue von anhaltendem Cache-Druck oder langsamer Generierung zu unterscheiden. Bewahren Sie die Konfiguration auf, die jede Zeitreihe erzeugt hat, damit die Analyse wiederholbar bleibt.

Prefill und Decodierung: zwei Phasen, zwei mögliche Engpässe

Eine Anfrage verbraucht während ihrer gesamten Laufzeit nicht auf dieselbe Weise Ressourcen. Beim Prefill verarbeitet das System die Eingabe, um den Zustand für die Generierung aufzubauen. Bei der Decodierung erzeugt es aufeinanderfolgende Tokens und aktualisiert diesen Zustand. Eine Anfrage mit langem Dokument kann einen langsamen Start haben, obwohl ihre Antwort kurz ist; eine umfangreiche Antwort kann dagegen früh beginnen und dennoch lange Ressourcen binden. Nur die Gesamtdauer zu messen, verwischt diesen Unterschied.

Die Zeit bis zum ersten Token ist ein nützliches Signal für Nutzende und spiegelt häufig sowohl die Queue-Wartezeit als auch die Vorarbeit zum Start der Generierung wider. Die Latenz zwischen Tokens, die Zeit pro Ausgabetoken und die Gesamtzeit liefern eine weitere Sicht auf die Generierungsphase. Erfassen Sie auch die tatsächliche Ein- und Ausgabegröße, denn Unterschiede dieser Längen können scheinbare Latenzunterschiede erklären, ohne dass sich die Hardware verändert hat.

Kontinuierliches Batching kann die Auslastung erhöhen, indem es Arbeit verschiedener Anfragen mischt. Es beseitigt jedoch weder Speichergrenzen noch garantiert es Fairness zwischen Lasten. Eine Last mit großem Kontext kann mit kurzen Chats konkurrieren; Entscheidungen des Schedulers beeinflussen, wer früher startet und wer in der Queue bleibt. Ein repräsentativer Test sollte daher sowohl homogene Batches als auch eine kontrollierte Mischung von Szenarien enthalten und diese getrennt ausweisen.

Interpretieren Sie einen Rückgang der durchschnittlichen Leistung nicht automatisch als Diagnose. Er kann durch schnellere Ankünfte als die Bedienkapazität, längere Eingaben, ein hohes Ausgabelimit, Speicherdruck oder eine Planungsrichtlinie entstehen. Die Instrumentierung muss genügend Kontext liefern, um Korrelationen zu erkennen; lässt sich die Ursache nicht zuordnen, muss die Unsicherheit benannt werden.

Von VRAM zur operativen Parallelität

Operative Parallelität ist die höchste Zahl an Anfragen, die der Dienst für ein definiertes Szenario zulassen kann, ohne seine Ziele zu verletzen. Sie darf nicht direkt aus freiem Speicher oder einem theoretischen maximalen Kontext abgeleitet werden. Speicher kann ausreichen, während Queue oder Latenz dennoch das Budget überschreiten. Umgekehrt validiert ein akzeptables Ergebnis bei einer bestimmten Parallelität keine Last mit größeren Ein- oder Ausgaben.

Erstellen Sie eine Testmatrix. Legen Sie in einer Dimension Lastklassen und ihre Ein- und Ausgabelängen fest. Erhöhen Sie in der anderen Dimension die gleichzeitigen Anfragen. Wiederholen Sie für jede Zelle den Test nach dem Warm-up und erfassen Sie Perzentile für Wartezeit, TTFT, Generierungslatenz und Ende-zu-Ende-Zeit. Notieren Sie tatsächlich verarbeitete Tokens, Cache-Nutzung, aktive und wartende Anfragen, Abbrüche, Zurückweisungen und Fehler. Durchschnitte können ergänzt werden, dürfen Perzentile aber nicht ersetzen.

Kapazität muss über das schlechteste noch akzeptierte Ergebnis definiert werden, nicht über das Maximum, das einen Lauf gerade noch abschließt. Überschreitet das p95 beim Start das Ziel, wächst die Queue dauerhaft oder treten Speicherfehler auf, ist diese Parallelität für das Szenario keine operative Kapazität. Sie kann als untersuchter Fehlerpunkt erhalten bleiben, um Limits anzupassen, aber nicht als Versprechen an Nutzende.

Testen Sie auch die Erholung nach Druck. Beobachten Sie nach einem Laststoß, ob die Queue auf normale Werte zurückkehrt, ob Speicher wie erwartet freigegeben wird und ob neue Anfragen die übliche Latenz wieder erreichen. Ein System, das einen kurzen Test abschließt, sich aber nicht schnell erholt, kann für eine interne API fragil sein.

Nutzen Sie Warteschlangen und explizite Zulassung, bevor ein Fehler entsteht

Eine Warteschlange ist nicht zwangsläufig ein Fehler: Sie kann eine kontrollierte Entscheidung sein, um bereits gestartete Anfragen zu schützen. Problematisch wird sie ohne Limit, wenn Nutzende nicht wissen, dass sie warten, oder wenn weiter Arbeit angenommen wird, die das Budget nicht einhalten kann. Eine Zulassungsrichtlinie muss vor der Ressourcenzuweisung entscheiden, ob eine Anfrage eintreten, warten, ein kleineres Limit erhalten oder mit einer klaren Antwort zurückgewiesen werden kann.

Übliche Kontrollen sind Limits pro Nutzer oder Zugangsdaten, maximale Eingabetokens, maximale Ausgabetokens, eine maximale Zahl aktiver Anfragen, maximale Queue-Länge und maximale Wartezeit. Ein Abbruch muss Arbeit und Speicher nachweisbar freigeben. Gibt es Prioritätsklassen, dokumentieren Sie sie: Priorität schafft keine Kapazität, sondern verteilt eine begrenzte Kapazität anders.

Die Degradierung muss ausdrücklich sein und zum Anwendungsfall passen. Eine Oberfläche kann beispielsweise dazu auffordern, angehängte Dokumente zu reduzieren, ein angekündigtes Ausgabelimit anwenden oder eine nicht interaktive Aufgabe verschieben. Kritische Informationen stillschweigend abzuschneiden oder ohne Hinweis das Modell zu wechseln, wenn dies das erwartete Ergebnis verändert, ist nicht angemessen. Die Richtlinie muss bestimmen, was geschieht, bevor die Runtime einen Speicherfehler erreicht.

Zähler für wartende und laufende Anfragen sowie Metriken zur Prefill- und Decode-Arbeit zeigen, ob die Regeln den Dienst schützen. Testen Sie absichtlich eine Last oberhalb der Zulassung: Prüfen Sie, dass neue Arbeit begrenzt wird und sich die Latenz laufender Anfragen nicht unkontrolliert verschlechtert. Dieser Überlasttest ist genauso wichtig wie der nominale Test.

Wiederholbares Protokoll auf der eigenen Hardware

Ein nützlicher Test muss wiederholbar sein. Fixieren und dokumentieren Sie die verfügbare Modellidentität, Quantisierung, Runtime, Treiberversion, Typ und Anzahl der GPUs, Kontext- und Ausgabelimits, Batching-Parameter und Zulassungsrichtlinie. Ändert sich eine dieser Variablen, behandeln Sie das Ergebnis als neue Messung und nicht als automatische Fortsetzung der vorherigen.

Bereiten Sie eine synthetische Last auf Grundlage der definierten Szenarien vor. Verwenden Sie keine echten Gespräche, außer es besteht eine spezifische Genehmigung mit angemessenen Kontrollen. Die Last muss Ein- und Ausgabelängen festlegen oder erfassen. Führen Sie ein vom Messen getrenntes Warm-up aus, machen Sie mehrere Wiederholungen und wählen Sie ein Beobachtungsfenster, das lang genug ist, um wachsende Queues zu erkennen. Berichten Sie p50, p95 und p99, wenn die Zahl der Stichproben ihre Interpretation erlaubt; nennen Sie daneben die Zahl der Anfragen und das Testintervall.

Die Benchmarking-Dokumentation von vLLM umfasst Metriken wie TTFT, Zeit pro Ausgabetoken und Latenz zwischen Tokens und warnt, dass ein Prefix-Cache Ergebnisse erhöhen kann, wenn er nicht kontrolliert wird. Wenn Sie einen Prefix-Cache in Produktion einsetzen, testen Sie ihn repräsentativ und erklären Sie, ob Prompts wiederholt werden; bildet dies die erwartete Last nicht ab, deaktivieren Sie ihn oder trennen Sie ihn in ein anderes Szenario. Ein Ergebnis, das von unrealistischer Wiederverwendung abhängt, ist keine vorsichtige Kapazitätsschätzung.

Es reicht nicht, ein Dashboard aufzubewahren. Speichern Sie eine Zusammenfassung von Konfiguration, Lastgenerator, Parametern, aggregierten Ergebnissen und Akzeptanzkriterien. Wiederholbarkeit erlaubt den Vergleich eines Modell- oder Runtime-Updates und das Erkennen von Regressionen. Sie verhindert zudem, dass eine Kauf- oder Deployment-Entscheidung von Erinnerungen an eine frühere Demo abhängt.

Mit Evidenz entscheiden: Limits, Modellwechsel oder mehr Hardware

Treffen Sie mit den gesammelten Ergebnissen eine Entscheidung gegen die Anforderung, nicht gegen die Intuition. Behalten Sie die Konfiguration, wenn sie priorisierte Szenarien mit Spielraum erfüllt und sich nach Spitzen erholt. Reduzieren Sie Kontext oder maximales Ausgabevolumen, wenn das Produkt dies ausdrücklich zulassen kann und Tests zeigen, dass die Maßnahme die Ziele wiederherstellt. Begrenzen Sie Parallelität, wenn das Nachfragemuster kontrolliertes Warten erlaubt. Lasten zu trennen kann vorzuziehen sein, wenn Aufgaben mit langen Dokumenten den interaktiven Chat beeinträchtigen.

Eine GPU hinzuzufügen oder die Architektur zu ändern, ist erst dann eine vernünftige Entscheidung, wenn klar ist, welche Einschränkung dadurch gelindert werden soll. Dominiert Cache-Druck, sind Speicherbudget und Kontextverteilung zentral. Verletzt das Prefill langer Eingaben das TTFT-Ziel, bewerten Sie diese Phase separat. Reicht die Modellqualität für die Aufgabe nicht aus, löst mehr Parallelität das Problem nicht. Die Evidenz eines Tests erlaubt nicht automatisch, ohne Messung abzuleiten, welche dieser Alternativen optimal ist.

Auch ein Modellwechsel verlangt die Wiederholung der Matrix. Zwei Modelle mit ähnlich benannter Größe können verschiedene Kontextkonfigurationen, Quantisierungen und Runtimes verwenden. Der Wechsel kann sowohl Basisspeicher als auch Generierungsverhalten verändern. Kommunizieren Sie in einem internen Vergleich die vollständigen Bedingungen und schreiben Sie der Größe der Gewichte keine Kausalität zu, die nicht isoliert wurde.

Gibt es keine Konfiguration, die die Anforderung mit akzeptablen Grenzen erfüllt, kann die ehrliche Entscheidung sein, den gemeinsam genutzten Dienst noch nicht bereitzustellen. Besser ist ein begrenzter Pilot mit klar definiertem Umfang, als einen allgemeinen privaten Assistenten ohne Kapazitätsbudget zu versprechen. Ein Verzeichnis lokaler Modelle und Vergleiche sollten diese Schlussfolgerung als betriebliche Möglichkeit darstellen, nicht als Scheitern.

Datenschutz, Telemetrie und Deployment-Checkliste

Kapazitätsinstrumentierung darf kein paralleles Gesprächsarchiv erzeugen. Telemetriespezifikationen für generative KI weisen darauf hin, dass Eingabe- und Ausgabenachrichten, Anweisungen und Argumente sensible Informationen oder personenbezogene Daten enthalten können. Um Parallelität zu messen, ist die Speicherung vollständiger Texte meist nicht nötig: Tokenlängen, Zeitstempel, pseudonymisierte Kennungen, Zulassungsresultate und Latenzmetriken reichen in der Regel aus.

Legen Sie vor der Aktivierung detaillierter Traces fest, welche Felder zu welchem Diagnosezweck erfasst werden, wer Zugriff erhält, wie lange sie aufbewahrt und wie sie gelöscht werden. Werden Prompts oder Antworten zur Fehlersuche gespeichert, muss die Ausnahme begründet sein, Zugriffskontrollen haben und zeitlich begrenzt werden. Prüfen Sie auch, ob scheinbar harmlose Attribute wie Tool-Namen oder Argumente Geschäftsinformationen offenlegen können.

Die Mindestevidenz für ein internes Deployment umfasst Dienstvertrag, Szenarien, technische Umgebung, Lastmethode, Perzentile nach Szenario, Verhalten bei Überschreitung des Limits, Zulassungsrichtlinie und Umgang mit Telemetrie. Unterscheiden Sie stets zwischen Gemessenem, Geschätztem und noch nicht Getestetem. Diese Disziplin erlaubt es, den Dienst anzupassen, ohne eine Demo-Zahl in eine unbelegte Garantie zu verwandeln.

Kapazität ist nicht dauerhaft. Änderungen an Modell, Quantisierung, Treiber, Runtime, Kontextparametern, Cache oder Planungsrichtlinie können frühere Ergebnisse entwerten. Planen Sie eine Wiederholung des Tests, wenn sich wesentliche Elemente ändern, und überwachen Sie in Produktion, ob reale Verteilungen von Ein- und Ausgabe sowie Wartezeiten von den genehmigten Szenarien abweichen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.