这两年搞大模型推理的人，感受最深的一个词叫“供需错配”。训练端的风头再盛，它终归是阶段性的投入；真正让基础架构团队每天睁眼就要面对的，是推理侧的算力账单。DeepSeek这波开源带火的不只是模型本身，更把“推理侧算力爆发”这个概念硬生生推到了台前——很多团队开始把目光从进口卡转向国产超节点，毕竟成本、交付周期、供应链可控性摆在那里。但国产超节点不是插上卡就能跑的，它和成熟的进口卡生态有差异，部署、量化、并行策略、调度优化这些环节里的坑，比很多人预想的多得多。

这篇文章不聊理论，主要讲实操。我会围绕DeepSeek在国产超节点上的部署流程、效率优化技巧、踩坑记录展开，把我实际跑过的配置、调过的参数、排查过的问题都整理出来，给正在做同类选型或迁移的团队一个可参考的路径。

1. 推理侧算力爆发，先搞清楚钱花在了哪里

1.1 训练是项目制，推理是订阅制

训练一个模型，无论花多少钱，它总有一个终点：训练完成，账单结束。但推理完全不一样，模型一旦上线，token就像自来水一样持续流出去，每一秒都在产生算力消耗。过去大家讨论算力，重心全在训练集群规模，但DeepSeek这类开放权重模型出现后，大量团队可以基于现成权重做私有化部署、做垂直场景微调，这就把推理需求直接拉满。

更关键的是，DeepSeek的推理成本结构很特殊。它用的是MoE（混合专家）架构，总参数量很大，但每次推理只激活一部分参数。这个特性让它在单token计算量上很占便宜，但同时也带来一个麻烦：模型权重必须完整放在显存里，否则没法按需激活对应专家。MoE解释清楚：参数量大但计算量小的模型，显存占用是“总参数量×字节数”，这和Dense模型没有区别。

一个典型的DeepSeek版本，总参数达到671B级别，光是权重以BF16存就要1.3TB以上，FP8也要接近700GB。单卡显存就算撑到80GB，也得十几张卡才能把模型装下。如果还要算上KV Cache、激活值、临时缓冲，单机八卡根本不现实。这就解释了为什么推理侧会盯着“超节点”这种形态——它本质上把很多张加速卡通过高速互联聚合起来，让大模型能更像跑在“一张大卡”上。

1.2 国产超节点和进口卡生态的定位差异

很多人看到国产超节点的第一反应是“规格还真高”——单节点几十张卡、高带宽互联、大容量HBM，纸面参数已经不输主流的进口方案。但实际用下来会发现，差距不在峰值算力，而在生态成熟度。

进口卡那条链路，从底层算子库到上层推理引擎，已经过大量生产环境打磨，很多事情是“开箱即用”的。国产这边则不一样，哪怕同一家厂商，不同型号的加速卡、不同版本的驱动和工具链，行为都可能不同。对一个部署团队来说，这意味着同样一个推理框架，在国产超节点上跑，可能需要自己改内核、调通信策略、绕过某些算子实现。

但这个差异不需要被妖魔化。国产超节点的优势也很明显：单节点聚合能力更强，卡间互联的带宽和拓扑往往比传统PCIe服务器更优；更关键的是供应稳定，大批量采购时不会有太多不确定性。对推理场景来说，只要模型能合理切分、通信能重叠起来，国产超节点实际上可以跑出非常可观的整体吞吐。

2. 部署前，先算清三笔账

2.1 显存账：模型装得下，才有优化可谈

部署DeepSeek之前，第一步不是选框架，而是算显存。我把核心公式列出来，方便照着套：

模型权重显存 = 参数量 × 每个参数的字节数

• BF16：2字节，671B模型约1342GB
• FP8：1字节，671B模型约671GB
• INT4：0.5字节，671B模型约335GB

然后是KV Cache，这是推理侧动态增长的显存消耗大头。KV Cache大小跟并发数、序列长度、层数、头数直接相关。公式可以简化成：

KV Cache显存 ≈ 2 × 层数 × 头数 × 每头维度 × 序列长度 × 并发请求数 × 字节数

拿DeepSeek这类MoE模型举例，虽然KV Cache因为注意力机制独立于专家网络，不如权重那么夸张，但在高并发长上下文场景下，几百GB的KV Cache也很常见。

