为什么不用 vLLM-Ascendppo-Huggy-NPU 推理引擎选型决策复盘【免费下载链接】ppo-Huggy-NPU项目地址: https://ai.gitcode.com/z_studio/ppo-Huggy-NPU在昇腾 NPU 上部署模型很多人的第一反应就是「上 vLLM-Ascend」。但 ppo-Huggy-NPU 这个开源项目偏偏反其道而行它把 Hugging Face Deep RL 课程经典示例 Huggy the Dog拥抱机器人 完整部署到了昇腾 910B NPU 上推理引擎选的却是torch_npu。这篇文章将完整复盘这次昇腾 NPU 推理引擎选型决策vLLM-Ascend 到底卡在哪、torch_npu 凭什么胜出、以及你下次遇到类似模型该怎么选。一、先认识这只小狗Huggy 到底是什么模型Huggy 是 Hugging Face Deep RL 课程的经典入门示例一只由 Unity ML-Agents 训练的小狗学会「扑向并拥抱」投出的棍子。它由PPO 算法训练max_steps: 2,000,000权重发布在 Hugging Face Hub参数量仅566,805fp32 权重约 2.3 MB。关键的一点是Huggy 的网络结构是MLP 策略网络59 维观测 → 3 层 512 隐藏层 → 21 维连续动作不是 Transformer不是 LLM也不是 VLM。整个网络的计算图非常简单观测归一化clamp((obs − running_mean) / sqrt(running_variance / steps), −5, 5)主干Linear(59→512) → SiLU → Linear(512→512) → SiLU → Linear(512→512) → SiLU动作头mu Linear(512→21)确定性动作 clip(mu, −3, 3) / 3这段网络结构在 inference.py 的脚本注释里有完整描述也在 README.md 中配了计算图说明。先看清模型类型是后面所有选型判断的起点。二、核心问题为什么 vLLM-Ascend 跑不了 Huggy这是整个项目最容易被问到的问题。答案其实很直接vLLM-Ascend 的定位是 LLM/VLM 的自回归 token 生成推理引擎。它的模型注册表vllm/model_executor/models/registry.py只包含文本和视觉生成架构——比如 Qwen、Llama、DeepSeek 这类大语言模型。它的工作方式是把 prompt 编码 → 逐 token 自回归生成 → 流式输出。这一整套链路是为生成式大模型量身定制的。而 Huggy 是强化学习的策略网络输入是 59 维的连续向量观测输出是 21 维的连续动作属于判别式的前向计算完全不涉及 token 生成。也就是说vLLM-Ascend 的模型注册表里根本没有 MLP 策略网络这类架构加载都加载不进去就算强行套用自回归的 KV Cache、采样器、tokenizer 等组件对 Huggy 来说毫无意义。打个比方vLLM-Ascend 是一台专门运集装箱的重型卡车而 Huggy 只是一件小快递。卡车装不下也不该用它来送。三、torch_npu 胜出的三个关键理由排除 vLLM-Ascend 后项目最终选择了torch_npu昇腾官方 PyTorch 后端。胜出理由有三点1. 原生 PyTorch 生态直接 forward 策略网络。torch_npu 让torch代码几乎零改动地在 NPU 上运行只需把设备指定为npu:0模型就能直接在昇腾 910B 上完成前向推理不需要任何转换。2. 算子全部原生兼容。逐算子核对后确认Huggy 计算图用到的Sub / Div / Clip / Gemm / Sigmoid / Mul / Add / Exp全部是 PyTorch 原生算子昇腾 ACL 直接支持没有 CUDA 独有算子、没有 Triton 依赖、没有阻塞项。这一条在 AGENT_WORKFLOW.md 的 Step 4 有详细记录。3. 与官方 ONNX 交叉验证数值完全对得上。项目以官方Huggy.onnx作为 CPU 参考实现onnxruntime与 torch 重建的网络做逐算子对比最大偏差仅6.6e-7float32 舍入级别余弦相似度 1.0确认模型结构与数值还原完全正确。四、选型决策复盘一张表看懂该选哪个引擎这次踩坑的经验完全可以沉淀成一张选型速查表模型类型典型特征推荐推理引擎LLM / VLMTransformer、自回归 token 生成vLLM-Ascend / SGLang经典 RL 策略网络MLP、向量观测 → 连续动作torch_npu其他 PyTorch 模型CNN 等非生成式架构torch_npu判断三步法以后遇到新模型可以照着走看架构是 Transformer 且需要逐 token 生成→ 考虑 vLLM-Ascend是 MLP/CNN 这种判别式结构→ 直接走 torch_npu看算子计算图里有没有 CUDA 独有或 Triton 依赖的算子没有就基本畅通看验证用官方权重如 ONNX做参考实现交叉验证数值对齐才算真正适配成功。五、实战验证50 组测试用例给出答案选型正确与否最终要靠数据说话。项目在inference.py中实现了11 种推理模式info / action / sample / batch / precision / onnx-compare / fingerprint / stats / benchmark / export-onnx 等并跑完了50 组测试用例可用 run_tests.sh 一键重跑性能单步推理平均延迟0.37 msp95 0.40 ms权重加载仅 0.03 秒峰值显存不到 100 MB精度float32 下 NPU 与 CPU 参考的余弦相似度1.0最大绝对误差仅1.1e-6与官方 ONNX 一致确定性同 seed 两次运行的输出逐位一致sha256 指纹校验通过双卡npu:0/npu:1输出也逐位一致发现fp16 精度可接受但bf16 在 910B 上相对误差略超阈值因此生产推荐 float32。另外值得一提的细节ML-Agents 的running_variance是累计和可达 1e5强转 float16 会溢出成 inf 导致归一化 NaN所以脚本强制将归一化统计量保留 float32——这类坑在 AGENT_WORKFLOW.md 的 Step 7 有完整记录。六、快速上手三步在昇腾 NPU 上跑通推理如果你想亲自验证这套选型环境要求是CANN 8.5.1 Ascend 910B Python 3.11然后按下面三步走第 1 步克隆仓库并创建虚拟环境git clone https://gitcode.com/z_studio/ppo-Huggy-NPU cd ppo-Huggy-NPU python3 -m venv --system-site-packages venv第 2 步安装依赖torch / torch-npu 为昇腾系统预置仅需按需安装交叉验证包./venv/bin/pip install -r requirements.txt第 3 步运行推理./venv/bin/python inference.py --mode info ./venv/bin/python inference.py --mode action --obs random --seed 0 ./venv/bin/python inference.py --mode benchmark --runs 200如果看到npu_available True且用例全部SUCCESS说明选型和部署都成功了。结语选型没有最好只有最合适vLLM-Ascend 是优秀的 LLM 推理引擎但它不是万能的。ppo-Huggy-NPU 的这次推理引擎选型决策复盘告诉我们先看清模型类型再选推理引擎。对于强化学习策略网络这类非生成式模型torch_npu 反而是更轻、更快、更正确的选择——单步 0.37 ms 的延迟和 1e-6 级别的精度误差就是最好的证明。希望这份复盘能帮你在下次选型时少走弯路。【免费下载链接】ppo-Huggy-NPU项目地址: https://ai.gitcode.com/z_studio/ppo-Huggy-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么不用 vLLM-Ascend？ppo-Huggy-NPU 推理引擎选型决策复盘
为什么不用 vLLM-Ascendppo-Huggy-NPU 推理引擎选型决策复盘【免费下载链接】ppo-Huggy-NPU项目地址: https://ai.gitcode.com/z_studio/ppo-Huggy-NPU在昇腾 NPU 上部署模型很多人的第一反应就是「上 vLLM-Ascend」。但 ppo-Huggy-NPU 这个开源项目偏偏反其道而行它把 Hugging Face Deep RL 课程经典示例 Huggy the Dog拥抱机器人 完整部署到了昇腾 910B NPU 上推理引擎选的却是torch_npu。这篇文章将完整复盘这次昇腾 NPU 推理引擎选型决策vLLM-Ascend 到底卡在哪、torch_npu 凭什么胜出、以及你下次遇到类似模型该怎么选。一、先认识这只小狗Huggy 到底是什么模型Huggy 是 Hugging Face Deep RL 课程的经典入门示例一只由 Unity ML-Agents 训练的小狗学会「扑向并拥抱」投出的棍子。它由PPO 算法训练max_steps: 2,000,000权重发布在 Hugging Face Hub参数量仅566,805fp32 权重约 2.3 MB。关键的一点是Huggy 的网络结构是MLP 策略网络59 维观测 → 3 层 512 隐藏层 → 21 维连续动作不是 Transformer不是 LLM也不是 VLM。整个网络的计算图非常简单观测归一化clamp((obs − running_mean) / sqrt(running_variance / steps), −5, 5)主干Linear(59→512) → SiLU → Linear(512→512) → SiLU → Linear(512→512) → SiLU动作头mu Linear(512→21)确定性动作 clip(mu, −3, 3) / 3这段网络结构在 inference.py 的脚本注释里有完整描述也在 README.md 中配了计算图说明。先看清模型类型是后面所有选型判断的起点。二、核心问题为什么 vLLM-Ascend 跑不了 Huggy这是整个项目最容易被问到的问题。答案其实很直接vLLM-Ascend 的定位是 LLM/VLM 的自回归 token 生成推理引擎。它的模型注册表vllm/model_executor/models/registry.py只包含文本和视觉生成架构——比如 Qwen、Llama、DeepSeek 这类大语言模型。它的工作方式是把 prompt 编码 → 逐 token 自回归生成 → 流式输出。这一整套链路是为生成式大模型量身定制的。而 Huggy 是强化学习的策略网络输入是 59 维的连续向量观测输出是 21 维的连续动作属于判别式的前向计算完全不涉及 token 生成。也就是说vLLM-Ascend 的模型注册表里根本没有 MLP 策略网络这类架构加载都加载不进去就算强行套用自回归的 KV Cache、采样器、tokenizer 等组件对 Huggy 来说毫无意义。打个比方vLLM-Ascend 是一台专门运集装箱的重型卡车而 Huggy 只是一件小快递。卡车装不下也不该用它来送。三、torch_npu 胜出的三个关键理由排除 vLLM-Ascend 后项目最终选择了torch_npu昇腾官方 PyTorch 后端。胜出理由有三点1. 原生 PyTorch 生态直接 forward 策略网络。torch_npu 让torch代码几乎零改动地在 NPU 上运行只需把设备指定为npu:0模型就能直接在昇腾 910B 上完成前向推理不需要任何转换。2. 算子全部原生兼容。逐算子核对后确认Huggy 计算图用到的Sub / Div / Clip / Gemm / Sigmoid / Mul / Add / Exp全部是 PyTorch 原生算子昇腾 ACL 直接支持没有 CUDA 独有算子、没有 Triton 依赖、没有阻塞项。这一条在 AGENT_WORKFLOW.md 的 Step 4 有详细记录。3. 与官方 ONNX 交叉验证数值完全对得上。项目以官方Huggy.onnx作为 CPU 参考实现onnxruntime与 torch 重建的网络做逐算子对比最大偏差仅6.6e-7float32 舍入级别余弦相似度 1.0确认模型结构与数值还原完全正确。四、选型决策复盘一张表看懂该选哪个引擎这次踩坑的经验完全可以沉淀成一张选型速查表模型类型典型特征推荐推理引擎LLM / VLMTransformer、自回归 token 生成vLLM-Ascend / SGLang经典 RL 策略网络MLP、向量观测 → 连续动作torch_npu其他 PyTorch 模型CNN 等非生成式架构torch_npu判断三步法以后遇到新模型可以照着走看架构是 Transformer 且需要逐 token 生成→ 考虑 vLLM-Ascend是 MLP/CNN 这种判别式结构→ 直接走 torch_npu看算子计算图里有没有 CUDA 独有或 Triton 依赖的算子没有就基本畅通看验证用官方权重如 ONNX做参考实现交叉验证数值对齐才算真正适配成功。五、实战验证50 组测试用例给出答案选型正确与否最终要靠数据说话。项目在inference.py中实现了11 种推理模式info / action / sample / batch / precision / onnx-compare / fingerprint / stats / benchmark / export-onnx 等并跑完了50 组测试用例可用 run_tests.sh 一键重跑性能单步推理平均延迟0.37 msp95 0.40 ms权重加载仅 0.03 秒峰值显存不到 100 MB精度float32 下 NPU 与 CPU 参考的余弦相似度1.0最大绝对误差仅1.1e-6与官方 ONNX 一致确定性同 seed 两次运行的输出逐位一致sha256 指纹校验通过双卡npu:0/npu:1输出也逐位一致发现fp16 精度可接受但bf16 在 910B 上相对误差略超阈值因此生产推荐 float32。另外值得一提的细节ML-Agents 的running_variance是累计和可达 1e5强转 float16 会溢出成 inf 导致归一化 NaN所以脚本强制将归一化统计量保留 float32——这类坑在 AGENT_WORKFLOW.md 的 Step 7 有完整记录。六、快速上手三步在昇腾 NPU 上跑通推理如果你想亲自验证这套选型环境要求是CANN 8.5.1 Ascend 910B Python 3.11然后按下面三步走第 1 步克隆仓库并创建虚拟环境git clone https://gitcode.com/z_studio/ppo-Huggy-NPU cd ppo-Huggy-NPU python3 -m venv --system-site-packages venv第 2 步安装依赖torch / torch-npu 为昇腾系统预置仅需按需安装交叉验证包./venv/bin/pip install -r requirements.txt第 3 步运行推理./venv/bin/python inference.py --mode info ./venv/bin/python inference.py --mode action --obs random --seed 0 ./venv/bin/python inference.py --mode benchmark --runs 200如果看到npu_available True且用例全部SUCCESS说明选型和部署都成功了。结语选型没有最好只有最合适vLLM-Ascend 是优秀的 LLM 推理引擎但它不是万能的。ppo-Huggy-NPU 的这次推理引擎选型决策复盘告诉我们先看清模型类型再选推理引擎。对于强化学习策略网络这类非生成式模型torch_npu 反而是更轻、更快、更正确的选择——单步 0.37 ms 的延迟和 1e-6 级别的精度误差就是最好的证明。希望这份复盘能帮你在下次选型时少走弯路。【免费下载链接】ppo-Huggy-NPU项目地址: https://ai.gitcode.com/z_studio/ppo-Huggy-NPU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考