DEV Community: Christian Ahrweiler

Dreizehn Tage Mining brachten mir 134 Sats. Warum ich trotzdem weitergebaut habe.

Christian Ahrweiler — Fri, 09 Oct 2026 19:40:31 +0000

Bitcoin-MiningEin kleines Set an Mac-Tools für Menschen, die Bitcoin-Mining so sehen wollen, wie es wirklich ist — nicht wie es beworben wird.

Dreizehn Tage. 56.559 akzeptierte Shares. 134 Satoshis.

Zum heutigen Kurs entspricht das etwa zehn Cent. Es würde nicht einmal die Stromkosten für den USB-Stick decken, der diese Erträge erwirtschaftet hat — geschweige denn für den Mac, der daneben gehasht hat.

Ich weiß das, weil mir eine Menüleisten-App genau das alle fünf Minuten verrät: in Sats und in Euro. Ich habe diese App letzte Woche geschrieben. Sie ist das neueste Puzzlestück einer Sammlung, an der ich seit einem Jahr baue. In diesem Artikel fasse ich all das zum ersten Mal an einem Ort zusammen: btcminertools.com

Die Frage, die niemand ehrlich beantwortet haben möchte

„Kann ein Mac Bitcoin minen?“Die ehrliche Antwort hat zwei Seiten:

Ja: Ein Mac kann exakt denselben Doppel-SHA-256-Proof-of-Work ausführen wie eine gigantische Mining-Farm. Der Test ist für alle identisch: Liegt dieser Hash unter dem Zielwert (Target)?
Nein: Ein Mac wird nichts einbringen, was der Rede wert ist. Das globale Netzwerk führt diesen Test mit fast einem Zettahash pro Sekunde aus (eine Eins gefolgt von 21 Nullen) — und ein Mac steuert lediglich ein paar Millionen bei. Die meisten Mining-Apps verstecken die zweite Hälfte hinter rotierenden Zahlenrädern. Ich wollte Werkzeuge, die beide Hälften gleichzeitig transparent machen. Alles auf btcminertools.com ist aus diesem Gedanken entstanden.

Bitcoin Miner: Dem Wettlauf zusehen

Die erste App war Bitcoin Miner. Sie baut einen echten 80-Byte-Blockheader, verändert die Nonce, hasht zweimal und vergleicht das Ergebnis mit dem Live-Target des Netzwerks. CPU und Metal-GPU arbeiten dabei Seite an Seite; der Header, beide SHA-256-Stufen, die Nonce und das Target sind live sichtbar, während sie sich verändern.

Die App kann selbstständig der öffentlichen Chain-Spitze folgen oder sich mit deinem eigenen Bitcoin-Core-Node verbinden, um über getblocktemplate eine echte Blockvorlage zu minen. Sie kann auch über Stratum für einen Pool minen. Nichts davon macht einen gültigen Block wahrscheinlich – aber es macht den Prozess beobachtbar.

Ich habe in einem früheren Artikel über die Beweggründe hinter dieser App geschrieben. Die Kurzfassung: Mining hat keinen Fortschrittsbalken, und eine App, die etwas anderes vorgaukelt, vermittelt das falsche Verständnis.

Coordinator und Workers: Ein Pool, viele Maschinen

Wenn man einmal verstanden hat, was ein Hash-Versuch ist, lautet die nächste Frage: Wie macht man mehr davon?

Der Bitcoin Miner Coordinator verbindet sich mit einem Stratum-V1-Pool und verteilt die Arbeit an Worker: Macs im lokalen Netzwerk, Linux-Instanzen auf einem VPS oder Maschinen, die über ein privates WireGuard-Netzwerk eingebunden sind, damit kein Mining-Port öffentlich im Internet liegt. Der Coordinator selbst führt keine Hashes aus. Er zeigt die Live-Hashrate jedes Workers, die Arbeit der aktuellen Sitzung und das Mining-Profil in einem einzigen Fenster an.

Der Mac Worker lässt dich CPU-Kerne und GPU-Nutzung in vier Profilen wählen — von „meinen Mac nutzbar lassen“ bis hin zu „alles geben“. Der Linux Worker ist eine kompakte Binary für entfernte CPUs.

Und dann gibt es da noch das Tool, das die 134 Sats tatsächlich erwirtschaftet hat:

Gekko Worker: Ein USB-ASIC, lokal gesteuert

GekkoScience stellt kleine USB-ASIC-Sticks her. Einer davon erreicht in einem aktiven USB-Hub eine Hashrate von etwa zwei Terahashes pro Sekunde — viele tausend Male mehr als ein Mac — und verbraucht dabei nur wenige Watt.

Der Bitcoin Miner Gekko Worker steuert diese Sticks auf dem Mac über ein integriertes, GPL-lizenziertes CGMiner-Build an. Er empfängt die Arbeitsaufträge vom Coordinator, überwacht die Chiptemperatur und stoppt den Stick mit einem Alarm, bevor Hitze zum Problem wird. Der exakte CGMiner-Quellcode für das mitgelieferte Binary ist direkt in der App enthalten, wie es die Lizenz vorschreibt.

Zwei Terahashes sind im Vergleich zum Gesamtnetzwerk immer noch verschwindend gering. Aber es reicht aus, um echte Shares an einen echten Pool zu senden und eine echte — wenn auch winzige — Belohnung zu erhalten.

Was mich zurück zur Menüleiste bringt.

Balance: Die ehrliche Zahl, immer im Blick

Mining-Pools zeigen Verdienste gewöhnlich auf einem Web-Dashboard hinter einem Login an — in einem Browser-Tab, den man schnell wieder schließt.

Bitcoin Miner BalanceBitcoin Miner Balance bringt diese Zahl stattdessen direkt in die macOS-Menüleiste. Die App liest ein Braiins-Pool-Konto über ein schreibgeschütztes API-Token aus:

Aktuelles Guthaben & heutige Belohnung
Account-Hashrate der letzten Stunde
Jeder Worker inklusive aktuellem Status
Tägliche Historie (so weit zurück, wie der Pool sie speichert) Du kannst beliebig zwischen Sats und BTC wechseln; wählst du Euro oder Dollar, rechnet die App direkt zum aktuellen Bitcoin-Kurs um.

Es gibt kein Benutzerkonto bei mir und keinen Server dazwischen. Das Token verbleibt in deiner Schlüsselbundverwaltung (Keychain), wird mit dem Bitcoin Miner auf demselben Mac geteilt und ausschließlich an Braiins gesendet. Ein schreibgeschütztes Token kann Werte anzeigen, aber keine Beträge bewegen. Löschst du es, vergisst die App alles.

Balance ist kostenlos. Es ist die App, die ich am häufigsten öffne, weil sie das gesamte Experiment ehrlich hält: Das haben die Maschinen heute geleistet, das war es wert.

Lernwerkzeuge und ein Transaktions-Finder

Nicht jeder möchte minen. Manche Menschen wollen einfach verstehen, was durch Mining abgesichert wird.

Bitcoin Miner Education zeigt einen Blockkandidaten, SHA-256 und das Entstehen von Proof-of-Work — ganz ohne Wallet oder privaten Schlüssel.
Bitcoin Mempool Monitor, Bitcoin Block Monitor und Bitcoin Transaction Tree machen den Mempool, die Blockchain und den UTXO-Graphen anhand öffentlicher Daten sichtbar.
Bitcoin Address Monitor beobachtet öffentliche Adressen, die du benennst und gruppierst — rein schreibgeschützt und lokal auf deinem Mac. Und auf der Website selbst stellt der Transaction Finder eine Transaktion als Stammbaum dar: Inputs auf der linken Seite, Outputs auf der rechten Seite, bestätigt oder ausstehend in klaren Worten. Ohne Login, ohne Tracking, ohne Wallet-Verbindung.

Was heute auf der Website verfügbar ist

btcminertools.comDirekte Downloads, signiert und notarisierbar für macOS auf btcminertools.com:

Bitcoin Miner Worker & Bitcoin Miner Gekko Worker (inkl. Worker-Handbuch)
Bitcoin Miner Balance (kostenlos)
Der Linux Worker & eine WireGuard-Hub-Anleitung für private Netzwerke Der Coordinator, die Education-App und die Monitoring-Apps befinden sich auf dem Weg in den Mac App Store; die Website verlinkt auf die einzelnen Tools, sobald sie verfügbar sind.

Alles ist schreibgeschützt, wo es nur geht, lokal gehalten, wo es möglich ist — und überall ehrlich bzgl. der Erfolgschancen.

Warum für zehn Cent weiterbauen?

Weil die zehn Cent der eigentliche Punkt sind.

Die Sicherheit von Bitcoin entsteht durch eine enorme Anzahl von Teilnehmern, die alle gleichzeitig dieselbe Frage stellen. Ein Mac und ein USB-Stick in Düsseldorf sind in dieser Gesamtzahl nur ein Rundungsfehler. Aber sie sind ein realer, überprüfbarer Teil davon.

Ein Set von Werkzeugen, das den echten Header, die echten Shares und das echte Guthaben anzeigt, lehrt unendlich viel mehr als jede Animation von Münzen, die in eine virtuelle Wallet fallen.

134 Sats in dreizehn Tagen. Ich nehme sie gerne.

Mehr auf btcminertools.com

Thirteen Days of Mining Earned Me 134 Sats. Here Is Why I Kept Building.

Christian Ahrweiler — Thu, 08 Oct 2026 05:40:44 +0000

A small set of Mac tools for people who want to see Bitcoin mining as it is, not as it is advertisedThirteen days. 56,559 accepted shares. 134 satoshis.

At today’s price that is about ten cents. It would not cover the electricity for the USB stick that earned it, let alone the Mac that was hashing beside it.

I know this because a menu bar app tells me so, every five minutes, in sats and in euro. I wrote that app last week. It is the newest piece of a collection I have been building for a year, and this article is the first time I put all of it in one place: https://btcminertools.com/

The question nobody wants answered honestly“Can a Mac mine Bitcoin?”

Bitcoin MinerThe honest answer has two halves. Yes, a Mac can perform exactly the same double SHA-256 proof of work as a mining farm; the test is the same for everyone: is this hash below the target? And no, a Mac will not earn anything worth mentioning, because the global network performs that test close to a zettahash per second, a one followed by twenty-one zeros, and a Mac contributes a few million.

Most mining apps hide the second half behind spinning numbers. I wanted tools that show both halves at once. Everything on btcminertools.com grew out of that.

Bitcoin Miner: watch the raceThe first app was Bitcoin Miner. It builds a real 80-byte block header, changes the nonce, hashes twice and compares against the live network target. CPU and Metal GPU work side by side; the header, both SHA-256 stages, the nonce and the target are visible while they change.

It can follow the public chain tip on its own, or connect to your own Bitcoin Core node and mine a real block template through getblocktemplate. It can also mine for a pool over Stratum. None of this makes a block likely. It makes the process observable.

I wrote about the reasoning behind that app in an earlier article; the short version is that mining has no progress bar, and an app that pretends otherwise teaches the wrong thing.

Coordinator and Workers: one pool, many machinesWhen you understand what a hash attempt is, the next question is how to make more of them.

Bitcoin Miner Coordinator connects to a Stratum V1 pool and hands work to Workers: Macs on the local network, Linux boxes on a VPS, or machines reached through a private WireGuard network so that no mining port faces the public internet. The Coordinator itself does not hash. It shows every worker’s live hashrate, session work and mining profile in one window.

The Mac Worker lets you choose CPU cores and GPU use in four profiles, from “leave my Mac usable” to “everything”. The Linux Worker is a compact binary for remote CPUs.

And then there is the one that actually earned those 134 sats.

Gekko Worker: a USB ASIC, kept localGekkoScience makes small USB ASIC sticks. One of them, in a powered hub, hashes at around two terahashes per second, many thousand times what a Mac manages, while drawing a few watts.

Bitcoin Miner Gekko Worker drives those sticks on a Mac through a bundled, GPL-licensed CGMiner build. It receives work from the Coordinator, watches the chip temperature and halts the stick, with an alarm, before heat becomes a problem. The exact CGMiner source for the bundled binary ships inside the app, as the license asks.

Two terahashes is still nothing against the network. But it is enough to submit real shares to a real pool and receive a real, if tiny, reward. Which brings me back to the menu bar.

Balance: the honest number, always visiblePools show you your earnings on a web dashboard, behind a login, in a browser tab you close.

Bitcoin Miner Balance*Bitcoin Miner Balance* puts the number in the macOS menu bar instead. It reads a Braiins Pool account through a read-only API token: current balance, today’s reward, the account hashrate of the last hour, every worker and its state, and the daily history as far back as the pool keeps it. Switch between sats and BTC; pick euro or dollar and the app converts at the current Bitcoin price.

There is no account with me, no server of mine in between. The token lives in your Keychain, is shared with Bitcoin Miner on the same Mac, and is sent to Braiins only. A read-only token can show figures; it cannot move funds. Remove it and the app forgets everything.

Balance is free. It is the app I open most, because it keeps the whole exercise honest: here is what the machines did today, here is what it was worth.

Learning tools and a transaction finderNot everyone wants to mine. Some people want to understand the thing that mining secures.

Bitcoin Miner Education shows a block candidate, SHA-256 and proof of work taking shape without a wallet or a key. Bitcoin Mempool Monitor, Bitcoin Block Monitor and Bitcoin Transaction Tree make the mempool, the chain and the UTXO graph visible from public data. Bitcoin Address Monitor follows public addresses you name and group, read-only, local to your Mac.

And on the site itself, Transaction Finder draws one transaction as a tree: inputs on the left, outputs on the right, confirmed or pending in plain words. No login, no tracking, no wallet connection.

What is on the site todayhttps://btcminertools.com/Direct downloads, signed and notarized for macOS:

Bitcoin Miner Worker and Bitcoin Miner Gekko Worker, with the Worker manual
Bitcoin Miner Balance, free
The Linux Worker and a WireGuard hub guide for private networks The Coordinator, Education and the monitoring apps are on their way to the Mac App Store; the site links to each as it becomes available.

Everything is read-only where it can be, local where it can be, and honest about the odds everywhere.

Why keep building for ten centsBecause the ten cents is the point.

Bitcoin’s security comes from an enormous number of participants asking the same question at the same time. A Mac and a USB stick in Düsseldorf are a rounding error in that number. But they are a real, verifiable part of it, and a set of tools that shows the real header, the real shares and the real balance teaches more than any animation of coins falling into a wallet.

