Mesh LLM - iroh-आधारित वितरित AI कंप्यूटिंग

 (iroh.computer)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कई मशीनों में बिखरे GPU और मेमोरी को एक ही कंप्यूटिंग संसाधन के रूप में जोड़कर, लोकल execution, peer forwarding और split execution को एक OpenAI-compatible API के जरिए उपलब्ध कराता है
  • रिक्वेस्ट लोकल GPU या मॉडल लोड किए हुए peer पर प्रोसेस होती हैं, और जो मॉडल एक मशीन में फिट नहीं होते उन्हें कई नोड्स में pipeline stages में बांटकर चलाया जा सकता है
  • plugin-आधारित catalog में लैपटॉप के लिए 500M parameter models से लेकर 235B MoE models तक 40 से अधिक मॉडल शामिल हैं, और client अंदरूनी batching की परवाह किए बिना सिर्फ localhost:9337/v1 को कॉल करता है
  • हर node एक iroh endpoint चलाता है, जो public key को ID और एकमात्र नेटवर्क surface दोनों की तरह इस्तेमाल करता है, और central server के बिना NAT traversal, hole punching और relay fallback paths के जरिए authenticated QUIC connection बनाता है
  • लगभग 18MB software से public mesh या private deployment बनाया जा सकता है, और आगे चलकर iroh Swift SDK तथा ACP को सपोर्ट करने वाले mobile apps के जरिए बंद सर्वरों पर निर्भरता कम करने की योजना है

बाहरी data center की जगह मौजूदा hardware का उपयोग

  • आम तौर पर LLM इस्तेमाल करने का तरीका बाहरी providers के GPU data centers और usage-based APIs पर निर्भर होता है, इसलिए usage बढ़ने के साथ लागत भी बढ़ती है
  • जब prompts बाहरी services को भेजे जाते हैं, तो user के लिए इन बातों पर सीधे नियंत्रण रखना मुश्किल होता है
    • मॉडल कब update होगा
    • data कहाँ भेजा जा रहा है
    • मॉडल किस memory और underlying hardware का इस्तेमाल कर रहा है
    • pricing और privacy policy में बदलाव
  • जिन कंपनियों और services के पास पहले से office, warehouse या desk के नीचे GPU मौजूद हैं, उन्हें कई मशीनों को एक ही कंप्यूटिंग संसाधन की तरह इस्तेमाल करने का तरीका चाहिए
  • Mesh LLM इस तरह डिज़ाइन किया गया है कि आप अपने GPU और मेमोरी को मनचाही संख्या की मशीनों में जोड़कर बड़े मॉडल चला सकें, और compute resources को टीम के भीतर निजी रूप से या बाहर सार्वजनिक रूप से साझा कर सकें

रिक्वेस्ट प्रोसेस करने के तीन रास्ते

  • standard OpenAI client से http://localhost:9337/v1 कॉल करने पर mesh यह तय करता है कि रिक्वेस्ट वास्तव में कहाँ execute होगी
  • रिक्वेस्ट नीचे दिए गए तीन रास्तों में से किसी एक से प्रोसेस होती है
    • मौजूदा मशीन के local GPU पर मॉडल चलाना
    • उस peer को रिक्वेस्ट forward करना जिसमें ज़रूरी मॉडल पहले से लोड हो
    • जो मॉडल एक मशीन में फिट नहीं होता उसे कई मशीनों में pipeline तरीके से बाँटना
  • user एक node से शुरुआत कर सकता है और ज़रूरत पड़ने पर और जोड़ सकता है, और OpenAI client को internal routing या split execution के तरीके के बारे में जानने की जरूरत नहीं होती

plugin architecture और model catalog

  • plugin अपने manifest में उपलब्ध capabilities घोषित करते हैं, और runtime उन्हें शुरू करके calls को route करता है
  • हर plugin की capabilities MCP, HTTP, inference, mesh events के जरिए expose होती हैं
  • default catalog में 40 से अधिक models शामिल हैं
    • लैपटॉप पर चल सकने वाले लगभग 500M parameter models
    • अधिकतम 235B के Mixture-of-Experts models

Skippy split execution

  • बड़े मॉडलों के लिए split mode को अंदरूनी रूप से Skippy कहा जाता है
  • मॉडल की layer ranges को stages में बाँटकर हर node पर रखा जाता है
    • एक node layers 0~15 संभालता है
    • अगला node layers 16~31 संभालता है
    • इसके बाद की layers भी इसी तरह pipeline के अंत तक बाँटी जाती हैं
  • एक stage में बने activation values अगले stage तक भेजे जाते हैं, इसलिए जो मॉडल किसी एक मशीन में नहीं समाते, उन्हें कई mid-range मशीनों को जोड़कर चलाया जा सकता है
  • यह split process OpenAI client को दिखाई नहीं देती, और client लगातार सिर्फ local endpoint को ही कॉल करता रहता है

