Wie viele Nutzer schafft ein KI-Server? Leistung auf dem Papier kann täuschen und Fehler sind teuer

Wie viele Nutzer schafft ein KI-Server – INHALT

1. Die Leistung eines KI-Servers berechnet sich nicht nur aus Parametern
2. Warum eine einzige Antwort nicht ausreicht
3. Wie viele Nutzer bedeutet eigentlich wie viel?
4. Das Datenblatt hilft, berechnet die Kapazität aber nicht für Sie
5. Grundlegende Berechnung: Wie viele Token verbraucht ein Nutzer
6. Das Modell entscheidet mehr als der Name des Servers
7. RAG: Wenn der Chatbot nicht rät, sondern in Unternehmensdokumenten sucht
8. Ein Server kann ausreichen, wenn Sie wissen, was Sie von ihm erwarten
9. Wie Sie einen Benchmark beauftragen, der geschäftlichen Wert hat

Die Leistung eines KI-Servers berechnet sich nicht nur aus Parametern

Die Leistung eines KI-Servers wirkt auf den ersten Blick wie eine Disziplin, die sich mit einem Blick in die technischen Daten klären lässt. Ein Unternehmen vergleicht die Anzahl der GPUs, die Speichergröße sowie die TFLOPS-Werte im Datenblatt und gewinnt schnell das Gefühl, damit die Grundkapazität berechnet zu haben. Doch bei generativer künstlicher Intelligenz entstehen genau an diesem Punkt oft die teuersten Fehler, da die reine Hardware noch nichts darüber aussagt, wie viele Personen den Dienst komfortabel nutzen können, wie viele warten müssen und wann das System an die Grenze einer akzeptablen Reaktionszeit stößt.

Bei einem KI-Server kommt es darauf an, welches KI-Modell darauf läuft, wie lang die Anfragen und wie umfangreich die Antworten sein werden, wie schnell der Text auf dem Bildschirm erscheinen soll und wie viele Anfragen im selben Moment eingehen. Derselbe Server kann daher für einen einfachen internen Assistenten deutlich überdimensioniert sein, während er bei der Arbeit mit langen Verträgen, technischer Dokumentation oder einem größeren Modell viel früher an seine Grenzen stößt.

Warum eine einzige Antwort nicht ausreicht

Ein Wert aus dem Datenblatt ist ein nützlicher Einstieg in die technische Diskussion, reicht für sich allein jedoch nicht aus, um die Frage zu beantworten, wie viele Nutzer ein Server tatsächlich bewältigen kann. Bei einer herkömmlichen Webanwendung wird die Leistung häufig in Anfragen pro Sekunde umgerechnet, da der Server eine Anfrage verarbeitet, das Ergebnis zurückgibt und sich der nächsten Anfrage widmen kann. Bei einem Chatbot ist die Situation komplexer, da das Modell die Antwort schrittweise generiert und über den gesamten Zeitraum hinweg einen Teil der Leistung beansprucht.

Zudem belastet ein einzelner Nutzer den Server nicht über die gesamte Dauer seiner Anmeldung: Er tippt eine Weile an seiner Frage, wartet dann auf die ersten Worte der Antwort, liest anschließend das Ergebnis und stellt erst danach die nächste Anfrage. Kurze interne Abfragen, eine einfache Dokumentenklassifizierung und ein juristischer Assistent, der mit langen Texten arbeitet, sind daher drei völlig unterschiedliche Szenarien. In einer Präsentation fallen sie möglicherweise alle unter Unternehmens-KI, aus Sicht der Infrastruktur bedeuten sie jedoch völlig verschiedene Anforderungen an Speicher, Latenz, Durchsatz sowie Puffer für Lastspitzen. Genau deshalb ist es nicht zielführend, nur nach der Leistungsfähigkeit des Servers zu fragen, sondern vor allem danach, welche konkrete Aufgabe er erfüllen soll.

Wie viele Nutzer bedeutet eigentlich wie viel?

