Wie viele gleichzeitige Nutzer kann ein einzelnes KI-Modell für den Heimgebrauch bedienen, bevor die Latenz instabil wird?
Ein KI-Modell zu Hause kann zuverlässig einen bis mehrere interaktive Nutzer bedienen, doch das stabile Limit hängt vom Tokenbedarf, Batching und den Latenzzielen ab.
Ein Modell, das 30 Token pro Sekunde erzeugt, kann sich in einem kurzen Chat mit einer Person schnell anfühlen, aber ins Stocken geraten, wenn vier Personen gleichzeitig lange Prompts senden. Gleichzeitige Anfragen verbrauchen KV-Cache-Speicher, teilen sich die Dekodierkapazität und erzeugen Warteschlangenspitzen. Das richtige Limit ist die höchste angebotene Last, bei der während der normalen Nutzung durch die Familie ein festgelegtes p95-Ziel für die Zeit bis zum ersten Token und die Tokenrate noch erreicht wird.
Parallelität verwandelt Durchsatz in Wartezeit
Eine grobe Kapazitätsschätzung ergibt sich, indem der anhaltende Generierungsdurchsatz durch die durchschnittlich von aktiven Sitzungen pro Sekunde angeforderten Token geteilt wird. Nähert sich die Nachfrage der Servicekapazität, können kleine Lastspitzen lange Warteschlangen erzeugen. Nutzer sind keine identischen Einheiten: Eine Antwort mit 50 Token beansprucht den Server anders als eine Antwort mit 2.000 Token.
Eine Analyse zu Latenz und Durchsatz erklärt, dass Batching den Gesamtdurchsatz verbessert, dabei aber häufig mit einer höheren individuellen Antwortlatenz einhergeht. Dieses Spannungsfeld entscheidet darüber, ob sich zusätzliche Sitzungen stabil anfühlen.
Das Prefilling von Prompts kann je nach Scheduler ebenfalls die Dekodierarbeit blockieren. Zwei Nutzer, die große Dokumente einfügen, können die Leistung für alle stärker beeinträchtigen als sechs Nutzer mit kurzen Fragen. Eine Nutzerzahl ohne Verteilungen von Prompt- und Ausgabelängen ist daher nicht übertragbar.
KV-Cache und Scheduling schaffen ein zweites Limit
Jede aktive Sequenz speichert die Attention-Schlüssel und -Werte ihres Kontexts. Längere Verläufe und größere Batches erhöhen die Nutzung des KV-Caches, bis Anfragen abgelehnt, ausgelagert oder verzögert werden. Kontinuierliches Batching kann zwischen Dekodieriterationen neue Arbeit aufnehmen, schafft aber keinen zusätzlichen Speicher.
Eine technische Erklärung zu kontinuierlichem Batching zeigt, wie Scheduling auf Iterationsebene ansonsten ungenutzte Batch-Plätze füllt. Der Nutzen hängt von der Arbeitslast ab und kann die Konkurrenz um Ressourcen pro Anfrage leicht erhöhen.
Nahe der Sättigung wird die Latenz instabil, da die Länge der Warteschlange stark auf Schwankungen bei den Anfrageeingängen reagiert. Die durchschnittliche Latenz kann allmählich steigen, während p95- und maximale Latenz sprunghaft zunehmen. Die stabile Kapazität sollte unterhalb dieses Knickpunkts liegen und nicht beim höchsten im Benchmark gemessenen Token-pro-Sekunde-Wert.
Wo eine Nutzerzahl keine verlässliche Aussage über das Nutzungserlebnis mehr erlaubt
Der gleiche Server kann mehr Nutzer bei der Autovervollständigung unterstützen als bei RAG, Tool-Nutzung oder Langform-Generierung. Kaltstarts, thermische Drosselung, Retrieval und Sprachsynthese fügen Schritte außerhalb der Modellbereitstellung hinzu. Eine auf das Modell beschränkte Parallelitätszahl kann daher keine Reaktionsfähigkeit der gesamten Anwendung garantieren.
Ein Leitfaden zur Bereitstellung von Speicher beschreibt Speicher, Kontext, Batching und Parallelisierung als miteinander verknüpfte Einschränkungen. Eine Änderung an einem dieser Faktoren kann den Kapazitätsknick verschieben.
Die Prognose versagt auch, wenn Familienanfragen in synchronisierten Spitzen statt unabhängig voneinander eintreffen. Vier Nutzer, deren Sitzungen sich selten überschneiden, können problemlos sein, während zwei automatisierte Agenten das Modell kontinuierlich auslasten. Messen Sie die tatsächlich angebotene Arbeit, nicht die Zahl der registrierten Konten.
Ermitteln Sie den Parallelitätsknick mit einem Lasttest
Spielen Sie realistische kurze, mittlere und lange Anfragen bei einer, zwei, vier und acht parallelen Sitzungen erneut ab. Halten Sie Modell, Quantisierung, Kontextlimit und Sampling konstant. Erfassen Sie Wartezeit, Latenz bis zum ersten Token, Latenz zwischen Token, Abschlussrate, KV-Cache-Nutzung sowie p50-, p95- und Maximalwerte.
Verwenden Sie die Architektur der geteilten Modellsitzungen als Testkontext, wenn mehrere Sitzungen im Haushalt ein Modell gemeinsam nutzen. Lassen Sie RAG- und Tool-Schritte entweder deaktiviert oder messen Sie sie separat.
Definieren Sie das stabile Limit als die höchste Parallelität, bei der die p95-Latenz bis zum ersten Token innerhalb des Haushaltsziels bleibt und weder ein anhaltender Anstieg der Warteschlange noch Speicherfehler auftreten. Halten Sie für Spitzenlasten einen Durchsatzpuffer von 20–30 Prozent vor. Wiederholen Sie den Test, sobald sich Kontextlänge, Modell oder Scheduler ändern.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
So messen Sie die lokale RAG-Abrufqualität und interpretieren Recall, Precision und Zitatabdeckung
Erstellen Sie einen lokalen RAG-Testsatz, berechnen Sie zentrale Retrieval-Metriken, interpretieren Sie deren Zielkonflikte und prüfen Sie, ob die Antwortaussagen durch die zitierten Belege gestützt...
Warum wird die Berechnung von Smart-Home-Funktionen bei gleicher Abtastrate wichtiger, je mehr Sensoren vorhanden sind?
Verfolge die Berechnungen pro Sensor und über mehrere Sensoren hinweg, während die Anzahl der Geräte steigt, ermittle nichtlineare Fusionskosten und benchmarke die Feature-Pipeline, bevor...
Warum werden die Kosten der RAG-Evaluierung bei gleichbleibender Abfragezahl wichtiger, je größer die Dokumentbibliothek wird?
Verstehen Sie, warum das Wachstum des Korpus den Bewertungsaufwand für RAG ohne zusätzliche Nutzeranfragen erhöht und wie geschichtete Tests die Kosten an das Risiko...
