Mesh LLM - komputasi AI terdistribusi berbasis iroh

 (iroh.computer)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Menggabungkan GPU dan memori yang tersebar di banyak mesin menjadi satu sumber daya komputasi, lalu menyediakan eksekusi lokal, penerusan ke peer, dan eksekusi terpecah melalui satu API yang kompatibel dengan OpenAI
  • Permintaan diproses di GPU lokal atau di peer yang sudah memuat model, dan model yang tidak muat di satu mesin dapat dijalankan dengan membaginya ke beberapa node sebagai tahap pipeline
  • Katalog berbasis plugin mencakup lebih dari 40 model, dari model 500 juta parameter untuk laptop hingga model MoE 235B, dan klien hanya memanggil localhost:9337/v1 tanpa perlu mengetahui batching internal
  • Setiap node menjalankan endpoint iroh yang menggunakan kunci publik sebagai ID sekaligus satu-satunya permukaan jaringan unik, lalu membangun koneksi QUIC terautentikasi melalui NAT traversal, hole punching, dan jalur fallback relay tanpa server pusat
  • Dengan perangkat lunak sekitar 18MB, pengguna dapat membangun mesh publik atau deployment privat, dan ke depannya mereka berencana menurunkan ketergantungan pada server tertutup melalui aplikasi seluler yang mendukung iroh Swift SDK dan ACP

Memanfaatkan perangkat keras yang sudah ada alih-alih data center eksternal

  • Cara umum menggunakan LLM bergantung pada data center GPU milik penyedia eksternal dan API berbasis pemakaian, sehingga semakin tinggi penggunaan, semakin besar pula biayanya
  • Saat prompt dikirim ke layanan eksternal, pengguna sulit mengendalikan langsung hal-hal berikut
    • kapan model diperbarui
    • ke mana data dikirim
    • memori dan perangkat keras dasar yang digunakan model
    • perubahan harga dan kebijakan privasi
  • Perusahaan dan layanan yang sudah memiliki GPU di kantor, gudang, atau di bawah meja membutuhkan cara untuk memanfaatkan banyak mesin seperti satu sumber daya komputasi
  • Mesh LLM dirancang untuk menggabungkan GPU dan memori yang dimiliki di sejumlah mesin sesuai kebutuhan, menjalankan model yang lebih besar, serta memungkinkan sumber daya komputasi dibagikan secara privat di dalam tim atau secara publik ke luar

Tiga jalur untuk memproses permintaan

  • Saat klien OpenAI standar memanggil http://localhost:9337/v1, mesh menentukan lokasi eksekusi sebenarnya untuk permintaan tersebut
  • Permintaan diproses melalui salah satu dari tiga jalur berikut
    • menjalankan model di GPU lokal mesin saat ini
    • meneruskan permintaan ke peer yang sudah memuat model yang diperlukan
    • membagi model yang tidak muat di satu mesin ke beberapa mesin dengan cara pipeline
  • Pengguna dapat memulai dengan satu node lalu menambah lebih banyak saat diperlukan, dan klien OpenAI tidak perlu mengetahui perutean internal atau metode eksekusi terpecah

Struktur plugin dan katalog model

  • Plugin mendeklarasikan kemampuan yang disediakan dalam manifest, lalu runtime memulainya dan merutekan pemanggilan
  • Kemampuan setiap plugin diekspos melalui MCP·HTTP·inferensi·event mesh
  • Katalog bawaan mencakup lebih dari 40 model
    • model sekitar 500 juta parameter yang dapat dijalankan di laptop
    • model Mixture-of-Experts berukuran hingga 235B

Eksekusi terpecah Skippy

  • Mode terpecah untuk model besar secara internal disebut Skippy
  • Rentang layer model dibagi per tahap lalu ditempatkan ke setiap node
    • satu node menangani layer 0~15
    • node berikutnya menangani layer 16~31
    • layer setelahnya juga didistribusikan dengan cara yang sama hingga akhir pipeline
  • Activation yang dihasilkan pada satu tahap diteruskan ke tahap berikutnya, sehingga model yang tidak muat di masing-masing mesin tetap bisa dijalankan dengan menggabungkan beberapa mesin kelas menengah
  • Proses pemecahan ini tidak terlihat oleh klien OpenAI, dan klien tetap hanya memanggil endpoint lokal

