Die ungenutzte Rechenleistung um uns herum

Manchmal beginnt eine grosse Infrastrukturfrage mit einem ganz kleinen Bild: Ein Smartphone liegt nachts am Ladegerät. Der Laptop ist zugeklappt. Die Spielkonsole wartet im Wohnzimmer. Das Auto steht in der Garage. Überall steckt Rechenleistung, die bereits bezahlt ist, Strom bekommt und meistens nichts tut.

Gleichzeitig entstehen neue Rechenzentren, so gross wie Industrieanlagen. Hallen voller GPUs, Glasfaser, Transformatoren, Kühltechnik und Stromverträge. Wir bauen gerade eine neue Schicht digitaler Infrastruktur, die unser Schreiben, Suchen, Programmieren, Analysieren und irgendwann vielleicht auch Entscheiden tragen soll.

Was wäre, wenn ein kleiner Teil dieser Leistung nicht einfach verfallen würde? Nicht als wilde Fantasie, in der jedes Handy plötzlich ein Rechenzentrum ersetzt. Sondern als ernsthaftes Gedankenspiel: Könnte es eine Art Compute-Smart-Grid geben, in dem Geräte freiwillig, begrenzt und vergütet Rechenleistung beitragen?

Im Artikel Von PRISM zu Prompts geht es um die andere Seite dieser Entwicklung: die wachsende Abhängigkeit von wenigen KI-Plattformen, vor allem aus den USA und China. Hier interessiert mich die Gegenidee. Nicht als naive P2P-Romantik, sondern als technische Frage: Wie viel Rechenleistung liegt eigentlich schon verteilt herum, welche KI-Aufgaben könnten überhaupt verteilt werden, und was müsste passieren, damit Menschen dafür fair bezahlt werden?

Das Gedankenspiel

KI ist nicht einfach Software. KI ist Strom, Kühlung, Glasfaser, GPUs, Land, Wasser und Kapital. Die Internationale Energieagentur schätzt, dass Rechenzentren 2024 weltweit rund 415 TWh Strom verbraucht haben, etwa 1,5 Prozent des globalen Stromverbrauchs. Bis 2030 könnten es rund 945 TWh werden.

Das ist nicht nur eine Zahl für Nachhaltigkeitsberichte. Das ist Infrastrukturpolitik. KI-Dienste sind 7x24 verfügbar. Jede Zusammenfassung, jede Code-Frage, jedes Bild, jeder Agentenlauf ist eine Berechnung. Und wenn Milliarden Menschen und Unternehmen Arbeit in KI-Schleifen legen, wird daraus eine Grundlast.

Darum verstehe ich die Faszination für grosse zentrale Lösungen. Rechenzentren sind kontrollierbar: gleiche Hardware, gleiche Racks, gleiche Netzwerke, klare Security-Zonen, SLAs, Monitoring, Abrechnung. Aus Betriebssicht ist das attraktiv. Aber politisch, ökonomisch und architektonisch erzeugt es wieder genau das, was uns im Netz immer verletzlich gemacht hat: wenige Machtzentren.

Das Gedankenspiel beginnt deshalb mit einer einfachen Gegenfrage: Was liegt schon da, bevor wir das nächste Rechenzentrum bauen?

Wie gross ist die ungenutzte Kapazität?

Die Idee entsteht eigentlich in einem ganz alltäglichen Moment. Das Smartphone liegt nachts auf dem Nachttisch, hängt am Strom und macht fast nichts. Im Inneren steckt aber ein Chip, der mehr KI-spezifische Rechenleistung hat, als viele Computer vor zehn Jahren überhaupt als Gesamtpaket hatten. Ein iPhone 15 Pro mit A17 Pro kommt auf rund 35 Billionen Neural-Engine-Operationen pro Sekunde. Selbst wenn man davon nur einen vorsichtigen Mittelwert nimmt, ist das für ein Gerät, das die meiste Nacht wartet, absurd viel.

Dasselbe passiert auf dem Schreibtisch. Neue Notebooks haben nicht mehr nur CPU und GPU, sondern zusätzlich NPUs oder Neural Engines. Apple baut seit Jahren eine Neural Engine in seine Chips. Windows-Notebooks kommen als AI-PCs mit dedizierten KI-Prozessoren. Eine Spielkonsole im Wohnzimmer hat GPU-Leistung, die früher nach Workstation klang. Und trotzdem nutzen wir diese lokale Rechenleistung meistens nur in kurzen Spitzen: ein Spiel, ein Export, ein Videocall, ein lokaler Effekt, eine Suche. Danach fällt das Gerät wieder in Idle.

Genau hier beginnt das Gedankenspiel. Nicht: “Kann ich mein iPhone morgen als Rechenzentrum vermieten?” Das wäre Quatsch. Sondern: Wenn so viel Silizium bereits bezahlt, vernetzt und jede Nacht am Strom ist, wie gross wäre die theoretische Kapazität, wenn man nur kleine, sichere, passende Zeitfenster nutzen könnte?

