大模型模型推理服务AI 应用【免费下载链接】openPangu-R-72B-2512-vllm-ascend-0.11.0Ascend-SACT开源项目提供openPangu-72B适配昇腾A2的vllm-ascend 0.11.0推理镜像预装CANN 8.5.0.alpha002、torch-npu 2.7.1等套件修改权重目录即可快速启动离线推理支持后训练扩展方便开发者在昇腾NPU上高效部署大模型应用。【此简介由AI生成】项目地址https://ai.gitcode.com/Ascend-SACT/openPangu-72B-vllm-ascend-0.11.0点击查看免费下载openPangu-72B 是适配昇腾AscendNPU 的 72B MoE 开源大模型配合 vllm-ascend 0.11.0 推理镜像部署。本文基于 openPangu-72B-vllm-ascend-0.11.0 项目的真实启动脚本手把手带你完成显存规划与 KV Cache 调优从反复 OOMOut of Memory走向稳定高并发推理。一、为什么 72B 模型在昇腾 NPU 上容易 OOM要调优显存先搞清楚 HBMNPU 显存被谁吃掉了。一次 vLLM 推理任务的显存由三部分组成占用项说明openPangu-72B 中的特点模型权重常驻显存启动即加载MoE 结构80 个专家全部常驻每 token 仅激活 8 个但权重全都要装下KV Cache随并发和上下文长度线性增长支持最长 131072 上下文是最容易爆掉的变量激活与编译开销前向计算、CUDA Graph 捕获等长上下文 高并发时达到峰值从仓库中的模型配置 config.json 可以看到关键信息num_hidden_layers: 5050 层 Transformern_routed_experts: 80、num_experts_per_tok: 880 选 8 的 MoE 路由num_key_value_heads: 4GQA 分组注意力KV Cache 比 MHA 小得多这是长上下文部署的基础max_position_embeddings: 131072128K 上下文torch_dtype: bfloat16bf16 精度72B 权重约 144GB 结论MoE 模型权重占大头KV Cache 随并发波动。OOM 一般发生在两个时机——启动加载阶段权重装不下和推理运行阶段KV Cache 或激活峰值超标。调优思路就是分别给这两部分划地盘。二、环境先行先排除环境干扰再调参数调优之前先用项目预置的验证镜像把环境固定住避免CANN 版本不对、torch-npu 不匹配这类假 OOM。项目 README.md 给出了镜像配套的软件栈软件版本vLLM / vllm-ascendv0.11.0CANN8.5.0.alpha002torch-npu2.7.1.post2.dev20251120transformers4.57.1Python3.11.13部署时参考 docker_run.sh 中的启动脚本注意几个与内存相关的细节--shm-size1g共享内存多进程推理必备--device /dev/davinci_manager等设备挂载让容器能访问 NPU 设备-v /home/models:/home/models权重目录挂载到容器内改路径就能切模型进入容器后用npu-smi info确认每张卡的 HBM 总量和空闲量这是后续所有显存规划的基准。三、核心参数速查表显存与 KV Cache 调优全解下面这张表整理自项目真实使用的启动脚本 serve_niu.sh是全文最重要的部分。⭐参数取值作用与调优要点--gpu-memory-utilization0.85vLLM 允许使用的 HBM 比例上限。留 15% 给系统和其他进程OOM 频发可下调到 0.8--tensor-parallel-size4张量并行度权重切分到 4 张卡直接解决权重装不下型 OOM--enable-expert-parallel开启MoE 专家并行把 80 个专家分散到多卡进一步摊薄单卡权重压力--block-size128KV Cache 块大小是 KV Cache 管理的基本单位块越大页表开销越小--max-model-len131072单请求最大上下文长度。KV Cache 需求 ≈ 并发数 × 上下文长度这是最费显存的一项--max-num-seqs256最大并发序列数直接决定 KV Cache 池上限--max-num-batched-tokens4096单批最大 token 数控制激活峰值调太大是运行时 OOM 的常见元凶--no-enable-chunked-prefill开启关闭分块 prefill减少长文本 prefill 阶段的显存碎片--load-format autoauto权重加载格式auto 会按硬件选最优布局三个关键参数可以这样理解它们的关系--gpu-memory-utilization定总盘子HBM 总量的 85% 归 vLLM 使用--max-model-len × --max-num-seqs定 KV Cache 需求上下文越长、并发越多KV Cache 吃得越多--max-num-batched-tokens定激活峰值批内 token 越多前向计算瞬时占用越大。三者不匹配时vLLM 会打出ValueError: Free memory ... less than desired GPU memory utilization或 KV Cache 不足的告警看到这类报错就该回头降其中一个。四、环境变量容易被忽略的内存优化开关同样在 serve_niu.sh 中几个环境变量对显存稳定性影响很大但新手经常漏掉export VLLM_USE_V11 # 启用 vLLM V1 引擎吞吐与显存效率更好 export ASCEND_RT_VISIBLE_DEVICES0,1,2,3 # 指定可见 NPU与 TP4 对应 export HCCL_OP_EXPANSION_MODEAIV # 集合通信算子展开模式 export PYTORCH_NPU_ALLOC_CONFexpandable_segments:True # 可扩展显存段治碎片 OOM 的关键 export VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS900 # 首卡 kernel 慢时避免误杀超时其中PYTORCH_NPU_ALLOC_CONFexpandable_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_layoutMoE 专家权重以 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 走向稳定看基准npu-smi info记录每卡 HBM 总量与空闲量算出 85% 利用率的可用上限先跑通把--max-model-len临时降到 8192、--max-num-seqs降到 32验证链路全通参考 curl.sh 发起一条测试请求再提长逐步抬高--max-model-len至 131072观察启动日志中 KV Cache 总量# GPU blocks一类信息是否充足后提并发小步上调--max-num-seqs如 32 → 64 → 128 → 256每步跑压测并盯npu-smi查日志兜底OOM 时看启动日志定位是权重阶段还是运行阶段启动阶段调 TP/EP运行阶段降 batch tokens 或并发并确认expandable_segments已开启。 经验值如果日志提示 KV Cache 块数不足warning: ... KV cache size ...说明盘子不够优先降--max-num-batched-tokens其次降--max-model-len最后才考虑降--gpu-memory-utilization的方向方向反了会更卡。七、常见问题 FAQQ1启动就 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.jsonMoE 建模代码参考 modeling_pangu_moe.py。调优时一般只需修改启动脚本中的参数无需改动模型代码。写在最后openPangu-72B 在昇腾 NPU 上的调优核心只有三句话用 TP EP 把权重摊薄用gpu-memory-utilization和block-size规划好 KV Cache 池子用expandable_segments消灭碎片。按本文的参数速查表起步再走五步法验证绝大多数 OOM 都能收敛为稳定运行。赞分享大模型模型推理服务AI 应用【免费下载链接】openPangu-R-72B-2512-vllm-ascend-0.11.0Ascend-SACT开源项目提供openPangu-72B适配昇腾A2的vllm-ascend 0.11.0推理镜像预装CANN 8.5.0.alpha002、torch-npu 2.7.1等套件修改权重目录即可快速启动离线推理支持后训练扩展方便开发者在昇腾NPU上高效部署大模型应用。【此简介由AI生成】项目地址https://ai.gitcode.com/Ascend-SACT/openPangu-72B-vllm-ascend-0.11.0点击查看免费下载相关推荐昇腾NPU内存管理优化openPangu-Embedded-1B-V1.1 KV缓存策略详解昇腾NPU内存管理优化openPangu Embedded 1B V1.1 KV缓存策略详解 引言嵌入式AI的内存困境与解决方案 你是否还在为嵌入式设备上部基础模型大模型昇腾NPU模型迁移指南从GPU到昇腾部署openPangu-Embedded-1B-V1.1昇腾NPU模型迁移指南从GPU到昇腾部署openPangu Embedded 1B V1.1 1. 迁移痛点与解决方案概览 在嵌入式设备部署大语言模型时开发基础模型大模型React Native IAP与Expo集成指南开发构建的完整配置教程React Native IAP与Expo集成指南开发构建的完整配置教程 React Native IAP是一个功能强大的原生模块专为React Nativ上一篇ComfyUI IPAdapter Plus终极指南快速掌握AI图像风格迁移下一篇OBS Spout2插件完整指南实现跨平台视频流高效传输创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