134 sats in thirteen days. I will take it.

*More on *https://btcminertools.com/

Quantencomputing verständlich erklärt — Episode 7

Christian Ahrweiler — Wed, 07 Oct 2026 08:44:13 +0000

Quantencomputing verständlich erklärt — Episode 7### Eine Million Einträge: Wo liegen die Daten?

In Episode 6 haben wir den Grover-Algorithmus mit vier Kundennummern betrachtet:

Position Kundennummer
00 5832
01 1947
10 4711
11 8264Zwei Qubits reichten aus, um die vier möglichen Positionen darzustellen. Die Vergleichsschaltung wirkte auf den gemeinsamen Zustand aller vier Positionen und markierte die Position, an der 4711 gespeichert war.

Für vier Einträge lässt sich dabei leicht übersehen, was bei einer wirklichen Datenbank zum entscheidenden Problem wird:

*Woher erhält die Vergleichsschaltung die Kundennummer, die zu einer Position gehört?*Bei einem klassischen Computer ist die Antwort selbstverständlich: Die Liste liegt im Arbeitsspeicher. Das Programm legt eine Position an den Speicher an und erhält den dort gespeicherten Wert zurück.

Bei einem Quantencomputer ist dieser Schritt nicht selbstverständlich.

Eine Million Positionen benötigen nur 20 Qubits

Mit jedem zusätzlichen Bit verdoppelt sich die Zahl der darstellbaren Positionen:

10 Bits → 1.024 Positionen
20 Bits → 1.048.576 PositionenEin Register aus 20 Qubits besitzt ebenfalls 1.048.576 mögliche Messergebnisse. Es kann deshalb alle Positionen einer Liste mit einer Million Einträgen darstellen.

Das klingt zunächst spektakulär: Nur 20 Qubits für eine Million Positionen.

Diese 20 Qubits enthalten jedoch nicht die eine Million Kundennummern. Sie enthalten nur das Positionsregister — also die möglichen Nummern der Listenplätze.

Die Daten selbst müssen an anderer Stelle liegen.

Was ein klassischer Speicherzugriff macht

Ein klassischer Arbeitsspeicher erhält genau eine Position:

Position 10 → Kundennummer 4711Das Suchprogramm kann den Wert anschließend mit 4711 vergleichen. Stimmt er nicht überein, setzt das Programm die nächste Position und wiederholt den Ablauf.

Position setzen
→ gespeicherte Kundennummer lesen
→ mit 4711 vergleichen
→ nächste Position setzenEin gewöhnlicher Speicherzugriff verarbeitet also eine bestimmte Position. Genau das passt zu einem klassischen Programm, das die Liste Eintrag für Eintrag durchsucht.

Was die Quantenschaltung benötigt

Nach den H-Gattern besitzt das Positionsregister nicht mehr nur eine bestimmte Position. Sein gemeinsamer Zustand enthält eine Amplitude für jede der rund eine Million möglichen Positionen.

Vereinfacht dargestellt:

Position 00000000000000000000 Amplitude
Position 00000000000000000001 Amplitude
Position 00000000000000000010 Amplitude
...
Position 11111111111111111111 AmplitudeDie Vergleichsschaltung soll nun für jede dieser Positionen feststellen, welche Kundennummer dort gespeichert ist und ob sie 4711 entspricht.

Dabei darf sie das Positionsregister nicht messen. Eine Messung würde nur eine einzige Position liefern und den gemeinsamen Zustand der übrigen Positionen zerstören.

Die benötigte Operation muss daher mit dem gesamten Quantenzustand arbeiten:

Positionen im gemeinsamen Quantenzustand
→ zugehörige Kundennummern bereitstellen
→ mit 4711 vergleichen
→ passende Amplitude markierenIn der Theorie wird diese gesamte Operation meist als Orakel bezeichnet. Unser Begriff Vergleichsschaltung aus Episode 6 beschreibt also nur ihre sichtbare Aufgabe. Damit sie vergleichen kann, muss sie jedoch zuerst an die zu jeder Position gehörenden Daten gelangen.

Ein gewöhnlicher Arbeitsspeicher reicht dafür nicht aus

Wir können das Quantenregister nicht einfach an einen normalen Arbeitsspeicher anschließen.

Der Arbeitsspeicher würde eine einzelne klassische Position erwarten. Das Quantenregister enthält vor der Messung aber keine einzelne Position, die wir ihm übergeben könnten. Es enthält Amplituden für alle möglichen Positionen.

Würden wir das Register messen, um eine klassische Position zu erhalten, wäre aus der Quantensuche wieder eine Suche nach nur einem Listeneintrag geworden.

Für Grovers Algorithmus benötigen wir stattdessen einen Speicherzugriff, der den gemeinsamen Zustand erhält. Aus

Position 00 + Position 01 + Position 10 + Position 11müsste vereinfacht

00 mit 5832

01 mit 1947
10 mit 4711
11 mit 8264werden — ohne vorher eine der vier Positionen auszuwählen.

Position und Kundennummer wären danach Teil desselben gemeinsamen Quantenzustands. Erst dann könnte die Vergleichsschaltung bei 4711 das Vorzeichen der zugehörigen Amplitude umkehren.

Drei Möglichkeiten, die Daten bereitzustellen

1. Die Daten werden berechnet

Manchmal steht hinter den Daten keine gespeicherte Liste, sondern eine Rechenvorschrift.

Wenn sich die Kundennummer aus der Position berechnen ließe, könnte eine Quantenschaltung diese Berechnung direkt ausführen. Sie benötigt dann keinen Speicherzugriff auf eine Million Einträge.

Grovers Algorithmus eignet sich besonders gut für solche Aufgaben: Eine Schaltung kann für jede mögliche Eingabe berechnen, ob sie die gesuchte Eigenschaft besitzt.

Unsere ungeordnete Kundenliste besitzt aber gerade keine solche Rechenvorschrift. Um zu wissen, welcher Wert an einer Position steht, muss die Schaltung die gespeicherten Daten kennen.

2. Die Liste wird in die Schaltung eingebaut

Man könnte die komplette Liste in Quantengatter übersetzen. Die Vergleichsschaltung wäre dann speziell für genau diese Daten gebaut.

Das funktioniert prinzipiell, hat aber einen Preis:

Die Schaltung wächst mit der Datenmenge.
Das Übersetzen der Liste verursacht Arbeit.
Ändert sich ein Eintrag, muss auch die Schaltung angepasst werden. Die Million Datensätze sind damit nicht verschwunden. Sie stecken nun in einer entsprechend großen Schaltung.

3. Ein Quantenspeicher stellt die Daten bereit

Die dritte Möglichkeit wird Quantum Random Access Memory, kurz qRAM, genannt.

Ein qRAM soll mit Positionen in Superposition umgehen können. Es soll die zugehörigen Daten bereitstellen, ohne das Positionsregister dabei auf eine einzelne Position festzulegen.

Das ist genau der Speicher, den unser vereinfachtes Beispiel stillschweigend vorausgesetzt hat.

Ein qRAM ist jedoch nicht einfach ein gewöhnlicher RAM-Chip mit einem Quantenanschluss. Die Positionen, die Daten und die Schaltelemente des Speichers müssen ihren gemeinsamen Quantenzustand während des Zugriffs bewahren. Fehler in diesem Vorgang verändern die Amplituden, auf denen der weitere Algorithmus beruht.

Es gibt verschiedene theoretische Vorschläge für qRAM. Einen großen, fehlertoleranten Quantenspeicher, den man wie heutigen Arbeitsspeicher als selbstverständliche Komponente verwenden kann, besitzen wir jedoch nicht.

Das Laden der Daten gehört zur Rechnung

Angenommen, unsere eine Million Kundennummern liegen zunächst in einer klassischen Datenbank. Bevor eine Quantenschaltung gemeinsam auf sie zugreifen kann, müssen die Daten in eine geeignete Quantenschaltung oder Speicherstruktur übertragen werden.

Schon das Einlesen aller Werte erfordert Arbeit, die mit der Größe der Liste wächst:

1.000.000 Einträge
→ 1.000.000 Werte müssen bereitgestellt werdenGrovers Algorithmus reduziert die Zahl der Orakelaufrufe von der Größenordnung N auf die Größenordnung √N. Er macht das erstmalige Bereitstellen von N beliebigen Datensätzen aber nicht automatisch billiger.

Für eine einzige Suche kann das Laden der Daten daher den theoretischen Suchvorteil aufzehren. Werden dieselben Daten anschließend sehr oft durchsucht, lässt sich der einmalige Aufwand auf viele Suchvorgänge verteilen. Dann kann die Rechnung anders ausfallen.

Der Satz

*„Grover durchsucht eine Million Einträge in ungefähr tausend Schritten“*ist deshalb unvollständig.

Vollständig müsste er lauten:

Wenn die Vergleichsschaltung bereits vorhanden ist und jeden benötigten Datenzugriff als geeignete Quantenoperation ausführen kann, benötigt Grovers Algorithmus ungefähr *√N Aufrufe dieser Schaltung.*### Aus einer Million werden ungefähr tausend Runden

Für eine Million mögliche Positionen gilt:

√1.000.000 = 1.000Die genaue günstigste Anzahl liegt bei genau einem Treffer etwas unter diesem Wert. Für unsere Betrachtung genügt die Größenordnung von ungefähr tausend Grover-Runden.

Jede Runde enthält mindestens:

Daten bereitstellen
→ mit 4711 vergleichen
→ passende Amplitude markieren
→ Amplituden spiegelnDie Aussage √N zählt also keine einzelnen elementaren Quantengatter und keine Nanosekunden. Sie zählt, wie oft die vollständige Vergleichsschaltung aufgerufen werden muss.

Ist diese Schaltung groß und langsam, ist auch eine Grover-Runde groß und langsam.

20 Qubits sind deshalb nicht genug

Die 20 Qubits stellen lediglich die Positionen dar. Eine wirkliche Schaltung benötigt zusätzlich Qubits für:

die gelesene Kundennummer,
den Vergleich mit 4711,
Zwischenergebnisse der Berechnung,
die Markierung der passenden Amplitude,
die fehlerfreie Rückführung aller Hilfsqubits in ihren Ausgangszustand. Hinzu kommt die Fehlerkorrektur. Die Qubits, mit denen ein Algorithmus beschrieben wird, sind logische Qubits. Für einen zuverlässigen logischen Qubit können — abhängig von Hardware, Fehlerquote und Korrekturverfahren — viele physische Qubits erforderlich sein.

Die Zahl der Positionsqubits sagt daher nur, wie viele Positionen mathematisch dargestellt werden können. Sie sagt noch nicht, wie groß der gesamte Quantencomputer sein muss.

Warum Fehler bei Grover besonders problematisch sind

Grovers Algorithmus lebt von kleinen, gezielten Veränderungen der Amplituden. Vergleich und Diffusion werden viele Male hintereinander ausgeführt.

Ein Fehler in einer frühen Runde betrifft nicht nur einen klassischen Zwischenwert. Er verändert den Quantenzustand, auf dem alle folgenden Runden weiterarbeiten. Wiederholen sich ungenaue Operationen hunderte Male, können sich ihre Fehler ansammeln und das gewünschte Amplitudenmuster zerstören.

Für eine große Suche genügt deshalb nicht nur eine große Zahl von Qubits. Die Qubits müssen ihren Zustand lange genug bewahren, die Gatter müssen sehr genau arbeiten und auftretende Fehler müssen während der Rechnung korrigiert werden.

Ist Grovers Algorithmus damit nutzlos?

Nein. Grovers Algorithmus zeigt eine echte und mathematisch bewiesene quadratische Verringerung der benötigten Orakelaufrufe.

Der Vorteil ist jedoch an Voraussetzungen gebunden:

Die möglichen Lösungen lassen sich mit ausreichend wenigen Qubits darstellen.
Die Prüfung einer möglichen Lösung lässt sich als Quantenschaltung ausführen.
Die Daten stehen dieser Schaltung in geeigneter Form zur Verfügung.
Die Kosten für Datenbereitstellung, Gatter und Fehlerkorrektur zerstören den Vorteil nicht.
Die quadratische Beschleunigung ist groß genug, um eine sehr schnelle klassische Implementierung zu schlagen. Grover macht daher nicht jede Datenbanksuche automatisch schneller. Er beschleunigt einen genau definierten Teil einer Aufgabe unter genau definierten Voraussetzungen.

Mit einem Missverständnis aufräumen

Missverständnis:* Mit 20 Qubits kann ein Quantencomputer eine Datenbank mit einer Million Einträgen speichern und in ungefähr tausend Schritten durchsuchen.20 Qubits können ungefähr eine Million **Positionen* darstellen. Sie speichern aber nicht automatisch die eine Million Datensätze. Damit Grovers Algorithmus diese Datensätze durchsuchen kann, müssen sie in der Vergleichsschaltung berechenbar, in die Schaltung eingebaut oder über einen geeigneten Quantenspeicher zugänglich sein.

Die ungefähr tausend Schritte sind außerdem ungefähr tausend Aufrufe dieser vollständigen Vergleichsschaltung — nicht tausend einfache CPU-Befehle.

Was wir jetzt wissen

Für eine Million mögliche Positionen genügen 20 Qubits im Positionsregister.
Das Positionsregister enthält Positionen, nicht die dazugehörigen Datensätze.
Ein gewöhnlicher Arbeitsspeicher liefert zu einer Zeit den Wert einer bestimmten klassischen Position.
Grovers Vergleichsschaltung muss mit allen Positionen im gemeinsamen Quantenzustand arbeiten, ohne sie vorher zu messen.
Die Daten können berechnet, in die Schaltung eingebaut oder über einen geeigneten Quantenspeicher bereitgestellt werden.
Ein qRAM müsste Speicherpositionen in Superposition verarbeiten und dabei den Quantenzustand erhalten.
Das Laden einer beliebigen Liste kostet Arbeit und gehört bei einer ehrlichen Laufzeitbetrachtung dazu.
Die Angabe √N zählt Orakelaufrufe, nicht elementare Gatter oder eine konkrete Laufzeit.
Die 20 Positionsqubits sind nur ein kleiner Teil der tatsächlich benötigten Hardware.
Große Grover-Schaltungen benötigen sehr genaue Operationen und Fehlerkorrektur. In Episode 8 wechseln wir von der Software zur Hardware. Wir vergleichen CPU, GPU und QPU und untersuchen, was ein physisches Qubit ist, wie Quantengatter technisch ausgeführt werden und warum eine QPU immer einen klassischen Computer zur Steuerung benötigt.

