[ROCm][AMD] Kimi-K3 Gap and Roadmap Tracking

快速结论：这不是一个单一报错，而是 Kimi-K3 在 ROCm/AMD 上做 Day 0 支持时的特性缺口与性能跟踪条目，常见于 MI355X/MI350（gfx950）与 MI300（gfx942）上的 vLLM 部署场景。优先排查方向是 fp8 kv-cache-dtype、AITER/Triton 版本、model runner V2 开关，以及 DSpark 推测解码与长上下文多轮负载下的崩溃问题。

适用环境：Issue 已确认涉及 vLLM、ROCm、AITER、Triton 3.6/3.7、gfx950（MI350/MI355X）与 gfx942（MI300），Day 0 镜像为 vllm/vllm-openai-rocm:kimi-k3，并提到 ROCm 7.14+ 用于 CPU offloading。Python、CUDA、PyTorch 的具体版本未在本 Issue 中确认。

最快修复方案：暂无确认的一步修复方案。该 Issue 本身是路线图跟踪，未给出“改一个参数即可恢复”的已验证做法。

注意事项：已勾选的条目（如 DSpark prefix-caching、#51653）只代表对应子项完成，不代表 Kimi-K3 在 ROCm 上的全部缺口已闭合；评论中提到的补丁多为本地未提交或待审 PR，不能当作已发布修复使用。

问题场景

用户在 AMD ROCm 环境用 vLLM 部署 Kimi-K3（MoonshotAI），并在 MI355X/MI350（gfx950）或 MI300（gfx942）上做推理、多节点分布式推理或推测解码（DSpark）。触发问题的具体场景包括：启用 fp8 kv-cache-dtype 以缓解 AgentX 性能下降、需要在 gfx950 上做多机扩展、在 gfx942 上做分布式推理，以及 DSpark 推测解码在长上下文多轮 Agent 负载下的表现与稳定性。

报错原文

[ROCm][AMD] Kimi-K3 Gap and Roadmap Tracking
dspark does not work on mi300+pp either which is the optimal theortical pareto parallelism
on realistic long context multi turn workloads, K3 vllm on mi355 crashes even tho the same workload and trace ordering does not crash b300

原因分析

按 Issue 讨论，可能原因分为几类：

特性缺口：Kimi-K3 的 fp8 kv-cache-dtype 在 asm-mla 与 gluon-mla 两条路径上仍在补齐，缺失时会带来 AgentX 场景的性能退化。
平台支持缺口：gfx950 多节点分布式推理、gfx942 支持与分布式推理尚未完成，因此 MI300 上 DSpark 与 PP 组合无法工作。
依赖版本：ROCm 基础镜像中 AITER 需要升级到 v0.1.19+，Triton 需要从 3.6 升到 3.7+，且 Triton 3.7.x 与 gluon MLA 内核在 DistributedLinearLayout 上存在待解决问题。
model runner V2 被禁用，V2 与 V1 之间的性能差距仍在评估。
精度问题：评论指出 Kimi-K3 MoE 的 e_score_correction_bias 被以环境默认 BF16 分配，导致 FP32 权重在加载时被截断精度；这属于可能影响数值质量的独立问题，与崩溃问题未必同源。
MI355 上长上下文多轮负载崩溃、而 B300 同负载不崩溃，Issue 未给出根因，需要结合 #50347 单独排查。

环境排查

确认 vLLM 版本是否为 Day 0 对应上游 PR（#50000、#50089、#50090）之后的构建，或直接使用 vllm/vllm-openai-rocm:kimi-k3 镜像。
确认 ROCm 基础镜像中的 AITER 版本是否达到 v0.1.19+；CPU offloading 场景需 ROCm 7.14 及以上。
确认 Triton 版本为 3.6 还是 3.7+，以及是否包含针对 gluon MLA 分布式布局的修复。
确认显卡架构：gfx950（MI350/MI355X）与 gfx942（MI300）的支持状态不同。
确认是否启用 DSpark 推测解码、目标模型是否走 AITER MLA（gluon）、草稿模型是否走 TRITON_MLA。
确认 kv-cache-dtype 是否为 fp8，以及走的是 asm-mla 还是 gluon-mla 路径。
确认 model runner 是 V1 还是 V2。

解决步骤

先对齐 Day 0 基线：使用 vllm/vllm-openai-rocm:kimi-k3 镜像，并参照 recipes 页面（https://recipes.vllm.ai/moonshotai/Kimi-K3?hardware=mi355x&features=reasoning）的参数配置，排除自定义参数引入的偏差。
在 gfx950 上若需要多机扩展，检查 #51052 对应改动是否已进入所用构建；未合入前该能力属于已知缺口。
需要 fp8 kv-cache-dtype 时，按所用 MLA 路径核对对应 PR 状态：#51040、#51011 对应 asm-mla，#50619 对应 gluon-mla。若内核不支持，先回退到非 fp8 kv cache 观察是否恢复。
升级依赖：按 #49361 将基础镜像的 AITER 升级到 v0.1.19+；按 #50607 升级 Triton 到 3.7+，并注意 #51464 用于选取包含 DistributedLinearLayout 修复的新提交。
DSpark 场景下先确认 prefix-caching 相关内容（ROCm/aiter #4474）已就绪，再排查推测解码本身的问题。
gfx942 或 MI300 上，若 DSpark 与 PP 组合不可用，检查 #50817 是否已在构建中；在此之前可优先尝试不使用 PP 的配置。
排除 model runner V2 干扰：确认 #51653 状态，必要时切回 V1 对比，以判断问题是否来自 V2。
若怀疑数值精度问题，可优先尝试核对 e_score_correction_bias 是否以 FP32 分配（评论中给出的是未合入的本地提交，需自行控制风险）。
MI355 长上下文多轮崩溃按 #50347 单独追踪，该问题在本 Issue 中没有给出结论性修复。

验证方法

针对具体子项分别验证：fp8 kv-cache 通过对比开启/关闭时 AgentX 类负载的吞吐与延迟；分布式推理通过多节点 TP 运行与单节点结果一致性判断；DSpark 通过在低并发（c1–c16）与 Agent 工作流下对比启用/不启用推测解码的性能；精度改动通过 GSM8K 等固定评测集做 A/B 对比。Issue 中的 GSM8K 结果（1319 题、five-shot greedy）显示 FP32 bias 候选方案为 1281/1319，基线为 1277/1319，评论同时说明该差异低于一个标准误，不能视为统计显著的提升。崩溃类问题需以长上下文多轮负载能否稳定复现不崩作为验收标准。