最近我把手头的两块 NVIDIA GB10 拼成了一个两节点推理集群目标很直接在本地把 DeepSeek-V4-Flash 完整跑起来。GB10 这颗桌面级芯片的单机能力其实已经不弱统一内存 128GBFP4 算力标称约 1000 TOPS但真要塞下 V4-Flash 这种大参数 MoE 模型单机显存和带宽立刻变成紧箍咒。折腾了一周从烧系统、配 RoCE 网络到调 vLLM 张量并行参数中间踩了不少坑。最深的感受是算力到位之后节点之间的带宽才是决定性能的胜负手。这篇文章把整个部署过程、选型思路、实测数据和典型报错完整整理出来。适合两类人看一是手头有 GB10、DGX Spark 这类桌面级 AI 设备想本地跑 MoE 大模型的朋友二是团队想用两台或多台工作站组小规模推理集群但拿不准互联带宽到底够不够用的同学。我会把我怎么组的、为什么这么组、各个参数背后是什么逻辑以及实测数据里哪些地方赢、哪些地方亏一次讲清楚。1. 为什么双节点单机到底差在哪一口气1.1 GB10 的算力上限与显存天花板先给不熟悉 GB10 的朋友补个背景。GB10 是 NVIDIA Grace Blackwell 平台里偏桌面和工作站的一颗芯片搭载 128GB LPDDR5x 统一内存CPU 和 GPU 通过 NVLink-C2C 共享这份内存。放在一年前这规格跑 20B 级别的模型算是富裕但 DeepSeek-V4-Flash 是不一样的物种它虽然是 MoE 架构激活参数不多可总参数体积摆在那里单用 FP8 存权重就几乎把 128GB 吃穿还没算 KV cache、CUDA context、运行时碎片和系统保留。很多人会下意识觉得“128GB 统一内存就是 128GB 显存”实际用起来完全不是这么回事。系统保留、驱动、cuDNN context、NCCL buffer 都要占空间实测留给推理的可用内存大约在 110GB 上下。单节点要跑 V4-Flash只能把权重压到 4bit推理精度、上下文长度、并发能力三者必然要牺牲一个。我一开始就在想既然一块不够那就上两块。但加节点不是做加法这么简单。模型并行之后每个 Transformer 层的前向传播都要跨节点同步中间结果算力上去了网络带宽立刻变成新瓶颈。这也是我把这篇文章主题定为“算力与带宽的博弈”的原因——分布式部署的真正难点从来不是单卡算力而是卡与卡之间怎么喂饱数据。1.2 单节点实测瓶颈到底卡在哪在决定组双机之前我先老老实实跑了一轮单机基线。用 vLLM 把 V4-Flash 量化到 4bit 塞进单块 GB10上下文设 64K单用户连续问答时解码速度大约 20 tokens/s。看着数字还行但只要并发拉到 4 个请求吞吐直接掉到 12 tokens/s 上下多路长文生成尤其吃力。进一步看监控数据瓶颈主要有三个。第一是统一内存带宽有限虽然标称带宽不低但 MoE 模型推理时专家参数要被反复拉取内存带宽很快耗尽。第二是 KV cache 跟权重抢显存上下文一长KV cache 预留不够vLLM 只能走 swap 到 CPU 的慢路径速度断崖下跌。第三是模型量化后精度损失在代码生成这类任务上4bit 下偶尔会出现逻辑链条断裂的情况。单机方案的可接受度不高所以双节点的想法就变得很自然。但两台机器怎么协同是摆在我面前的第一道选择题。2. 双机集群怎么组最划算2.1 三种拓扑方案对比TP、双副本、异构分工组双节点有几种常见玩法各有利弊。我把它们理成一张对比表方便后面展开讲方案模型放置方式需要高带宽互联解决的问题主要缺点张量并行TP2模型参数按层内维度切到两台强烈需要单机显存装不下大模型通信极其频繁带宽不足会拖垮性能双副本负载均衡两台各放一个完整模型不需要提升并发吞吐、做高可用不解决单机装不下模型的问题异构分工一台跑推理一台跑网关/向量库/预填充一般需要扩展周边能力而非扩展单模型算力不算真正的推理算力叠加我最终选择了张量并行方案也就是 TP2把 V4-Flash 的权重按 Hidden 维度切到两台机器上共同推理。原因很直接V4-Flash 的 FP8 权重在两个节点加起来才能放得舒坦双副本方案压根不扩容显存模型塞不进去就是塞不进去。至于异构分工适合的场景是带 RAG、带 Agent 工作流的系统它扩展的是“外围能力”跟我想验证的算力叠加是两码事。不过 TP2 不是唯一可行的并行维度。DeepSeek 系模型是 MoE理论上还可以做专家并行把不同专家分发到不同机器。但 MoE 的 expert 分发涉及 All-to-All 通信交换量比 TP 的 All-Reduce 还要大对网络要求更苛刻。所以我的最终方案是 TP2 为主更进一步的在后面微调环节再谈。2.2 互联选型与带宽实测万兆被直接劝退组 TP2互联网络是生死线。我先用两台机器自带的万兆网口跑了一轮结果非常惨烈。理论上 TP 模式下每个 Transformer 层要跨机同步两次激活值我们来算一笔账假设模型 hidden size 是 4096序列长度 8192张量并行切分后需要 All-Reduce 的数据量大约是 2 × 4096 × 8192 × 2 字节 128MB万兆网卡实际有效带宽约 1.1GB/s单次同步耗时接近 100ms。而模型有几十层跑一个 8192 token 的完整前向光通信就要好几秒这比单机更慢毫无价值。所以我直接把互联升级到 RDMA 网络。我这边用的是 ConnectX 网卡走 RoCE v2链路标称 200Gbps。用 iperf3 实测TCP 模式跑到 14.2Gbps 就被 CPU 中断处理卡住了切到 RDMA 之后裸带宽能到 182GbpsAll-Reduce 的延迟从毫秒级降到了微秒级。这组对比让我对“算力与带宽的博弈”有了非常具体的认知互联方式实测带宽All-Reduce 128MB 耗时TP2 是否可用万兆以太网~1.1GB/s~100ms不可用25G 以太网~2.8GB/s~45ms勉强但吃亏200G RoCE v2~22GB/s~6ms可用400G InfiniBand参考~45GB/s~3ms理想结论很简单没有 RDMA 级别的互联就别张罗跨节点 TP老老实实单机 or 双副本。我后面所有实测数据都是基于 200G RoCE v2 这条网络跑出来的。3. 从零开始的双节点部署实录3.1 软件栈选型为什么用 vLLM部署推理服务我先在 vLLM、SGLang 和 TGI 之间做了一番比较。TGI 部署简单但可调参数少遇到 DeepSeek 系模型经常要等社区补丁SGLang 在 MoE 模型上的性能表现不错但当时对 GB10 这种 arm64 平台的适配还差点意思。最后选了 vLLM原因有三个一是对 OpenAI 兼容接口支持最完整Claude Code、Trae 这类工具直接指过去就能用二是对 KV cache 的管理成熟PagedAttention 在长上下文场景下能省不少显存三是对新模型的适配速度最快遇到报错社区资料也最全。权重文件的获取渠道也比较常规。模型权重可以直接从 Hugging Face 或 ModelScope 上拉我这边网络环境访问 ModelScope 更稳就直接从 ModelScope 下载了 FP8 版本的权重。下载完检查目录完整性确认 tokenizer、config.json、权重分片都在再统一放到两台机器都能访问的目录下。这里有个细节值得强调双节点 TP 模式下模型权重可以由主节点加载后通过 NCCL 分发到副节点也可以两台机器各自存放完整权重。我建议后者也就是两个节点都放一份完整权重省去跨节点加载权重的时间也避免启动时占用 RDMA 带宽影响其他任务。3.2 vLLM 启动参数详解与KV cache计算vLLM 启动命令是这次部署的核心。我用的是类似这样的配置vllm serve /models/DeepSeek-V4-Flash \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --max-model-len 131072 \ --gpu-memory-utilization 0.92 \ --kv-cache-dtype fp8 \ --chat-template ./dsml_v4_chat.jinja逐个说参数背后的考虑。--tensor-parallel-size 2是让 vLLM 把每层的权重切成两半分别放到两台机器这是双节点算力叠加的直接开关。--distributed-executor-backend ray在双机场景下更稳虽然在单机多卡时 vLLM 自带的 mp 后端更轻量但跨节点需要 Ray 来做节点发现和分布式协调省事很多。--max-model-len 131072决定了 KV cache 的上限预留这里我做了详细的显存估算见下面。--gpu-memory-utilization 0.92是告诉 vLLM 可以吃掉 92% 的可用显存留一点余量给运行时。KV cache 的显存估算可以直接套公式。假设模型有 61 层每层 4 个 KV 头每个头的维度是 128使用 FP8 存储那么单 token 的 KV cache 占用是2K 和 V × 4KV 头 × 128头维度 × 1FP8 一字节 1024 字节。跑 131072 token 的上下文单层需要 134MB全部 61 层合计约 8.2GB。这个数字在 128GB 统一内存面前不夸张但要算上 236B 总参数的 FP8 权重约 236GB两台分摊后每台约 118GB显存就已经非常紧张。实际操作中我还得控制 NCCL buffer 和系统保留所以把执行器的 buffer 大小调低了一些避免两个节点因为内存紧张触发 OOM。vLLM 在启动时如果发现显存不够会直接报ValueError: Not enough memory见到这个错就得往回减max-model-len或调低gpu-memory-utilization。3.3 双节点张量并行的数据流与通信配置TP2 跨节点的数据流核心是 NCCL 通信。vLLM 每个 Transformer 层的计算会先做本地分片的线性变换然后跨节点做 All-Reduce 把结果拼回完整张量。这一步走的是 NCCL 的 RDMA 通道所以网络质量直接决定端到端性能。启动前我在两台机器上都做了 NCCL 环检测确保 RDMA 模式正常。常见问题有两类一类是网卡没有正确绑定到 NCCL走回了 TCP socket表现为 All-Reduce 延迟突增另一类是不同机器的 GPU 拓扑不一致导致 NCCL 选了低效的通信路径。这些都通过环境变量解决比如设置NCCL_IB_TIMEOUT、NCCL_IB_RETRY_CNT之类的参数。梳理下来稳定性核心其实是把NCCL_IB_DISABLE0和NCCL_SOCKET_IFNAMErdma网卡名显式设置好别让 NCCL 自己去猜。3.4 客户端接入与 API 兼容层配置模型服务起来之后对外就是一个 OpenAI 兼容的 HTTP 接口默认端口 8000。这一步的接入门槛很低但坑都在模型名和端点细节上。接 Claude Code 的时候我在配置里指定 base URL 指向主节点的http://主节点IP:8000/v1模型名必须填deepseek-v4-flash用本地 vLLM 部署时模型名来自启动命令里的目录名如果你目录名取的是别的接口就会找不到模型。接 Trae 也一样在自定义模型配置里填同样的 base URL 和模型名即可。这一节看起来平淡但后面马上会讲到客户端接入之后thinking mode 的处理机制会给你上一课。4. 实测数据算力跑满了吗带宽拖后腿了吗4.1 吞吐与首Token延迟对比部署完成之后我做的第一轮测试是对比单节点 4bit 方案和双节点 TP2 FP8 方案的吞吐表现。测试用的是一组代码生成和文档摘要混合的请求集分别测单并发和 8 并发场景单节点 4bit双节点 TP2 FP8提升幅度单用户短问答首 token 延迟0.8s0.6s25%单用户连续长文生成decode 速度20 tok/s32 tok/s60%8 并发混合负载总吞吐42 tok/s104 tok/s147%8 并发下每用户平均延迟3.1s1.7s45%看到这个结果我第一反应是“双节点值了”。但拆开分析会发现它的优势在不同场景下差异很大。短问答场景提升只有 25%因为单次请求的 KV cache 很小、计算量也不大双节点多出来的通信开销吃掉了大部分算力红利长文生成场景提升到 60%因为 decode 阶段每生成一个 token 都要跑完整前向双节点的算力叠加开始显现并发一上来吞吐直接翻倍多因为两个节点的中间激活和 KV cache 总容量都翻倍了可以同时处理更多请求。这说明什么双节点 TP 的真实收益不在低延迟而在高吞吐和长上下文。如果你的业务是单用户对话、短请求为主那 GPB10 双机的性价比并不高如果团队要接 IDE 插件、批处理工具这类并发场景双节点的优势立刻兑现。4.2 长上下文场景是重灾区我把max-model-len拉到 128K 后又做了一轮测试发现“算力与带宽的博弈”在长上下文中被演绎得淋漓尽致。128K 上下文时 KV cache 需要预留约 8.2GB这部分计算之前已经算过但它带来的问题是每轮 prefill 的中间激活会变得更大跨节点通信量也跟着涨。实测在不同上下文长度下的 decode 速度上下文长度双节点 decode 速度相对 32K 的下降32K32 tok/s—64K27 tok/s-15.6%128K21 tok/s-34.4%长上下文时吞吐下降的直接原因有两个。一是 KV cache 占用增加后单请求占用的显存变大vLLM 的调度器能并发处理的请求数变少总吞吐自然下降。二是 prefill 阶段每处理一个长 prompt 都要做大量跨节点 All-Reduce通信数据量和序列长度线性相关带宽被 prefill 打满之后decode 阶段能分到的带宽就少了。这里有个结论可以分享对 MoE 大模型的长上下文场景哪怕有 200G RDMA通信仍然是不可忽略的瓶颈部署时就得把“长上下文”单独做资源预留和并发限流别和短请求混在同一服务里。4.3 功耗、成本与收益核算最后算一笔账。单块 GB10 平台在满负载推理时整机功耗大约 350W双节点就是 700W 上下。按照工业电价估算24 小时不间断跑的话一天电费大概几十块钱。从收益上看双节点带来的收益用单机 4bit 方案做对比同样的 8 并发负载双机吞吐是单机的 2.5 倍左右但功耗只多了一倍单位 token 的能耗成本反而降低了。不过这笔账还得算上硬件成本。如果第二块 GB10 只是偶尔跑大模型、平时闲置那绝对划不来如果你有长期跑服务、跑批处理、跑微调的需求双机的单位算力成本才会显得划算。我的建议是先想清楚业务负载形态再决定要不要加节点。5. 高频报错与排查实录5.1 报错速查表整个部署过程中我记录了四个高频报错都很有代表性。先给一个速查表后面逐个展开讲排查思路报错/现象根因解决方案HTTP 400reasoning_contentmust be passed back to the apithinking mode 下未回传思维链字段网关层缓存并回传reasoning_content或客户端关闭 thinking modeThe supported API model names aredeepseek-v4-pro、deepseek-v4-flash...网关模型白名单与请求模型名不匹配修改客户端 model 字段输出中出现 /dsmlparameter 等标记本地网关切换失败导致请求打到错误后端本地 API 网关节点路由配置失效检查网关配置的模型名和上游地址5.2 thinking mode 与 reasoning_content 回传机制第一个报错是接入 Claude Code 时遇到的错误信息长这样provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这个错误的背景是 DeepSeek 系模型支持“思考模式”也就是模型在给出正式回答之前会先产出一段内部推理内容API 把这个推理内容放在reasoning_content字段里返回。坑就在这在连续多轮对话中如果客户端或网关没有把上一轮的reasoning_content原样带回给服务端服务端就认为推理状态丢失直接拒绝请求返回 400。为什么要强制回传我的理解是DeepSeek 的 thinking mode 要求多轮对话中保持推理链的完整性如果只传用户的新消息不传历史推理内容模型无法在同一个上下文里延续之前的思考状态生成结果的质量和一致性都会受影响。所以服务端干脆用 400 强制拦截。解决方案有两种。一种是粗暴但有效的在客户端配置里直接关闭 thinking mode比如把请求参数里的thinking设为关闭这样接口就不会返回reasoning_content也就没有回传问题。另一种是把请求交给一层网关做智能处理网关在首次请求时缓存reasoning_content后续请求自动追加到上下文中再转发给上游。后者对用户体验更好因为保留了模型的推理能力。5.3 模型名白名单与网关路由问题第二个报错也是做 API 网关时遇到的服务端直接返回一段提示The supported API model names are deepseek-v4-pro, deepseek-v4-flash, and deepseek-v4-mini...这个报错本质上是模型名不匹配。我在网关层配置了一个上游模型池里面只挂了几个白名单模型名但某个客户端请求时传的 model 字段写成别的名字比如默认的gpt-4或者错误的版本号网关找不到对应模型就直接拒绝。排查思路很简单先在服务端用 curl 直接请求http://主节点IP:8000/v1/models看当前服务支持哪些模型名再到客户端配置里把 model 字段改成一致。如果你用的是网关中转服务还要检查网关的路由表确认“模型名 → 上游推理服务地址”的映射关系没有错位。这个报错在接入 Claude Code、Trae 这类工具时极易出现因为这些工具内置的模型下拉列表不会自动读取你本地服务的模型名必须手动填。5.4 Trae 接入后出现 dsml 参数标记泄漏第三个问题更有意思是把 Trae 指向本地部署服务之后对话回复里经常冒出/|dsml|parameter这类尖括号标记看起来像是模型把内部协议标记当成了正文输出。dsml在 DeepSeek 系模型里一般指模型消息语言用来在 special token 层面标记参数和消息的边界。正常的生成流程中模型输出到/|dsml|parameter之后就应该停止不把它展示给用户。出现泄漏说明服务端的停止词或 chat template 配置有问题。我的排错分三步走。第一步检查 vLLM 侧的 tokenizer 是否完整模型目录下的tokenizer_config.json里有没有正确的 special token 定义第二步检查 chat templateDeepSeek 系模型如果要保持官方行为通常需要单独指定--chat-template为官方 jinja 模板不能随便用通用模板第三步显式设置停止 token在 vLLM 启动命令里加上--stop-token-id对应模型的结束标记 ID比如 dsml 结束符。一层层查下来最终定位到是 Trae 客户端拼 prompt 时用了自定义前缀绕过了我配好的模板导致模型没吃到正确的结束指令。解决方式是统一走 vLLM 的 chat 接口不要在客户端层自己做模板拼接。5.5 本地网关切换失败的实战处理最后一个是“本地网关切换失败”类的问题通常表现为请求打到了错误的后端或者明明改了配置却不生效。我遇到的具体场景是本地网关配置了多个模型入口准备从 deepseek-v4-pro 切到 deepseek-v4-flash结果切换后请求仍然走到旧节点返回的也是旧模型的行为。这个问题的排查点主要集中在三处一是网关配置文件的模型名和实际服务不一致二是客户端侧缓存的模型端点没有刷新三是网关所在主机防火墙或路由规则把请求拦截或重定向了。处理时我先用 curl 带同样的模型名直接请求目标服务确认后端是通的然后重启网关进程并清掉本地 DNS 缓存最后确认路由表里新模型名指向的 IP 和端口确实是 vLLM 服务所在节点。这些都是常规步骤但往往就是某个环节没刷新导致一连串诡异问题。6. 延伸在双节点上跑 Micro-Finetune6.1 MindSpeed-LLM 做 V4-Flash 微调的基本思路部署完成、推理稳定之后我又做了一步延伸实验在双节点上用 MindSpeed-LLM 对 V4-Flash 做轻量微调。MindSpeed-LLM 是昇腾生态里的一套大模型加速与微调框架支持 MoE 结构也能对接多节点分布式训练。虽然 GB10 平台和 MindSpeed-LLM 的默认适配场景不完全一致但通过修改数据并行和专家并行配置能比较好的用起来。微调相比推理最大的区别是显存消耗。推理只需要存权重、激活和 KV cache微调还要额外存梯度和优化器状态。对于 V4-Flash 这种大参数 MoE 模型全量微调在双节点上也扛不住所以我选择 LoRA 低秩微调只在注意力层和部分专家层的权重上挂低秩矩阵。这样新增的可训练参数只有原模型的极小比例大幅降低优化器状态的内存开销。MindSpeed-LLM 的配置项里我主要关注三个维度数据并行度、张量并行度和专家并行度。双节点的场景下我设数据并行 1、张量并行 1、专家并行 2让不同专家分到不同节点这样既利用了双节点的显存容量又避免了张量并行频繁的跨节点通信。LoRA 的 rank 设置为 32alpha 设置为 64用 FP8 混合精度做训练实测能塞进两块 GB10 的显存预算。这个配置不一定是任务最优但作为起步模板足够稳定。6.2 一组可复用的双节点调优清单做完推理和微调两轮实验我把值得固化的经验整理成一份清单方便后面或同配置的朋友复用网络层面优先上 RDMARoCE 或 InfiniBand并关闭交换机的 PFC 流控死锁检测避免长尾延迟MTU 统一开 9000 巨型帧。启动层面显式设置 NCCL 网卡和NCCL_IB_TIMEOUT避免 NCCL 探测到错误的接口导致性能回退gpu-memory-utilization不要拉满到 0.99留 6% 至 8% 余量给运行时和通信库。调度层面长上下文和短请求分离部署或者用 vLLM 的--max-num-seqs显式限制单请求并发防止 prefill 打爆带宽拖垮 decode。监控层面看板里同时盯 GPU 利用率和 RDMA 网卡收发速率任意一项长时间跑满都需要警惕推荐nvidia-smi dmon配合rdma_stat一起看。结尾的个人体会这次双 GB10 部署最大的体会一句话总结算力和带宽是一对冤家省下的每一分算力都有可能被互联还回去。我在万兆网络上的第一次 TP2 尝试性能甚至不如单机那一刻我才真正理解为什么数据中心里做分布式训练必配 InfiniBand。如果预算有限我的建议是优先把单节点的显存和内存带宽拉满确认模型确实塞不下再考虑第二节点一旦决定上多节点网络设备上千万别省RDMA 不是可选项而是必需品。最后再分享一个实操小技巧在 vLLM 服务起来之后先用curl对/v1/chat/completions发一个最小请求验证连通性再接入 IDE 工具。很多看起来像“模型回答质量差”的问题根源其实是客户端和服务端的模板、模型名不一致这种基础问题在接入复杂工具前多花三分钟测试能省掉后面好几个小时的排障时间。