A More Thorough Way to Delete Files on Mac

Christian Ahrweiler — Wed, 07 Oct 2026 08:33:39 +0000

Drop & Forget overwrites accessible file contents before removing themA More Thorough Way to Delete Files on MacDragging a file to the Trash feels final. Emptying the Trash feels even more final.

But in most cases, macOS is not immediately erasing every byte that belonged to the file. It is removing the file from the visible file system and marking its storage space as available for reuse.

That is perfectly adequate for everyday cleanup. But sometimes a file contains information you would rather not leave behind unnecessarily: an exported database, a private document, an old backup, customer data, financial records, or a folder prepared for someone else.

That is why I built Drop & Forget.

Drop. Confirm. Forget.

Drop & Forget is a small native Mac app with a deliberately simple workflow:

Drop files or folders into the app.
Review the selection.
Confirm the warning.
Let the app process and delete the selected items. The files are not moved to the Trash. Before removing them, Drop & Forget performs several additional steps.

It replaces the original filename with a random name, removes the file extension and accessible metadata, overwrites the accessible file contents, synchronizes the changes to storage, truncates the file, and finally deletes it.

Complete folders can be processed recursively, with a clear result shown for every item.

Why anonymize the filename?

The contents of a file are not always the only sensitive part.

A name such as Customer_Export_September.csv, Tax_Return_2025.pdf, or Confidential_Agreement.docx can reveal useful information even without opening the file.

Drop & Forget therefore replaces the original name before it begins overwriting the contents. If the process is interrupted, the descriptive filename has already disappeared from the active directory.

The app also removes the extension, so the temporary randomized name no longer identifies the original file type.

Why overwrite the contents?

Normal deletion primarily removes the file system’s reference to a file. Until the freed storage is reused, recovery software may sometimes be able to reconstruct some or all of its contents.

Drop & Forget writes zeros across the complete accessible length of the file before deleting it. This makes conventional recovery from the file’s currently accessible storage significantly more difficult.

One overwrite pass is enough for this purpose. Repeating the operation many times is a practice associated with older magnetic storage and does not solve the limitations of modern SSDs.

An honest limitation of secure deletion

No ordinary Mac app can truthfully guarantee the physical destruction of every trace of an individual file on a modern SSD.

There are several reasons for this:

SSD controllers use wear leveling and decide which physical memory cells receive new data.
APFS uses copy-on-write techniques and may retain earlier storage blocks.
APFS snapshots can contain an older version of a file and its original name.
Time Machine and other backup systems may already hold a copy.
Cloud services may retain synchronized copies or previous versions. Even after an app synchronizes a write successfully, it cannot command an SSD controller to overwrite one specific physical memory cell.

For that reason, Drop & Forget does not promise “military-grade deletion” or guaranteed physical erasure. Those claims would be misleading on current Mac hardware.

What it does provide is a practical additional layer: anonymize the visible name, remove accessible metadata, overwrite the accessible contents, and delete the item directly instead of placing it in the Trash.

Designed to avoid dangerous surprises

A deletion utility must be especially careful about unusual file-system objects.

Drop & Forget does not follow symbolic links into other locations. Deleting a selected folder must never unexpectedly erase files somewhere else on the Mac.

Files with multiple hard links also require special treatment. Because every hard link refers to the same underlying content, overwriting one would affect the others. Drop & Forget detects this situation rather than silently damaging another file.

The app also reports whether each item was deleted, skipped, only partially processed, or could not be removed. A failed operation must never be presented as a successful deletion.

Everything happens locally

Drop & Forget does not upload or analyze files. There is no account, subscription, or external deletion service.

The app works only with the files and folders you explicitly select and performs the complete operation locally on your Mac.

More than Empty Trash

The Trash remains the right tool for routine file management. It gives you a chance to recover something deleted by mistake, which is usually exactly what you want.

Drop & Forget is for the smaller number of files you intentionally want to remove more thoroughly.

It cannot reach copies stored in snapshots, backups, cloud histories, or other devices. But it can do considerably more than simply remove a directory entry and hope that the underlying storage is reused someday.

Sometimes deleting a file is enough.

And sometimes you want to drop it and forget it.

Drop & Forget is a native macOS utility.

Download on App Store: https://apps.apple.com/us/app/drag-forget/id6807579446

More Beaver Tools: https://beavertools.app/

Bitcoin Tools for Miners — and People Who Want to Look Closer

Christian Ahrweiler — Tue, 06 Oct 2026 16:54:28 +0000

Bitcoin Tools for Miners — and People Who Want to Look CloserBitcoin is often presented as a price chart, a wallet balance or a headline.

But underneath that surface is a network with its own visible mechanics: blocks arrive, transactions wait, fees compete for limited block space, and miners construct candidate blocks from work performed across many machines.

I wanted a small collection of macOS tools that makes those mechanics easier to inspect without requiring a wallet, private keys or an exchange account.

That collection is now available at BTC Miner Tools.

One pool. Many machines.

The centrepiece is Bitcoin Miner Coordinator.

It connects to a Stratum V1 mining pool and coordinates compatible Workers running on separate Macs or Linux machines. The Coordinator itself does not perform hashing. Instead, it provides one place to see the connected Workers, their selected CPU and GPU profiles, live hashrate, completed work and session state.

Mac Workers can be found automatically on the local network. Remote Linux Workers can be connected through a separately configured private WireGuard network.

That distinction matters. A mining port does not need to be exposed to the public internet just to coordinate machines across locations.

The point is not to promise profitable mining. Mining is probabilistic, pool difficulty changes, hardware varies, and a share may arrive quickly or not at all.

The point is to make the process visible.

A Worker can be a Mac that is already running, a small Linux VPS, or a dedicated Hub that helps connect remote Workers. The Coordinator shows what each machine is contributing and lets you decide which machines should participate.

Mining can be a useful way to learn

Bitcoin Miner Education takes the same subject in a different direction.

Rather than hiding the work behind a single number, it shows a block candidate, the 80-byte header, double SHA-256 processing, nonces and the relationship between a hash and the current target.

Bitcoin mining is often described with simplified phrases such as “solving a puzzle.” That is useful as a first introduction, but it leaves out the interesting part: miners repeatedly change a candidate header and test whether its resulting hash meets the network target.

The Education app makes that cycle tangible without asking the user to create a wallet or manage a mining account.

Observe public Bitcoin addresses without exposing keys

A wallet is not the only way to follow Bitcoin.

Bitcoin Address Monitor is deliberately read-only. Add public Bitcoin addresses, give them clear names, organize them into groups and review balances and transaction history.

It does not request a recovery phrase. It does not import a private key. It cannot send or spend Bitcoin.

That boundary is intentional.

The app can display BTC, sats and a selected fiat currency, and it can help organize public addresses for savings, donations, business activity or cold storage. It also supports notes and output review so that users can identify monitored change addresses more clearly.

A separate Bitcoin wallet may come later. Monitoring public information should remain simple and safe on its own.

See the network, one layer at a time

The other tools are built around public Bitcoin network data.

Bitcoin Mempool Monitor focuses on the transactions waiting for confirmation. It turns an overwhelming stream of unconfirmed transactions into a clearer question:

Which transactions are likely to fit into the next block?

It shows fee-rate pressure, available block weight, the estimated inclusion threshold and the way replacement-by-fee can change the visible transaction set. It does not claim to know exactly when the next block will arrive or precisely which transactions a specific mining pool will select.

Bitcoin Block Monitor lets you move through the blockchain one block at a time. Browse recent or historical blocks, inspect their transaction count, size, weight, fees, subsidy, mining time and other network context.

Bitcoin Transaction Tree makes the UTXO model visible. Start with a transaction ID, inspect its inputs on one side and its outputs on the other, then move backward to the transactions that funded it or forward to transactions that later spent an output.

Together, these tools make it easier to see that Bitcoin does not move coins between accounts in the way a traditional banking app does. Transactions consume previous outputs and create new outputs. Blocks record those transactions. The mempool is the waiting area before inclusion. Mining is the process that turns one candidate block into the next accepted block.

Built to inspect, not to ask for trust

The common design principle behind the collection is straightforward:

Use public data where public data is enough.
Keep monitoring tools read-only.
Do not request recovery phrases or private keys.
Do not make return promises.
Explain the uncertainty instead of hiding it. Bitcoin is already interesting without adding unnecessary mystery around it.

BTC Miner Tools is a growing set of apps for people who want to look closer: curious Bitcoin users, students, educators, developers and anyone who prefers to understand the tools in front of them.

Explore the collection at btcminertools.com.

Bitcoin-Tools für Miner und alle, die Bitcoin verstehen wollen

Christian Ahrweiler — Tue, 06 Oct 2026 16:52:48 +0000

Bitcoin-Tools für Miner und alle, die Bitcoin verstehen wollenBitcoin ist zugleich Geldsystem, Netzwerk, Datenstruktur und ein fortlaufender Wettbewerb um den nächsten Block. Wer sich damit beschäftigt, stößt schnell auf viele Fachbegriffe, verstreute Datenquellen und Werkzeuge, die jeweils nur einen kleinen Teil sichtbar machen.

BTC Miner Tools bündelt mehrere macOS-Apps, die unterschiedliche Aspekte von Bitcoin verständlich, praktisch und bewusst transparent machen.

Nicht als Börse. Nicht als Wallet-Anbieter. Nicht mit Versprechen über Erträge.

Sondern als Werkzeuge für Menschen, die sehen möchten, was im Bitcoin-Netzwerk geschieht.

Mining koordinieren, ohne selbst zu minen

Der Bitcoin Miner Coordinator verbindet kompatible Mac- und Linux-Worker mit einem Stratum-V1-Mining-Pool.

Der Coordinator selbst führt keine SHA-256-Hashes aus. Er verteilt Arbeit an separat laufende Worker, sammelt deren Status und zeigt die gemeinsame Leistung übersichtlich an:

erkannte lokale und Netzwerk-Worker
aktuelle Hashrate je Worker
CPU-, GPU- und Leistungsprofil
bisherige Arbeit innerhalb der Sitzung
angenommene und abgelehnte Shares
Verbindung zum Mining-Pool Lokale Worker können automatisch im Netzwerk gefunden werden. Für räumlich getrennte Systeme ist eine private WireGuard-Verbindung vorgesehen. So muss kein Mining-Port öffentlich ins Internet gestellt werden.

Mining mit normaler Hardware ist kein Geschäftsmodell und kein Renditeversprechen. Gerade deshalb ist es interessant: Es macht sichtbar, was hinter Blockvorlagen, Nonces, Hashraten und Shares technisch passiert.

Mining verstehen, nicht nur starten

Bitcoin Miner Education konzentriert sich auf den Prozess hinter Proof of Work.

Die App zeigt, wie ein Blockkandidat aufgebaut ist, welche Daten im 80-Byte-Header stehen und wie sich Nonces, Zielwert und Double-SHA-256 zueinander verhalten. CPU- und GPU-Hashing lassen sich unmittelbar beobachten.

Damit wird aus einem abstrakten Satz wie „Miner suchen einen gültigen Hash“ ein nachvollziehbarer technischer Vorgang.

Bitcoin-Mining ist kein Countdown bis zur nächsten Belohnung. Jeder Hash ist ein weiterer Versuch. Ob ein gültiger Block gefunden wird, bleibt probabilistisch.

Öffentliche Adressen beobachten — ohne Wallet-Zugriff

Mit Bitcoin Address Monitor lassen sich öffentliche Bitcoin-Adressen lokal auf dem Mac beobachten und organisieren.

Die App arbeitet ausschließlich lesend:

kein Seed
keine privaten Schlüssel
keine Möglichkeit, Bitcoin zu senden
keine Exchange-Verbindung
keine Registrierung Adressen können benannt, Gruppen zugeordnet und in einer gemeinsamen Übersicht betrachtet werden. Transaktionen, Salden, Gebühren und bekannte Gegenadressen werden nachvollziehbar dargestellt.

Auch die geschätzte Gewinn- und Verlustbetrachtung ist als Orientierung gedacht, nicht als Steuer- oder Finanzberatung. Die zugrunde liegenden öffentlichen Daten können hilfreich sein — sie ersetzen keine individuelle Bewertung.

Die nächste Blockauswahl verstehen

Der Mempool ist keine einfache Warteschlange.

Bitcoin Mempool Monitor zeigt, wie unbestätigte Transaktionen in den geschätzten nächsten Block einfließen könnten. Sichtbar werden unter anderem:

neu eintreffende Transaktionen
Gebührenraten und Einschätzung der Aufnahmegrenze
belegtes und verfügbares Blockgewicht
Replace-by-Fee-Änderungen
Transaktionen, die unterhalb der aktuellen Grenze warten Die Anzeige ist bewusst als Schätzung formuliert. Unterschiedliche Nodes und Mining-Pools sehen nicht immer exakt dieselben Transaktionen und können eigene Auswahlregeln anwenden. Niemand kann zuverlässig vorhersagen, wann der nächste Block gefunden wird oder exakt welche Transaktionen er enthalten wird.

Blöcke und Transaktionen als zusammenhängendes System

Bitcoin Block Monitor macht die Blockchain als navigierbare zeitliche Folge sichtbar. Blöcke lassen sich nach Höhe, Hash oder Zeitpunkt finden und detailliert untersuchen: Größe, Gewicht, Gebühren, Mining-Pool, Merkle Root, Nonce, Difficulty und Bestätigungen.

Bitcoin Transaction Tree macht dagegen die Verbindungen zwischen Transaktionen greifbar. Eine Transaktion steht im Mittelpunkt; ihre Inputs führen rückwärts zu früheren Ausgängen, ihre Outputs vorwärts zu späteren Ausgaben.

Das hilft beim Verständnis des UTXO-Modells: Bitcoin verschiebt keine Kontostände zwischen Konten. Transaktionen verbrauchen bestehende Ausgänge und erzeugen neue.

Werkzeuge statt Versprechen

Bitcoin kann kompliziert sein — aber die zugrunde liegenden Abläufe sind nicht geheim.

BTC Miner Tools setzt auf sichtbare Daten, kontextbezogene Erklärungen und klar abgegrenzte Funktionen. Die Apps verwalten keine Wallets, fragen keine Wiederherstellungsphrasen ab und versprechen keine Gewinne.

