Eval bug: DeepSeek-V4-Flash lightning-indexer materialises a ctx-proportional (4 GiB/layer) score buffer

快速结论：此问题发生在使用 llama.cpp 加载 DeepSeek-V4-Flash 模型，并设置大上下文窗口（如 –ctx-size 131072）时。系统内存（RSS）异常增长约 38-40 GiB，根本原因是 lightning-indexer 的 score 缓冲区未使用融合算子，导致每个 CSA 层都物化了完整的 [n_kv x n_indexer_head x n_tokens] 分数矩阵（约 4 GiB/层）。优先排查是否使用了支持 ggml_lightning_indexer 融合算子的构建版本。

问题场景

用户使用 llama-cli 或 llama-server 加载 DeepSeek-V4-Flash（DSV4-Flash）模型，GGUF 格式，MXFP4 量化，5 分片。在设置 --ctx-size 131072、启用 --flash-attn on 和 MoE expert-offload（--fit）时触发。多 GPU 环境（5x NVIDIA GPU, 96 GiB 总显存），对比旧版本（fairydreaming 分支）发现主机内存（RSS）从 71 GiB 增长至约 110 GiB。

报错原文

# Load-time host RSS at /health OK, ctx 131072, identical llama-server flags.
# RSS = VmRSS from /proc//status. VRAM = per-device used at load (MiB, 5 GPUs).

be00e7771  v9854  old fairydreaming base
  RSS  = 71 GiB
  VRAM = 22079 22686 13163 13265 13160 MiB   (total ~82 GiB)

90e0f5cfc  v9924  clean current master
  RSS  = 110.5 GiB

# GGML_SCHED_DEBUG=2 shows:
ctx 131072:  lid_kq-2 .. lid_kq-42  = 4096 MiB each   (x21 CSA layers)
ctx  16384:  lid_kq-*               =  512 MiB each

原因分析

根本原因：master 分支缺少 ggml_lightning_indexer 融合算子。在 build_lid_top_k() 函数中，fairydreaming 分支使用融合算子 ggml_lightning_indexer 流式计算 indexer score，不会物化完整的中间矩阵。而 master 分支使用未融合的 fallback 路径：

先执行 ggml_mul_mat(indexer_k, indexer_q) 生成 lid_kq，这是一个形状为 [n_kv x n_indexer_head x n_tokens] 的全尺寸分数矩阵。
每个 CSA 层此矩阵大小为 4 GiB（ctz 131072 时），21 个 CSA 层总计约 84 GiB 的 compute buffer（但实际调度中按设备总和约 55 GiB）。
接着进行 relu、mul、sum_rows 操作后只选取 top-512，但中间结果没有被优化掉。

内存增长的传导机制：在多 GPU + MoE expert-offload 环境下，过大的 compute buffer 占用了显存，offloader 被迫将更多 expert 权重推送到系统 RAM，导致主机 RSS 增长。在无 CPU offload 的环境下，同样的 buffer 会直接导致显存不足（OOM）。

环境排查

llama.cpp 版本：master 分支 90e0f5cfc (v9924) 及以上版本（包含 DeepSeek-V4 支持，通过 #24162 合并）
模型：DeepSeek-V4-Flash，GGUF 格式，MXFP4 量化
硬件：多 GPU 环境（2x RTX 3090, RTX 5060 Ti, 2x RTX 4060 Ti），96 GiB 总显存；128 GB 系统 RAM
操作系统：Linux x86_64 (Ubuntu 24.04)
关键配置：--ctx-size 131072，--flash-attn on，--fit on（启用 MoE expert-offload）

解决步骤

确认问题是否与构建版本相关：使用 ggml_sched_debug=2 环境变量运行，观察计算图张量大小。如果看到多个 lid_kq-* 张量（如 4096 MiB each），则确认问题存在。
可优先尝试：切换到支持 GGML_OP_LIGHTNING_INDEXER 融合算子的分支（如 fairydreaming 的 DSV4 分支，提交 be00e7771）。该分支使用 ggml_lightning_indexer 流式计算，compute buffer 仅约 5 GiB（图节点约 9.6k 个，对比 master 的 33.7k 个）。
等待上游修复：根本解决方案是 master 分支实现 ggml_lightning_indexer 融合算子（包括 GGML_OP_LIGHTNING_INDEXER 枚举、ggml.c 创建函数、CPU 内核和 CUDA 内核）。目前 master 分支完全没有此 op，需要社区贡献。
临时缓解措施：如果无法切换分支，可以减小 --ctx-size 值。从数据来看，ctx 16384 时每个 lid_kq 仅为 512 MiB，compute buffer 总计约 17 GiB；ctx 131072 时则达到 55 GiB。

验证方法

使用 ggml_sched_debug=2 环境变量运行 llama-server 或 llama-cli，观察计算图张量列表。如果不再出现 lid_kq-* 张量，或者出现了 GGML_OP_LIGHTNING_INDEXER 节点，说明修复生效。此外，比较修复前后的 RSS 和 compute buffer 大小：修复后 compute buffer（按设备总和）应显著下降，且主机 RSS 增长模式（约 0.34 MiB/token）不再出现。