Fable5 महंगा हो रहा है, लोकल GPU कम पड़ रहे हैं: DRIFT, जो एक LLM को Mac और CUDA में बांटकर चलाता है

LLM अब व्यक्तियों की पहुंच से दूर जा रहे हैं, और DRIFT एक LLM को कई व्यक्तिगत डिवाइसों में बांटकर चलाकर इसका जवाब देता है.

DRIFT एक open source प्रोजेक्ट है जो एक LLM को कई व्यक्तिगत डिवाइसों पर layer स्तर पर बांटकर चलाता है.

आजकल अगर कोई व्यक्तिगत डेवलपर सीधे AI के साथ काम करना चाहे, तो दोनों ही रास्ते आसान नहीं हैं. Fable5 जैसे top-tier मॉडल तक पहुंच लगातार सीमित होती जा रही है, और लोकल मॉडल भी “मेरे कंप्यूटर पर चल सकता है” कहे जाने के बावजूद वास्तव में काफी ज्यादा GPU memory और setup मांगते हैं. मॉडल खुले हों, तब भी उन मॉडलों को पर्याप्त बड़े पैमाने पर चलाने की क्षमता अब भी कुछ हार्डवेयर और प्लेटफ़ॉर्म तक ही केंद्रित है. आखिरकार यह AI के लिए एक केंद्रीकृत माहौल बनाता है और व्यक्तियों की नवीनतम तकनीक तक पहुंच पर बड़ी सीमाएं लगाता है.

DRIFT का सवाल सरल है.

अगर एक मशीन पूरा मॉडल नहीं संभाल सकती, तो क्या कई व्यक्तिगत डिवाइस मिलकर एक ही मॉडल नहीं चला सकते?

DRIFT, Mac के Apple GPU (MPS) और Windows/Linux PC के NVIDIA GPU (CUDA) को साथ इस्तेमाल करके एक मॉडल चलाता है. यह मॉडल को decoder layer स्तर पर बांटता है, और nodes के बीच पूरे मॉडल या KV cache की जगह सिर्फ hidden state भेजता है. संचार PyTorch objects या CUDA handles से नहीं, बल्कि TCP + msgpack आधारित neutral byte protocol से किया जाता है.

मुख्य फीचर इस प्रकार हैं.

• एक LLM को decoder layer स्तर पर अपने-आप विभाजित करना
• Mac MPS और NVIDIA CUDA का mixed execution
• nodes के बीच संचार के लिए TCP + msgpack का उपयोग
• P2P chain mode से head node के bandwidth bottleneck को कम करना
• X25519, ChaCha20-Poly1305 आधारित encrypted wire
• Ed25519 signed receipts से हर node के काम का verification
• बीच में node बंद हो जाने पर re-split + replay आधारित failover
• OpenAI-compatible HTTP API उपलब्ध
• सिद्धांततः decoder layers की संख्या जितना विभाजन संभव. डिफ़ॉल्ट Qwen के आधार पर अधिकतम 28 मशीनों तक, और Gemma के आधार पर अधिकतम 35 मशीनों तक एक मॉडल को बांटकर चलाया जा सकता है; अभी व्यवहारिक sweet spot 2–4 मशीनों का है

इसी तरह की समस्या हल करने वाले प्रोजेक्ट्स में Exo और llama.cpp RPC शामिल हैं. Exo, Apple Silicon मशीनों को जोड़कर उन्हें लोकल cluster की तरह इस्तेमाल करने देता है, लेकिन nodes के बीच communication MLX पर निर्भर होने के कारण Apple ecosystem से बाहर जाना मुश्किल है. llama.cpp RPC कई backends का उपयोग कर सकता है, लेकिन वह ggml/llama.cpp runtime से जुड़ा RPC तरीका है. DRIFT की खास बात यह है कि उसने nodes के बीच की boundary को किसी खास ML runtime की बजाय neutral byte protocol तक उठाया है. इसलिए इसका फोकस Apple MPS और NVIDIA CUDA जैसे उन संयोजनों को एक ही मॉडल execution में शामिल करने पर है, जिन्हें सामान्य distributed runtime में रखना मुश्किल होता है.

DRIFT का implementation Python और PyTorch पर है, लेकिन nodes के बीच का contract PyTorch पर निर्भर नहीं रखा गया है. मॉडल loading और execution के लिए यह Hugging Face Transformers, safetensors, और PyTorch MPS/CUDA का उपयोग करता है, और बाहर की तरफ Starlette/Uvicorn आधारित OpenAI-compatible API देता है. अंदरूनी communication msgpack framing और encryption layer में लिपटी हुई है, इसलिए इसका design “कौन सा मॉडल किस डिवाइस पर चल रहा है” और “nodes आपस में कौन से bytes का आदान-प्रदान कर रहे हैं” इन दोनों बातों को अलग करने की कोशिश करता है.

व्यक्तिगत रूप से यह प्रोजेक्ट इसलिए दिलचस्प लगता है क्योंकि यह “AI decentralization” की शुरुआत सीधे token economy या विशाल नेटवर्क की कहानी से नहीं करता. पहले ज़रूरत एक ऐसे execution layer की है जिसमें व्यक्तिगत डिवाइस सचमुच एक ही मॉडल चलाने में भाग ले सकें. यह verify किया जा सके कि किसने कौन-सी layer compute की, node हट जाए तो recovery हो सके, और संरचना किसी खास vendor या datacenter से बंधी न हो—तभी उसके ऊपर बड़ा नेटवर्क बनाया जा सकता है.

DRIFT speed को आगे रखने वाला प्रोजेक्ट नहीं है. बल्कि इसकी प्राथमिकता correctness है. इसका जोर इस बात पर है कि distributed तरीके से चलाने पर वही जवाब मिले या नहीं जो single machine पर चलाने से मिलता है. README के अनुसार Qwen2.5-1.5B-Instruct पर इसने कई parity gates पार किए हैं, और Mac MPS व NVIDIA CUDA को मिलाकर किए गए प्रयोग भी शामिल हैं.

जब top-tier AI मॉडल लगातार बंद होते जा रहे हैं, और लोकल AI अब भी महंगे हार्डवेयर की मांग करता है, तब DRIFT एक काफी व्यावहारिक सवाल उठाता है.

जब frontier models व्यक्तिगत ग्राहकों से दूर होते जा रहे हों, तब क्या व्यक्तिगत संसाधनों को जोड़कर उनकी ताकत बढ़ाई जा सकती है?

GitHub: https://github.com/TaewoooPark/DRIFT

[theoverstructure]

DRIFT गति की दौड़ से ज़्यादा यह देखने वाला प्रोजेक्ट है कि क्या अलग-अलग तरह के निजी डिवाइसों पर एक ही LLM को सटीक ढंग से बाँटकर चलाया जा सकता है!

खासकर Exo / llama.cpp RPC / Petals से तुलना करने पर इसका अंतर कितना ठोस और भरोसेमंद है, और MPS↔CUDA mixed execution में प्रोडक्शन/वर्कप्लेस स्तर पर जिन अतिरिक्त बातों की ज़रूरत पड़ती है, उन पर आप सभी की राय और feedback जानना चाहूँगा।