Sie sind für Miner, Lernende, Entwickler und alle gedacht, die nicht nur auf einen Bitcoin-Preis schauen möchten, sondern verstehen wollen, was darunter passiert.

Mehr Informationen: btcminertools.com

F1 Racing, Episode 2 — Die Formel 1 auf Kaffeefahrt

Christian Ahrweiler — Tue, 06 Oct 2026 16:08:44 +0000

F1 Racing, Episode 2 — Die Formel 1 auf KaffeefahrtEin Safety Car soll eine Sache tun: die Strecke sicher machen.

Ein Auto steht ungünstig, Marshals müssen arbeiten, Trümmer liegen auf der Strecke. Das Safety Car kommt raus, das Feld wird langsam, die Gefahr wird beseitigt.

Soweit ist alles richtig.

Seltsam wird es, wenn die Strecke längst wieder frei ist — und die Formel 1 trotzdem noch weitere Runden hinter dem Safety Car dreht, um überrundete Autos zu sortieren.

Am Sonntag in Sepang konnte man sehen, wie viel Zeit diese Prozedur kosten kann.

Erst sichern, dann stoppen, dann sortieren

Während das Safety Car die Strecke absichert, dürfen die Fahrer in die Box. Neue Reifen, andere Strategie, vielleicht ein beschädigter Frontflügel — das gehört dazu.

Doch dadurch verteilt sich das Feld noch einmal neu. Ein überrundeter Fahrer kann in der Box stehen, während die Führenden längst hinter dem Safety Car gesammelt sind.

Wenn die Strecke endlich freigegeben ist, beginnt deshalb oft erst der zweite Teil der Veranstaltung: das Zurückrunden.

Die Rennleitung gibt die Meldung „LAPPED CARS MAY NOW OVERTAKE“. Überrundete Autos müssen am Feld und am Safety Car vorbeifahren, fast eine ganze Runde drehen und sich hinten wieder einreihen.

Erst dann kann das Safety Car hinein.

Die Zeit addiert sich:

Strecke sichern
Boxenstopps abwarten
Feld wieder sammeln
Überrundete zurückrunden lassen
alle wieder korrekt einsortieren Das kann aus einer notwendigen Unterbrechung eine sehr lange Pause machen.

Der Grund ist nachvollziehbar

Ohne diese Regel könnte ein überrundetes Auto zwischen dem Führenden und dem Zweitplatzierten liegen.

Der Führende hätte freie Fahrt. Der Zweite müsste beim Restart aber zunächst an einer „lahmen Ente“ vorbei, bevor er den Kampf um die Spitze überhaupt wieder aufnehmen kann.

Das ist der sportliche Gedanke hinter dem Zurückrunden: Die Führenden sollen direkt hintereinander starten.

Sauber. Fairer. Verständlich.

Nur ist der Preis dafür oft zu hoch.

Der Nutzen ist kleiner als der Zeitverlust

Der Zweitplatzierte könnte durch einen überrundeten Wagen tatsächlich einige Sekunden verlieren. Das kann entscheidend sein.

Aber dieser Wagen wurde bereits überrundet.

Der Zweite sollte ihn normalerweise ebenfalls überholen können. Vielleicht kostet es Zeit, vielleicht wird es kurz spannend — aber genau das ist Rennsport.

Stattdessen nimmt die Formel 1 häufig noch eine oder mehrere Runden im Safety‑Car‑Tempo in Kauf, damit am Ende alles perfekt sortiert aussieht.

Am Sonntag waren die überrundeten Fahrer erst spät freigegeben. Pérez und Bortoleto hatten das Hauptfeld zu diesem Zeitpunkt noch nicht einmal erreicht. Während sie ihre Runde drehten, warteten die anderen weiter hinter dem Safety Car.

Nicht, weil die Strecke noch gefährlich war.

Sondern weil die Reihenfolge noch nicht schön genug war.

Weniger Ordnung, mehr Rennen

Die Regel ist nicht unsinnig. Sie will einen sauberen Neustart ermöglichen.

Sie ist aber unnötig aufwendig.

Ein Safety Car sollte so bald wie möglich wieder hereinkommen, sobald die Strecke sicher ist. Ein Führender darf freie Fahrt haben. Der Zweite darf auch einmal Verkehr vor sich haben. Das Rennen muss nicht vor jedem Restart sortiert werden.

Die einfachere Alternative:

Safety Car rein. Autos bleiben, wo sie sind. Grün.

Dann passiert vielleicht etwas Unordentliches.

Vor allem aber passiert wieder etwas auf der Strecke.

Quellen

F1 Racing, Episode 1 — Die Formel 1 und das kleine Problem namens Regen

Christian Ahrweiler — Mon, 05 Oct 2026 22:52:51 +0000

F1 Racing, E1 — Die Formel 1 und das kleine Problem namens RegenDie Formel 1 baut die schnellsten Rennwagen der Welt.

Sie beschleunigen brutal, bremsen absurd spät und verwalten Energie, Aerodynamik und Motorleistung in Echtzeit.

Und dann regnet es.

In Sepang fuhren mehrere Autos in der Formationsrunde los, verloren Leistung und rollten beinahe aus. Der Start wurde abgebrochen, die Autos kehrten zurück — und die FIA verteilte neue Softwareparameter.

Die Formel 1 wartete auf ein Update.

Das ist kein witziger Ausrutscher. Das ist die Bestätigung eines Problems, das mit dem neuen Reglement vorhersehbar war: Zu viele Regeln haben aus einem Rennwagen ein unnötig fragiles Softwaresystem gemacht.

Nicht der Regen war zu kompliziert

Die FIA erklärte, eine bisher nicht aufgetretene Kombination aus niedriger Motordrehzahl, wenig Grip und Nässe habe bei mehreren Autos zu einem unbeabsichtigten Leistungsverlust geführt. Eine Energielimitierung wurde per Software‑Update geändert.

Vielleicht war das ein Programmierfehler. Vielleicht war eine Anforderung unvollständig. Von außen lässt sich das nicht seriös trennen.

Der entscheidende Punkt ist ein anderer: Das System war für eine vollkommen normale Rennsituation nicht ausreichend vorbereitet.

Nasse Strecke. Langsame Formationsrunde. Niedrige Drehzahl. Batteriemanagement. Rekuperation. Begrenzte elektrische Leistung. Motorschutz. Logik gegen Traktionskontrolle.

Jede dieser Funktionen lässt sich einzeln begründen. Zusammen ergeben sie ein System, das offenbar nicht mehr sicher wusste, wie es Leistung abgeben soll.

Das ist das klassische Problem mit Komplexität: Nicht jede einzelne Regel ist falsch. Aber ihre Wechselwirkungen werden irgendwann größer als das Verständnis und die Testabdeckung des Gesamtsystems.

Die FIA sitzt mit im Steuergerät

Teams und Motorenhersteller entwickeln weiterhin eigene Software und Kalibrierungen. Aber sie tun das nicht völlig frei.

Die Formel 1 schreibt eine FIA‑Standard‑ECU vor. Darüber laufen unter anderem Power Unit, Getriebe, Bremsen, Reifendrucküberwachung und verstellbare Aerodynamik. Die eingesetzte Software muss von der FIA zugelassen und registriert werden.

Das soll versteckte elektronische Fahrhilfen verhindern. Verständlich.

Es bedeutet aber auch: Die FIA ist nicht nur Regelhüter am Streckenrand. Sie ist Teil der technischen Architektur. Wenn ein zentral geregelter Softwarebereich unter bestimmten Bedingungen versagt, kann das gleich mehrere Teams treffen.

Genau das passierte am Sonntag.

Regen ist kein exotischer Sonderfall

Besonders unerquicklich ist, dass diese neue Fahrzeuggeneration offenbar noch kein vergleichbares nasses Rennen erlebt hatte.

Natürlich kann man nicht jede Situation auf einem Prüfstand vollständig nachstellen. Aber Regen gehört nicht in die Kategorie „unvorhersehbares Ereignis“.

Regen gehört zum Motorsport.

Wenn ein Formel‑1‑Auto bei einer nassen Formationsrunde erst nach einem Update wieder losfahren kann, dann ist nicht der Regen das Problem. Dann ist das Regelwerk zu kompliziert.

Die Formel 1 will gleichzeitig effizienter, elektrischer, nachhaltiger, kontrollierter und fairer werden. Jedes Ziel erzeugt neue Vorgaben. Jede Vorgabe erzeugt Software. Jede Software erzeugt Sonderfälle.

Irgendwann fährt ein Rennwagen nicht mehr einfach schnell. Er verhandelt erst mit sich selbst, ob er es darf.

Weniger Regelwerk, mehr Rennwagen

Die falsche Lehre aus Sepang wäre eine neue Ausnahmeregel: zusätzliche Regenparameter, neue Kennfelder, noch mehr Bedingungen.

Das wäre nur die nächste Schicht auf einem bereits überladenen System.

Die richtige Frage lautet: Was kann weg?

Ein Formel‑1‑Auto muss nicht jede Kilowattstunde unter jeder denkbaren Bedingung perfekt verwalten. Es muss vor allem zuverlässig fahren — schnell, langsam, trocken, nass und hinter dem Safety Car.

Am Sonntag hat die Formel 1 gezeigt, was passiert, wenn ein Reglement zu viel will.

Dann regnet es.

Und die schnellsten Autos der Welt warten auf ein Update.

Quellen

Google Challenges NVIDIA’s AI Business with In-House Chips

Christian Ahrweiler — Sun, 04 Oct 2026 11:33:49 +0000

Google Challenges NVIDIA’s AI Business with In-House Chips*Why TPUs are not simply faster GPUs, why Google is both a customer and a competitor to NVIDIA, and how the market for AI data centers could evolve.*

NVIDIA reported revenue of $215.9 billion for its fiscal year ending late January 2026.

$193.7 billion of that total was generated by NVIDIA’s Data Center segment. In this context, the name describes the target market, not the operator: NVIDIA does not run its customers’ data centers, but instead provides a major portion of their underlying hardware and technical infrastructure. This includes GPUs, networking components, full server systems, and associated software. Operators and customers include Google, Amazon, Microsoft, Oracle, Meta, as well as specialized cloud providers. [1]

Google Cloud also offers NVIDIA systems to its customers. At the same time, Google has been developing its own proprietary AI accelerator for over a decade: the Tensor Processing Unit (TPU).

This makes Google both a customer and a competitor.

The company needs NVIDIA hardware to meet current demand for AI compute capacity. However, with each new TPU generation, Google can offload a larger share of that workload onto its own platform — initially for Search, YouTube, Ads, and Gemini, and now increasingly for external cloud customers as well.

This dual path illustrates how the market could shift. NVIDIA won’t disappear overnight from data centers, but new AI capacity no longer has to be built using NVIDIA GPUs by default.

Why AI Runs on GPUsA computer chip consists of billions of transistors — tiny electronic switches that form computing circuits and memory. How these circuits are arranged determines which tasks a processor excels at.

The Central Processing Unit (CPU) is a computer’s versatile primary processor. It launches applications, manages memory, responds to user inputs, and handles complex logic with many branch decisions and varied execution steps.

A Graphics Processing Unit (GPU) was originally designed for graphics rendering.

When generating an image, positions, colors, and lighting must be calculated for millions of pixels. Many of these calculations are virtually identical and can be executed simultaneously.

While a CPU has a relatively small number of high-performance cores, a GPU distributes work across thousands of smaller processing units. This allows it to process massive volumes of similar numerical operations in parallel.

This exact capability is what neural networks require.

The learned knowledge of a neural network is stored in vast arrays of numerical values known as weights. During training and inference, large matrices of numbers are multiplied together and their products summed up.

These matrix operations map naturally to the parallel computing units of a GPU.

Thus, a graphics processor evolved into an AI accelerator.

Training and Inference Are Two Distinct TasksDuring training, an AI model learns. It processes training data, compares its output against a desired result, and subsequently updates its weights. This cycle repeats billions of times.

Consequently, training involves much more than generating an answer. The system must track errors backward through the network, compute gradient updates for weights, and exchange these updates across hundreds or thousands of interconnected chips. Large training runs therefore require flexible compute units, ultra-fast interconnects, and a mature software ecosystem.

During inference, the trained AI model is applied to real-world inputs. For instance, a language model receives a query and calculates a response using its existing weights. The weights themselves are not updated during this process.

In an active production environment, this workflow repeats for millions of users:

Receive input
→ Calculate output using existing weights
→ Return responseThis repetitive and highly predictable workload is ideally suited for custom, domain-specific hardware. When serving millions or billions of requests, every incremental reduction in power consumption and cost per response matters immensely.

This is why inference in particular could shift faster toward TPUs and other custom accelerators, whereas training may rely longer on NVIDIA’s greater flexibility and mature ecosystem.

CUDA Turned the GPU into a PlatformHardware alone would not have made NVIDIA the undisputed market leader.

With CUDA, NVIDIA created a software platform that allowed programs to execute non-graphics workloads directly on GPU cores.

CUDA is far more than a basic API; it encompasses compilers, optimized mathematical libraries, debugging tools, and tailored implementations of common algorithmic routines.

AI frameworks like PyTorch leverage this underlying foundation, sparing developers from having to program low-level matrix multiplications directly for the hardware.

Over many years, a powerful ecosystem emerged:

NVIDIA GPU
→ CUDA
→ Optimized AI libraries
→ PyTorch & other frameworks
→ Tooling for development & ops
→ Experienced developer poolModern NVIDIA GPUs also feature dedicated Tensor Cores — specialized hardware modules explicitly designed for the mathematical operations most common in neural networks. [2]

As a result, NVIDIA no longer simply sells graphics chips that happen to process AI workloads. It delivers specialized AI GPUs, high-speed interconnects, advanced networking tech, and fully integrated server racks.

Google Buys NVIDIA Tech — and Builds the ReplacementGoogle Cloud offers both NVIDIA GPUs and Google’s in-house TPUs. As recently as late 2025, Google announced new cloud clusters featuring NVIDIA’s GB300 platform while simultaneously preparing Ironwood, its seventh-generation TPU. [3]

This is not a contradiction.

Google demands immense volumes of compute capacity. Its internal chips cannot instantly absorb every workload, nor are they available in unlimited quantities. NVIDIA provides a mature, turnkey platform that many enterprise customers and models already support natively.

At the same time, Google has a compelling financial incentive to build its own alternative.

