[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fq8lmw1khv9dt":3},{"slug":4,"category":5,"publishedAt":6,"titleZh":7,"titleEn":8,"summaryZh":9,"summaryEn":10,"models":11,"hardwares":12,"bodyZh":13,"bodyEn":14,"sourceName":15,"sourceUrl":16,"updatedAt":17},"llamacpp-b12079-nccl-multinode-2026-11-04","RUNTIME","2026-11-03T23:04:42.392Z","llama.cpp b12079 纳入跨节点 NCCL：多机张量并行有了新通信路径","llama.cpp b12079 adds a cross-node NCCL path for tensor parallelism","新构建把跨进程集合通信接入 CUDA 与 RPC。合并和发布发生在本次窗口，但上游旧速度表不能当作今天的独立复现，也不意味着任意两台电脑插网线就能提速。","The new build connects cross-process collectives to CUDA and RPC. The merge and release are new; older upstream measurements are not fresh independent results or a promise for arbitrary networked PCs.",[],[],"llama.cpp 在本次时间窗发布 b12079，将跨节点张量并行的 NCCL 支持纳入构建。上游 PR #28967 于 11 月 3 日合并，构建于当日 21:58 UTC 发布。这里确认的是通信实现进入新版本，不是 AraoAI 已完成多机复现，也不是新硬件上市。\n\n1. 改动在哪里。PR 增加了面向不同进程中各 rank 的集合通信后端接口，在 CUDA 后端使用 NCCL 实现，并在可用时交给 RPC server 使用。它建立在已有多节点工作之上；发布说明还包含针对 DGX Spark 的通信配置调整。因此，不能把“支持 NCCL”理解成所有后端、所有设备组合都走同一路径。\n\n2. 对部署有什么意义。模型拆到多台机器后，除了每台机器能装下多少权重，还要支付节点间数据交换的代价。张量并行依赖通信配合，设备、网络和后端是否真正启用该实现，都影响结果。新增路径值得已有 CUDA 多节点用户做同机群对照，但单卡用户不应据此期待自动加速。\n\n3. 什么证据仍然缺。关联 PR 创建于更早时间，其中保留了作者在 DGX Spark 上的对照表。今天合并代码，不会把旧表变成今天的新实测；本文不搬用旧吞吐数字，也不把作者单方报告提升成跨机器独立复现。对于家用以太网、异构电脑或其他后端，本次核验没有得到等条件的适用性结论。\n\n升级前应保留旧构建和完整启动参数，固定模型、量化、上下文、节点数及网络，分别观察预填充、生成速度和失败情况，再核对实际通信路径。判断不在于机器是否互相看得见，而在于计算与交换能否在同一负载下形成收益。功能已发布，收益仍需验证。\n\n来源：[b12079 发布页](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb12079)；[PR #28967](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F28967)。","llama.cpp released b12079 within this reporting window, incorporating NCCL support for multi-node tensor parallelism. PR #28967 merged on November 3 and the build was published at 21:58 UTC that day. This confirms a newly shipped communication implementation, not an independent multi-machine reproduction by AraoAI or a new hardware launch.\n\n1. Scope. The PR adds a backend interface for collectives across ranks in separate processes, implements it with NCCL in the CUDA backend, and uses it in the RPC server when available. It builds on earlier multi-node work. Release notes also include a DGX Spark-specific communication configuration adjustment. Support for NCCL must not be generalized to every backend or device combination.\n\n2. Deployment relevance. Splitting a model across machines adds communication cost as well as weight capacity. Tensor parallelism depends on exchanging data, so the devices, network and actual selected backend matter. Existing CUDA multi-node deployments have a reason to run a controlled comparison; single-GPU users should not expect automatic acceleration from this announcement.\n\n3. Evidence limits. The associated PR was opened earlier and retains its author's DGX Spark comparison tables. Merging code today does not make those older tables newly measured results. We do not reproduce their throughput figures or label them independent cross-machine validation. This review establishes no matched-workload conclusion for home Ethernet, heterogeneous PCs or other backends.\n\nKeep the previous build and full launch configuration. Fix model, quantization, context, node count and network, then compare prefill, generation and failures while checking the actual communication path. Discoverable machines are not proof of useful scaling: computation and exchange must deliver a benefit together under the same workload. The feature has shipped; its benefit for your deployment still needs verification.\n\nSources: [b12079 release](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb12079); [PR #28967](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F28967).","llama.cpp GitHub release \u002F upstream PR","https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb12079","2026-11-03T23:04:42.393Z"]