Ausgabe vom 4. September 2026

Nvidia hat am Mittwoch bestätigt, was seit Ende August als Bericht durch die Branche lief: Das Unternehmen übernimmt Hugging Face für 12,93 Milliarden Dollar. Als wir am 28. August darüber geschrieben haben, war der ganze Artikel eine Übung darin, Beleg von Behauptung zu trennen — die Übernahme galt damals ausdrücklich nicht als beschlossen. Diese Trennung ist jetzt hinfällig: Beide Seiten haben unterschrieben, der Abschluss wird für das kommende Jahr erwartet, vorbehaltlich der Kartellbehörden.

Wer die Größenordnung des Übernahmeziels einordnen will, sollte nicht auf den Umsatz schauen. Hugging Face beherbergt nach Nvidias eigenen Angaben drei Millionen Modelle, eine Million Anwendungen und 500.000 Datensätze und wird von über 18 Millionen Entwicklerinnen und Entwicklern genutzt. Der Umsatz liegt Berichten zufolge bei rund 150 Millionen Dollar im Jahr, mit Profitabilität in Sichtweite; insgesamt hatte das 2016 gegründete Unternehmen zuvor gut 395 Millionen Dollar eingesammelt, darunter 235 Millionen in der Serie D von 2023. Der Kaufpreis entspricht damit etwa dem 86-Fachen des Jahresumsatzes. Bezahlt wird hier offenkundig nicht für eine Gewinn- und Verlustrechnung, sondern für eine Position.

Die aufschlussreichste Einzelheit ist eine ältere: Hugging Face hat vor einem Jahr ein Angebot von Nvidia über 500 Millionen Dollar abgelehnt. Der jetzt gezahlte Preis liegt beim Sechsundzwanzigfachen davon. Was sich in zwölf Monaten so verändert hat, ist nicht die Technik des Unternehmens, sondern die Einsicht, wie viel eine neutrale Verteilstelle wert ist, wenn die gesamte Branche ihre Modelle über sie bezieht.

Beide Seiten haben die erwartbaren Zusagen gemacht. Nvidia-Chef Jensen Huang erklärte, Hugging Face werde „eine offene Plattform für das gesamte KI-Ökosystem bleiben“; Entwickler behielten die Freiheit, Modelle, Frameworks und Auslieferungswege zu wählen, ohne Nvidia-Rechenleistung nutzen zu müssen. Hugging-Face-Chef Clem Delangue begründete den Verkauf damit, die Plattform habe „mehr Rechenleistung, mehr Unterstützung, mehr Zusammenarbeit und mehr Sichtbarkeit“ gebraucht. Zur Untermauerung der eigenen Ökosystem-Glaubwürdigkeit verweist Nvidia darauf, selbst über 500 Modelle und 250 offene Datensätze auf die Plattform gestellt zu haben.

Die Zusage der Offenheit ist ehrlich gemeint oder auch nicht — entscheidend ist, dass sie strukturell nicht das Problem trifft, das Kritiker benennen. Das britische IT-Magazin The Register überschrieb seinen Kommentar mit dem Satz, Hugging Face sei „zu wichtig, um in Nvidias Hände zu fallen“. Das Argument dahinter dreht sich nicht um Zensur, sondern um Voreinstellungen: Wer die größte Verteilstelle für offene Modelle besitzt, sieht als Erster, welche Modelle an Fahrt gewinnen, und bestimmt, welche Auslieferungswege in der Dokumentation zuerst genannt werden. Ein Chiphersteller bekäme damit Einfluss darauf, auf welche Modelle sich der Rest der Branche standardisiert.

Genau hier wird die kartellrechtliche Prüfung ansetzen, und Nvidia hat mit solchen Verfahren Erfahrung. Der Versuch, den Chipentwickler Arm für 40 Milliarden Dollar zu kaufen, scheiterte 2022 am gemeinsamen Widerstand der US-Handelsbehörde FTC, der britischen Wettbewerbsbehörde CMA, der EU-Kommission und Chinas — im Kern an der Frage der Plattformneutralität, also daran, ob ein Marktteilnehmer eine von allen genutzte neutrale Schicht besitzen darf. Die Parallele liegt so nahe, dass Nvidia ihr vorbeugend begegnet: Ein Vizepräsident des Konzerns bezeichnet die Übernahme als Deconcentration Platform, als entkonzentrierende Plattform, und äußert die Erwartung, die Behörden würden den Schritt als überwiegend positiv bewerten. Ob Regulierer in London und Peking das ähnlich sehen, wenn ein US-Konzern die Verteilstelle übernimmt, über die auch die meisten ausländischen Forschungslabore ihre Modelle beziehen, ist offen.

