Fable5 wird teurer, lokale GPUs sind knapp: DRIFT verteilt ein LLM auf Mac & CUDA
(github.com/TaewoooPark)LLMs entfernen sich von Einzelpersonen, und DRIFT hält dagegen, indem es ein einzelnes LLM auf mehrere persönliche Geräte verteilt.
DRIFT ist ein Open-Source-Projekt, das ein einzelnes LLM schichtweise auf mehreren persönlichen Geräten ausführt.
Wer als einzelner Entwickler heute direkt mit AI experimentieren will, hat es auf beiden Seiten nicht leicht. Der Zugang zu Spitzenmodellen wie Fable5 wird zunehmend eingeschränkt, und lokale Modelle verlangen in der Praxis – anders als die Aussage „läuft auf meinem Rechner“ suggeriert – recht viel GPU-Speicher und Setup-Aufwand. Selbst wenn die Modelle offen sind, bleibt die Fähigkeit, sie in ausreichend großer Größenordnung auszuführen, weiterhin auf bestimmte Hardware und Plattformen konzentriert. Das schafft letztlich ein zentralisiertes AI-Umfeld und begrenzt stark, in welchem Maß Einzelpersonen Zugang zu aktueller Technologie haben.
Die Frage, die DRIFT stellt, ist einfach.
Wenn eine einzelne Maschine das gesamte Modell nicht stemmen kann: Können dann nicht mehrere persönliche Geräte gemeinsam ein Modell ausführen?
DRIFT führt ein einzelnes Modell aus, indem es die Apple GPU (MPS) eines Mac gemeinsam mit NVIDIA GPUs (CUDA) auf Windows-/Linux-PCs nutzt. Das Modell wird auf Ebene der Decoder-Schichten aufgeteilt, und zwischen den Nodes wird nicht das gesamte Modell oder der KV-Cache übertragen, sondern nur der Hidden State. Die Kommunikation erfolgt nicht über PyTorch-Objekte oder CUDA-Handles, sondern über ein neutrales Byte-Protokoll auf Basis von TCP + msgpack.
Die wichtigsten Funktionen sind:
- Automatische Aufteilung eines einzelnen LLMs auf Ebene der Decoder-Schichten
- Gemischte Ausführung mit Mac MPS und NVIDIA CUDA
- TCP + msgpack für die Kommunikation zwischen Nodes
- P2P-Chain-Modus zur Verringerung des Bandbreiten-Flaschenhalses am Head-Node
- Verschlüsselter Wire auf Basis von X25519 und ChaCha20-Poly1305
- Verifikation der Arbeit jedes Nodes über signierte Ed25519-Receipts
- Failover auf Basis von Re-Split + Replay, wenn ein Node zwischendurch ausfällt
- OpenAI-kompatible HTTP API
- Theoretisch ist eine Aufteilung bis zur Anzahl der Decoder-Schichten möglich. Beim Standardmodell Qwen kann ein Modell auf bis zu 28 Geräte verteilt werden, bei Gemma auf bis zu 35; der derzeit realistische Sweet Spot liegt bei 2 bis 4 Geräten.
Projekte, die ein ähnliches Problem lösen, sind Exo und llama.cpp RPC. Exo kann Apple-Silicon-Geräte wie einen lokalen Cluster zusammenschalten, doch die Kommunikation zwischen Nodes ist an MLX gebunden, wodurch es schwierig ist, das Apple-Ökosystem zu verlassen. llama.cpp RPC kann mehrere Backends nutzen, ist aber ein RPC-Ansatz, der an die ggml/llama.cpp-Runtime gekoppelt ist. Der Unterschied von DRIFT liegt darin, dass die Grenze zwischen Nodes nicht über eine bestimmte ML-Runtime definiert wird, sondern auf ein neutrales Byte-Protokoll angehoben wurde. Der Fokus liegt daher darauf, Kombinationen wie Apple MPS und NVIDIA CUDA, die ursprünglich schwer in dieselbe verteilte Runtime zu integrieren sind, innerhalb einer einzelnen Modellausführung zusammenzubringen.
DRIFT ist zwar auf Python und PyTorch implementiert, aber der Vertrag zwischen den Nodes ist so gestaltet, dass er nicht von PyTorch abhängt. Für Modell-Loading und Ausführung nutzt es Hugging Face Transformers, safetensors sowie PyTorch MPS/CUDA; nach außen stellt es eine OpenAI-kompatible API auf Basis von Starlette/Uvicorn bereit. Die interne Kommunikation ist in msgpack-Framing und eine Verschlüsselungsschicht gekapselt. Das Design zielt darauf ab, „welches Modell auf welchem Device läuft“ von „welche Bytes die Nodes austauschen“ zu trennen.
Was dieses Projekt für mich interessant macht, ist, dass es „AI-Dezentralisierung“ nicht sofort mit Token-Ökonomien oder großen Netzwerkvisionen beginnt. Zunächst braucht es eine Ausführungsschicht, mit der persönliche Geräte tatsächlich an der Ausführung eines einzelnen Modells teilnehmen können. Erst wenn man prüfen kann, wer welche Schicht berechnet hat, wenn sich der Ausfall von Nodes abfangen lässt und wenn die Architektur nicht an einen bestimmten Anbieter oder ein Rechenzentrum gebunden ist, kann man darauf ein größeres Netzwerk aufbauen.
DRIFT ist kein Projekt, das Geschwindigkeit in den Vordergrund stellt. Priorität hat vielmehr Korrektheit. Der Schwerpunkt liegt darauf zu überprüfen, ob eine verteilte Ausführung dieselben Antworten liefert wie die Ausführung auf einer einzelnen Maschine. Laut README hat Qwen2.5-1.5B-Instruct mehrere Parity-Gates bestanden; enthalten sind auch Experimente mit einer Mischung aus Mac MPS und NVIDIA CUDA.
In einer Situation, in der Spitzenmodelle der AI zunehmend geschlossen werden und lokale AI weiterhin teure Hardware verlangt, stellt DRIFT eine ziemlich realistische Frage.
Wenn Frontier-Modelle sich von Privatkunden entfernen: Können Einzelpersonen ihre Ressourcen bündeln und so ihre Schlagkraft erhöhen?
1 Kommentare
DRIFT ist ein Projekt, das weniger auf einen Geschwindigkeitswettbewerb abzielt, sondern zunächst darauf, ob sich ein einzelnes LLM auf heterogenen persönlichen Geräten korrekt aufteilen und ausführen lässt!
Insbesondere im Vergleich zu Exo / llama.cpp RPC / Petals möchte ich viele von Ihnen um Ihre Einschätzungen und Ihr Feedback bitten: ob die Differenzierungsmerkmale ausreichend überzeugend sind und welche zusätzlichen Punkte beim gemischten Betrieb MPS↔CUDA in der Praxis erforderlich wären.