On-Premises-KI dimensionieren: Nutzerzahl allein reicht nicht

  • Beitrags-Kategorie:Sustainability
  • Lesedauer:7 Minuten zum Lesen

Wer On-Premises-KI dimensioniert, braucht mehr als eine Mitarbeiterzahl und eine Modellbezeichnung. Entscheidend ist, welche Aufgaben gleichzeitig bearbeitet werden sollen, wie umfangreich die Eingaben sind und welche Antwortqualität der Fachbereich benötigt. Dieser Leitfaden zeigt, wie Unternehmen, öffentliche Einrichtungen und Betreiber kritischer Infrastruktur daraus überprüfbare Anforderungen für eine lokale KI-Lösung entwickeln können.

In diesem Artikel

Mit dem Anwendungsfall beginnen

Eine interne Wissenssuche, die Zusammenfassung langer Dokumente und ein Assistent für technische Abläufe stellen unterschiedliche Anforderungen. Vor einer Hardwareentscheidung empfehlen wir deshalb, zwei oder drei konkrete Aufgaben zu beschreiben. Zu jeder Aufgabe gehören typische Eingaben, ein erwartetes Ergebnis und Kriterien, nach denen der Fachbereich dieses Ergebnis beurteilen kann.

Für eine Wissenssuche könnte das Ziel beispielsweise lauten: Beschäftigte erhalten zu einer technischen Frage eine verständliche Antwort mit einer überprüfbaren Fundstelle im freigegebenen Dokumentenbestand. Für eine Dokumentenauswertung kann entscheidend sein, ob alle geforderten Angaben vollständig und korrekt extrahiert werden. Ein flüssiger Text ist in beiden Fällen noch kein ausreichender Qualitätsnachweis.

Halten Sie außerdem fest, welche Informationen die Anwendung ausdrücklich nicht verarbeiten soll. Ein abgegrenzter Pilot lässt sich leichter bewerten, wenn Datenbestand, Nutzerrollen und erlaubte Aktionen vorher bekannt sind. Die Erweiterung auf zusätzliche Aufgaben wird dadurch zu einer bewussten Entscheidung und nicht zum unbeabsichtigten Ergebnis wachsender Berechtigungen.

Anfragen und Gleichzeitigkeit getrennt erfassen

Für eine erste Mengenbetrachtung helfen aktive Nutzer, Anfragen je Tag sowie typische Ein- und Ausgabelängen. Für die technische Dimensionierung kommt es zusätzlich darauf an, wann die Anfragen eintreffen. Eine Tagesmenge kann gleichmäßig verteilt sein oder sich in kurzen Zeitfenstern konzentrieren. Deshalb empfehlen wir, mindestens einen Normalbetrieb und ein nachvollziehbares Spitzenszenario zu beschreiben.

Ein Modellbeispiel verdeutlicht den Unterschied: 50 aktive Nutzer mit jeweils 20 Anfragen erzeugen 1.000 Anfragen pro Tag. Bei angenommenen 2.000 Eingabe- und 500 Ausgabetokens pro Anfrage entstehen zwei Millionen Eingabetokens und 500.000 Ausgabetokens. Über acht Stunden gleichmäßig verteilt entsprechen die Ausgaben durchschnittlich etwa 17,36 Tokens pro Sekunde. Diese Zahl beschreibt lediglich den rechnerischen Tagesdurchschnitt des Gesamtsystems.

Treffen mehrere lange Anfragen gleichzeitig ein, kann die kurzfristige Anforderung erheblich darüber liegen. Aus dem Durchschnitt lässt sich daher weder die notwendige GPU-Anzahl noch eine akzeptable Wartezeit ableiten. Der Edge-AI-Bedarfsrechner hilft, Annahmen transparent zu machen. Eine belastbare Hardwareauswahl erfordert anschließend Messungen mit dem vorgesehenen Modell und Arbeitsprofil.

Welche Leistungskennzahlen im Pilot relevant sind

Für interaktive Anwendungen sind mehrere Messgrößen sinnvoll: die Wartezeit bis zum ersten ausgegebenen Token, die Zeit bis zur vollständigen Antwort und der Durchsatz bei parallelen Anfragen. Diese Werte beantworten unterschiedliche Fragen. Ein System kann insgesamt viele Tokens verarbeiten, während einzelne Nutzer trotzdem lange warten. Definitionen und Messverfahren sollten bei jedem Vergleich übereinstimmen. Quelle: NVIDIA, LLM-Benchmarking-Metriken, aktualisiert am 20. Juli 2026.

