[安装] 昇腾 NPU 环境下 pip install funasr 可能替换 torch 导致 torch_npu 失效，建议提供对 NPU 友好的安装方式

[Liuzi0816]

环境

• funasr：1.3.14
• torch：2.10.0+cpu / torch_npu：2.10.0（昇腾 Atlas 300I Pro / 310P3，CANN 9.1.0-beta.1）

问题描述

昇腾 NPU 环境要求 torch 使用 CPU 版本，并与 torch_npu 严格配对
（如 torch 2.10.0+cpu + torch_npu 2.10.0）。默认依赖解析安装 funasr 时，
可能拉取/升级通用（CUDA）版 torch，静默破坏这一配对——之后 import torch_npu
会因 C++ 扩展不匹配而失败。

我们目前的规避方式（openEuler 24.03，容器内）：

pip install funasr --no-deps -i <国内镜像>
pip install torch_complex kaldiio omegaconf librosa kaldi-native-fbank
editdistance jieba zhconv tgt umap-learn ... # 手动逐个补齐

这种做法容易出错：不少运行时依赖（kaldiio、omegaconf、torch_complex、
umap-learn、praat-parselmouth 等）很容易遗漏，只在 import 时才报
ModuleNotFoundError。

建议（任一均可）

1. 提供依赖分组，如 pip install "funasr[npu]"（torch 视为环境自带，不强制版本）；
2. 或将依赖声明放宽到"已安装的 torch 不被替换"（避免触发升级的上限约束）；
3. 或补充文档《在昇腾 NPU 上安装》，列出 --no-deps 方式所需的完整运行时依赖清单。

如有需要，我们愿意贡献在 310P3 上实测验证过的完整依赖清单。

[LauraGPT]

感谢报告，这个安装问题需要与 #3708 的 CAM++ 算子兼容问题分开处理。目前还不能把它标为已解决。

我核对了 PyPI 1.3.14 的实际依赖元数据、已安装的正式 1.4.15 元数据，以及 main 的依赖声明：

• 两个版本的基础依赖均没有直接声明 torch 或 torchaudio。因此需要查清是哪条传递依赖、extra 或安装命令触发了替换；这并不否认你遇到的 torch_npu 失效。
• 当前有 knf extra（kaldi-native-fbank），没有 npu extra；增加 extra 本身也不会移除基础依赖。
• docs: 新增《在昇腾 NPU 上运行 FunASR》指南 #3708 当前的 --no-deps 加手工补包清单不能作为完整依赖清单，例如 hydra-core、modelscope、huggingface_hub、safetensors、transformers、tiktoken 等声明依赖并未列出。第二条 pip 命令仍会解析所列包的传递依赖，所以第一条用了 --no-deps 并不保证后续步骤不会改动 torch。

独立检查范围：我现有 Linux/CPU 环境的 FunASR 1.4.15、torch/torchaudio 2.10.0+cpu 通过 pip check；离线 pip install --dry-run --no-index "funasr[knf]==1.4.15" 因该环境未安装、离线源也没有 kaldi-native-fbank 而失败。它不是 NPU 安装通过的证据，也不是对你的原始替换问题的复现；本次没有修改该环境或执行 NPU 推理。

为定位触发链，请一次性补充：

1. 导致替换的完整安装命令（包括 extra、-U、镜像参数；隐藏凭据）以及 pip/Python 版本。
2. 原日志中 Collecting/Installing/Uninstalling torch 附近的依赖链，以及安装前后的 torch、torch_npu、torchaudio 版本。
3. 你提到的已验证依赖清单，注明哪些包由基础镜像预装；最好附 pip check 结果。

若还有未受影响的环境且 pip 支持 dry-run，可先对同一条安装命令追加 --dry-run --report resolve-report.json 保存解析计划，不要为取日志再次执行实际升级；分享前请删去私有索引凭据和敏感路径。下一步根据解析链验证保留厂商 torch 配对的安装方案，不能仅靠一份手写补包清单宣称兼容。