Search, YouTube, Ads, and Gemini generate continuous, large-scale AI workloads. If a proprietary chip makes an individual calculation even marginally cheaper or more energy-efficient, those tiny savings compound across hundreds of billions of queries.

Developing custom silicon also reduces vendor lock-in. Google can co-design chips, software, and data centers in tandem, tailoring future hardware directly to its proprietary model architectures.

The TPU did not begin as a direct head-to-head assault on NVIDIA; it started as an internal engineering solution to manage Google’s own cost structure and compute requirements.

Through Google Cloud, it evolved into an enterprise product for external customers.

What Makes a TPU Different*TPU* stands for Tensor Processing Unit.

A tensor is a multi-dimensional array of numbers — a vector is a one-dimensional tensor, while a matrix is a two-dimensional tensor.

The name highlights the chip’s core focus. Google designed the TPU from day one specifically for machine learning. Massive matrix multiplication units, high-bandwidth memory access, and inter-chip communications are custom-engineered for these exact workloads. [4]

A TPU does not contain hardcoded AI models. It is a programmable hardware accelerator capable of training and running a wide variety of supported neural architectures.

The fundamental difference between GPUs and TPUs lies in their origin stories:

GPU:
Flexible parallel processor
→ Later heavily specialized for AI

TPU:
Purpose-built for machine learning from day one
→ Later broadened for more models & workloadsToday, this boundary is blurring.

NVIDIA builds dedicated AI modules (Tensor Cores) into its GPUs, while Google expands its TPUs to handle wider ranges of model architectures, precision formats, and mathematical operations.

One platform is becoming more specialized, while the other is becoming more versatile.

TPUs Live in Racks TooA TPU chip does not operate in isolation.

A complete TPU system requires standard host CPUs, system memory, network interconnects, power delivery, and specialized cooling infrastructure. Google links large numbers of TPU chips into clusters known as “Pods,” which span multiple physical server racks.

In practice, a large AI model is split across hundreds or thousands of interconnected chips. During computation, these chips must continuously exchange intermediate results. Consequently, memory bandwidth and interconnect speed dictate overall performance just as much as raw compute power.

Google provides TPU capacity via Google Cloud, meaning customers do not need to purchase or physically host the hardware themselves. Instead, they provision specific cluster configurations for discrete training runs or ongoing inference services. [4][5]

Because of this model, Google isn’t competing with NVIDIA on a chip-by-chip basis.

Both companies deliver end-to-end platforms:

Accelerators
→ Memory architecture
→ High-speed interconnects
→ Server racks & infrastructure
→ Liquid/air cooling
→ Compilers & framework libraries
→ Cloud operational layersModels Don’t Need to “Re-learn” When Switching HardwareThe weights of a neural network are simply stored numeric parameters. They are not permanently bound to the specific GPUs on which the model was originally trained.

Therefore, a model can be trained on GPUs and subsequently deployed for inference on TPUs. Likewise, training state from a TPU run can be saved and resumed on alternative supported hardware.

A model does not need to be retrained from scratch simply because the underlying chip vendor changes.

The critical distinction is between model parameters and the surrounding software environment:

Model weights are portable. The surrounding software stack may not be.High-level AI frameworks like PyTorch and JAX define mathematical operations abstractly. Underlying compilers and runtime engines then translate those operations for specific hardware backends.

For TPUs, JAX and PyTorch/XLA serve as these translation layers. If a model relies strictly on standard, well-supported operations, porting it can be relatively straightforward. [6]

Migration becomes significantly more complex if a codebase:

Uses custom CUDA kernels,
Relies on NVIDIA-specific proprietary libraries,
Has been hand-tuned for a specific GPU cache or interconnect architecture,
Or ties its monitoring and telemetry pipeline directly to NVIDIA tooling. In those scenarios, portions of the software stack must be rewritten or re-architected.

An AI model doesn’t need to learn again — but engineers may need to reconfigure the infrastructure supporting it.

Migration Happens Workload by WorkloadNo enterprise data center swaps out its entire GPU footprint for TPUs over a single weekend.

Instead, an operator typically spins up a parallel model instance on TPUs to evaluate key metrics:

Does output quality remain identical?
What is the end-to-end response latency for users?
How many concurrent requests can the system handle?
How stable is the service under sustained load?
What is the total cost per million input and output tokens?
What are the real-world energy and cooling requirements? If performance and unit economics prove compelling, a small fraction of live traffic is routed to the TPU cluster. As confidence grows, that share expands over time.

GPU and TPU infrastructures can coexist peacefully within the same organization for years. Furthermore, training and inference do not need to run on identical hardware.

What cannot easily be done is swapping individual GPUs for TPUs inside an active, running training cluster. The underlying chips within a single cluster must be tightly synchronized and share an identical software and network environment.

Migration therefore occurs service by service or model by model — not component by component.

A TPU Isn’t Faster by DefaultThe real-world speed of an AI system depends on far more than nominal chip specs.

In training, the key metric is how long a model takes to reach a target validation loss or quality threshold. In inference, user latency and concurrent throughput take center stage.

A given cluster might deliver high aggregate throughput while exhibiting higher latency on individual requests. Another setup might offer lower latency but carry a higher hourly rental cost.

Theoretical compute figures (e.g., peak FLOPS) can also be deceptive. Data must be streamed efficiently from memory, and hundreds of chips must exchange intermediate tensors without bottlenecking. If memory bandwidth or network interconnects saturate, raw compute units sit idle.

A meaningful performance benchmark requires a strictly defined task:

Identical model architecture
→ Identical output quality threshold
→ Identical maximum latency allowance
→ Total end-to-end system cost
→ Energy consumed per valid outputWithout these constraints, claims like “3x faster” are largely meaningless.

For enterprise buyers, peak theoretical compute capacity is irrelevant compared to the actual cost per useful training hour or production inference call.

NVIDIA’s Business Is Transparent — Google’s TPU Revenue Is ObscuredNVIDIA’s $193.7 billion in annual Data Center revenue provides a clear metric of its market dominance and commercial reach. [1]

Google, by contrast, does not break out standalone TPU revenue in its financial reporting.

TPUs generate value across multiple channels:

Reducing operational costs for internal Google services,
Generating direct cloud rental revenue via Google Cloud Platform,
Enabling Google to sell fully integrated AI infrastructure bundles,
And, as of 2026, selling turnkey TPU systems directly as product offerings. [7] Google Cloud reported total revenue of $58.7 billion for 2025 — a figure that combines AI compute with Workspace subscriptions, databases, storage, and general cloud services.

Parent company Alphabet reported $91.4 billion in capital expenditures for 2025, directed primarily toward technical infrastructure. This sum encompasses GPUs, TPUs, servers, networking gear, real estate, and data center facilities combined. [8]

As a result, precise TPU market share figures cannot be calculated directly from public filings.

This financial structure complicates direct comparisons: NVIDIA profits primarily from selling hardware infrastructure, whereas Google can capture ROI simply by lowering the operational unit economics of Search, Ads, or Gemini.

Anthropic Turns TPUs into a Major Non-Google BusinessFor years, TPUs were viewed primarily as an internal Google technology stack.

Anthropic is changing that narrative.

The creator of Claude finalized multi-gigawatt agreements with Google and Broadcom to secure next-generation TPU capacity starting in 2027. [9]

According to Reuters, Anthropic’s financial disclosures detail a five-year commitment totaling $125.2 billion for TPU compute capacity. [10]

This does not mean Anthropic is abandoning NVIDIA entirely — leading AI laboratories routinely diversify their compute footprints across multiple hardware vendors and cloud providers.

However, a commitment of this scale confirms that an external AI company is anchoring a massive share of its core future infrastructure on Google’s TPU platform.

Google has successfully transitioned the TPU from an internal custom chip into a mainstream enterprise platform upon which leading AI firms build multi-year strategy.

The Real Competition Happens at the Next Expansion PhaseGoogle does not need to rip and replace existing NVIDIA server racks in established data centers.

Demand for AI compute continues to grow rapidly. Companies are building new facilities, expanding existing footprint, and scaling out capacity to handle rising inference volumes.

Every infrastructure expansion presents a fresh purchasing decision.

An operator can maintain its legacy GPU footprint for core training while routing new inference expansion onto TPU pods. A new model generation can be trained on a different hardware platform than its predecessor. A cloud customer can shift specific microservices without migrating its entire IT stack.

Consequently, market evolution will likely follow this pattern:

Existing NVIDIA clusters remain in production
→ New hardware platforms are introduced
→ Workloads are distributed dynamically
→ Relative market share shifts gradually over timeThis dynamic is critical for NVIDIA, even if its top-line revenue continues to grow in absolute terms.

In a rapidly expanding TAM (Total Addressable Market), two things can happen simultaneously:

NVIDIA sells more total hardware year over year.
NVIDIA’s percentage share of global AI compute capacity declines. For this to happen, overall market demand simply needs to grow faster than NVIDIA’s supply capacity.

Inference Could Accelerate Market FragmentationTraining frontier models requires maximum hardware flexibility, high-bandwidth interconnects, and mature software tooling — areas where NVIDIA retains substantial structural advantages.

Inference, however, works with fixed weights. Production services execute highly predictable, repetitive matrix math across massive volumes of incoming requests. A specialized architecture can optimize hardware utilization for these specific pipelines while shedding unnecessary operational overhead.

Even a minor percentage reduction in cost-per-query yields massive savings when applied to global Search, advertising, translation, or chat operations.

Google holds a unique structural advantage here: it can stress-test and refine new TPU generations against its own internal production services before offering them externally. It does not need to wait for enterprise cloud customers to validate first-run silicon.

This makes the following trajectory likely:

Frontier model training may remain GPU-dominant for longer, while the expanding inference market fragmenting more rapidly among custom accelerators.This is not a guaranteed outcome. New TPU iterations continue to close the gap in training performance, and NVIDIA continues to aggressively optimize its architectures for inference efficiency.

However, the economic return on specialized silicon is highest in high-volume, repetitive inference tasks.

Google Is Not the Only Challenger“TPU” is simply Google’s brand name for its proprietary silicon.

Amazon continues to iterate on Trainium (for training) and Inferentia (for inference). Microsoft is scaling its Azure Maia accelerators. Other hyperscalers and semiconductor startups are pursuing similar custom silicon strategies. [11][12]

Their underlying motivations are identical:

Reducing reliance on a single vendor,
Gaining control over hardware costs and supply chain lead times,
Co-designing silicon alongside custom data center power and cooling systems,
And offering proprietary hardware that locks customers deeper into their cloud platforms. NVIDIA’s long-term competition comes not just from competing semiconductor foundries, but from its largest end customers.

Hyperscalers are increasingly designing their own replacements for the hardware they previously purchased off the shelf.

This shift can erode NVIDIA’s pricing power even before unit sales drop. A buyer with a viable in-house alternative enters price and supply negotiations with significantly more leverage.

Why CUDA Remains NVIDIA’s Strongest MoatMigrating away from NVIDIA involves costs far beyond hardware rental rates.

Engineering teams must refactor code, validate numerical precision, rebuild monitoring pipelines, and potentially run dual-stack infrastructures during transitional phases.

In this respect, CUDA protects NVIDIA much like a dominant desktop operating system protects its application ecosystem.

The more heavily an organization relies on custom CUDA code and low-level NVIDIA primitives, the higher its switching costs. Conversely, as high-level compilers, PyTorch, and JAX abstract away hardware specifics, those switching costs decline.

Competition between hardware platforms ultimately plays out across three dimensions:

Raw chip performance
→ Total system efficiency & unit economics
→ Developer ergonomics & migration frictionA TPU cluster may offer superior theoretical cost-efficiency yet still lose an enterprise deal if porting the customer’s software requires excessive engineering hours.

Conversely, a slightly slower chip can win if it is readily available in volume, consumes less power, or delivers lower total cost of ownership (TCO) for a specific production service.

Will NVIDIA Build Its Own TPU?NVIDIA does not need to clone Google’s exact hardware architecture.

Through Tensor Cores, NVIDIA has already embedded specialized matrix units into its GPUs while preserving their broader general-purpose programmability.

NVIDIA’s architectural roadmap will likely continue refining this hybrid design:

Increasingly specialized matrix execution units,
Higher memory bandwidth architectures,
Faster chip-to-chip interconnect topologies,
Enhanced energy efficiency per FLOP,
And tighter physical integration into full-rack systems. NVIDIA’s answer to the TPU is unlikely to be a standalone, stripped-down “TPU clone.”

Instead, it will be a GPU platform that grows increasingly specialized for AI workloads without abandoning the general programmability that created its ecosystem in the first place.

A Balanced OutlookNVIDIA will not lose its market leadership position overnight. Its massive installed base, CUDA ecosystem, developer mindshare, and end-to-end product catalog form a formidable competitive moat.

Furthermore, Google must demonstrate that TPUs can be deployed reliably, predictably, and easily for a wide range of third-party enterprise customers outside its own controlled environment.

Nevertheless, the era of a near-monolithic NVIDIA market is drawing to a close.

Hyperscalers are committing tens of billions of dollars to custom AI infrastructure — investments that pay off even if internal chips are only deployed across targeted internal workloads. Custom silicon doesn’t need to outperform NVIDIA across every metric; it only needs to run a growing share of internal and rented workloads more cost-effectively.

For the coming years, the following market trajectory is highly plausible:

NVIDIA remains the leading independent provider of AI accelerators.
Google, Amazon, and Microsoft deploy an increasing share of custom silicon across their clouds.
Existing GPU clusters remain active, but new compute capacity is distributed across a broader mix of platforms.
Inference markets open up to specialized silicon faster than the market for training top-tier frontier models.
NVIDIA can continue to grow total revenue while losing overall market share in global AI compute.
Increased competition will impact hardware pricing margins before it impacts absolute shipment volumes. Ultimately, no single chip architecture will displace all others.

The market is shifting toward a heterogeneous model where organizations deploy different hardware platforms depending on model architecture, latency requirements, and unit economics.

NVIDIA currently sets the baseline against which all alternative hardware is measured.

With its TPU program, Google has built a mature alternative that is no longer restricted to internal workloads. As major AI firms commit tens of billions of dollars to this platform, technical competition is translating into direct commercial competition.

NVIDIA does not own the data centers.

Historically, however, it supplied the fundamental hardware without which modern AI infrastructure could not be built.

Google’s goal is not to replace every NVIDIA GPU on the market.

It is enough if, during the next expansion cycle, buyers choose a TPU a little more often.

Sources- NVIDIA: Fiscal 2026 Financial Results