Für die Abnahme empfehlen wir, konkrete Anforderungen gemeinsam mit dem Fachbereich festzulegen. Ein interaktiver Assistent kann eine andere Wartezeit erlauben als ein nächtlicher Verarbeitungslauf. Zusätzlich sollten langsame Einzelfälle sichtbar bleiben. Ein Tagesmittelwert allein verrät nicht, wie häufig Beschäftigte ungewöhnlich lange auf eine Antwort warten müssen.

Dokumentieren Sie deshalb für jeden Testlauf das Modell, das Speicherformat, die Softwareversion, die Eingabelängen, die Ausgabelängen und die parallele Last. Notieren Sie außerdem, ob das Modell bereits geladen war und ob zwischengespeicherte Ergebnisse verwendet wurden. Ein Vergleich ist besonders hilfreich, wenn eine andere Person ihn unter denselben Bedingungen wiederholen kann.

Modellgewichte sind nur ein Teil des Speicherbedarfs

Für eine erste rechnerische Untergrenze lässt sich der Speicher der Modellgewichte aus Parameterzahl und Bits je Parameter überschlagen. Ein hypothetisches Modell mit 32 Milliarden Parametern bei vier Bits je Parameter benötigt rechnerisch 16 Milliarden Bytes, also rund 14,9 GiB allein für diese Gewichte. Die Rechnung berücksichtigt weder zusätzliche Verwaltungsdaten noch Arbeitsspeicher für die Ausführung.

Das ist ausdrücklich keine Aussage, dass eine Grafikkarte mit 16 GB für dieses Modell und Ihren Anwendungsfall ausreicht. Kontextverwaltung, Laufzeit und weitere Komponenten benötigen zusätzliche Ressourcen. Auch das verwendete Format und die konkrete Implementierung müssen berücksichtigt werden. Eingabe- und Ausgabelängen beeinflussen zudem den Inferenzablauf und den Speicher für den sogenannten KV-Cache. Quelle: NVIDIA, LLM Inference Benchmarking: Fundamental Concepts.

Unsere Empfehlung lautet, Speicherbetrachtung und fachliche Bewertung gemeinsam durchzuführen. Eine kleinere Darstellung der Gewichte kann technisch attraktiv sein; entscheidend bleibt, ob die benötigten Aufgaben zuverlässig bearbeitet werden. Ein größeres Modell sollte ebenso wenig allein wegen seiner Parameterzahl bevorzugt werden. Maßgeblich sind die Ergebnisse mit Ihren repräsentativen Aufgaben.

Unternehmenswissen anbinden und Berechtigungen erhalten

Für einen Wissensassistenten empfehlen wir einen bewusst ausgewählten Dokumentenbestand. Prüfen Sie zunächst, ob Dokumente aktuell, eindeutig bezeichnet und für die vorgesehenen Nutzer freigegeben sind. Unklare Versionen oder widersprüchliche Inhalte sollten als Datenproblem behandelt werden. Eine zusätzliche KI-Schicht macht diese Widersprüche nicht automatisch unschädlich.

Bei einer Suche mit anschließend generierter Antwort, häufig als Retrieval Augmented Generation oder RAG bezeichnet, sollten im Pilot auch die gefundenen Quellen geprüft werden. Wird die richtige Passage verwendet? Ist sie für die konkrete Frage ausreichend? Kann eine berechtigte Person die Fundstelle öffnen? Enthält die Antwort Aussagen, die durch diese Fundstelle nicht gedeckt sind?

Für Berechtigungen empfehlen wir ausdrücklich negative Testfälle: Ein Benutzer ohne Zugriffsrecht darf die gesperrten Informationen weder als Suchtreffer noch in einer daraus erzeugten Antwort erhalten. Diese Prüfung sollte auch indirekte Nachfragen umfassen. Fachliche Qualität und Zugriffsschutz gehören damit in denselben Abnahmekatalog.

Lokaler Betrieb braucht kontrollierte Datenflüsse

Ein Server im eigenen Haus ist ein wichtiger Architekturbaustein. Für die Bewertung der Datenhoheit empfehlen wir zusätzlich eine vollständige Übersicht der Datenwege: Welche Dienste werden angesprochen? Wo liegen Protokolle und Sicherungen? Wie erfolgen Updates? Welche Zugriffe erhalten Administratoren und Wartungsdienstleister? Werden externe Recherchefunktionen oder andere Schnittstellen genutzt?

