Mesh LLM - Điện toán AI phân tán dựa trên iroh

• Kết hợp GPU và bộ nhớ phân tán trên nhiều máy thành một tài nguyên điện toán, cung cấp chạy cục bộ, chuyển tiếp qua peer và chạy phân tách thông qua một API tương thích OpenAI
• Yêu cầu được xử lý trên GPU cục bộ hoặc trên peer đã nạp mô hình; những mô hình không vừa trong một máy có thể được chia thành các giai đoạn pipeline để chạy trên nhiều node
• Catalog dựa trên plugin bao gồm hơn 40 mô hình, từ mô hình 500 triệu tham số cho laptop đến mô hình MoE 235B; client chỉ cần gọi localhost:9337/v1 bất kể việc batch nội bộ
• Mỗi node chạy một endpoint iroh dùng khóa công khai làm ID và bề mặt mạng duy nhất, đồng thời thiết lập kết nối QUIC đã xác thực thông qua NAT traversal, hole punching và đường thay thế relay mà không cần máy chủ trung tâm
• Có thể triển khai mesh công khai hoặc riêng tư bằng phần mềm khoảng 18MB; trong tương lai dự định giảm phụ thuộc vào máy chủ đóng thông qua ứng dụng di động hỗ trợ iroh Swift SDK và ACP

---

Tận dụng phần cứng hiện có thay vì trung tâm dữ liệu bên ngoài

• Cách sử dụng LLM thông thường phụ thuộc vào trung tâm dữ liệu GPU của nhà cung cấp bên ngoài và API tính phí theo mức sử dụng, nên chi phí cũng tăng khi lưu lượng sử dụng tăng
• Khi gửi prompt tới dịch vụ bên ngoài, người dùng khó trực tiếp kiểm soát các yếu tố sau
  • Thời điểm cập nhật mô hình
  • Vị trí dữ liệu được truyền tới
  • Bộ nhớ và phần cứng nền tảng mà mô hình sử dụng
  • Thay đổi về giá và chính sách xử lý dữ liệu cá nhân
• Các doanh nghiệp và dịch vụ đã có GPU trong văn phòng, kho hàng hoặc dưới bàn làm việc cần một cách để sử dụng nhiều máy như một tài nguyên điện toán
• Mesh LLM được thiết kế để gộp GPU và bộ nhớ sẵn có trên số lượng máy tùy ý nhằm chạy các mô hình lớn hơn, đồng thời chia sẻ tài nguyên tính toán trong nội bộ nhóm một cách riêng tư hoặc công khai với bên ngoài

Ba đường xử lý yêu cầu

• Khi gọi http://localhost:9337/v1 từ client OpenAI tiêu chuẩn, mesh sẽ quyết định vị trí thực thi thực tế của yêu cầu
• Yêu cầu được xử lý theo một trong ba đường sau
  • Chạy mô hình trên GPU cục bộ của máy hiện tại
  • Chuyển tiếp yêu cầu tới peer đã nạp mô hình cần thiết
  • Chia mô hình không vừa trong một máy theo kiểu pipeline trên nhiều máy
• Người dùng có thể bắt đầu với một node và thêm node khi cần; client OpenAI không cần biết về routing nội bộ hay cách chạy phân tách

Cấu trúc plugin và catalog mô hình

• Plugin khai báo các khả năng cung cấp trong manifest, còn runtime khởi chạy chúng và định tuyến các lời gọi
• Chức năng của từng plugin được phơi bày thông qua MCP, HTTP, suy luận và sự kiện mesh
• Catalog mặc định bao gồm hơn 40 mô hình
  • Mô hình khoảng 500 triệu tham số có thể chạy trên laptop
  • Mô hình Mixture-of-Experts quy mô tối đa 235B

Chạy phân tách Skippy

• Chế độ phân tách cho các mô hình lớn được gọi nội bộ là Skippy
• Phạm vi các layer của mô hình được chia theo từng giai đoạn và bố trí lên từng node
  • Một node phụ trách các layer 0~15
  • Node tiếp theo phụ trách các layer 16~31
  • Các layer sau đó cũng được phân phối theo cách tương tự cho tới cuối pipeline
• Activation được tạo ở một giai đoạn sẽ được truyền sang giai đoạn tiếp theo, nhờ đó có thể kết hợp nhiều máy tầm trung để chạy những mô hình không vừa trong từng máy riêng lẻ
• Quá trình phân tách không hiển thị với client OpenAI; client vẫn chỉ gọi endpoint cục bộ

Mạng P2P dựa trên iroh