iroh-आधारित P2P नेटवर्क

  • मॉडल उपलब्ध कराने वाले nodes और सिर्फ रिक्वेस्ट भेजने वाले nodes, दोनों iroh endpoints शुरू करते हैं
  • endpoint तीन भूमिकाएँ निभाता है
    • node की ID
    • public key
    • node का बाहरी दुनिया के सामने एकमात्र नेटवर्क surface
  • iroh central server के बिना hole punching, NAT traversal और relay fallback paths संभालकर अलग-अलग स्थानों पर मौजूद nodes के बीच सीधे और authenticated QUIC connections बनाता है
  • जिन nodes से direct connection नहीं बन सकता, उनके लिए अलग-अलग regions में 2 iroh relays चलाए जाते हैं, जो नज़दीकी fallback path देते हैं
  • public key से मशीन को निर्दिष्ट किया जा सकता है और authenticated NAT-traversing QUIC इस्तेमाल किया जा सकता है, इसलिए peer को रिक्वेस्ट forward करना या अगले pipeline stage तक activation values भेजना, दोनों endpoint ID के अलावा समान communication primitive से संभाले जाते हैं

QUIC ALPN से protocol का विभाजन

  • पूरा protocol QUIC की ALPN negotiation का इस्तेमाल करता है और उपयोग के आधार पर तीन भागों में बंटा है
    • mesh-llm/1: gossip, routing, HTTP tunnel, plugin channels सहित base mesh messaging
    • mesh-llm-control/1: config sync और ownership proof के लिए owner control plane
    • skippy-stage/2: split models में latency-sensitive activation transfer
  • mesh-llm/1 connection में सभी operations bidirectional QUIC streams के जरिए भेजे जाते हैं, और stream का पहला byte उसका प्रकार बताता है
    • 0x01 GOSSIP: models, GPU, RTT, capabilities सहित peer announcements
    • 0x04 TUNNEL_HTTP: peer को proxy की गई inference requests
    • 0x05 ROUTE_REQUEST: peer द्वारा hosted models की query
    • 0x06 PEER_DOWN: connection टूटे हुए peer की सूचना
    • 0x07 PEER_LEAVING: सामान्य shutdown की सूचना
    • 0x08 PLUGIN_CHANNEL: plugin RPC
    • 0x0e DIRECT_PATH_REQUEST: NAT traversal के लिए direct address sharing
  • एक ही connection में gossip, inference, route lookup और peer lifecycle events संभाले जाते हैं, और leading byte से हर stream को demultiplex किया जाता है

secure transport और mesh control का अलगाव

  • iroh मशीनों के बीच secure transport layer उपलब्ध कराता है
  • Mesh LLM इसके ऊपर अपनी gossip layer बनाता है ताकि वह इन नीतियों को सीधे नियंत्रित कर सके
    • mesh में किसे शामिल होने देना है
    • कौन से versions compatible हैं
    • किन peers पर भरोसा करना है

installation और आगे की support

  • लगभग 18MB का हल्का software install करके public mesh में हिस्सा लिया जा सकता है या private deployment बनाया जा सकता है
  • standard OpenAI client में यह localhost:9337/v1 endpoint के रूप में expose होता है
  • iroh Swift SDK के साथ mobile apps विकसित करने की योजना है, और दूसरे clients भी mesh में शामिल हो सकें इसके लिए नए agent standard ACP का support तैयार किया जा रहा है
  • प्रोजेक्ट का लक्ष्य P2P उपयोग बढ़ाना और बंद सर्वरों व vendor dependencies को कम करना है
  • source code और Mesh LLM website पर प्रोजेक्ट देखा जा सकता है