Man kann diese ungenutzte Rechenleistung der Welt nicht exakt messen. Zu viele Geräte sind unterschiedlich, zu viele sind offline, zu viele dürfen aus Akku-, Wärme-, Sicherheits- oder Plattformgründen gar nicht mitmachen. Trotzdem hilft eine grobe Hochrechnung, um ein Gefühl für die Grössenordnung zu bekommen.

Nehmen wir dafür ein paar bewusst einfache Blöcke. Wichtig ist: Ich rechne nicht so, als ob jedes Gerät jederzeit voll verfügbar wäre. Ich rechne mit Zeitfenstern, Teilnahmequoten und vorsichtigen Abschlägen. Es bleibt ein Gedankenspiel, aber eines mit Zahlen unter den Füssen.

Tesla: Silizium auf Rädern

Tesla meldete im Juni 2025 das achtmillionste produzierte Fahrzeug. Nicht jedes davon ist noch aktiv, nicht jedes hat dieselbe Autopilot-Hardware, und nicht jeder Besitzer würde sein Auto für ein Rechennetzwerk freigeben. Also rechne ich konservativ:

• Von 8 Millionen produzierten Fahrzeugen sind vielleicht 80 Prozent noch realistisch aktiv und technisch relevant. Das wären 6,4 Millionen Fahrzeuge.
• Für Hardware 3, also den FSD Computer ab 2019, wird häufig eine Grössenordnung von 144 TOPS für das System genannt.
• Hardware 4 steckt in neueren Fahrzeugen und ist moderner, aber Tesla veröffentlicht dafür keinen sauberen, einfachen TOPS-Wert wie bei älteren Autonomy-Day-Zahlen. Für diese Rechnung nehme ich deshalb trotzdem 144 TOPS als konservativen Basiswert.
• Ein Auto steht zwar oft 23 Stunden am Tag, aber wirklich interessant ist das Ladefenster. Wenn es nachts 6,5 Stunden am Strom hängt, entspricht das auf 24 Stunden gemittelt etwa 27 Prozent Verfügbarkeit.

Wenn sich nur 25 Prozent dieser aktiven Tesla-Besitzer anmelden würden, wären das 1,6 Millionen Fahrzeuge und rund 62 Exa-Operationen pro Sekunde als Tagesäquivalent. Bei 50 Prozent Teilnahme wären es rund 125 Exa-Operationen pro Sekunde. Wenn theoretisch alle aktiven Fahrzeuge teilnehmen würden, läge die Zahl bei etwa 250 Exa-Operationen pro Sekunde. Im Nachtfenster selbst wäre die Momentanleistung höher; die Tagesäquivalent-Zahl ist nur der fairere Vergleich zu einem Rechenzentrum, das 24 Stunden läuft.

iPhones: die grössere Überraschung

Bei iPhones ist die Rechnung gleichzeitig einfacher und schwieriger. Einfach, weil Apple jedes Jahr enorme Mengen ausliefert. Schwieriger, weil Apple keine saubere öffentliche Tabelle liefert, welche iPhone-Generation weltweit noch aktiv ist. Also nehme ich veröffentlichte Shipments der letzten Jahre und lege eine plausible aktive Restquote darüber.

Diese Mischrechnung ergibt rund 885 Millionen wahrscheinlich noch aktive iPhones aus nur fünf Auslieferungsjahren. Das ist nicht die gesamte iPhone-Basis, sondern bewusst ein begrenzter Ausschnitt. Ältere A14/A15-Generationen lagen im niedrigen zweistelligen TOPS-Bereich, A16 bei knapp 17 TOPS, A17 Pro bei rund 35 TOPS. Darum ist ein Mittelwert je Jahr sinnvoller als so zu tun, als hätten alle Geräte denselben Chip.

Jetzt wieder dasselbe Spiel: 6,5 Stunden nachts am Strom, nicht den ganzen Tag. Wenn 25 Prozent dieser Geräte teilnehmen würden, käme man auf rund 1'437 Exa-Operationen pro Sekunde als Tagesäquivalent. Bei 50 Prozent Teilnahme wären es rund 2'875 Exa-Operationen pro Sekunde. Wenn theoretisch alle Geräte teilnehmen würden, läge die Zahl bei etwa 5'750 Exa-Operationen pro Sekunde.

Das klingt verrückt. Aber genau darum geht es. Nicht weil ein iPhone ein Server ist. Sondern weil die Masse der Geräte so gross ist, dass selbst vorsichtige Quoten plötzlich in eine Grössenordnung kommen, die man sonst nur Rechenzentren zutraut.

Der Vergleich

Als weitere Bezugspunkte nehme ich:

