4张R9700凑128GB显存，10人公司16路跑1250亿参数模型6880 tok/s

一、四个插槽，装下了别人机柜里的显存

一家十个人的小公司，不租云账号，自己在机房里放了一台机器：四张 32GB 显卡并排插在一块主板上，合计 128GB 显存；十六个人同时用，各自跑长上下文，谁也不等谁。

发帖人把这称作"给一个客户做的交付"。帖子里没有跑分截图，只有一张配置单和四行实测数字：十六路并发下聚合预填充 6,300 到 6,800 tok/s；上下文每路 4K 时聚合解码 900 tok/s，每路灌到 128K 时掉到 80 tok/s。十二个小时里这帖拿到 620 赞、278 条评论，而最高赞那条根本没聊硬件，直接跳到结论：「我觉得那两家的墙已经出现了，这是我看到的第五个用本地模型搭起来的创业公司。」

真正让评论区从"跑得快不快"转向"这笔钱花得值不值"的，是并排出现的两条算术。发帖人说这套配置大约九个月能回本；底下一条高赞却按另一套口径算出了五年七个月。同一台机器、同一批数字，两套账差了七点七倍。这个差值，才是这条素材里最值得看的东西。

二、配置单、四行实测，和一套只有118.5MB的推理栈 一张配置单里的取舍

先把交付清单摆出来。它值得看的地方不是"堆了四张卡"，而是每处选择都在回避同一个瓶颈。

部件

规格

这么选的理由

处理器

线程撕裂者 9970X，32 核 64 线程

92 条 PCIe 5.0 通道，四张卡各跑满 x16 还有余量

主板

TRX50 芯片组

四张卡之外还得留固态和网卡的位置

系统内存

128GB DDR5 ECC，四通道

显存装不下的权重从这里取，通道数直接等于带宽

显卡

4 × R9700 AI Pro，单卡 32GB GDDR6

合计 128GB 显存，单卡官方峰值带宽 640GB/s

电源

1600W

瓶颈不在瓦数，在要凑出四个以上显卡供电口

显卡功耗

每张压在 210W 以下

降压之后实测性能损失只有 1% 到 3%

显卡本身按厂商规格页核过：RDNA 4 架构，32GB GDDR6、256 位位宽、640GB/s 峰值带宽，整板功耗 300W，PCIe 5.0 x16，支持 ECC。四张卡插满，名义聚合带宽 2,560GB/s。评论区另补了一个坑：这块主板最后一个 PCIe 插槽官方并不标 PCIe 5.0，只是处理器支持，于是它会尝试协商到 5.0。

四行实测：预填充漂亮，解码随上下文一路下坠

发帖人自述的全部性能数据只有下面四行，测试条件是十六路并发、KV 缓存统一用 BF16。

模型与量化

每路上下文

聚合预填充

聚合解码

Qwen3.8-27B MXFP4

4K

6.3–6.8k tok/s

900 tok/s

Qwen3.8-27B MXFP4

128K

6.3–6.8k tok/s

80 tok/s

Qwen3.8-Flash-Next int4 fp8

48K

6,880 tok/s

538.5 tok/s

Qwen3.8-Flash-Next int4 fp8

128K

3,050 tok/s

365 tok/s

一眼看去是两个方向：预填充几乎不随上下文缩水，27B 那两行甚至一条数都没变；解码却在同样一段区间里掉了十一倍。

把模型拆开看，就明白为什么内存会被当成必需项。Qwen3.8-27B 是稠密结构，64 层里只有 16 层是全注意力，其余 48 层是线性注意力，BF16 权重 18 个分片、合计 55.59GB，换成 MXFP4 约 14GB。Qwen3.8-Flash-Next 是稀疏结构，48 层、512 个专家、每次只激活 10 个，光权重就有 360GB——里面还塞着一张 2000 万行的查表。155GB 的另一个模型同理，比 128GB 显存还大，只能把一部分权重留在系统内存里，靠四通道 DDR5 那 204.8GB/s 喂给显卡。

所以 128GB 显存买到的不是"所有模型都装得下"，而是"能装下一部分、剩下的用内存兜住"。发帖人的原话是：DDR5 不是浪费，稀疏模型本来就要靠内存卸载跑。

引擎才是这条帖子里最反常识的部分

发帖人用的推理栈不是 llama.cpp 也不是 vLLM，而是 Radiance 的一个分支——这个名字背后是一次推倒重来。

Radiance 的前身是一套打过补丁的 vLLM 分支，给 RDNA 4 手写了注意力、门控线性注意力、全归约、MXFP4 与投机解码内核。作者后来把 vLLM 整个丢掉，用 C++ 和 HIP 从零重写成插件式引擎：模型结构、内核库、量化器都是运行时加载的动态库。

对比项

Radiance

vLLM 官方镜像

实现形态

C++ 与 HIP，插件式动态库

Python 与 PyTorch 技术栈

镜像体积

118.5 MB

9,035 MB

已发布版本

23 个标签，集中在五天里

持续滚动

目标硬件

只编 RDNA4 的 gfx1201

通用多架构

镜像体积是全文最直观的一组数字：118.5MB 对 9,035MB，差约 76 倍，两边同在 Docker Hub 官方接口上核过，同一口径。

一条评论把这件事说得很准：「128GB 统一显存是标题，但真正值得停一下的是它选了 Radiance 分支而不是 llama.cpp 或者 vLLM。这个规模下 ROCm 的支持仍然参差不齐，到第三个月这台机器顺不顺，服务层选型的权重可能比硬件规格更大。」

卡内640GB每秒，卡间63GB每秒

预填充和解码为什么会分道扬镳，答案在一个比值上。