还有一类容易被忽视的显存占用是激活值和临时缓冲区。做prefill的时候，长序列的中间激活很占资源；做decode的时候，虽然单步激活小，但调度框架需要预留一部分显存做请求管理。

算完这三块，再看看手头的超节点有多少显存。我给的实操建议是：总显存至少留出模型权重2倍以上，否则后面做批量调度和KV Cache优化会很紧。

2.2 带宽账：MoE模型最吃的是互联，不是算力

DeepSeek这种MoE模型，推理时有两个显著特征。第一，计算密度低，因为只激活部分参数，算力利用率天然不如Dense模型高；第二，通信密度高，因为token需要路由到不同专家所在的卡上，跨卡通信非常频繁。

这就带来一个反直觉的结论：在DeepSeek推理场景下，卡间互联带宽往往比单卡算力更决定系统吞吐。如果互联带宽不足，每次token路由都要等待all2all通信返回，哪怕每张卡的算力再强，也只能干等着。

所以部署前一定要搞清楚超节点的互联拓扑。是全网状？还是分层交换？卡与卡之间的理论带宽是多少？实测带宽是多少？我建议拿一个小矩阵做一次纯通信压测，比如让每张卡之间互相传几百MB数据，看看实际能达到多少带宽。很多时候纸面带宽和实测带宽差异巨大，这个数据直接影响后续并行策略选择。

2.3 性能目标账：吞吐优先还是延迟优先

同样是部署DeepSeek，阶段不同目标完全不同。如果接的是离线批量任务，比如批量处理文档、跑数据标注，那优先指标是吞吐，单位时间内处理多少token，延迟大一点可以接受。如果接的是在线对话、智能助手，那优先指标是首token延迟和单token延迟，要求就是“快感”。

这两个目标会导向不同的配置策略。吞吐优先时，可以用更大的batch size、更激进的KV Cache复用、更深的请求合并；延迟优先时，则要控制batch size、减少通信往返、考虑用投机解码来加速单步生成。

很多团队一开始就希望两者兼顾，结果两头都没做到。我的建议是先明确当前业务的主要目标，按它来定参数，后续再根据实际压测结果调整。

3. DeepSeek在国产超节点上的部署实操

3.1 环境准备：别急着上大模型，先跑通小矩阵

国产超节点的环境准备通常比进口卡要多花一点时间，因为驱动、固件、加速卡管理工具链的版本兼容性比较讲究。我踩过的一次典型坑是：驱动版本和上层算子库版本不匹配，导致某些算子回退到慢速路径，整体吞吐直接打六折。

更稳妥的流程是：

1. 先确认加速卡驱动版本、容器运行时版本，以及深度学习框架的适配版本。
2. 建一个最小的测试环境，用一个小模型跑通前向和反向，确认基础算子是通的。
3. 跑一次all2all通信压测，确认卡间通信带宽达标。
4. 再加载DeepSeek的权重做推理验证。

这套流程看起来繁琐，但能帮你在后面排查问题时隔离变量。环境层面有问题，就别急着调优参数，否则你会陷入“看着没问题，但性能就是不达标”的泥潭。

3.2 推理框架选型：没有银弹，只有适配

当前主流的开源推理框架，我归纳下来主要有三套体系：一套偏科研和生产并重，调度灵活，社区很活跃，支持多种量化格式和并行策略；另一套更强调极致吞吐，对某些硬件特性做了深度优化；还有一套是厂商自带的商业推理引擎，和自家加速卡绑定紧密，闭源但性能下限高。

实操经验是：不要迷信某一个框架。同一个模型、同一批卡，换一个框架性能可能差很多。更靠谱的做法是，同时准备两个框架做基准对比，哪个指标达标就用哪个。

国产超节点上尤其要注意的是，框架对底层算子的调用路径。有些框架默认走标准CUDA（或通用计算接口）路径，有些能走到硬件专用的加速库，两者的差距可能有好几倍。部署时可以先看框架是否支持接入厂商的加速算子库，这是性能提升的一个捷径。

3.3 并行策略：MoE模型的答案是“EP + TP混用”

