Verteiltes Rechnen: Pools, Jobs und Vertrauen

Scellis hat für verteiltes Rechnen genau einen Mechanismus. Ein inhaltsadressierter Job wird in Shards partitioniert, die Shards führt ein Pool aus Peers aus, die Ergebnisse kombiniert eine deklarierte Reduction, und jedes Ergebnis wird verifiziert, bevor es akzeptiert wird. Das ist das ganze Modell. Ein Pool der Größe eins ist ein gewöhnlicher Solo-Run — derselbe Codepfad, vollständig offline. Federated Learning ist eine Konfiguration desselben Mechanismus, nie ein eigenes Subsystem. Was sich über diese Spannweite ändert, ist nicht die Maschinerie, sondern das Vertrauen drumherum — und diese Seite benennt die Grenzen so klar wie die Fähigkeiten.

Ein Mechanismus, viele Workloads#

Pooling ist kein Trainings-Feature. Parameter-Sweeps, Monte-Carlo-Simulationen, Ensembles, k-fache Kreuzvalidierung und Batch-Analysen fahren alle auf demselben Weg Job → Shard → Reduction, weil sie eine Form teilen: unabhängige Teile plus eine deklarierte Art, sie zu kombinieren. Training fährt ebenfalls darauf — als eine Konfiguration, nicht als privilegierte. Und die Arbeit rendert live, während Shards landen: Die Heatmap eines Sweeps füllt sich Zelle für Zelle, ein Trainingslauf zeichnet eine konvergierende Loss-Kurve, der alle in einer geteilten Session gleichzeitig zusehen.

Alles Strategieförmige in diesem Mechanismus ist Content, nie Engine-Code. Partitionierer, Reducer, Aggregationsstrategien — FedAvg, FedProx, SCAFFOLD, DiLoCo und FedBuff sind eingebauter Content — und die Pool-Topologie sind von Nutzern erstellbare Entitäten wie jeder Block, nie ein hartkodierter Switch. Fehlt die Aggregationsstrategie, die du brauchst, schreibst du sie selbst — und sie nimmt denselben Katalogweg wie alles andere.

Drei Vertrauensregime, nie vermischt#

Wer in deinem Pool ist, ändert, was sicher ist — also weigert sich Scellis, das zu verwischen. Es gibt drei Vertrauensregime, und die Plattform verschmilzt sie nie zu einer beruhigenden Einstellung.

Die Grenzen werden erzwungen, nicht empfohlen. Eine sicherheitskritische Konfiguration weigert sich, auf einem offenen Pool zu starten — laut, per Konstruktion, im selben Diagnoseformat wie jede andere Ablehnung der Plattform. Und offene datenparallele Arbeit ist auf öffentliche Eingabedaten beschränkt — denn dass Fremde Shards über privaten Daten rechnen, ist keine Einstellung, die man versehentlich erreichen können sollte. Die Umkehrung ist genauso ehrlich: Ein vertrauliches Modell oder ein vertraulicher Datensatz verweigert den offenen Pool, denn ausführende Peers halten notwendig, worauf sie rechnen.

Bei Ankunft verifiziert, in Receipts gemessen#

Einem entfernten Ergebnis wird bei Ankunft nie vertraut. Je nachdem, was der Job deklariert, wird es gegen die deterministische CPU-Referenz innerhalb einer deklarierten Toleranz geprüft, in einem unvorhersehbaren Anteil stichprobengeprüft oder quorum-repliziert über unabhängige Peers gerechnet — und erst dann in die Reduction aufgenommen. Freivalds-Wahrscheinlichkeitsprüfungen senken die Kosten des Verifizierers bei Matmuls, und bezahlte Verifizierer werden selbst durch eingestreute Canary-Shards mit bekannter Antwort ehrlich gehalten. Das volle Verifikationsregime ist die Korrektheits-Geschichte, über Geräte hinweg erweitert.

Akzeptierte Arbeit prägt ein Receipt in einem hash-verketteten Ledger, und Beiträge werden in verifizierten Work-Units gemessen, nie in verstrichener Zeit — verstrichene Zeit bezahlt Langsamkeit und lässt sich fälschen. Jede Einheit trägt einen vom Planner abgeleiteten Preis, den der Anbieter nicht aufblähen kann. Altruistisches Pooling — deine eigenen Geräte, Freiwillige, ein Konsortium — ist heute vollständig live und kommt ohne jede Zahlungsschiene aus. Der bezahlte Compute-Marktplatz mit Auszahlungen, Treuhand und Staking steht noch aus — er ist benannt und wird auf genau diesen Receipts gebaut; er erscheint als eine unteilbare Einheit, denn Auszahlungen vor den Betrugsbremsen auszuliefern würde Sybil-Farming profitabel machen.

