8卡H20跑DeepSeek-V3-0324光听这个组合就很有反差感。一边是显存管够但算力被收过的NVIDIA H20一边是671B总参数、37B激活参数的MoE大模型单从账面上看很多人第一反应是这卡跑V3会特别吃力。实际上我们连续测了两周结论是能跑而且跑得稳但前提是得把显存、并发、KV cache和量化方式这些坑一个个填平。这篇文章我不打算复述官方文档而是把从裸环境到稳定上线的全过程拆开讲讲H20这套卡在V3-0324上到底能交出什么样的性能数据瓶颈在哪哪些参数是真有效哪些是白折腾。1. 先看清这盘棋H20的性能底牌与V3-0324的适配逻辑开始部署之前必须先把硬件和模型的“脾性”摸清楚。H20是一张很特殊的卡特殊到你不能用常规大模型推理卡的眼光去衡量它。同时DeepSeek-V3-0324也不是传统意义上的稠密大模型它俩凑到一起本质上是一场显存带宽与稀疏激活的匹配游戏。1.1 H20是什么水平96GB显存和“缩水”的算力H20的标称规格大家应该都看过96GB HBM3显存显存带宽4.0TB/sNVLink带宽900GB/s整卡功耗400W左右。这套参数放在推理场景里其实非常好看显存比A100的80GB还大带宽也够宽多卡之间通信不至于拖后腿。但真正决定它口碑的短板也在明面上BF16/FP16算力大约148 TFLOPSFP8大约296 TFLOPS这个数字和H100相比差不多只有六分之一到七分之一。更直白地说H20是一张典型的“带宽型”显卡适合大模型推理时那种每步都要把大量权重读出来的场景但不适合疯狂做矩阵乘法的高算力场景。这种偏科直接影响了部署策略。跑DeepSeek-V3-0324这种671B参数的MoE模型每生成一个token理论上只有37B左右的激活参数参与计算剩下的专家权重大部分时间是“躺”在显存里等调度。H20的高带宽、大显存恰好能把这种稀疏激活的优势发挥出来而它算力偏弱的缺点会在预填充阶段被最大程度放大。所以部署前就要有心理准备这个组合的TTFT首token延迟不会太漂亮真正的亮点应该在后端的吐字速度和整体吞吐上。1.2 V3-0324为什么能吃下这套硬件DeepSeek-V3-0324是DeepSeek在2025年3月发布的一个版本整体架构还是V3的MoE路线总参数量671B激活参数约37B内部有256个路由专家每次推理只激活其中8个另外还有一个共享专家负责兜底。官方在发布说明里强调它在代码生成、数学推理和工具调用上有增强并且权重许可放得更开商用友好度比早期版本高不少。这类架构对部署方最大的诱惑是虽然“全量”看起来大得吓人但实际推理过程中真正参与计算的参数只有5%左右。这意味着在FP8量化下671B权重大约只占671GB显存8张H20刚好是768GB容量上卡得非常准。如果换成过去那种纯稠密模型8卡H20别说跑671B就是跑一个300B稠密模型都费劲。所以选这个组合不是拍脑袋而是算过账之后的最优解用尽量少的卡把大模型塞进去再用MoE的稀疏特性对冲H20的算力不足。2. 部署前的显存规划768GB怎么塞进671B权重很多人在这一步就翻车了。8卡H20总显存768GB听起来很大但DeepSeek-V3-0324的原始BF16权重可是要1342GB直接塞肯定爆。所以第一个要解决的问题不是“怎么跑”而是“跑什么精度”。2.1 模型量化选型FP8几乎是唯一选择实测下来FP8是平衡精度和显存的最佳方案。V3本身原生支持FP8训练和推理DeepSeek在训练时就用到了FP8所以权重转成FP8后精度损失非常小几乎可以忽略。我们用FP8权重跑了好几组评测数学和代码任务的得分和BF16基本在误差范围内。为什么不用INT4或者INT8INT4确实能把权重压到335GB左右每张卡能省出一大截空间给KV cache但DeepSeek这类大模型对量化误差很敏感INT4在某些长文本生成场景里会出现明显的退化尤其是代码补全这种需要精确命中的任务我测下来稳定性不如FP8。INT8则有点尴尬压缩比不够极致权重大小和FP8差不多精度也没比FP8强多少属于两头不讨好。所以最后定下来的方案就是FP8。权重从HuggingFace或者官方镜像拉下来之后需要确认文件后缀带fp8字样如果没有就要自己在部署前用脚本做一遍量化。整个模型在FP8精度下大概是671GB8卡一共768GB按90%到95%的显存利用率算大概剩下30GB到60GB给KV cache和运行时buffer。这个余量说不上宽裕但配合V3的MLA多头潜在注意力机制KV cache占用被压得很小还是能撑起一定并发的。2.2 软件环境与vLLM服务启动命令软件栈方面我们用的是Ubuntu 22.04NVIDIA驱动550.54.15CUDA 12.4PyTorch 2.5.1。推理框架直接选了vLLM版本0.8.6。说实话vLLM对H20的支持在早期版本确实有一堆兼容性问题但从0.8.x开始已经比较稳了尤其是FlashAttention和FP8相关的算子基本不会再无脑回退到慢速实现。启动命令是踩过几次坑之后定下来的python -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-V3-0324-FP8 \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.93 \ --max-num-seqs 32 \ --trust-remote-code \ --enable-prefix-caching \ --port 8000这里有几个参数值得多说一句。--tensor-parallel-size 8表示把模型切成8份平均分到每张卡上这是最直接的并行方案。--max-model-len 32768是目前线上业务的上下文上限没有直接拉到模型支持的128K原因后面细说。--gpu-memory-utilization 0.93给系统留了7%的显存余量防止峰值时触发OOM。--enable-prefix-caching是必选项多用户共享相同前缀时可以白赚一大截吞吐。第一次启动时模型加载会持续一分钟左右期间每张卡显存会快速填满到接近90GB这是正常现象。实测从NVMe固态加载FP8权重大约65秒左右完成如果是机械硬盘或者网络盘时间会成倍增长建议无论如何都要用NVMe。3. 性能实测延迟、吞吐、并发下的真实表现跑通只是第一步真正要看的是数据。这一节我直接给出我们实测的核心数字测试工具主要是vLLM自带的服务接口加上自己写的Python压测脚本数据基于我们的业务prompt分布可能和你的场景有差异但趋势大概率是通用的。3.1 单路延迟表现TTFT和TPOT实测先看最简单的单用户场景。这里有两个关键指标TTFT首token延迟也就是从发出请求到收到第一个token的时间和TPOT每个token输出的间隔时间。测试项输入长度实测值TTFT256 tokens约1.1秒TTFT2048 tokens约2.6秒TTFT8192 tokens约9.8秒TPOT单并发-约45毫秒单流输出速度-约22 tokens/sTTFT这组数据验证了我开头的判断H20的算力短板在预填充阶段暴露得很明显。8卡H20虽然加起来有约2400 TFLOPS的FP8算力但实际预填充多卡利用率大概只有50%到60%遇到8K这种长输入将近10秒才能吐出第一个字线上体验肯定不行。但单流TPOT表现比想象中好。45毫秒一个token换算过来大概22 tokens/s对于671B这个量级的模型来说这个速度放在H100上也未必能翻倍。原因很简单decode阶段模型主要是从显存里反复读取权重H20的4TB/s带宽在这里能充分发挥而算力需求反而不高。也就是说这个组合在“输出密集、输入较短”的场景里非常能打但如果输入很长、每个请求都在预填充短板就会被无限放大。3.2 并发压测总吞吐与显存水位单流好看不算本事生产环境看的是并发。我们用aiohttp写了个简单的并发压测脚本固定输入512 tokens目标输出512 tokens分别压了8、16、32、64并发结果如下并发数总吞吐输出tokens/s平均TPOT显存峰值8约15052 ms每卡约92GB16约29055 ms每卡约93GB32约51062 ms每卡约94GB64约69093 ms每卡约95GB从数据能明显看到32并发以前总吞吐基本是线性增长的单用户延迟也没有太大恶化说明显存带宽还没有被打满。到了64并发总吞吐虽然还在涨但单用户TPOT已经飙到93毫秒差不多10 tokens/s体验明显下降。这个拐点说明当前配置下32并发是一个甜点位再往上堆并发只会让每个请求都变慢总吞吐的边际收益已经很小。显存水位方面每卡长期稳定在92GB到95GB之间和规划时的预期基本一致。FP8权重占了约84GB每卡剩下的空间一部分被KV cache吃掉一部分被vLLM的调度buffer占据。如果你跑任务时发现显存动不动就99%那就得把max_num_seqs往下调不然迟早OOM。4. H20DeepSeek的调优思路瓶颈识别与参数取舍性能数据出来了下一步是定位瓶颈、做针对性调优。很多朋友一上来就堆并发、调KV cache方向其实错了。你要先搞清楚这个系统到底卡在算力、显存还是通信上再动手。4.1 算力不够是硬伤但可以绕H20的算力短板最直观的体现就是预填充慢。这个瓶颈是硬件层面的靠软件参数很难完全绕开但能做到“扬长避短”。我们试过两个有效的办法。第一个是限制max_model_len。模型虽然支持128K上下文但实际业务里绝大多数请求用不到把上限压到32K之后vLLM预先分配的KV cache块更紧凑预填充计算量也随之下降实测TTFT有10%到15%的改善。第二个是开vLLM的chunked prefill。这个功能会把长输入的预填充切成小块和decode请求交错执行避免一个长输入独占所有卡导致其他请求全部排队。开了之后并发场景下的平均TTFT明显更平滑没有那种“一个长请求进来整机卡死几秒”的灾难现场。decode阶段反而是H20的主场。因为每生成一个token基本是带宽瓶颈8张卡的总带宽差不多32TB/s应付37B激活参数绰绰有余。只要不要同时塞太多请求单流速度能稳稳维持在20 tokens/s以上。4.2 KV cache、并发度与max_model_len的三角关系这三个变量是相互制约的。KV cache占用的显存约等于“KV cache大小 × 并发序列数 × 最大序列长度”所以任何一个指标增加都会挤占其他指标的空间。具体到V3-0324因为用了MLA机制KV cache相比传统MHA模型小了一个数量级以上这也是它能塞进H20的重要原因。但“小”不等于“没有”我们把max_model_len从128K降到32K之后单卡释放出了大约8GB显存这些空间全部回到了KV cache池子里实测支撑32并发明显比之前从容。并发度方面max_num_seqs这个参数直接决定了vLLM同时处理的序列数。它不是越大越好因为并发太高时显存带宽和CPU调度都会成为新瓶颈而且单用户延迟会显著恶化。我们的经验是先从16开始压测观察显存水位和平均TPOT逐步加上去找到吞吐曲线的拐点。4.3 几个真正有用的调优参数整理一下这一轮调优里真正见效的参数按优先级排序max-model-len能压多低压多低这是KV cache空间的最大变量。max-num-seqs控制并发数建议根据压测曲线来定不要盲目拉高。enable-prefix-caching多用户场景必开相同system prompt能省大量重复预填充。gpu-memory-utilization0.90-0.94之间比较安全太低浪费显存太高容易OOM。块大小相关参数如block-size默认16即可改动收益不大反而增加调度碎片。至于网上常提的NCCL_P2P_DISABLE1这类环境变量在我们的8卡环境下没有发现明显影响。H20的多卡通信已经有NVLink加持TP8时通信开销主要集中在allreduce上这部分带宽是够用的。如果你用的是PCIe互联的低端服务器才需要考虑这类优化。5. 常见问题与排查技巧两周踩坑实录这部分我整理一下过去两周遇到的最典型问题每个都是实际跑出来的教训不是文档里能查到的。5.1 问题速查表现象原因解决方案启动时NCCL报错卡间通信失败多卡P2P未打通或驱动版本过旧升级驱动到550用nvidia-smi topo -m检查拓扑一跑请求就OOM崩溃KV cache预留不足或max_model_len过大降低max-model-len和max-num-seqs检查gpu-memory-utilization输出速度只有2-3 tokens/s某个算子回退到慢速实现升级vLLM到0.8.6确认flash-attn版本匹配FP8推理结果乱码老版本vLLM对H20的FP8支持有bug换用新版本vLLM不要用0.6.x并发一高TTFT暴涨长输入请求占住所有卡做预填充开启chunked prefill限制单请求最大输入长度显存明明有冗余但开不了更多并发max_num_seqs参数没显式设置启动参数里加上--max-num-seqs并调大5.2 三个值得展开的坑第一个坑是模型版本混用。我们一开始从网盘下载的权重其实是V3原版不是0324虽然文件名差不多但生成效果和性能都有细微差别。查了半天才发现是权重不对白白浪费了大半天。所以部署前一定要核对权重的文件hash或者直接看目录里的config.json确认是DeepSeek-V3-0324再往下走。第二个坑是vLLM版本和依赖的兼容性。H20的FP8支持在vLLM 0.6.x时代非常不稳定经常出现乱码或者未知算子崩溃。升级到0.8.6之后问题大幅减少但需要注意对应的flash-attention和transformers版本也必须是新版本否则会报Unsupported op之类的错误。装依赖的时候别只盯vLLM一个包整个环境一起更新更省心。第三个坑是长上下文请求导致的“假死”。线上有一次某个调用传了接近100K的输入结果整台服务的响应速度瞬间崩了其他短请求也跟着超时。这就是预填充阶段独占资源的典型症状。后来我们把max-model-len压到32K同时开启chunked prefill和请求级超时情况才稳定下来。如果你也要在H20上跑DeepSeek-V3-0324最想提醒的就一句话这个组合的性能上限不是由“跑不跑得动”决定的而是由你能把显存预算和并发度掰得多细决定的。FP8权重几乎吃光整机显存你必须在KV cache、max_model_len和并发数这三者之间做仔细的取舍。两周跑下来我们最终用8卡H20稳定支撑了32并发、单流22 tokens/s、总吞吐500 tokens/s的线上服务这个成绩对671B模型来说已经算达标了。建议你部署时也按这个思路先压一遍自己的业务流量别拿单流数据去估算生产容量那样会偏差很远。
8卡H20跑DeepSeek-V3-0324光听这个组合就很有反差感。一边是显存管够但算力被收过的NVIDIA H20一边是671B总参数、37B激活参数的MoE大模型单从账面上看很多人第一反应是这卡跑V3会特别吃力。实际上我们连续测了两周结论是能跑而且跑得稳但前提是得把显存、并发、KV cache和量化方式这些坑一个个填平。这篇文章我不打算复述官方文档而是把从裸环境到稳定上线的全过程拆开讲讲H20这套卡在V3-0324上到底能交出什么样的性能数据瓶颈在哪哪些参数是真有效哪些是白折腾。1. 先看清这盘棋H20的性能底牌与V3-0324的适配逻辑开始部署之前必须先把硬件和模型的“脾性”摸清楚。H20是一张很特殊的卡特殊到你不能用常规大模型推理卡的眼光去衡量它。同时DeepSeek-V3-0324也不是传统意义上的稠密大模型它俩凑到一起本质上是一场显存带宽与稀疏激活的匹配游戏。1.1 H20是什么水平96GB显存和“缩水”的算力H20的标称规格大家应该都看过96GB HBM3显存显存带宽4.0TB/sNVLink带宽900GB/s整卡功耗400W左右。这套参数放在推理场景里其实非常好看显存比A100的80GB还大带宽也够宽多卡之间通信不至于拖后腿。但真正决定它口碑的短板也在明面上BF16/FP16算力大约148 TFLOPSFP8大约296 TFLOPS这个数字和H100相比差不多只有六分之一到七分之一。更直白地说H20是一张典型的“带宽型”显卡适合大模型推理时那种每步都要把大量权重读出来的场景但不适合疯狂做矩阵乘法的高算力场景。这种偏科直接影响了部署策略。跑DeepSeek-V3-0324这种671B参数的MoE模型每生成一个token理论上只有37B左右的激活参数参与计算剩下的专家权重大部分时间是“躺”在显存里等调度。H20的高带宽、大显存恰好能把这种稀疏激活的优势发挥出来而它算力偏弱的缺点会在预填充阶段被最大程度放大。所以部署前就要有心理准备这个组合的TTFT首token延迟不会太漂亮真正的亮点应该在后端的吐字速度和整体吞吐上。1.2 V3-0324为什么能吃下这套硬件DeepSeek-V3-0324是DeepSeek在2025年3月发布的一个版本整体架构还是V3的MoE路线总参数量671B激活参数约37B内部有256个路由专家每次推理只激活其中8个另外还有一个共享专家负责兜底。官方在发布说明里强调它在代码生成、数学推理和工具调用上有增强并且权重许可放得更开商用友好度比早期版本高不少。这类架构对部署方最大的诱惑是虽然“全量”看起来大得吓人但实际推理过程中真正参与计算的参数只有5%左右。这意味着在FP8量化下671B权重大约只占671GB显存8张H20刚好是768GB容量上卡得非常准。如果换成过去那种纯稠密模型8卡H20别说跑671B就是跑一个300B稠密模型都费劲。所以选这个组合不是拍脑袋而是算过账之后的最优解用尽量少的卡把大模型塞进去再用MoE的稀疏特性对冲H20的算力不足。2. 部署前的显存规划768GB怎么塞进671B权重很多人在这一步就翻车了。8卡H20总显存768GB听起来很大但DeepSeek-V3-0324的原始BF16权重可是要1342GB直接塞肯定爆。所以第一个要解决的问题不是“怎么跑”而是“跑什么精度”。2.1 模型量化选型FP8几乎是唯一选择实测下来FP8是平衡精度和显存的最佳方案。V3本身原生支持FP8训练和推理DeepSeek在训练时就用到了FP8所以权重转成FP8后精度损失非常小几乎可以忽略。我们用FP8权重跑了好几组评测数学和代码任务的得分和BF16基本在误差范围内。为什么不用INT4或者INT8INT4确实能把权重压到335GB左右每张卡能省出一大截空间给KV cache但DeepSeek这类大模型对量化误差很敏感INT4在某些长文本生成场景里会出现明显的退化尤其是代码补全这种需要精确命中的任务我测下来稳定性不如FP8。INT8则有点尴尬压缩比不够极致权重大小和FP8差不多精度也没比FP8强多少属于两头不讨好。所以最后定下来的方案就是FP8。权重从HuggingFace或者官方镜像拉下来之后需要确认文件后缀带fp8字样如果没有就要自己在部署前用脚本做一遍量化。整个模型在FP8精度下大概是671GB8卡一共768GB按90%到95%的显存利用率算大概剩下30GB到60GB给KV cache和运行时buffer。这个余量说不上宽裕但配合V3的MLA多头潜在注意力机制KV cache占用被压得很小还是能撑起一定并发的。2.2 软件环境与vLLM服务启动命令软件栈方面我们用的是Ubuntu 22.04NVIDIA驱动550.54.15CUDA 12.4PyTorch 2.5.1。推理框架直接选了vLLM版本0.8.6。说实话vLLM对H20的支持在早期版本确实有一堆兼容性问题但从0.8.x开始已经比较稳了尤其是FlashAttention和FP8相关的算子基本不会再无脑回退到慢速实现。启动命令是踩过几次坑之后定下来的python -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-V3-0324-FP8 \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.93 \ --max-num-seqs 32 \ --trust-remote-code \ --enable-prefix-caching \ --port 8000这里有几个参数值得多说一句。--tensor-parallel-size 8表示把模型切成8份平均分到每张卡上这是最直接的并行方案。--max-model-len 32768是目前线上业务的上下文上限没有直接拉到模型支持的128K原因后面细说。--gpu-memory-utilization 0.93给系统留了7%的显存余量防止峰值时触发OOM。--enable-prefix-caching是必选项多用户共享相同前缀时可以白赚一大截吞吐。第一次启动时模型加载会持续一分钟左右期间每张卡显存会快速填满到接近90GB这是正常现象。实测从NVMe固态加载FP8权重大约65秒左右完成如果是机械硬盘或者网络盘时间会成倍增长建议无论如何都要用NVMe。3. 性能实测延迟、吞吐、并发下的真实表现跑通只是第一步真正要看的是数据。这一节我直接给出我们实测的核心数字测试工具主要是vLLM自带的服务接口加上自己写的Python压测脚本数据基于我们的业务prompt分布可能和你的场景有差异但趋势大概率是通用的。3.1 单路延迟表现TTFT和TPOT实测先看最简单的单用户场景。这里有两个关键指标TTFT首token延迟也就是从发出请求到收到第一个token的时间和TPOT每个token输出的间隔时间。测试项输入长度实测值TTFT256 tokens约1.1秒TTFT2048 tokens约2.6秒TTFT8192 tokens约9.8秒TPOT单并发-约45毫秒单流输出速度-约22 tokens/sTTFT这组数据验证了我开头的判断H20的算力短板在预填充阶段暴露得很明显。8卡H20虽然加起来有约2400 TFLOPS的FP8算力但实际预填充多卡利用率大概只有50%到60%遇到8K这种长输入将近10秒才能吐出第一个字线上体验肯定不行。但单流TPOT表现比想象中好。45毫秒一个token换算过来大概22 tokens/s对于671B这个量级的模型来说这个速度放在H100上也未必能翻倍。原因很简单decode阶段模型主要是从显存里反复读取权重H20的4TB/s带宽在这里能充分发挥而算力需求反而不高。也就是说这个组合在“输出密集、输入较短”的场景里非常能打但如果输入很长、每个请求都在预填充短板就会被无限放大。3.2 并发压测总吞吐与显存水位单流好看不算本事生产环境看的是并发。我们用aiohttp写了个简单的并发压测脚本固定输入512 tokens目标输出512 tokens分别压了8、16、32、64并发结果如下并发数总吞吐输出tokens/s平均TPOT显存峰值8约15052 ms每卡约92GB16约29055 ms每卡约93GB32约51062 ms每卡约94GB64约69093 ms每卡约95GB从数据能明显看到32并发以前总吞吐基本是线性增长的单用户延迟也没有太大恶化说明显存带宽还没有被打满。到了64并发总吞吐虽然还在涨但单用户TPOT已经飙到93毫秒差不多10 tokens/s体验明显下降。这个拐点说明当前配置下32并发是一个甜点位再往上堆并发只会让每个请求都变慢总吞吐的边际收益已经很小。显存水位方面每卡长期稳定在92GB到95GB之间和规划时的预期基本一致。FP8权重占了约84GB每卡剩下的空间一部分被KV cache吃掉一部分被vLLM的调度buffer占据。如果你跑任务时发现显存动不动就99%那就得把max_num_seqs往下调不然迟早OOM。4. H20DeepSeek的调优思路瓶颈识别与参数取舍性能数据出来了下一步是定位瓶颈、做针对性调优。很多朋友一上来就堆并发、调KV cache方向其实错了。你要先搞清楚这个系统到底卡在算力、显存还是通信上再动手。4.1 算力不够是硬伤但可以绕H20的算力短板最直观的体现就是预填充慢。这个瓶颈是硬件层面的靠软件参数很难完全绕开但能做到“扬长避短”。我们试过两个有效的办法。第一个是限制max_model_len。模型虽然支持128K上下文但实际业务里绝大多数请求用不到把上限压到32K之后vLLM预先分配的KV cache块更紧凑预填充计算量也随之下降实测TTFT有10%到15%的改善。第二个是开vLLM的chunked prefill。这个功能会把长输入的预填充切成小块和decode请求交错执行避免一个长输入独占所有卡导致其他请求全部排队。开了之后并发场景下的平均TTFT明显更平滑没有那种“一个长请求进来整机卡死几秒”的灾难现场。decode阶段反而是H20的主场。因为每生成一个token基本是带宽瓶颈8张卡的总带宽差不多32TB/s应付37B激活参数绰绰有余。只要不要同时塞太多请求单流速度能稳稳维持在20 tokens/s以上。4.2 KV cache、并发度与max_model_len的三角关系这三个变量是相互制约的。KV cache占用的显存约等于“KV cache大小 × 并发序列数 × 最大序列长度”所以任何一个指标增加都会挤占其他指标的空间。具体到V3-0324因为用了MLA机制KV cache相比传统MHA模型小了一个数量级以上这也是它能塞进H20的重要原因。但“小”不等于“没有”我们把max_model_len从128K降到32K之后单卡释放出了大约8GB显存这些空间全部回到了KV cache池子里实测支撑32并发明显比之前从容。并发度方面max_num_seqs这个参数直接决定了vLLM同时处理的序列数。它不是越大越好因为并发太高时显存带宽和CPU调度都会成为新瓶颈而且单用户延迟会显著恶化。我们的经验是先从16开始压测观察显存水位和平均TPOT逐步加上去找到吞吐曲线的拐点。4.3 几个真正有用的调优参数整理一下这一轮调优里真正见效的参数按优先级排序max-model-len能压多低压多低这是KV cache空间的最大变量。max-num-seqs控制并发数建议根据压测曲线来定不要盲目拉高。enable-prefix-caching多用户场景必开相同system prompt能省大量重复预填充。gpu-memory-utilization0.90-0.94之间比较安全太低浪费显存太高容易OOM。块大小相关参数如block-size默认16即可改动收益不大反而增加调度碎片。至于网上常提的NCCL_P2P_DISABLE1这类环境变量在我们的8卡环境下没有发现明显影响。H20的多卡通信已经有NVLink加持TP8时通信开销主要集中在allreduce上这部分带宽是够用的。如果你用的是PCIe互联的低端服务器才需要考虑这类优化。5. 常见问题与排查技巧两周踩坑实录这部分我整理一下过去两周遇到的最典型问题每个都是实际跑出来的教训不是文档里能查到的。5.1 问题速查表现象原因解决方案启动时NCCL报错卡间通信失败多卡P2P未打通或驱动版本过旧升级驱动到550用nvidia-smi topo -m检查拓扑一跑请求就OOM崩溃KV cache预留不足或max_model_len过大降低max-model-len和max-num-seqs检查gpu-memory-utilization输出速度只有2-3 tokens/s某个算子回退到慢速实现升级vLLM到0.8.6确认flash-attn版本匹配FP8推理结果乱码老版本vLLM对H20的FP8支持有bug换用新版本vLLM不要用0.6.x并发一高TTFT暴涨长输入请求占住所有卡做预填充开启chunked prefill限制单请求最大输入长度显存明明有冗余但开不了更多并发max_num_seqs参数没显式设置启动参数里加上--max-num-seqs并调大5.2 三个值得展开的坑第一个坑是模型版本混用。我们一开始从网盘下载的权重其实是V3原版不是0324虽然文件名差不多但生成效果和性能都有细微差别。查了半天才发现是权重不对白白浪费了大半天。所以部署前一定要核对权重的文件hash或者直接看目录里的config.json确认是DeepSeek-V3-0324再往下走。第二个坑是vLLM版本和依赖的兼容性。H20的FP8支持在vLLM 0.6.x时代非常不稳定经常出现乱码或者未知算子崩溃。升级到0.8.6之后问题大幅减少但需要注意对应的flash-attention和transformers版本也必须是新版本否则会报Unsupported op之类的错误。装依赖的时候别只盯vLLM一个包整个环境一起更新更省心。第三个坑是长上下文请求导致的“假死”。线上有一次某个调用传了接近100K的输入结果整台服务的响应速度瞬间崩了其他短请求也跟着超时。这就是预填充阶段独占资源的典型症状。后来我们把max-model-len压到32K同时开启chunked prefill和请求级超时情况才稳定下来。如果你也要在H20上跑DeepSeek-V3-0324最想提醒的就一句话这个组合的性能上限不是由“跑不跑得动”决定的而是由你能把显存预算和并发度掰得多细决定的。FP8权重几乎吃光整机显存你必须在KV cache、max_model_len和并发数这三者之间做仔细的取舍。两周跑下来我们最终用8卡H20稳定支撑了32并发、单流22 tokens/s、总吞吐500 tokens/s的线上服务这个成绩对671B模型来说已经算达标了。建议你部署时也按这个思路先压一遍自己的业务流量别拿单流数据去估算生产容量那样会偏差很远。
