霜之暗伤不算复杂的排查，但绝对够折腾人。如果你正在昇腾Ascend环境里做多模型推理，尤其是想在910B A2这类服务器上同时跑embedding向量模型和reranker模型，很可能也会撞上这个错误码：100002。单模型推理跑惯了的同事第一反应是Google，但昇腾生态的坑，很多时候网上的答案并不直接。这篇文章我把整个事故现场、错误码含义、排查链路和最终解法完整复盘一遍，希望能帮你少走几小时弯路。适合已经跑通过单模型推理、正准备上多模型并行方案的同学。
1. 事故现场还原：一次本该顺利的多模型联调卡在了初始化
1.1 当时的环境与任务
先说背景。我手上拿到的是一台昇腾910B A2服务器，8卡。任务是把一个RAG检索链路里的两个模型放到同一台机器上做服务化部署：一个是embedding向量模型，负责把文本转成向量；另一个是reranker排序模型，负责对检索结果做精排。部署架构上，我们希望这两个模型能同时对外提供服务，并且如果有余力，后续再把LLM也塞进去，这样一台机器就能撑起完整的"向量化-召回-精排-生成"链路。
软件环境方面，系统是Ubuntu，CANN版本装的8.0.RC1，torch_npu配套版本也确认过匹配，GPU模式下已经跑通过几个模型的单模型推理。昇腾910B A2的驱动固件当时也是官方推荐版本，AI Core、HBM、HCCS链路检查都是正常的。
1.2 报错现场
问题出现在我们用vllm-ascend启动第二个模型的时候。第一个embedding模型启动很顺利，服务起来了，向量化接口也通了。紧接着我在同一个进程里重新初始化了一下运行时上下文去加载reranker模型，结果终端直接甩出来一行错误码：
text复制RuntimeError: aclInit failed, error code: 100002
再往下翻，CANN的plog日志里也留了对应记录。更迷惑的是，这个错误并不是偶发，而是必现。只要第一个模型占住运行时资源之后，第二个模型的初始化几乎必炸。同事问我的第一句话就是："是不是我设备号写错了？"但设备号没错，而且就算把第二个模型放到另一张卡上，一样的报错还是会出现。
1.3 最容易中招的两种代码形态
我在排查过程中顺手把我们自己的代码和其他项目组的代码都翻了一遍，发现容易踩进这个坑的大致是两种写法。
第一种是多个模型加载模块各自调用初始化接口。比如模型A的加载器里调了acl.init()，模型B的加载器里也调acl.init()，两个模块在同一个进程里先后加载，第二次初始化就触发了100002。
第二种是使用vllm、MindIE这类推理框架时，框架内部其实已经初始化过ACL运行时了，但我们的业务代码在某个环节又手动调了一次acl.init()或者torch_npu.npu.set_device()，和框架内部行为撞在一起。单模型时这种写法侥幸没问题，因为框架初始化一次就够了，业务代码补的那一次在同一个模型的生命周期里没有上下文竞争；可一旦多模型同驻，资源状态交互复杂，问题就暴露了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 100002错误码拆解：不是"初始化不了"，而是"重复初始化"
2.1 ACL错误码怎么读
昇腾CANN的ACL（Ascend Computing Language）模块有一套自己的错误码体系。正常情况下，acl.init()返回0代表成功，返回非0值就代表失败。但如果你只看"失败"两个字，会有一种错觉，以为是环境坏了、设备没了、AI Core挂了。实际上错误码本身带着更精确的信息。
我整理了一张常用错误码对照表，方便你遇到报错时快速对照：
| 错误码 | 宏定义 | 含义 |
|---|---|---|
| 100000 | ACL_ERROR_INVALID_PARAM | 参数无效，上一调用的入参不合法 |
| 100001 | ACL_ERROR_UNINITIALIZE | 未初始化，调用接口前没有做初始化动作 |
| 100002 | ACL_ERROR_REPEAT_INITIALIZE | 重复初始化，初始化动作被执行了两次及以上 |
| 100003 | ACL_ERROR_INVALID_DEVICE | 设备类型不合法或设备不可用 |
| 100004 | ACL_ERROR_INVALID_DEVICE_ID | 设备ID超出范围或不存在 |
所以100002对应的就是"重复初始化"，属于初始化阶段失败的一种。它跟设备被占用、显存不足、驱动异常都不是一回事。
2.2 初始化与反初始化的状态机
ACL