DeepSeek这类MoE模型，并行方式不能照搬Dense模型。Dense模型的核心并行是张量并行TP，把权重切到多张卡上共同算一个层。但在MoE场景下，专家的分布才是决定通信量的关键。

我的部署策略是：

• 注意力层用TP（张量并行），因为注意力计算对算力要求高，需要把计算分散到多卡。
• 专家层用EP（专家并行），把不同专家分布到不同卡上，token按路由结果发送到对应卡。

EP的好处是，每张卡只负责一部分专家，计算密度更高；坏处是，token在不同卡之间流转，通信模式复杂。国产超节点做EP时，卡间互联带宽就是胜负手。但也不用过度担心，只要互联带宽到位，通过把EP和TP混用，通常可以达到比较理想的吞吐。

实操中还有一个经验：如果token路由非常不均衡，部分专家负载过高，部分专家闲置，EP的效率会下降。这时可以在框架层开启负载均衡策略，或者在训练时就用带负载均衡约束的MoE结构。DeepSeek本身的专家路由设计比较均匀，这个坑相对小一些。

3.4 量化与KV Cache优化：从FP8开始，逐级往下降

对DeepSeek这种千亿级模型，不做量化基本没法在生产环境落地。我的建议是从FP8起步，这是一个在精度和性能之间最平衡的点。FP8权重配合FP8激活（W8A8），整体显存能比BF16省一半，算力利用率也会明显提升。

量化时的关键点在于校准数据。要用有代表性的数据做激活值校准，不能随便拿几句话就完事。国产加速卡对FP8的支持程度不一，有些卡对FP8算子支持不完整，可能出现算子回退到FP16的情况。碰到这种情况，需要检查算子图，看看是不是所有关键算子都跑在FP8路径上。

KV Cache量化是另一个大头。DeepSeek的上下文窗口很长，如果KV Cache用BF16存，高并发下显存压力非常大。把KV Cache降到INT8甚至INT4，能在保持较高精度的情况下，把显存占用降一半以上。这里有一点要提醒：KV Cache量化对长尾注意力值比较敏感，量化后一定要做基准测试，特别是长上下文场景下，看看困惑度和生成质量有没有明显退化。

3.5 调度优化：连续性批处理和PD分离

框架层面的调度优化，对吞吐提升的贡献往往比硬件优化更直接。我重点提三个方向。

第一是连续性批处理。传统的静态批处理，要等一个batch全部生成完才接收新请求，浪费严重。连续性批处理则是每步都检查有哪些请求已完成，空出来的GPU资源立刻分配给新请求。这个技术能让空闲算力被填满，吞吐提升非常可观，属于必选项。

第二是PD分离。prefill阶段计算密集，decode阶段访存密集，两者混在一起对资源调度不友好。把prefill和decode分别放在不同的计算资源上，可以有效避免互相拖累。国产超节点通常规模够大，完全有条件划分出prefill节点和decode节点。甚至可以让多个prefill节点服务一个decode节点，这对长上下文和稀疏请求场景尤其有效。

第三是投机解码。DeepSeek这种模型decode速度不算快，每步生成一个token，如果有一段时间序列很长，用户体感会很差。投机解码用一个轻量草稿模型先预测多个token，再用大模型一次性验证，能大幅提升decode吞吐。不过这会多占一部分显存，需要在显存预算里提前规划。

3.6 一个可复现的配置参考

下面是我在某国产超节点上实测过的一组配置，场景是做DeepSeek的私有化推理服务，在线对话为主，兼跑批量任务。数据是实测近似值，配置可以照抄，具体数值请按自己的卡重新压测。

这套配置的核心思路是把显存压下来，把通信提上去，再用调度把空闲算力填满。过程中最大的收益来源是PD分离，它把在线对话的延迟抖动明显消除了。

4. 踩坑实录：国产超节点部署DeepSeek的典型问题

4.1 显存OOM：不是显存不够，是碎片和预留不对

跑DeepSeek时OOM，最常见的原因不是模型太大，而是显存管理策略不对。连续性批处理下，每个请求的KV Cache是动态增长的，如果框架没有做好预分配和复用，显存碎片会越来越大，最后明明有空间但分配不出来。

排查方法很简单：看显存分配曲线，如果出现锯齿状波动，大概率是碎片问题。解决思路是开启框架的显存池复用机制，同时设置合理的连续批处理请求上限，别让请求无限涌入。

