利益披露：这是我们自己团队的工作。完整坑清单（PITFALLS.md，6 条全量）与复现命令在公开仓库：https://github.com/maidou75293/ltx-ascend-bench （MIT）；前一篇基准实测帖：https://blog.csdn.net/2604_97403603/article/details/170146847
我们在 4x 华为昇腾 910B3 上跑 LTX-2.5-22B 视频生成（PyTorch 2.10 + torch_npu + CANN 9.1.0），40+ 组配置实测。最大的教训不是崩溃，而是静默错误：程序不报错、结果全错。## 一、三个坑速览| # | 坑 | 症状 | 根因 | 一句话修法 ||—|—|—|—|—|| 1 | 空 match mapping 丢权重 | 加载零报错，输出纯噪点 | state_dict 全部停在 meta 设备，加载器不视为错误 | 加载后断言参数真在卡上 || 2 | cache_weights 语义反转 | 两 stage 共卡直接 OOM | 该 flag 实际缓存在显存，与文档相反 | 共卡场景显式关闭 || 3 | HCCL 端口冲突 | 通信「变慢」不报错 | 两任务共享端口段，只排队不抛异常 | 每任务钉死端口段+预检 |## 二、坑一：空 match mapping 静默丢弃全部权重症状：模型加载零报错、流程跑通，但输出是纯噪点视频。你去调试下游采样/VAE，越查越远。根因：自定义加载路径的 SDops 用空 match mapping 构建时，没有任何张量真正落卡——全部停在 meta 设备，加载器却不认为这是错误。修法（固化成回归金丝雀）：python# 加载完成后立刻断言dev = next(model.parameters()).deviceassert dev.type == "npu", f"weights parked on {dev}!"# 关键张量 checksum 抽查def load_hook(m, s): for n, p in m.named_parameters(): assert p.numel() > 0 and not p.is_meta, nmodel._load_state_dict_post_hooks.append(load_hook)## 三、坑二：cache_weights=True 缓存到显存而不是内存症状：文档写「缓存权重」，直觉是省显存；实际两个 stage 共享一张卡时直接 OOM。根因：实现把权重缓存在加速卡显存，语义与文档相反。修法：多 stage 共卡时显式关掉；选型阶段用 npu-smi info 实测两 stage 并存显存水位，别信文档。## 四、坑三：HCCL 基础端口冲突 = 延迟翻倍而非报错症状：多任务并发时集合通信整体吞吐约腰斩，所有调用正常返回。你以为是硬件或框架慢。根因：两个任务共享 HCCL 端口段，冲突不抛异常，只是重传/排队；且只在第二个服务惰性建通信组时触发——距启动已几分钟，远离真正根因。修法：bash# 每个任务显式钉死端口段，启动前预检export HCCL_CONNECT_TIMEOUT=1200# CI 设超时，让「通过但劣化」不会伪装成性能玄学## 五、通用原则这三类坑的共同点：失败模式是静默的。移植到任何非 CUDA 后端时，把「无错误」当作需要额外证明的结论，而不是默认结论：1. 每个加载路径加断言（参数在卡上 + checksum）2. 每个通信配置显式钉死端口与超时3. 每次性能异常先查资源冲突，再查代码其余 3 个坑（含注意力掩码极性翻转、NTP 时钟扭曲基准测试等）见仓库 PITFALLS.md。