Jaringan P2P berbasis iroh

  • Node yang menyediakan model maupun node yang hanya mengirim permintaan sama-sama memulai endpoint iroh
  • Endpoint menangani tiga peran
    • ID node
    • kunci publik
    • satu-satunya permukaan jaringan yang diekspos node ke luar
  • iroh menangani hole punching, NAT traversal, dan jalur fallback relay tanpa server pusat untuk membangun koneksi QUIC langsung dan terautentikasi antar-node di lokasi berbeda
  • Untuk node yang tidak bisa terhubung langsung, mereka mengoperasikan 2 relay iroh di wilayah berbeda guna menyediakan jalur fallback terdekat
  • Karena mesin dapat ditentukan dengan kunci publik dan memakai QUIC NAT traversal yang terautentikasi, penerusan permintaan ke peer atau pengiriman activation ke tahap pipeline berikutnya ditangani sebagai elemen komunikasi dasar yang sama, hanya berbeda pada ID endpoint

Membedakan protokol dengan QUIC ALPN

  • Seluruh protokol menggunakan negosiasi ALPN milik QUIC dan dibagi menjadi tiga sesuai fungsi
    • mesh-llm/1: pesan dasar termasuk gossip, routing, tunnel HTTP, dan channel plugin
    • mesh-llm-control/1: control plane pemilik yang menangani sinkronisasi konfigurasi dan pembuktian kepemilikan
    • skippy-stage/2: pengiriman activation yang sensitif terhadap latensi dalam model terpecah
  • Pada koneksi mesh-llm/1, semua operasi dikirim melalui stream QUIC dua arah, dan byte pertama stream mengidentifikasi jenisnya
    • 0x01 GOSSIP: pengumuman peer yang mencakup model, GPU, RTT, dan kemampuan
    • 0x04 TUNNEL_HTTP: permintaan inferensi yang diproksikan ke peer
    • 0x05 ROUTE_REQUEST: pencarian model yang di-host peer
    • 0x06 PEER_DOWN: pemberitahuan peer yang terputus
    • 0x07 PEER_LEAVING: pemberitahuan penghentian normal
    • 0x08 PLUGIN_CHANNEL: RPC plugin
    • 0x0e DIRECT_PATH_REQUEST: pembagian alamat langsung untuk NAT traversal
  • Dalam satu koneksi, gossip, inferensi, pencarian rute, dan event siklus hidup peer diproses, lalu setiap stream didemultipleks dengan byte awalan

Pemisahan transport aman dan kontrol mesh

  • iroh menyediakan lapisan transport aman antar-mesin
  • Di atasnya, Mesh LLM membangun lapisan gossip sendiri untuk mengendalikan langsung kebijakan berikut
    • siapa yang diizinkan berpartisipasi dalam mesh
    • versi yang kompatibel
    • peer yang dapat dipercaya

Instalasi dan dukungan mendatang

  • Dengan memasang perangkat lunak ringan sekitar 18MB, pengguna dapat bergabung ke mesh publik atau membangun deployment privat
  • Untuk klien OpenAI standar, layanan diekspos pada endpoint localhost:9337/v1
  • Mereka berencana mengembangkan aplikasi seluler dengan iroh Swift SDK, dan juga menyiapkan dukungan untuk standar agen baru, ACP, agar klien lain dapat bergabung ke mesh
  • Proyek ini bertujuan meningkatkan pemanfaatan P2P dan mengurangi ketergantungan pada server tertutup serta vendor lock-in
  • Proyek ini dapat dilihat di kode sumber dan situs web Mesh LLM