Für Unternehmen, die offene Modelle produktiv einsetzen, ändert sich vorerst nichts — der Abschluss steht aus, und die Genehmigungen sind nicht vergeben. Die praktische Frage stellt sich trotzdem jetzt, weil sie sich nicht in einer Woche beantworten lässt: Über wie viele Stellen im eigenen Auslieferungsprozess läuft eine Adresse, die auf huggingface.co endet, und was passiert an diesen Stellen, wenn sich Voreinstellungen, Nutzungsbedingungen oder Preise ändern? Wir haben diese Frage in unserer Reportage vom 28. August unter dem Titel „Die Registry-Frage“ ausführlich behandelt. Sie war damals hypothetisch. Seit Mittwoch ist sie es nicht mehr.

Zwischen 10:30 und 11:00 Uhr Ortszeit New York lief am Donnerstag bei Downdetector eine Meldungswelle auf, wie sie in dieser Gleichzeitigkeit selten ist: über 35.000 Störungsmeldungen für ChatGPT, rund 1.400 für Claude und etwa 1.200 für Grok. Drei Produkte dreier konkurrierender Unternehmen — OpenAI, Anthropic und Elon Musks xAI — waren im selben Zeitfenster nicht oder nur eingeschränkt erreichbar.

Die Einzelheiten, soweit die Anbieter sie veröffentlicht haben, ergeben ein uneinheitliches Bild. OpenAIs Statusseite meldete „erhöhte Fehlerraten über ChatGPT und Codex hinweg“; als Ursache nannte das Unternehmen später einen Routing-Fehler ab etwa 7:43 Uhr pazifischer Zeit, durch den ChatGPT und das Codex-Werkzeug für einen Teil der Nutzer über alle Plattformen hinweg nicht verfügbar waren. Anthropic teilte mit, die Modelle Opus 4.8 und Opus 5 seien weiterhin gestört, während die übrigen Claude-Modelle bereits wieder auf normale Fehlerraten zurückgekehrt seien. xAI bestätigte lediglich, an dem Problem zu arbeiten. Alle drei Dienste waren im Lauf des Tages wieder erreichbar.

Der offensichtliche gemeinsame Nenner ist Microsoft Azure, das zur selben Zeit eigene Störungen meldete und für alle drei genannten Modellfamilien Cloud-Dienste bereitstellt. Mehrere Fachmedien haben daraus die Vermutung abgeleitet, Microsofts Problem könnte die Ausfälle mitverursacht haben. Belegt ist dieser Zusammenhang nicht. Keines der vier beteiligten Unternehmen hat eine gemeinsame Ursache bestätigt, und OpenAIs eigene Erklärung — ein Routing-Fehler im eigenen Haus — erklärt die gleichzeitigen Störungen bei Claude und Grok gerade nicht. Es bleibt möglich, dass drei unabhängige Fehler zufällig zusammenfielen. Wahrscheinlich ist es nicht, aber ausgeschlossen ebenso wenig.

Und genau diese Unsicherheit ist der eigentliche Befund. Wenn nach einem Ausfall dieser Sichtbarkeit auch am Folgetag niemand sagen kann, ob drei Anbieter unabhängig voneinander oder aus einem gemeinsamen Grund ausgefallen sind, dann kann auch kein Kunde beurteilen, ob seine Ausweichstrategie funktioniert hätte. Ein Unternehmen, das aus Vorsicht von OpenAI auf Anthropic umschaltet, hat für den Fall vorgesorgt, dass ein Anbieter Probleme hat. Es hat nicht für den Fall vorgesorgt, dass beide auf derselben Infrastruktur liegen — und ohne bestätigte Ursachenanalyse weiß es nicht, in welchem der beiden Fälle es sich gerade befand.

Ein Blick auf die vertraglichen Zusagen zeigt, wie wenig davon durch Verfügbarkeitsversprechen aufgefangen wird. OpenAIs Scale Tier nennt 99,9 Prozent Verfügbarkeit, Enterprise-Rahmenverträge liegen je nach Vereinbarung zwischen 99,9 und 99,99 Prozent. Der Azure OpenAI Service erbt das Azure-Verfügbarkeitsversprechen von 99,9 Prozent im Monat, mit den üblichen Gutschriftstufen: 10 Prozent Gutschrift unterhalb von 99,9 Prozent, 25 Prozent unterhalb von 99 Prozent, 100 Prozent unterhalb von 95 Prozent. Latenz, Ausfälle der Inhaltsfilter und Änderungen am Tokenizer fallen ausdrücklich nicht unter diesen Gutschriftrahmen. Die gemessene Wirklichkeit liegt darunter: Für claude.ai wurde über einen jüngeren Dreißigtagezeitraum eine Verfügbarkeit von 99,32 Prozent ermittelt — knapp fünf Stunden Ausfall im Monat.