• Cả node cung cấp mô hình lẫn node chỉ gửi yêu cầu đều khởi động endpoint iroh
• Endpoint đảm nhiệm ba vai trò
  • ID của node
  • Khóa công khai
  • Bề mặt mạng duy nhất mà node phơi bày ra bên ngoài
• iroh xử lý hole punching, NAT traversal và đường thay thế relay mà không cần máy chủ trung tâm, qua đó thiết lập kết nối QUIC trực tiếp và đã xác thực giữa các node ở những vị trí khác nhau
• Đối với các node không thể kết nối trực tiếp, hệ thống vận hành 2 iroh relay ở các khu vực khác nhau để cung cấp đường thay thế gần hơn
• Nhờ có thể chỉ định máy bằng khóa công khai và dùng QUIC NAT traversal đã xác thực, việc chuyển tiếp yêu cầu tới peer hoặc gửi activation tới giai đoạn pipeline tiếp theo đều được xử lý bằng cùng một primitive truyền thông, chỉ khác ID endpoint

Phân biệt giao thức bằng QUIC ALPN

• Toàn bộ giao thức sử dụng thỏa thuận ALPN của QUIC và được chia thành ba loại theo mục đích sử dụng
  • mesh-llm/1: mesh cơ bản, bao gồm gossip, routing, HTTP tunnel và kênh plugin
  • mesh-llm-control/1: mặt phẳng điều khiển của chủ sở hữu, phụ trách đồng bộ cấu hình và chứng minh quyền sở hữu
  • skippy-stage/2: truyền activation nhạy cảm với độ trễ trong mô hình phân tách
• Trong kết nối mesh-llm/1, mọi tác vụ được truyền qua stream QUIC hai chiều, và byte đầu tiên của stream xác định loại
  • 0x01 GOSSIP: thông báo peer bao gồm mô hình, GPU, RTT và khả năng
  • 0x04 TUNNEL_HTTP: yêu cầu suy luận được proxy tới peer
  • 0x05 ROUTE_REQUEST: truy vấn mô hình do peer host
  • 0x06 PEER_DOWN: thông báo peer đã mất kết nối
  • 0x07 PEER_LEAVING: thông báo thoát bình thường
  • 0x08 PLUGIN_CHANNEL: RPC plugin
  • 0x0e DIRECT_PATH_REQUEST: chia sẻ địa chỉ trực tiếp để NAT traversal
• Một kết nối xử lý gossip, suy luận, truy vấn đường đi và sự kiện vòng đời peer, đồng thời tách kênh từng stream bằng byte dẫn đầu

Tách biệt truyền tải bảo mật và điều khiển mesh

• iroh cung cấp lớp truyền tải bảo mật giữa các máy
• Mesh LLM xây dựng lớp gossip riêng bên trên để trực tiếp kiểm soát các chính sách sau
  • Đối tượng được phép tham gia mesh
  • Phiên bản tương thích
  • Peer được tin cậy

Cài đặt và hỗ trợ trong tương lai

• Có thể cài đặt phần mềm nhẹ khoảng 18MB để tham gia mesh công khai hoặc cấu hình triển khai riêng tư
• Với client OpenAI tiêu chuẩn, hệ thống được phơi bày dưới dạng endpoint localhost:9337/v1
• Dự án có kế hoạch phát triển ứng dụng di động bằng iroh Swift SDK, đồng thời chuẩn bị hỗ trợ ACP, một tiêu chuẩn agent mới, để các client khác cũng có thể tham gia mesh
• Dự án hướng tới tăng cường sử dụng P2P và giảm phụ thuộc vào máy chủ đóng cùng các ràng buộc của chúng
• Có thể xem dự án tại mã nguồn và website Mesh LLM

Thư viện mạng iroh

• iroh là thư viện mạng mã nguồn mở cung cấp kết nối giữa các thiết bị, cho phép kết hợp các giao thức có sẵn hoặc xây dựng giao thức tùy chỉnh trên một abstraction truyền thông đơn giản
• Đã chạy trên hàng trăm nghìn thiết bị trong môi trường production
• Cung cấp tài liệu, mã nguồn và kênh Discord

[GN⁺]

Ý kiến trên Hacker News

• Nhìn vào dàn GPU, laptop, server, node cloud trong hình đầu tiên, tôi mới thấm là tài nguyên tính toán mình có ít đến mức nào. Tôi không có laptop VRAM 24GB hay workstation 96GB, và dù huy động hết PC gaming của bạn bè để chạy LLM thì có lẽ tổng VRAM cũng không bằng trong ảnh
  Bài viết cũng giới thiệu mạng mesh công khai, nhưng tôi không tìm được thông tin chi tiết

  • Địa chỉ mesh công khai là https://public.meshllm.cloud/

