去年年底我遇到一个很典型的局面单颗GB10跑DeepSeek-V4-Flash的INT8量化版日常对话完全没压力但当我试图同时挂上128k上下文的长文档任务、几路Agent并发调用还得留出窗口做实验时单机的响应就开始飘了。TOPS排行上那颗芯片的数据再漂亮一上真实负载就露馅。既然GB10节点就是干这个的干脆再搞一颗组双节点。算力翻倍的预期很美好结果实测第一周我就被带宽按在地上摩擦。这篇文章把这段经历完整记下来从组网选型、部署参数、两个经典报错到张量并行如何被网络拖垮再到最后留下来的优化方案。如果你也在折腾双节点推理或者正准备给本地算力扩容这里面的实测数据、排查链路和避坑经验应该能帮你少走不少弯路。1. 双GB10的动机拆解单机瓶颈不在算力而在并发与上下文1.1 别被TOPS排行带偏显卡AI算力TOPS排行这几个月特别火GB10的FP4算力能到上千TOPS数字确实唬人。但做推理服务的人心里要有一根弦TOPS只是芯片的峰值算力真正决定单机体验的是显存带宽、KV cache容量、服务端utilization这三件事的组合。GB10的优势在192GB LPDDR5x统一内存容量管够但带宽只有273GB/s左右比H100的3.35TB/s差了一个数量级。这意味着它更适合容量敏感、激活参数少的模型架构而不适合那种每个token都要扫一遍全部权重的稠密大模型。DeepSeek-V4-Flash恰好是MoE结构专家网络稀疏分布激活参数远小于总参数量。模型权重可以常驻这192GB统一内存里单token计算时只激活一部分专家所以它能在这个平台上跑得动而且日常小并发下响应质量很不错。但我所说的跑得动和扛得住线上负载是两码事。1.2 单机的三个真实局限我给自己列过一张表梳理为什么非要加节点长上下文的KV cache暴涨128k上下文时KV cache能吃掉几十GB统一内存再叠加多路并发显存直接告急。并发请求互相踩脚一个Agent任务把算力吃满后另一个API请求的首token时延从0.8秒漂到6秒客户端的超时告警就响了。实验与生产互相干扰加载不同量化版本要切进程一个压测任务崩了整个服务全挂。最初我考虑过单机加并发队列、或者用CPU offload硬扛但实际测下来DeepSeek-V4-Flash在GB10上的瓶颈不是算力峰值而是同时能开多少路、每路能带多长上下文。与其把所有请求塞进一台机器不如两节点分工主节点负责HTTP服务、请求排队和RAG检索从节点通过Ray加入推理集群。这样推理进程崩了不影响网关压测任务和生产请求也能互不打扰。不过这里要提个醒主节点千万别同时跑推理和数据库IO会打架。我一开始把PostgreSQL也放在主节点上长文档解析任务一跑磁盘和内存带宽被抢推理延迟立刻上浮15%左右。后来数据库挪到单独的存储机器上才稳定下来。2. 组网链路实测从千兆到USB4带宽档次决定推理上限2.1 GB10的板载网络到底有哪几路GB10节点的网络家底其实比普通PC强不少但很多人装机时压根没认真选链路。DGX Spark这类设备一般会提供USB4口和10GbE网口有些型号还预留了PCIe插槽可以扩展网卡。问题在于大部分人在组双节点时图省事直接拿千兆交换机一接或者干脆用Wi-Fi配置文档能过性能就不好说了。我动手前先做了链路带宽摸底。方法是用iperf3在两个节点之间测TCP吞吐顺便用ethtool看网卡协商速率。这里插一句很多跑不满带宽的问题不是网卡不行而是MTU没调、或者协商到了半速先排查链路再调模型参数才是正确顺序。2.2 三种链路的实测数据我在完全相同的两台GB10节点之间分别用千兆、2.5G和10Gbps SFP三种链路跑了同一组测试结果如下链路类型实测吞吐传输30GB权重大约耗时对推理的实际感受千兆115MB/s4.5分钟TP2完全不可用模型并行一步要卡半天2.5G280MB/s1.8分钟小请求勉强批量一上来就露馅10G SFP1.15GB/s26秒支撑PP2和轻量TP场景基本可用USB4桥接2.4GB/s左右13秒速度不错但CPU占用偏高长稳时出现过掉速结论很直接双节点推理集群至少10Gbps起步2.5G以下只能当数据复制集群用谈不上分布式推理。USB4桥接虽然瞬时吞吐高但我实测它的CPU占用比独立网卡高30%以上做长稳测试时还掉过速所以生产环境我没选它而是规规矩矩上了10G光口。2.3 Ubuntu下怎么确认设备的真实带宽如果有人也遇到明明买的是千兆实测只有300Mb这类问题建议按这个顺序排查ethtool 网卡名看协商速率。如果显示100Mb/s大概率是网线或交换机端口问题。ip -s link show 网卡名看丢包和重传。重传一多TCP吞吐会大幅衰减。用lspci -vvv -s 01:00.0 | grep -E LnkCap|LnkSta查PCIe设备的协商带宽。PCIe 1.1 x4的单向带宽只有1GB/s左右比想象中低得多。热词里pcie1.1*4带宽就是这个坑很多人明明插了高性能网卡结果插槽只协商到Gen1 x4等于给超跑装了个踏板车轮胎。最后用iperf3 -s和iperf3 -c做端到端吞吐测试端口别放在01:00.0设备本身上。这套排查逻辑比一上来就怀疑模型配置要靠谱得多。我在部署DeepSeek-V4-Flash之后遇到过一次吞吐异常查了半天模型参数最后发现是交换机的某个端口协商到了百兆白折腾一个下午。3. DeepSeek-V4-Flash部署实录模型选择、启动参数与两个400错误3.1 模型选型Pro还是Flash量化用哪档DeepSeek的模型分deepseek-v4-pro和deepseek-v4-flash两条路由Flash是轻量推理版本MoE结构激活参数明显少于Pro对GB10这种统一内存平台相当友好。本地部署时有个容易踩的坑模型名必须精确配置成deepseek-v4-flash不要加路径前缀、日期后缀也不要写成my-host/DeepSeek-V4-Flash这种。有次我在网关里配了个deepseek-v4-flash-0.1结果API直接报the supported api model names are deepseek-v4-pro, deepseek-v4-flash, and de...提示里能看到的合法名字就这么几个。这不是模型文件问题是服务端路由没匹配上。用vLLM启动时通过--served-model-name deepseek-v4-flash显式指定对外暴露的名字能一次性解决大部分映射问题。量化档位方面FP8是首选INT8次之。INT4要小心MoE的某些敏感层对低位量化很敏感效果参差不齐。我在GB10上实测下来AWQ分块量化比GPTQ低比特更稳校准集用500条领域数据就够了。3.2 vLLM启动配置与参数解读我的生产启动命令长这样vllm serve /data/models/DeepSeek-V4-Flash-AWQ \ --served-model-name deepseek-v4-flash \ --tensor-parallel-size 1 \ --pipeline-parallel-size 2 \ --max-model-len 131072 \ --kv-cache-dtype fp8 \ --max-num-seqs 48 \ --gpu-memory-utilization 0.92 \ --enable-prefix-caching \ --host 0.0.0.0 --port 8000有人会问都双节点了为什么启动参数里--tensor-parallel-size反而是1--pipeline-parallel-size才是2这个答案贯穿整篇文章双机走10Gbps网络时张量并行每层都要AllReduce同步通信量太大带宽根本扛不住性能反而不如单机流水线并行只在stage边界传激活值通信量小一个量级更适合当前组网。后面第4章我会放实测数据说明这个选择。--kv-cache-dtype fp8把KV cache压成FP8省下来的统一内存可以塞更多batch--enable-prefix-caching对RAG场景尤其有用同样的文档前缀不用重复计算首token时延能降低40%左右。3.3 两个高频报错的完整排查链路第一个错误是上游400。报错原文大概是cc switch local proxy failed while handling codex endpoint /responses. 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-V4-Flash处于thinking mode时API要求把之前返回的reasoning_content原样回传本地网关在转发时把它丢了就触发400。排查链路我建议这样走先用curl直接打vLLM的/v1/chat/completions确认服务端本身是否正常。再通过网关转发同一请求对比请求体看reasoning_content字段是否还在。确认是网关丢弃之后要么换成支持非OpenAI标准字段的代理要么在服务端关闭thinking mode走普通生成接口。这类问题跟模型本身没关系纯粹是生态工具链没跟上。我见过有人排查了两天模型参数最后发现是自己写的一层middleware把未知字段全滤掉了。第二个错误是流式输出里的结构标签。Trae这类IDE配置本地部署的DeepSeek-V4-Flash之后输出内容里出现/|dsml|parameter和/|dsml|这种标签看起来很吓人。本质是模型侧返回了用于解析的结构化分隔符但下游IDE的协议层没有剥离干净。我的处理方式是在网关加一层后处理用正则把|dsml|....../|dsml|之间的内容剥掉只保留文本主体。如果不想碰正则也可以把vLLM的服务模板里对应参数调成对客户端兼容的停止词实测也能解决大部分问题。4. 张量并行带来的带宽反噬为什么双机性能反而倒退4.1 同一套模型三种并行方式的实测对比为了搞清楚双节点的真实性能我用相同的prompt集做了一组对照测试记录prefill吞吐、decode吞吐、首token时延三个指标部署方式prefill吞吐decode吞吐首token时延备注单机TP1 PP12600 tokens/s41 tokens/s0.85s基线性能稳定双机TP2 PP11800 tokens/s22 tokens/s1.9s网络打满decode接近腰斩双机TP1 PP22200 tokens/s52 tokens/s1.1sprefill略降decode提升明显单机decode是41 tokens/s双机张量并行反而掉到22 tokens/s这不是个例是网络带宽导致的必然结果。我用10Gbps组网都这样如果是2.5GTP2的实测数据会更惨——基本就卡死在一个batch上后面所有请求都在排队等网络。4.2 为什么TP2会被网络拖垮一个粗糙的计算张量并行的AllReduce通信量能粗略算出来。假设hidden size是5120序列长度4096batch是16每层Transformer做一次AllReduce需要传输的数据量大约是序列长度乘hidden乘batch乘每个元素字节数再乘上收和发两个方向。粗算下来一次迭代要同步2.7GB左右的数据而2.5Gbps链路理论每秒只有312MB。这意味着即便网络零损耗一秒钟也只能完成零点几次层间迭代decode吞吐自然断崖式下跌。对比之下流水线并行每步只传输micro-batch边界的激活值单次通信量小得多。虽然它也有气泡等待问题但在节点间只有10Gbps带宽的前提下通信量的优先级高于一切。这也是为什么我最终选定TP1 PP2的原因。4.3 确认瓶颈在网络而不是算力的排查步骤很多人遇到性能倒退第一反应是调模型参数其实先确认瓶颈在哪更高效。我的排查套路是iperf3确认链路能跑满如果iperf3本身只有500Mbps那先修网络别碰模型。推理压测同时用iftop或nload观察两个节点之间的实时流量。如果decode阶段流量持续接近网卡上限说明瓶颈基本锁定在通信。跑netstat -s | grep -i retrans看重传率。NCCL对丢包很敏感重传一多实际带宽会掉到可用带宽的三成以下。确认是NCCL流量后检查NCCL_SOCKET_IFNAME和NCCL_PROTO两个环境变量确保选中的是实际高速网卡而不是板载管理口。GB10内部的内存带宽是273GB/s节点之间哪怕10Gbps也只有1.25GB/s差了超过200倍。所以分布式推理的核心原则就是能少跨节点就绝不多跨一次。5. 优化路线流水线并行、批量合并与量化的实测收益5.1 TP改成PP之后通信量降了一个量级在双节点上把张量并行改成流水线并行是我做的第一个优化收益立竿见影。TP是把每一层拆到两台机器每层都要做一次高频AllReducePP是把网络切分成两段主节点管前半部分从节点管后半部分中间只需要在stage边界传一次激活值。对于DeepSeek-V4-Flash这种层数较深的MoE模型PP2的通信压力小得多。但PP也不是没有代价。它的流水线气泡会导致GPU利用率下降需要配合micro-batch切分来对冲。我把batch切成4个micro-batch让两段管线尽量重叠执行实测decode吞吐从22 tokens/s回到了52 tokens/s首token时延也稳定在1.1秒左右。整体比单机提升了约27%虽然没到翻倍但对于双节点组网来说已经是可以接受的结果。5.2 请求合并比无脑堆并发更划算DeepSeek-V4-Flash是MoE架构激活参数少单位显存能容纳的batch数比稠密模型大得多。GB10的192GB统一内存在这里成了优势——KV cache和激活值都能放得下更大的batch。我把--max-num-seqs从16调到48配合vLLM的连续批处理decode吞吐从41提到52踩在流水线并行之上又叠加了一层收益。不过这里有个度的问题。并发数太高单个请求的首token时延会显著恶化客户端那边如果设了5秒超时反而会触发大量重试把服务打崩。我试过直接拉到96首token时延涨到3秒以上整个服务明显开始抖动最后稳定在48比较合适。5.3 量化在统一内存平台上的额外收益量化通常被看作是省显存的手段但在GB10这类统一内存平台上它还意味着省带宽。模型权重和KV cache从FP16压到INT8每次访存搬运的数据量直接减半decode生成时等待内存的时间也就少了。我在同样条件下实测INT8相对FP16的decode吞吐提升约20%从34涨到41 tokens/s。再往下降到INT4还能再快10%左右但需要跑校准集而且MoE的expert层对低比特特别敏感容易掉点严重。我的建议是FP8/INT8作为生产首选INT4只做流式长上下文场景的备用方案。6. 双节点周边的工具链协同微调、客户端接入与流式输出异常6.1 在GB10上微调DeepSeek-V4-FlashMindSpeed还是自建LoRA如果你搜索mindspeed-llm deepseek-v4-flash finetune会发现MindSpeed LLM这个名字频繁出现。它确实是面向大模型训练/微调的加速工具但它的算子优化和平台绑定主要面向NPU生态直接拿到GB10的CUDA路径上跑兼容成本高得吓人。我在双节点上试过一次光是算子适配就折腾了一周最后果断放弃。GB10上更现实的微调路线是LoRA/QLoRA。统一内存带宽有限全参数微调的反向传播要反复搬运激活值训练吞吐会非常难看LoRA把梯度更新压缩到小型适配器里训练速度快很多。我用8k上下文、1000条领域数据做了实测单节点上QLoRA微调一轮约65分钟双节点切PP2 数据并行后压到30分钟左右这个速度对于轻量定制完全够用。微调产出的adapter文件在vLLM里通过--enable-lora加载配合--lora-modules做热加载不用重新部署主模型。6.2 扣子这类客户端接入本地算力的配置要点扣子客户端要接入本地算力其实就是一个指向自己的OpenAI兼容端点的操作。配置时把对话服务的base_url填成http://主节点IP:8000/v1模型名填deepseek-v4-flash然后注意三件事本地服务必须支持工具调用和流式输出否则插件类Agent会话会莫名其妙断掉。如果客户端在浏览器里直连需要在vLLM前套一层带CORS头的网关否则浏览器跨域请求会被拦。不要在客户端同时挂两个不同量化版本模型名冲突会导致路由错乱报错文案还不直观。6.3 流式输出里出现结构化标签的处理方法开头提到的/|dsml|parameter问题在接入Trae、Codex这类IDE时尤其常见。它的根因是模型侧在流式响应里吐出了用于解析的结构化标记而IDE侧没有做对应处理。处理方案有三种按优先级排在网关做后处理用正则剥离|dsml|...相关内容再从/v1/chat/completions的流式输出里重组文本。修改vLLM启动参数里的停止词/绑定token让模型输出直接规避这类标签。关闭thinking mode改用普通生成模式流式输出通常会更干净。如果你只是本地自用方案三最省事如果要给团队提供服务方案一更通用。我的生产环境最终是网关层兜底配合方案二双管齐下之后这类问题基本绝迹。在双GB10节点上折腾了两周最后留下的结论其实很简单算力和带宽从来不是同一件事。TOPS、参数规模解决的是能不能算的问题通信和调度解决的是能不能快的问题。以这个配置而言我最终的生产方案是10Gbps组网 PP2 连续批处理 INT8量化整体decode吞吐能做到单机的1.3倍prefill有波动但换来的是高可用和实验隔离。最后分享一个经验部署前先花半小时把链路速率、MTU、丢包、PCIe协商带宽全部测一遍比后面调任何模型参数都值得。网络链路如果本身就有问题你在模型层面做的所有优化都会打折扣。