Misc. bug: mmproj memory margin is added twice on resume from sleep, causing CPU offload

快速结论：该报错通常出现在 llama-server 加载带 mmproj 的多模态模型、启用休眠（sleep）后再次唤醒的场景：休眠恢复时会重新执行 load_model，并把 mmproj 的内存余量重复加进 fit 目标，导致部分层被调到 CPU、生成速度下降。核心报错为 Misc. bug: mmproj memory margin is added twice on resume from sleep, causing CPU offload，优先排查休眠恢复路径与内存适配（memory-fit）逻辑。

适用环境：Issue 已确认：llama.cpp version 10217（ddd4ec142），GNU 14.2.0，Linux x86_64，GPU 为 NVIDIA RTX 5070 Ti（CUDA）；另外有用户在 b10639 复现，模型包括 Qwen3.6-27B-UD-IQ3_XXS、Qwen3.8-27B-UD-Q4_K_XL、unsloth/Qwen3.5-9B-GGUF:Q4_K_XL。Python、PyTorch、CUDA 具体版本 Issue 未提供。

最快修复方案：暂无确认的一步修复方案（Issue 中的根因代码修改未被验证合并）。可优先尝试 Issue 中给出的规避方式：启动 llama-server 时加 –fit off 或 –fit-target 0，关闭休眠恢复时的内存适配逻辑。

注意事项：–fit off / –fit-target 0 是规避而非修复，会禁用整体的自动内存适配，显存吃紧时可能引发其他加载问题；另有用户反馈设置 –no-mmproj 可绕过该问题，但会失去多模态能力；若改用 Open-WebUI 显式卸载模型而非依赖 llama.cpp 自动休眠，也有用户表示可规避。

问题场景

用户用 llama-server 加载带 mmproj 的多模态 GGUF 模型（如 Qwen 系列 + mmproj-BF16.gguf），并通过 –mmproj 提供视觉/多模态支持，同时启用 sleep。首次冷启动时模型完全正确放入 GPU；空闲超时进入 sleeping state 后，新请求唤醒服务器，日志显示恢复加载时 n_gpu_layers 减少，部分层被 offload 到 CPU，tok/s 明显下降。Issue 标题即 “Misc. bug: mmproj memory margin is added twice on resume from sleep, causing CPU offload”。

报错原文

srv  handle_sleep: server is entering sleeping state
srv  handle_sleep: server is exiting sleeping state
srv    load_model: [mtmd] estimated worst-case memory usage of mmproj is 1161.02 MiB
common_params_fit_impl: projected to use 12322 MiB of device memory vs. 14805 MiB of free device memory
common_params_fit_impl: cannot meet free memory target of 3296 MiB, need to reduce device memory by 813 MiB
common_params_fit_impl: id=0, n_layer=59, n_part= 0, overflow_type=4, mem= 11340 MiB
common_params_fit_impl: set ngl_per_device[0].n_layer=59

原因分析

根据 Issue 中的根因分析：在 tools/server/server-context.cpp 中，load_model 会把 mmproj 的内存占用加到 params_base.fit_params_target[i] 上；而 handle_sleeping_state 从休眠恢复时调用 load_model(params_base)，此时 params_base 已包含上次增加过的目标值，赋值 params_base = params 实际相当于自赋值，于是 mmproj margin 在每次唤醒时被重复累加。结果恢复时的 free memory target 变大，fit 逻辑判定显存不足，减少 n_gpu_layers，导致层被 offload 到 CPU。以上属于 Issue 讨论中给出的分析，具体修复未在该 Issue 中验证。

环境排查

确认是否使用带 mmproj 的多模态模型，以及是否启用 sleep（空闲自动休眠）。
确认 llama.cpp 版本（–version），对比是否有相关修复；Issue 报告版本为 10217（ddd4ec142），另有用户在 b10639 复现。
确认是否通过 –fit 或 –fit-target 启用了内存适配逻辑，以及是否存在显式指定 fit-target 的启动参数。
对比冷启动日志与恢复后日志中的 n_gpu_layers、memory breakdown 与 free memory target 是否变大。
确认是否使用了 Open-WebUI 前端；若由前端显式卸载模型而非 llama.cpp 自动休眠，可能不触发该问题。
操作系统与 GPU 驱动/CUDA 版本可记录用于对照，但 Issue 未将其作为必要排查项。

解决步骤

先复现确认：启动带 mmproj 的 llama-server，等待空闲进入 sleeping state，再发送请求唤醒，观察日志中 n_gpu_layers 是否从首次的满额层数下降。
示例命令：llama-server -m Qwen3.6-27B-UD-IQ3_XXS.gguf --mmproj mmproj-BF16.gguf -c 32768
可优先尝试 Issue 给出的规避方式：在启动命令中加入 --fit off 或 --fit-target 0，禁用恢复时的内存适配逻辑，再重复休眠/唤醒测试。
若仍异常，可尝试 --no-mmproj 关闭 mmproj 加载（有用户确认可绕过），或由 Open-WebUI 显式卸载模型而不是依赖 llama.cpp 自动休眠。
如需要从根本上修复，需跟踪 Issue #26401 及关联 #24475 的修复进展，更新到包含修复的 llama.cpp 版本；Issue 中未给出已验证的代码补丁或构建步骤。

验证方法

重复“冷启动 → 休眠 → 唤醒”流程，观察恢复后的日志：free memory target 不再异常变大、n_gpu_layers 与冷启动一致（或接近），且生成速度没有在连续 reload 后从约 30t/s 降到约 10t/s 这类明显衰减。也可对比休眠前后 memory breakdown 中 CUDA 设备上的 model/context 占用是否回落。若仅采用 –fit off 规避，验证重点是唤醒后不再发生 CPU offload。