Misc. bug: Very slow prompt cache update process.

快速结论：该问题在 llama.cpp 的 llama-server 场景下触发，表现为 prompt cache update 耗时从正常几十毫秒飙升至数十甚至上百秒（如 86s / 113s），同时其他正在生成 token 的 slot 吞吐率骤降至接近 0。优先排查：--cache-ram 设置与大容量 host-memory cache 交互时的回写/比较路径，尤其在使用混合/类注意力架构模型（如 GLM、Qwen3.5-MoE Hybrid DeltaNet）时。已知 b8185 版本之后该问题未复现，假定已修复。

问题场景

用户运行 llama-server 作为后端服务（服务 OpenCode 等前端），使用 --cache-ram （如 16384 或 65536 MB）及 --kv-unified、--parallel、--cache-reuse 等配置。当出现多 agent / sub-agent 并发或多轮对话、导致 prompt cache 需要 “found better prompt with f_keep=…, sim=…”（复用覆盖已有 cache 条目而非新建）时，该 update 操作耗时异常。

触发模型包括 GLM-4.7-Flash-UD 以及 Qwen3.5-MoE Hybrid (Gated DeltaNet + sparse full-attention) 架构。

报错原文

[09:55] - found better prompt with f_keep = 0.998, sim = 0.998
[11:22] - cache state: 1 prompts, 500.751 MiB (limits: 65536.000 MiB, 425984 tokens, 2350391 est)
[11:22] prompt cache update took 86642.04 ms
[11:22]  0 | 5816 | n_decoded =   4061, tg =  26.95 t/s, tg_3s =   0.22 t/s   <-- other slot stalls during this window

Another instance:
[12:55] - looking for better prompt, base f_keep = -1.000, sim = 0.000
[12:55] prompt cache update took 113333.71 ms

正常场景下日志对比（耗时仅 62 ms 或 107 ms）：

[65323] srv  get_availabl: prompt cache update took 62.04 ms
[65323] srv  get_availabl: prompt cache update took 107.91 ms

原因分析

可能原因：在 --cache-ram 启用 host-memory prompt cache（由 PR #16391 引入）并执行“复用覆盖 cache 条目”操作时，对包含混合/类注意力结构（如 Gated DeltaNet、SSM、或者 GLM 架构）的模型，其 state recovery/comparison 路径走的是慢分支。服务器日志中出现：

the context does not support partial sequence removal
forcing full prompt re-processing?

这一提示表明对于不支持部分序列删除的模型（通常为 recurrent / hybrid 架构），cache 更新时会强制全量重处理，从而耗时会从毫秒级变为数十秒到分钟级。cache 大小或 prompt 长度与延迟不成线性关系，匹配原始报告。

注意：原报告在升级到 b8185 后该问题消失，因此主流版本极有可能已修复。Qwen3.5-MoE 报告在 ~b9930 期仍然命中，可能需要在后续构建中验证是否彻底修复。

环境排查

llama.cpp 版本：b8157（原始报告）至 ~b9930（Qwen35 报告），以及最新版本。
后端：ROCm (AMD RX 7900 XTX, gfx1100) 或 CUDA（如 2x GPU: RTX 3090 + RTX A5000，--split-mode tensor）。
模型架构：GLM-4.5/4.7；Qwen3.5-MoE Hybrid (Gated DeltaNet + sparse attention)。
启动参数中：--cache-ram（如 16384 / 65536 MB）、--kv-unified、--parallel、--cache-reuse（需注意 multimodal 模式会禁用 cache-reuse）。
关键 server 日志标志：若看到 the context does not support partial sequence removal，则高度相关。

解决步骤

升级到最新版本：原报告在 b8185 后未复现。优先升级到最近稳定版本。
验证修复情况：使用与之前相同的模型和 --cache-ram 设置，启动 llama-server，并触发多 agent 场景（或模拟多个并发会话），观察 prompt cache update 日志，确认耗时不再异常。
临时绕过（workaround）：如果无法升级，或升级后仍然遇到（如 ~b9930 报告），可以设置 --cache-ram 0 禁用 host-memory prompt cache。这将避免该慢路径，但代价是无法实现跨 agent/sub-agent 的 prompt reuse。
确认是否被 multimodal 模式影响：如果使用 --mmproj，注意 --cache-reuse 会自动禁用，可能并非问题原因。
针对 hybrid/recurrent 模型特别排查：检查服务器启动时是否打印 the context does not support partial sequence removal，以及 ckeckpoint 不匹配时是否强制 full re-processing。

验证方法

启动 llama-server 后，在多个并发 agent/会话中发送请求，观察 server 日志中 prompt cache update took 字段。正常应保持在亚秒级（ 60000 ms）且伴随其他 slot 停滞，则问题未解决。可对比设置 --cache-ram 0 前后的耗时差异。