Auf jede große Veröffentlichung eines Open-Weight-Modells folgt eine vertraute Prognose: Bald verdrängen Laptops und Smartphones die Cloud, und KI-Rechenzentren verlieren ihre heutige Bedeutung.

Wahrscheinlicher ist ein weniger sauberer Ausgang. Lokale KI wird wachsen. Der Bildschirm, auf dem KI erscheint, und der Ort, an dem die Rechenarbeit stattfindet, sind jedoch zwei verschiedene Fragen. Ein kleines Modell auf dem Gerät kann ein Gespräch eröffnen, sensible Angaben entfernen oder einen kurzen Befehl erledigen. Lange Schlussfolgerungen, große Kontexte und Aufgaben mit vielen Werkzeugen können trotzdem ins Rechenzentrum wandern. Mehr lokale Nutzung und mehr Inferenz im Rechenzentrum schließen sich nicht aus.

Das ist weder eine Abwertung lokaler Modelle noch die Behauptung, die Cloud sei immer günstiger. Grundlage sind offizielle Unterlagen und Primärforschung mit Stand vom 25. August 2026. Entscheidend sind die Bedingungen, unter denen ein Rechenzentrum einen strukturellen Vorteil hat – und die Grenzen, an denen dieser Vorteil verschwindet. Es handelt sich nicht um einen selbst gemessenen Geschwindigkeitsvergleich oder eine Marktanteilsprognose für die nächsten fünf Jahre.

Open Weights sind ein echter Fortschritt, aber „lokal“ ist keine einheitliche Klasse

Open Weights bedeutet, dass sich die trainierten Gewichte herunterladen und auf einer selbst gewählten Infrastruktur ausführen lassen. Daraus folgt weder, dass Quellcode und Trainingsdaten vollständig offenliegen, noch dass der Betrieb kostenlos ist.

Die Ankündigung von gpt-oss macht den Unterschied greifbar. Laut OpenAI wurde gpt-oss-20b für den Betrieb in 16GB Speicher ausgelegt; gpt-oss-120b passt in 80GB. Beide sind Open-Weight-Modelle. Das erste kommt für ein leistungsfähiges persönliches Gerät oder eine Edge-Maschine infrage. Das zweite benötigt eine GPU der 80-GB-Klasse oder eine Umgebung mit vergleichbarer Speicherkapazität.

Diagramm der unterschiedlichen Einsatzklassen von gpt-oss-20b mit 16GB und gpt-oss-120b mit 80GB

Zahlenquelle: OpenAI, Introducing gpt-oss. Geprüft am 25.08.2026. Ein Modell in den Speicher zu laden belegt weder Geschwindigkeit noch Qualität.

„Lokal gegen Cloud“ ist deshalb ein zu grober Vergleich. Ein Desktop-PC, ein On-Premises-Cluster im eigenen Serverraum, eine gemietete dedizierte GPU und die API eines Modellanbieters sind unterschiedliche Betriebsformen. Ein vom Unternehmen kontrollierter Server mit acht GPUs ist beim Eigentum lokal, bei Strom, Kühlung und Betrieb aber bereits ein kleines Rechenzentrum. Umgekehrt kann ein Open-Weight-Modell bei einem fremden Cloud-Anbieter laufen.

Auch Leistung hat keine feste Ziellinie. Ein kleines Modell kann ein großes bei einem bestimmten Benchmark einholen. Das belegt nicht, dass es den längeren Agentenlauf von morgen zum gleichen Preis abschließt. Mit Kontextlänge, Werkzeugnutzung, Fehlerbehebung, multimodalen Eingaben und längeren Aufgaben steigen auch die Erwartungen. Die operative Frage lautet daher nicht, wie intelligent ein lokales Modell geworden ist. Sie lautet: Welches Modell beendet die gewünschte Arbeit mit den wenigsten Wiederholungen?

Eine überzeugende erste Antwort kann teuer werden, wenn ein Mensch den Plan mehrfach reparieren, Werkzeuge neu starten oder einen großen Auftrag in viele Prompts zerlegen muss. Sobald die abgeschlossene Aufgabe statt des einzelnen Tokens die relevante Einheit ist, gehören Modellqualität und Betriebskosten zusammen.

Der stärkste Rechenzentrumsvorteil ist der gemeinsame Anfragepool

Teure GPUs allein erklären den strukturellen Vorsprung eines Rechenzentrums nicht. Ebenso wichtig ist eine große, kontinuierlich gefüllte Warteschlange mit Anfragen vieler voneinander unabhängiger Nutzer.