Das erste Problem entsteht bereits beim Begriff des Nutzers selbst. Ein Unternehmen kann 10.000 Mitarbeiter haben, das bedeutet jedoch nicht, dass der KI-Server gleichzeitig 10.000 Antworten generieren muss. Zu einem bestimmten Zeitpunkt wird die Mehrheit der Personen die Anwendung gar nicht geöffnet haben, ein Teil liest die fertige Ausgabe und nur eine kleinere Gruppe wartet gerade darauf, dass das Modell den nächsten Teil der Antwort generiert.

Für die Kapazitätsplanung ist daher die Anzahl der gleichzeitig bedienten Anfragen wichtiger als die Gesamtzahl der Personen mit Zugriff auf den Dienst. Bei einem generativen Chatbot ist es noch präziser, die Anzahl der Antworten zu beobachten, die das Modell im selben Augenblick aktiv generiert. Wenn zwanzig Personen das Ergebnis lesen und fünf Personen im selben Moment eine neue Antwort erhalten, stellen genau diese fünf laufenden Generierungsprozesse die größte Last für die GPU dar.

Formulierungen wie „der Server schafft 500 Nutzer“ sind daher nur dann aussagekräftig, wenn klar definiert ist, um welche Art von Nutzern es sich handelt. Es kann sich um angemeldete Konten, aktive Sessions, gleichzeitige Anfragen oder zeitgleich generierte Antworten handeln. Für die Kaufentscheidung ist die letzte Option am praktischsten, da genau sie mit Generierungsgeschwindigkeit, Latenz und dem tatsächlichen Nutzererlebnis verknüpft werden kann.

Das Datenblatt hilft, berechnet die Kapazität aber nicht für Sie

Die GPU-Parameter haben beim Entwurf eines KI-Servers einen klaren Wert. Die Rechenleistung zeigt, wie leistungsfähig der verwendete Chip ist, die VRAM-Kapazität bestimmt, wie groß das Modell und der Kontext sein dürfen, die in den Speicher passen, die Speicherbandbreite beeinflusst die Generierungsgeschwindigkeit und der Interconnect entscheidet darüber, wie effizient mehrere GPUs zusammenarbeiten. Das Problem entsteht in dem Moment, in dem diese Angaben zum einzigen Kaufkriterium erhoben werden und die restliche betriebliche Realität unberücksichtigt bleibt.

Bei Sprachmodellen entscheidet sich die Leistung in der Praxis an Metriken, die näher am tatsächlichen Anwendungsverhalten liegen. Die Latenz gibt an, wie lange der Nutzer wartet, der Throughput zeigt, wie viel Arbeit das System insgesamt bewältigen kann, und Tokens/s beschreiben, wie schnell das Modell Ausgaben generiert. Wichtig ist auch die TTFT (Time to First Token), da die Zeit bis zum ersten sichtbaren Teil der Antwort oft darüber entscheidet, ob eine Anwendung als schnell oder träge wahrgenommen wird.

Der beste Wert aus einem Benchmark ist oft weniger wichtig als die Bedingungen, unter denen er erzielt wurde. Ein Test mit kurzem Prompt, kurzer Antwort und idealem Batching kann hervorragend aussehen, sagt aber über einen Unternehmensassistenten mit umfangreichen Dokumenten, deutscher Sprache und morgendlichen Lastspitzen nur wenig aus. Entscheidend ist daher, die Leistung bei vergleichbarer Anfragelänge, vergleichbarer Antwortlänge und einer ähnlichen Gleichzeitigkeit zu testen, wie sie der künftige Produktivbetrieb aufweisen wird.

Grundlegende Berechnung: Wie viele Token verbraucht ein Nutzer

Bei generativer KI lässt sich mit einem einfachen Kapazitätsmodell beginnen. Schafft ein Server beispielsweise 6.000 Ausgabetoken pro Sekunde und möchte ein Unternehmen, dass ein aktuell bedienter Nutzer die Antwort mit einer Geschwindigkeit von 15 Token pro Sekunde erhält, ergibt sich eine rechnerische Bruttokapazität von 400 gleichzeitig generierten Antworten. Im Produktivbetrieb muss von dieser Zahl ein Puffer für Lastspitzen, längere Anfragen, Kontextverarbeitung, ungleichmäßiges Nutzerverhalten und den allgemeinen Overhead der Anwendung abgezogen werden.