• Điểm nổi bật là thiếu thông tin về hiệu năng. Tôi đã dự đoán nó sẽ chậm hơn rất nhiều so với mọi cách chạy mô hình lớn khác, kể cả dùng RAM hệ thống hay streaming từ đĩa. Mạng consumer, ngay cả Ethernet 10Gbps, cũng rất chậm so với RAM cục bộ hoặc đĩa, nên tôi tò mò liệu mô hình được chia nhỏ có chỉ đạt 1 token/giây hoặc thấp hơn không
  Nhìn danh sách mô hình thì Qwen 235B A22B được ghi là “MoE 235B/22B đã được xác minh ở 16 tok/s trên 2 node”. Họ không công bố cấu hình node và kết nối mạng, nhưng đó là tốc độ khá ổn; dù hơi dưới mức thoải mái cho tương tác hội thoại, nó cũng đã khá gần

  • Không nhất thiết là chậm hơn; thậm chí có lẽ có nhiều cấu hình không như vậy. Nếu offload trọng số sang RAM hoặc NVMe, mỗi token khi xử lý từng layer đều phải chuyển các trọng số khổng lồ từ bộ lưu trữ chậm sang GPU, nên băng thông DRAM hoặc tốc độ đọc đĩa trở thành nút thắt
    Trong cấu hình phân tán, trọng số vẫn nằm trong VRAM của từng máy, tận dụng được băng thông bộ nhớ GPU nhanh hơn nhiều. Đầu ra của layer được chuyển giữa các thiết bị chỉ ở mức kilobyte chứ không phải trọng số mức gigabyte, nên thông lượng mạng không phải nút thắt
    Ràng buộc thực sự là độ trễ mạng. Nếu chia mô hình ra 4 thiết bị, mỗi token sẽ phát sinh độ trễ mạng ba lần; nếu độ trễ là 1ms thì mỗi token cộng thêm 3ms. Ngay cả giả sử thời gian tính toán bằng 0, tốc độ tối đa về lý thuyết nếu không có speculative decoding cũng chỉ khoảng 30 tok/s
    Trên Internet, độ trễ có khả năng quá lớn nên không thực tế, nhưng trên mạng cục bộ/doanh nghiệp, nếu dùng speculative decoding thì hoàn toàn khả thi. Với prefill hoặc xử lý prompt, độ trễ không bị cộng dồn, nên cấu hình phân tán gần như chắc chắn nhanh hơn
  • Tôi đã mô phỏng và đo độ trễ 5ms cùng jitter giữa các máy trong homelab của mình. Chạy chia nhỏ hoạt động khá tốt ở mức độ trễ WAN trong một vùng đô thị lớn, nhưng không nhanh lắm trên WAN toàn cầu
    Mục tiêu là gom nhiều máy không có RDMA chuyên dụng hay fabric NVLink thành một cụm, dùng phần cứng mình sở hữu để cung cấp mô hình lớn và chia sẻ với người khác. Hiện tôi đang triển khai chạy GLM 5.2 khoảng 10 tok/s trên cùng cấu hình chia nhỏ đó
  • Có thể ước lượng hiệu năng khá đơn giản. Với autoregressive decoding, mỗi token cần truyền qua mạng khoảng 2 × hidden_size × num_shards byte; với prefill thì chia giá trị này cho kích thước chunk
  • Tốc độ này tương tự những gì tôi đạt được khi chạy Qwen3.6-35B-A3B trên Framework 13 dùng AMD Ryzen AI 9 HX 370. Nếu mô hình lớn hơn nhiều cũng đạt cùng tốc độ thì thật ấn tượng

• Tôi quan tâm hơn đến suy luận phân tán cho các mô hình ngôn ngữ nhỏ được làm riêng cho mục đích cụ thể, thay vì LLM dành cho coding. Dùng cho xử lý ảnh, radio định nghĩa bằng phần mềm (SDR), quan trắc thời tiết địa phương, v.v. thì có thể chạy trên cấu hình bình thường mà vẫn cho đầu ra đáng tin cậy

  • Thay vì một mô hình có X expert đang hoạt động, có vẻ phù hợp hơn là đặt 10 mô hình nhỏ, dense và khác nhau được huấn luyện bằng thông tin chuyên biệt lên 10 server, rồi nối chúng bằng một router