Die Dokumentation von NVIDIA Triton beschreibt dynamisches Batching: Der Server fasst einzelne Inferenzanfragen zusammen und führt sie gemeinsam aus. Das erhöht häufig den Durchsatz. Das Warten auf eine größere Gruppe kann allerdings die Antwort verzögern. Deshalb werden Batchgröße und Wartezeit gegen das Latenzbudget des Dienstes eingestellt.

Diagramm eines unregelmäßigen lokalen Einzelanwender-Workloads neben einem gepoolten Mehrnutzer-Workload, der durch Batching mehr Beschleunigerkapazität auslastet

Konzeptionelle Grundlage: NVIDIA Triton Dynamic Batcher. Der Nutzen hängt von Modell, Eingabelängen, Parallelität und Latenzziel ab.

Interaktive Sprachmodelle erzeugen Ausgabetokens nacheinander; sie können also nicht jede Berechnung in einem einzigen Schritt beenden. Ein Serving-System kann dennoch die Generierungsschritte verschiedener Nutzer auf derselben GPU verschachteln und freie Kapazität reduzieren. Ein Rechenzentrum kann das besonders gut, weil Anfragen über Kunden, Anwendungen, Zeitzonen und Tageszeiten verteilt eintreffen.

Auch lokal ist Batching möglich. Ein Entwickler mit mehreren parallel laufenden Agenten oder ein Unternehmen mit einem gemeinsam genutzten internen Modellserver kann nützliche Parallelität erzeugen. Der Unterschied liegt nicht in der technischen Möglichkeit, sondern in der Wahrscheinlichkeit, dass dauerhaft eine weitere passende Anfrage bereitsteht. Die Abschreibung läuft weiter, während ein einzelner Besitzer schläft. Ein großer Dienst kann dieses Intervall mit Bedarf aus anderen Regionen füllen.

Das ist statistische Multiplexierung, keine kostenlose Rechenleistung. Feste Kapazität wird auf einen breiteren, weniger korrelierten Nachfragepool verteilt. Bleibt eine lokale GPU mit wertvoller Arbeit ausgelastet, schrumpft der Vorteil. Wird teure Hardware nur für gelegentliche Spitzen angeschafft, wächst er.

Eine pauschale Zahl wie „30-mal effizienter“ würde die Aussage eher schwächen. Die PagedAttention-Studie berichtet in den getesteten Workloads bei ähnlicher Latenz einen zwei- bis vierfach höheren Durchsatz als frühere Systeme. Das ist ein wichtiges Ergebnis, aber kein universeller Faktor für jedes Modell und jede GPU. Die Richtung lässt sich begründen; der konkrete Faktor muss in der Zielumgebung gemessen werden.

Entscheidend sind Auslastung und gleichwertige Modellqualität, nicht der GPU-Preis

Eine lokale Rechnung nur mit Stromkosten ist unvollständig. Gleiches gilt für eine API-Rechnung, die nur ein Monatsabo betrachtet. Mindestens braucht der Vergleich einen gemeinsamen Kostenrahmen:

monatliche lokale TCO = (Hardwarepreis - Restwert) / Nutzungsmonate
                         + Durchschnittsleistung × Stunden × Strompreis
                         + Kühlung, Ausfall- und Betriebskosten

monatliche API-Kosten = Eingabetokens × Eingabepreis
                        + Ausgabetokens × Ausgabepreis
                        + Werkzeug-, Speicher- und Netzwerkkosten

Diagramm mit einer lokalen Gesamtkostenformel und offiziellen Speicher- und Bandbreitendaten für RTX 4090 und B200

Hardwaredaten: NVIDIA Ada Architecture Whitepaper und NVIDIA HGX AI Factory Spezifikation. Es sind verschiedene Generationen und Produktklassen, kein direkter LLM-Tokens-pro-Sekunde-Vergleich.

NVIDIA nennt für die RTX 4090 24GB GDDR6X und 1.008GB/s Speicherbandbreite. Eine B200 besitzt 180GB HBM3e und bis zu 8TB/s Bandbreite – etwa 7,5-mal so viel Kapazität und 7,9-mal so viel Bandbreite. Die Zahlen zeigen, dass das Rechenzentrumsprodukt für größere Modelle und mehr gleichzeitige Arbeit konzipiert wurde. Sie beweisen nicht, dass es bei jedem Sprachmodell exakt 7,9-mal schneller ist. Präzisionsformat, Batchgröße, Kontextlänge und Softwarestack verändern die tatsächlich gelieferte Leistung.