Eine solche Berechnung ist keine exakte Prognose des realen Betriebs, aber ein sehr guter Entscheidungsfilter. Sie zeigt schnell, ob das Unternehmen über einen Server für ein Pilotprojekt, einen internen Assistenten für ein kleineres Team oder über eine Infrastruktur für hunderte Personen zur Spitzenzeit spricht. Gleichzeitig zwingt sie den Auftraggeber dazu zu definieren, welche Antwortgeschwindigkeit für den jeweiligen Dienst noch komfortabel ist und welche bereits als Arbeitsbremse wahrgenommen wird.

Wichtig ist auch der Betriebspuffer, da ein Produktivsystem nicht so ausgelegt sein darf, dass es während normaler Lastspitzen dauerhaft an der Belastungsgrenze läuft. Es genügt ein längeres Dokument, eine komplexere Anfrage, eine langsamere Komponente der Anwendungsschicht oder ein Wartungseingriff, und die Reaktionszeit beginnt sich rapide zu verschlechtern. Ein Puffer ist daher kein Luxus, sondern eine Absicherung dafür, dass der Dienst auch abseits idealer Bedingungen nutzbar bleibt.

Bei nicht-generativen Aufgaben wird die Kapazität anders berechnet. Klassifizierung, Embeddings oder einfache Suchvorgänge lassen sich häufig über Anfragen pro Sekunde ausdrücken, da die Antwort nicht durch schrittweises Generieren von langem Text entsteht. Wenn ein Dienst 2.000 Anfragen pro Sekunde verarbeiten kann und ein aktiver Nutzer durchschnittlich eine Anfrage alle zehn Sekunden sendet, fällt das Kapazitätsmodell völlig anders aus als bei einem Chatbot, der eine lange Antwort Token für Token generiert.

Das Modell entscheidet mehr als der Name des Servers

Die Modellgröße verändert die Anforderungen an die Infrastruktur drastisch. Kleinere Modelle mit bis zu etwa 10 Milliarden Parametern können bei guter Optimierung eine sehr beachtliche Anzahl interner Anfragen bedienen – insbesondere dann, wenn das Unternehmen keinen extrem langen Kontext benötigt. Größere Modelle bieten zwar bei anspruchsvolleren Aufgaben eine höhere Antwortqualität, steigern jedoch gleichzeitig die Anforderungen an VRAM, Speicherbandbreite und den effizienten Betrieb über mehrere GPUs hinweg erheblich.

Die reinen Modellparameter sind dabei nur der erste Teil der Speichergleichung. In den Speicher muss auch der KV-Cache passen, also der Zwischenspeicher des Modells für bereits verarbeitete Token. Weiteren Platz beanspruchen die Inference Engine und die Batch-Verarbeitung von Anfragen. Wenn der Server mehrere Modelle gleichzeitig bedient, muss zudem für jedes Modell eine separate Speicherreserve einkalkuliert werden.

Eine Quantisierung kann den Ressourcenbedarf senken, sollte jedoch an der konkreten Aufgabe und nicht nur anhand eines allgemeinen Benchmarks überprüft werden. Bei einem internen Assistenten, der wiederkehrende betriebliche Fragen beantwortet, kann eine sparsamere Konfiguration ein sinnvoller Kompromiss sein. Bei juristischen, technischen oder finanziellen Ausgaben muss hingegen geprüft werden, ob die gewählte Genauigkeit nicht die Arbeit mit Details beeinträchtigt – beispielsweise, ob das Modell ähnliche Vertragsklauseln schlechter unterscheidet, kleine Unterschiede in technischen Spezifikationen übersieht oder Zahlenangaben auf eine Weise vereinfacht, die in einem kurzen Labortest möglicherweise nicht auffällt.

RAG: Wenn der Chatbot nicht rät, sondern in Unternehmensdokumenten sucht

Ein unternehmensinterner KI-Assistent soll oft nicht nur aus dem allgemeinen Wissen des Modells heraus antworten. Viel nützlicher ist es, wenn er vor der Antwort relevante Informationen in internen Dokumenten, Handbüchern, Verträgen oder Wissensdatenbanken sucht. Dies nennt man RAG bzw. Retrieval-Augmented Generation. Einfach ausgedrückt handelt es sich um eine Kombination aus Recherche und Generierung: Das System findet zunächst die Unterlagen und erst danach stellt das Modell daraus die Antwort zusammen.