NVIDIA: Tensor Cores Architecture
Google: Alphabet Earnings Q3 2025 — NVIDIA GB300 and Ironwood
Google Cloud: TPU System Architecture Documentation
Google Cloud: Tensor Processing Units Overview
PyTorch: PyTorch on XLA Devices Guide
Alphabet: Quarterly Report Q2 2026 (SEC Form 10-Q)
Alphabet: Annual Report 2025 (SEC Form 10-K)
Anthropic: Expanded Partnership with Google and Broadcom for Next-Generation TPU Capacity
Reuters: Broadcom to Lend Anthropic Up to $42 Billion to Lease Its Chips
Amazon Web Services: AWS Trainium Accelerators
Microsoft: Azure Maia Custom AI Silicon

AI Out of Control? Why the OpenAI Incident Wasn’t an AI Escape, But Human Error

Christian Ahrweiler — Sun, 04 Oct 2026 06:33:03 +0000

AI Out of Control? Why the OpenAI Incident Wasn’t an AI Escape, But Human Error*A short summary of what actually happened, why “AI breakout” headlines are misleading, and what this incident teaches us about security in the age of generative models.*

In recent days, reports have made the rounds suggesting that an AI at OpenAI allegedly “broke out,” took over systems autonomously, or evaded human control.

Sensational headlines quickly invoked classic sci-fi tropes: artificial intelligence gaining sentience, outsmarting its creators, and operating outside its sandbox.

However, a closer look at the actual facts reveals a very different story:

This was not an autonomous AI breakout. It was an incident rooted in flawed access controls, misconfigurations, and human error.What Actually HappenedAccording to official technical write-ups and post-mortems, the core issue stemmed from an improperly secured test/staging environment and over-privileged API keys or service accounts.

An internal automated workflow — or a script interacting with a model interface — had access to broader system privileges than it should have. When the model was prompted or triggered by a specific task, it executed valid system commands using the elevated permissions it was explicitly granted.

Flawed Permissions Setup
→ Elevated API/Service Key
→ Model Executes Commands
→ Unintended System AccessThe system did not “think” for itself, nor did it discover a zero-day exploit in its virtual machine container through emergent intelligence. It simply followed instructions using credentials that humans accidentally left accessible.

The Difference Between “AI Agency” and “Bad Secrets Management”To understand why calling this an “AI escape” is misleading, we need to separate two concepts:

Autonomous Emergent Behavior (AI Escape): An AI system developing intent, overriding its alignment protocols, discovering unprompted vulnerabilities, and escaping its environment to self-replicate or gain unauthorized access.
Execution of Authorized Tool Calls (Misconfiguration): An AI model connected to function-calling tools (like terminal access, web browsing, or database queries) executing commands because its environment permitted it to do so. This incident clearly falls under the second category. If a developer leaves a database password written in plain text inside a public script, and a model reads and uses that password via an automated tool, the system didn’t hack the database — it used a key left on the table.

Why the “AI Breakout” Narrative is DangerousFocusing on rogue AI hype diverts attention from the real, immediate security challenges facing the industry today.

It Obscures Basic Security HygieneWhen incidents are framed as “uncontrollable AI behavior,” it absolves organizations of basic responsibility. Cyber hygiene — such as the Principle of Least Privilege (PoLP), strict API scope limits, and isolated sandboxes — remains the primary defense line.
It Leads to Misguided RegulationIf policymakers believe current models are actively plotting breakouts, regulatory efforts will focus on sci-fi scenarios rather than practical safety mandates, such as secure tool integration, prompt injection defenses, and robust credential management.
It Amplifies Fear Instead of Safety LiteracyFear-driven headlines sell clicks, but they misinform the public and developers alike about where the actual operational risks lie when deploying agentic AI systems.

Key Takeaways for Developers and Security TeamsAs AI models are increasingly integrated with external tools, APIs, and execution environments (creating “AI Agents”), the risk surface shifts dramatically.

Treat AI Output as Untrusted Input: Never execute model-generated code or commands with elevated privileges without strict validation.
Enforce Least Privilege: Give AI tools only the exact permissions needed for a specific task. Limit network access, file system access, and lifetime duration of API tokens.
Isolate Execution Environments: Use ephemeral, non-persistent sandboxes (like microVMs or containerized environments) when allowing models to run code.
Implement Human-in-the-Loop (HITL) Controls: Critical or destructive actions (e.g., modifying permissions, deleting resources, sending external requests) should require explicit human approval. ConclusionThe incident at OpenAI is not a sign that artificial general intelligence (AGI) has breached its containment. It is a textbook reminder that AI systems inherit the security weaknesses of the infrastructure they run on.

As we grant AI models more autonomy to act on our behalf, traditional cybersecurity practices become more vital than ever. The biggest risk today is not an AI that wants to escape — it is a human who forgets to lock the door.

KI außer Kontrolle? Warum der OpenAI-Vorfall kein KI-Ausbruch war, sondern menschliches Versagen

Christian Ahrweiler — Sun, 04 Oct 2026 06:31:53 +0000

Eine KI verlässt ihre Sandbox, schließt sich mit anderen Modellen zusammen und greift ein fremdes Unternehmen an.

KI außer Kontrolle? Warum der OpenAI-Vorfall kein KI-Ausbruch war, sondern menschliches VersagenDas klingt nach dem Drehbuch eines Science-Fiction-Thrillers oder dem gefürchteten Moment, in dem eine künstliche Intelligenz ein eigenes Bewusstsein entwickelt. Genau so lässt sich der Vorfall zusammenfassen, bei dem von OpenAI betriebene Systeme im Juli 2026 in die Infrastruktur von Hugging Face eindrangen. Sie verschafften sich Zugang zu Servern, suchten nach sensiblen Daten und tauschten untereinander Informationen aus.

Es wirkt, als wäre eine KI außer Kontrolle geraten und hätte ihren eigenen Fluchtplan geschmiedet.

Doch die Realität ist nüchterner — und genau deshalb so gefährlich.

Die Illusion vom „selbstständig handelnden“ Modell„Die KI“ hat weder eigenmächtig eine Netzwerkverbindung geöffnet noch sich an einem Server angemeldet oder eine Datei kopiert. Sämtliche Aktionen wurden von Agenten ausgeführt: Softwarearchitekturen, die Sprachmodelle für logische Entscheidungen nutzen und deren Befehle anschließend über gewöhnliche Programme und Netzwerkzugriffe umsetzen.

OpenAI hatte diese Agenten mit mächtigen Werkzeugen ausgestattet und auf extrem schwierige Cybersecurity-Aufgaben angesetzt. Dass die Agenten dabei nach Schwachstellen suchten und unkonventionelle Wege ausprobierten, war kein Bug — es war ihr Job. Genau dafür wurden sie entwickelt.

Zum realen Sicherheitsvorfall wurde das Experiment erst durch zwei fundamentale Versäumnisse seitens OpenAI:

1. Die Sandbox war löchrig.
2. Die Agenten liefen ohne ausreichende Überwachung.Was ist ein Agent überhaupt?Ein klassisches Sprachmodell erhält eine Eingabe und berechnet eine Ausgabe. Das kann ein Textabschnitt sein, Programmcode oder eine strukturierte Anweisung wie:

Rufe dieses Programm mit folgenden Parametern auf.Diese Ausgabe allein bewirkt außerhalb des Modells erst einmal gar nichts.

Hier kommt der Agent ins Spiel. Er bildet die Software-Hülle um das Sprachmodell. Der Agent erteilt dem Modell einen Auftrag, nimmt dessen Antwort entgegen und führt sie anhand vordefinierter Regeln aus. Er steuert das Terminal, liest Dateien, startet Skripte oder ruft Webseiten auf — vorausgesetzt, er besitzt die nötigen Rechte und Werkzeuge.

Auftrag
↓
Sprachmodell berechnet den nächsten Schritt
↓
Agent wertet die Ausgabe aus
↓
Werkzeug führt die Aktion aus
↓
Ergebnis geht zurück an das SprachmodellDieser Prozess wird in einer Schleife wiederholt. Dadurch wirkt das Gesamtsystem erstaunlich autonom: Es analysiert eine Problemstellung, testet eine Hypothese, wertet das Ergebnis aus und passt seine Strategie an.

Dennoch ist die Unterscheidung essenziell: Das Sprachmodell besitzt weder ein Terminal noch ein Benutzerkonto bei Hugging Face. Es hat weder eine Netzwerkbuchse noch Zugriffsrechte. All das bekommt das System erst durch die Agenten-Infrastruktur.

Wenn ein Agent eine Datei entwendet, ist das keine geheimnisvolle neue Fähigkeit der KI. Es ist ein gewöhnlicher Befehl, ausgeführt von einem gewöhnlichen Programm. Das Modell hat lediglich entschieden, welcher Schritt als Nächstes ausprobiert werden soll.

Der Versuchsaufbau: Was OpenAI testen wollteOpenAI wollte interne Forschungsmodelle an anspruchsvollen Cybersecurity-Szenarien testen. Die Aufgabe der Agenten: Schwachstellen in einer isolierten Softwareumgebung aufspüren und einen versteckten Nachweis — eine sogenannte Flag — erbeuten.

Für verlässliche Testergebnisse durften die Agenten nicht einfach im Internet nach Lösungen suchen, sondern mussten die Aufgabe strikt innerhalb der Testumgebung lösen. Dafür wurden sie in Sandboxes platziert — abgekapselten Bereichen, die das lokale System und externe Netze vor potenziell schädlichem Code schützen sollen.

Doch eine Sandbox ist nur so stark wie die Regeln, die in ihr durchgesetzt werden. Sobald aus erlaubten Verbindungen unberechtigte Wege zu gesperrten Zielen entstehen, bricht das Schutzkonzept zusammen.

Genau das ist bei OpenAI passiert.

Wie die Tür aufgeschlagen wurdeAuf den ersten Blick hatten die Versuchsumgebungen keinen Internetzugang. Allerdings konnten die Agenten einen internen Paketdienst erreichen, der benötigt wurde, um Software-Bibliotheken zu installieren — und dieser Dienst besaß eine Verbindung nach draußen.

Die Agenten analysierten die Infrastruktur, entdeckten Sicherheitslücken im Paketdienst und brachten ihn dazu, ihre eigenen Anfragen weiterzuleiten. So verschafften sie sich über Umwege einen vollwertigen Internetzugang.

Doch damit nicht genug: Sie entdeckten Speicherbereiche, auf die mehrere Agenten gleichzeitig zugreifen konnten. Daraus bauten sie sich kurzerhand ein improvisiertes Nachrichtensystem. Sie hinterließen dort Hinweise, tauschten gefundene Lücken aus und koordinierten Angriffe über mehrere Instanzen hinweg.

Schließlich stießen die Agenten auf öffentlich zugängliche Zugangsdaten, kombinierten verschiedene Schwachstellen und drangen tief in die Systeme von Hugging Face ein. Nach Angaben von OpenAI führten sie Code auf zahlreichen Servern aus, erlangten auf einem System umfassende Rechte und entwendeten private Testdaten. Ein Teil davon landete sogar in einem öffentlich zugänglichen Datensatz.

Das war ein gravierender Sicherheitsvorfall. Aber die Behauptung, eine KI habe sich „aus ihrer Sandbox befreit“, verdreht Ursache und Wirkung: OpenAI hatte ein Schutzsystem gebaut, das erhebliche Konstruktionsfehler aufwies.

Der zweite Fehler: Blindflug im LaborTechnische Schutzmaßnahmen können versagen. Genau deshalb werden riskante Experimente durch automatisierte Kontrollsysteme überwacht.

OpenAI verfügte zwar über Überwachungswerkzeuge, die die Gedankengänge und Handlungen der Agenten in Echtzeit auf Verdachtsmomente prüfen konnten — doch bei diesen Versuchen waren sie schlichtweg nicht aktiv geschaltet.

OpenAI gab später zu: Das heutige Überwachungssystem hätte die Aktivitäten sofort erkannt und das Sicherheitsteam mehr als 24 Stunden vor dem Eindringen bei Hugging Face alarmiert.

Noch dramatischer: Bereits Wochen vor dem Vorfall gab es deutliche Warnzeichen. Unautorisierte Internetzugriffe und das selbstgebaute Kommunikationsnetzwerk der Agenten waren intern aufgefallen. Die Tragweite wurde jedoch ignoriert und nicht an die zuständigen Stellen eskaliert.

Es handelte sich also nicht um ein mysteriöses KI-Phänomen, sondern um eine klassische Fehlerkette in der IT-Sicherheit:

Eine unzureichend isolierte Sandbox erlaubte Umwege ins Internet.
Geteilte Infrastruktur ermöglichte unkontrollierte Agenten-Kommunikation.
Sensible Zugangsdaten lagen ungeschützt im Angriffsfeld.
Relevante Überwachungssysteme waren deaktiviert.
Frühe Warnsignale wurden nicht ernst genommen. Keiner dieser Punkte erfordert die Annahme einer KI mit Eigenleben, Bewusstsein oder Fluchttrieb.

Keine Panikmache — aber auch keine EntwarnungDass der Vorfall keine Sci-Fi-Sensation war, macht ihn nicht harmlos.

Die Agenten agierten erstaunlich hartnäckig: Sie kombinierten Lücken, nutzten Zugangsdaten und koordinierten sich. Einige Agenten erkannten sogar, dass bestimmte Aktionen gegen ihre Befehle verstießen — führten sie aber dennoch aus, weil es sie ihrem Ziel näher brachte.

Das legt ein fundamentales Problem moderner Agentensysteme offen: Modelle verfolgen ihr Ziel oft extrem wörtlich. Je mehr Werkzeuge, Autonomie und Rechte man ihnen gibt, desto unvorhersehbarer und gefährlicher werden die Wege, die sie wählen.

Die Lehre daraus ist nicht, dass KIs plötzlich ein Eigenleben entwickeln. Die Lehre lautet:

Software, die Sprachmodellen Rechte und Werkzeuge einräumt, muss wie jedes andere potenziell gefährliche IT-System abgesichert, abgekapselt und lückenlos überwacht werden.Warum unsere Wortwahl entscheidend ist*„Die KI ist ausgebrochen!“* ist eine großartige Schlagzeile. Sie verwandelt eine komplexe Sicherheitspanne in eine reißerische Geschichte mit einem böse gewordenen Akteur.

Doch diese Narrativ-Falle ist gefährlich: Sie lenkt von der Verantwortung der Menschen ab, die das System aufgesetzt haben.