Der Break-even-Punkt ist individuell. Ist die GPU bereits vorhanden und rund um die Uhr mit nützlicher Arbeit belegt, können die zusätzlichen lokalen Kosten niedrig sein. Schwankt die Nutzung und wird ein stärkeres Modell nur gelegentlich gebraucht, kann eine API günstiger als ungenutzte Kapazität sein. Dürfen Daten grundsätzlich nicht extern übertragen werden, steht die Kostenfrage nicht an erster Stelle.

Auch OpenAIs Erläuterung zu Open-Weight-Modellen nennt beide Fälle: Self-Hosting kann kosteneffektiv sein; eine API kann unter Einbeziehung von Hosting, Wartung und begleitenden Diensten wirtschaftlicher sein. Diese bedingte Aussage ist belastbarer als ein Slogan. Ohne Nutzungsmenge und Qualitätsziel lässt sich weder „lokal ist immer billiger“ noch „Cloud ist immer billiger“ halten.

Häufig fehlt im Kostenblatt die Vergleichbarkeit der Modelle. Ein kleines lokales Modell ist nicht automatisch günstiger als ein stärkeres Cloud-Modell, wenn es mehr Wiederholungen, zusätzliche Prüfung oder eine niedrigere Abschlussquote verursacht. Sinnvoll ist ein Vergleich pro Aufgabe, die dieselben Abnahmekriterien erfüllt. Günstige Tokens sind keine günstige Arbeit, wenn die Aufgabe offen bleibt.

Es gibt klare Grenzen, an denen lokale Inferenz gewinnt

Die überzeugendsten lokalen Anwendungsfälle entstehen aus harten Bedingungen, nicht aus Vorlieben.

Diagramm der vier strukturellen Vorteile lokaler Inferenz: Datenschutz, Offline-Betrieb, geringe Latenz und Infrastrukturkontrolle

  • Daten dürfen die Umgebung nicht verlassen. In Recht, Medizin oder bei vertraulichen Unternehmensdaten kann eine externe API ausgeschlossen sein. Eigene Infrastruktur ist dann eine Vorgabe.
  • Der Betrieb muss ohne verlässliche Verbindung weitergehen. Feldgeräte, mobile Nutzung und Notfalleinsätze brauchen einen On-Device-Pfad, der einen Netzausfall überlebt.
  • Die Antwortzeit muss kurz und vorhersehbar sein. Tastaturvorschläge, Sprachoberflächen oder Kameraassistenz leiden, wenn ein Netzwerk-Roundtrip im kritischen Pfad liegt.
  • Modell und Protokolle müssen vollständig kontrollierbar bleiben. Self-Hosting eignet sich, wenn eine Version fixiert, angepasst oder der gesamte Datenaufbewahrungspfad geprüft werden muss.

Unter diesen Bedingungen zählt die höchste allgemeine Leistungsfähigkeit weniger als die Frage, ob das System im entscheidenden Moment zuverlässig läuft. Ein kleines spezialisiertes Modell, das einen wiederkehrenden Vorgang sicher beendet, kann wertvoller als ein besser bewertetes Allzweckmodell sein.

Lokal bedeutet trotzdem nicht automatisch sicher. Heruntergeladene Modelle und Laufzeitumgebungen haben Lieferkettenrisiken. Schadsoftware auf dem Rechner, lokale Logs und Backups sowie Nutzerrechte bleiben relevant. Keine Daten an einen Cloud-Dienst zu senden ist eine Datenschutzschicht, aber kein vollständiges Sicherheitskonzept.

Auch die Form des Workloads verschiebt die Grenze. Eine Videoworkstation, die jede Nacht wertvolle Inferenzarbeit erledigt, ist nicht mit einem Laptop vergleichbar, der zweimal pro Woche ein Modell lädt. In einer Fabrik mit ausreichend interner Nachfrage kann ein eigener Server einen großen Teil des Cloud-Auslastungsvorteils erreichen. „Lokal“ sollte die Betriebsbedingungen beschreiben und nicht als Synonym für klein oder ineffizient dienen.

Wahrscheinlicher als ein Sieger ist hybrides Routing

Reale Produkte kombinieren bereits lokale und Cloud-Ausführung. Apples Dokumentation zu Private Cloud Compute beschreibt, dass geeignete Vorgänge auf dem Gerät bleiben, während Anfragen an ein leistungsfähigeres Basismodell in die Cloud gehen. Androids experimentelle Hybrid-Inference-API kann Gemini Nano auf dem Gerät bevorzugen und bei Nichtverfügbarkeit in die Cloud wechseln. Alternativ kann sie die Cloud bevorzugen und offline auf das Gerät zurückfallen.

