#39555 [NPU] [DOC] delete unsupported models in npu docs

原始 PR 作者 amote-i 合并时间 2026-09-15 14:55 文件变更 1 提交数 1 评论 0 代码增减 +0 / -24

执行摘要

NPU 文档移除 4 个不受支持模型条目

PR 标题与 body 只有一句表述："delete unsupported models in npu docs"，即 NPU 支持矩阵里列出的部分模型在 Ascend NPU 后端上并不受支持，勾选状态与真实能力不符。关联 Issue 为空，PR body 的 Accuracy / Speed / Modifications 三节均为 N/A，说明作者把这次改动定位为文档事实性纠偏，而不是功能或性能变更。由于没有 Issue 或评论解释判定依据，具体是哪些后端限制导致这些模型被判定为「不受支持」在材料中无法确认。

不需要精读。建议只做两件事：一是 NPU 相关使用者快速扫一眼删除清单，确认自己在用的模型是否被从矩阵中摘掉，避免继续按旧版本文档尝试部署；二是关注该文档线后续是否会补充「为什么移除」的依据，或引入更可追溯的支持状态标记（例如区分「已验证 / 社区贡献 / 不支持」），否则纯粹的整行删除会让支持矩阵的维护历史难以回溯。设计决策层面没有值得借鉴的工程技巧，价值主要在于领会「支持矩阵类文档需要可追溯的删改理由」。

讨论亮点

本 PR 没有任何 review 评论（review_comments_count = 0），也没有 Issue 讨论，唯一的审核记录是 sglang-npu-bot 以 APPROVED 状态通过、且 body 为空。因此不存在被讨论或驳回的技术分歧，也不存在关于「某模型到底支不支持」的公开结论记录；判断依据只体现在删除动作本身。

实现拆解

变更入口与范围：唯一改动文件是 docs/docs/hardware-platforms/ascend-npus/reference/support_models.mdx，统计为 +0/-24，属于纯删除，没有新增任何替代说明、注释或 deprecation 提示。仓库其他目录、文档侧边栏、部署脚本均未同步修改。
删除点一（文件中段）：整行移除 LFM2 系列两行——LiquidAI/LFM2.5-1.2B-Instruct（系列列写作 LFM2 230M, 350M, 1.2B）与 LiquidAI/LFM2-8B-A1B（LFM2-MoE 8B-A1B, 24B-A2B）。两行原本都标为 ✅/✅。删除后这两行原先的邻居 ibm-granite/granite-4.0-micro 直接承接上下文，说明是按「单个模型是否被 NPU 支持」逐行判断，而非整段砍掉 LFM2 系列或某种架构类型。
删除点二（文件后段）：同一处删除动作里移除 AI-ModelScope/whisper-large-v3（Whisper，语音分组）与 LiquidAI/LFM2.5-VL-1.6B（LFM2-VL，多模态分组）；夹在两者之间的 Qwen/Qwen3-ASR-1.7B 保留。也就是说语音分组删完后只剩 Qwen3-ASR，多模态分组则继续保留在表尾。
表格契约保持不变：每一行仍是四个 td（模型仓库 / 系列 / 两列硬件可用性），style 内联样式（padding、rgba 背景）逐字未改，因此 Ascend A2/A3 两列勾选语义、表头与排序规则没有变化，读者看到的只是行数减少。这种「只删行、不改 schema」的做法降低了文档渲染回归的风险。
测试与配置配套：没有任何新增测试、配置或部署改动，PR 模板中的 Format / Unit tests / Documentation / Accuracy / Speed 勾选项全部未勾选。PR body 内嵌的 CI 状态显示 Latest PR Test (Base) 通过、Latest PR Test (Extra) 失败（Run #34937749583），AMD ROCm 无运行记录；对于只改 .mdx 的 PR，Base 通过已足以支撑合并，Extra 失败更可能是既有的不稳定任务。

