[Bug]: FP8 MoE models produce corrupted output when serving LoRA adapters

快速结论：此问题发生在 vLLM 使用 FP8 精度（E4M3）的 MoE 模型并同时加载 LoRA 适配器时，模型输出会变成乱码。优先排查是否使用了 FP8 MoE 模型+LoRA 的组合，并检查 vLLM 版本是否低于 0.20.0 或未包含 PR #42120 的修复。

问题场景

用户在 vLLM 0.20.0 上，使用 FP8（E4M3）量化的 MoE 模型（如 Mixtral 8x7B 等），并同时加载 LoRA 适配器进行推理服务时触发。该问题同样可能影响其他基于 Triton 的 MoE+LoRA 推理流程。Issue 作者是在 vLLM 的 main 分支上（而非稳定版）测试修复时发现的。

报错原文

Unsupported lhs dtype

这是当新的一体式 MoE+LoRA Triton 核被触发时的崩溃错误。如果不触发该核，则表现为输出乱码，不会有显式报错。

原因分析

根本原因是 vLLM 的 Triton 内核（位于 vllm/lora/ops/triton_ops/fused_moe_lora_op.py）在处理 FP8 的 MoE + LoRA 时存在两个独立缺陷：

新的一体式 MoE+LoRA 内核（fused_moe_lora_op.py 中的 fused_moe_lora_kernel）：当两个输入矩阵都是 FP8 时，Triton 的 dot 操作会报出 Unsupported lhs dtype 错误，因为它只支持两个矩阵都是 FP8 的场景，但这里 LHS 不是 FP8（具体细节参见代码逻辑）。
旧的 MoE+LoRA 内核或新的小批量 MoE+LoRA 内核：即使不崩溃，也会产生错误的数值结果（乱码），说明在 FP8 量化下的 LoRA 权重计算或合并逻辑有错误。

这两个问题的修复均包含在 PR #42120 中。

环境排查

vLLM 版本：确认版本是否为 0.20.0 或更早。修复已合入 main 分支，预计在下一个发布版本（0.21.0+）中可用。
GPU 型号：通常在 H100/H200 等支持 FP8 加速的 Hopper 架构 GPU 上触发，但也可在其它 GPU 上复现。
Triton 版本：vLLM 0.20.0 自带的 Triton 3.6.0 影响不大，但未来 Triton 版本如果修改了 dot 的行为，可能会改变现象。
FP8 模型格式：确认模型前向计算是否启用了 FP8（E4M3），而非 FP16/BF16。
LoRA 配置：是否同时加载了多个 LoRA 适配器（multi-LoRA）。

解决步骤

升级 vLLM 至包含修复的版本：直接使用 vLLM main 分支（commit 时间晚于 2026-06-23），或者等待下一个正式发布版本（>=0.21.0）。
如果无法升级，作为临时手段，可以尝试：
- 不使用 LoRA 适配器，只使用基础 FP8 MoE 模型，确认基础推理正常。
- 如果真的需要 LoRA，考虑将基础模型降级为 FP16/BF16 精度（但会失去内存节省优势）。
编译或安装包含修复的 vLLM：从源码编译 vLLM main 分支（推荐），或等待官方的 wheel 包更新。

验证方法

使用相同的 FP8 MoE 模型 + LoRA 适配器重新进行推理，检查输出是否与 FP16 基线一致。可编写一个简单的脚本，对比 FP8+LoRA 结果与 FP16+LoRA 结果的差异（如余弦相似度或困惑度）。若之前触发 Unsupported lhs dtype 崩溃，升级后应不再崩溃，并且输出恢复正常。