Mesh LLM - iroh tabanlı dağıtık yapay zeka hesaplama

 (iroh.computer)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Farklı makinelere dağılmış GPU ve belleği tek bir hesaplama kaynağı olarak birleştirerek, yerelde çalıştırma, peer'e iletme ve bölünmüş çalıştırmayı OpenAI uyumlu tek bir API ile sunuyor
  • İstekler yerel GPU'da ya da modeli yüklemiş bir peer'de işleniyor; tek bir makineye sığmayan modeller ise birden çok düğüme pipeline aşamaları halinde bölünerek çalıştırılabiliyor
  • Eklenti tabanlı katalogda dizüstü bilgisayarlar için 500 milyon parametreli modellerden 235B MoE modellere kadar 40'tan fazla model bulunuyor; istemci, içerdeki batching yapısından bağımsız olarak yalnızca localhost:9337/v1 adresini çağırıyor
  • Her düğüm, açık anahtarını hem kimlik hem de ağda görünen tek yüzey olarak kullanan bir iroh endpoint'i çalıştırıyor ve merkezi sunucu olmadan NAT geçişi, hole punching ve relay yedek yolları üzerinden kimliği doğrulanmış QUIC bağlantıları kuruyor
  • Yaklaşık 18MB'lık yazılım ile herkese açık bir mesh ya da özel dağıtım kurulabiliyor; gelecekte iroh Swift SDK ve ACP destekli mobil uygulamalarla kapalı sunucu bağımlılığını azaltmayı hedefliyor

Harici veri merkezi yerine mevcut donanımdan yararlanma

  • LLM kullanmanın yaygın yöntemi, harici sağlayıcıların GPU veri merkezlerine ve kullanım bazlı API'lerine dayanıyor; bu yüzden kullanım arttıkça maliyet de büyüyor
  • Prompt'lar harici servislere gönderildiğinde kullanıcıların aşağıdaki unsurlar üzerinde doğrudan denetim kurması zorlaşıyor
    • Modelin ne zaman güncellendiği
    • Verinin nereye gönderildiği
    • Modelin kullandığı bellek ve temel donanım
    • Fiyatlandırma ve gizlilik politikalarındaki değişiklikler
  • Ofiste, depoda ya da masa altında zaten GPU bulunduran şirketler ve servisler için, birden çok makineyi tek bir hesaplama kaynağı gibi kullanmanın bir yoluna ihtiyaç var
  • Mesh LLM, eldeki GPU ve belleği istenen sayıda makineye yayarak daha büyük modeller çalıştırmak ve hesaplama kaynaklarını ekip içinde özel olarak ya da dışarıyla açık biçimde paylaşmak üzere tasarlandı

İstekleri işleyen üç yol

  • Standart OpenAI istemcisinden http://localhost:9337/v1 çağrıldığında mesh, isteğin gerçekte nerede çalıştırılacağını belirliyor
  • İstekler aşağıdaki üç yoldan biriyle işleniyor
    • Modelin mevcut makinenin yerel GPU'sunda çalıştırılması
    • Gerekli modeli zaten yüklemiş bir peer'e isteğin iletilmesi
    • Tek bir makineye sığmayan modelin birden çok makineye pipeline yöntemiyle bölünmesi
  • Kullanıcılar tek bir düğümle başlayıp gerektiğinde daha fazlasını ekleyebiliyor; OpenAI istemcisinin iç yönlendirmeyi ya da bölünmüş çalıştırma yöntemini bilmesi gerekmiyor

Eklenti yapısı ve model kataloğu

  • Eklentiler, manifest içinde sundukları yetenekleri bildiriyor ve çalışma zamanı bunları başlatıp çağrıları yönlendiriyor
  • Her eklentinin işlevleri MCP·HTTP·çıkarım·mesh olayları üzerinden açığa çıkıyor
  • Varsayılan katalogda 40'tan fazla model bulunuyor
    • Dizüstü bilgisayarda çalışabilen yaklaşık 500 milyon parametreli modeller
    • En fazla 235B ölçeğinde Mixture-of-Experts modelleri

Skippy ile bölünmüş çalıştırma

  • Büyük modeller için bölünmüş mod dahili olarak Skippy diye adlandırılıyor
  • Modelin katman aralıkları aşamalara bölünerek her düğüme yerleştiriliyor
    • Bir düğüm katman 0~15'ten sorumlu oluyor
    • Sonraki düğüm katman 16~31'den sorumlu oluyor
    • Sonraki katmanlar da aynı şekilde pipeline'ın sonuna kadar dağıtılıyor
  • Bir aşamada üretilen aktivasyonlar (activation) bir sonraki aşamaya iletildiği için, tek tek makinelere sığmayan modeller de birden çok orta sınıf makine birleştirilerek çalıştırılabiliyor
  • Bölme süreci OpenAI istemcisine görünmüyor; istemci yalnızca yerel endpoint'i çağırmaya devam ediyor