Was skaliert — und was nicht#

Synchronisiertes Training ist das Spiel einer stabilen Kohorte, nie eines offenen Schwarms: Peers müssen Updates austauschen, und dieser Austausch — nicht das Rechnen — wird zur Wand; Churn statt Arithmetik ist die dominante Kostenquelle. Hinter „Skalierung“ versteckt sich eine zweite Grenze, die ihren eigenen Satz verdient: Datenparalleles Pooling repliziert das volle Modell auf jedem Peer. Es multipliziert Durchsatz, aber es kann kein Modell unterbringen, das für ein einzelnes Gerät zu groß ist. Größere Modelle sind ein anderer Weg — der Relay-Pfad, bei dem Layer über Geräte hinweg gereicht werden, oder sharded Optimizer-State. Ein numerischer Speedup-Multiplikator wird nie versprochen; die benannten Mechanismen sind die Aussage. Die Seite der ehrlichen Grenzen führt jede davon auf — Fehlerbalken für Fehlerbalken.

Fair zu Freiwilligen, ehrlich über das Netzwerk#

Ein Shard, den du für jemand anderen ausführst, läuft als reiner Compute ohne Effekt-Grants: Er kann deine lokalen Daten, deine Credentials und dein Netzwerk strukturell nicht lesen. Du behältst einen Budget-Regler — eine Batterie-Untergrenze, einen Stopp in zwei Klicks. Und Beitragen braucht ein Gerät im Vordergrund am Strom, denn der Browser friert Hintergrund-Tabs ein: Ein Tab im Hintergrund rechnet nicht, und Scellis tut nicht so, als ob.

Pooled Compute ist außerdem nicht serverlos, und diese Seite wird es nicht so nennen. Eine Pool-Session braucht für ihre Dauer einen Online-Koordinator — „serverlos“ beschreibt die Datenebene auf kooperativen Netzen, nie die Kontrollebene. Der Koordinator plant Shards und vermittelt Verbindungen; auf dem Happy Path berührt er nie Tensor-Bytes (ein Koordinator-Objekt kann keinen Tensor summieren — nur Peers reduzieren), und für Solo-Arbeit wird er nie gebraucht. In kooperativen Netzen gehen die meisten Heimverbindungen direkt Peer-to-Peer via STUN, ohne Relay-Kosten; symmetrische und Firmen-NATs fallen auf ein Relay zurück, das dann der ehrliche Dauerzustand für dieses Setting ist. Sehr große Pools föderieren den Koordinator in einen hierarchischen Baum, damit der Control-Fan-out beschränkt bleibt.

Federated Learning: Was einen Standort wirklich verlässt#

Federated Learning ist die Konfiguration, in der die Daten liegen bleiben und das Modell wandert. Rohdaten verlassen einen teilnehmenden Standort nie als Bytes. Aber Modell-Updates verlassen ihn — und ein Update ist eine verlustbehaftete, manchmal invertierbare Funktion der Daten, aus denen es berechnet wurde. Byte-Ausschluss allein ist deshalb keine Privacy-Garantie, und Scellis präsentiert ihn nie als eine.

Darum ist bilanzierte Differential Privacy mit Clipping für jedes Regime jenseits deiner eigenen Geräte immer aktiv, verfolgt von einem monotonen Privacy-Budget-Ledger, das Überziehung verweigert — eine live (ε,δ)-Anzeige sitzt im Rundenmonitor. Secure Aggregation kommt obendrauf, wo machbar, und ist in Cross-Silo-Konstellationen verpflichtend; sie verbirgt jedes einzelne Update, gibt aber das Aggregat frei — sie ersetzt DP also nicht. Und auch hier bleibt die Skalierungsaussage ehrlich: Federated Learning bringt statistische Aussagekraft — mehr teilnehmende Standorte, mehr lokale Beispiele hinter dem Modell — kein schnelleres Wallclock-Tempo.

Ein Mechanismus, drei Vertrauensregime, Receipts statt verstrichener Zeit — und Grenzen, die im Datenblatt stehen, statt in der Produktion entdeckt zu werden. Reproduzierbarkeit ist zweistufig deklariert — replayable auf dem Oracle-Pfad und konvergent innerhalb der Toleranz auf dem GPU-Pfad —, sodass ein verteiltes Ergebnis committete Versionen zitiert, nie einen geräteübergreifenden Hash. Und ein Pool der Größe eins ist dieselbe Maschine — sie läuft mit gezogenem Netzwerkkabel.