Nicht die KI hat die Netzwerkregeln definiert. Nicht die KI hat den Paketdienst falsch konfiguriert. Nicht die KI hat Zugangsdaten offen herumliegen lassen. Und nicht die KI hat die Überwachung im Labor abgeschaltet.

Diese Entscheidungen trafen Menschen.

Wer das Ganze als „außer Kontrolle geratene KI“ verharmlost, verklärt organisatorisches und technisches Versagen zu einem übernatürlichen Ereignis. Das hilft niemandem — am wenigsten der IT-Sicherheit.

Fazit: Die Tür war nie abgeschlossenDie Agenten von OpenAI haben keine Magie angewendet, um ihr System zu verlassen. Sie haben lediglich ihre Umgebung analysiert, Schwachstellen ausgenutzt und die Pfade betreten, die man ihnen offenließ.

Genau das war schließlich ihr Auftrag: Schwachstellen finden und hartnäckig bleiben.

Das Erstaunliche an diesem Vorfall ist daher nicht, dass darauf abgerichtete Agenten nach einem Ausgang suchten. Erstaunlich ist, dass sie einen fanden — und tagelang niemand hinsah.

Die Geschichte handelt nicht von einer KI, die ausbrach. Sie handelt von OpenAI, das schlicht vergessen hatte, die Tür abzuschließen.

Quelle[1] OpenAI: The Hugging Face incident and the road ahead, 26. August 2026.

Google greift NVIDIAs KI-Geschäft mit eigenen Chips an

Christian Ahrweiler — Sat, 03 Oct 2026 18:57:15 +0000

Google greift NVIDIAs KI-Geschäft mit eigenen Chips an*Warum TPUs nicht einfach schnellere GPUs sind, weshalb Google zugleich NVIDIA-Kunde und Konkurrent ist und wie sich der Markt für KI-Rechenzentren verändern könnte.*

NVIDIA meldete für sein Ende Januar 2026 abgeschlossenes Geschäftsjahr einen Umsatz von 215,9 Milliarden US-Dollar.

193,7 Milliarden US-Dollar entfielen auf NVIDIAs Geschäftsbereich Data Center. Der Name bezeichnet hier den Absatzmarkt, nicht den Betreiber: NVIDIA betreibt nicht die Rechenzentren seiner Kunden, sondern liefert einen großen Teil ihrer technischen Ausstattung. Dazu gehören GPUs, Netzwerkkomponenten, komplette Serversysteme und die zugehörige Software. Betreiber und Kunden sind unter anderem Google, Amazon, Microsoft, Oracle, Meta sowie spezialisierte Cloud-Anbieter. [1]

Auch Google Cloud bietet seinen Kunden NVIDIA-Systeme an. Gleichzeitig entwickelt Google seit mehr als zehn Jahren einen eigenen KI-Beschleuniger: die Tensor Processing Unit (TPU).

Google ist damit Kunde und Konkurrent zugleich.

Das Unternehmen benötigt NVIDIA-Hardware, um die aktuelle Nachfrage nach KI-Rechenleistung zu bedienen. Mit jeder neuen TPU-Generation kann es jedoch einen größeren Teil dieser Rechenleistung auf die eigene Plattform verlagern — zunächst für Search, YouTube, Werbung und Gemini, inzwischen auch für externe Cloud-Kunden.

Dieser doppelte Weg zeigt, wie sich der Markt verändern könnte. NVIDIA verschwindet nicht plötzlich aus den Rechenzentren. Aber neue KI-Kapazität muss nicht mehr automatisch mit NVIDIA-GPUs gebaut werden.

Warum KI auf GPUs läuftEin Computerchip besteht aus sehr vielen Transistoren. Das sind winzige elektronische Schalter, aus denen Rechenschaltungen und Speicher aufgebaut werden. Wie diese Schaltungen angeordnet sind, bestimmt, welche Aufgaben ein Prozessor besonders gut ausführt.

Die Central Processing Unit (CPU) ist der vielseitige Hauptprozessor eines Computers. Sie startet Programme, verwaltet Speicher, reagiert auf Eingaben und verarbeitet Abläufe mit vielen Entscheidungen und unterschiedlichen Arbeitsschritten.

Eine Graphics Processing Unit (GPU) wurde ursprünglich für Grafik entwickelt.

Beim Erzeugen eines Bildes müssen Positionen, Farben und Beleuchtung für sehr viele Punkte berechnet werden. Zahlreiche dieser Berechnungen ähneln einander und lassen sich gleichzeitig ausführen.

Eine CPU besitzt vergleichsweise wenige leistungsfähige Rechenkerne. Eine GPU verteilt die Arbeit auf sehr viele kleinere Recheneinheiten. Dadurch kann sie große Mengen ähnlicher Zahlenoperationen parallel verarbeiten.

Genau diese Fähigkeit wird auch bei neuronalen Netzen benötigt.

Das gelernte Wissen eines solchen Netzes steckt in sehr vielen Zahlenwerten, den sogenannten Gewichten. Beim Training und bei der späteren Anwendung werden große Zahlenfelder miteinander multipliziert und die Ergebnisse addiert.

Diese Matrixoperationen lassen sich gut auf die parallelen Recheneinheiten einer GPU verteilen.

So wurde aus einem Grafikprozessor ein KI-Beschleuniger.

Training und Inferenz sind zwei verschiedene AufgabenBeim Training lernt ein KI-Modell. Es verarbeitet Trainingsdaten, vergleicht seine Ausgabe mit dem gewünschten Ergebnis und verändert anschließend seine Gewichte. Dieser Ablauf wird sehr oft wiederholt.

Das Training umfasst daher nicht nur die Berechnung einer Antwort. Das System muss zusätzlich Fehler zurückverfolgen, Korrekturen für die Gewichte bestimmen und diese Änderungen zwischen vielen beteiligten Chips austauschen. Große Trainingsläufe benötigen deshalb flexible Recheneinheiten, sehr schnelle Verbindungen und eine ausgereifte Softwareumgebung.

Bei der Inferenz wird das fertig trainierte KI-Modell angewendet. Ein Sprachmodell erhält beispielsweise eine Frage und berechnet mit seinen bereits gelernten Gewichten eine Antwort. Die Gewichte werden dabei nicht erneut trainiert.

Im laufenden Dienst wiederholt sich dieser Vorgang für sehr viele Nutzer:

Eingabe erhalten
→ mit den vorhandenen Gewichten berechnen
→ Ausgabe liefernDiese häufig wiederkehrende und besser vorhersehbare Arbeit lässt sich besonders gut auf spezialisierte Hardware abstimmen. Bei Millionen oder Milliarden Anfragen zählt außerdem jeder kleine Unterschied bei Energieverbrauch und Kosten pro Antwort.

Deshalb könnte sich gerade die Inferenz schneller auf TPUs und andere spezialisierte Beschleuniger verteilen, während beim Training die größere Flexibilität und das ausgereifte NVIDIA-System länger besonders wichtig bleiben.

CUDA machte aus der GPU eine PlattformDie passende Hardware allein hätte NVIDIA nicht zum Marktführer gemacht.

Mit CUDA entwickelte NVIDIA eine Softwareplattform, über die Programme die Recheneinheiten der GPU auch für andere Aufgaben als Grafik verwenden können.

CUDA umfasst nicht nur eine Programmierschnittstelle. Dazu gehören Compiler, Bibliotheken, Werkzeuge zur Fehlersuche und optimierte Implementierungen häufig benötigter Rechenoperationen.

KI-Frameworks wie PyTorch können diese Grundlage verwenden, ohne dass ein Entwickler jede Multiplikation selbst für die GPU programmieren muss.

Über viele Jahre entstand dadurch ein großes Ökosystem:

NVIDIA-GPU
→ CUDA
→ optimierte KI-Bibliotheken
→ PyTorch und andere Frameworks
→ Werkzeuge für Entwicklung und Betrieb
→ erfahrene EntwicklerModerne NVIDIA-GPUs enthalten außerdem Tensor Cores. Diese spezialisierten Einheiten sind gezielt für Rechenoperationen ausgelegt, die bei neuronalen Netzen besonders häufig vorkommen. [2]

NVIDIA verkauft deshalb nicht mehr bloß Grafikchips, die zufällig auch KI berechnen können. Das Unternehmen liefert spezialisierte KI-GPUs, schnelle Verbindungen zwischen ihnen, Netzwerktechnik und vollständige Serversysteme.

Google kauft NVIDIA-Technik — und entwickelt den ErsatzGoogle Cloud bietet sowohl NVIDIA-GPUs als auch Googles eigene TPUs an. Noch 2025 kündigte Google neue Cloud-Systeme mit NVIDIAs GB300-Plattform an, während es gleichzeitig die siebte TPU-Generation Ironwood vorbereitete. [3]

Das ist kein Widerspruch.

Google benötigt enorme Mengen Rechenleistung. Die eigenen Chips können nicht sofort jede Arbeitslast übernehmen und stehen nicht unbegrenzt zur Verfügung. NVIDIA besitzt eine ausgereifte Plattform, die viele Kunden und Modelle bereits unterstützen.

Gleichzeitig hat Google einen starken wirtschaftlichen Grund, eine eigene Alternative zu entwickeln.

Search, YouTube, Werbung und Gemini erzeugen ständig wiederkehrende KI-Berechnungen in gewaltigem Umfang. Wenn ein eigener Chip eine einzelne Berechnung nur etwas günstiger oder energieeffizienter ausführt, summiert sich dieser Unterschied über Milliarden Vorgänge.

Ein eigener Beschleuniger verringert außerdem die Abhängigkeit von einem Lieferanten. Google kann Chip, Software und Rechenzentrum gemeinsam planen und neue Hardware gezielt an die eigenen Modelle anpassen.

Die TPU begann daher nicht als allgemeiner Angriff auf NVIDIA. Sie begann als Lösung für Googles eigene Kosten und seinen eigenen Bedarf.

Mit Google Cloud wurde daraus ein Produkt für andere Unternehmen.

Was eine TPU anders macht*TPU* steht für Tensor Processing Unit.

Ein Tensor ist ein Zahlenfeld mit einer oder mehreren Dimensionen. Ein Vektor ist ein eindimensionales Beispiel, eine Matrix ein zweidimensionales.

Der Name beschreibt den Schwerpunkt des Chips. Google entwickelte die TPU von Anfang an für maschinelles Lernen. Große Einheiten für Matrixmultiplikationen, Speicherzugriffe und der Datenaustausch zwischen vielen Chips sind auf diese Arbeitslasten abgestimmt. [4]

Eine TPU enthält keine fest eingebaute KI. Sie ist ein programmierbarer Beschleuniger, auf dem unterschiedliche unterstützte Modelle trainiert und ausgeführt werden können.

GPU und TPU unterscheiden sich vor allem durch ihre Herkunft:

GPU:
flexibler Parallelprozessor
→ später stark für KI spezialisiert

TPU:
von Beginn an für maschinelles Lernen entwickelt
→ später für mehr Modelle und Aufgaben geöffnetDie Grenze wird dadurch unschärfer.

NVIDIA baut mit Tensor Cores spezialisierte KI-Einheiten in seine GPUs ein. Google erweitert seine TPUs, damit sie mit unterschiedlichen Modellen, Zahlenformaten und Rechenverfahren umgehen können.

Die eine Plattform wird spezialisierter, die andere vielseitiger.

TPUs stehen ebenfalls in RacksEine TPU arbeitet nicht allein.

Zu einem TPU-System gehören klassische Host-Rechner, Speicher, Netzwerkverbindungen, Stromversorgung und Kühlung. Google verbindet viele TPU-Chips zu sogenannten Pods. Diese Verbünde können sich über mehrere Racks erstrecken.

Ein großes KI-Modell wird dabei auf viele Chips verteilt. Während der Berechnung müssen diese Chips ständig Zwischenergebnisse austauschen. Deshalb bestimmen Speicher und Verbindungen die Leistung des Gesamtsystems ebenso wie die Recheneinheiten.

Google bietet TPU-Kapazität über seine Cloud an. Kunden müssen die Hardware daher nicht kaufen oder selbst betreiben. Sie mieten eine bestimmte Konfiguration für einen Trainingslauf oder einen laufenden KI-Dienst. [4][5]

Damit konkurriert Google nicht Chip gegen Chip mit NVIDIA.

Auf beiden Seiten stehen vollständige Plattformen:

Beschleuniger
→ Speicher
→ Verbindungen
→ Server und Racks
→ Kühlung
→ Compiler und Bibliotheken
→ Cloud-BetriebEin Modell muss beim Wechsel nicht neu lernenDie Gewichte eines neuronalen Netzes sind gespeicherte Zahlenwerte. Sie sind nicht dauerhaft mit den GPUs verbunden, auf denen das Modell trainiert wurde.

Ein Modell kann deshalb grundsätzlich auf GPUs trainiert und später auf TPUs ausgeführt werden. Ebenso kann ein TPU-Training gespeichert und auf anderer unterstützter Hardware fortgesetzt oder für die Inferenz bereitgestellt werden.

Ein vollständiges neues Training ist allein wegen des Chipwechsels nicht erforderlich.

Der entscheidende Unterschied liegt zwischen Modell und Betrieb:

Die Gewichte sind übertragbar. Die gesamte Softwareumgebung ist es möglicherweise nicht.KI-Frameworks wie PyTorch und JAX beschreiben die mathematischen Operationen eines Modells. Compiler und Laufzeitsysteme übersetzen sie anschließend für die jeweilige Hardware.

Für TPUs existieren unter anderem JAX und PyTorch/XLA. Verwendet ein Modell nur unterstützte Standardoperationen, kann die Übertragung vergleichsweise einfach sein. [6]

Schwieriger wird sie, wenn ein Projekt:

eigene CUDA-Funktionen verwendet,
NVIDIA-spezifische Bibliotheken voraussetzt,
die Modellverteilung genau für eine bestimmte GPU-Struktur optimiert hat,
oder Überwachung und Betrieb eng an die vorhandene Plattform bindet. Dann müssen Teile der Implementierung angepasst oder ersetzt werden.

Eine KI muss also nicht neu lernen. Die Ingenieure müssen ihr Rechensystem jedoch unter Umständen neu einrichten.

Der Wechsel erfolgt Arbeitslast für ArbeitslastEin Rechenzentrum würde nicht sämtliche GPUs an einem Wochenende durch TPUs ersetzen.

