llama-server报错引出的三层缓存理解

在做llama-server压测中遇到高并发与大上下文不能推理直接崩溃问题：

 .\llama-server.exe  -m C:\……models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf --host 0.0.0.0 --port 8080  -ctk q4_0 -ctv q4_0 -ngl 999   -a Qwen3.6-35B  -np 32 -c 4500000
0.52.356.143 I slot get_availabl: id 31 | task -1 | selected slot by LRU, t_last = -1
0.52.356.191 I slot launch_slot_: id 31 | task 0 | processing task, is_child = 0
0.56.729.005 I slot print_timing: id 31 | task 0 | n_gen =    179, tg =  59.11 t/s, tg_3s =  59.44 t/s
0.56.866.037 I slot print_timing: id 31 | task 0 | prompt eval time =    1361.68 ms /    11 tokens (  123.79 ms per token,     8.08 tokens per second)
0.56.866.051 I slot print_timing: id 31 | task 0 |        eval time =    3148.22 ms /   187 tokens (   16.93 ms per token,    59.08 tokens per second)
0.56.866.052 I slot print_timing: id 31 | task 0 |       total time =    4509.90 ms /   198 tokens
0.56.866.053 I slot print_timing: id 31 | task 0 |    graphs reused =        186
0.56.866.079 I slot      release: id 31 | task 0 | stop processing: n_tokens = 197, truncated = 0
0.57.834.622 I slot get_availabl: id 30 | task -1 | selected slot by LRU, t_last = -1
0.57.834.674 I slot launch_slot_: id 30 | task 189 | processing task, is_child = 0
D:/a/llama.cpp/llama.cpp/ggml/src/ggml-backend.cpp:359: GGML_ASSERT(tensor->data != NULL && "tensor not allocated") failed

 压测指令 evalscope perf   --api openai   --model qwen3.6-35b-q4   --url http://127.0.0.1:8080/v1   --tokenizer-path /……/Qwen/Qwen3.6-35B-A3B   --dataset random   --min-prompt-length 512 --max-prompt-length 1024   --min-tokens 1024 --max-tokens 2048   --prefix-length 0   --parallel 1 2 4 8 16 32   --number 4 8 16 32 64 128   --warmup-num 8   --stream   --duration 300   --visualizer wandb   --name single-short-in-long-out   --wandb-api-key wandb_v1_Qn6P6W29imIJ836NidR

原因：llama-server 自身在多 slot 场景下做 KV-cache / prompt-cache 状态序列化时，读到了一个从未被分配的 tensor，触发 GGML_ASSERT直接 abort 进程。

日志看时序很清晰：

1. slot 31 正常完成了 task 0 的生成（59 t/s，198 tokens），说明模型加载、warmup、首次推理都没问题；
2. 随后 LRU 选中 slot 30、launch task 189，还没来得及输出任何 timing 就立刻崩了；
3. 崩溃点 ggml-backend.cpp:359: GGML_ASSERT(tensor->data != NULL && "tensor not allocated")，这行代码位于 ggml_backend_tensor_get/put，是在读写某个 KV-cache tensor 的数据时发现该 tensor 根本没被分配过。

关联issue：https://github.com/ggml-org/llama.cpp/issues/26128 。

llama-server 的 prompt cache 在做 slot 状态保存时走 server_slot::prompt_save()→ llama_context::state_seq_get_data()→ ggml_backend_tensor_get()这条序列化路径，而这条路径假设 KV tensor 在主机内存里有直接的 data 指针。当 KV tensor 落在 RPC 后端（无本地指针）这类"非平凡"后端 buffer 上时，assert 在 buf->iface.get_tensor()（本可以正确处理远端 tensor 的接口）被调用之前就先炸了。

触发条件与你的日志完全对得上：issue 明确说 -np = 1时潜伏不炸（没有 idle slot 可保存、对话永远命中自己的 slot），-np ≥ 2 时只要有新任务在其它 slot 空闲时进来就立刻 abort。它还列出了两个调用点：LRU 换占 slot 时（get_available_slot()）和每个新任务对所有 idle slot 做缓存保存时（process_single_task()）。本地日志里 slot 30 被 LRU 选中、launch task 189 即崩，就是这个模式的翻版。

处理方法：

• --cache-ram 0 完全禁用 prompt cache，崩溃消失，作者在并发负载下验证稳定；我验证也是可用的。
• 另外一种方式是把--np 改16 也是可以正常运行的。
• 两个重要澄清：--no-cache-prompt 无效（server prompt cache 是独立机制）；--no-cache-idle-slots 只能去掉一个调用点，LRU 路径仍在，不够。
• 关键安慰：slot 内的前缀复用不受 --cache-ram 0影响（实测后续轮次 cache_n=53仍命中），server prompt cache 只在"会话数 > slot 数"时才有收益，对你 32 slot、每 slot 独立请求的压测场景本来就是零收益。

引出--cache-ram 参数，它控制的是 server 的“跨 slot prompt cache”（RAM 侧 KV 状态存档）预算，0 表示完全关闭这套机制；它是独立于 slot 内前缀复用和 --no-cache-prompt的第三个缓存层。

引出了三层缓存机制：

--cache-ram 的8192 MiB预算同时服务第二、三层两个机制，设置 --cache-ram 0会同时禁用检查点创建和跨slot缓存。

需要详细解释的第三层是llama.cpp的上下文检查点系统，用于处理长上下文和上下文移场景。它通过定期保存KV状态的"部分快照"来避免完全重新处理长提示。

第三层检查点参数

实际应用场景

1. 长上下文处理：当上下文超过模型限制时，通过检查点移，避免完全重新处理
2. 代理工具调用：在本地编码代理等场景中，工具调用后恢复状态，大幅减少冗余计算
3. 混合注意力模型：对Qwen3.5等具有滑动窗口注意力的模型特别有用

第三层是缓存“不可重建的中间状态”

在llama.cpp的上下文检查点系统中，“不可重建的中间状态”是指那些无法通过简单截断KV cache来恢复的模型内部状态。

两种典型不可重建状态

A. 滑动窗口注意力（SWA）的KV Cache

对于采用SWA的模型（如Qwen3.6、Mistral），每个注意力层只维护一个固定大小的“窗口”，窗口外的token的KV会被丢弃。

SWA（滑动窗口注意力）机制：

• 不是“压缩+新内容保留”，而是维护固定大小的窗口
• 当处理新Token时，窗口外的最旧Token的KV会被永久丢弃
• 窗口内的Token可能包含新Token和部分旧Token

B. 递归层的运行状态（如Mamba、RWKV）

对于Mamba、RWKV等状态空间模型，它们不存储每个token的KV，而是维护一个单一的“运行状态”，这个状态在每个token处理时都会被原地更新。

递归模型（如Mamba）机制：

• 没有独立的KV对，而是维护一个单一的运行状态
• 这个状态在每个Token处理时都会被原地更新（覆盖）

检查点设计的主要目标。当处理一个长prompt后，后续请求如果与之前的对话有共同前缀，server会尝试找到匹配的检查点，恢复到某个中间状态，只计算新增的token。

典型场景：多轮对话中，用户发送新请求（包含之前所有对话历史+新问题）。如果没有检查点，server需要重新处理整个对话历史；有了检查点，可以恢复到之前某个状态，只处理新问题部分。