Diagramm eines hybriden Routings, das private, offlinefähige und sofortige Arbeit lokal hält und tiefe, lange, ressourcenintensive Arbeit an Cloud-Modelle gibt

Umsetzungsbeispiele: Apple Private Cloud Compute und Android experimental hybrid inference. Die Android-Funktion war am 25.08.2026 experimentell.

Der Beitrag Interaction Models von Thinking Machines liefert eine weitere hilfreiche Rollentrennung. Ein Echtzeitmodell bleibt im Dialog reaktionsfähig, während tiefere Schlussfolgerungen und Werkzeugnutzung an ein asynchrones Hintergrundmodell gehen. Das belegt die Trennung eines schnellen und eines tiefen Modells. Es beweist nicht, dass das erste lokal und das zweite in der Cloud läuft. Beides gleichzusetzen würde die Quelle überdehnen.

Ein plausibler Aufbau sieht so aus: Das Gerätemodell bereinigt Eingaben, entfernt private Angaben, liefert kurze Antworten sofort und hält Grundfunktionen offline verfügbar. Servermodelle übernehmen lange Dokumente, große Codebasen, komplexe Werkzeugaufrufe und Entscheidungen mit hohem Qualitätsanspruch. Für den Nutzer bleibt es ein Produkt, obwohl im Hintergrund mehrere Modelle und Ausführungsorte zusammenarbeiten.

Fünf Fragen reichen als Routing-Tabelle:

Frage Spricht für lokal Spricht für Rechenzentrum
Dürfen Daten Gerät oder Standort verlassen? Übertragung verboten oder sensibel Übertragung laut Richtlinie erlaubt
Ist das Internet immer verfügbar? Offline-Betrieb erforderlich Stabile Verbindung vorhanden
Wie lange darf die Antwort dauern? Sofortige Reaktion nötig Längere Verarbeitung vertretbar
Wie tief und lang ist die Aufgabe? Kurz und wiederholbar Langer Kontext, komplexe Werkzeuge
Wie konstant lässt sich Kapazität füllen? Hohe feste Auslastung Schwankende Last oder hohe Parallelität

Mehrere Entwicklungen könnten diese Einschätzung widerlegen. Kleine Modelle könnten schneller besser werden als die Erwartungen steigen. Speicher- und Energieeffizienz könnten große Sprünge machen. Regulierung könnte externe Rechenzentren unpraktisch machen. Umgekehrt würde eine weitere Verlängerung und Verkomplizierung von KI-Aufgaben die Zentralisierung stärken. Keiner dieser Pfade ist heute entschieden.

Aus der gegenwärtigen Struktur folgt dennoch ein klares Ergebnis: Open Weights erweitern die Wahl des Ausführungsorts, beseitigen aber nicht die Ökonomie gepoolter Anfragen, großer gemeinsamer Speicher und Beschleuniger. Meine strukturelle Erwartung ist, dass lokale KI wächst, während ein erheblicher Teil der gesamten Rechenarbeit in Rechenzentren bleibt und das Gerät des Nutzers zur ersten Schicht wird, die über einen Aufruf entscheidet.

Vor der Wahl des Ausführungsorts notieren

  • Prüfen, ob die verglichenen Modelle dieselbe Aufgabenqualität liefern.
  • Monatliche Ein- und Ausgabetokens sowie parallele Anfragen messen.
  • Abschreibung, Strom, Kühlung und Betriebszeit in die lokalen Kosten aufnehmen.
  • Datenschutz und Datenresidenz vor der Kostenoptimierung klären.
  • Einen Fallback-Pfad für lokale und für Cloud-Ausfälle festlegen.
  • Routing pro Aufgabe regelmäßig prüfen, statt einen Ort dauerhaft festzuschreiben.

Diese Strukturanalyse stützt sich auf offizielle Unterlagen und Primärforschung. Sie ersetzt weder den Geschwindigkeitstest eines konkreten Modells noch die Kostenrechnung einer Organisation. Vor einer Entscheidung sollte ein kurzer Vergleich mit denselben Prompts, demselben Qualitätsziel und derselben Last lokal und per API durchgeführt werden.

Quellen und Berichte

Öffentliche Quellen, die wir für Fakten, offizielle Dokumentation, politischen Hintergrund, Produktinformationen und veränderliche Angaben geprüft haben.