iroh networking library

  • iroh एक open source networking library है जो devices के बीच connection उपलब्ध कराती है; इसके साथ तैयार protocols को जोड़ा जा सकता है या simple communication abstractions के ऊपर custom protocols बनाए जा सकते हैं
  • यह पहले से production environments में लाखों नहीं बल्कि सैकड़ों हज़ार devices पर चल रही है
  • docs, source code, और Discord channel उपलब्ध हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • पहली इमेज में GPU रिग, लैपटॉप, सर्वर, cloud nodes वगैरह देखकर एहसास हुआ कि मेरे पास compute resources कितने कम हैं। मेरे पास 24GB VRAM वाला लैपटॉप या 96GB workstation भी नहीं है, और अगर दोस्तों के सभी gaming PCs लगाकर भी LLM चलाऊं, तो भी शायद फोटो में दिख रहे कुल VRAM तक नहीं पहुंच पाऊंगा
    लेख में public mesh network का भी ज़िक्र था, लेकिन उसके बारे में विस्तृत जानकारी नहीं मिली

  • performance जानकारी की कमी साफ दिखती है। मुझे लगा था कि system RAM या disk streaming समेत किसी भी दूसरे तरीके से बड़े model चलाने की तुलना में यह बहुत धीमा होगा। consumer networks में 10Gbps Ethernet भी local RAM या disk की तुलना में बहुत धीमा है, इसलिए जानना चाहता था कि split model 1 token प्रति सेकंड या उससे भी कम देता है क्या
    model list देखने पर Qwen 235B A22B को “2 nodes पर 16 tok/s के साथ verified MoE 235B/22B” बताया गया था। node specs और network connection सार्वजनिक नहीं किए गए, लेकिन यह काफी ठीक-ठाक speed है; interactive इस्तेमाल के लिए आरामदेह स्तर से थोड़ा कम, फिर भी काफी करीब

    • यह ज़रूरी नहीं कि हमेशा ज्यादा धीमा ही हो; बल्कि कई configurations में शायद ऐसा न हो। weights को RAM या NVMe पर offload करने पर हर token के लिए हर layer process करते समय बड़े weights को धीमे storage से GPU में ले जाना पड़ता है, इसलिए DRAM bandwidth या disk read speed bottleneck बन जाती है
      distributed setup में हर मशीन के VRAM में weights बने रहते हैं, जिससे कहीं तेज GPU memory bandwidth का फायदा मिलता है। devices के बीच भेजा जाने वाला layer output gigabyte-size weights नहीं, बल्कि kilobyte-size होता है, इसलिए network throughput bottleneck नहीं बनता
      असली सीमा network latency है। model को 4 devices में बांटने पर हर token पर network latency तीन बार आती है, और अगर latency 1ms है तो प्रति token 3ms जुड़ते हैं। compute time को 0 मान लें तो भी speculative decoding के बिना theoretical maximum speed करीब 30 tok/s है
      internet पर latency इतनी ज्यादा हो सकती है कि यह practical न रहे, लेकिन local/enterprise network में speculative decoding के साथ यह काफी संभव है। prefill या prompt processing में latency जमा नहीं होती, इसलिए distributed setup लगभग निश्चित रूप से तेज होगा
    • मैंने अपने home lab में machines के बीच 5ms latency और jitter simulate करके मापा। split execution metro-area WAN latency पर काफी अच्छा काम करता है, लेकिन global WAN पर इतना तेज नहीं रहता
      मकसद यह है कि dedicated RDMA या NVLink fabric के बिना कई machines को जोड़कर अपने hardware पर बड़े models serve किए जाएं और दूसरों के साथ share किए जाएं। फिलहाल इसी split setup में GLM 5.2 को करीब 10 tok/s पर चलाने का काम चल रहा है
    • performance का अंदाज़ा अपेक्षाकृत सरलता से लगाया जा सकता है। autoregressive decoding में हर token पर लगभग 2 × hidden_size × num_shards bytes network से भेजने पड़ते हैं, और prefill में इस value को chunk size से divide कर दें
    • AMD Ryzen AI 9 HX 370 वाले Framework 13 पर Qwen3.6-35B-A3B चलाते समय मुझे जो speed मिलती है, यह उससे मिलती-जुलती है। अगर कहीं बड़े model पर भी यही speed मिलती है, तो यह impressive है

  • coding के लिए LLM की तुलना में purpose-built छोटे language models की distributed inference में मेरी ज्यादा दिलचस्पी है। image processing, software-defined radio (SDR), local weather observations आदि में इस्तेमाल करने पर ये सामान्य specs पर भी चल सकते हैं और भरोसेमंद output दे सकते हैं

    • active experts X वाले एक model के बजाय, खास जानकारी पर trained छोटे और dense 10 अलग-अलग models को 10 servers पर रखकर एक router से जोड़ना बेहतर setup लगता है

  • मैं Mesh LLM contributor हूं और बड़े models को कई nodes में split करने वाला skippy engine बनाया है। कोई सवाल हो तो जवाब दूंगा

    • IPFS से जुड़ी tech फिर दिखना अच्छा है। दो बातें जाननी हैं
      पहली, इस तरह compute distribute करने पर computation graph के सभी participants को process हो रही sequence पता चल जाती है; ऐसे में privacy protection कैसे handle करते हैं? दूसरी, malicious participant model activations को corrupt न कर सके, इसके लिए कोई safeguards हैं?
    • public mesh में भाग लेने का incentive क्या है, यह जानना चाहता हूं। अगर कोई किसी खास model को चलाने के लिए जरूरी VRAM का 1/8 देता है, तो क्या उसे कम से कम inference usage का 1/16 मिलने जैसी fairness guarantee है?
    • कुछ दिन पहले public हुआ Colibri project के साथ integrate करने से कोई फायदा होगा क्या?
    • मैंने KV cache implementation को गहराई से नहीं देखा है, पर जानना चाहता हूं कि क्या हर layer के लिए व्यवहार में independent cache चलता है
      अगर ऐसा है, तो compute और data size के लिहाज से यह साफ-सुथरे ढंग से split हो जाता है, और बस हर layer को अपनी बारी का इंतजार करने का time ही slowdown होगा। pipeline बनाकर कई queries साथ-साथ भी चलाई जा सकती हैं
      क्या queries को एक stage offset के साथ डालने वाली N-stage pipeline से best-of-N implement करने का कोई उदाहरण है?
    • मैं अलग-अलग EPYC processors और models वाली एक बड़ी lab चलाता हूं; इन्हें इस तरह एक साथ जोड़ सकना impressive है

  • इसी तरह के distributed computing वाले LLMs खोजते हुए मुझे AI Horde, Aphrodite की कुछ छोटी कोशिशें, और Nous Research की distributed training मिलीं
    इनमें AI Horde सबसे बड़ा लगता है। API chat completion के बजाय KoboldCPP text completion format इस्तेमाल करता है। यह ज्यादा control variables expose करता है, जिससे roleplay में results बेहतर आते हैं, इसलिए community के active members इस तरीके को काफी पसंद करते दिखते हैं। बाकी uses के लिए ज्यादातर tool calling चाहिए होगी, इसलिए roleplay के अलावा यह कहां काम आएगा, पक्का नहीं
    इस हफ्ते मैंने OpenAI bridge को बेहतर करना शुरू किया, ताकि chat templates और response parsing support हो सके। अगर official release सफल रहा, तो roleplay models का इस्तेमाल करना पड़े तब भी इसे coding में उपयोग किया जा सकेगा
    abuse-prevention mechanisms भी ज्यादा मजबूत हैं। organized attacks रोकने के लिए worker को trusted माने जाने से पहले 1 सप्ताह का accumulated uptime पूरा करना होता है, और users सिर्फ trusted workers चुन सकते हैं। worker चलाने पर kudos मिलते हैं, जिन्हें 512 tokens से ज्यादा generation में इस्तेमाल किया जा सकता है, और free requests queue के सबसे पीछे चली जाती हैं

  • मैं सोच रहा था कि एक या ज्यादा distributed LLMs चलाने वाला polymorphic botnet क्या कर सकता है। विचार यह है कि botnet के सभी hosts को cluster compute resources की तरह इस्तेमाल करके LLM चलाया जाए, और हर botnet cluster के propagation methods और payloads evolve हों
    खराब variants detect होकर हट जाते हैं और बेअसर propagation methods फैलते नहीं, लेकिन सबसे अच्छे versions बचे रहते हैं और बढ़ते रहते हैं। यहां बताई गई structure से यह काफी मिलती-जुलती है, और QUIC बहुत dynamic तरीके से काम करता है, इसलिए इसे detect करना उम्मीद से मुश्किल हो सकता है

  • https://query.mt/ project कुछ समय से iroh-based mesh इस्तेमाल कर रहा है। अगर mesh model को phone पर भी इस्तेमाल करना चाहते हैं, तो इसे आज़माया जा सकता है

  • mesh-llm चलाने के लिए मैं कुछ समय तक जूझता रहा, लेकिन installable llama.cpp builds में से कोई भी मेरे पुराने GPU पर काम नहीं करता था। ऐसा लगा कि external llama.cpp service को proxy किया जा सकता है, लेकिन वह setup भी सफल नहीं हुआ
    project बहुत दिलचस्प है, लेकिन अभी भी इसमें काफी rough edges हैं

    • अगर आप bug report भेजें, तो मैं इसे चलाने के लिए आपके साथ मिलकर हल करना चाहूंगा

  • मुझे लगा था कि यह तरीका संभव होगा, इसलिए करीब 1 साल पहले ChatGPT से पूछा था, लेकिन उसने जवाब दिया कि latency बहुत ज्यादा होने से यह असंभव है। उस समय मैं लगभग 1 साल से libp2p पढ़ रहा था और इसका उपयोग करने के लिए कोई project ढूंढ रहा था