双机约 96GB 显存，实测六款开放大模型

把两台电脑的消费级显卡拼成约 96GB 显存，就能低成本跑大模型、供整个团队使用吗？作者用 llama.cpp RPC 搭了一套双机集群，得到的结果却有些反直觉：本轮综合表现最好的 Qwen3.6-35B-A3B Q8_0，大约只占 42GB 显存，单机也能装下。

这次测试的价值，在于展示了多机推理的实际约束：网络、显卡排列、模型架构和测试方法，都会影响结论。至于标题中的 6 款模型谁更强，提供的原文缺少完整结果表，不能据此补出一份排行榜。

96GB 显存拼起来，为什么不等于一张大显卡

作者的出发点是预算有限，因此用网线直连两台机器，通过 RPC（远程过程调用）把模型按层分配到不同主机。可以把它理解为：前面的设备算完，再把中间结果交给后面的设备继续算。

这套配置共有 5 张 GPU，包括一张 RTX 5090、一张 RTX 5080 和三张 RTX 5060Ti，总显存约 96GB。作者将网络描述为标称 5Gbps 的 CAT6A 连接，实测约 4.7Gbps，吞吐量约 500 MB/s。他们先跑通官方 RPC server，没有做特殊架构优化。

显存解决的是模型能否装下，设备之间的通信则决定它能跑得多顺。

作者认为，在这个带宽条件下，llama.cpp 的 RPC 链式调用是当前可行的选择。但这是其配置下的判断，原文没有提供其他方案的对照测试。正在等待的 Thunderbolt 5 转接设备，也只是后续测试计划，尚不能算性能改善的证据。

测试时环境温度为 35°C，CPU 达到 76°C，RTX 5090 限功耗 450W，峰值温度为 68°C。这些条件有助于理解测试环境，但原文没有给出持续负载、功耗曲线或降频记录，不能进一步判断长时间运行的稳定性。

分配显存前，要先确认设备到底怎么排

作者第一次加载 Qwen3.6-35B-A3B Q8_0 时，发现主卡 RTX 5090 的显存占用不到 7GB。他原先设置了 --tensor-split 32,16,16,16,16，希望把最大份额分给主卡。

问题出在参数对应的设备顺序。实际枚举顺序是：

[ local - RPC : 5080 , local - RPC : 5060Ti , local - RPC : 5060Ti , 5090 , 5060Ti ]

远程 RPC 设备排在前面，RTX 5090 排在第四位。因此，第一个权重 32 并没有分配给作者心中的主卡。这里需要盯住的是设备列表，不能凭「本地主卡应该排第一」来填写比例。

原文还提醒，同一主机内的 GPU 排列和显存分配，会受到 --tensor-split 及加载顺序影响。不同模型的主机、显卡分配并不固定，某次截图只能代表那次运行。

另一个干扰来自显存清理。跑完 Qwen2.5 后，作者才发现之前测试留下的 SAM/CLIP 小模型没有完全卸载。这会影响可用显存，也让模型之间的比较多了一个变量。

作者讨论容量时，还提出要兼顾 8-15 人团队、KV 上下文缓存和模型精度。不过，8-15 人是他设定的使用目标，并非原文已经验证的服务能力。

为什么这次小一些的 MoE 更占优势

作者重点比较了 Qwen3.6-35B-A3B 与 Llama-3.3-70B。

Llama-3.3-70B 是 Dense（稠密）模型，作者描述其每个 token 都要经过全部 80 层计算。在这套跨 5 张 GPU、包含一次跨机网络传输的配置里，实测速度约为 10 tok/s。他认为这只勉强够一个人做翻译，仍有明显延迟。

Qwen3.6-35B-A3B 则采用 MoE（混合专家）架构，每个 token 只激活约 3B 参数。总参数量决定需要装载多少权重，激活参数量则影响每一步的计算负担；两者不是同一个指标。

原文称 Llama 的相关开销被放大约 9 倍，但没有解释计算口径，也没有拆分计算和通信耗时。这个数字可以保留为作者的描述，不能直接拿来预测其他集群的性能。

在关闭 thinking mode 后，作者从 5 个维度评估模型，认为 Qwen3.6-35B-A3B Q8_0 在速度、并发下的性能退化、翻译错误率和幻觉抑制方面综合最好。不过，所提供文本没有展开完整的五维定义和结果表。

测试主要由 Claude 3.5 Sonnet 裁判，辅以部分人工复核。原文同时标注了「Opus 4.8 equivalent internally」，却没有解释其含义，不能把两者直接视为等价裁判。

我的判断

作者最有价值的发现，是最终胜出的模型约占 42GB 显存，能够完整放进单机。**如果目标模型单机已经装得下，双机 RPC 的额外收益就需要重新证明。**它仍可能帮助装载更大的模型，但不能仅凭总显存增加，就认定吞吐和多人体验也会改善。

这份测试适合用来筛选候选模型，不适合证明模型排名。所有题目都只运行一次，没有投票或自我反思；第 3、4、5 维度分别只有 6、24、9 道题，一次有争议的判分就可能改变顺序。作者也承认题目带有主观性。

原文提到多路径推理验证可能提高准确率，但本次没有测试，仍属于推测。此外，低于 48GB 的模型放在此前文章里测试，本篇无法独立覆盖更小模型的取舍。

对于团队部署，我更关心相同请求长度下的并发吞吐、首字延迟和失败情况。原文缺少这些完整对照，所以「综合最好」应当理解为作者当前环境中的经验结论。「Max Usable Context」也只是特定资源分配下测得的上限，并非模型自身的上下文能力上限。

能拿来做什么

• 准备搭建本地 AI 编程服务时，先核算目标模型权重与 KV 缓存是否能装进单机。像原文约 42GB 的模型，应先建立单机基线，再判断是否需要跨机。
• 调整 --tensor-split 前，先记录实际设备枚举顺序，加载后逐卡核对显存占用。不要直接照搬别人按显存容量填写的比例。
• 给团队选择翻译或编程模型时，用自己的任务复测，并把单次回答质量与并发体验分开记录。原文的约 10 tok/s 不能直接代表多人使用体验。
• 每轮比较前检查显存是否真正释放，同时记录模型精度、上下文配置和 thinking mode 状态，避免把运行条件差异误判成模型差异。