在 128GB 内存 + 双 3090 上魔改 llama.cpp 跑 DeepSeek-V4-Flash

一名 r/LocalLLaMA 用户在内存与显存均不足以完整容纳 4-bit 量化 DeepSeek-V4-Flash（约 140+ GB）的条件下，基于 leloch 的 llama.cpp 分支做了若干工程改造，把该模型的本地推理速度从最初的个位数 token/s 推到约 20 tgs，并在长上下文场景下尝试用更低量化模型单独处理 prompt 阶段。整套方案以两个分支形式开源在 GitHub，可作为爱好者跑大尺寸 MoE 模型时的参考。

硬件与目标性能

作者的配置为：第 14 代 Intel i5、DDR5 128GB（2×48 + 2×16，4400 频率）、2 张 RTX 3090 + 1 张 RTX 3060、20 条可用 PCIe 5.0 通道，以及两块无 DRAM 缓存、理论读取约 4.5 GB/s 的 SSD。

他设定的「可用」门槛是：

• 生成速度（tgs）≥ 20 多的高位区间
• Prompt processing 速度（pp）≥ 300
• 上下文长度 156K

在此目标下，原版 4-bit 量化直接读取 SSD 时会出现大量缓存未命中，最初仅得到约 7 tgs 与 20 pp，远不足以作为日常驱动。

MoE 缓存策略改造

DeepSeek-V4-Flash 属于 MoE 架构，但作者的 RAM + VRAM 总量已超过模型权重，理论上应能完全驻留而无需回退 SSD。问题在于 llama.cpp 默认会同时在 RAM 与 VRAM 中保留冗余的 expert 副本，并依赖操作系统页缓存管理。

作者做了两点关键修改：

• VRAM 中的「热」expert 升至 GPU 后，其内存缓存会被释放，使 kernel 可将该段 RAM 挪作他用；
• VRAM 中的 expert 被降级后，不会立即从 SSD 预读，而是首次被命中时再读入并 mlock。

这样在任何时刻同一 expert 都不会同时存在于 RAM 与 VRAM，节省了空间。叠加 VRAM 缓存预算、ELITE 比例、demand decay 等参数调优后，他在启用 dflash 草稿模型并把其固定到主内存时，能稳定跑到 20 上下 tgs，生成超过 1000 token 后尤其明显。但 prompt processing 仍卡在 60 pp 以下，长 prompt 下的体验并不理想。

长 prompt 切换更低量化的尝试

为了解决 pp 过慢的问题，作者做了一项他自认较新的实验：在 prompt 阶段临时卸载 4-bit 主模型、加载 IQ_2_M 这类极低量化模型专门处理输入，待其结束后再切回原模型继续 decode。

其逻辑是：

• 长 prompt 下，由 IQ_2_M 提速带来的收益，可能超过「卸载主模型 + 加载低量化 + 重载主模型 + 冷启动 expert 缓存」带来的代价；
• 已有研究表明，即便初始 KV cache 由低质量模型生成，只要 decode 足够长，模型仍能在后续补回质量。

实测中部分配置下 pp 可逼近 200，但整体收益受制于切换后 decode 头 1000 token 偏慢，主观体验只在 prompt 达到 30K+ 时才明显改善。尝试仅迁移「热门 expert ID」的方案未能完全避免缓存重建带来的减速。

代码与分支

作者把改动放到 GitHub 仓库的两个分支：

• moe-cache-ousemma：不含 PP 阶段切模型逻辑，可实现约 20 tgs 与 45 pp；
• moe-cache-ppswap：包含 PP 阶段切模型逻辑。

样例命令中可见作者对 GGML_CUDA_MOE_CACHE_* 系列参数做了较细粒度的控制，例如 RESERVE_MB=512、QUEUE_MB=2048、BUDGET_MB=40000、BUDGET_MB_DEVICES=0:11800 等，并配合 MOE_CACHE_MLOCK=1 强制专家权重常驻内存。

作者也表示，其 PCIe 与 SSD 条件较差，期待在更强硬件上验证这些思路能否把指标进一步推高。