文件	模块	状态	重要度
`docs/docs/hardware-platforms/ascend-npus/reference/support_models.mdx`	NPU 文档	modified	3.29
`docs/docs/hardware-platforms/ascend-npus/reference/support_models.mdx`	NPU 文档	modified	2.89

分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

无 review 讨论，仅机器人批准 other

review_comments_count = 0，comments_count = 0；唯一审核记录来自 sglang-npu-bot，状态为 APPROVED 且 body 为空，没有任何人追问「为什么这些模型不受支持」或要求补充依据。

结论：变更以零争议方式合并，判定依据只存在于删除动作本身；如果后续需要重新支持这些模型，缺少可回溯的说明。 · 已解决

风险与影响

信息丢失与判定依据缺失：删除的 4 个模型没有任何说明性文字（如「暂不支持」「欢迎贡献」），读者只能通过 git 历史反查为什么消失。若某个模型其实只在特定 CANN / torch-npu 版本或特定 Ascend A2/A3 形态下可用，这次删除会把信息抹平；后续若重新支持，需要重新确认系列与硬件列的勾选状态。
文档与实现漂移风险：support_models.mdx 是一份与后端能力人工对齐的矩阵，没有生成或校验机制。本次删除属于单向收缩，未来一旦 NPU 侧补齐 LFM2 / Whisper / LFM2-VL 支持（例如把模型接进 python/sglang/srt/platforms/npu.py 及相关后端路径），文档不会自动回补，容易出现「支持但文档没写」的反向漂移。
相邻条目一致性未复核：删除只集中在两处，同一张表中其他模型行的勾选值未在本次 PR 中复核；如果判定标准是「NPU 后端是否真的跑通」，其余行仍可能存在同类不实勾选，本次改动不完全等于整表校准。
无回归性技术风险：改动不涉及源码、kernel、配置或测试，运行时行为、性能与兼容性零影响；文档站点构建是唯一可能的受影响面。

对用户：影响 Ascend NPU 部署者的选型路径。原先按矩阵勾选去尝试 LFM2 系列、LFM2.5-VL 或 Whisper 的用户会少走弯路，但同时在读文档时无法得知这些模型是完全不支持还是暂时未验证。对系统：无任何运行时影响，不改动调度、KV cache、attention 或 NPU 平台代码。对团队：这是一次低成本的事实纠偏，维护 NPU 支持清单的团队需要承担后续「重新支持后回补文档」的责任；由于只有 24 行删除且 CI Base 已绿，评审与合并成本极低。影响面集中在文档可信度这一维度，程度为轻微但正向。

缺少验证依据记录文档与后端支持可能再次漂移整表未同步复核无测试覆盖（文档变更）

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。

完整报告

[NPU] [DOC] 删除 NPU 文档中不受支持的模型

执行摘要

本 PR 是纯文档清理：在 docs/docs/hardware-platforms/ascend-npus/reference/support_models.mdx 中整行删除 4 个模型条目（共 -24 行、+0 行），把 Ascend NPU 支持模型矩阵里「标着 ✅ 但实际不受支持」的行摘掉。改动不触及任何源码、kernel、测试或配置，运行时零影响；唯一后果是 NPU 用户的选型参考更贴近真实能力，代价是删除理由缺少可追溯记录。

功能与动机

PR 标题与 body 只有一句表述：

delete unsupported models in npu docs

也就是说，Ascend NPU 支持矩阵中列出的部分模型在 NPU 后端上并不受支持，勾选状态与真实能力不符，继续保留会误导部署选型。关联 Issue 列表为空，PR body 的 Modifications / Accuracy Tests / Speed Tests 三节均为 N/A，Checklist 也全部未勾选——作者明确把这次改动定位为事实性纠偏，而非功能或性能变更。

需要标注的不确定性：材料中没有 Issue 或评论解释「为什么这几个模型不受支持」，因此是特定 CANN / torch-npu 版本限制、缺少算子实现，还是仅仅没有验证过，无法确认。

实现拆解