iroh tabanlı P2P ağ

  • Hem model sunan düğümler hem de yalnızca istek gönderen düğümler birer iroh endpoint'i başlatıyor
  • Endpoint üç rol üstleniyor
    • Düğümün kimliği
    • Açık anahtar
    • Düğümün dışarıya sunduğu tek ağ yüzeyi
  • iroh, merkezi sunucu olmadan hole punching, NAT geçişi ve relay yedek yollarını işleyerek farklı konumlardaki düğümler arasında doğrudan ve kimliği doğrulanmış QUIC bağlantıları kuruyor
  • Doğrudan bağlanamayan düğümler için farklı bölgelerde iki iroh relay'i işletiliyor ve yakın yedek yollar sağlanıyor
  • Makineyi açık anahtarla belirtip kimliği doğrulanmış NAT geçişli QUIC kullanabildiğiniz için, peer'e istek iletmek ya da sonraki pipeline aşamasına aktivasyon göndermek, yalnızca endpoint kimliği farklı olan aynı iletişim ilkel unsuru olarak ele alınıyor

QUIC ALPN ile protokol ayrımı

  • Tüm protokol, QUIC'in ALPN pazarlığını kullanıyor ve kullanım amacına göre üçe ayrılıyor
    • mesh-llm/1: gossip, yönlendirme, HTTP tüneli ve eklenti kanallarını içeren temel mesh mesajları
    • mesh-llm-control/1: ayar senkronizasyonu ve sahiplik kanıtını yöneten sahip kontrol düzlemi
    • skippy-stage/2: bölünmüş modellerde gecikmeye duyarlı aktivasyon aktarımı
  • mesh-llm/1 bağlantılarında tüm işler çift yönlü QUIC stream'leri üzerinden iletiliyor ve stream'in ilk baytı türü tanımlıyor
    • 0x01 GOSSIP: model, GPU, RTT ve yetenekleri içeren peer duyuruları
    • 0x04 TUNNEL_HTTP: peer'e proxy'lenen çıkarım istekleri
    • 0x05 ROUTE_REQUEST: peer'in barındırdığı modellerin sorgulanması
    • 0x06 PEER_DOWN: bağlantısı kesilen peer bildirimi
    • 0x07 PEER_LEAVING: düzgün kapanış bildirimi
    • 0x08 PLUGIN_CHANNEL: eklenti RPC'si
    • 0x0e DIRECT_PATH_REQUEST: NAT geçişi için doğrudan adres paylaşımı
  • Tek bir bağlantı üzerinde gossip, çıkarım, rota sorgusu ve peer yaşam döngüsü olayları işleniyor; her stream, önek baytı ile demultipleks ediliyor

Güvenli taşıma ile mesh denetiminin ayrılması

  • iroh, makineler arasında güvenli taşıma katmanı sağlıyor
  • Mesh LLM bunun üzerinde kendi gossip katmanını kurarak aşağıdaki politikaları doğrudan denetliyor
    • Mesh'e kimlerin katılmasına izin verileceği
    • Hangi sürümlerin uyumlu olduğu
    • Hangi peer'lere güvenileceği

Kurulum ve gelecek destek

  • Yaklaşık 18MB boyutundaki hafif yazılım kurularak herkese açık bir mesh'e katılmak ya da özel bir dağıtım oluşturmak mümkün
  • Standart OpenAI istemcilerine localhost:9337/v1 endpoint'i olarak sunuluyor
  • iroh Swift SDK ile mobil uygulama geliştirmeyi planlıyor; ayrıca diğer istemcilerin de mesh'e katılabilmesi için yeni ajan standardı ACP desteği hazırlanıyor
  • Proje, P2P kullanımını artırmayı ve kapalı sunuculara ile bağımlılıklara duyulan ihtiyacı azaltmayı hedefliyor
  • Proje; kaynak kodu ve Mesh LLM web sitesi üzerinden incelenebilir

