§ 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 jedes Ergebnis wird verifiziert, bevor es zählt. Derselbe Mechanismus spannt sich über deine eigenen Maschinen, ein Konsortium zugelassener Institutionen und eine offene Menge Fremder — drei Vertrauensstufen, die die Plattform nie vermischt.
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 auf exakt demselben Codepfad — 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, unvorhersehbar stichprobengeprüft 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 verschmelzen zu einem Cluster, 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 verteilen sich zwischen den Peers, statt einzeln aus einer einzigen Quelle herauszufächern — ein großes Dataset wird so nicht zum Nadelöhr. Ergebnisse werden erst eingefaltet, nachdem sie die Verifikation bestanden haben — eine schlechte Stichprobe lässt sich aus einem laufenden Mittelwert nicht wieder herausrechnen — und lange Simulationen strömen durch Akkumulatoren konstanter Größe, statt Millionen Samples im Speicher aufzutürmen. Ein Sweep füllt sich Teil für Teil, während er läuft; der Guide zu verteiltem Rechnen geht einen komplett durch.
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 — Tausende Peers | 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 | Unabhängige Seeds; erst nach der Verifikation in einen Akkumulator konstanter Größe eingefaltet. |
| Training im Gleichschritt | sublinear — Dutzende stabile Peers | Alle warten auf den Langsamsten; es wächst durch seltenere Synchronisation, nie durch tiefere Koordination. |
| 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 bis zu Tausenden Peers ist real — und präzise begrenzt: Er gilt für Arbeit, deren Teile nie aufeinander warten müssen. Training, das im Gleichschritt bleibt, ist sublinear — langsame Peers und zugeklappte Laptops begrenzen es auf grob Dutzende stabile Peers —, und es wächst, indem seltener synchronisiert wird, nicht durch tiefere Koordination. 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: Ein Beitrag zählt auf einem Gerät im Vordergrund, dediziert oder am Netzteil. 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 nicht: Der Großteil der Bytes bewegt sich von Gerät zu Gerät, und in den meisten Heim- und Mobilfunknetzen steht diese Verbindung direkt.
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. 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, wie stark jedes Update beschnitten wird und wie viel Rauschen es trägt, dazu ein Privacy-Budget-Meter, dem du live zusehen kannst. Das Engineering ist konkret: Ein föderierter Sprachmodell-Lauf tauscht kleine Adapter statt voller Gewichte — grob tausendmal weniger zu übertragen — und diese Updates zu komprimieren, ohne ihren Gehalt zu verlieren, ist das, was gewöhnliche Heimanschlüsse überhaupt tragfähig macht.
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, wird beschnitten und trägt bilanziertes Privacy-Rauschen, 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. 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 | heute live | Eigene Geräte, Freiwillige, Konsortien — jedes angenommene Teil erzeugt einen Nachweis; kein Geld fließt. |
| Das Beitrags-Ledger | heute live | Eine verkettete, manipulationssichere Historie — ein Eintrag entsteht durch Verifikation, nie durch verstrichene Zeit. |
| Kapazitätsangebote | heute live | 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. |
Nichts davon liegt in der Schublade: Der Freiwilligen-Pool nutzt heute jeden Teil davon — für Rechenzeit zu bezahlen ergänzt Zahlungswege, nie neue Mechanik.
Annahme und Zählung sind dieselbe Grenze. Ein Ergebnis betritt das Ledger erst nach der Verifikation — gegen die Referenz nachgerechnet, innerhalb einer deklarierten Toleranz, stichprobengeprüft zu Zeitpunkten, die ein Peer nicht vorhersagen kann, oder von mehreren Peers bestätigt, wo es keine Referenz gibt — 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 resultierende Garantie probabilistisch, ökonomisch und prüfbar — nie kryptografisch und absolut.
Was heute läuft, ist die 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. 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.