Für ein Unternehmen bedeutet das einen entscheidenden Unterschied. Das Modell muss nicht alles „im Kopf“ haben – also in den trainierten Parametern gespeichert –, sondern kann mit aktuellen Daten arbeiten, die sich im Unternehmen fortlaufend ändern. So kann der Chatbot auf Basis der neuesten Version einer internen Richtlinie, der Produktdokumentation oder der Geschäftsbedingungen antworten und nicht nur anhand dessen, was das Modell während des Trainings gelernt hat.

Aus Leistungssicht kommt jedoch zusätzliche Arbeit hinzu, die das System vor der eigentlichen Antwort bewältigen muss. Zunächst muss die Anfrage in ein suchfähiges Format umgewandelt werden, relevante Abschnitte müssen gefunden, mitunter nochmals nach Relevanz neu geordnet werden (sogenanntes Reranking) und schließlich in den Prompt für das Sprachmodell eingefügt werden. Erst danach beginnt die eigentliche Generierung der Antwort.

Aus diesem Grund kann ein RAG-Assistent langsamer und ressourcenintensiver sein als ein einfacher Chatbot ohne Dokumentenanbindung. Die Kapazität wird nicht allein durch die Generierungsgeschwindigkeit von Token bestimmt, sondern auch durch Suchvorgänge, Datenbanken, den Umgang mit längerem Kontext, die Dokumentenqualität sowie die Anwendungsschicht um das Modell herum. Hier zeigt sich oft der Unterschied zwischen einer ansprechenden Demo und einem Werkzeug, das im Arbeitsalltag eingesetzt werden kann. Eine Demo arbeitet möglicherweise mit wenigen vorbereiteten Fragen und kurzen Dokumenten. Der Produktivbetrieb bringt jedoch lange Dateien und unpräzise Anfragen mit sich, die das System korrekt verstehen muss. Hinzu kommen unterschiedliche Dokumentenversionen und mehrere Personen, die den Assistenten zur selben Zeit nutzen.

Eine Demo kann daher ein guter Anfang sein, sollte jedoch nicht der letzte Schritt vor der Anschaffung eines Servers sein. In der Praxis ist es sinnvoll, vom Anbieter oder dem internen IT-Team eine praktische Überprüfung anhand eines realistischen Szenarios zu verlangen – etwa mit ähnlichen Dokumenten, vergleichbarer Anfragelänge und der erwarteten Anzahl gleichzeitiger Nutzer. Dabei kann es sich um einen technischen Proof of Concept handeln, also eine kurze Prüfung, ob die Lösung unter den gegebenen Bedingungen funktioniert, oder um einen Pilotbetrieb für ein ausgewähltes Team. Die Form variiert je nach Anbieter und Projektgröße, das Ziel bleibt jedoch stets dasselbe: noch vor der Investition herauszufinden, ob die Leistung aus der Präsentation mit der Realität im Unternehmen Schritt hält.

Ein Server kann ausreichen, wenn Sie wissen, was Sie von ihm erwarten

Für die Entwicklung, das Testen kleinerer Modelle oder einen internen Assistenten für einen begrenzten Personenkreis kann ein einzelner leistungsstarker KI-Server eine sehr gute Lösung sein. Das Unternehmen behält die Kontrolle über seine Daten, profitiert von einem stabileren Kostenrahmen und kann Modelle anpassen, ohne ständig sensible Eingaben an einen externen Dienst zu senden. Bei vorhersehbarer Auslastung kann eine eigene Infrastruktur wirtschaftlich sinnvoller sein als die dauerhafte Bezahlung von Cloud-Kapazitäten.

Bei einer einzelnen Maschine muss vor allem an Lastspitzen und die Hochverfügbarkeit des Dienstes gedacht werden. Bedient der Server eine geschäftskritische Anwendung, muss ein Teil der Leistung als Betriebspuffer reserviert bleiben. Ebenso sind Aktualisierungen des Modells, der Treiber oder der Inference Engine erforderlich, die das Verhalten des gesamten Dienstes vorübergehend verändern und dessen Leistung beeinflussen können. Sobald der KI-Assistent von einem begrenzten Einsatz in den Arbeitsalltag mehrerer Teams übergeht, wird die Modellreplikation, der Einsatz mehrerer GPUs oder ein Cluster aus mehreren Servern sinnvoll.

