Fable5 pahalanıyor, yerel GPU’lar yetersiz kalıyor: Tek bir LLM’i Mac ve CUDA arasında paylaştırarak çalıştıran DRIFT
(github.com/TaewoooPark)LLM’ler bireylerden uzaklaşıyor ve DRIFT buna karşı tek bir LLM’i birden fazla kişisel cihaza bölerek çalıştırıyor.
DRIFT, tek bir LLM’i katman düzeyinde birden fazla kişisel cihaza bölerek çalıştıran açık kaynaklı bir projedir.
Bugünlerde bireysel geliştiriciler yapay zekayı doğrudan kullanmaya çalıştığında, her iki tarafta da iş kolay değil. Fable5 gibi en üst düzey modeller giderek daha kısıtlı erişilebilir hale gelirken, yerel modeller de “kendi bilgisayarında çalıştırabilirsin” denmesine rağmen pratikte oldukça yüksek GPU belleği ve kurulum gerektiriyor. Modeller açık olsa bile, bu modelleri yeterince büyük ölçekte çalıştırabilme yeteneği hâlâ belirli donanım ve platformlarda yoğunlaşıyor. Sonuçta bu, yapay zeka için merkeziyetçi bir ortam oluşturuyor ve bireylerin en güncel teknolojiye erişiminde büyük sınırlamalar yaratıyor.
DRIFT’in sorduğu soru basit.
Tek bir makine modelin tamamını taşıyamıyorsa, birden fazla kişisel cihaz tek bir modeli birlikte çalıştıramaz mı?
DRIFT, Mac’teki Apple GPU’yu (MPS) ve Windows/Linux PC’lerdeki NVIDIA GPU’yu (CUDA) birlikte kullanarak tek bir modeli çalıştırır. Modeli decoder layer düzeyinde böler ve düğümler arasında modelin tamamını ya da KV cache’i değil, yalnızca hidden state’i gönderir. İletişim de PyTorch nesneleri veya CUDA handle’larıyla değil, TCP + msgpack tabanlı nötr bir bayt protokolüyle yürütülür.
Başlıca özellikler şöyle:
- Tek bir LLM’i decoder layer düzeyinde otomatik bölme
- Mac MPS ve NVIDIA CUDA karma çalıştırma
- Düğümler arası iletişimde TCP + msgpack kullanımı
- Head düğümündeki bant genişliği darboğazını azaltmak için P2P chain modu
- X25519, ChaCha20-Poly1305 tabanlı şifreli wire
- Her düğümün işini doğrulamak için Ed25519 imzalı makbuzlar
- Düğüm arada düşerse re-split + replay tabanlı failover
- OpenAI uyumlu HTTP API sunumu
- Teorik olarak decoder layer sayısı kadar bölünebilme. Varsayılan Qwen temelinde en fazla 28 makineye, Gemma temelinde ise en fazla 35 makineye kadar tek bir modeli bölerek çalıştırmak mümkün; şu an pratikte en uygun aralık 2–4 makine seviyesi
Benzer problemi çözen projeler arasında Exo ve llama.cpp RPC bulunuyor. Exo, Apple Silicon cihazlarını bir araya getirip yerel bir küme gibi kullanabiliyor, ancak düğümler arası iletişim MLX tarafına bağlı olduğu için Apple ekosisteminin dışına çıkmak zor. llama.cpp RPC ise birden fazla backend kullanabiliyor, fakat ggml/llama.cpp runtime’ına bağlı bir RPC yaklaşımı. DRIFT’in farkı, düğümler arasındaki sınırı belirli bir ML runtime’ına değil, nötr bir bayt protokolüne yükseltmiş olması. Bu nedenle Apple MPS ve NVIDIA CUDA gibi, normalde aynı dağıtık runtime içine koyması zor kombinasyonları tek bir model yürütmesinin içinde birleştirmeye odaklanıyor.
DRIFT’in uygulaması Python ve PyTorch üzerinde olsa da, düğümler arasındaki sözleşme PyTorch’a bağımlı olmayacak şekilde tasarlanmış. Model yükleme ve yürütme için Hugging Face Transformers, safetensors, PyTorch MPS/CUDA kullanılıyor; dışarıya ise Starlette/Uvicorn tabanlı, OpenAI uyumlu bir API sunuluyor. İç iletişim msgpack framing ve şifreleme katmanıyla sarılmış durumda; yani tasarım, “hangi modelin hangi cihazda çalıştırıldığı” ile “düğümlerin hangi baytları alıp verdiği”ni birbirinden ayırmayı hedefliyor.
Bence bu projeyi ilginç kılan şey, “yapay zekanın merkezsizleşmesi” meselesine token ekonomisi veya dev ağ hikâyeleriyle başlamaması. Önce gerçekten gerekli olan şey, kişisel cihazların tek bir model yürütmesine katılabildiği bir yürütme katmanı. Kimin hangi katmanı hesapladığı doğrulanabilmeli, düğüm devre dışı kalsa bile sistem toparlanabilmeli ve belirli bir satıcıya ya da veri merkezine bağlı olmayan bir yapı bulunmalı ki bunun üzerine daha büyük ağlar kurulabilsin.
DRIFT hız odaklı bir proje değil. Hatta önceliği doğruluk. Dağıtık çalıştırıldığında, tek makinede çalıştırılan sonuçla aynı cevabın çıkıp çıkmadığını doğrulamaya ağırlık veriyor. README’ye göre Qwen2.5-1.5B-Instruct üzerinde çeşitli parity gate’leri geçti ve Mac MPS ile NVIDIA CUDA’nın birlikte kullanıldığı deneyler de buna dahil.
En üst düzey yapay zeka modelleri giderek daha kapalı hale gelirken ve yerel yapay zeka hâlâ pahalı donanım gerektirirken, DRIFT oldukça gerçekçi bir soru ortaya atıyor.
Frontier modeller bireysel kullanıcılardan uzaklaşırken, bireylerin kaynaklarını bir araya getirip bu gücü artırmak mümkün olabilir mi?
1 yorum
DRIFT, hız yarışından ziyade heterojen kişisel cihazlarda tek bir LLM’yi doğru şekilde bölüştürüp çalıştırmanın mümkün olup olmadığına önce bakan bir proje!
Özellikle Exo / llama.cpp RPC / Petals tarafıyla karşılaştırıldığında farklılaştırıcı noktalarının yeterince ikna edici olup olmadığı ve MPS↔CUDA karma yürütme üzerinde gerçek dünyadaki işlerin gerektirdiği ek noktalar hakkında birçok kişinin görüş ve geri bildirimlerini rica ediyorum.