4张R9700搭建本地AI服务器：1.8万美元支撑10人团队实测

一套面向小团队的本地推理方案

一位开发者在Reddit分享了为客户搭建的本地大模型推理服务器方案，整套配置约1.8万美元，目标是为一家10人规模的初创团队提供私有化的AI推理能力。这类需求正在变得越来越普遍——团队既想要大模型能力，又不愿把代码和数据持续送往第三方API，本地部署成为折中选择。

这套方案的核心亮点在于用4张AMD Radeon R9700 AI Pro显卡堆出128GB显存，并通过精细的功耗控制把整机压在相对可控的电力预算内。对于预算有限但对数据隐私敏感的小团队来说，这是一个值得参考的真实样本。

硬件配置拆解

整机的关键规格如下：

• CPU：Threadripper 9970X
• 内存：128GB DDR5 ECC 5600
• GPU：4× AMD Radeon R9700 AI Pro，单卡32GB显存，合计128GB VRAM
• 电源：1600W PSU

一个容易被忽视的细节是功耗管理。原帖提到所有GPU都做了欠压（undervolt）处理，每张卡功耗控制在210W以下。四张卡满载也不过840W左右，加上CPU和其他组件，1600W电源留有充足余量。这种做法在多卡本地部署中非常实用：欠压不仅降低了电费和散热压力，还能让整机在普通电路和机箱条件下稳定长时间运行，对小团队办公环境尤其友好。

选择AMD而非NVIDIA方案，很大程度上是出于性价比考量。单张32GB显存的专业卡在同等显存容量下，整体采购成本往往低于同级别NVIDIA方案，这也是整套系统能把总价压到1.8万美元的重要原因。

软件栈与模型选择

推理引擎方面，作者使用了Radiance的一个分支（fork）来对外提供服务。承载的模型包括Qwen3系列（27B及Next flash版本）以及DSV4 Flash。KV缓存统一采用BF16精度，模型权重则部分采用MXFP4量化。

这里的组合逻辑清晰：用MXFP4量化压缩模型体积以塞进有限显存并提升吞吐，同时保留BF16的KV缓存以维持较长上下文下的质量稳定。对于一个需要同时服务多名工程师的团队，吞吐量和并发能力比单次请求的极致延迟更重要，这套配置明显是朝着并发服务优化的。

MXFP4（Microscaling Float Point 4-bit）是由Nvidia、AMD、Intel等厂商共同推进的一种新型量化格式标准，属于MX系列微缩放浮点格式之一。与传统INT4或NF4量化不同，MXFP4在每组（通常32个元素）共享一个缩放因子，在极低位宽下保留了更好的数值表示范围。相比INT8量化，MXFP4能将模型权重的存储大小进一步减半，使得在有限显存内塞入更大参数量的模型成为可能。BF16（Brain Float 16）则是谷歌推出的16位浮点格式，相比FP16拥有更宽的指数范围，更不容易出现数值溢出，在大模型推理的KV缓存场景下能更稳定地维持计算精度。将二者结合——权重用MXFP4压缩以节省显存、KV缓存用BF16保持精度——是当前多卡本地推理中兼顾吞吐与质量的主流工程策略。

实测性能数据

作者给出了相当详细的实测结果，核心指标集中在并发会话、prefill（预填充）和decode（解码）吞吐上。

16并发会话 · Qwen3 27B（MXFP4）

• 聚合prefill：6,300–6,800 tok/s
• 聚合decode：80 tok/s起步，峰值可达约900 tok/s
• 每用户上下文范围：4K–128K

Qwen3 Next flash

• 每用户48K上下文：prefill 6,880 tok/s，聚合decode 538.5 tok/s
• 每用户128K上下文：prefill 3,050 tok/s，聚合decode 365 tok/s

从数据能看出两个规律。其一，随着每用户上下文从48K拉长到128K，prefill吞吐几乎腰斩（6,880降到3,050），这符合注意力计算量随上下文增长的预期。其二，即便在128K超长上下文下，系统仍能维持数百token/s的聚合解码速度，对于十来个人日常的代码补全、文档问答和Agent任务来说完全够用。

需要说明的是，这些是聚合吞吐（所有并发会话加总），单个用户感受到的速度会是聚合值除以活跃并发数。16个会话同时跑满时，单用户体验会相应下降，但对于不会所有人时刻并发请求的真实办公场景，这套配置的余量相当充裕。

Prefill（预填充）和Decode（解码）是大模型推理的两个阶段，理解二者的区别有助于解读上述数据。Prefill阶段指模型一次性处理完整输入提示词（prompt），计算出所有token的注意力表示并填充KV缓存，这一阶段高度并行、吞吐量大，但耗时随上下文长度平方级增长。Decode阶段则是逐token自回归生成输出，每次只生成一个token，速度受限于显存带宽而非算力。正因如此，超长上下文会导致prefill吞吐大幅下降（如文中48K到128K时从6,880降至3,050 tok/s），而decode速度则相对稳定。对于代码补全等短输出场景，decode速度是用户感知延迟的主要决定因素；对于文档摘要等长输入场景，prefill延迟则更为关键。

对小团队本地部署的启示

这个案例的价值不在于某项性能纪录，而在于它展示了一个可复制的工程平衡点：用消费级/专业级AMD多卡+积极的功耗管理+量化模型，在不到2万美元的预算内，为10人团队提供私有化的多模型推理服务。

几点可供参考的经验：

• 显存容量优先。128GB VRAM让它能同时承载多个模型或支撑超长上下文，这是本地部署能否实用的关键门槛。
• 欠压是多卡方案的刚需而非可选项，它直接决定了整机的可部署性和运行成本。
• 聚合吞吐数据要结合真实并发模式解读，不能简单当作单用户体验指标。
• AMD生态在推理场景下已经可用，配合合适的推理引擎（如本例的Radiance分支）能跑出不错的成绩。

当然，这只是单一来源的个人分享，具体数据未经第三方复现，不同模型版本、量化策略和引擎实现都会显著影响结果。对于考虑自建推理服务器的团队，这更适合作为选型思路的参考，而非照抄的配置清单。