• 50 Millionen Desktop-GPUs, Workstations oder kleine Server, die im Schnitt 20 TFLOPS FP32 liefern könnten. Wenn davon nur 20 Prozent praktisch nutzbar wären, blieben rund 200 Exa-Operationen pro Sekunde in geeigneten Zeitfenstern.
• xAI Colossus als Vergleich aus der Rechenzentrumswelt. Bei 200'000 Hopper-GPUs und rund 3'958 INT8-TOPS pro H100-Grössenordnung kommt man auf ungefähr 792 Exa-Operationen pro Sekunde theoretische AI-Spitzenleistung. Das ist der Sparsity-Peak; dichte und dauerhaft nutzbare Leistung liegt tiefer.

Das ist keine exakte globale Kapazität. Es ist ein Denkmodell. Und genau hier muss man bremsen: TOPS lassen sich nicht einfach wie Liter Wasser in einen gemeinsamen Pool giessen. Neural-Engine-TOPS eines iPhones, INT8-TOPS einer GPU und FP32-Leistung einer Workstation sind verschiedene Dinge. Viele sinnvolle Jobs brauchen nicht nur Rechenoperationen, sondern RAM, VRAM, Speicherbandbreite, stabile Laufzeit, Softwarezugriff und ein Betriebssystem, das solche Jobs überhaupt zulässt.

Trotzdem zeigt die Rechnung, warum die Idee nicht lächerlich ist. Schon eine konservative Kombination aus PCs, Fahrzeugen und Smartphones kommt als theoretisches Silizium in eine Grössenordnung, die neben einem der sichtbarsten AI-Rechenzentren der Welt nicht mehr absurd klein wirkt.

Gerade die iPhone-Zahl ist spannend, weil sie nur fünf Auslieferungsjahre betrachtet, nicht die gesamte aktive installierte Basis. Gleichzeitig ist sie das beste Beispiel dafür, warum Peak-Leistung nicht genügt: Ein iPhone ist kein Server. Es hat Wärmegrenzen, Akkulogik, Betriebssystemregeln, Datenschutzmodelle und einen Besitzer, der am Morgen ein funktionierendes Gerät erwartet. Trotzdem liegt dort Rechenleistung, die vor wenigen Jahren wie Science-Fiction gewirkt hätte.

Und selbst diese Peak-Werte sind nur Peak-Werte. Ein Smartphone, ein lüfterloses Notebook oder ein Auto-Steuergerät kann solche Leistung nicht einfach sechs Stunden lang wie ein Rechenzentrums-GPU liefern. Thermik, Drosselung und Schutzlogik drücken die Dauerleistung massiv. Wer daraus ein echtes Netz bauen wollte, müsste also mit sustained performance rechnen, nicht mit der schönsten Zahl aus dem Datenblatt.

Man kann es auch über Strom denken. Wenn 50 Millionen Geräte im Schnitt 150 Watt für vier Stunden pro Tag beitragen würden, wären das etwa 11 TWh pro Jahr. Das ist nur ein kleiner Bruchteil des heutigen globalen Rechenzentrumsverbrauchs. Aber es wäre genug, um viele Hintergrundjobs, Embeddings, wissenschaftliche Workloads, Rendering, Verifikationsaufgaben oder dezentrale Speicherprozesse zu tragen.

Der unangenehme Einwand ist: Das muss nicht automatisch effizienter sein. Rechenzentren haben bessere Kühlung, bessere Auslastung, günstigeren Strom, neuere Hardware und professionelles Batching. Ein Heimgerät kann pro nützlicher Rechenarbeit schlechter dastehen, besonders wenn viel Overhead entsteht oder wenn ein Smartphone-Akku für ein paar Cent Credits schneller altert. Ein dezentrales Compute-Grid wäre deshalb nicht schon gut, weil es verteilt ist. Es müsste für passende Workloads netto sinnvoll sein: technisch, energetisch und wirtschaftlich.

Noch spannender wird es mit neuen AI-PCs. Canalys erwartete für 2025 rund 100 Millionen ausgelieferte AI-PCs. Viele dieser Geräte bringen NPUs mit 40 TOPS oder mehr mit. TOPS ist nicht dasselbe wie GPU-FLOPS, und eine NPU ersetzt kein Rechenzentrum. Aber selbst wenn man diese Leistung sehr vorsichtig betrachtet, entsteht eine neue Klasse lokaler KI-Hardware, die nicht nur auf dem Papier existiert, sondern in Büros und Wohnungen landet.

Die Pointe ist also nicht: “Wir ersetzen morgen alle Rechenzentren durch Gaming-PCs, Teslas und iPhones.” Die Pointe ist: Wir bauen gewaltige neue zentrale Kapazität, während gleichzeitig eine riesige Menge verteilter, bereits bezahlter Kapazität ungenutzt verfällt.

Rechenleistung verdirbt

Strom kann ich speichern. Nicht perfekt, nicht verlustfrei, aber grundsätzlich. Wenn meine Solaranlage mittags mehr produziert, als ich brauche, geht Energie in eine Batterie oder ins Netz. Am Abend kann ich sie wieder verwenden, oder mein Nachbar verwendet sie. Smart Grids, Batteriespeicher und Peer-to-Peer-Energiemodelle machen diese Denkweise immer konkreter: mal produziere ich, mal verbrauche ich, und die Grenze zwischen Kunde und Anbieter wird weicher.

