Warum der Schwarm eine ganze Anfrage an ein Gerät schickt
Veröffentlicht
Das verbreitete Bild eines Compute-Swarms ist ein großes Modell, auf viele Maschinen verteilt. Dieses Bild stammt aus Rechenzentren, in denen die Verbindungen zwischen Beschleunigern genau für diesen Verkehr gebaut wurden. Ein Schwarm aus Geräten, die Menschen ohnehin besitzen, hat solche Verbindungen nicht. Als das Design dieses Projekts aufgeschrieben wurde, bestand die erste Entscheidung darin, das nicht länger vorzutäuschen.
Die Rechnung, die Modellparallelität hier beendet hat
Eine einzelne Vorwärtsberechnung über Geräte aufzuteilen heißt, Aktivierungen zwischen den Schichten auszutauschen, die auf verschiedenen Maschinen liegen. Das Architektur-Dokument rechnet diesen Austausch mit eigenen Zahlen durch und nennt sie, was sie sind: eine Entwurfsrechnung, keine Messung. In diesem Projekt ist kein echtes Modell gelaufen und es werden keine Gewichte geladen; nichts davon ist ein Benchmark.
- Für ein 7B-Modell mit Hidden Size 4096 in bf16 schätzt das Architektur-Dokument der Schwarm-Spezifikation rund 8 KB Aktivierungsaustausch pro Token an jeder Gerätegrenze, über die 20 bis 60 ms Round-Trip-Zeit, die es für eine Consumer-Leitung nennt. Das ist die Schätzung der Spezifikation und keine Messung; das Warten wird zu den Kosten, nicht das Rechnen.
- Dieselbe Schätzung der Spezifikation landet bei einem 70B-Modell oberhalb von etwa 32 KB pro Schichtschritt, und das Architektur-Dokument nennt das über Consumer-Leitungen unbrauchbar.
- Ein Modell aufzuteilen erkauft also Latenz, die mit jedem weiteren Gerät schlechter wird. Das Dokument ist deutlich: Ein Schwarm, der ein Modell über tausende Telefone verspricht und nur schneller sein soll, beschreibt eine Rechenzentrumsverbindung auf Hardware, die keine hat.
Was die Arbeitseinheit tatsächlich ist
Die Arbeitseinheit ist eine ganze Anfrage: eine Completion, eine Klassifikation, ein Embedding, an ein Gerät geschickt, das dieses Modell bereits hält. Der Koordinator leitet einen verschlüsselten Umschlag weiter und reicht das verschlüsselte Ergebnis zurück; das Architektur-Dokument ist sorgfältig bei der Frage, was das kostet. Der Koordinator sieht Routing-Metadaten wie Job-ID, Empfänger, Größe, TTL und Modellklasse. Er sieht weder Prompt noch Modellausgabe noch Ergebnis, weil diese in einem Umschlag reisen, den er nicht öffnen kann.
Die Routing-Felder liegen innerhalb der authentifizierten Daten des Umschlags und nicht daneben. Das ist eine Entwurfsentscheidung mit benennbarer Folge: Ein Koordinator, der Empfänger oder Ablaufzeit ändert, um sich selbst zu helfen, macht den Job kaputt, statt still erfolgreich zu sein.
Warum ein Gerät eine ganze Anfrage übernehmen kann
- Ein Job geht nur an ein Gerät, das das Modell bereits hält; eine Planungsentscheidung kann also keinen Download von mehreren Gigabyte auf einer Maschine beginnen, die das Netz vielleicht vorher verlässt.
- Freier Speicher ist ein hartes Filterkriterium und keine Punktzahl. Ein Modell, das nicht passt, scheitert erst beim Laden, also nachdem der Job angenommen wurde; deshalb wird die Untergrenze vor dem Versand geprüft.
- Consumer-Geräte schlafen, drosseln und trennen die Verbindung, deshalb sind Leases kurz, ein Ablauf führt zur Neuvergabe an ein anderes Gerät mit demselben Modell, und die Job-ID unterscheidet einen Wiederholungsversuch von einem Replay.
- Capability-Epochen entziehen älteren Ansprüchen und Schlüsselmaterial die Gültigkeit, ohne eine Zertifizierungsstelle zu brauchen.
Die drei Dinge, für die sich das Design stattdessen entschieden hat
Sobald die Vorwärtsberechnung vom Tisch ist, bleiben drei Muster übrig, die eine Consumer-Leitung überstehen. Sie verdienen eine eigene Nennung, weil sie keine drei Varianten derselben Idee sind.
- Unabhängige Jobs auf unabhängigen Geräten: die Einheit, die dieses Projekt tatsächlich festlegt.
- Replikation für Zuverlässigkeit und Verifikation: dieselbe ganze Anfrage anderswo laufen lassen und vergleichen – genau dafür zahlt die Abrechnungs-Ebene.
- Erst prüfen, dann vertrauen, bei ausgewählten Ergebnissen: den zweiten Lauf nur dort aufwenden, wo die Antwort eine Prüfung wert ist.
Die Geräteklassen sagen dasselbe von der anderen Seite. Telefone und Tablets gelten als Worker für kleine Modelle, die erwartungsgemäß mitten im Job verschwinden, Laptops als Mainstream-Worker, der einem integrierten Grafikchip ein kleines Modell überlässt, und Workstations als zuverlässige Stufe, die üblicherweise prüft. Ein Design, das davon abhinge, dass sich eine dieser Klassen wie ein Rechenzentrum verhält, wäre bei allen dreien kaputt.
Was der Schwarm wirklich bringt
Kapazität, Jurisdiktion und Ausfallsicherheit, in dieser Reihenfolge, und nicht Latenz für eine einzelne Anfrage. Das sind drei andere Produkte als das, was das verbreitete Bild beschreibt, und das früh zu sagen hält das übrige Design ehrlich.
Tatsächlich gelaufen ist bisher ein Mock-Backend über echtes HTTP, und der Status sagt es klar: Weder lief irgendwo echte Modellinferenz noch eine echte GPU. Die nächste Phase ist eine llmeu.com-Seite, die benennt, was gemessen wurde, ein Einstieg zum Beisteuern eines Geräts und eine Inhaltsoberfläche, die aus der Modellregistry erzeugt wird statt aus handgeschriebenen Behauptungen.
Quellen
Jeder Link führt zu der Quelle, die der Beitrag nennt. Wo eine Quelle eine Angabe nicht hergibt, zeigt der Beitrag sie als unverified, statt sie zu füllen.