Strategie & Forschung

Rechenzeit ist keine Ware mehr, sondern eine Warteliste – und dein Anbieter steht selbst darauf

27. Juli 2026 · 13 Min. Lesezeit · Beyond Prompt AI Studio

Zwischen dem 25. und 27. Juli 2026 sind drei Meldungen erschienen, die in der Berichterstattung nichts miteinander zu tun haben. Nvidia verhandelt laut Wall Street Journal über eine Bürgschaft von rund 250 Milliarden US-Dollar, damit OpenAI Kapazität aus einem geplanten 10-Gigawatt-Rechenzentrum in Ohio mieten kann. Microsoft rationiert parallel die Azure-Kapazität und hat offen erklärt, dass bei Knappheit die eigenen Copilot-Produkte Vorrang haben. Und Moonshot AI hat die Gewichte von Kimi K3 veröffentlicht, dem mit 2,8 Billionen Parametern größten je frei verfügbaren Sprachmodell. Die erste Meldung läuft als Börsenthema, die zweite als IT-Ärgernis, die dritte als Modellvergleich. Diese Analyse argumentiert, dass es dieselbe Nachricht aus drei Richtungen ist: Nicht Intelligenz ist das knappe Gut, sondern Rechenkapazität. Sie wird nicht über den Preis verteilt, sondern über eine Prioritätsliste. Und für ein mittelständisches Unternehmen mit einem laufenden KI-Projekt hat das Konsequenzen, die in keiner der drei Meldungen vorkommen.

Das Wichtigste in Kürze

Bei einem proprietären Modell gibt es genau eine Warteschlange – und der Anbieter steht mit seinem eigenen Produkt darin. Microsoft hat erklärt, dass bei knapper Kapazität die internen Copilots für Microsoft 365, GitHub und Security Vorrang bekommen. Dein Lieferant ist gleichzeitig dein Mitbewerber um dieselben Chips.
Verfügbarkeit steht in keinem Standard-SLA. Ein Uptime-SLA garantiert, dass eine laufende Ressource läuft – nicht, dass du eine bekommst. Eine abgelehnte Zuteilung ist kein Ausfall, also entsteht daraus auch kein Anspruch. Wer Kapazität garantiert haben will, muss sie separat reservieren und bezahlen.
Kontingent und Kapazität sind zwei verschiedene Dinge. Ein erhöhtes Kontingent bringt nichts, wenn in der Region keine Hardware frei ist – die Fehlermeldung heißt dann nicht Limit erreicht, sondern schlicht nicht verfügbar. Diese Unterscheidung fehlt in fast jeder Projektplanung.
Der Preis, auf den viele Budgets planen, ist kein Marktpreis. Wenn ein Chiphersteller die Miete seines größten Kunden verbürgt, ist die Nachfrage vorfinanziert. Zusammen mit dem Befund aus unserer früheren Analyse – pro Leistungsklasse sind die Listenpreise seit Anfang 2025 eher gestiegen – ist die Annahme wird schon billiger keine belastbare Planungsgrundlage.
Offene Gewichte schützen nicht, weil man sie selbst hostet – das ist für den Mittelstand nachweislich unwirtschaftlich –, sondern weil mehrere Anbieter dasselbe Modell anbieten können. Der praktische Unterschied zwischen offen und proprietär ist nicht Kontrolle, sondern die Anzahl der Warteschlangen, in die man sich stellen kann.
Wechselfähigkeit ist eine Architektur-Eigenschaft, keine Vertragsklausel. Wer sie erst braucht, wenn die Zuteilung ausbleibt, baut sie zu spät. Die drei Bausteine: eine Abstraktionsschicht statt anbieterspezifischer SDK-Aufrufe, ein eigenes Testset zur Bewertung von Alternativen, und die saubere Trennung von interaktiven und verschiebbaren Aufgaben.

Drei Meldungen, ein Befund

Am 27. Juli 2026 berichtete das Wall Street Journal, Nvidia verhandle über eine Bürgschaft in Höhe von rund 250 Milliarden US-Dollar. Damit soll OpenAI Rechenkapazität aus einem 10-Gigawatt-Campus im südlichen Ohio mieten können, den eine Energietochter von SoftBank auf dem Gelände einer stillgelegten Urananreicherungsanlage errichtet. Separat verhandelt Nvidia offenbar über die Finanzierung der Chips, die in dieses Rechenzentrum kommen sollen – ein Volumen von bis zu 350 Milliarden. Der Gesamtcampus wird auf über 500 Milliarden taxiert. Reuters hat den Bericht nicht bestätigt. Die Kritik kam trotzdem sofort: Der Investor Michael Burry kommentierte öffentlich, hier verbürge ein Chiphersteller die Ausgaben eines Kunden für die Chips desselben Herstellers.