Rechenleistung funktioniert anders.

Eine ungenutzte GPU-Stunde von gestern kann ich heute nicht aus der Schublade holen. Ein Prozessor, der eine Nacht lang nichts getan hat, hat keine Rechenleistung für später aufgehoben. Diese Zeit ist weg. Unwiederbringlich. Compute ist verderblich.

Genau das macht ungenutzte Geräte spannend. Wir haben nicht nur Hardware. Wir haben ständig verfallende Möglichkeiten. Der kurzfristig realistische Pool sind vor allem Desktop-GPUs, Workstations, Spielkonsolen, kleine Server, NAS-Speicher und Campus- oder Provider-Ressourcen. Smartphones und Autos sind eher langfristige Randfälle: technisch faszinierend, aber wegen Akku, Wärme, Plattformregeln, Sicherheit und Herstellerkontrolle deutlich schwieriger.

Es scheitert also nicht nur an der Mathematik, sondern auch am Anreiz. Die Geräte mit dem interessantesten brachliegenden Silizium gehören ausgerechnet geschlossenen Plattformen: Apple baut mit Private Cloud Compute eigene Infrastruktur für grosse Apple-Intelligence-Anfragen, Tesla mit Cortex eigene Trainingskapazität für FSD und Optimus. Warum sollten gerade diese Firmen ihre Geräteflotte für einen herstellerunabhängigen Compute-Markt öffnen, wenn Kontrolle über Hardware, Software und Cloud der eigentliche Burggraben ist?

Trotzdem bleibt die Grundfrage: Warum behandeln wir verteilte Rechenleistung so, als wäre sie irrelevant, während wir gleichzeitig immer grössere zentrale Anlagen bauen?

Kann KI überhaupt dezentral rechnen?

Hier muss man ehrlich sein: Für vieles, was heute als KI sichtbar ist, ist Dezentralität schwierig.

Ein grosses Sprachmodell ist nicht einfach eine Liste kleiner Aufgaben, die man beliebig auf fremde Geräte wirft. Modelle brauchen RAM oder VRAM. Sie brauchen Speicherbandbreite. Sie brauchen teilweise schnelle Interconnects. Bei der Token-Generierung wird das Modell immer wieder durchlaufen, und jedes zusätzliche Netzwerk-Hopping macht die Antwort langsamer. Ein Frontier-Modell über fremde Smartphones, alte Laptops und Autos zu zerlegen, wäre für eine interaktive Chat-Antwort meistens Unsinn.

Das heisst aber nicht, dass dezentrale KI unmöglich ist. Es heisst nur, dass man die richtigen Aufgaben wählen muss.

Sehr gut passen Arbeiten, die nicht in zwei Sekunden fertig sein müssen: Embeddings für grosse Archive, Batch-Zusammenfassungen, Rendering, wissenschaftliche Simulationen, synthetische Daten, Tests, Crawling, Verifikationsaufgaben, dezentrale Speicherreparatur, kleine lokale Modelle, Vorverarbeitung und Aufgaben, bei denen man Ergebnisse prüfen oder mehrfach rechnen lassen kann.

Praktisch müsste man die Aufgaben viel sauberer trennen:

Auch grosse Modelle sind nicht völlig ausgeschlossen, aber sie brauchen andere Architektur. Petals hat gezeigt, dass kollaborative Inferenz und Fine-Tuning grosser Modelle über verteilte Ressourcen grundsätzlich möglich sind. Prime Intellect geht mit INTELLECT-2 noch einen Schritt weiter und zeigt, wie verteiltes Reinforcement Learning mit nicht vertrauenswürdigen Workern funktionieren kann, wenn Ergebnisse verifiziert werden. Das ist noch nicht die Welt, in der dein iPhone nachts heimlich GPT-7 trainiert. Aber es ist ein Hinweis, dass das Problem nicht grundsätzlich unmöglich ist.

Der realistische Start wäre deshalb nicht: “Wir verteilen ein riesiges Modell quer über alles.” Der realistische Start wäre: lokale Modelle zuerst, regionale Pools für passende Batch-Jobs, verifizierbare Aufgaben, klare Datenzonen und zentrale Rechenzentren nur dort, wo sie wirklich nötig sind.

Der alte Traum verteilter Systeme

Es gibt eine andere Erzählung des Internets. Eine, die weniger nach Kathedrale klingt und mehr nach Schwarm.

Freiwilliges Rechnen

SETI@home war für mich immer eines der schönsten Beispiele. Millionen Menschen liessen ihre Computer im Hintergrund Daten aus der Radioastronomie berechnen. Nicht, weil sie dafür ein SaaS-Dashboard bekamen, sondern weil die Idee gross genug war: Wir suchen gemeinsam nach Signalen im Rauschen des Alls. Seit März 2020 verteilt SETI@home keine neuen Work Units mehr und ist in einer Art Hibernation. Aber als Beweis, dass freiwilliges Rechnen global funktionieren kann, bleibt es wichtig.

