Wie viele Nutzer bedient ein lokaler KI-Server?

Passt der AI Cube Pro zu Ihrer Nutzerzahl? Wir stimmen Modell und erwartete Parallelität vor der Lieferung ab. Wenn die gemessene Last darüber hinausgeht, erweitern wir um weitere AI Cubes oder dimensionieren einen GPU-Server. AI Cube Pro konfigurieren

Ein lokaler KI-Server hat keine seriöse feste Grenze wie „50 Nutzer“. Hundert angelegte Konten können problemlos sein, wenn nur wenige Personen gleichzeitig kurze Fragen stellen. Zehn gleichzeitig aktive Nutzer können anspruchsvoll sein, wenn sie große Dokumente verarbeiten und lange Antworten erwarten. Für die Dimensionierung zählt deshalb Parallelität statt Kontenzahl.

Kurzantwort: Welcher Aufbau passt zu welchem Nutzungsprofil?

Die Tabelle ist keine feste Leistungszusage. Sie zeigt, welche Architektur zuerst geprüft wird. Eine belastbare Nutzerzahl entsteht erst aus dem konkreten Modell, realistischen Aufgaben und der akzeptierten Wartezeit.

Die fünf Größen, die den Durchsatz bestimmen

1. Modell und Quantisierung: Größere Gewichte belegen mehr Speicher und benötigen mehr Rechenzeit je Token. Der Leitfaden zu LLMs auf 128 GB Unified Memory ordnet passende Modellklassen ein.
2. Eingabekontext: Lange Chats und große Dokumentauszüge vergrößern die Vorverarbeitung und den KV-Cache.
3. Antwortlänge: Eine kurze Auskunft belegt das System wesentlich kürzer als ein Bericht mit mehreren tausend Token.
4. Gleichzeitige Anfragen: Inferenzserver bündeln Arbeit, aber jede aktive Sequenz benötigt Speicher und Rechenzeit.
5. Erwartete Reaktionszeit: Ein Team akzeptiert für eine Analyse möglicherweise eine Minute, für einen interaktiven Chat aber nur wenige Sekunden bis zur ersten Ausgabe.

Drei Nutzerzahlen statt einer

Für ein realistisches Lastprofil erfassen wir:

• registrierte Nutzer, die grundsätzlich Zugriff haben;
• täglich aktive Nutzer, die das System im Arbeitsalltag verwenden;
• gleichzeitig aktive Nutzer in der erwarteten Spitzenzeit.

Die dritte Zahl ist für die Hardware entscheidend. Hinzu kommt die Verteilung der Aufgaben: Chat, Dokumentensuche, Transkription und automatisierte API-Aufrufe belasten das System unterschiedlich.

Was auf dem AI Cube Pro gemessen wird

Der AI Cube Pro stellt 128 GB Unified Memory und eine für Mehrbenutzerbetrieb geeignete lokale Plattform bereit. Vor der Auslieferung stimmen wir ein Modell auf den Anwendungsfall ab. Für eine belastbare Kapazitätsaussage messen wir anschließend mit repräsentativen Anfragen:

• Zeit bis zum ersten Token;
• sichtbare Ausgaberate je Anfrage;
• Gesamtdurchsatz über alle Anfragen;
• Speicherbelegung bei typischem und maximalem Kontext;
• Warteschlange, Abbrüche und Fehler unter Spitzenlast.

Die Ergebnisse gelten immer für die dokumentierte Kombination aus Modellversion, Quantisierung, Runtime und Testprofil. Ein Wechsel zu einem größeren Modell kann die Kapazität deutlich verändern.

Wann ein zweiter AI Cube sinnvoll ist

Für mehr gleichzeitige Nutzer können zwei AI Cubes unabhängige Anfragen bearbeiten. Ein Load Balancer verteilt neue Anfragen auf freie Kapazität. Das ist ein anderer Aufbau als ein einzelnes großes Modell, das über zwei Systeme verteilt wird. Bei verteilter Inferenz kommunizieren die Systeme über ConnectX-7; Netzwerk- und Softwarekonfiguration werden Teil des Leistungsprofils.

Ein zweiter Knoten bringt zudem nicht automatisch Hochverfügbarkeit. Dafür müssen Modellendpunkte, Oberfläche, Datenbank, Wissensspeicher, Identität und Load Balancer redundant oder wiederherstellbar ausgelegt werden.

Wann AI Cube Custom oder GPU-Server folgt

Ein größerer Aufbau ist sinnvoll, wenn sehr große Modelle dauerhaft benötigt werden, viele lange Kontexte parallel laufen, mehrere Modelle gleichzeitig bereitstehen oder definierte Verfügbarkeit verlangt wird. Dann planen wir AI Cube Custom oder GPU-Server anhand des gemessenen Profils.

Ein einfaches Lasttest-Profil

1. Fünf bis zehn typische Aufgaben auswählen.
2. reale Größenordnungen für Prompt, Dokumente und Antwort festlegen;
3. einen, zwei, vier und acht gleichzeitige Abläufe testen;
4. Qualität und Geschwindigkeit gemeinsam bewerten;
5. Spitzenzeiten und automatisierte Jobs ergänzen;
6. eine ausdrücklich vereinbarte Kapazitätsreserve für Wachstum und Updates vorsehen.

So wird die Nutzerzahl zu einer nachprüfbaren Kapazitätsentscheidung statt zu einer Marketingangabe.

Quellen und Vertiefung

• vLLM: Architektur und kontinuierliches Batching
• NVIDIA: DGX-Spark-Hardware
• WZ-IT: GPU und VRAM dimensionieren
• WZ-IT: AI Cubes mit ConnectX-7 verbinden