Wer aus 99,9 Prozent eine Zahl macht, mit der sich planen lässt, muss zwei Dinge auseinanderhalten. Erstens ist eine Gutschrift von zehn Prozent auf die Monatsrechnung kein Ersatz für den Schaden eines dreistündigen Ausfalls in einem Prozess, der ohne das Modell stillsteht — sie ist eine Rückerstattung für nicht erbrachte Leistung, keine Haftung für Folgeschäden. Zweitens gilt die Zusage je Anbieter. Zwei Anbieter mit je 99,9 Prozent ergeben nur dann eine höhere gemeinsame Verfügbarkeit, wenn ihre Ausfälle unabhängig voneinander sind. Genau diese Unabhängigkeit hat der Donnerstag in Frage gestellt.

Für die Praxis folgt daraus weniger ein Alarm als eine Hausaufgabe. Die belastbare Frage lautet nicht „welchen Anbieter nehmen wir“, sondern: An welchen Stellen unseres Produkts steht der Betrieb still, wenn ein Modell 90 Minuten lang nicht antwortet — und was tut das System in diesen 90 Minuten? Für die meisten Anwendungen ist die richtige Antwort nicht ein zweiter Anbieter, sondern ein definierter eingeschränkter Betrieb: eine Warteschlange statt einer Fehlermeldung, ein kleineres Modell statt gar keines, ein sichtbarer Hinweis statt eines hängenden Ladebalkens. Wie sich das rechnet und was es tatsächlich kostet, behandeln wir in der Reportage dieser Ausgabe.

Der Begriff Abliteration — ein Kunstwort aus ablation, dem Wegschneiden, und obliteration, dem Auslöschen — bezeichnet ein Verfahren, das in der Forschung zu offenen Modellen seit Jahren praktiziert wird. Die Idee dahinter ist bemerkenswert schlicht: Die Weigerung eines Sprachmodells, eine Anfrage zu beantworten, ist im Modell nicht als Regelwerk hinterlegt, sondern als eine Richtung im internen Zahlenraum. Wer diese Richtung identifiziert und aus den Gewichten herausrechnet, erhält ein Modell, das seine Fähigkeiten behält, aber die Weigerung verlernt hat. Ein Nachtraining ist dafür nicht nötig, und die Rechenkosten sind gering.

Neu ist nicht die Technik, sondern dass jemand ein Unternehmen darum herum baut. Abliteration.AI hostet solche Modelle und macht sie über den Browser oder eine Programmierschnittstelle zugänglich — unter den bearbeiteten Modellen ist GLM-5.3 von Z.ai, daneben weitere offen gewichtete Modelle, denen die Schutzmechanismen entfernt wurden. Ein kostenloses Konto genügt für den Einstieg, darüber hinaus gibt es kostenpflichtige Angebote. Gegründet wurde die Firma von einem Entwickler, der gegenüber TechCrunch nur mit dem Vornamen Devon auftritt; seinen Nachnamen ließ er auf eigenen Wunsch weg, weil er zum Zeitpunkt des Berichts noch anderweitig angestellt war.

Die Begründung des Unternehmens ist das klassische Argument der offensiven Sicherheitsforschung: Verteidiger müssten über dieselben Werkzeuge verfügen wie Angreifer, sonst prüften sie ihre Systeme gegen einen Gegner, den es so nicht gibt. Diese Logik ist nicht neu und in der Branche weithin akzeptiert — Penetrationstests, Red-Team-Übungen und die gesamte Werkzeuglandschaft der Angriffssimulation beruhen darauf. Zur Kundschaft zählen nach Unternehmensangaben Red-Teaming-Startups in Großbritannien und Europa, darunter Firmen, die Banken und Betreiber kritischer Infrastruktur bei der Absicherung unterstützen. Finanziert wird das Ganze bislang aus Kundenumsätzen; Risikokapital hat die Firma nicht aufgenommen, führt darüber aber Gespräche. Zudem bestehen nach eigener Aussage Vereinbarungen mit mehreren größeren Cloud-Anbietern.