Pustaka jaringan iroh

  • iroh adalah pustaka jaringan open-source yang menyediakan koneksi antarperangkat, memungkinkan penggabungan protokol yang sudah tersedia atau penyusunan protokol khusus di atas abstraksi komunikasi sederhana
  • iroh sudah berjalan di ratusan ribu perangkat dalam lingkungan produksi
  • Tersedia dokumentasi, kode sumber, dan channel Discord

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Melihat perangkat GPU, laptop, server, cloud node, dan lainnya pada gambar pertama membuatku sadar betapa sedikitnya sumber daya komputasi yang kumiliki. Aku bahkan tidak punya laptop VRAM 24GB atau workstation 96GB, dan sepertinya sekalipun mengerahkan semua PC gaming milik teman-teman untuk menjalankan LLM, total VRAM-nya tetap tidak akan menyamai yang ada di foto
    Tulisan itu juga memperkenalkan jaringan mesh publik, tetapi aku tidak berhasil menemukan informasi rinci mengenainya

  • Yang menonjol adalah kurangnya informasi performa. Aku menduga ini akan jauh lebih lambat daripada cara lain mana pun untuk menjalankan model besar, termasuk yang memakai RAM sistem atau streaming dari disk. Bahkan Ethernet 10Gbps di jaringan konsumen pun sangat lambat dibanding RAM lokal atau disk, jadi aku penasaran apakah model yang dibagi seperti ini hanya mencapai 1 token per detik atau bahkan kurang
    Dari daftar model, terlihat Qwen 235B A22B disebut sebagai “MoE 235B/22B tervalidasi pada 16 tok/s di 2 node”. Spesifikasi node dan koneksi jaringannya memang tidak dipublikasikan, tetapi itu kecepatan yang cukup baik; mungkin sedikit di bawah tingkat nyaman untuk penggunaan interaktif, tetapi sudah sangat mendekati

    • Tidak harus lebih lambat; malah mungkin ada banyak konfigurasi yang justru tidak demikian. Jika bobot di-offload ke RAM atau NVMe, maka untuk setiap token dan setiap layer, bobot berukuran besar harus dipindahkan dari media penyimpanan yang lambat ke GPU, sehingga bandwidth DRAM atau kecepatan baca disk menjadi bottleneck
      Dalam konfigurasi terdistribusi, bobot tetap berada di VRAM masing-masing perangkat sehingga bisa memanfaatkan bandwidth memori GPU yang jauh lebih cepat. Keluaran layer yang dikirim antarperangkat berukuran kilobyte, bukan bobot berukuran gigabyte, jadi throughput jaringan tidak menjadi bottleneck
      Batasan yang sebenarnya adalah latensi jaringan. Jika model dibagi ke 4 perangkat, maka untuk setiap token akan ada tiga kali latensi jaringan; jika latensinya 1ms, berarti bertambah 3ms per token. Bahkan dengan asumsi waktu komputasi nol, tanpa speculative decoding, kecepatan maksimum teoretisnya sekitar 30 tok/s
      Di internet, latensinya mungkin terlalu tinggi sehingga tidak praktis, tetapi di jaringan lokal atau perusahaan, dengan speculative decoding, ini sangat mungkin dilakukan. Pada prefill atau pemrosesan prompt, latensi tidak terakumulasi, jadi konfigurasi terdistribusi hampir pasti lebih cepat
    • Di homelab-ku, aku mensimulasikan dan mengukur latensi 5ms beserta jitter antarperangkat. Eksekusi yang dibagi seperti ini bekerja cukup baik pada latensi WAN setingkat area metropolitan, tetapi tidak terlalu cepat pada WAN global
      Tujuannya adalah menggabungkan beberapa perangkat tanpa fabric RDMA atau NVLink khusus agar model besar bisa dijalankan di hardware yang dimiliki dan dibagikan ke orang lain. Saat ini sedang dikerjakan menjalankan GLM 5.2 sekitar 10 tok/s pada konfigurasi split yang sama
    • Performa sebenarnya cukup mudah diperkirakan secara kasar. Pada decoding autoregresif, per token kira-kira perlu mengirim 2 × hidden_size × num_shards byte melalui jaringan, dan pada prefill nilai ini tinggal dibagi ukuran chunk
    • Ini mirip dengan kecepatan yang kudapat saat menjalankan Qwen3.6-35B-A3B di Framework 13 dengan AMD Ryzen AI 9 HX 370. Jika model yang jauh lebih besar bisa mendapat kecepatan yang sama, itu mengesankan

  • Daripada LLM untuk coding, aku lebih tertarik pada inferensi terdistribusi model bahasa kecil yang dibuat sesuai tujuan. Itu bisa dipakai untuk pemrosesan gambar, software-defined radio (SDR), pengamatan cuaca lokal, dan sebagainya, sambil tetap bisa berjalan di spesifikasi biasa dan memberi keluaran yang dapat dipercaya

    • Alih-alih satu model dengan X expert aktif, tampaknya lebih cocok menaruh 10 model berbeda yang kecil dan dense, masing-masing dilatih dengan informasi tertentu, di 10 server lalu menghubungkannya dengan satu router

  • Aku kontributor Mesh LLM, dan aku membuat engine skippy yang memungkinkan model besar di-split ke beberapa node. Kalau ada pertanyaan, aku akan menjawab

    • Senang melihat teknologi terkait IPFS muncul lagi. Ada dua hal yang membuatku penasaran
      Pertama, jika komputasi didistribusikan seperti ini, semua peserta dalam graph komputasi akan mengetahui sekuens yang sedang diproses; bagaimana perlindungan privasi ditangani? Kedua, adakah pengaman agar peserta jahat tidak bisa meracuni aktivasi model?
    • Aku penasaran apa insentif untuk ikut mesh publik. Jika seseorang menyediakan 1/8 dari VRAM yang dibutuhkan untuk menjalankan model tertentu, adakah jaminan keadilan seperti minimal mendapat 1/16 dari penggunaan inferensi?
    • Apakah ada manfaat jika diintegrasikan dengan proyek Colibri yang diumumkan beberapa hari lalu?
    • Aku belum pernah mendalami implementasi KV cache, jadi aku penasaran apakah pada praktiknya cache yang dipakai memang independen per layer
      Jika begitu, pembagiannya tampak bersih dari sisi komputasi dan ukuran data, dan yang melambat mungkin hanya waktu tunggu tiap layer untuk giliran. Dengan membuat pipeline, beberapa kueri juga bisa dijalankan bersamaan
      Apakah ada contoh penerapan best-of-N dengan pipeline N-tahap yang memasukkan kueri secara selang satu tahap?
    • Aku mengelola laboratorium dengan banyak prosesor dan model EPYC yang berbeda-beda, dan mengesankan bahwa semuanya bisa digabung menjadi satu dengan cara seperti ini

  • Saat mencari LLM dengan komputasi terdistribusi serupa, aku menemukan AI Horde, beberapa percobaan kecil di sisi Aphrodite, dan pelatihan terdistribusi dari Nous Research
    Di antara semuanya, AI Horde tampaknya yang paling besar. API-nya memakai format text completion KoboldCPP, bukan chat completion. Karena mengekspos lebih banyak variabel kontrol dan memberi hasil lebih baik untuk roleplay, tampaknya anggota komunitas yang aktif sangat menyukai pendekatan ini. Untuk penggunaan lain, kebanyakan mungkin memerlukan tool calling, jadi selain roleplay aku kurang yakin ini bisa dipakai untuk apa
    Minggu ini aku mulai memperbaiki bridge OpenAI agar mendukung template chat dan parsing respons. Jika berhasil masuk rilis resmi, ini bisa dipakai untuk coding walaupun harus menggunakan model roleplay
    Pengaman terhadap penyalahgunaan juga lebih matang. Untuk mencegah serangan terorganisasi, worker baru dianggap tepercaya hanya setelah mengumpulkan total uptime 1 minggu, dan pengguna bisa memilih hanya worker tepercaya. Dengan menjalankan worker, seseorang memperoleh kudos yang bisa dipakai untuk generasi di atas 512 token, sedangkan permintaan gratis didorong ke paling belakang antrean

  • Aku penasaran apa yang bisa dilakukan oleh botnet polimorfik yang menjalankan satu atau lebih LLM terdistribusi. Gagasannya adalah memakai semua host dalam botnet sebagai sumber daya komputasi klaster untuk menjalankan LLM, sambil membiarkan metode propagasi dan payload setiap klaster botnet berevolusi
    Varian jahat akan terdeteksi dan dibersihkan, metode propagasi yang tidak efektif tidak akan menyebar, tetapi versi terbaik akan bertahan dan terus berkembang. Ini cukup mirip dengan arsitektur yang diperkenalkan di sini, dan QUIC bekerja sangat dinamis sehingga mungkin lebih sulit dideteksi daripada dugaan awal

  • Proyek https://query.mt/ sudah cukup lama menggunakan mesh berbasis iroh. Jika ingin memakai model mesh bahkan di ponsel, ini layak dicoba

  • Aku sempat berjuang cukup lama untuk menjalankan mesh-llm, tetapi tidak ada build llama.cpp yang bisa dipasang dan berjalan di GPU lamaku. Sepertinya ada cara untuk mem-proxy layanan llama.cpp eksternal, tetapi aku juga tidak berhasil dengan konfigurasi itu
    Ini proyek yang sangat menarik, tetapi masih ada cukup banyak bagian yang belum matang

    • Kalau kamu mengirim laporan bug, aku ingin mencoba membantu menyelesaikannya sampai bisa berjalan

  • Sekitar setahun lalu aku bertanya ke ChatGPT apakah pendekatan ini mungkin dilakukan, dan jawabannya adalah tidak mungkin karena latensinya terlalu tinggi. Saat itu aku sudah hampir setahun mempelajari libp2p sambil mencari proyek tempat teknologi itu bisa dipakai