Am selben Wochenende lief eine zweite Geschichte, deutlich leiser. Microsoft rationiert die Kapazität in Azure. Die Nachfrage übersteigt das Angebot so deutlich, dass eingehende Rechenleistung aktiv zugeteilt wird – zwischen Kundenworkloads, eigenen Diensten, Forschungslasten und Ersatzhardware. Einzelne Regionen gelten als voll, Kunden berichten von abgelehnten Kapazitätsanfragen und von Migrationsprojekten, die auf halber Strecke stehen bleiben. Microsoft hat dabei nicht einmal ein Geheimnis daraus gemacht, wie priorisiert wird: Bei Knappheit gehen die eigenen KI-Produkte vor – die Copilots in Microsoft 365, in GitHub und im Sicherheitsbereich. Der Zustand soll mindestens bis Ende 2026 anhalten.

Und drittens hat Moonshot AI am 27. Juli die Gewichte von Kimi K3 freigegeben: 2,8 Billionen Parameter, rund 1,4 Terabyte Download, das mit Abstand größte je offen veröffentlichte Sprachmodell. In der Frontend Code Arena belegt es aktuell Platz eins vor westlichen Spitzenmodellen. Diese drei Meldungen werden in drei verschiedenen Ressorts abgelegt – Finanzen, IT-Betrieb, Modellvergleich. Zusammengelesen ergeben sie einen einzigen Befund: Der Engpass in der KI-Wirtschaft ist nicht mehr die Frage, wie klug ein Modell sein kann. Der Engpass ist Rechenkapazität. Und Kapazität wird gerade nicht über den Preis verteilt, sondern über eine Rangfolge.

Was Microsoft offen sagt – und was daraus folgt

Der interessanteste Satz der letzten Tage stammt nicht aus der Milliardenmeldung, sondern aus der Kapazitätsdebatte. Microsoft priorisiert bei knapper Rechenleistung die eigenen Copilot-Produkte gegenüber Kundenworkloads. Das ist keine Unterstellung von Kritikern, sondern erklärte Zuteilungslogik. Und es beschreibt eine Konstellation, die in Beschaffungsprozessen normalerweise sofort auffallen würde, in der Cloud aber fast nie thematisiert wird: Der Anbieter, bei dem du Rechenzeit kaufst, verkauft mit derselben Hardware ein Produkt, das mit deinem konkurriert – und er entscheidet, wer zuerst bedient wird.

Übersetzt auf ein KI-Projekt im Mittelstand heißt das: Wenn dein Assistent für die Angebotserstellung auf einem gehosteten Frontier-Modell läuft und dieselbe Infrastruktur gleichzeitig den Copilot des Anbieters bedient, dann stehst du mit deinem Anwendungsfall in einer Schlange, in der du nicht vorn stehst. Nicht aus Böswilligkeit, sondern weil jede Rationierung eine Reihenfolge braucht. Und diese Reihenfolge orientiert sich nachvollziehbar am strategischen Wert für den Anbieter, nicht am Wert für dich.

Kontingent ist nicht Kapazität

In der Praxis wird das an einer Unterscheidung sichtbar, die in Projektplanungen fast nie vorkommt. Ein Kontingent ist eine Obergrenze, die dir dein Anbieter administrativ zugesteht. Kapazität ist die physische Frage, ob zum Zeitpunkt der Anforderung tatsächlich Hardware frei ist. Beides wird umgangssprachlich vermischt, ist aber unabhängig voneinander. Wenn eine Region ausgelastet ist, hilft eine Kontingenterhöhung nicht – die Anforderung scheitert trotzdem, und die Fehlermeldung sagt dann nicht, dass ein Limit erreicht wurde, sondern dass die gewünschte Ressourcenklasse in dieser Region gerade nicht verfügbar ist. Wer beim Kapazitätsproblem reflexhaft ein höheres Kontingent beantragt, adressiert die falsche Ursache.

Verfügbarkeit steht in keinem Standard-SLA