变更入口只有一处：support_models.mdx 这一个 .mdx 文件，两处删除动作，合计 24 行。

删除点一（文件中段）：整行移除 LFM2 系列两行——LiquidAI/LFM2.5-1.2B-Instruct（系列列写作 LFM2 (230M, 350M, 1.2B)）与 LiquidAI/LFM2-8B-A1B（LFM2-MoE (8B-A1B, 24B-A2B)），两行原本都是 ✅ / ✅。删除后，原先紧随其后的 ibm-granite/granite-4.0-micro 直接承接上下文。
删除点二（文件后段）：同一处动作里移除 AI-ModelScope/whisper-large-v3（Whisper，语音分组）与 LiquidAI/LFM2.5-VL-1.6B（LFM2-VL，多模态分组）；夹在两者之间的 Qwen/Qwen3-ASR-1.7B 被保留。也就是说语音分组删完后只剩 Qwen3-ASR，多模态分组条目继续保留在表尾。

被删除行	系列	分组（依据相邻行推断）	删除位置
`LiquidAI/LFM2.5-1.2B-Instruct`	LFM2 (230M, 350M, 1.2B)	通用 LLM 分组	文件中段
`LiquidAI/LFM2-8B-A1B`	LFM2-MoE (8B-A1B, 24B-A2B)	通用 LLM 分组	文件中段
`AI-ModelScope/whisper-large-v3`	Whisper	语音 / ASR 分组	文件后段
`LiquidAI/LFM2.5-VL-1.6B`	LFM2-VL	多模态分组	文件后段

表格契约保持不变：每行仍是四个 td（模型仓库 / 系列 / 两列硬件可用性），内联 style（padding: "9px 12px"、rgba(255,255,255,0.02|0.05) 背景）逐字未改。因此 Ascend A2 / A3 两列的勾选语义、表头与排序规则都没有变化，读者看到的只是行数减少——这种「只删行、不改 schema」的做法有效规避了文档渲染层的回归风险。
判定粒度是单个模型：删除点二里，Whisper 与 LFM2.5-VL 被移除而中间的 Qwen3-ASR 保留，说明作者是按「单模型是否被 NPU 支持」逐行判断，而不是整段砍掉某个系列或某个模态。
测试 / 配置 / 部署配套：无。没有新增测试、配置项或部署脚本改动。PR body 内嵌 CI 状态显示 Latest PR Test (Base) 通过、Latest PR Test (Extra) 在 Run #34937749583 失败，AMD ROCm 无运行记录；对只改 .mdx 的 PR，Base 通过已足以支撑合并，Extra 失败更可能是既有的不稳定任务，但这一点在材料中无法证实。

以下是根据删除点两侧上下文整理的表格片段，用于说明该支持矩阵的契约形态，以及本次删除发生在哪些行之间：

{/* docs/docs/hardware-platforms/ascend-npus/reference/support_models.mdx
   Ascend NPU 支持模型矩阵：<tbody> 中每行代表一个模型条目，
   四个 td 依次为 模型仓库 / 系列 / 两列硬件可用性勾选。
   本次 PR 只做删行，表结构与内联 style 一律不动。 */}

