b10091: ~35% generation speed regression on 8GB VRAM — 3 root causes identified (fit+no-mmap incompatibility, GPU not boosting, CPU MoE regr

b10091: ~35% generation speed regression on 8GB VRAM — 3 root causes identified (fit+no-mmap incompatibility, GPU not boosting, CPU MoE regression)

快速结论：该问题发生在使用 Windows 11、NVIDIA GeForce RTX 4060 Laptop 8GB 显卡、8GB VRAM 场景下，运行 llama.cpp b10091 版本并加载大型 MoE 模型（35B）时，生成速度相比 b9536 版本下降约 35%。优先排查方向：检查 --fit 与 --no-mmap 是否同时使用（存在兼容性问题），并确认 GPU 实际时钟频率是否达到预期最大值。

问题场景

用户在 Windows 11 24H2 系统上，使用 llama.cpp b10091 版本（CUDA 13.3 构建），配合 NVIDIA GeForce RTX 4060 Laptop 8GB 显卡和 Intel Core Ultra 5 125H CPU，加载 Ornith-1.0-35B-MTP-APEX-I-Quality.gguf（35B MoE 模型，IQ3_S 量化），并使用 MTP 推测解码和 100K token 上下文窗口。在相同硬件、配置和模型下，b9536 版本正常工作，b10091 版本出现约 35% 的生成速度下降。

报错原文

# 速度对比（Hot 阶段）
# b9536 🏆: 32.4 t/s (平均)
# b10091 ❌: 21.1 t/s (平均)
# 变化: -35%
# 
# GPU 时钟频率分析：
# 最大时钟频率: 3105 MHz
# b10091 实际频率: 1275-1455 MHz（仅为最大值的约一半）
# b9536 实际频率: 2625 MHz / 47W（正常区间）
#
# VRAM 使用量（一致时）：
# b9536: 7901 MiB
# b10091: 7901 MiB (但最初因 DLL 缺失降级为纯 CPU 推理，导致误判为 70-80% 回归)
#
# 关键日志/配置冲突线索（用户推测）：
# --fit on 与 --no-mmap 存在已知不兼容性：当设置 --no-mmap 时，--fit 拒绝工作。
# 用户测试中用户推测：b9536 无此限制，fit 正常运作并动态卸载非关键层到 CPU。

原因分析

经用户排查，本次回归由三个独立原因叠加导致：

--fit 与 --no-mmap 不兼容：b10091 版本中，当同时使用 --fit（设置 --fit on）和 --no-mmap 时，--fit 会提前中止并拒绝动态分配 VRAM。b9536 版本无此限制。这导致在 b10091 上使用相同配置时，VRAM 利用不足（早期测试中仅使用 6581 MiB vs 7901 MiB），虽然最终修正好后 VRAM 用量一致，但该不兼容性仍被认为是首要根因。
GPU 无法达到最大升频时钟：GPU 进入 P0 性能状态，但实际时钟频率仅维持在 1275-1455 MHz，而非其额定最大值 3105 MHz。功率约 18W（最大 47W），远低于正常水平。用户推测 b10091 的 CUDA 内核启动模式变化影响了 NVIDIA 驱动的升频算法，导致 GPU 无法自动提升频率。
CPU 侧 MoE 路由路径回归：长文本生成（Hot Long gen）速度从 29.3 t/s 降至 8.0 t/s，降幅达 73%，是受冲击最大的场景。用户推测这暴露了 CPU 侧 MoE 路由（ggml-backend 调度）的回归问题，短文本和智能体场景受影响较小（30% 和 25%）。

注意：用户最初报告的 70-80% 回归是假阳性，因为在 b10091 的 bin 目录中缺少 cudart64_13.dll/cublas64_13.dll，导致服务器降级为纯 CPU 推理（约 2 t/s）。安装正确的 CUDA 运行时 DLL 后，实际回归约为 35%。

环境排查

确认 llamm.cpp 版本：b9536（commit 308f61c31）vs b10091（commit b4d6c7d8f）
确认 CUDA 构建完整：检查 bin 目录是否包含 cudart64_13.dll/cublas64_13.dll（缺失会导致降级）
确认 GPU 时钟频率：使用 nvidia-smi 或 GPU-Z 监测 Hot 阶段 GPU 实际时钟（正常应为 2500-3105 MHz）和功耗（正常应为 47W 附近），确认是否处于 P0 状态但仍限频（用户测得仅 1275-1455 MHz / 18W）。
确认 VRAM 使用量：检查 –fit 是否正常分配 VRAM（b10091 上若同时使用 –no-mmap 可能导致分配不足）。
操作系统与驱动：Windows 11 24H2，NVIDIA 驱动 610.62
显卡型号与显存：NVIDIA GeForce RTX 4060 Laptop 8GB

解决步骤

修复 DLL 缺失（验证基础）：检查 llama-server.exe 所在 bin 目录是否包含 cudart64_13.dll/cublas64_13.dll。若不包含，请从 CUDA Toolkit 13 安装目录复制或通过环境变量指定路径。缺失时服务器将静默降级为纯 CPU 推理（~2 t/s）。
避免 –fit 与 –no-mmap 同时使用（可优先尝试）：这是最可能影响 8GB VRAM 用户的单个配置项。如果正在使用 --fit on（或 --fit-target）且同时使用 --no-mmap，请移除 --no-mmap，然后测试速度是否恢复。如果必须使用 --no-mmap，需手动调整 -ngl 参数（如减少层数）以确保不超出 VRAM。
尝试手动固定 GPU 时钟（缓解 GPU 不升频）：使用 nvidia-smi 命令尝试强制设定 GPU 时钟频率（注意：用户尝试后仅获得 +3% 改善，属于噪声级别）：nvidia-smi -i 0 -lgc 2500,3105（将频率锁定在 2500-3105 MHz 区间）。如果无效，说明瓶颈在 CPU MoE，而非 GPU 频率。
优化 CPU 线程配置（缓解 CPU MoE 回归）：用户测试显示调整线程数能显著改善效果：可优先尝试 -t 8 --cpu-range 0-7（限定使用 0-7 号核心），此配置在用户实验中从 21.1 t/s 提升至 24.8 t/s（Hot avg）。另外尝试减少 MoE 专家线程数（如 --n-cpu-moe 33）也可能有效。
回退到 b9536 版本（临时方案）：如果上述步骤均无法解决且严重影响使用，可临时回退到 b9536（commit 308f61c31）版本，该版本在相同硬件和配置下工作正常，Hot avg 为 32.4 t/s。

验证方法

使用与问题场景完全相同的模型、配置、上下文长度和推测解码参数（MTP），运行一个连续生成 200+ token 的长文本任务（如 RealSim 测试或自定义长提示词）。记录并对比 Hot 阶段的生成速度（t/s）：b10091 应达到 b9536 版本的 80% 以上（即 25+ t/s），同时 GPU 实际时钟频率应接近 2500-3105 MHz，功耗接近 47W。如时钟和功耗仍显著偏低，则 GPU 未升频；如速度仍低但时钟正常，则可能是 CPU MoE 路径问题。注意：短文本（<100 token）测试可能不会暴露所有回归（尤其实时提升问题）。