Der zweite Punkt ist der unangenehmere. Die üblichen Verfügbarkeitszusagen der Hyperscaler beziehen sich auf laufende Ressourcen: Eine bereits gestartete Instanz, ein bereits gebuchter Dienst soll zu einem bestimmten Prozentsatz erreichbar sein. Sie sagen nichts darüber, ob du eine neue Ressource überhaupt bekommst. Eine abgelehnte Zuteilung ist technisch kein Ausfall – es war nie etwas in Betrieb, das ausfallen konnte. Damit entsteht daraus auch kein Anspruch, keine Gutschrift, kein Eskalationspfad. Ein Anbieter kann seine Verfügbarkeitszusage vollständig einhalten und dir gleichzeitig sagen, dass er dir gerade nichts geben kann.

Wer Kapazität wirklich garantiert haben will, muss sie gesondert reservieren und bezahlen – bei Azure etwa über Kapazitätsreservierungen, mit denen man die Zuteilung im Voraus sichert, unabhängig davon, ob man sie gerade nutzt. Das ist eine legitime Option, aber sie kostet, und sie ist das Gegenteil des elastischen Bezahlmodells, mit dem Cloud-Nutzung üblicherweise begründet wird. Der ehrliche Satz lautet: Elastizität nach oben war immer ein Versprechen unter der stillen Annahme, dass genug da ist. Diese Annahme gilt gerade nicht.

Warum der Preis, auf den du planst, kein Marktpreis ist

Zurück zur Nvidia-Meldung – nicht als Börsenthema, sondern als Preissignal. Wenn ein Chiphersteller die Mietverpflichtung seines größten Abnehmers verbürgt und parallel dessen Chipkäufe finanziert, dann ist die Nachfrage nach diesen Chips nicht mehr allein Ausdruck dessen, was Kunden zu zahlen bereit sind. Sie ist zu einem Teil vom Lieferanten selbst getragen. Ob man das für eine kluge Investition oder für Zirkelfinanzierung hält, ist eine Frage für Analysten. Für ein Unternehmen, das ein Budget für die nächsten zwei Jahre plant, ist die relevante Folgerung eine andere: Die Zahlen, aus denen sich Preisentwicklungen ableiten lassen, entstehen gerade nicht in einem normalen Markt.

Das deckt sich mit einem Befund, den wir in einer früheren Analyse zum Kimi-K3-Effekt an Listenpreisen nachgerechnet haben: Pro Leistungsklasse sind die Preise seit Anfang 2025 nicht gefallen, sondern eher gestiegen. Billiger wird zuverlässig nur die Qualität von gestern; das jeweils aktuelle Spitzenmodell kostet ungefähr so viel wie das aktuelle Spitzenmodell davor. Wer sein KI-Budget auf die Erwartung stützt, die Inferenz werde schon von selbst günstiger, plant auf eine Zahl, für deren Zustandekommen es gerade sehr viele Sternchen gibt.

Der eigentliche Unterschied zwischen offen und proprietär: die Anzahl der Warteschlangen

Hier kommt die dritte Meldung ins Spiel, und zwar anders, als es die naheliegende Lesart nahelegt. Die naheliegende Lesart lautet: Offene Gewichte bedeuten, dass man unabhängig wird, weil man das Modell selbst betreiben kann. Diese Lesart haben wir in einem früheren Artikel konkret durchgerechnet und verworfen. Ein Modell mit 2,8 Billionen Parametern selbst zu betreiben, erfordert auch bei starker Quantisierung eine zweistellige Zahl an High-End-Beschleunigern; die realistische Größenordnung liegt im mittleren fünfstelligen bis unteren sechsstelligen Bereich pro Monat, nur für die Rechenleistung. Für ein Unternehmen mit zwanzig bis fünfzig Mitarbeitenden ist das keine Option, sondern eine Rechnung, die man einmal aufstellt und dann weglegt.

Der Wert offener Gewichte liegt für den Mittelstand woanders, und er wird selten benannt. Er liegt darin, dass mehrere unabhängige Anbieter dasselbe Modell hosten können. Ein proprietäres Modell hat genau einen Betreiber, also genau eine Warteschlange, genau eine Preisliste, genau eine Prioritätslogik und genau einen Zeitpunkt, zu dem es abgekündigt werden kann. Ein offenes Modell mit ernstzunehmender Leistung kann bei mehreren Anbietern liegen, auch bei europäischen mit Datenresidenz in der EU. Der praktische Unterschied ist also nicht Kontrolle über das Modell – die hat man in beiden Fällen nicht. Der Unterschied ist die Anzahl der Türen, durch die man gehen kann, wenn eine davon zu ist.