iroh ağ kütüphanesi

  • iroh, cihazlar arası bağlantı sağlayan bir açık kaynak ağ kütüphanesi; hazır protokoller birleştirilebiliyor ya da basit iletişim soyutlamaları üzerinde özel protokoller kurulabiliyor
  • Şimdiden üretim ortamında yüz binlerce cihazda çalışıyor
  • Dokümantasyon, kaynak kodu ve Discord kanalı sunuluyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • İlk görseldeki GPU donanımları, dizüstüler, sunucular, bulut düğümleri vb. görünce elimdeki hesaplama kaynaklarının ne kadar az olduğunu fark ettim. 24 GB VRAM’li bir dizüstüm ya da 96 GB’lık bir iş istasyonum yok; arkadaşlarımın tüm oyun PC’lerini toplayıp LLM çalıştırsam bile fotoğraftaki toplam VRAM’e yaklaşamaz gibi.
    Yazıda açık mesh ağından da bahsedilmişti ama ayrıntılı bilgi bulamadım.

  • Performans bilgisinin eksikliği göze çarpıyor. Sistem RAM’i ya da diskten streaming dahil, büyük modelleri çalıştırmanın diğer tüm yollarından çok daha yavaş olacağını beklemiştim. Tüketici ağlarında 10 Gbps Ethernet bile yerel RAM veya diske kıyasla çok yavaş; bu yüzden parçalanmış modelin saniyede 1 token ya da daha az mı üreteceğini merak ettim.
    Model listesine bakınca Qwen 235B A22B için “2 düğümde 16 tok/s ile doğrulanmış MoE 235B/22B” yazdığını gördüm. Düğüm özellikleri ve ağ bağlantısı açıklanmamış ama oldukça makul bir hız; etkileşimli kullanımda rahat sayılacak seviyenin biraz altında olsa da epey yakın.

    • Mutlaka daha yavaş olmak zorunda değil; hatta böyle olmayan pek çok kurulum olabilir. Ağırlıkları RAM’e ya da NVMe’ye offload ederseniz, her token için her katmanı işlerken devasa ağırlıkları yavaş depolamadan GPU’ya taşımak gerekir; bu da DRAM bant genişliğini veya disk okuma hızını darboğaz yapar.
      Dağıtık kurulumda ise ağırlıklar her makinenin VRAM’inde kalır ve çok daha hızlı GPU bellek bant genişliğinden yararlanılır. Cihazlar arasında aktarılan katman çıktıları gigabayt ölçeğinde ağırlıklar değil, kilobayt ölçeğindedir; bu yüzden ağ verimi darboğaz olmaz.
      Asıl kısıt ağ gecikmesidir. Modeli 4 cihaza bölerseniz her token için ağ gecikmesi üç kez yaşanır; gecikme 1 ms ise token başına 3 ms eklenir. Hesaplama süresinin 0 olduğunu varsaysak bile, speculative decoding olmadan teorik azami hız yaklaşık 30 tok/s olur.
      İnternet üzerinde gecikme muhtemelen pratik olamayacak kadar yüksek olur; ancak yerel/kurumsal ağlarda speculative decoding kullanılırsa gayet mümkün. Prefill ya da prompt işleme sırasında gecikme birikmediğinden, dağıtık kurulum neredeyse kesinlikle daha hızlıdır.
    • Kendi home lab’imde cihazlar arasında 5 ms gecikme ve jitter simüle ederek ölçüm yaptım. Parçalı çalıştırma, büyük metropol düzeyindeki WAN gecikmelerinde oldukça iyi çalışıyor; ancak küresel WAN’da pek hızlı değil.
      Amaç, özel RDMA ya da NVLink fabric olmadan birden fazla cihazı bir araya getirip sahip olunan donanımla büyük modeller sunmak ve bunları başkalarıyla paylaşmak. Şu anda aynı parçalı kurulumda GLM 5.2’yi yaklaşık 10 tok/s hızda çalıştırma üzerinde çalışıyorum.
    • Performansı kabaca tahmin etmek görece kolay. Otoregresif decoding’de her token için ağa yaklaşık 2 × hidden_size × num_shards bayt aktarmak gerekir; prefill’de ise bu değeri chunk boyutuna bölebilirsiniz.
    • AMD Ryzen AI 9 HX 370’li Framework 13 üzerinde Qwen3.6-35B-A3B çalıştırırken aldığım hıza benziyor. Çok daha büyük modellerde de aynı hız çıkıyorsa etkileyici.

  • Kodlama amaçlı LLM’lerden ziyade, amaca özel yapılmış küçük dil modellerinin dağıtık çıkarımı daha çok ilgimi çekiyor. Görüntü işleme, yazılım tanımlı radyo (SDR), yerel hava gözlemleri gibi alanlarda kullanıldığında sıradan donanımlarda çalışıp güvenilir çıktılar verebilir.

    • X aktif uzmana sahip tek bir model yerine, belirli bilgilerle eğitilmiş küçük ve yoğun 10 farklı modeli 10 sunucuya koyup tek bir router ile bağlamak daha uygun görünüyor.

  • Mesh LLM’e katkıda bulunanlardan biriyim ve büyük modelleri birden çok düğüme bölebilmeyi sağlayan skippy engine’i yaptım. Sorunuz varsa yanıtlayabilirim.

    • IPFS ile ilgili teknolojilerin yeniden ortaya çıkması sevindirici. İki şeyi merak ediyorum.
      Birincisi, hesaplamayı bu şekilde dağıtınca hesaplama grafiğindeki tüm katılımcılar işlenen diziyi biliyor; gizliliği nasıl ele alıyorsunuz? İkincisi, kötü niyetli bir katılımcının model aktivasyonlarını bozmasını engelleyen korumalar var mı?
    • Açık mesh’e katılım teşvikinin ne olduğunu merak ediyorum. Belirli bir modeli çalıştırmak için gereken VRAM’in 1/8’ini sağlarsam en azından çıkarım kullanımının 1/16’sını almak gibi bir adillik garantisi var mı?
    • Birkaç gün önce duyurulan Colibri projesi ile entegre etmenin bir faydası olur mu?
    • KV cache uygulamasına derinlemesine bakmadım; katman başına fiilen bağımsız bir cache mi işletiliyor, merak ediyorum.
      Öyleyse hesaplama yükü ve veri boyutu açısından temiz biçimde bölünür; yalnızca her katmanın sırasını bekleme süresi yavaşlatır gibi. Pipeline kurarsanız birden fazla sorguyu aynı anda da çalıştırabilirsiniz.
      Sorguları birer aşama kaydırarak veren N aşamalı pipeline ile best-of-N uygulanmış bir örnek var mı?
    • Birçok farklı EPYC işlemci ve modele sahip bir araştırma laboratuvarı işletiyorum; bunları bu şekilde tek bir bütün hâline getirebilmek etkileyici.

  • Benzer dağıtık hesaplama yaklaşımına sahip LLM’ler ararken AI Horde, Aphrodite tarafındaki küçük ölçekli girişimler ve Nous Research’ün dağıtık eğitim çalışmalarıyla karşılaştım.
    Bunların içinde AI Horde en büyüğü gibi görünüyor. API’si sohbet tamamlama değil, KoboldCPP metin tamamlama biçimini kullanıyor. Daha fazla ayar değişkeni sunduğu ve rol yapmada sonuçlar daha iyi olduğu için topluluğun aktif üyeleri bu yaklaşımı güçlü biçimde tercih ediyor gibi. Diğer kullanım alanlarının çoğu muhtemelen tool calling gerektireceğinden, rol yapma dışında nerede kullanılabileceğinden pek emin değilim.
    Bu hafta OpenAI bridge’i chat template ve yanıt ayrıştırmayı destekleyecek şekilde iyileştirmeye başladım. Resmî dağıtıma sokabilirsem, rol yapma modeli kullanmak zorunda kalsam bile kodlama için yararlanılabilir.
    Kötüye kullanımı önleme mekanizmaları da daha kapsamlı. Koordineli saldırıları engellemek için worker’ların güvenilir sayılmadan önce toplam 1 hafta çalışma süresini doldurması gerekiyor; kullanıcılar da yalnızca güvenilir worker’ları seçebiliyor. Worker çalıştırınca kudos kazanılıyor ve bunlar 512 token’ı aşan üretimlerde kullanılabiliyor; ücretsiz istekler ise kuyruğun en arkasına atılıyor.

  • Bir veya daha fazla dağıtık LLM çalıştıran polimorfik bir botnet neler yapabilir diye merak etmiştim. Fikir, botnet’teki tüm host’ları küme hesaplama kaynağı olarak kullanıp LLM çalıştırmak ve her botnet kümesinin yayılma yöntemi ile payload’unun evrilmesini sağlamak.
    Kötü varyantlar tespit edilip kaldırılır, etkisiz yayılma yöntemleri yayılmaz; ama en başarılı sürümler hayatta kalır ve büyümeye devam eder. Burada tanıtılan yapıya oldukça benziyor; QUIC çok dinamik çalıştığı için beklenenden daha zor tespit edilebilir.

  • https://query.mt/ projesi bir süredir iroh tabanlı mesh kullanıyor. Mesh modeli cep telefonlarında da kullanmak istiyorsanız denemeye değer.

  • mesh-llm’i çalıştırmak için bir süre uğraştım ama kurulabilir llama.cpp derlemeleri arasında eski GPU’mda çalışan olmadı. Harici bir llama.cpp servisini proxy’leyebiliyor gibi görünüyordu ama o ayarı da başaramadım.
    Çok ilginç bir proje, ancak hâlâ epey pürüzlü kısmı var.

    • Bir hata raporu gönderirseniz çalışır hâle getirmek için birlikte çözmeyi isterim.

  • Bu yöntemin mümkün olacağını düşünüp yaklaşık 1 yıl önce ChatGPT’ye sormuştum; ama gecikme çok yüksek olduğu için imkânsız yanıtını almıştım. O dönemde neredeyse bir yıldır libp2p öğreniyor ve kullanabileceğim bir proje arıyordum.