On-Premise AI 2026: Warum lokale KI-Infrastruktur gerade zum strategischen Thema wird — und wie viel Leistung ihr wirklich braucht
Drei Wochen im Juni 2026 haben etwas verändert, das viele Unternehmen bis dahin für selbstverständlich hielten: den unbegrenzten Zugriff auf die leistungsstärksten KI-Modelle der Welt.
Erst wurden Claude Fable 5 und Claude Mythos 5 – Anthropics neueste Spitzenmodelle – drei Tage nach Launch per US-Exportkontrollanordnung weltweit gesperrt. Wenige Wochen später traf es OpenAI: GPT-5.6 durfte zunächst nur an rund 20 einzeln von der US-Regierung geprüfte Partnerorganisationen ausgeliefert werden – kein öffentlicher Rollout, keine Selbstbedienung. Mitte Juli sind beide Episoden formal aufgelöst: Fable 5 ist seit dem 1. Juli wieder weltweit verfügbar, GPT-5.6 ist seit dem 9. Juli öffentlich zugänglich. Mythos 5 bleibt bis heute nur für rund 100 handverlesene Organisationen freigegeben.
Der eigentliche Punkt ist nicht, dass diese Sperren am Ende (teilweise) wieder aufgehoben wurden. Der Punkt ist: Sie konnten überhaupt verhängt werden – über Nacht, ohne Vorwarnung, für Unternehmen weltweit, unabhängig davon, ob sie in den USA sitzen oder nicht. Genau dieses Risiko ist der Grund, warum „On-Premise AI“ 2026 von einer Nischen-Diskussion für besonders regulierte Branchen zu einem Thema für praktisch jedes Unternehmen geworden ist, das KI produktiv einsetzt.
Drei Entwicklungen verstärken sich gegenseitig:
- Digitale Souveränität ist kein Compliance-Thema mehr, sondern ein Betriebsrisiko.
Die Export-Kontroll-Episoden rund um Fable 5, Mythos 5 und GPT-5.6 haben gezeigt, dass Zugriff auf US-Frontier-Modelle politisch steuerbar ist. Für Unternehmen, die KI in kritische Prozesse eingebaut haben, ist das kein abstraktes geopolitisches Risiko mehr, sondern eine sehr konkrete Frage: Was passiert mit unserem Produkt, unserem Kundensupport, unserer Entwicklungspipeline, wenn der API-Zugang zum zugrunde liegenden Modell morgen eingeschränkt wird? On-Premise-Betrieb – eigene Hardware, eigenes Rechenzentrum oder zumindest ein souveräner europäischer Anbieter – eliminiert dieses Abhängigkeitsrisiko strukturell.
- Die Kosten für API-basierte KI-Nutzung im großen Maßstab steigen spürbar.
Solange man ein paar Millionen Tokens im Monat verbraucht, ist Pay-as-you-go günstig und bequem. Sobald ein Unternehmen KI aber in der Breite einsetzt – Kundensupport, interne Assistenten, Dokumentenverarbeitung, Coding-Unterstützung für ein ganzes Entwicklerteam – wächst die Rechnung schnell in Regionen, in denen sich reservierte, eigene Kapazität rechnet. Das gilt für Cloud-Anbieter genauso wie für eigene Hardware: Ab einem bestimmten Nutzungsvolumen kippt die Kalkulation zugunsten fester, vorhersehbarer Kosten.
- Open-Weight-Modelle sind Top-Tier-Niveau extrem nahegekommen.
Modelle wie GLM-5.2 (753 Milliarden Gesamt-, ca. 40 Milliarden aktive Parameter, Mixture-of-Experts mit Sparse-Attention) zeigen, dass man für viele Business-Anwendungsfälle kein geschlossenes Flaggschiff-Modell mehr braucht, das nur über eine einzige API verfügbar ist. In Kombination mit modernen Quantisierungsverfahren wie NVFP4 lassen sich solche Modelle auf realistischer, bezahlbarer GPU-Hardware betreiben – mit einem Speicherbedarf, der gegenüber FP8 um rund 38 % sinkt.
Das Ergebnis: Souveränität, Kostenkontrolle und Modellqualität ziehen 2026 zum ersten Mal alle drei in dieselbe Richtung – hin zu eigener, kontrollierter KI-Infrastruktur.
Sobald Unternehmen ernsthaft über On-Premise- oder Private-Cloud-KI nachdenken, taucht fast immer dieselbe Kernfrage auf – meist in drei Teilen:
- Welche Kapazität benötigen wir? Wie viele gleichzeitige Nutzer, wie viele Anfragen pro Minute, welche Prompt-Längen?
- Was kostet das konkret? Hardware, Betrieb, Strom, im Vergleich zur bisherigen API-Rechnung?
- Reicht diese Leistung für unseren tatsächlichen Anwendungsfall – kurze Chat-Interaktionen, Standard-Assistenz oder Long-Context-Workloads wie Codebase-Analyse und RAG?
Die ehrliche Antwort: Das hängt vollständig vom Workload ab. Ein System, das 50 Nutzer bei kurzen FAQ-Antworten mühelos bedient, kann bei langen Kontextfenstern mit denselben 50 Nutzern bereits an seine Grenzen stoßen. Genau deshalb lohnt sich ein belastbarer Benchmark – nicht ein Marketing-Diagramm, sondern echte Lasttests gegen eine produktive Schnittstelle.
Wir haben genau das gemacht: ein selbst gehostetes GLM-5.2-Setup (NVFP4-quantisiert, vLLM v0.23.0, Tensor- und Expert-Parallelism über 8× NVIDIA B200) mit GuideLLM – dem vom vLLM-Projekt für Produktions-Benchmarks empfohlenen Framework – unter drei realistischen Lastprofilen getestet: Quick Q&A, Standard Chat und Long-Context/Coding, jeweils bei 10, 25, 50 und einer unbegrenzten Lastspitze (bis 200 gleichzeitige Anfragen).
Für kurze und mittlere Interaktionen ist das Bild eindeutig gut: Selbst bei 50 gleichzeitigen Nutzern bleibt die Zeit bis zur ersten sichtbaren Antwort im Quick-Q&A-Szenario unter 400 Millisekunden (P95) – spürbar schnelle, interaktive Nutzererfahrung. Wie sich das in absoluten Tokens-pro-Minute übersetzt und wo genau die Kurve abflacht, zeigt der Skalierungs-Chart weiter unten.
Für kurze und mittlere Interaktionen ist das Bild eindeutig gut: Selbst bei 50 gleichzeitigen Nutzern bleibt die Zeit bis zur ersten sichtbaren Antwort im Quick-Q&A-Szenario unter 400 Millisekunden (P95) – spürbar schnelle, interaktive Nutzererfahrung. Wie sich das in absoluten Tokens-pro-Minute übersetzt und wo genau die Kurve abflacht, zeigt der Skalierungs-Chart weiter unten.
Der Punkt an dem es kippt
Bei Long-Context-Workloads mit 8.000 Eingabe-Tokens (typisch für Codebase-Kontext oder RAG mit mehreren Dokumenten) zeigt sich bei einer unbegrenzten Lastspitze von rund 200 gleichzeitigen Anfragen ein klarer Kapazitätskollaps: Von rund 200 gestarteten Requests wurde innerhalb von 60 Sekunden nur eine einzige vollständig verarbeitet – der Rest blieb in der Warteschlange hängen. Der Grund: Bei langen Prompts füllt sich der verfügbare KV-Cache-Speicher bei hoher Parallelität extrem schnell, sodass aus echter Parallelverarbeitung eine reine Warteschlange wird.
Das ist keine Schwäche des Modells, sondern ein Kapazitätsplanungs-Fakt, den jedes On-Premise-Setup kennen muss: Die maximal sinnvolle Nutzerzahl hängt massiv vom Anwendungsfall ab – nicht nur von der Hardware.
Kapazitätsplanung im Überblick
Zur besseren Vergleichbarkeit mit gängigen Kapazitätsangaben haben wir alle 12 Benchmark-Läufe in Tokens pro Minute (TPM) umgerechnet – der Kennzahl, mit der auch Cloud-Anbieter Kapazität ausweisen. Das macht ein Muster sichtbar, das in den Rohzahlen leicht untergeht:
Bei Quick Q&A und Standard Chat wächst der Gesamt-TPM-Wert über die Concurrency-Stufen hinweg nahezu linear – ein gesundes, vorhersagbares Skalierungsverhalten, bei dem mehr gleichzeitige Nutzer im Rahmen der getesteten Werte einfach zu proportional mehr Durchsatz führen, ohne dass die Latenz aus dem Ruder läuft.
Bei Long-Context ist die Kurve dagegen von Anfang an flacher, und zwischen Concurrency 25 und 50 wird die Verlangsamung bereits sichtbar (die P95-Latenz steigt bei 50 gleichzeitigen Nutzern auf rund 8 Sekunden bis zur ersten Antwort). Das ist der Vorbote des Kollapses, der beim ungebremsten Peak-Lauf (rund 200 gleichzeitige Anfragen) dann tatsächlich eintritt: Statt weiter zu skalieren, bricht der nutzbare Durchsatz auf praktisch null ein, weil der KV-Cache-Speicher unter der Last der langen Prompts vollläuft und aus Parallelverarbeitung eine reine Warteschlange wird.
Die praktische Konsequenz für die Kapazitätsplanung: Ein einzelner TPM- oder „Nutzer“-Wert für ein System ist ohne Angabe des Workload-Typs wenig aussagekräftig.
Ein System, das bei kurzen Anfragen mühelos 900.000+ TPM liefert, kann bei langen Kontextfenstern schon bei einem Bruchteil der Nutzerzahl an seine Grenze stoßen. Genau deshalb lohnt sich vor jeder Kapazitätsentscheidung ein Benchmark, der die eigenen, tatsächlichen Prompt-Längen abbildet – nicht ein generischer Wert aus einem Datenblatt.
On-Premise- und Local-AI sind 2026 kein ideologisches Statement mehr, sondern eine nüchterne Risiko-, Kosten- und Kapazitätsfrage. Die Ereignisse rund um Fable 5, Mythos 5 und GPT-5.6 haben gezeigt, dass Modellzugriff politisch steuerbar ist. Open-Weight-Modelle wie GLM-5.2 haben gezeigt, dass die Qualitätslücke zu geschlossenen Flaggschiffmodellen kleiner wird. Und unser Benchmark zeigt: Mit der richtigen Hardware- und Kapazitätsplanung lässt sich daraus ein System bauen, das linear und vorhersagbar skaliert – solange man die Grenzen seines eigenen Workloads kennt und entsprechend plant.
Die entscheidende Arbeit liegt genau dort: nicht in der Frage „Cloud oder On-Premise“, sondern in der Frage „Wie viel Leistung brauche ich für meinen konkreten Anwendungsfall, und für wie viele Nutzer reicht das wirklich?“