Und genau das ist die Nachricht, die der 27. Juli für Unternehmen enthält. Nicht dass ein chinesisches Modell einen Benchmark anführt – Ranglisten wechseln monatlich. Sondern dass es zum ersten Mal ein frei verfügbares Modell auf einem Leistungsniveau gibt, bei dem ein Wechsel keinen spürbaren Qualitätsverzicht bedeutet. Vor einem halben Jahr war Anbieterunabhängigkeit im KI-Bereich eine Absichtserklärung. Seit dieser Woche ist sie eine Option mit belegbaren Zahlen dahinter – vorausgesetzt, das eigene System kann sie überhaupt nutzen.

Was das praktisch heißt

Der entscheidende Satz lautet: Wechselfähigkeit ist eine Architektur-Eigenschaft, keine Vertragsklausel. Wer sie erst beschafft, wenn die Zuteilung ausbleibt, beschafft sie zu spät – ein Wechsel des Modellanbieters ist in einem gewachsenen System nicht eine Konfigurationsänderung, sondern ein Projekt. Drei Ebenen sind dabei zu unterscheiden.

Vertraglich

Klären, in welcher Kundenklasse ihr bei eurem Anbieter geführt werdet. Rahmenverträge mit Abnahmeverpflichtung und reine nutzungsabhängige Konten werden bei Zuteilungsengpässen nachweislich unterschiedlich behandelt.
Prüfen, was eure Verfügbarkeitszusage tatsächlich abdeckt – und dabei zwischen dem Betrieb bestehender Ressourcen und der Zuteilung neuer sauber unterscheiden. Der zweite Fall ist im Regelfall nicht abgedeckt.
Für wirklich geschäftskritische Lasten die Frage stellen, ob eine bezahlte Kapazitätsreservierung günstiger ist als das Risiko eines Stillstands. Das ist eine Rechnung, keine Glaubensfrage – aber sie muss vor dem Engpass aufgemacht werden.
Bei jedem KI-Anbieter im Vertrag nachlesen, mit welcher Frist ein Modell abgekündigt werden kann. Modellabkündigungen sind der häufigste erzwungene Wechsel, und die Fristen sind oft kürzer als der eigene Umstellungsaufwand.

Architektonisch

Anbieterspezifische Aufrufe hinter einer eigenen dünnen Schicht kapseln, statt das SDK eines Anbieters quer durch die Anwendung zu streuen. Das ist wenig Arbeit am Anfang und sehr viel Arbeit im Nachhinein.
Ein eigenes Testset mit echten Fällen aus dem eigenen Betrieb aufbauen – dreißig bis fünfzig reichen für den Anfang. Ohne dieses Set lässt sich die Frage, ob ein Alternativmodell gut genug ist, nicht in Stunden beantworten, sondern nur in Wochen.
Prompts und Modellzuordnung als Konfiguration behandeln, nicht als Code. Ein Wechsel sollte eine Änderung an einer Stelle sein, nicht an dreißig.
Mindestens einen Zweitanbieter einmal produktionsnah durchgetestet haben, bevor man ihn braucht. Ein nie ausgeführter Notfallplan ist kein Notfallplan.

Betrieblich

Die eigenen Anwendungsfälle danach sortieren, ob sie interaktiv sind oder verschiebbar. Ein Chat-Assistent im Kundengespräch verträgt keine Verzögerung; eine nächtliche Dokumentenauswertung schon. Verschiebbare Lasten sind bei Knappheit die günstigste Reserve, weil man sie zeitlich oder regional verlegen kann.
Wissen, welcher Anwendungsfall wirklich ein Spitzenmodell braucht. Ein Großteil dessen, was in Unternehmen auf Frontier-Modellen läuft, läuft dort aus Gewohnheit – und genau diese Lasten lassen sich bei einem Engpass zuerst verlagern.
Den Ernstfall benennen, bevor er eintritt: Was passiert konkret, wenn euer Hauptanbieter für zwei Wochen keine zusätzliche Kapazität zuteilt? Wenn darauf niemand antworten kann, ist das das Ergebnis der Übung.

Was daraus ausdrücklich nicht folgt

Diese Analyse ist kein Argument gegen große Cloud-Anbieter und erst recht keine Empfehlung, jetzt Hardware zu kaufen. Eigene Beschleuniger zu betreiben ist für die allermeisten Unternehmen die teuerste denkbare Antwort auf ein Problem, das sie vermutlich nie in voller Härte trifft. Es ist auch kein Argument dafür, aus Prinzip auf ein offenes Modell zu wechseln – die datenschutzrechtlichen Fragen bei einem chinesischen Anbieter bleiben bestehen und sind an anderer Stelle ausführlich behandelt. Und die Nvidia-Meldung ist bislang unbestätigt; sie taugt als Signal, nicht als Tatsache.

