§ Plattform / Verteiltes Rechnen
Bündle deine Geräte. Bündle dein Labor. Bündle die Crowd.
Ein Mechanismus macht aus den Geräten, die du erreichst, eine arbeitende Kohorte: Ein Job — ein Programm plus eine deklarierte Art, ihn zu teilen, eine deklarierte Art, die Ergebnisse zusammenzuführen, und eine Regel, wer mitmachen darf — wird in Teile zerlegt, ein Pool von Peers rechnet sie, und ein Ergebnis zählt erst, wenn es verifiziert ist. Derselbe Mechanismus spannt sich über deine eigenen Maschinen, ein Konsortium zugelassener Institutionen und eine offene Menge Fremder — drei Vertrauensstufen, die die Plattform nie vermischt. Sein Koordinator ist implementiert und getestet; gepoolte Jobs über echte Browser hinweg sind im aktiven Aufbau.
Ein Mechanismus, von solo bis Schwarm
Verteiltes Rechnen ist hier keine Familie von Subsystemen, sondern eine einzige Sache. Ein Job liegt fest und wird über seinen Inhalt identifiziert: ein Programm, eine deklarierte Regel, wo die Arbeit sich teilt, eine deklarierte Regel, wie die Ergebnisse zusammenkommen, und eine Policy, wer mitmachen darf. Jedes Teilstück trägt genau die Eingaben, die es bekommen hat, und seinen eigenen reproduzierbaren Ausschnitt des Zufalls — jeder Peer kann exakt das Stück nachrechnen, das ihm gegeben wurde; ein Stück, das nicht zurückkommt, wird schlicht neu vergeben, nie aufgegeben.
Eine Form deckt data-paralleles Training, Parameter-Sweeps, Ensembles, k-fold-Validierung, Monte-Carlo-Simulation und Batch-Analysen ab. Ein Pool aus einem Gerät ist ein gewöhnlicher Solo-Lauf, ohne Koordinator — Bündeln schwächt den Offline-Kern nie, und nichts, was du baust, hängt davon ab, dass jemand anders auftaucht. Arbeit, die Geräte in fester Reihenfolge durchlaufen muss — wo die Ausgabe der einen Maschine die Eingabe der nächsten ist —, ist bewusst ein eigener Mechanismus, statt in diesen hineingepresst zu werden.
Deine Geräte, ein Konsortium oder die offene Menge — nie vermischt
Jeder Pool deklariert, wer beitreten darf, und die drei Antworten werden nie zu einem vagen Vertrauensregler verschmolzen. Deine eigenen Geräte — Laptop, Desktop, Workstation — treten als eine Kohorte an: volles Vertrauen, keine Rückfragen. Ein Konsortium besteht aus institutionell signierten Mitgliedern; es ist die einzige Umgebung, in der sicherheitskritische oder regulierte Arbeit überhaupt laufen darf. Eine offene Menge sind anonyme Fremde: reines Rechnen, beschränkt auf Eingaben, die ohnehin öffentlich sind, durch unabhängige Nachrechnung stichprobengeprüft — die geprüften Teile so zu wählen, dass kein Peer sie vorhersagen kann, ist noch im Aufbau — und durch ein Budget gedeckelt, das du setzt.
Rechenleistung leihen und gemeinsam bearbeiten sind zwei verschiedene Handlungen, und die Plattform hält sie auseinander: Ein Fremder kann dir eine GPU leihen, ohne eine Zeile deiner Daten zu lesen und ohne eine Zeile in dein Dokument zu schreiben — gemeinsam an einem Dokument arbeiten ist Live-Zusammenarbeit, eine eigene Entscheidung. Die Ehrlichkeit gilt auch andersherum: Ein Peer, der deine Arbeit ausführt, hält zwangsläufig, worauf er rechnet — ein Modell oder ein Dataset, das du als vertraulich markierst, verweigert die offene Menge schlicht. Die breitere Vertrauensmaschinerie steht unter Sicherheit.
Sweeps, Simulationen und Batch-Analysen sind erstklassig
Ungenutzte Laptops und Workstations sollen zu einem Cluster verschmelzen, der jede Arbeit rechnet, die sich in unabhängige Teile schneiden lässt — ein Parameter-Sweep, ein Ensemble, k-fold-Validierung, eine Monte-Carlo-Simulation, eine Batch-Analyse über ein großes Dataset — ganz ohne Trainingsmaschinerie: unabhängige Teile, eine schlichte deklarierte Art, sie zusammenzuführen, nirgends Gradienten. Wer gerade frei ist, nimmt das nächste Teil — ein langsamer Peer, ein verschwundener Peer und ein ausgefallener Peer sind damit ein einziger abgefangener Fall statt dreier Flicken.
Eingaben sollen sich zwischen den Peers verteilen, statt einzeln aus einer einzigen Quelle herauszufächern — ein großes Dataset wird so nicht zum Nadelöhr. Ergebnisse sollen erst eingefaltet werden, nachdem sie die Verifikation bestanden haben — eine schlechte Stichprobe lässt sich aus einem laufenden Mittelwert nicht wieder herausrechnen; heute markiert der Koordinator ein unbestätigtes Ergebnis, statt es zurückzuhalten — und lange Simulationen strömen durch Akkumulatoren konstanter Größe, statt Millionen Samples im Speicher aufzutürmen. Ein Sweep soll sich Teil für Teil füllen, während er läuft; der Guide zu verteiltem Rechnen erklärt den Mechanismus.
Was sich gut bündeln lässt — und was ehrlicherweise nicht
Unterschiedliche Arbeit skaliert unterschiedlich. Die Tabelle sagt es laut.
| Arbeit | Skalierung | Der ehrliche Grund |
|---|---|---|
| Parameter-Sweeps & Batch-Analysen | nahezu linear — erwartet, noch nicht gemessen | Unabhängige Teile, kein Warten; wer frei ist, nimmt das nächste — ein Nachzügler und ein Ausfall sind derselbe abgefangene Fall. |
| Monte-Carlo & Ensembles | nahezu linear — erwartet | Unabhängige Seeds; dafür gebaut, erst nach der Verifikation in einen Akkumulator konstanter Größe eingefaltet zu werden. |
| Training im Gleichschritt | sublinear — bestenfalls Dutzende stabile Peers | Alle warten auf den Langsamsten; es wächst durch seltenere Synchronisation, nie durch tiefere Koordination — über Browser hinweg noch nicht verdrahtet. |
| Föderiertes Lernen | über Teilnehmer | Wächst in Kohortengröße und statistischer Aussagekraft — nie im Tempo. |
| Modelle, die nicht auf ein Gerät passen | das Modell selbst aufteilen | Das Modell auf mehr Geräte zu kopieren bringt Durchsatz, nicht Platz; es unterzubringen heißt, das Modell über sie zu verteilen — der Planner benennt, wie. |
Nirgends auf dieser Seite wird ein Speedup-Faktor versprochen — die benannten Mechanismen (kleinere Updates senden, Rechnen und Übertragen überlappen, schnelleren Geräten größere Teile geben) sind die Zusage.
Nahezu linearer Speedup ist die erwartete Form — und präzise begrenzt: Er gilt für Arbeit, deren Teile nie aufeinander warten müssen, und ist über Browser hinweg noch nicht gemessen. Training, das im Gleichschritt bleibt, ist sublinear — langsame Peers und zugeklappte Laptops begrenzen es bestenfalls auf grob Dutzende stabile Peers —, und es wächst, indem seltener synchronisiert wird, nicht durch tiefere Koordination; gepooltes Training über Browser hinweg ist noch nicht verdrahtet. Fluktuation, nicht die Mathematik, ist der dominante Preis des Bündelns.
Zwei weitere Grenzen überleben in jedem Satz dieser Seite. Bündeln vervielfacht den Durchsatz, nicht die Kapazität: Ein Modell, das nicht auf ein Gerät passt, passt auch nicht auf zehn Kopien davon — es unterzubringen heißt, das Modell selbst über Geräte zu verteilen, und der Planner benennt, wie. Und ein Browser-Tab im Hintergrund ist eingefroren, nicht am Rechnen: Beitragen ist auf ein Gerät im Vordergrund und am Netzteil ausgelegt. Wir versprechen Mechanismen, nie Multiplikatoren — der Rest steht in den ehrlichen Grenzen.
„Serverlos“ beschreibt die Daten, nie die Koordination
Ein Browser-Tab kann keine eingehende Verbindung annehmen, also steht bei jedem Beitritt und jedem Reconnect ein Koordinator in der Schleife. Seine Rolle ist präzise benannt: nie tragend für die Korrektheit und nie nötig für Solo-Arbeit, die vollständig offline läuft — aber wirklich nötig, um einen Pool über die Zeit am Laufen zu halten. Koordination läuft über einen Server; deine Tensoren sollen das nicht: Das Design bewegt den Großteil der Bytes von Gerät zu Gerät, in den meisten Heim- und Mobilfunknetzen direkt — eine Datenebene, die noch im aktiven Aufbau ist.
Hinter einer Firmen-Firewall — der abgeriegelten institutionellen Umgebung — scheitert eine direkte Verbindung meist, und der Verkehr fällt auf ein Relay zurück. Für diese Umgebung ist das Relay der Dauerzustand, und wir sagen das, statt es zu „von Gerät zu Gerät“ aufzurunden — das Relay selbst ist noch nicht in Betrieb. Eine Regel gilt auf jeder Skala: Nur Peers führen je ein Ergebnis zusammen — der Koordinator sequenziert und wählt aus, er summiert nie — und ein großer Pool verteilt seine Koordination, statt alles durch einen Punkt zu trichtern.
Föderiertes Lernen ist eine Einstellung, kein Subsystem
Föderiertes Lernen ist derselbe Job in einer anderen Einstellung: Jeder teilnehmende Standort behält seine Rohdaten, trainiert auf eigener Hardware und schickt nur Modell-Updates, die eine deklarierte Strategie mittelt. Die Strategien sind gewöhnlicher Katalog-Content, kein Engine-Code: FedAvg, FedProx, SCAFFOLD, DiLoCo und die FedAdam-Familie für stabile Konsortien; FedBuff und Gossip für Geräteflotten, die kommen und gehen; Ditto, FedPer und geclustertes Föderieren für den häufigen Fall, dass ein einziges globales Modell das falsche Ziel ist. Eine neue zu schreiben ist gewöhnliches Erstellen.
Das Rezept lebt in Model View, neben jeder anderen Trainings-Einstellung — die Strategie, wer pro Runde mitmacht, und das (ε, δ)-Privacy-Ziel; Clipping-Schranke und Rauschstärke lassen sich dort noch nicht einstellen —, und ein Privacy-Budget-Meter, dem du live zusehen kannst, sitzt im Rundenmonitor. Das Engineering ist konkret: Das Update-Format lässt einen föderierten Sprachmodell-Lauf kleine Adapter statt voller Gewichte tauschen — grob tausendmal weniger zu übertragen — und diese Updates zu komprimieren, ohne ihren Gehalt zu verlieren, ist das, was gewöhnliche Heimanschlüsse überhaupt erst tragfähig machen wird. Der Beitrag eines Standorts läuft noch nicht Ende zu Ende, ein föderierter Lauf hat im Produkt also noch nicht stattgefunden.
Das Privacy-Versprechen steht auf zwei Ebenen, weil sie sich unterscheiden. „Rohdaten verlassen das Gerät nie“ ist wahr für die Bytes, und das Übertragungsformat selbst erzwingt es: Es gibt schlicht kein Feld, in dem eine Rohprobe übertragen werden könnte. Ein Update aber ist eine Funktion der Daten — manchmal eine umkehrbare —, also hält die Zusage über die Information nur mit einer Untergrenze, die immer aktiv ist: Jedes Update, das einen Pool jenseits deiner eigenen Geräte verlässt, soll beschnitten werden und bilanziertes Privacy-Rauschen tragen, verbucht gegen ein Budget, das Überziehung verweigert, mit Secure Aggregation obendrauf, wo die Kohorte es zulässt — zwischen Institutionen verpflichtend und nie ein Ersatz für das Rauschen. Diese Untergrenze gilt noch nicht: Heute greift sie nur, wo ein Rezept ein Privacy-Ziel deklariert, das verbuchte ε wird übergeben statt berechnet, das Rauschen, inzwischen aus dem kryptografisch sicheren Zufallsgenerator des Browsers, wird noch von keinem Produktpfad angewendet, und Secure Aggregation setzt einen ehrlichen, aber neugierigen Server voraus. Regulierte Kohorten laufen in einem Konsortium und sonst nirgends.
Gezählt nach verifizierter Arbeit — nie nach der Uhr
| Fähigkeit | Status | Was es bedeutet |
|---|---|---|
| Freiwilliges Bündeln | im Aufbau | Eigene Geräte, Freiwillige, Konsortien — jedes angenommene Teil erzeugt einen Nachweis; kein Geld fließt. |
| Das Beitrags-Ledger | implementiert | Eine verkettete, manipulationssichere Historie — ein Eintrag entsteht durch Verifikation, nie durch verstrichene Zeit. |
| Kapazitätsangebote | implementiert | Die ungenutzte Hardware einer Maschine und ihre freien Stunden anbieten — und Jobs durchsuchen, die Rechenleistung suchen. |
| Für Rechenzeit bezahlen | ein benannter nächster Schritt | Treuhand, eine verfallbare Kaution und eine Anbieter-Sicherheit kommen zusammen als eine Einheit — oder gar nicht. |
| Der Copilot und Geld | strukturell gesperrt | Kein Assistent — unserer oder deiner — kann einen bezahlten Pool anlegen oder Geld bewegen; das verweigert der Bau des Systems, nicht eine Einstellung. |
Für Rechenzeit zu bezahlen ergänzt Zahlungswege, nie neue Mechanik — doch der Freiwilligen-Pool, der diese Maschinerie nutzen wird, ist selbst noch im Aufbau: Seine Teile sind implementiert und getestet, aber noch nicht Ende zu Ende über Browser hinweg gelaufen.
Annahme und Zählung sind dieselbe Grenze. Ein Ergebnis betritt das Ledger erst nach der Verifikation — heute dadurch, dass ein zweiter, unabhängiger Peer für dasselbe Teilstück exakt dasselbe Ergebnis zurückgibt; die Prüfung gegen die Referenz innerhalb einer deklarierten Toleranz und Stichproben, die ein Peer nicht vorhersagen kann, sind noch im Aufbau — und jede angenommene Einheit erzeugt einen Beitragsnachweis, dessen Kosten der Planner aus der Arbeit selbst ableitet, nie aus dem, was der Beitragende behauptet. Verstrichene Zeit wird nie gezählt: Sie lässt sich fälschen, sie bezahlt Langsamkeit, und sie ist blind dafür, ob die Antwort stimmte. In einer offenen Menge ist die angestrebte Garantie probabilistisch, ökonomisch und prüfbar — nie kryptografisch und absolut; heute wird eine erkannte Abweichung markiert, aber noch nicht korrigiert oder sanktioniert.
Was heute gebaut ist, ist die Maschinerie der Freiwilligen-Ökonomie: Pools aus eigenen Geräten, aus Freiwilligen und aus Konsortien — Beitragsnachweise, eine Beitragshistorie und Kapazitätsangebote, mit denen eine Maschine ungenutzte Hardware anbietet und Jobs durchsucht, die Rechenleistung suchen — im aktiven Aufbau, denn noch hat kein Browser einen gepoolten Job Ende zu Ende abgearbeitet. Das ist die Angebotsseite eines Marktes für Rechenzeit, den es noch nicht gibt: Dafür zu bezahlen ist ein benannter nächster Schritt und kommt als eine unteilbare Einheit — Treuhand, eine Kaution, die verfallen kann, eine Anbieter-Sicherheit —, denn auszuzahlen, ohne Betrug abzuschrecken, machte Schummeln profitabel. Das ist etwas anderes als der Marketplace, der Packs, Modelle und Datasets verkauft und niemals Rechenleistung. Und eine Regel gilt in jedem Tarif: Rechnen auf deinem eigenen Gerät wird überhaupt nie gezählt.