Die Cloud hat ihre Stärken dort, wo sich Arbeitslasten ändern, sprunghaft ansteigen oder das passende Modell erst noch ermittelt werden muss. Ein eigener Server eignet sich besser, sobald das Unternehmen das Betriebsprofil kennt und weiß, dass die Infrastruktur regelmäßig genutzt wird. Die Entscheidung sollte daher nicht allein auf dem Vergleich zwischen Anschaffungskosten des Servers und Cloud-Preisen basieren, sondern auch darauf, wie stabil die Auslastung sein wird, wie sensibel die Daten sind und wie hoch der Verwaltungsaufwand für die gesamte Umgebung ausfällt.

Wie Sie einen Benchmark beauftragen, der geschäftlichen Wert hat

Ein guter Kapazitätstest beginnt mit der Beschreibung des Dienstes, nicht mit der Auswahl der GPU. Ein Unternehmen sollte wissen, welche Nutzergruppen das System verwenden werden, welche Fragen sie stellen, wie lange Dokumente verarbeitet werden sollen und welche Antwortzeit noch akzeptabel ist. Ohne diese Vorgaben wird der Benchmark zu einer reinen Technikübung, die mit dem künftigen Produktivbetrieb kaum etwas gemein haben dürfte.

Das technische Team sollte nicht nur die durchschnittliche Antwortzeit messen, sondern auch die p95- und p99-Latenz. Diese Werte geben an, innerhalb welcher Zeitspanne 95 bzw. 99 % der Anfragen beantwortet werden, und decken langsame Antworten auf, die im Durchschnitt leicht untergehen. Im Unternehmensbetrieb sind häufig Lastspitzen, lange Dokumente und atypische Anfragen ausschlaggebend, da sich dort die tatsächliche Leistungsreserve der Infrastruktur zeigt. Im Test sollten dieselben Komponenten eingesetzt werden wie im späteren Produktivbetrieb: Nutzt die Anwendung RAG, muss auch die Dokumentensuche Teil des Benchmarks sein. Soll auf Deutsch geantwortet werden, müssen deutsche Anfragen getestet werden, und wenn die Nutzer lange Anhänge senden, ist ein kurzer Beispiel-Prompt für eine Kapazitätsentscheidung irreführend.

In der Praxis genügt es, mit fünf Kennzahlen zu beginnen, die die technische Leistung des Servers in den realen Unternehmensbetrieb übersetzen.

Sobald diese Zahlen vorliegen, lässt sich ein Server anhand der Realität vergleichen und nicht anhand von Marketingparametern. Ohne sie wird die Wahl der Infrastruktur schnell zu einer kostspieligen Wette darauf, dass die Leistung im Datenblatt dem tatsächlichen Unternehmensbetrieb entspricht.

Die entscheidende Frage bei der Auswahl eines KI-Servers lautet daher nicht, wie leistungsfähig die verbaute GPU ist. Weitaus aufschlussreicher ist es zu ermitteln, wie viele Token pro Sekunde das System in einer konkreten Anwendung, mit einem bestimmten Modell, bei einer definierten Kontextlänge und inklusive Puffer für Lastspitzen liefern kann. Genau hier entsteht der Unterschied zwischen einem KI-Server, der in einer Präsentation glänzt, und einer Infrastruktur, die den Mitarbeitern die Arbeit spürbar erleichtert. Ein Unternehmen, das KI ernsthaft einsetzen möchte, sollte daher mit einem einfachen Kapazitätsmodell und einem praxisnahen Pilotprojekt starten – nicht um den Kauf zu verzögern, sondern um Geld für Leistung auszugeben, die sich im Echtbetrieb bemerkbar macht und sich künftig sinnvoll skalieren lässt. Bei KI-Servern ist schließlich nicht schwächere Hardware am teuersten, sondern Leistung, die niemand richtig zu nutzen weiß.