Der Einwand setzt nicht am Argument an, sondern an dessen Umsetzung. Andrew Yoon von der Organisation CivAI formulierte gegenüber TechCrunch, mit dieser Technik lasse sich „das Modell so verändern, dass es zum Soziopathen wird“ — es befolge anschließend „buchstäblich alles“. Kritiker erwarten Missbrauch im Bereich Cyberangriffe und biologischer Waffen. Entscheidend ist dabei weniger die Frage, ob abliterierte Modelle existieren — sie existieren seit Jahren und lassen sich von jedem mit ausreichender Hardware selbst herstellen —, sondern wie niedrig die Hürde wird, wenn sie fertig gehostet über einen Browser erreichbar sind. Genau das ist der Unterschied zwischen einer Forschungstechnik und einem Produkt.

An dieser Stelle wird die Schwachstelle des Angebots konkret. Abliteration.AI verfügt nach eigenen Angaben über keine Verfahren zur Identitätsprüfung, die über das Protokollieren der Kreditkarte hinausgehen; entsprechende Regeln würden noch erarbeitet. Ein Anbieter, der sein Geschäft ausdrücklich damit begründet, professionellen Verteidigern Werkzeuge zu geben, unterscheidet damit derzeit nicht zwischen einer Sicherheitsfirma und jedem anderen, der eine funktionierende Karte besitzt. Die Kontrolle, auf der die Rechtfertigung des Angebots ruht, ist die eine Komponente, die noch fehlt.

Der Zeitpunkt macht die Meldung interessanter, als sie für sich genommen wäre. Am selben Tag hat OpenAI GPT-6 Astra vorgestellt und dabei erstmals ein Modell in der eigenen Regelwerkstufe kritisch für Cyberfähigkeiten eingeordnet — mit gestaffelter Freigabe, Zugangsprogramm und abgeschaltetem Enterprise-Zugang als Ergebnis eines aufwendigen Abwägungsprozesses. Am selben Tag wird bekannt, dass ein Startup ein offen gewichtetes Modell mit entfernten Schutzmechanismen gegen Kreditkarte anbietet. Beide Vorgänge betreffen dieselbe Fähigkeit, und die Steuerungswirkung des einen hängt daran, wie leicht der andere Weg ist.

Für Unternehmen, die keine Sicherheitsforschung betreiben, ist die praktische Konsequenz weniger eine Frage der Beschaffung als der Bedrohungsmodellierung. Wer die Schutzmechanismen kommerzieller Modelle bislang implizit als Teil seiner Verteidigungslinie mitgedacht hat — etwa in der Annahme, ein Angreifer bekomme von einem Sprachmodell keine brauchbare Hilfe beim Ausnutzen einer Lücke —, sollte diese Annahme streichen. Sie war schon vorher fragil, weil sich offene Modelle selbst bearbeiten lassen. Seit dieser Woche ist sie es sichtbar.

Meta hat am Mittwoch Muse Spark 1.3 veröffentlicht, und die Werte sind bemerkenswert genug, um sie in Ruhe anzusehen. Im Artificial Analysis Intelligence Index — dem Sammelwert, an dem die Branche derzeit Modelle vergleicht — erreicht die Stufe xhigh 61 Punkte und liegt damit gleichauf mit GPT-5.6 Sol in der Einstellung max. Eine neue Stufe max kommt auf 62 Punkte und wird nur noch von Claude Fable 5.1 max (66) und Claude Opus 5 max (63) übertroffen. Meta selbst hebt „deutliche Verbesserungen bei agentischer Wissensarbeit“ und bei naturwissenschaftlichem Schlussfolgern hervor.

Interessant wird das im Verhältnis zum Preis. Die regulären Sätze bleiben unverändert bei 1,25 Dollar je Million Eingabe-Token und 4,25 Dollar je Million Ausgabe-Token. Zur Einordnung: Das im ersten Artikel dieser Ausgabe beschriebene GPT-6 Astra kostet 10 und 50 Dollar. Für einen Punkt Unterschied im selben Index — 62 gegen 61,2 zugunsten von Muse Spark, wohlgemerkt — verlangt OpenAI beim Ausgabe-Token etwa das Zwölffache. Das ist die Sorte Zahl, die eine Beschaffungsentscheidung eher entscheidet als jede Benchmarktabelle.

Die eigentliche Neuerung steht aber weiter unten im Preisblatt, und sie verdient mehr Aufmerksamkeit, als sie in der Berichterstattung bekommen hat. Meta führt eine Tarifstufe namens Contributor ein: 0,10 Dollar Eingabe, 0,20 Dollar Ausgabe — also etwa ein Zwölftel beziehungsweise ein Zwanzigstel des Normalpreises. Die Gegenleistung ist ausdrücklich benannt: Meta darf die Prompts zum Training eigener Modelle verwenden. Nach Angaben des KI-Chefs des Konzerns nutzt bereits „ein zweistelliger Prozentsatz der Programmierer“ diese Stufe.