4.2 通信等待：算力卡在互联上

之前提到MoE模型吃互联带宽，这个坑在实际部署中经常表现为：GPU利用率不高但吞吐也上不去。拿性能分析器一看，发现大量时间耗在all2all通信等待上。

解决方向有三个：一是在并行策略上减少EP跨节点（尽量把EP限制在单节点内，不做跨节点EP），二是开启通信与计算重叠，让当前层的通信和上一层的计算同时进行，三是如果框架支持，调整通信算子实现，比如用高带宽路径代替默认实现。

4.3 量化后精度下降：小心激活值离群点

FP8量化DeepSeek权重，整体质量损失通常不大，但如果校准数据集覆盖不够，激活值会出现离群点，导致量化后特定Prompt下生成质量明显变差。

我的经验是：校准数据至少要覆盖业务实际场景的主要类型，而且多样化一些。对于DeepSeek这种长上下文模型，校准数据里一定要包含长文本场景，否则短文本校准出来的量化参数在长文本上容易出问题。

4.4 负载不均衡：专家路由与请求偏斜

MoE模型在极端场景下会出现某个专家特别忙、其他专家很闲的问题。比如大量请求集中在某个领域，导致特定专家被打满，其他专家空转。这种情况在EP配置下会更明显，因为一部分卡会排队，另一部分卡却闲得发慌。

解法有两个层面：一是框架层面开启负载均衡策略，让路由分配尽量均匀；二是业务层面做请求整形，错开热点请求。如果都不行，只能考虑扩大EP维度，分担热点专家压力。

4.5 问题速查表

5. 效率优化的延伸思考：别只盯单点指标

5.1 推理链路的整体视角：从模型到服务的统筹

部署DeepSeek到国产超节点，最后的瓶颈往往不在单点，而是整条链路的协同。模型并行、量化、调度、解码策略、通信重叠、显存复用，这些优化不是孤立存在的。改一个参数，可能让另一个环节恶化。所以我把优化顺序固定下来：先压显存，再减通信，最后调调度。顺序反了，效果会大打折扣。

举个例子，如果你先开了投机解码，占了一部分显存，再去跑大的batch size，可能KV Cache放不下，最后整体吞吐反而下降。反过来，把量化做完，显存宽裕了，再加投机解码，收益就会很明显。

5.2 成本视角：超节点的容量规划与弹性

国产超节点的部署通常是大批量采购，但推理需求往往在一开始没有那么大。我见过不少团队上来就买几十上百卡，结果负载只有百分之二三十，成本压力非常大。

我的建议是，先确定最小可用规模，用量化后的单节点容量做估算，跑出基线指标后，再按业务增长曲线决定扩容节奏。同时注意国产超节点在推理场景下可以按节点横向扩展，通过PD分离把prefill和decode节点拆开，这样扩容量的时候可以只扩瓶颈侧，不用整堆一起加。

5.3 可运维性：监控、告警与灰度

部署上线只是开始，真正后续打磨的是可运维性。国产超节点和进口卡在监控指标上会有些差异，比如卡间通信带宽、环型/网格拓扑的健康状态、特定算子的回退情况，这些都需要加到监控大盘里。

灰度发布也很关键。上线时先用一小部分流量测试，观察量化后生成质量、延迟分布、OOM频率，确认稳了再全量。我个人的经验是，DeepSeek这类开放权重模型的部署本身难度不算高，真正的难点是保持长期稳定运行，这需要监控、压测、灰度机制都要跟上。

写在最后的一点体会

前前后后做了几轮DeepSeek在国产超节点上的部署和调优，我最深的一条感受是：不要把国产超节点当作进口卡的平替来用，而是要把它当作一个独立的硬件形态去适配。它的互联拓扑、算子生态、调度习惯都有自己的特点，顺着它的优势来设计并行和部署方案，很多看似“性能不够”的问题其实都能解决。

如果只能给一条建议，我会说：先跑通最小闭环，再谈压满性能。很多时候性能瓶颈不是硬件不行，而是环境、框架、并行策略的组合没有调到位。希望这篇文章的经验能帮正打算上国产超节点跑DeepSeek的团队少踩几个坑，省下一些花在排查上的时间。