从OOM到稳定：openPangu-72B昇腾NPU显存与KV Cache调优完整指南

• 大模型
• 模型推理服务
• AI 应用

openPangu-72B 是适配昇腾（Ascend）NPU 的 72B MoE 开源大模型，配合 vllm-ascend 0.11.0 推理镜像部署。本文基于 openPangu-72B-vllm-ascend-0.11.0 项目的真实启动脚本，手把手带你完成显存规划与 KV Cache 调优，从反复 OOM（Out of Memory）走向稳定高并发推理。🚀

一、为什么 72B 模型在昇腾 NPU 上容易 OOM？

要调优显存，先搞清楚 HBM（NPU 显存）被谁吃掉了。一次 vLLM 推理任务的显存由三部分组成：

从仓库中的模型配置 config.json 可以看到关键信息：

• num_hidden_layers: 50：50 层 Transformer
• n_routed_experts: 80、num_experts_per_tok: 8：80 选 8 的 MoE 路由
• num_key_value_heads: 4：GQA 分组注意力，KV Cache 比 MHA 小得多，这是长上下文部署的基础
• max_position_embeddings: 131072：128K 上下文
• torch_dtype: bfloat16：bf16 精度，72B 权重约 144GB

💡 结论：MoE 模型权重占大头，KV Cache 随并发波动。OOM 一般发生在两个时机——启动加载阶段（权重装不下）和推理运行阶段（KV Cache 或激活峰值超标）。调优思路就是分别给这两部分"划地盘"。

二、环境先行：先排除环境干扰再调参数

调优之前，先用项目预置的验证镜像把环境固定住，避免"CANN 版本不对、torch-npu 不匹配"这类假 OOM。

项目 README.md 给出了镜像配套的软件栈：

部署时参考 docker_run.sh 中的启动脚本，注意几个与内存相关的细节：

• --shm-size=1g：共享内存，多进程推理必备
• --device /dev/davinci_manager等设备挂载：让容器能访问 NPU 设备
• -v /home/models:/home/models：权重目录挂载到容器内，改路径就能切模型

进入容器后用npu-smi info确认每张卡的 HBM 总量和空闲量，这是后续所有显存规划的基准。

三、核心参数速查表：显存与 KV Cache 调优全解

下面这张表整理自项目真实使用的启动脚本 serve_niu.sh，是全文最重要的部分。⭐

三个关键参数可以这样理解它们的关系：

1. --gpu-memory-utilization定总盘子：HBM 总量的 85% 归 vLLM 使用；
2. --max-model-len × --max-num-seqs定 KV Cache 需求：上下文越长、并发越多，KV Cache 吃得越多；
3. --max-num-batched-tokens定激活峰值：批内 token 越多，前向计算瞬时占用越大。

三者不匹配时，vLLM 会打出ValueError: Free memory ... less than desired GPU memory utilization或 KV Cache 不足的告警，看到这类报错就该回头降其中一个。

四、环境变量：容易被忽略的内存优化开关

同样在 serve_niu.sh 中，几个环境变量对显存稳定性影响很大，但新手经常漏掉：

export VLLM_USE_V1=1 # 启用 vLLM V1 引擎，吞吐与显存效率更好 export ASCEND_RT_VISIBLE_DEVICES=0,1,2,3 # 指定可见 NPU，与 TP=4 对应 export HCCL_OP_EXPANSION_MODE="AIV" # 集合通信算子展开模式 export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True # 可扩展显存段，治碎片 OOM 的关键 export VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS=900 # 首卡 kernel 慢时避免误杀超时

其中PYTORCH_NPU_ALLOC_CONF=expandable_segments:True最值得强调：它让 PyTorch NPU 分配器使用可扩展的显存段，显著减少长时运行后出现的显存碎片型 OOM（日志里显示"总剩余不少，却分配失败"的典型症状）。

五、编译与调度：榨出最后一点显存空间

启动命令的后半段还有一些进阶选项：

--async-scheduling --additional-config '{"enable_weight_nz_layout":true,"multistream_overlap_shared_expert":true}' --compilation_config '{"cudagraph_mode": "FULL_DECODE_ONLY", "cudagraph_capture_sizes": [1,2,4,8,16,32,64,128,256]}'

• enable_weight_nz_layout：MoE 专家权重以 nz 紧凑布局存放，省掉稀疏权重中的空洞，直接节省显存；
• multistream_overlap_shared_expert：共享专家与路由专家多流重叠执行，用时间换显存峰值；
• cudagraph_mode: FULL_DECODE_ONLY：只对 decode 阶段做整图捕获。注意：Graph 捕获本身也会占用一部分显存，所以cudagraph_capture_sizes只列到常用并发档位（1~256），不要盲目拉满；
• --async-scheduling：异步调度，减少调度器等待带来的显存驻留时间。

另外两个与业务相关但不影响显存的开关也一并说明：--enable-auto-tool-choice --tool-call-parser pangu与--reasoning-parser pangu，分别开启工具调用与推理模式解析。

六、实操调优流程：防 OOM 五步法

把上面的参数用起来，再按这个流程走一遍，基本可以从 OOM 走向稳定：

1. 看基准：npu-smi info记录每卡 HBM 总量与空闲量，算出 85% 利用率的可用上限；
2. 先跑通：把--max-model-len临时降到 8192、--max-num-seqs降到 32，验证链路全通（参考 curl.sh 发起一条测试请求）；
3. 再提长：逐步抬高--max-model-len至 131072，观察启动日志中 KV Cache 总量（# GPU blocks一类信息）是否充足；
4. 后提并发：小步上调--max-num-seqs（如 32 → 64 → 128 → 256），每步跑压测并盯npu-smi；
5. 查日志兜底：OOM 时看启动日志定位是权重阶段还是运行阶段，启动阶段调 TP/EP，运行阶段降 batch tokens 或并发，并确认expandable_segments已开启。

📌 经验值：如果日志提示 KV Cache 块数不足（warning: ... KV cache size ...），说明盘子不够，优先降--max-num-batched-tokens，其次降--max-model-len，最后才考虑降--gpu-memory-utilization的方向（方向反了会更卡）。

七、常见问题 FAQ

Q1：启动就 OOM，还没开始推理怎么办？多为权重装不下。检查--tensor-parallel-size与ASCEND_RT_VISIBLE_DEVICES的卡数是否匹配，确认--enable-expert-parallel已开启（MoE 必开）。

Q2：高并发跑一会儿才 OOM，单独跑没问题？典型 KV Cache/并发问题。确认--max-num-seqs与--max-num-batched-tokens没有同时拉满；开启expandable_segments:True排除碎片因素。

Q3：想支持更长上下文，但显存不够怎么办？利用该模型的 GQA 优势（仅 4 个 KV head）：保持--block-size 128，适度降低--max-num-seqs，把省下的块让给长上下文；MoE 激活参数少，长上下文主要压力就是 KV Cache 本身。

Q4：改过哪些文件？本项目的启动参数集中在 serve_niu.sh，环境部署在 docker_run.sh，模型结构定义见 config.json，MoE 建模代码参考 modeling_pangu_moe.py。调优时一般只需修改启动脚本中的参数，无需改动模型代码。

写在最后

openPangu-72B 在昇腾 NPU 上的调优核心只有三句话：用 TP + EP 把权重摊薄，用gpu-memory-utilization和block-size规划好 KV Cache 池子，用expandable_segments消灭碎片。按本文的参数速查表起步，再走五步法验证，绝大多数 OOM 都能收敛为稳定运行。🎯

• 大模型
• 模型推理服务
• AI 应用