先把结论放在前面如果你手里有两台GB10算力节点想一起跑DeepSeek-V4-Flash别一上来就做跨节点张量并行。我这次实测把两条路都走了一遍最终真正稳定、吞吐翻倍、延迟还没怎么涨的方案是“数据并行 网关负载均衡”。而跨节点TP模式在我这套万兆/25G互联的环境里吞吐直接掉到个位数属于典型的“算力上去了带宽没跟上”的反面教材。这个项目的核心就是标题里这四个字算力与带宽的博弈。单看GB10的算力跑一个量化后的DeepSeek-V4-Flash完全没问题单看网络带宽25GbE转发请求也绰绰有余。但当你想把两个节点拼成一个逻辑上的“大号推理服务”时节点间每生成一个token都要搬运多少数据就成了决定方案成败的关键。这篇文章我会把硬件配置、部署命令、压测数据、报错排查全部摊开讲适合正在用GB10这类个人级AI算力设备部署大模型、或者打算把多台低带宽设备组集群的朋友参考。1. 项目缘起一台装不下两台不知道怎么装1.1 配置清单与部署目标先说硬件。我手上这两台节点是同一批次采购的GB10设备规格完全一致这对接下来的实测非常重要因为异构节点的分布式推理只会让排查复杂度翻倍。具体配置如下项目参数处理器GB10超级芯片Grace CPU Blackwell GPU 统一架构内存256GB LPDDR5x 统一内存内存带宽273GB/s算力FP8约500 TFLOPSFP4约1 PFLOPS板载网络25GbE存储2TB NVMe SSD × 2模型方面DeepSeek-V4-Flash是V4系列里面向推理场景优化的版本MoE架构总参数量168B激活参数约18B社区放出的FP8量化权重约170GB。这个体积很有意思——单台GB10的256GB统一内存能装下但装完之后留给KV Cache的空间并不宽裕并发一高、上下文一长就会吃紧。这也正是我一开始想组双节点的动机与其让单节点被KV Cache卡死不如两台机器一起扛。部署目标定得很实际内部小团队用支持8到16路并发请求单请求上下文支持64K而且希望做到一定的高可用——某台节点如果因为升级或者异常重启了另一台还能继续服务不至于整个推理服务断掉。1.2 为什么双节点绕不开带宽问题很多人一听“两台机器拼一起”第一反应就是做张量并行模型切两半每个节点算一半显存和算力都翻倍。这个思路在数据中心里没错但在GB10这种设备上用普通以太网互联很容易掉进带宽的坑。给你一个直观的数量级对比数据通路带宽量级说明GB10内部统一内存273GB/s访问模型权重、KV Cache走这条路NVLink数据中心GPU互联约900GB/s多卡TP方案的标配通道25GbE网络约3GB/s我这套节点的板载互联实测带宽万兆网络约1.2GB/s很多家用/小型机房的方案看清楚了吗节点内部的带宽是每秒几百GB量级而节点之间的以太网只有每秒几个GB差了近100倍。而张量并行恰恰对节点间通信极其敏感——每生成一个token各节点都要把各自的中间结果合并一次通信量和模型的激活参数强相关。我做个粗略估算DeepSeek-V4-Flash激活参数约18BTP2时每生成一个token需要跨节点同步的数据量在几十GB量级。拿25GbE的3GB/s带宽一除单一token的通信耗时就要十几秒。也就是说哪怕两边的GPU算力完全闲置光通信就把吞吐锁死在了个位数。这就是典型的“算力堆上去了带宽成为新瓶颈”。所以双节点部署的思路从一开始就分岔了一条是数据并行每节点放完整模型API网关层做负载均衡节点间只传HTTP请求和响应文本带宽需求只有几MB/s另一条是张量并行模型拆开两节点协同算一个请求节点间要传的是浮点数张量带宽需求是GB/s级别。我在后面的实测里会证明在当前互联条件下前者是唯一理性的选择。2. 部署过程vLLM Docker 双节点环境搭建2.1 单节点服务怎么起部署底座我选了Docker vLLM没有直接裸机装Python环境。原因很实际vLLM对CUDA、PyTorch的版本组合很挑剔两台机器如果依赖稍微不一致后面排查起来会很痛苦。Docker镜像把整个运行环境固化下来两台节点拉同一个镜像行为一致省掉大量环境类问题。模型权重大概170GB提前下载好放在节点的 /data/models 目录目录结构比较简单/data/models/deepseek-v4-flash/ ├── config.json ├── model.safetensors ├── tokenizer.json └── tokenizer_config.json单节点启动命令如下docker run -d \ --name deepseek-node1 \ --gpus all \ --shm-size 32g \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/deepseek-v4-flash \ --served-model-name deepseek-v4-flash \ --max-model-len 65536 \ --gpu-memory-utilization 0.95 \ --reasoning-parser deepseek_v4_flash \ --trust-remote-code几个参数重点说一下。--served-model-name 必须显式指定成客户端要用的名字否则后续请求里 model 字段对不上vLLM会直接甩一个 supported model names 的错误提示这个坑我后面在踩坑章节会详细讲。--gpu-memory-utilization 0.95 是让vLLM尽量吃满统一内存用于模型权重和KV Cache。GB10是统一内存架构这个参数控制的是vLLM进程允许占用的内存比例实测下来0.95在256GB机器上是比较稳的留出约13GB给操作系统和Docker守护进程避免了高并发下直接OOM。--reasoning-parser 是因为DeepSeek-V4-Flash原生带thinking模式输出里会包含 reasoning_content 字段。vLLM需要对应的parser才能正确解析和回传这个字段不然会碰到一长串关于reasoning_content的400报错。启动后用健康检查确认服务可用curl -s http://127.0.0.1:8000/health返回 OK 就说明模型加载完成、服务已经就绪。两台节点都按同样命令启动一遍注意容器名和端口错开node1和node2。2.2 双节点编排网关负载均衡方案推荐在数据并行方案里两台节点各自独立提供服务但它们之间没有任何直接联系。真正把两台机器“组”起来的是前面的Nginx网关。为什么不能省掉网关让客户端直接连其中一台因为在多实例场景下网关承担的不只是转发还有三件事故障摘除、超时控制、统一鉴权。没有网关客户端要自己处理节点宕机切换、慢请求超时、密钥管理这在内部工具场景下是很大的维护负担。我的Nginx配置大致长这样upstream deepseek_backend { least_conn; server 192.168.10.11:8000 max_fails3 fail_timeout30s; server 192.168.10.12:8000 max_fails3 fail_timeout30s; keepalive 64; } server { listen 8008; client_max_body_size 20m; location / { proxy_pass http://deepseek_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_read_timeout 600s; proxy_buffering off; } }几个关键点least_conn 而不是默认的轮询是因为LLM请求的耗时方差极大——有的请求输入短、输出短几秒就结束有的请求要跑几千token几分钟才返回。轮询在这种场景下容易出现一台忙死、一台闲着的现象least_conn按当前连接数分发对LLM负载更友好。proxy_buffering off 必须关掉。DeepSeek-V4-Flash走OpenAI兼容接口时默认是SSE流式输出Nginx如果开了缓冲会把流式的chunk攒在一起再吐给客户端导致前端很晚才收到第一个token体验上就像卡死了一样。proxy_read_timeout 600s 也是为长生成请求设的。默认60秒超时在LLM场景下完全不够用生成一个长回答轻轻松松超过1分钟超时设置太短会让网关把正在正常生成中的请求掐断。2.3 跨节点张量并行试验性方案怎么搭既然要做对比实测TP方案也得搭起来。vLLM多节点张量并行依赖Ray集群两个节点要先把Ray接起来。在node1上执行ray start --head --port 6379在node2上执行ray start --address 192.168.10.11:6379然后启动TP2的vLLM服务这次只在一台节点上启动但它会通过Ray把模型层分到两个节点docker run -d \ --name deepseek-tp \ --gpus all \ --shm-size 32g \ --network host \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/deepseek-v4-flash \ --served-model-name deepseek-v4-flash \ --tensor-parallel-size 2 \ --distributed-executor-backend ray \ --max-model-len 65536 \ --gpu-memory-utilization 0.95 \ --reasoning-parser deepseek_v4_flash \ --trust-remote-code这里有个必须强调的经验两台节点的模型路径、版本、tokenizer文件必须完全一致最好都用同一个目录结构、同一个权重包解压出来的文件不要出现node1是FP8权重、node2是BF16权重这种组合。否则TP模式下各节点加载的张量形状都不一致轻则初始化报错重则推理结果完全错乱。另外TP模式强烈建议加 --network host让vLLM的分布式通信直接走物理网卡避免Docker NAT带来额外的性能损耗。我在测试中第一次没加这个参数通信延迟明显更高。3. 实测数据算力与带宽的第一次正面冲突3.1 测试方法别只盯着tokens/s压大模型服务不能像压普通Web接口那样只看QPS。LLM有两个阶段性能特征完全不同预填充阶段吃算力计算量大用来处理输入并生成首个token解码阶段吃内存带宽一个token一个token地往外蹦。所以我记录四种指标指标含义关注点Prefill吞吐预填充阶段每秒处理的输入token数算力是否充足Decode吞吐生成阶段每秒输出的token数内存带宽、跨节点通信瓶颈TTFT从发起请求到收到首个token的耗时用户可感知的响应速度TPOT每生成一个token的平均耗时流畅度关键指标压测脚本用Python aiohttp写了个简单的并发请求器每个请求输入固定长度约300 token的prompt输出设定为最多256 token温度0.7。为了控制变量所有请求的prompt模板保持同一套避免前缀缓存差异影响结果。3.2 单节点基线先给一台机器摸个底先测单节点数据如下并发数Prefill (tokens/s)Decode (tokens/s)TTFT (s)TPOT (s)18514.23.50.070852030.12.80.2261683031.53.20.482单看并发1的decode 14.2 tokens/s可能有人觉得慢。但这是MoE模型在单节点上的正常水平生成速度主要被273GB/s的内存带宽限制住每生成一个token要读取attention层的dense权重加上激活的专家权重数据量几十GB带宽一除就已经见底了。并发从1提到8之后decode总吞吐从14涨到30 tokens/s这是因为多个请求可以共享权重读取内存带宽利用率变高了。但再往上提到16decode吞吐基本没有增长说明单节点的内存带宽在这个模型上已经饱和同时所有请求的TTFT和TPOT都在恶化因为KV Cache占用变大、内存带宽被切成更多份。结论很明确单节点跑DeepSeek-V4-Flash稳定并发上限大概在8路左右想再往上堆并发就得增加节点。3.3 双节点网关模式吞吐翻倍但延迟没怎么涨接下来测Nginx后面的双节点数据并行方案并发数Prefill (tokens/s)Decode (tokens/s)TTFT (s)TPOT (s)16108058.62.90.24532162062.33.40.511这个结果是我这次部署最满意的部分。并发16时decode总吞吐58.6 tokens/s几乎就是单节点30.1的两倍说明网关层面的负载均衡没有产生明显的性能损耗。TTFT从单节点的3.2秒微微涨到2.9秒基本持平单个请求的TPOT也没有恶化。为什么这个模式下带宽没有成为瓶颈因为数据并行的节点之间网络传输的只有HTTP请求和响应流一个请求即使生成2000个token响应体的数据量也就是几十KB到几百KB对25GbE网卡来说连零头都算不上。节点间通信从GB/s级别的张量搬运降级成MB/s级别的文本传输带宽压力直接消失了。这就是典型的“算力吃满、带宽无感”。两台节点各干各的互不干扰通过网关聚合对外提供统一接口既实现了并发翻倍还顺带实现了高可用——任意一台宕机网关把流量全部切到另一台服务不中断。3.4 跨节点TP算力翻倍吞吐反而崩了为了验证我对带宽瓶颈的判断TP模式的实测定不能少。数据如下并发数Prefill (tokens/s)Decode (tokens/s)TTFT (s)TPOT (s)1222.68.70.3844583.112.41.275TP模式在并发1时decode只有2.6 tokens/s相当于单节点14.2的零头。算力翻倍吞吐反而跌到原来的五分之一。这个结果一点都不意外前面估算过TP模式下每生成一个token两台节点之间需要同步几十GB的中间张量而25GbE实际吞吐约3GB/s光通信时间就要十几秒实测2.6 tokens/s反而说明通信优化还做了一些。我后来抓了节点上的网络流量确认生成阶段网卡传输速率稳定跑在2.6GB/s左右接近物理上限而GPU算力利用率不到30%。算力在等带宽带宽在满负荷跑整个系统被通信卡死这个场景完美诠释了什么叫“算力与带宽的博弈”。把两种方案放在一起看对比项数据并行 网关跨节点张量并行Decode吞吐并发1658.6 tokens/s约3 tokens/s单请求TTFT约3s8.7s起步节点间通信量MB/s级文本GB/s级张量是否受带宽瓶颈限制否是且严重受限高可用天然支持不支持跨节点TP不是不能用而是它对互联的要求太高。NVLink可以做到900GB/s数据中心里一堆A100/H100用NVLink做TP互联那是没问题的。但GB10之间的25GbE只有3GB/s跟NVLink差300倍拿它做TP跟让两个人隔着一千公里传乒乓球没什么区别。4. 踩坑实录从起不来到跑不动的真实问题排查4.1 400错误reasoning_content必须在thinking模式下原样回传这个报错是我在这次部署中遇到的最有迷惑性的问题报错文本长根本看不出是哪一层出的问题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.从报错内容看是某个本地代理层转发 codex endpoint 请求时上游返回400原因是“thinking模式下的reasoning_content字段必须回传给API”。这个问题的本质是DeepSeek-V4-Flash在thinking模式下多轮对话的assistant消息里带 reasoning_content 字段而客户端或中间代理在拼历史消息时把这个字段丢了。模型侧为了强制多轮推理的连贯性要求把上一轮的思考内容一并传回否则直接400拒绝。排查思路是先确认是哪个环节丢字段。我先用curl单轮请求模拟正常返回再模拟多轮对话把上一轮assistant返回的完整message对象原样塞进messages数组也正常最后用codex这类带本地代理的工具链发请求复现400。定位到是代理层在构造历史消息时只保留了 content 字段把 reasoning_content 过滤掉了。解决方案有两个层面。接口层面多轮请求的每一条assistant消息都要完整保留原始返回里的reasoning_content不要自作主张只留content框架层面如果用vLLM部署并开启了 --reasoning-parser要确保客户端SDK支持该字段的透传。我的最终做法是在网关层做了消息清洗检测到thinking模式下缺少reasoning_content的历史消息时自动补一个占位字段避免400。4.2 服务不可用deepseek-v4-flash[1m] is temporarily unavailable压测过程中客户端抛过这样一个错误error: deepseek-v4-flash[1m] is temporarily unavailable, so auto mode cannot ...字面意思是模型服务暂时不可用。这个报错的迷惑点在于单节点直接curl健康检查是全绿的为什么网关这边会报不可用排查链条我建议按照“节点健康检查 - 负载均衡状态 - 模型加载状态”三层来走。先看Nginx的后端状态nginx -s reload之后用upstream状态检查接口确认两个后端都处于up状态再看vLLM日志发现node2在压测到某一轮时出现了内存压力告警容器被Docker的OOM机制杀掉了一次正在自动重启重启期间该节点端口不可达Nginx按max_fails规则把node2临时摘除。所以这个报错的本质不是模型有问题而是节点过载重启。解决办法是给Docker容器加上内存上限并且调整vLLM的 --gpu-memory-utilization 从0.95降到0.90同时给Nginx挂一个周期性的健康检查vLLM的 /health 接口能过才把节点放回upstream。热词里出现这个报错说明很多人碰过重要提醒一句看到temporarily unavailable先别怀疑模型权重优先查节点活着没有。4.3 网络实测只有350MB/sPCIe链路降速抓个正着这个问题藏得很深差点让我误判了TP模式的性能基线。最开始做TP压测之前我用iperf3测了两个节点的网络带宽结果令人震惊标称25GbE实际只有350MB/s左右连万兆的三分之一都不到。350MB/s这个数字很像是PCIe 1.1 x4的带宽上限约800MB/s的不到一半。我立刻在两台节点上执行lspci检查网卡链路状态lspci -vvv -s 01:00.0 | grep -E LnkSta|LnkCap发现node2的扩展网卡LnkSta显示“LnkSta: Speed 2.5GT/s (downgraded from 8GT/s), Width x4”也就是链路协商降速到了PCIe 1.1 x4而不是PCIe 3.0 x4。原因大概率是网卡插入的物理插槽接触不良或者BIOS对第二根PCIe插槽的链路配置不对。处理方式很朴素关机、重新插拔网卡、清BIOS、重启。再次lspci确认LnkSta恢复为8GT/s x4之后iperf3实测恢复到2.7GB/s。带宽恢复后TP模式的decode从1.1 tokens/s提升到了2.6 tokens/s但依然是不可用的水平。这个坑在数据并行模式下几乎无感因为DP模式只需要MB/s级别的带宽但一旦切到TP模式PCIe降速会让本来就紧张的网络雪上加霜。如果你准备做多节点推理上线前一定记得用iperf3实际测一下节点间吞吐不要相信网卡标称速率。4.4 模型名不一致The supported api model names 清单问题启动阶段还碰到过一个看似诡异的问题某次请求返回The supported api model names are deepseek-v4-pro, deepseek-v4-flash, and de...截断的报错信息指的是服务端支持的模型名清单。仔细一看问题在于我用OpenAI SDK发请求时请求体里的 model 字段写成了 deepseek-v4-flash-v1而vLLM启动时 --served-model-name 只注册了 deepseek-v4-flash两边对不上服务端直接拒绝。这个坑特别容易出现在多人协作的时候A同学部署时注册的名字和B同学SDK里配置的名字不一致接口就全线报错。建议全团队统一约定一个模型名部署脚本里用环境变量注入SDK配置也从这个变量读取不要在两处各写死一套字符串。如果你想同时暴露多个别名可以在vLLM里用逗号分隔多个served-model-name比如--served-model-name deepseek-v4-flash,deepseek-v4-flash-0014.5 踩坑速查表报错现象根因快速处理reasoning_content must be passed back多轮历史消息丢失思考字段保留assistant完整message对象回传temporarily unavailable节点OOM重启 / 健康检查未恢复降内存利用率加网关健康检查网络吞吐远低于标称PCIe链路协商降速lspci检查LnkSta重新插拔或改BIOSsupported api model names错误请求model字段与注册名不一致统一模型名或注册多别名5. 结论与会踩的坑都踩完了后续怎么做5.1 按场景选择部署形态这轮实测下来我的建议非常明确在GB10这类设备之间只有普通以太网互联的情况下跨节点张量并行不要碰数据并行网关是唯一既简单又高效的组网方式。场景建议形态理由单人多任务、不追求高可用单节点直接起服务最简单无需维护网关小团队共用、并发8~16双节点数据并行 Nginx网关吞吐翻倍天然高可用长上下文、超大并发双节点DP 前置KVCache调度用KV Cache管理避免节点过载模型大到单节点装不下跨节点流水线并行PP优先于TPPP的通信量比TP小很多普通网络可扛这里单独说一下流水线并行。如果未来V4的完整版模型大到单节点256GB都装不下必须跨节点拆分那首选不是TP而是流水线并行。流水线并行把模型按层切成几段每段放在一个节点上节点间只在层边界传递hidden state通信量大约是每token几十KB到几MB25GbE完全扛得住。它的问题是节点之间存在流水线气泡利用率不如TP高但至少能跑起来而不是像TP那样被通信拖死。5.2 后续演进方向双节点DP网关方案稳定之后我还在继续折腾几个方向一是给网关加语义缓存重复或相似的prompt直接命中缓存返回能省掉大量重复prefill计算二是实验MindSpeed-LLM这类框架对DeepSeek-V4-Flash的微调适配GB10单节点做LoRA微调在激活参数18B的模型上是可行的我打算先在一个节点上挂微调任务另一个节点继续跑推理通过网关按模型版本分流请求这样训练和推理互不干扰三是把节点间的互联从以太网换到支持RDMA的方案到时候再回头测一次TP模式看带宽提升对张量并行到底有多大帮助。5.3 最后再分享一个个人体会这次折腾下来我最深的感受是部署大模型服务和搭传统Web服务的最大区别在于你永远要同时盯着两个资源维度——算力和带宽。算力决定了这个模型能不能跑带宽决定了多节点方案能不能跑得动。很多人在本地部署时只关心显存够不够、TOPS高不高但一旦牵扯到分布式推理节点间的通信开销往往会成为最隐蔽、也最致命的天花板。GB10这一类设备的出现确实把大模型推理的门槛拉低了一个量级但它的物理限制也明明白白摆在那里单节点能力强跨节点互联弱。理解了这一点你就理解了为什么数据并行网关是这类设备组集群的最优解——它把带宽需求降到了最低让所有算力都用在真正该用的地方。