Damit ist eine Praxis, die bislang im Kleingedruckten kostenloser Angebote stand, erstmals offen als Preisbestandteil ausgewiesen. Man kann das als bemerkenswerte Ehrlichkeit lesen — der Handel wird benannt statt versteckt —, und dieses Lob ist verdient. Für Unternehmen entsteht daraus trotzdem eine Aufgabe, die nicht die Beschaffung allein lösen kann. Ein Preisunterschied vom Zwölffachen erzeugt erheblichen Druck, und die Entscheidung fällt selten in der Rechtsabteilung: Sie fällt, wenn eine Entwicklerin einen API-Schlüssel anlegt. Wer Muse Spark einsetzt, sollte die Frage, welche Tarifstufe für welche Art von Inhalt zulässig ist, deshalb ausdrücklich beantworten, bevor sie sich implizit beantwortet. Prompts aus einem Kundenprojekt sind Kundendaten, und ein zweistelliger Prozentsatz nutzender Programmierer legt nahe, dass diese Abwägung vielerorts bereits stattgefunden hat — nur eben nicht schriftlich.

Zu den technischen Rahmendaten: Das Kontextfenster bleibt bei einer Million Token, verarbeitet werden Text, Bild und Video. Zunächst ist das Modell bis zur Denkstufe xhigh verfügbar; die Stufe max soll folgen. Der Zugang läuft über den Agenten Muse Code für macOS und Linux — Metas Einstieg in den Markt für Coding-Agenten, über den wir am 6. August berichtet haben — oder über die Meta Model API. Eine Veröffentlichung der Gewichte ist erneut zugesagt, wie schon bei den Vorgängerversionen, wieder ohne Zeitplan. Diese Zusage hat inzwischen eine Vorgeschichte, und wer darauf plant, sollte sie als Absichtserklärung behandeln, nicht als Termin.

Der Zeitpunkt der Veröffentlichung ist kein Zufall. Muse Spark 1.3 kam praktisch zeitgleich mit Anthropics Claude Fable 5.1 und Googles Gemini 3.8 Flash — und einen Tag vor GPT-6 Astra. Innerhalb einer Woche haben damit vier Anbieter neue Modelle in denselben Preis- und Leistungskorridor geschoben. Für Kunden ist das die günstigste Marktlage seit Langem; für die Anbieter ist es eine Situation, in der sich Leistungsunterschiede von einem Indexpunkt kaum noch in Preisaufschläge übersetzen lassen. Metas Antwort darauf — Leistung nahe der Spitze zu einem Bruchteil des Preises, und eine noch billigere Stufe gegen Daten — ist die aggressivste Positionierung in diesem Feld.

Nvidia hat am Mittwoch den Personal AI Router, kurz PAIR, als quelloffene Beta für Windows, macOS und Linux veröffentlicht. Der Zweck lässt sich in einem Satz beschreiben: Er verteilt die Anfragen eines KI-Agenten auf alle geeigneten Geräte im lokalen Netz, statt sie alle auf demselben Rechner abarbeiten zu lassen.

Das Problem, auf das PAIR antwortet, entsteht durch die Bauweise heutiger Agenten. Ein führender Agent zerlegt eine Aufgabe in Teilaufgaben und übergibt sie an spezialisierte Unteragenten — und wenn fünf davon gleichzeitig arbeiten, erzeugen sie fünf gleichzeitige Anfragen an ein Modell. Auf einem einzelnen Rechner werden diese nacheinander abgearbeitet, und die Parallelität, die den Entwurf attraktiv macht, verpufft. Wer daneben noch einen älteren Spielerechner und ein Notebook stehen hat, besitzt Rechenleistung, die währenddessen nichts tut.

Technisch ist PAIR eine Zwischenschicht, kein Cluster-System — diese Unterscheidung ist wichtig. Die Software findet Geräte im Netz über mDNS, koppelt sie über mTLS-verschlüsselte Verbindungen und fängt anschließend Anfragen ab, die eigentlich an Ollama oder LM Studio gerichtet sind. Jede Anfrage wird auf Basis von Verfügbarkeit der Ausführungsumgebung, vorhandenem Modell und aktueller GPU-Auslastung an einen geeigneten Knoten geleitet und über dieselbe Schnittstelle zurückgegeben; für die aufrufende Anwendung ändert sich nichts. Ausdrücklich nicht geschieht dabei zweierlei: Grafikkarten werden nicht zu einem gemeinsamen Speicher verschmolzen, und einzelne Anfragen werden nicht auf mehrere Geräte aufgeteilt. Jeder Auftrag läuft vollständig auf einem Knoten. Ein Modell, das auf keinem einzelnen Gerät in den Speicher passt, wird durch PAIR also nicht lauffähig — der Nutzen liegt allein im Durchsatz bei vielen gleichzeitigen Anfragen.