BOINC, die Plattform dahinter und daneben, beschreibt nüchtern, warum das funktioniert: viele unabhängige, rechenintensive Jobs, bei denen Durchsatz wichtiger ist als niedrige Latenz. Genau das ist der entscheidende Unterschied. Ein verteiltes System muss nicht jede interaktive Chat-Antwort in zwei Sekunden liefern. Es kann dort stark sein, wo Arbeit zerlegbar, überprüfbar und nicht sofort fällig ist.

Speicher ohne festen Ort

IPFS trägt denselben Gedanken in den Speicherbereich. Dateien werden nicht primär über einen Ort adressiert, sondern über ihren Inhalt. Der Inhalt hat einen Fingerabdruck. Wer ihn hat, kann ihn liefern. Das ist eine andere Denke als “diese Datei liegt auf diesem Server unter dieser URL”.

Geld ohne zentrale Buchhaltung

Bitcoin hat, völlig unabhängig davon, wie man Spekulation und Energieverbrauch bewertet, eine ähnliche Ur-Idee populär gemacht: ein System ohne zentrale Buchhaltung, in dem Konsens nicht von einer einzigen Institution abhängt. Nicht jede dezentrale Idee ist automatisch gut. Aber Bitcoin hat gezeigt, dass ein Protokoll politisch mächtig sein kann, wenn es die zentrale Kontrollstelle entfernt.

Storage als Netzwerk

Beim Speicher gab es ebenfalls interessante Versuche. Symform war ein dezentraler Cloud-Storage-Anbieter, bei dem überschüssiger Speicher in ein Netzwerk eingebracht werden konnte. 2014 wurde die Plattform von Quantum übernommen; zu diesem Zeitpunkt war von 45'000 Nutzern und kleinen Unternehmen in 170 Ländern die Rede. Storj, Sia, Filecoin und andere Varianten zeigen ebenfalls: Die Idee ist nicht neu. Sie kommt nur nie ganz im Alltag an.

Heute lebt diese Idee in neuen Formen weiter. Storj zerlegt Dateien clientseitig verschlüsselt und verteilt Stücke über viele Storage Nodes. Das ist näher an Infrastruktur als an Romantik: Der Nutzer sieht im besten Fall nicht den Schwarm, sondern einen Speicher-Dienst, der funktioniert.

Compute als Marktplatz

Golem und Akash wollen ungenutzte Rechenleistung als Marktplatz zugänglich machen. Das ist für mich die direkte Brücke zu diesem Artikel: Nicht nur Speicherplatz liegt verteilt herum, sondern auch Prozessoren, GPUs und kleine Server, die heute oft untätig bleiben.

KI im verteilten Schwarm

Auch Andrej Karpathy taucht in diesem Umfeld wieder auf: Bei Prime Intellect wird er als prominenter Unterstützer genannt, und Prime Intellect hat mit INTELLECT-2 eine dezentral verteilte RL-Trainingsrunde für ein 32B-Parameter-Modell gestartet, bei der heterogene, permissionless Rechenressourcen beitragen können.

Das ist noch nicht die perfekte Antwort. Aber es zeigt: Der Traum ist nicht verschwunden. Er sucht nur immer wieder nach einer Form, die im echten Betrieb überlebt.

Vom virtuellen Kraftwerk lernen

Spannend ist, dass diese Denkweise im Strombereich längst weniger exotisch klingt.

Tesla beschreibt sein Virtual Power Plant als Netzwerk verteilter Energiequellen: Häuser mit Solaranlagen und Powerwalls werden zusammen wie ein Kraftwerk betrachtet. Wenn das Netz Unterstützung braucht, können Batterien Strom abgeben. Der Besitzer stellt eine Ressource bereit und bekommt dafür Geld oder andere Vorteile. Einzelne Powerwalls sind klein. Zusammen können sie aber für das Netz relevant werden.

Das ist genau die Analogie, die mich bei Compute fasziniert. Eine einzelne GPU im Homeoffice, ein einzelnes NAS, ein einzelnes iPhone oder ein einzelnes Auto ist kein Rechenzentrum. Aber viele Geräte zusammen könnten eine neue Schicht bilden: nicht für alles, nicht jederzeit, nicht ohne Regeln, aber für bestimmte Aufgaben.

Die Analogie hat Grenzen. Strom ist viel fungibler als Rechenarbeit. Eine Kilowattstunde ist nicht davon abhängig, ob sie gerade ein Modell mit 80 GB VRAM, eine Embedding-Pipeline oder einen verschlüsselten Storage-Repair ausführen soll. Compute ist workload-abhängig. Genau deshalb braucht es Jobklassen, Scheduling und harte Ausschlüsse.

