DeepSeek V4 Flash Q4 量化版在 4×RTX 3060 上的实测记录
社区用户在 4 张 RTX 3060 12GB 上跑通 144 GiB 的 DeepSeek V4 Flash 量化版,…
Reddit 社区 r/LocalLLaMA 用户 /u/syscomua 近日分享了一项本地推理实测:在 4 张 NVIDIA RTX 3060 12GB(共 48 GB VRAM)上,配合 128 GB DDR4-3200 四通道内存与 Intel i9-10920X 处理器,使用 llama.cpp(build b10181)成功加载并运行 unsloth/DeepSeek-V4-Flash-0731 的 UD-Q4_K_XL GGUF 量化版(文件大小约 143–144 GiB),并保持 36 万至 37.6 万 token 的上下文窗口。实测显示,该方案在大约 2.05 万 token 的提示下,提示处理速度约 99.4 tok/s,文本生成速度约 10.1 tok/s。
硬件与模型规格
- CPU:Intel Core i9-10920X,12 核 / 24 线程
- 内存:128 GB DDR4-3200,四通道
- GPU:4 × NVIDIA RTX 3060 12GB,合计 48 GB VRAM
- 存储:NVMe SSD
- 推理引擎:llama.cpp(build b10181)
- 模型:unsloth/DeepSeek-V4-Flash-0731-GGUF
- 量化方案:UD-Q4_K_XL,约 144 GiB
- KV 缓存:Q8_0
最优高速配置与实测数据
作者给出的「最佳高速」启动参数核心如下:在 -c 368640 上下文、-ncmoe 34(将第 0–33 块的专家留在系统内存)、剩余 9 层专家通过 -ot 显式分到 GPU 1/2/3 各 3 层、-ts 100,1,1,1 把注意力与非专家张量压向 GPU 0 的布局下:
- 提示处理:99.4 tok/s
- 文本生成:10.1 tok/s
- 上下文配置:368,640 token
- 模型加载耗时:约 198 秒
- 满载时各卡最小剩余 VRAM:GPU0 约 671 MiB,GPU1 约 842 MiB,GPU2 约 1,395 MiB,GPU3 约 1,395 MiB
其他上下文/安全档位的对照数据(提示处理 / 解码 / 最小剩余 VRAM):
- 376,832:99.5 tok/s / 10.4 tok/s / 611 MiB
- 368,640:99.4 tok/s / 10.1 tok/s / 671 MiB
- 360,448:99.4 tok/s / 10.1 tok/s / 735 MiB
作者强调,368,640 这一档既保证了接近峰值的提示处理速度,也给 GPU0 留出了 671 MiB 的安全余量;相比之下,将上下文推到 393,216 时 GPU0 仅剩 493 MiB,告急。
GPU 布局与微批次的杠杆作用
该方案的关键在于「分层 + 显式覆盖」的混合分片策略:
- -ncmoe 34 将前 34 块的 MoE 专家固定在系统内存中,避免挤占消费级显卡本就紧张的 VRAM;
- 通过 -ot 显式将第 34–42 块(blk.(3[4-6])、blk.(3[7-9])、blk.(4[0-2]))的 ffn_*_exps 分别落到 GPU1、GPU2、GPU3,每卡 3 层;
- -ts 100,1,1,1 不再分配被 -ot 覆盖的专家权重,而是把注意力张量、KV 相关分配等非专家张量集中到 GPU0,为大体积专家腾出空间。
作者指出,这种张量摆放是离散的且不太直观,因此对每一组候选配置都做了实测,而不是靠解析估算。
性能上最大的杠杆来自微批次大小(-ub):
- -ub 1024:提示处理约 63.4 tok/s
- -ub 2048:提示处理约 99.4 tok/s
- 解码速度基本不变,约 10.1–10.5 tok/s
与之对应的权衡是:-ub 1024 安全性更高,可在 524,288 上下文中运行、最紧的 GPU 仍有约 1,032 MiB 余量,但提示处理速度下降至 63.4 tok/s 左右。
边界条件与尚未验证的部分
- KV 缓存选型:Q8_0 为默认推荐;同上下文下使用 F16 KV 在 c=393,216 时仅余 587 MiB,更容易 OOM。
- -ncmoe 33 触发 CUDA 分配失败,作者未进一步尝试更小值。
- 启用 -lm none 关闭内存映射;-np 1 是关键,多槽位会按倍数放大 KV 缓存需求。
- 模型主体位于系统内存,quad-channel 内存带宽成为瓶颈之一。
作者也提醒,36 万 token 的上下文目前仍是「配置容量」,368k token 端到端生成尚未实测完成,因此不能视为已验证的生成吞吐。整体而言,从 4 张 12 GB 消费卡上跑出近 100 tok/s 的提示处理与 10 tok/s 的解码,已经超出作者预期。
