Misc. bug: llama server high cpu usage during token generation

快速结论：llama-server 在 token 生成（decode）阶段出现 CPU 占用高、GPU 占用低的现象，通常不是 bug，而是模型加上下文所需显存超出显卡 VRAM 容量，导致权重或 KV Cache 溢出到系统内存所致。优先排查启动日志中模型权重的加载位置，并尝试降低上下文长度（-c）使模型完全载入 VRAM。

适用环境：Linux 与 Windows 11；llama.cpp 版本 8184（319146247），GNU 15.2.1 for Linux x86_64；NVIDIA GeForce RTX 3060 Laptop GPU / RTX 5060 Ti 16GB，CUDA 后端。

最快修复方案：Issue 中报告者已验证有效的方案是将上下文大小降低至 VRAM 可容纳的范围。例如使用 ./llama-server -hf unsloth/Qwen3-VL-2B-Instruct-GGUF -c 29000 -np 3 -cram 2048 --reasoning-budget 0 使整个上下文（及权重）完全载入显存。

注意事项：具体可用的最大上下文长度取决于模型大小、量化方式、KV Cache 量化类型及显卡显存容量，不存在通用数值，需要根据自身硬件通过启动日志观察并调整。此外，该验证来自 RTX 3060 Laptop（具体显存容量未在 Issue 中明确），若你的显存更大或模型更小，数值参考意义有限。

问题场景

用户通过 llama-server 加载 GGUF 量化模型（如 unsloth/Qwen3-4B-GGUF 或 Qwen3-VL-2B-Instruct-GGUF），并配置大上下文（如 -c 40000）及多并行槽位（-np 3）。当同时发送多个推理请求时，在 token 生成（decode）阶段 CPU 占用率持续走高，GPU 利用率反而很低；只有在 prompt 处理阶段 GPU 占用才会拉高。用户观察到 CPU 与 GPU 利用率呈明显交替而非同时高负载，怀疑是否为软件缺陷。

报错原文

Misc. bug: llama server high cpu usage during token generation

During token generation, CPU usage is high, and GPU usage is low. GPU use Is only high during prompt processing.
Is this a bug? I remember GPU usage being high all the time and not alternating between the CPU and GPU.

What causes CPU usage to be high if it's supposedly not generating tokens nor processing prompts?

slot print_timing: id  0 | task 23532 | n_decoded =   1915, tg =  23.74 t/s, tg_3s =  23.86 t/s

原因分析

根据 Issue 维护者的分析，该现象最可能的原因是：模型权重 + 上下文（Context）+ 视觉组件所需的总体显存占用超过了 GPU 可用显存，导致部分权重或缓存被卸载到系统内存（RAM）中。prompt 处理阶段以大批量矩阵运算为主，即使部分数据驻留内存，对整体吞吐影响有限；但 token 生成属于逐步串行 decode，每次仅生成一个 token 都需要在 CPU 与 GPU 之间反复搬运数据或执行 CPU 侧算子，因而 CPU 占用大幅上升、GPU 利用率反而下降。

此外，Issue 中还出现一次“同一会话前半段正常、后半段突然 CPU 拉满”的报告，说明即使是同一配置，长时间的上下文累积（KV Cache 增长）也可能在会话中途逼近显存上限，导致系统开始将缓存换出到内存。这不属于 llama.cpp 本身的代码错误，而是资源规划不足的表现。

环境排查

确认显卡显存总容量（如 nvidia-smi），并对比启动日志中模型加载时报告的总显存占用。
确认 llama.cpp 启动日志中是否存在 offloaded to CPU、CPU buffer size、llama_kv_cache_unified 等显存不足/溢出的提示。
明确模型实际文件名与量化类型（Issue 中同时提及 Qwen3-4B 与 Qwen3-VL-2B，需确认实际使用的模型）。
确认上下文长度 -c、并行槽位 -np、KV Cache 量化（-ctk/-ctv）及是否开启 Flash Attention。
注意 Windows 环境下可能存在 --no-mmap + --mlock 与内存锁定策略的交互问题，需检查任务管理器中的内存占用曲线。

解决步骤

先用 llama-fit-params（或配合 --fit on 参数）让程序仅计算并打印加载参数后退出，观察推荐的上下文长度是否能够将权重完全放入显存。
在启动 llama-server 时查看完整日志输出，重点查找模型权重各层的加载设备分布（GPU vs CPU）以及 KV Cache 的分配位置。
若日志表明存在 CPU offload，逐步降低 -c（上下文长度）的数值，直到 nvidia-smi 显示显存占用保持在显卡容量以内，且启动日志不再提示 CPU buffer 分配。
可优先尝试 Issue 中验证过的配置调整：针对 2B 级别模型在移动版 RTX 3060 上将上下文长度从 40000 降至 29000，同时保持 -np 3 -cram 2048 不变。
若仅在长时间会话中途出现该问题，可尝试缩短单次会话的连续调用长度，或启用 --ctx-checkpoints（若支持）以定期释放过期上下文，防止 KV Cache 在运行中突破显存上限。
若同时运行多个任务/其它占用显存的程序，检查是否存在第三方进程抢占显存导致可用 VRAM 缩水。

验证方法

重启 llama-server 后，在启动日志中确认所有模型层均加载在 GPU（Device 0）而无法 CPU 卸载提示；随后同时发送两个或以上推理请求，观察 btop/任务管理器中 CPU 占用是否回落至正常水平，GPU 利用率在 token 生成阶段是否维持在较高水平，并与 prompt 处理阶段不再出现明显的负载交替。同时对比吞吐指标（t/s）是否回到正常水平（例如不再从 50 t/s 骤降至 20 t/s 左右）。