Bei Tesla sieht man denselben Gedanken sogar an zwei Stellen. Powerwalls können Teil eines virtuellen Kraftwerks werden. Autos sollen perspektivisch Teil einer autonomen Robotaxi-Flotte werden, also dann Geld verdienen, wenn der Besitzer sie gerade nicht selbst nutzt. Ob und wie schnell das wirklich skaliert, ist eine andere Frage. Aber die Grundidee ist wichtig: Ein privates Gerät wird nicht mehr nur konsumiert, sondern kann in freien Zeitfenstern als Infrastruktur arbeiten.

Compute könnte ähnlich gedacht werden. Nicht als Stromverkauf an den Nachbarn, sondern als Verkauf von verifizierbarer Rechenzeit, Speicherplatz oder Modellarbeit an eine regionale Zelle. Der Nutzer bezahlt am Ende den Strom, die Wärme, den Hardwareverschleiss und das Risiko. Also muss er auch vergütet werden. Ohne diesen Punkt wird aus der Idee nur ein hübsches technisches Experiment.

Warum der Schwarm so selten gewinnt

Wenn Dezentralität so schön klingt, warum setzt sie sich nicht einfach durch?

Weil Zentralisierung oft das bessere Produktpaket ist.

Ein Rechenzentrum ist kontrollierbar. Ein Schwarm besteht aus fremden Geräten, verschiedenen Betriebssystemen, wechselnder Verfügbarkeit, schlechter Vorhersagbarkeit und Besitzern, die ihr Gerät ausschalten, verkaufen, updaten oder vom Netz trennen. Für einen Produktmanager ist das keine Romantik, sondern Kopfschmerz.

Dazu kommt die Ökonomie. Viele dezentrale Projekte haben versucht, Anreize über Tokens zu lösen. Das ist verständlich, weil ein Netzwerk ohne zentrale Firma trotzdem Vergütung braucht. Aber sobald die Kosten für Speicher oder Rechenzeit an eine volatile Währung gekoppelt sind, wird es für normale Unternehmen unattraktiv. Ich will nicht, dass mein Terabyte Backup plötzlich teurer wird, weil ein Coin auf Twitter gepumpt wird. Ich will auch nicht, dass mein Budget für GPU-Stunden von einem Markt abhängt, der sich eher wie ein Casino als wie Infrastruktur anfühlt.

Und der Preisgegner ist nicht die teuerste On-Demand-GPU in der Cloud. Der echte Vergleich sind Spot- und Preemptible-Angebote, also ohnehin überschüssige Rechenzentrumskapazität, die Anbieter mit deutlichem Rabatt verkaufen. Ein dezentrales Compute-Netz müsste also nicht nur philosophisch schöner sein. Es müsste gegen sehr billige, gut integrierte, wenn auch unterbrechbare Cloud-Kapazität bestehen.

Die zweite Bremse ist Bequemlichkeit. S3 hat nicht gewonnen, weil es philosophisch schön ist. Es hat gewonnen, weil es einfach genug, dokumentiert genug und überall integriert ist. Wenn dezentrale Speicher- oder Compute-Netze relevant werden wollen, müssen sie sich für Entwickler und Admins fast langweilig anfühlen: API-Key rein, Bucket anlegen, Monitoring, Rechnung, SLA, Restore-Test, fertig.

Dann kommt die Sicherheit. In einem Unternehmensnetzwerk soll nicht plötzlich irgendein fremder Compute-Job eingehend auf Workstations landen. Das würde jede vernünftige Firewall blockieren und für Threat-Intelligence-Systeme verdächtig aussehen. Praktisch müsste so ein System eher von innen nach aussen arbeiten: der Knoten meldet sich bei einer Zelle, holt geprüfte Jobs ab, läuft in einer Sandbox und sieht nur Daten, die er sehen darf. Sonst sieht ein legitimes Compute-Netz auf Netzwerkebene schnell aus wie ein sehr höflich formuliertes Botnet.

Vertrauen ist der nächste harte Punkt. Dezentrale Systeme müssen beweisen können, dass Arbeit korrekt erledigt wurde, ohne dass jeder Knoten alles sehen darf. Bei Speicher gibt es bekannte Bausteine: Verschlüsselung, Erasure Coding, Audits, Reparaturmechanismen. Bei KI und Compute wird es schwieriger. Wie prüfe ich, ob ein fremdes Gerät ein Modell korrekt ausgeführt hat? Wie verhindere ich Datenabfluss? Wie schütze ich das Gerät des Teilnehmers vor fremdem Code?

Auch Hardwareverschleiss ist mehr als Strom. SSDs und NVMe-Speicher haben Schreiblimits. Wer Modellgewichte, temporäre Daten, Embedding-Batches oder Swap-Dateien ständig auf Consumer-Geräte schreibt, verbraucht echte Lebensdauer. Dazu kommt das Bandbreitenproblem: Wenn der Download eines grossen Modells oder Datensatzes länger dauert und mehr Netz-Overhead erzeugt als die eigentliche Berechnung, kippt die Rechnung. Daten sind schwerer, als die einfache Smart-Grid-Metapher vermuten lässt.

