Wie viele gleichzeitige Nutzer kann ein lokaler LLM-Server bedienen?

Nutzerzahl ist nicht gleich Parallelität

100 registrierte Personen können einen Server kaum belasten, wenn sie selten fragen. Umgekehrt können 5 automatisierte Prozesse viele lange Anfragen gleichzeitig senden. Entscheidend sind daher Ankunftsrate, tatsächlich parallele Sequenzen, Eingabe- und Ausgabetokens sowie die akzeptierte Wartezeit. Auch das Serving-System beeinflusst, wie Anfragen gebündelt und KV-Cache genutzt werden.

Ein Kapazitätstest bildet das reale Profil nach. vLLM stellt dafür unter anderem eine Serve-Benchmark mit einstellbarer Anfragefrequenz und maximaler Parallelität bereit. Sinnvoll ist eine Stufenfolge, beispielsweise 1, 2, 4, 8, 16 und 32 gleichzeitige Anfragen. Das sind Testpunkte und keine zugesicherte Serverkapazität. Die Prompts müssen den erwarteten Längen und Funktionen entsprechen; eine kurze Begrüßung ist kein Ersatz für einen 20-seitigen Dokumentkontext.

Pro Stufe werden mindestens Time to First Token, Ende-zu-Ende-Latenz, Ausgabe-Tokens pro Sekunde, Fehlerquote, Warteschlangenlänge sowie GPU- und Arbeitsspeicher erfasst. Neben p50 ist p95 oder p99 wichtig, weil ein guter Mittelwert einzelne sehr langsame Antworten verdeckt. Der Test läuft lange genug, um Aufwärmen, Cache-Effekte und eine stabile Lastphase zu trennen.

Die Betriebsgrenze liegt nicht dort, wo der Server erstmals antwortet, sondern dort, wo das vereinbarte Ziel noch mit Reserve eingehalten wird. Danach begrenzen Admission Control, maximale Kontext- und Ausgabelänge, Zeitlimits und eine sichtbare Warteschlange Überlast. Werden mehrere Instanzen eingesetzt, muss auch der Load Balancer unter demselben Profil getestet werden. Erst der dokumentierte Messwert für eine konkrete Modell- und Hardwareversion ist belastbar; bei jedem Modellwechsel wird er neu bestimmt.