Was folgt, ist etwas Nüchterneres: Die stille Annahme, dass Rechenleistung jederzeit in beliebiger Menge verfügbar ist, war fünfzehn Jahre lang richtig genug, um sie nicht zu prüfen. In der KI-Schicht stimmt sie derzeit nicht. Wer ein KI-Projekt plant, sollte Kapazität ab sofort wie jede andere Lieferkette behandeln – mit der Frage, wer im Ernstfall vor einem bedient wird, und mit mindestens einer zweiten Bezugsquelle, die man schon einmal benutzt hat.

Fazit

Die drei Meldungen dieser Woche sagen dasselbe. Die Bürgschaft sagt: Kapazität ist so knapp und so teuer, dass sie vorfinanziert werden muss. Die Rationierung sagt: Sie wird nach Rangfolge verteilt, und der Anbieter steht selbst in der Reihe. Die offenen Gewichte sagen: Es gibt zum ersten Mal eine belastbare Alternative zu genau einer Reihe. Für ein mittelständisches Unternehmen ist die Konsequenz weder Panik noch Anbieterwechsel, sondern eine Fähigkeit: wechseln zu können, ohne dass es ein Projekt wird.

Diese Fähigkeit kostet am Anfang wenige Tage – eine Abstraktionsschicht, ein eigenes Testset, eine ehrliche Sortierung der Anwendungsfälle. Nachträglich kostet sie ein Vielfaches, und zwar genau zu dem Zeitpunkt, an dem man sie braucht und keine Zeit hat. Das ist der ganze Rat, und er ist unspektakulär: Die Frage ist nicht, welches Modell gerade das beste ist. Die Frage ist, wie lange ihr braucht, um ein anderes zu benutzen.

Häufige Fragen zu Kapazitätsknappheit und KI-Projekten

Betrifft die Azure-Kapazitätsknappheit auch kleine und mittlere Unternehmen?

Ja, und tendenziell stärker. Bei einer Rationierung wird nach Rangfolge zugeteilt, und Kunden mit großen Rahmenverträgen werden dabei anders behandelt als Konten mit reiner nutzungsabhängiger Abrechnung. Hinzu kommt, dass Microsoft die eigenen Copilot-Produkte bei Knappheit ausdrücklich vorzieht. Ein kleines Unternehmen mit einem einzelnen KI-Anwendungsfall steht in dieser Reihenfolge nicht vorn.

Schützt uns unser Verfügbarkeits-SLA nicht davor?

In der Regel nicht. Übliche Verfügbarkeitszusagen beziehen sich auf den Betrieb bereits laufender Ressourcen, nicht auf den Anspruch, eine neue zu erhalten. Eine abgelehnte Zuteilung gilt technisch nicht als Ausfall, weil nie etwas in Betrieb war, das ausfallen konnte – entsprechend gibt es weder Gutschrift noch Eskalationsanspruch. Wer Kapazität garantiert haben will, muss sie gesondert reservieren und bezahlen.

Sollten wir wegen der Knappheit auf ein offenes Modell wie Kimi K3 wechseln?

Nicht aus diesem Grund allein, und vor allem nicht mit dem Ziel, es selbst zu betreiben – das ist bei 2,8 Billionen Parametern für mittelständische Budgets unwirtschaftlich. Der eigentliche Wert offener Gewichte liegt darin, dass mehrere Anbieter dasselbe Modell hosten können, auch mit Datenhaltung in der EU. Das schafft eine echte Ausweichmöglichkeit. Die datenschutzrechtliche Prüfung des jeweiligen Anbieters ersetzt das nicht.

Was ist der schnellste erste Schritt, wenn wir heute anfangen wollen?

Zwei Dinge, beide in wenigen Tagen machbar. Erstens: alle anbieterspezifischen Aufrufe hinter einer eigenen dünnen Schicht bündeln, statt das SDK quer durch die Anwendung zu verteilen. Zweitens: dreißig bis fünfzig echte Fälle aus dem eigenen Betrieb als Testset sammeln. Damit lässt sich die Frage, ob ein Alternativmodell gut genug ist, an einem Nachmittag beantworten statt in Wochen.

Wollt ihr KI so aufsetzen, dass ein Anbieterwechsel Tage statt Monate dauert – bevor ihr ihn braucht?

Custom Applications entdecken Alle Artikel