Genau hier wird INTELLECT-2 interessant. Prime Intellect beschreibt in seinem Paper TOPLOC als Baustein, der Rollouts von nicht vertrauenswürdigen Inference Workern verifiziert. Das löst nicht plötzlich alle Compute-Probleme. Es ist kein magischer Datenschutz für beliebige Firmendaten auf fremder Hardware. Aber es zeigt einen realen Mechanismus für eine bestimmte Klasse verteilter KI-Arbeit: Jobs werden so gebaut, dass Ergebnisse überprüfbar sind, statt dass man jedem Worker blind vertrauen muss.

Für vertrauliche Daten reicht das allein nicht. Dort bräuchte es andere Bausteine: Confidential Computing, Trusted Execution Environments, Remote Attestation, saubere Sandboxes, klare Datenklassifikation und im Zweifel die harte Entscheidung, bestimmte Jobs gar nicht auf fremder Hardware laufen zu lassen. Dazu kommen langweilige, aber entscheidende Fragen: Steuer, Haftung, Datenschutz, Datenresidenz und die AGB von Internetprovidern. Infrastruktur scheitert selten nur an Mathematik. Oft scheitert sie an Betrieb.

Ein Compute-Smart-Grid

Ich stelle mir kein naives “alles ist P2P und dann wird alles gut” vor. So funktioniert Infrastruktur nicht. Was funktionieren könnte, wäre ein Compute-Smart-Grid mit klaren Schichten.

Die erste Schicht heisst: lokal zuerst. Alles, was persönlich, vertraulich oder latenzkritisch ist, sollte möglichst auf dem eigenen Gerät oder im eigenen Vertrauensraum laufen. Kleine Modelle, lokale Suche, private Zusammenfassungen, einfache Klassifikation, Vorverarbeitung, Verschlüsselung, Embeddings für persönliche Daten. Nicht jede E-Mail, jede Notiz und jede Suche muss zu einem Hyperscaler.

Die zweite Schicht wäre regional und föderiert. Eine Stadt, ein Quartier, ein Campus, ein Unternehmen, eine Genossenschaft oder ein Provider könnte eine Zelle betreiben. In dieser Zelle stellen Geräte freiwillig Ressourcen bereit, aber nur unter klaren Bedingungen: nur am Strom, nur im Idle, nur innerhalb thermischer Grenzen, nur mit definierter Maximalleistung, nur für bestimmte Jobklassen.

Der Startpunkt wären nicht Smartphones und Autos, sondern die langweiligeren Geräte: Desktop-GPUs, Workstations, Spielkonsolen, kleine Server, NAS-Systeme und freie Kapazität bei lokalen Providern. Smartphones könnten später kleine Verifikationsjobs übernehmen. Autos wären noch später denkbar, in sehr engen, herstellerkontrollierten Grenzen. Genau wie beim Stromnetz müsste man erst mit den Ressourcen beginnen, die zuverlässig, messbar und steuerbar sind.

Die dritte Schicht bleibt zentral. Frontier-Training, harte Echtzeit, extrem grosse Modelle, regulatorisch heikle Spezialfälle und Workloads mit hoher Kopplung gehören weiterhin in professionelle Rechenzentren. Dezentralität muss nicht alles ersetzen. Sie muss nur verhindern, dass jede Alltagsarbeit automatisch durch dieselben fünf Machtzentren läuft.

Wenn man das testen wollte, würde ich klein anfangen. Nicht mit Millionen iPhones, sondern mit einer regionalen Zelle aus vielleicht 500 bis 2'000 freiwilligen Desktop-GPUs, Workstations, NAS-Systemen und kleinen Servern. Erlaubt wären nur wenige Jobtypen: Embeddings für nicht sensible Daten, wissenschaftliche Batch-Jobs, verschlüsselte Speicherstücke und Verifikationsaufgaben. Erfolg misst man nicht an einer hübschen Exa-Zahl, sondern an drei langweiligen Kennzahlen: erledigte Jobs je $1 Stromkosten, Fehler- und Wiederholungsrate, Auszahlung nach Hardwareverschleiss.

Der schwierigste Teil wäre die Vergütung. Der Nutzer bezahlt Strom, Wärme und Hardwareverschleiss. Also braucht er etwas zurück. Wahrscheinlich bräuchte es tatsächlich einen Token oder Credit. Aber nicht als Spekulationsobjekt, sondern als Infrastruktur-Guthaben.

Ein solcher Compute-Credit müsste für etwas Reales stehen: eine GPU-Minute bestimmter Klasse, einen GB-Monat Speicher, eine verifizierte Inferenz, eine Batch-Embedding-Einheit oder eine kWh-äquivalente Recheneinheit. Wer Ressourcen gibt, verdient Credits. Wer später selbst KI-Leistung braucht, verbraucht sie. Wer nichts verbrauchen will, könnte sie in Fiat auszahlen lassen, ähnlich wie man bei einem virtuellen Kraftwerk nicht in “Powerwall-Coins” bezahlt werden will, sondern in echtem Geld oder einer klaren Gutschrift.

