Distributed AI/LLM for the people. Share compute privately or publicly to power your agents and chat.
1.3k
Stars
156
Forks
47
Open issues
20
Contributors
AI Analysis
Mesh LLM is a distributed inference system written in Rust that pools GPUs and memory across multiple machines to serve LLMs via an OpenAI-compatible API. It is purpose-built for operators and developers who want to share compute resources privately or join public meshes for collaborative model serving, with features like intelligent routing, layer-stage splitting for oversized models, and peer discovery. This is not a general-purpose tool—it targets infrastructure operators, distributed syst...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Rust-based mesh networking layer for distributed LLM inference with OpenAI-compatible API
Mesh LLM pools GPU and memory resources across multiple machines to serve language models via a unified OpenAI-compatible API. Built in Rust, it targets operators who want to run models across a cluster without centralized infrastructure, supporting model splitting for models too large for single nodes. The project is very new (created February 2026) but shows sustained activity and a thoughtful architecture design for distributed inference routing and peer discovery.
Launched in February 2026, Mesh LLM appears positioned at the intersection of decentralized compute (via Nostr-based discovery) and practical LLM serving. It reuses llama.cpp-compatible GGUF format and borrows concepts like layer splitting from prior distributed inference work, but bundles orchestration, mesh routing, and operator control in a single Rust binary.
1,234 stars in ~4.5 months with 35 stars in the last week suggests steady but not viral adoption. The 150 forks and recent push (2026-06-30) indicate active development. Growth pattern appears driven by niche interest in decentralized/self-hosted LLM infrastructure rather than mainstream adoption rush; appeals to operators and privacy-conscious users rather than API consumers.
Adoption not verified. README provides quickstart and CLI examples but includes no case studies, testimonials, or deployment counts. The public mesh invite mechanism and web console suggest beta/preview maturity. MoA (Mixture-of-Agents) gateway is explicitly labeled experimental. No public evidence of production usage at scale or in named organizations.
Based on README: single Rust binary exposing OpenAI-compatible `/v1` API. Routing logic directs requests by model name to appropriate peer or local instance. 'Skippy' stage-splitting coordinator plans layer ranges across nodes; gossip-based peer discovery with Nostr backend for public meshes; invite-token join for private meshes. Owner control plane separate from public mesh plane. Likely uses async Rust (Tokio or similar) and gRPC or custom protocol for inter-node communication, but implementation details not visible from README.
Not documented in README. No mention of CI/CD pipelines, test suites, or coverage targets.
Last push 2026-06-30 (same as current date per prompt) indicates very recent activity. 35 stars in last 7 days and 150 forks suggest ongoing contributor interest. README is comprehensive with multiple linked design docs (MOA_GATEWAY.md, SKIPPY_SPLITS.md, FAMILY_STATUS.md), indicating deliberate documentation effort. No evidence of stagnation; appears actively maintained at 4.5 months post-launch.
ADOPT IF: you operate a cluster of heterogeneous GPUs, need decentralized model serving without central broker, want OpenAI-compatible API, and tolerate beta tooling and limited community. AVOID IF: you need production-hardened stability, require commercial support, or lack operational experience with distributed systems (this is an orchestration tool, not a simple single-binary service). MONITOR IF: you are evaluating decentralized LLM infrastructure; the project shows intent and velocity, but real-world deployments are not yet publicly documented, and core features like MoA are experimental.
Independent dimensions
Mainstream potential
3/10
Technical importance
6/10
Adoption evidence
2/10
- Very young project (4.5 months old); API, discovery protocol, and wire formats may change incompatibly between releases despite Apache 2.0 license, as evidenced by MoA experimental warning.
- Adoption not verified; no public case studies or deployment counts make it unclear whether design assumptions hold in practice at scale or multi-cloud.
- Nostr-based public discovery is novel for LLM infrastructure; unclear how decentralized mesh discovery will perform under real-world network partitions, join storms, or adversarial peer behavior.
- Skippy stage-splitting requires manual model packaging and layer coordination; likely to be operationally complex for non-trivial deployments compared to monolithic model serving.
- Single maintainer or small team inferred from rapid iteration velocity; project may suffer if core contributors leave before community is large enough to sustain it.
Likely to remain a niche but viable option for privacy-focused and decentralized-compute advocates over next 12–24 months. Will either stabilize API/discovery protocols and accumulate production users, or stall if operational complexity and immaturity block adoption. Mainstream LLM serving via traditional cloud providers unlikely to be displaced.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- http://meshllm.cloud/
- Language
- Rust
- License
- Apache-2.0
- Last updated
- 16h ago
- Created
- 5mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Split serving: second worker's stage never activated, host stays "ready" alone
Console chat output pauses when switching browser tabs
perf: Sidecar hash cache for GGUF model load: eliminate SHA-256 re-hashing on every startup
MoA gateway: idle-worker judges for early hedging + hint-carrying retries
latency hiding enhancements for skippy
Top contributors
Similar repos
b4rtaz/distributed-llama
Distributed Llama enables distributed LLM inference by connecting home devices...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
1.3k | +31 | Rust | 7/10 | 16h ago |
|
|
3k | — | C++ | 7/10 | 5d ago |
|
|
53.2k | — | Python | 9/10 | 2h ago |
|
|
18.3k | — | TypeScript | 8/10 | 1mo ago |
|
|
1.1k | — | TypeScript | 7/10 | 5mo ago |
|
|
63k | — | JavaScript | 8/10 | 15h ago |
Narrower scope: focuses on splitting one model across machines. Mesh LLM adds router, peer discovery, and multi-model orchestration; more infrastructure-complete but also heavier. distributed-llama is more mature (~3x stars).
Client-side/browser-first; runs models in WebAssembly. Mesh LLM is server-centric, distributed backend. Different target use case (browser vs. data center).
LLM API abstraction layer; routes between providers. Mesh LLM is infrastructure for self-hosted distributed serving. Complementary rather than competitive; litellm could theoretically proxy to Mesh LLM endpoints.
End-user chat/RAG wrapper. Mesh LLM is lower-level infrastructure for model serving. anything-llm could potentially consume Mesh LLM as a backend.
Browser-based chat UI + local inference. Mesh LLM adds distributed backend orchestration; different architectural tier.