• Tôi là người đóng góp cho Mesh LLM và đã tạo engine skippy, thứ cho phép chia mô hình lớn ra nhiều node. Nếu có câu hỏi, tôi sẽ trả lời

  • Thật vui khi thấy công nghệ liên quan đến IPFS xuất hiện trở lại. Tôi có hai điều muốn hỏi
    Thứ nhất, khi phân tán tính toán theo cách này, mọi bên tham gia trong đồ thị tính toán đều biết chuỗi đang được xử lý, vậy xử lý quyền riêng tư thế nào? Thứ hai, có cơ chế bảo vệ nào để ngăn người tham gia độc hại làm bẩn activation của mô hình không?
  • Tôi tò mò động lực tham gia mesh công khai là gì. Nếu cung cấp 1/8 lượng VRAM cần để chạy một mô hình cụ thể, có bảo đảm công bằng kiểu ít nhất nhận được 1/16 mức sử dụng suy luận không?
  • Có lợi ích gì nếu tích hợp với dự án Colibri vừa được công bố vài ngày trước không?
  • Tôi chưa từng xem sâu cách triển khai KV cache, nên tò mò liệu về cơ bản nó có vận hành cache độc lập theo từng layer không
    Nếu đúng vậy thì nó được chia tách gọn gàng về mặt khối lượng tính toán và kích thước dữ liệu, và chỉ chậm ở thời gian mỗi layer phải chờ đến lượt. Nếu dựng pipeline thì cũng có thể chạy nhiều truy vấn cùng lúc
    Đã có trường hợp nào triển khai best-of-N bằng pipeline N bước, đưa các truy vấn vào lệch nhau từng bước chưa?
  • Tôi vận hành một lab có nhiều bộ xử lý EPYC và nhiều mô hình khác nhau; thật ấn tượng khi có thể gom chúng lại theo cách này

• Khi tìm các LLM theo kiểu điện toán phân tán tương tự, tôi thấy AI Horde, một số thử nghiệm nhỏ bên Aphrodite, và huấn luyện phân tán của Nous Research
  Trong số đó, AI Horde có vẻ lớn nhất. API dùng định dạng hoàn thành văn bản KoboldCPP chứ không phải chat completion. Nó phơi bày nhiều biến điều chỉnh hơn, giúp kết quả tốt hơn trong roleplay, nên có vẻ các thành viên tích cực của cộng đồng rất chuộng cách này. Những mục đích khác hầu hết sẽ cần tool calling, nên ngoài roleplay ra tôi không rõ còn dùng vào đâu
  Tuần này tôi bắt đầu cải tiến bridge OpenAI để hỗ trợ chat template và parsing phản hồi. Nếu phát hành chính thức thành công, có thể dùng cho coding dù phải dùng mô hình roleplay
  Cơ chế chống lạm dụng cũng đầy đủ hơn. Để ngăn tấn công có tổ chức, worker phải đạt tổng thời gian hoạt động 1 tuần mới được công nhận là đáng tin cậy, và người dùng có thể chỉ chọn worker đáng tin cậy. Vận hành worker sẽ kiếm được kudos, dùng cho các lượt sinh dài hơn tối đa 512 token; còn yêu cầu miễn phí bị đẩy xuống cuối hàng đợi

• Tôi từng tò mò một botnet đa hình chạy một hoặc nhiều LLM phân tán có thể làm được gì. Ý tưởng là dùng mọi host của botnet làm tài nguyên tính toán cụm để chạy LLM, rồi dẫn dắt cách phát tán và payload của từng cụm botnet tiến hóa
  Biến thể tệ sẽ bị phát hiện và loại bỏ, cách phát tán không hiệu quả sẽ không lan rộng, còn phiên bản tốt nhất sẽ sống sót và tiếp tục lớn lên. Nó khá giống cấu trúc được giới thiệu ở đây, và QUIC hoạt động rất động nên có thể khó bị phát hiện hơn tưởng tượng

• Dự án https://query.mt/ đã dùng mesh dựa trên iroh một thời gian. Nếu muốn dùng mô hình mesh cả trên điện thoại, đáng để thử

• Tôi đã vật lộn một thời gian để chạy mesh-llm, nhưng trong các bản build llama.cpp có thể cài được, không bản nào chạy trên GPU cũ của tôi. Có vẻ có thể proxy dịch vụ llama.cpp bên ngoài, nhưng tôi cũng không cấu hình thành công
  Đây là dự án rất thú vị, nhưng vẫn còn khá nhiều phần chưa được trau chuốt

  • Nếu bạn gửi báo cáo lỗi, tôi muốn cùng xử lý để nó chạy được

• Tôi nghĩ cách này có thể khả thi nên khoảng 1 năm trước đã hỏi ChatGPT, nhưng nhận được câu trả lời rằng độ trễ quá lớn nên không thể. Khi đó tôi đã học libp2p gần một năm và đang tìm một dự án để ứng dụng