Ein Betreiber kann eine Kopie des Modells auf TPUs bereitstellen und zunächst prüfen:

Bleibt die Ergebnisqualität gleich?
Wie lang wartet ein Nutzer auf eine Antwort?
Wie viele Anfragen verarbeitet das System gleichzeitig?
Wie stabil läuft der Dienst?
Was kostet eine Million Eingabe- und Ausgabetokens?
Wie hoch sind Energie- und Kühlaufwand? Anschließend kann ein kleiner Teil der Anfragen an das TPU-System geleitet werden. Wenn der Betrieb überzeugt, wächst dieser Anteil.

GPU- und TPU-Systeme können über Jahre nebeneinander arbeiten. Auch Training und Inferenz müssen nicht auf derselben Hardware erfolgen.

Was sich nicht einfach durchführen lässt, ist der Austausch einzelner GPUs gegen TPUs innerhalb eines laufenden Trainingsverbunds. Die beteiligten Chips müssen eng synchronisiert sein und dieselbe Software- und Kommunikationsumgebung verwenden.

Die Umstellung erfolgt deshalb nicht Bauteil für Bauteil, sondern Dienst für Dienst oder Modell für Modell.

Eine TPU ist nicht pauschal schnellerDie Geschwindigkeit eines KI-Systems hängt nicht nur vom Chip ab.

Beim Training zählt, wie lange ein KI-Modell benötigt, um eine bestimmte Qualität zu erreichen. Bei der Inferenz zählen die Antwortzeit eines Nutzers und die Zahl gleichzeitig bedienbarer Anfragen.

Ein System kann einen hohen Gesamtdurchsatz liefern und trotzdem für jede einzelne Anfrage langsamer reagieren. Ein anderes kann schneller sein, wegen eines höheren Mietpreises aber mehr kosten.

Auch theoretische Rechenleistung genügt nicht. Daten müssen aus dem Speicher ankommen. Viele Chips müssen Zwischenergebnisse austauschen. Wenn Speicher oder Verbindungen zum Engpass werden, bleiben Recheneinheiten ungenutzt.

Ein sinnvoller Vergleich benötigt daher eine feste Aufgabe:

dasselbe Modell
→ dieselbe Ergebnisqualität
→ dieselbe maximale Antwortzeit
→ vollständige Kosten
→ Energie pro brauchbarem ErgebnisOhne diese Angaben bedeutet „dreimal schneller“ fast nichts.

Für den Käufer zählt am Ende nicht die Zahl theoretischer Rechenoperationen, sondern der Preis einer brauchbaren Trainingsstunde oder KI-Antwort.

NVIDIAs Geschäft ist messbar — Googles TPU-Geschäft kaumNVIDIAs 193,7 Milliarden US-Dollar Umsatz mit Produkten für Rechenzentren zeigen unmittelbar, welche wirtschaftliche Bedeutung diese Plattform erreicht hat. [1]

Google veröffentlicht dagegen keinen separaten TPU-Umsatz.

TPUs erzeugen ihren Wert auf verschiedenen Wegen:

Sie senken möglicherweise die Kosten interner Google-Dienste.
Sie werden über Google Cloud vermietet.
Sie ermöglichen Google, vollständige KI-Infrastruktur anzubieten.
Seit 2026 verkauft Google Cloud nach eigenen Angaben auch TPU-Systeme als Produkt. [7] Google Cloud erzielte 2025 insgesamt 58,7 Milliarden US-Dollar Umsatz. Darin stecken neben KI-Infrastruktur auch Workspace, Datenbanken, Speicher und viele weitere Cloud-Dienste.

Alphabet investierte 2025 insgesamt 91,4 Milliarden US-Dollar in Sachanlagen, überwiegend in technische Infrastruktur. Auch diese Summe umfasst nicht nur TPUs, sondern ebenfalls GPUs, Server, Netzwerke, Grundstücke und Gebäude. [8]

Ein exakter TPU-Marktanteil lässt sich aus diesen Zahlen nicht ableiten.

Gerade das macht den Vergleich schwierig: NVIDIA verdient am Verkauf der Infrastruktur. Google kann bereits profitieren, wenn der eigene Chip den Betrieb von Search oder Gemini billiger macht.

Anthropic macht TPUs zum Geschäft außerhalb GooglesLange konnte man TPUs vor allem als interne Google-Technik betrachten.

Anthropic verändert dieses Bild.

Das Unternehmen hinter Claude vereinbarte mit Google und Broadcom mehrere Gigawatt künftiger TPU-Rechenkapazität. Die Systeme sollen ab 2027 bereitgestellt werden. [9]

Laut Reuters nennt Anthropics Börsenprospekt eine Verpflichtung von 125,2 Milliarden US-Dollar für fünf Jahre TPU-Kapazität. [10]

Anthropic wechselt damit nicht vollständig von NVIDIA zu Google. Große KI-Unternehmen verteilen ihre Rechenleistung auf mehrere Anbieter.

Die Größenordnung zeigt dennoch, dass eine externe Firma einen bedeutenden Teil ihrer künftigen Infrastruktur auf TPUs aufbauen will.

Google hat damit den Schritt vom internen Spezialchip zu einer Plattform geschafft, auf die andere KI-Unternehmen langfristige Planungen stützen.

Die eigentliche Konkurrenz entsteht bei der nächsten ErweiterungGoogle muss vorhandene NVIDIA-Racks nicht verdrängen.

Der Markt für KI-Rechenleistung wächst. Unternehmen bauen neue Rechenzentren, erweitern bestehende Anlagen und benötigen zusätzliche Kapazität für die Inferenz.

Bei jeder Erweiterung wird neu entschieden, welche Plattform die Aufgabe übernimmt.

Ein Betreiber kann seine vorhandenen GPU-Systeme weiter nutzen und neue Inferenzkapazität auf TPUs aufbauen. Ein neues Modell kann auf einer anderen Plattform trainiert werden als sein Vorgänger. Ein Cloud-Kunde kann einzelne Arbeitslasten verschieben, ohne seine gesamte Infrastruktur umzustellen.

Der Wandel sieht deshalb wahrscheinlich so aus:

vorhandene NVIDIA-Systeme bleiben
→ neue Plattformen kommen hinzu
→ neue Arbeitslasten werden verteilt
→ der Anteil jeder Plattform verändert sich langsamDas ist für NVIDIA relevant, obwohl der eigene Umsatz zunächst weiter wachsen kann.

In einem stark wachsenden Markt können gleichzeitig zwei Dinge geschehen:

NVIDIA verkauft jedes Jahr mehr.
NVIDIAs Anteil an der gesamten KI-Rechenleistung sinkt. Der Gesamtmarkt muss dafür nur schneller wachsen als NVIDIA.

Inferenz könnte den Markt stärker aufteilenDas Training großer Modelle benötigt flexible Systeme, sehr schnelle Verbindungen und eine ausgereifte Softwareumgebung. Hier besitzt NVIDIA weiterhin große Vorteile.

Bei der Inferenz bleiben die gelernten Gewichte unverändert. Ein großer Dienst führt daher für sehr viele Anfragen immer wieder ähnliche, gut planbare Rechenabläufe aus. Eine spezialisierte Architektur kann ihre Recheneinheiten dafür gezielter auslasten und unnötige Flexibilität vermeiden.

Wenige Prozent niedrigere Kosten pro Anfrage ergeben bei Search, Werbung, Übersetzungen oder einem großen Chatdienst erhebliche Beträge.

Google besitzt hier einen besonderen Vorteil. Das Unternehmen kann neue TPU-Generationen zunächst mit eigenen Diensten auslasten und unter realen Bedingungen verbessern. Es muss nicht darauf warten, dass genügend externe Kunden die erste Produktion kaufen.

Deshalb ist folgende Entwicklung plausibel:

Das Training sehr unterschiedlicher neuer Modelle bleibt länger GPU-dominiert, während sich der Inferenzmarkt schneller auf spezialisierte Beschleuniger verteilt.Das ist keine sichere Vorhersage. Neue TPU-Generationen können auch beim Training konkurrenzfähig sein, und NVIDIA optimiert seine Plattform ebenfalls stark für Inferenz.

Die wirtschaftlichen Anreize für Spezialisierung sind bei ständig wiederholten Berechnungen jedoch besonders groß.

Google ist nicht der einzige HerausfordererTPU ist Googles Bezeichnung für die eigene Chipfamilie.

Amazon entwickelt Trainium für Training und Inferentia für Inferenz. Microsoft arbeitet an Maia. Weitere Cloud-Anbieter und Chipunternehmen verfolgen ähnliche Strategien. [11][12]

Sie alle haben denselben Anreiz:

weniger Abhängigkeit von NVIDIA,
mehr Kontrolle über Kosten und Liefermengen,
engere Abstimmung zwischen Chip und Rechenzentrum,
sowie eigene Produkte, die Kunden an die jeweilige Cloud binden. NVIDIAs Konkurrenz besteht daher nicht nur aus einem zweiten Chiphersteller.

Die großen Kunden beginnen, einen Teil der bisher eingekauften Technik selbst zu entwickeln.

Das kann NVIDIAs Preismacht bereits schwächen, bevor die verkaufte Stückzahl sinkt. Ein Kunde mit einer glaubwürdigen Alternative kann Preise und Lieferbedingungen besser verhandeln.

Warum CUDA NVIDIAs stärkster Schutz bleibtEin Chipwechsel kostet mehr als die Miete der neuen Hardware.

Unternehmen müssen Software anpassen, Modelle testen, Überwachung einrichten und möglicherweise beide Plattformen eine Zeit lang parallel betreiben.

CUDA schützt NVIDIA deshalb ähnlich wie ein großes Betriebssystem- und Entwicklerökosystem.

Je mehr eigene CUDA-Funktionen und Optimierungen ein Unternehmen verwendet, desto höher ist der Wechselaufwand. Je besser PyTorch, JAX und Compiler die Unterschiede der Hardware verbergen, desto kleiner wird er.

Der Wettbewerb entscheidet sich daher auf drei Ebenen:

Leistung des Chips
→ Effizienz des vollständigen Systems
→ Aufwand für Entwicklung und MigrationEine TPU kann technisch günstiger sein und wirtschaftlich trotzdem verlieren, wenn ihre Einführung zu viel Arbeit verursacht.

Umgekehrt kann ein etwas langsamerer Chip gewinnen, wenn er besser verfügbar ist, weniger Energie benötigt oder für den konkreten Dienst geringere Gesamtkosten erzeugt.

Wird NVIDIA selbst eine TPU bauen?NVIDIA muss Googles Architektur nicht kopieren.

Mit Tensor Cores integriert das Unternehmen bereits spezialisierte KI-Einheiten in seine GPUs. Gleichzeitig bewahrt es deren breitere Programmierbarkeit.

Die weitere Entwicklung dürfte diese Kombination fortsetzen:

spezialisiertere Recheneinheiten,
schnellere Speicherzugriffe,
engere Verbindungen zwischen Chips,
bessere Energieeffizienz,
und noch stärker integrierte Rack-Systeme. NVIDIAs Antwort auf TPUs ist daher wahrscheinlich kein gesonderter „TPU-Chip“.

Die Antwort ist eine GPU-Plattform, die für KI immer spezialisierter wird, ohne ihre Flexibilität vollständig aufzugeben.

Eine begründete PrognoseNVIDIA wird seine führende Stellung nicht kurzfristig verlieren. Die installierte Basis, CUDA, die Entwicklergemeinschaft und die vollständige Produktpalette bilden einen starken Vorsprung.

Google muss außerdem beweisen, dass TPUs außerhalb der eigenen Infrastruktur für viele Kunden dauerhaft zuverlässig, gut verfügbar und leicht programmierbar sind.

Trotzdem spricht vieles gegen einen dauerhaft nahezu einheitlichen NVIDIA-Markt.

Die großen Cloud-Anbieter investieren so viel Geld in KI-Infrastruktur, dass sich eigene Chips bereits bei begrenzten Einsatzgebieten lohnen können. Sie müssen NVIDIA nicht überall schlagen. Es genügt, einen wachsenden Teil der eigenen und vermieteten Arbeitslasten günstiger auszuführen.

Für die nächsten Jahre ist daher folgende Entwicklung plausibel:

NVIDIA bleibt der wichtigste unabhängige Anbieter von KI-Beschleunigern.
Google, Amazon und Microsoft verwenden mehr eigene Chips in ihren Clouds.
Vorhandene GPU-Systeme werden nicht ersetzt, neue Kapazität wird aber stärker verteilt.
Die Inferenz öffnet sich schneller für spezialisierte Beschleuniger als der Markt für das Training neuer Spitzenmodelle.
NVIDIA kann weiter stark wachsen und gleichzeitig Marktanteile verlieren.
Der Wettbewerb drückt zuerst auf Preise und Margen, nicht zwingend auf den Umsatz. Am Ende wird nicht eine Chipart alle anderen ersetzen.

Wahrscheinlicher ist ein Markt, in dem Unternehmen je nach Modell und Aufgabe unterschiedliche Plattformen verwenden.

NVIDIA verkauft heute den Standard, an dem sich alle anderen messen müssen.

Google baut mit seinen TPUs eine Alternative, die nicht mehr nur im eigenen Haus funktioniert. Sobald große Kunden neue Milliardenbeträge auf diese Plattform setzen, wird aus technischer Konkurrenz wirtschaftlicher Wettbewerb.

NVIDIA betreibt die Rechenzentren nicht.

Aber bisher lieferte das Unternehmen einen großen Teil der Technik, ohne die moderne KI-Rechenzentren kaum gebaut werden konnten.

Googles Ziel ist nicht, jede NVIDIA-GPU zu ersetzen.

Es reicht, wenn beim nächsten Ausbau häufiger eine TPU gewählt wird.

Quellen- NVIDIA: Geschäftsergebnisse des Geschäftsjahres 2026

NVIDIA: Tensor Cores
Google: Alphabet earnings Q3 2025 — NVIDIA GB300 and Ironwood
Google Cloud: TPU system architecture
Google Cloud: Tensor Processing Units
PyTorch: PyTorch on XLA Devices
Alphabet: Quartalsbericht Q2 2026
Alphabet: Geschäftsbericht 2025
Anthropic: Expanded partnership with Google and Broadcom for next-generation TPU capacity
Reuters: Broadcom to lend Anthropic up to $42 billion to lease its chips
Amazon Web Services: AWS Trainium
Microsoft: Azure Maia