路径

单向带宽

相对卡内显存

R9700 卡内显存

640 GB/s

1

四张卡的名义聚合

2,560 GB/s

4

PCIe 5.0 x16 卡间

63 GB/s

约 1/10

四通道 DDR5-6400

204.8 GB/s

约 1/3

预填充是矩阵乘法，吃算力，四张卡各干各的，所以随卡数几乎线性上涨；解码要逐 token 走一遍所有权重，卡与卡之间每层都得同步一次，而这一步走的是 PCIe，不是显存。卡内比卡间快约十倍——凡是走卡间的那部分，加卡就不涨。

发帖人在评论区亲手证实了这一点。有人先预言：「四张 R9700 之间没有点对点通路，每次全归约都要绕回主机内存走 PCIe，四路张量并行下预填充看着很好，解码的扩展性会明显低于线性。」发帖人的回复是：「27B 我改成了两个副本、每个副本两张卡，比四路张量并行更快。」

一句预言、一句证实，就把"该往上堆并行度，还是该横向开副本"这道题答完了。同一张卡、同一批机器，四路张量并行换两个两卡副本，是这条帖子里最实用的一条经验。

三、同一台机器，两套账差出七点七倍

讨论到这一步，硬件已经讲完了。剩下的全是账。

第一笔账是回本周期，它恰好暴露了"本地替代云"这个说法最含糊的地方。发帖人的口径是九个月：他按云侧按量调用价格，把这台机器每月能顶掉的产出折算出来，约合每月一万三到两万元人民币，于是九个月左右拉平。而评论区那条高赞走的是另一套算法——用订阅制价格去除硬件总支出，算出五年七个月。

两个数字都对，只是回答的不是同一个问题：一个问的是"这些 token 按量买要花多少钱"，另一个问的是"十六个人的订阅费加起来够不够"。前者算出九个月，后者算出近六年。任何一场"本地到底划不划算"的争论，吵到最后都会落到这个岔口上：你拿它替代的是按量账单，还是包月账单。

第二笔账是发帖人没算、但可以当场算出来的一笔。Qwen3.8-27B 有 16 层全注意力、4 个 KV 头、每个头 256 维，用 BF16 存 KV，每个 token 占 2×16×4×256×2 字节，也就是 64KB；十六路各灌满 128K 上下文，光是 KV 缓存就要 128GiB，再加 MXFP4 之后约 14GB 的权重——已经超过 128GB 显存了。

也就是说，"十六路 ×128K"是槽位上限，不是同时满载。评论区有人当场指出了这一点，并给了退路：KV 从 BF16 换成 FP8 大致能省一半，而这些卡上精度损失很小——发帖人写的是"全部用 BF16 KV"，这条提醒他没有回应。

第三笔账，是解码衰减到底有多少该记在硬件头上。有一条评论提出了另一种可能：「我在 vLLM 上测另一个模型时见过同样的多用户长上下文速度衰减，像是一个缺陷。如果修掉，多用户生成速度应该能一直撑到 262K。」换句话说，900 掉到 80 里面，有多少是显存带宽的物理规律，有多少是这版引擎的调度问题，目前分不清。发帖人的回答是"有意思，我去试 int4 再发一帖"——一个还没关闭的问题。

第四笔账是反方的，而且反方并不弱。有人算得更直接：「除非你有云厂商偷数据那种隐私顾虑，这台机器对创业公司的帮助并不比云模型大。它跑得慢，上下文一长更慢，高并发的好处会消失。」另一条补充了管理的隐性成本：「如果开发一半时间在管上下文和工具链，你换来的不是生产力，是十个烦躁的员工。」还有人提醒定价结构在变：「对写代码的十个人来说，大头账单是反复重读的上下文，不是新输入，所以回本周期取决于缓存怎么计价。」

这些反方观点没有被发帖人反驳，也没法反驳。他给出的边界很清楚：这是给一个有明确数据驻留要求、要自己跑 Agent 的客户做的，不是通用推荐。

四、对国内团队意味着什么

把这条帖子拆完之后，能拿走的判断有三条。

第一条，显存是硬通货，算力不是。这台机器的全部价值来自"四张卡凑出 128GB"这个容量数字，而不是任何一项 TOPS。有人拿一台内存更大的整机来比，被一个两套都用过的用户一句话挡回来：「四张 R9700 在并发上完全碾压它。」同一段对话里也有人提醒，这类小机器横向堆叠的收益并不线性——互联一慢，多买一台换来的就只是容量。

第二条，服务层选型的分量被严重低估。118.5MB 对 9,035MB，它意味着构建、分发、回滚的成本完全不在一个量级，同时也意味着你在赌一个五天发了 23 个版本的小项目——轻量是真的，早期也是真的。

第三条，也是最能直接抄走的一条：在卡间通路不够快的机器上，横向开副本优于纵向加大并行度。发帖人自己试过四路张量并行，最后换回两个两卡副本——这一点对那些打算"多买几张卡拼一个大模型"的团队，是最省钱的一课。

至于降压到每张 210W 只损失一到三个点、连续两周每天八小时满载温度压在 90 度以下这类细节，反倒说明：这类交付的难点早就不在"能不能跑起来"，而在"能不能在客户机房里连着跑三个月不出事"。

五、这台机器该不该出现在你的预算里

一句话总结：它证明的不是"本地可以替代云"，而是"当你的约束是数据不出门、模型要自己定版、账单要可预期时，一台四卡机器已经能服务十个人"。

那么问题留给读者：你们团队现在花的模型钱，走的是按量账单还是包月订阅？如果换成一台四卡机器，你会用哪一套算法去算回本周期？评论区聊聊。