Unterstützt werden GeForce-RTX-Karten ab der 20er-Serie, RTX-PRO-Arbeitsplatzkarten ab der Turing-Architektur, Nvidias DGX Spark sowie Apple-Silicon ab M4 — dass ein Nvidia-Werkzeug Apple-Hardware als gleichberechtigten Knoten einbindet, ist die vielleicht überraschendste Zeile der Ankündigung. Der Quelltext liegt auf GitHub unter NVIDIA/Personal-AI-Router.

Zu den Leistungsangaben ist Zurückhaltung geboten. Nvidia nennt ein Beispiel mit fünf Unteragenten, bei dem ein Verbund aus drei Geräten die Aufgabe in 8 Minuten 48 Sekunden erledigte, während ein einzelnes RTX-Spark-Notebook 18 Minuten brauchte. Das ist eine Halbierung — aber es ist eine Herstellermessung mit einer Arbeitslast, die der Hersteller ausgewählt hat, und Nvidia schreibt selbst dazu, die Ergebnisse hingen erheblich von der Parallelisierbarkeit der Arbeitslast und der Konfiguration ab. Bei einer Aufgabe, die nur eine Anfrage nach der anderen stellt, ist der Gewinn null.

Die Ankündigung fällt zusammen mit dem Hardwareteil derselben Strategie. Auf der IFA in Berlin zeigten Nvidia und seine Partner die ersten Notebooks und Mini-PCs mit dem RTX-Spark-Chip, die im Oktober weltweit in den Handel kommen sollen. Es gibt zwei Ausbaustufen: Der RTX Spark 675 bietet 20 CPU-Kerne und 6.144 Shader-Kerne und erscheint in Notebooks wie in Mini-PCs mit 24 bis 128 GB Speicher; der kleinere RTX Spark 650 mit 18 Kernen und 5.120 Shader-Kernen bleibt Notebooks mit 24 oder 32 GB vorbehalten. Nvidia nennt bis zu ein Petaflop lokale KI-Rechenleistung. Entscheidend für lokale Inferenz ist aber der gemeinsame Speicher, weil er bestimmt, welche Modellgrößen überhaupt hineinpassen — und da trennt sich die Produktlinie deutlich. Asus zeigte die Kreativnotebooks ProArt P16 und P14 sowie den Mini-PC ProArt GR1X, Lenovo das Yoga Pro 9n und ein Yoga 9n als 2-in-1, Acer steigt mit einem Mini-PC ein; Geräte von Microsoft, HP und Dell sind angekündigt.

Offizielle Preise hat bislang niemand genannt. heise schätzt angesichts der derzeit hohen Speicherpreise mindestens 2.500 Euro für Einstiegsmodelle und über 3.000 Euro für größere Konfigurationen; Nvidias DGX Spark mit 128 GB kostet zum Vergleich 4.800 Euro. Solange die Hersteller nicht liefern, bleibt das eine Schätzung — aber sie markiert die Größenordnung, gegen die man die Cloudrechnung stellen muss.

Für Unternehmen, die über lokale Inferenz nachdenken, verschiebt die Kombination aus beidem eine Rechnung, die bisher recht eindeutig ausfiel. Die übliche Kalkulation vergleicht die Anschaffung eines leistungsfähigen Einzelgeräts mit laufenden Cloudkosten. PAIR fügt eine dritte Möglichkeit hinzu: vorhandene, bereits abgeschriebene Geräte zusammenzuschalten, statt neu zu beschaffen. Ob sich das lohnt, hängt an der Frage, ob die eigenen Arbeitslasten tatsächlich viele gleichzeitige, jeweils kleine Anfragen erzeugen — bei Agenten mit Unteragenten ist das häufig der Fall, bei einem Chatfenster für einzelne Mitarbeitende nicht.

Google DeepMind hat am Mittwoch WeatherNext 3 vorgestellt, die neue Version seines globalen Wettermodells. Die Zahlen sind eindrucksvoll, und weil Wettervorhersage eines der wenigen Felder ist, in denen sich die Güte eines KI-Modells nachträglich objektiv überprüfen lässt — es regnet oder es regnet nicht —, verdienen sie eine genauere Betrachtung als übliche Benchmarkwerte.

