Refactor: Deprecate DIAG_MASK_* operators, migrate kernels to TRI

问题场景

你在编译 llama.cpp / ggml 相关代码，或在基于它构建推理程序时，代码中仍包含旧的 ggml_diag_mask_inf、ggml_diag_mask_zero 等 DIAG_MASK_* 算子调用，触发了弃用告警，或与重构后的头文件、内核签名不匹配而编译失败。该 Issue 正是围绕“弃用 DIAG_MASK_* 算子，并把内核迁移到 TRI”展开。

报错原文

Refactor: Deprecate DIAG_MASK_* operators, migrate kernels to TRI

原因分析

可能原因：旧实现中的 ggml_diag_mask_inf_impl 和 ggml_diag_mask_zero_impl 不再作为独立内核存在，重构方向是让 ggml_diag_mask_* 内部调用 ggml_tri，遇到不支持的情况直接抛错。评论链中确认的映射思路为：ggml_diag_mask_zero 对应 GGML_TRI_TYPE_LOWER_DIAG（n_past == 0）或 GGML_TRI_TYPE_LOWER（n_past == -1）；ggml_diag_mask_inf 对应 GGML_TRI_TYPE_UPPER_DIAG（n_past == 0）或 GGML_TRI_TYPE_UPPER（n_past == 1）。此外，TRI 路径总是创建新张量，传入 inplace == true 会失败；ggml_diag_mask_inf 用 -FLT_MAX 参与加法掩码构造，是因为用 -INF 做乘法类内核会产生 NaN。对于 v1.0.0，讨论倾向于跳过弃用阶段直接移除旧算子。

环境排查

• 确认当前 llama.cpp / ggml 是旧版 v0.x，还是已包含 TRI 迁移或已移除旧算子的版本。
• 检查项目中是否直接调用 ggml_diag_mask_inf、ggml_diag_mask_zero 或引用 DIAG_MASK_* 算子。
• 检查调用处传入的 n_past 值，以及是否使用 inplace = true。
• 检查目标后端（如 CPU、Metal）以及 ggml_tri 对应内核是否在该版本中可用。
• Issue 中未给出可核对的 Python、CUDA、PyTorch、显卡驱动或 WebUI 节点版本，不要据此补充猜测。

解决步骤

1. 在代码库中搜索 DIAG_MASK_ 和 ggml_diag_mask_，找出所有直接调用点。
2. 按讨论中的映射改写为零掩码或无穷掩码的 TRI/FILL 组合：LOWER 侧使用 ggml_tri(ctx, a, GGML_TRI_TYPE_LOWER_DIAG)（n_past == 0）或 GGML_TRI_TYPE_LOWER（n_past == -1）；UPPER 侧使用 GGML_TRI_TYPE_UPPER_DIAG（n_past == 0）或 GGML_TRI_TYPE_UPPER（n_past == 1）。这些函数名和常量以你所用版本的实际头文件为准。
3. 去掉 inplace = true 的使用，改为接收 TRI 返回的新张量；TRI 路径不支持原地写入。
4. 对 n_past 超出上述取值范围的旧调用做显式判断，按讨论允许的方式抛出错误，而不是继续走掩码构造。
5. 如果准备升级到讨论中提到的 v1.0.0 或移除分支，以合入后的版本为准处理旧算子的删除，不要在旧 v0.x 上直接套用。

验证方法

重新编译目标项目，确认不再出现 DIAG_MASK_* 弃用提示或相关符号/签名错误；运行原先依赖掩码的推理或训练路径，检查输出是否出现 NaN，并确认 n_past 为非常规值时按预期报错。讨论中提到 n_past = 0 的掩码在 CPU 上应与旧内核逐位一致，可作为对照验证点。

参考来源

ggml-org/llama.cpp #17654

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。