Das BSI weist bei KI-Anwendungen auf die Bedeutung von Zugriffsberechtigungen hin: Zusätzliche angebundene Ressourcen erweitern die Handlungsmöglichkeiten und müssen bewusst berücksichtigt werden. Quelle: BSI, Anwendungen mit Künstlicher Intelligenz sicher nutzen.

Für Organisationen mit hohen Schutzanforderungen empfehlen wir, das System zunächst mit den für den Anwendungsfall erforderlichen Rechten auszustatten und jede Erweiterung gezielt zu prüfen. Eine pauschale Aussage wie „lokal bedeutet vollständig sicher“ ist für die Projektentscheidung zu ungenau. Nachvollziehbare Architektur, definierte Rollen und geprüfte Betriebsabläufe liefern die wesentlich bessere Grundlage.

Autonome Abläufe schrittweise freigeben

Soll die KI Aktionen ausführen, empfehlen wir eine klare Trennung zwischen Vorschlag, Prüfung und Ausführung. Im ersten Schritt kann ein Assistent einen Arbeitsauftrag vorbereiten. Erst nachdem Qualität und Berechtigungen bewertet wurden, wird festgelegt, welche Schritte automatisiert ausgeführt werden dürfen. Bei folgenreichen Änderungen werden geeignete menschliche Freigaben vorgesehen.

Zur Vorbereitung gehören auch Fehlerfälle: Was passiert bei einer unvollständigen Eingabe? Wie wird eine widersprüchliche Quelle behandelt? Kann eine Aktion abgebrochen werden? Wie lässt sich nachvollziehen, welcher Auftrag zu welcher Änderung geführt hat? Ein überzeugender Pilot zeigt nicht nur den gelungenen Standardfall, sondern auch einen kontrollierten Umgang mit solchen Situationen.

Die Einordnung für KRITIS, NIS2 oder andere organisationsbezogene Anforderungen muss gesondert erfolgen. Dieser Artikel leitet aus einer lokalen Installation keine pauschale Konformität ab. Im Projekt werden Schutzbedarf, Zuständigkeiten und erforderliche Nachweise konkret festgelegt.

Pilot und Betrieb gemeinsam vorbereiten

Für einen prüfbaren Pilot empfehlen wir folgende Reihenfolge:

  • Aufgaben festlegen: Repräsentative Fragen und Dokumente zusammenstellen sowie erwartete Ergebnisse beschreiben.
  • Qualität bewerten: Korrektheit, Vollständigkeit, Quellenbezug und Umgang mit fehlenden Informationen prüfen.
  • Last messen: Normalbetrieb, parallele Nutzung und relevante Spitzen mit dokumentierten Einstellungen testen.
  • Zugriffe prüfen: Erlaubte und gesperrte Datenbestände sowie vorgesehene Aktionen gezielt testen.
  • Betrieb erproben: Wiederanlauf, Sicherung, Wiederherstellung und ein kontrolliertes Update vorbereiten.

Ein Abnahmeprotokoll sollte neben Ergebnissen auch bekannte Grenzen enthalten. Wird beispielsweise nur ein bestimmter Dokumententyp zuverlässig verarbeitet, bleibt diese Begrenzung sichtbar. Der nächste Ausbau kann dann gezielt ansetzen. Auf diese Weise entsteht eine überprüfbare Entwicklung vom ersten Anwendungsfall zum produktiven System.

Edge AI und Rechenzentrumsinfrastruktur zusammen denken

Die ausgewählte KI-Plattform muss am vorgesehenen Standort betrieben werden können. Für die Planung empfehlen wir deshalb einen Abgleich von elektrischer Versorgung, Kühlung, Platzbedarf, Netzwerk und Wartungszugang. Reserven werden anhand eines konkreten Ausbauplans beschrieben. Ein technischer Pilot am Arbeitsplatz ersetzt diese Prüfung für den späteren Dauerbetrieb nicht.

High Knowledge verbindet die Planung souveräner KI mit der benötigten Infrastruktur. Mehr zu Anwendungsfeldern, Datenhoheit und Einführung finden Sie unter Souveräne KI und Edge AI. Wenn für das Vorhaben zusätzliche Rechenzentrumskapazität benötigt wird, bietet eine Machbarkeitsstudie die Grundlage für den Vergleich geeigneter Varianten.

Redaktioneller Stand: 8. September 2026. Zahlenbeispiele sind Modellannahmen und keine Hardware- oder Leistungsgarantie. Verlinkte Primärquellen wurden an diesem Tag geprüft.