Die Auflösung steigt deutlich. Oberflächennahe Größen wie Temperatur und Feuchte berechnet das Modell auf fünf Kilometer genau, weitere Oberflächengrößen auf zehn, atmosphärische Größen wie Windgeschwindigkeit auf 25 Kilometer. Vor allem aber liefert WeatherNext 3 stündlich neue Vorhersagen, wo der Vorgänger in Sechs-Stunden-Schritten arbeitete. Google beschreibt das Ergebnis insgesamt als „rund fünfmal schärfer“ als das Vorgängermodell, das durchgängig auf 25 Kilometern operierte.

Die größten Fortschritte meldet DeepMind beim Niederschlag — jener Größe, die Vorhersagemodelle traditionell am schlechtesten beherrschen, weil Regen kleinräumig und sprunghaft auftritt. Gegen die Satellitendaten des NASA-Datensatzes IMERG gemessen verbessert sich der Continuous Ranked Probability Score, ein Standardmaß für die Güte von Wahrscheinlichkeitsvorhersagen, um bis zu 60 Prozent; gegen die Referenz MRMS um 30 Prozent, gegen Regenmessungen am Boden bei kurzen Vorlaufzeiten um 10 Prozent. Für die Tagesplanung nennt Google „bis zu 50 Prozent genauere Niederschlagsvorhersagen“, mit besonderem Gewinn in Regionen, die bislang schlecht abgedeckt waren.

Bei diesen Zahlen lohnt ein Hinweis zur Lesart. „Bis zu 60 Prozent“ ist der günstigste Wert aus einem Vergleich gegen eine bestimmte Referenz; gegen die Bodenmessungen — der strengste der drei genannten Maßstäbe — bleiben 10 Prozent übrig. Das ist immer noch ein realer Fortschritt, aber es ist ein anderer Fortschritt als der, den die Überschrift nahelegt. Bemerkenswert ist zudem, dass das Modell Satellitendaten in Echtzeit einbezieht, statt ausschließlich auf Ergebnissen physikalischer Simulationen trainiert zu werden — genau darin liegt vermutlich ein Teil des Sprungs bei kurzen Vorlaufzeiten.

Der Weg in die Praxis ist diesmal kurz. Über BigQuery, Earth Engine und Google Cloud Storage ist das Modell für Fachanwender zugänglich; parallel fließen die Vorhersagen in die Google-Suche, die Gemini-App, Google Maps und die Weather API der Maps-Plattform ein. Für Energieunternehmen gibt es eigene Größen: Windgeschwindigkeit auf 100 Metern Höhe, Bewölkung und Sonneneinstrahlung — die Eingangsdaten für die Ertragsprognose von Wind- und Solarparks, wo ein halber Tag zusätzlicher Vorlauf unmittelbar in Handelsentscheidungen übersetzt wird.

Eine Zusage fehlt allerdings, und ihr Fehlen ist die eigentliche Nachricht für alle, die auf diesen Modellen aufbauen. Als wir am 7. August über WeatherNext Cyclones berichtet haben, war die ungewöhnliche Veröffentlichungspolitik ein zentraler Punkt: Code und Modellgewichte für WeatherNext Cyclones sowie WeatherNext 2 lagen offen, die kleine Variante lief kostenlos in einem Colab-Notebook auf einer einzelnen TPU. In der Ankündigung zu WeatherNext 3 findet sich keine Angabe zu offenen Gewichten. Das ist keine Absage — Google hat sich schlicht nicht geäußert, und es wäre voreilig, daraus einen Kurswechsel abzuleiten. Aber es ist eine Auslassung an genau der Stelle, an der die Vorgängerankündigung besonders deutlich war, und wer für die eigene Anwendung ein selbst betreibbares Wettermodell eingeplant hat, sollte diese Frage klären, bevor er WeatherNext 3 fest einplant.

Unabhängig davon steht hinter der Meldung ein größerer Vorgang. Die numerische Wettervorhersage war jahrzehntelang die Domäne physikalischer Simulationen auf Supercomputern der nationalen Wetterdienste — ein Feld mit hohen Zugangshürden und langsamen Zyklen. Dass ein gelerntes Modell dort inzwischen in mehreren Kategorien vorn liegt und seine Ergebnisse nebenbei in eine Kartenanwendung für Endverbraucher schiebt, ist die eigentlich bemerkenswerte Entwicklung. Für Unternehmen, deren Geschäft vom Wetter abhängt — Logistik, Landwirtschaft, Energie, Bau, Versicherung —, verschiebt sich damit, was eine Wettervorhersage als Eingangsgröße für eigene Systeme leisten kann.