<tbody>
  {/* 删除点 1：LFM2 系列两行被整行摘掉
      - LiquidAI/LFM2.5-1.2B-Instruct（系列 LFM2 230M / 350M / 1.2B）
      - LiquidAI/LFM2-8B-A1B（系列 LFM2-MoE 8B-A1B / 24B-A2B）
      两行原本都是 ✅ / ✅，按 PR 描述它们在 NPU 上其实不受支持，
      保留会直接误导部署选型；删除后 granite-4.0-micro 成为该处相邻行。 */}
  <tr>
    <td style={{padding: "9px 12px", fontWeight: 500, backgroundColor: "rgba(255,255,255,0.02)"}}>ibm-granite/granite-4.0-micro</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.05)"}}>IBM Granite 4.0 (Hybrid, Dense)</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.02)"}}>✅</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.05)"}}>✅</td>
  </tr>

  {/* 语音分组：AI-ModelScope/whisper-large-v3 被移除后，
      该分组只剩下面这一行 Qwen3-ASR；夹在中间的条目被保留，
      说明判定粒度是「单个模型是否被 NPU 支持」，
      而不是整段砍掉某个系列或某个模态。 */}
  <tr>
    <td style={{padding: "9px 12px", fontWeight: 500, backgroundColor: "rgba(255,255,255,0.02)"}}>Qwen/Qwen3-ASR-1.7B</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.05)"}}>Qwen3-ASR (0.6B, 1.7B)</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.02)"}}>✅</td>
    <td style={{padding: "9px 12px", backgroundColor: "rgba(255,255,255,0.05)"}}>✅</td>
  </tr>

  {/* 多模态分组：紧随 Qwen3-ASR 之后、</tbody> 之前的
      LiquidAI/LFM2.5-VL-1.6B（LFM2-VL）也在本次被整行删除，
      与 Whisper 同属后段这一处删除；表格列数与 style 完全未变。 */}
</tbody>

评论区精华

本 PR 没有任何 review 评论（review_comments_count = 0），也没有 Issue 讨论，唯一的审核记录是机器人：

sglang-npu-bot：APPROVED（review body 为空）

因此不存在被讨论、被质疑或需要权衡的技术分歧。反过来看，也没有任何人追问「这几个模型为什么不受支持」「删除依据是什么」——判定依据只存在于删除动作本身。

风险与影响

风险项	说明	严重度
判定依据不可追溯	4 个模型行没有任何说明性文字（如「暂不支持」「未验证」），读者只能靠 git 历史反查消失原因；若某模型只在特定 CANN / torch-npu 版本或特定 A2/A3 形态下可用，这次删除会把信息抹平	中
文档与实现反向漂移	`support_models.mdx` 没有生成或校验机制。本次是单向收缩，未来 NPU 侧补齐 LFM2 / Whisper / LFM2-VL 支持后文档不会自动回补，容易出现「支持但文档没写」	中
整表未同步复核	两处删除共 24 行，但同一张表内其他模型行的勾选值没有一并复核；如果判定标准是「NPU 后端是否真跑通」，其余行可能仍有同类不实勾选	低
运行时回归	不涉及源码、kernel、配置或测试，运行时行为、性能、兼容性零影响	无

影响范围：仅限 Ascend NPU 部署者的选型路径与文档可信度。原先按矩阵去尝试 LFM2 系列、LFM2.5-VL 或 Whisper 的用户会少走弯路；但对系统调度、KV cache、attention、模型加载等模块均无影响。

关联脉络

PR#39389 [NPU][DOC] Rename NPU hardware to Ascend A2/A3 Series product：改动同一 docs/docs/hardware-platforms/ascend-npus/ 文档目录，把硬件称谓统一为 Ascend A2/A3 系列。本 PR 支持矩阵中的两列勾选正对应这两代硬件，二者同属一条「NPU 文档校准」脉络：先统一硬件称谓，再收缩不受支持的模型条目。
PR#39423 [NPU][Bugfix] Disable pinned memory to fix DeepSeek-V2 DP-attention hang：同为近期 NPU 平台方向变更，涉及 python/sglang/srt/platforms/npu.py。这类后端行为调整正是支持矩阵容易与实现脱节的根源，也解释了为什么该文档需要人工持续校正。
- 本次未引用任何 Issue，也没有 follow-up。若要把文档可信度做成机制而不是人工维护，可考虑为支持矩阵引入状态标记（如「已验证 / 社区贡献 / 不支持」），让后续删改自带理由，而不只是行数变化。

#39555 [NPU] [DOC] delete unsupported models in npu docs

执行摘要

NPU 文档移除 4 个不受支持模型条目

实现拆解

评论区精华

风险与影响

关联 Issue

未识别关联 Issue

完整报告

参与讨论