Damit ist die Preisfrage aber nicht magisch gelöst. Stabilität braucht einen Anker: Fiat-Abrechnung, Energiepreis-Korridore, regionale Clearingstellen, Genossenschaftstarife oder regulierte Betreiber. Ganz ohne Governance wird aus “stabilen Credits” schnell wieder ein frei schwankender Token. Und dann ist man wieder beim alten Problem: Infrastruktur fühlt sich an wie ein Casino.

Noch wichtiger ist die Frage der Betriebsrechte. Wir müssen nicht jedes grosse Foundation Model selbst trainieren. Vielleicht kauft oder lizenziert man Modelle, offene Gewichte oder Modellfamilien ein und betreibt sie dann dezentral, föderiert und regional kontrolliert. Die eigentliche Souveränität läge dann nicht nur im Training, sondern im Betrieb: Wo laufen die Modelle? Wo liegen die Daten? Wer darf auditieren? Gibt es einen Rückkanal zum Anbieter? Kann ich das Modell lokal weiterbetreiben, wenn sich Politik, Preise oder Terms ändern?

Damit das mehr ist als ein hübscher Einkaufsvertrag, müssten solche Lizenzen echte Betriebsrechte enthalten: lokale Deployments, langfristige Update- und Sicherheitszusagen, nachvollziehbare Modellkarten, Auditierbarkeit, klare Exit-Rechte und keine Pflicht, sensible Daten wieder in die zentrale Hersteller-Cloud zurückzuschieben. Das wäre nicht die reine dezentrale Utopie. Aber es wäre ein realistischer Weg zwischen naiver Selbstversorgung und totalem Plattform-Lock-in.

Die Nacht, in der Geräte rechnen

Stell dir vor, es ist 22:43 Uhr. Dein Desktop mit GPU ist im Idle, das NAS ist online, das Handy lädt. In den Einstellungen hast du festgelegt: maximal 80 Watt, nur im Leerlauf, nur für geprüfte Workloads aus der Region und nur, wenn die Vergütung Stromkosten plus Hardwarepauschale deckt.

Ein lokaler Agent meldet freie Kapazität. Nicht mit deinem Namen und nicht mit deinen privaten Daten, sondern als attestierter Knoten mit bestimmten Fähigkeiten. Die Zelle verteilt kleine Jobs: Simulationen, Embeddings, verschlüsselte Speicherstücke, Verifikationsaufgaben.

Am Morgen steht da keine Rakete, keine Wall-Street-Story, kein Hype-Token. Nur eine nüchterne Zeile:

Diese Nacht: 2,4 GPU-Credits verdient, 18 GB-Monate Storage bestätigt, $0.31 Stromkosten geschätzt.

Später nutzt du diese Credits für ein lokales Modell über deine eigenen Dokumente. Die sensiblen Daten bleiben bei dir. Du bist nicht nur Kunde. Du bist Teilnehmer.

Das klingt romantisch. Ja. Aber manchmal ist genau das der Grund, ein schwieriges Engineering-Problem ernst zu nehmen.

Der Schwarm und der Berg

Ich glaube nicht, dass zentrale Rechenzentren verschwinden. Sie sind zu effizient, zu wichtig und für manche Aufgaben schlicht notwendig. Der Berg bleibt. Die Frage ist nur, ob wir daneben wieder einen Boden bauen.

Einen Boden aus lokalen Geräten, regionalen Zellen, offenen Protokollen, stabilen Credits und klaren Sicherheitsmodellen. Einen Boden, auf dem Rechenleistung nicht nur von oben nach unten verkauft wird, sondern zwischen Teilnehmern fliesst. Einen Boden, auf dem bestimmte KI-Arbeit dort läuft, wo sie hingehört: private Arbeit lokal, regionale Arbeit regional, globale Grenzfälle im Rechenzentrum.

Vielleicht ist das naiv. Vielleicht auch nicht. Virtuelle Kraftwerke waren ebenfalls einmal eine schräge Idee: tausende kleine Batterien als ein grosses Netzwerk. Dezentrales Geld klang lange absurd. Autos, die autonom als Taxi fahren, klangen nach Science-Fiction. Nicht alles davon wird so kommen, wie es versprochen wurde. Aber die Richtung ist klar: Ressourcen, die früher passiv herumstanden, werden zunehmend als Teil eines grösseren Systems gedacht.

Gerade jetzt stehen überall ungenutzte Maschinen. In Wohnungen, Büros, Garagen, Serverräumen und Hosentaschen. Nicht jede davon eignet sich gleich gut. Nicht jede sollte jemals fremde Arbeit ausführen. Aber viele sind bereits da, bezahlt und vernetzt. Und jede ungenutzte Sekunde verschwindet.

Vielleicht sollten wir anfangen, ihnen zuzuhören.

Bis zum nächsten Mal,
Euer Joe