distributed-llama：用 Tensor 并行把多台家用设备拼成一台大模型推理机
Distributed LLM inference. Connect home devices into a powerful cluster to accelerate LLM inference. More devices means faster inference.
秒懂
- 它是什么？
- distributed-llama 是一套基于 C++ 的分布式推理方案，它把模型权重按层切片到多台设备上，用 Ethernet 同步，从而在内存有限的设备上运行 70B 甚至 405B 模型。本文基于仓库文档和发布记录，分析它的架构、启动方式、已知限制和适用边界。
- 适合谁用？
- distributed-llama 适合那些已经拥有多台闲置设备、愿意花时间调网络和编译的人，尤其是想在本地跑 70B 以上模型、但单机内存不足的开发者或研究者。不适合追求开箱即用或需要动态扩缩容的生产环境，因为节点数必须为 2 的幂且受 KV head 数量限制，同步精度只有 q80 和 f32 两种选择。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 72 天前。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是单机内存墙，不是算力墙
大多数本地 LLM 工具把模型完整加载到一台机器上，显存或内存不够就换更大的机器。distributed-llama 换了一条路：把模型切成多份，分散到多台设备的 RAM 里，用网络把它们拼成一台逻辑上的大机器。仓库的 README 直接写明目标是“Connect home devices into a powerful cluster”。它面向的是那些手头有若干台树莓派、旧笔记本或 Mac mini、但单台都跑不动 70B 模型的人。注意，它不是为了把 8B 模型跑得更快而设计的，它的价值在于让内存总和够大的集群能加载超出任何单机能力的模型。
Tensor 并行加 Ethernet 同步，但同步精度只有两个选项
架构上分为 root node 和 worker node。root 负责加载模型和权重，把它们分发给 worker，同时同步神经网络的状态。root 自己也参与计算，处理属于自己的那一份网络切片。worker 不需要知道模型配置，只管处理分到的 slice。这种切分方式是 tensor parallelism，不是 pipeline parallelism，意味着每一层都被横向切开，所有节点同时算同一层，然后通过 Ethernet 交换中间结果。README 的架构图显示设备通过交换机连接，每个 worker 监听 9999 端口。同步时使用的浮点精度由 buffer-float-type 参数控制，目前只支持 q80 或 f32。q80 是 8-bit 量化浮点，能减少网络流量但可能损失精度，f32 则保持全精度但网络开销大。这是一个关键权衡，文档没有给出两者在吞吐上的具体差异，你需要根据网络条件自己测。
启动方式：一条命令拉起 root，再手动加 worker
最简单的路径是用 Python 脚本 launch.py。README 给出了多个预设模型命令，例如 python launch.py llama3_1_8b_instruct_q40 会下载模型和 tokenizer，并启动 root 节点。要加入 worker，得先在各台设备上编译并运行 dllama worker，使用 --host 和 --port 指定监听地址，默认端口 9999。然后在 root 节点用 --workers 参数列出所有 worker 的 ip:port，例如 --workers 10.0.0.2:9999 10.0.0.3:9999。root 自己也是一个计算节点，所以如果总共有 4 台设备，那么 root 加 3 个 worker。编译需要 C++ 编译器，README 提到支持 Linux、macOS、Windows，并有针对树莓派和 GPU 的单独文档。GPU 支持是实验性的 Vulkan，从 2025 年 3 月的 v0.13.0 开始，但 README 没有给出详细配置步骤。
除了 2 的幂节点数，还有 KV head 这个硬上限
README 明确列出两个已知限制。第一，节点数只能是 1、2、4 等 2 的幂，这意味着你无法用 3 台或 5 台设备组成集群，这对硬件规划是个约束。第二，最大节点数等于模型的 KV head 数量。KV head 是注意力机制中的键值头，不同模型数量不同，比如 Llama 3 8B 有 8 个 KV head，所以最多能加 7 个 worker。如果你有一台 16 核的机器和一个 4 核的树莓派，想组 2 节点集群，那没问题；但如果你想用 6 台旧手机加一台电脑，那 7 个节点的组合就超出了 KV head 限制。这个限制来自张量并行对注意力头切分的自然要求，但 README 没有解释具体细节，只知道它存在。
量化支持面窄，模型转换需要额外步骤
支持的量化只有两种组合：q40 模型配 q80 buffer-float-type，或者 f32 模型配 f32 buffer-float-type。q40 是 4-bit 量化，用于模型存储，而 buffer-float-type 是同步时的精度。这意味着你不能用常见的 q4_K_M 或 q5_1 格式，也不能在 q40 模型上使用 f32 同步。发布记录显示 2025 年 8 月开始支持 Qwen 3 系列，9 月支持 Qwen 3 MoE 模型，说明项目在跟进新模型，但转换工具需要手动操作。README 提供了一份 Hugging Face 模型转换指南，但具体命令没有写在主文档中。如果你有一个自定义微调模型，必须先转换成支持的格式，这一步可能成为阻碍。
与 llama.cpp 的差异：单机优化 vs 多机切分
最直接的替代方案是 llama.cpp，它同样支持 CPU 推理和多种量化格式，但它的分布式能力很弱，通常只能在一台机器内利用多核，或者通过 RPC 做简单的层间并行。distributed-llama 的 tensor parallelism 让多个设备同时计算同一层，理论上延迟更低，但对网络同步要求极高。llama.cpp 的优势在于模型格式支持丰富，社区转换工具成熟，你可以直接跑大多数 Hugging Face 模型。而 distributed-llama 需要专用转换流程，且量化选择有限。另一个区别是，llama.cpp 是单进程，而 distributed-llama 是多进程、多设备，部署复杂度高一个量级。如果你的目标是单机 8B 模型，llama.cpp 更简单；只有当你确实需要跨设备内存聚合时，distributed-llama 才有意义。
维护成本与许可证：活跃但版本节奏不规律
项目采用 MIT 许可证，意味着你可以自由使用、修改和分发，只需保留版权声明。仓库默认分支是 main，最近一次推送是 2026 年 7 月，发布记录显示 v0.16.5 在 2026 年 2 月发布，v0.16.4 在 2026 年 1 月，v0.16.3 在 2025 年 10 月。版本间隔从 3 个月到 1 个月不等，没有固定发布周期。代码库在 2025 年 2 月经历了一次大规模重构（v0.12.0），这可能导致 API 或命令参数变化，升级时需要检查变更日志。由于是个人或小团队项目，文档主要集中在 README 和几个指南文件，遇到问题可能依赖 Discord 社区。对于生产环境，你需要自己评估维护风险，但作为实验性工具，它的活跃度看起来足够。
网络是隐藏的瓶颈，先测再决定
整个方案的可行性建立在网络延迟和带宽之上。tensor parallelism 要求每生成一个 token 都要跨节点同步多次，如果交换机是百兆，或者设备走 Wi-Fi，那么同步开销可能抵消多节点带来的算力提升。README 没有提供任何性能数据，也没有给出网络要求的建议，这是文档的一个明显空白。发布记录里提到“Llama 3.3 70B on 4 x Mac Mini M4 Pro 24GB RAM”的讨论，但那是用户报告，不是官方基准。所以在投入时间编译和配置之前，你应该先用 iperf 或类似工具测一下设备间的实际吞吐。另外，root 节点加载模型和权重，RAM 占用比 worker 高，README 只说了“a bit more”，没有量化，实际需要多少取决于模型大小。
编辑结论
distributed-llama 适合那些已经拥有多台闲置设备、愿意花时间调网络和编译的人，尤其是想在本地跑 70B 以上模型、但单机内存不足的开发者或研究者。不适合追求开箱即用或需要动态扩缩容的生产环境，因为节点数必须为 2 的幂且受 KV head 数量限制，同步精度只有 q80 和 f32 两种选择。在决定采用之前，先确认你的模型能否转换为 q40 或 f32 格式，并检查你的交换机是否能承担同步流量。如果你是单机用户，或者你的模型量化格式不在支持列表内，那么直接使用 llama.cpp 或 vLLM 会更省事。
社区笔记