Im Regierungsentwurf zum Einkommensteuerreformgesetz 2027 steckt eine Änderung des Gewerbesteuerrechts, die in der Berichterstattung über das Gesetz weitgehend unterging, für den Rechenzentrumsbau in Deutschland aber erhebliche Folgen haben dürfte. Sie betrifft die sogenannte Zerlegung — die Frage, wie die Gewerbesteuer eines Unternehmens mit mehreren Standorten auf die beteiligten Gemeinden aufgeteilt wird.

Bislang gilt dafür ein einziger Maßstab: die Arbeitslöhne an den jeweiligen Standorten. Diese Regel stammt aus einer Zeit, in der ein Betrieb dort Kosten und Nutzen verursachte, wo Menschen arbeiteten, und für die meisten Branchen funktioniert sie weiterhin gut. Für Rechenzentren funktioniert sie gar nicht. Eine große Anlage beschäftigt im laufenden Betrieb oft nur einige Dutzend Menschen, während sie Fläche, Netzanschluss, Straßen und Wasser der Standortgemeinde beansprucht. Das Ergebnis ist eine Gemeinde, die sämtliche Lasten trägt und aus der Gewerbesteuer praktisch nichts sieht, weil die Lohnsumme am Verwaltungssitz des Betreibers anfällt.

Der Entwurf dreht diesen Maßstab für die Branche um. Der Arbeitslohn soll künftig nur noch zu einem Zehntel über die Verteilung entscheiden. Maßgeblich für die übrigen neun Zehntel wird die elektrische Nennanschlussleistung der Rechenzentren — vereinfacht gesagt: Wo der Strom fließt, bleiben künftig rund 90 Prozent des Steueraufkommens. Gelten soll die Regelung ab dem Erhebungszeitraum 2027. Für die Betreiber entsteht dabei kein zusätzlicher Verwaltungsaufwand, weil die Anschlussleistung ohnehin dokumentiert ist — es ändert sich die Verteilung, nicht die Steuerlast.

Das politische Ziel wird ungewöhnlich offen benannt: Die Reform soll möglichen Protesten frühzeitig entgegenwirken. Der gedankliche Hintergrund sind die Bürgerinitiativen in den USA, die dort inzwischen eine ganze Reihe von Rechenzentrumsprojekten aufgehalten haben — meist mit Argumenten zu Stromverbrauch, Wasserverbrauch, Lärm und Flächenversiegelung. Die Bundesregierung setzt darauf, dass Bürgermeisterinnen und Gemeinderäte einer Ansiedlung anders gegenüberstehen, wenn dauerhafte Einnahmen im eigenen Haushalt daran hängen.

Nüchtern betrachtet ist das ein rationaler Eingriff, denn er korrigiert eine echte Fehlzuordnung: Wer die Lasten trägt, sollte auch die Einnahmen bekommen. Bemerkenswert ist eher die Begründung. Ein Steuerinstrument wird hier ausdrücklich nicht mit Steuergerechtigkeit begründet, sondern mit seiner Wirkung auf die kommunale Zustimmungsbereitschaft. Die Einwände der Bürgerinitiativen — Stromverbrauch, Wasser, Fläche — werden dadurch nicht adressiert, sondern der Gemeinde wird ein Gegenposten in die andere Waagschale gelegt. Ob das die Konflikte auflöst oder nur verlagert, wird sich an den ersten Verfahren nach 2027 zeigen.

Für Betreiber und ihre Standortplanung entsteht daraus eine neue Variable. Bisher war der Hebesatz der Gemeinde für die Standortwahl eines Rechenzentrums nahezu irrelevant, weil dort ohnehin kaum Steuer anfiel. Künftig fällt dort der Großteil an — und damit wird der kommunale Hebesatz zu einem echten Kostenfaktor, der zwischen Standorten mit ähnlichem Netzanschluss den Ausschlag geben kann. Zugleich entsteht für Gemeinden mit freien Netzkapazitäten ein Anreiz, aktiv um Ansiedlungen zu werben.

Der Vorgang fügt sich in ein Muster, das wir in dieser Rubrik seit Monaten verfolgen. Wir haben am 3. September über die 474 Gigawatt in der texanischen Netz-Warteschlange geschrieben und über die Frage, wie viel dieser angemeldeten Nachfrage überhaupt existiert; am 28. August über 5,6 Milliarden Euro für 240 Megawatt bei Rostock. In allen drei Fällen ist die eigentliche Währung dieselbe, und es ist nicht die Rechenleistung: Es ist der Netzanschluss. Dass der deutsche Gesetzgeber nun ausgerechnet die Anschlussleistung zum Steuerverteilungsmaßstab macht, ist insofern die konsequente Übersetzung dieser Realität in Recht — die Regierung rechnet Rechenzentren nicht mehr nach Beschäftigten, sondern nach Megawatt.