Fallback 路径：VLLM_BATCH_INVARIANT=1 详细解释

先一句话概括：

昇腾 vLLM 里，VLLM_BATCH_INVARIANT=1 就是强制不走昇腾专项优化的自定义Ascend C算子，全部走框架原生通用实现（CANN基础算子/ATC编译通用kernel）；它牺牲吞吐、延迟这些性能指标，换来数值计算上更贴近GPU、更贴近HF transformers的FP32参考值，浮点噪声更小、结果稳定。

下面拆开讲：背景、原理、和Custom OP路径对比、什么时候用、优缺点、在你这个测试里的价值。

1. 背景：为什么会有两条路径？

vLLM-Ascend 为了跑快，针对LLM里高频计算（RMSNorm、Silu、Add、Matmul、Reshape、Pooling等）手写了昇腾自定义Ascend C算子（Custom OP）：

• 优势：充分利用昇腾NPU的Vector单元、Cube单元、流水线、分块调度，算力利用率高，推理性能好
• 代价：手写算子做了很多工程优化（重排计算顺序、分块累加、中间结果用bf16截断、拆分求和）。浮点运算顺序一变，浮点舍入误差就和PyTorch/HF原生不一样；边界样本上概率漂移会更大（也就是你前面置信度分层要处理的问题）

浮点数特点：加法不满足结合律。(a+b)+c ≠ a+(b+c)。同样的数学公式，计算顺序不同，bf16下结果就有差异。
HF Transformers是标准PyTorch实现，计算顺序固定，是你的真值基准。

于是社区增加了环境变量开关：

export VLLM_BATCH_INVARIANT=1

作用：禁用这批手写Custom OP，回退到CANN原生通用算子实现。

2. Fallback路径内部是怎么跑的？

当开启 VLLM_BATCH_INVARIANT=1：

1. vLLM算子注册层判断这个开关，遇到有自定义Ascend C实现的算子，跳过自定义kernel
2. 改用CANN原生算子库（比如 te 算子 / ATC自动编译生成的通用kernel）
3. 计算逻辑、求和顺序、规约顺序，尽量对齐PyTorch原生的实现逻辑
4. 中间张量的截断、精度保存策略更保守，不会为了速度随意合并计算步骤

Batch invariant 字面意思：批不变性
含义：同一个样本，单独跑（batch_size=1），或者放到大batch里面一起跑，输出的数值结果应该基本一样。

• 关闭（默认0，custom op）：很多自定义kernel为了并行分块加速，规约顺序随batch分片变化 → 同一样本，在不同batch里概率会飘，不满足batch invariant
• 开启（=1，fallback）：保证规约顺序固定，同一样本不管在多大batch里，输出概率几乎不变，满足batch不变性

👉 这个名字的由来非常关键，答辩可以说：
这个开关叫 Batch Invariant，目标就是消除batch分片带来的数值漂移，让单样本和batch内样本输出一致，方便精度对齐验证。

3. 两条路径对比（重点）

4. 在你这套Qwen分类对齐测试里，它的作用（贴合你的项目）

你的测试同时跑两条路径，用来做根因判断，这个是你方案里很重要的排查手段：

1. 如果：Custom OP失败，但是Fallback路径校验可以通过
   → 结论：bug/误差来源就是昇腾手写自定义算子的浮点规约、计算顺序引入的偏差，模型上层逻辑没问题。反馈给算子开发同学优化算子精度。
2. 如果：Custom OP 和 Fallback 两条路径全都校验失败（标签错或者概率大幅超标）
   → 结论：问题不在自定义算子，而是vLLM上层逻辑：比如取错last token、pooling逻辑、分类头加载、logit后处理代码写错。属于模型适配层面bug。
3. 边界低置信样本，你可以用fallback看：这个样本本身是不是天然敏感，还是custom op额外放大了误差。

通俗讲：Fallback 相当于一把“尺子”。
尺子本身更准、但是量起来慢；生产的custom op是一把快尺子，但刻度会有一点点偏移。

5. 局限和坑（答辩加分点，体现你理解深度）

1. 只是对齐PyTorch数值行为，不等于完全和FP32一模一样。vLLM仍然用bf16推理，和HF fp32之间本身就存在bf16固有舍入误差，只是误差更小；
2. 性能下降是明显代价：大batch吞吐可能下降不少，绝对不能直接线上业务打开这个开关，它只用于验证、调试；
3. 不是所有算子都回退：只是那些有batch分片规约优化的自定义算子走fallback，Matmul等基础矩阵计算依然走CANN Cube优化；
4. 它只能排查“自定义算子带来的数值漂移”，不能修复模型本身的缺陷。