用户实测 DeepSeek V4 Pro 本地批量推理性能

Reddit 用户「fairydreaming」近日分享了在自建工作站上运行 DeepSeek V4 Pro 的实测数据。测试基于 llama.cpp 的一个自定义分支（包含尚未合入主线的一系列修复与优化），通过批量推理基准工具 llama-batched-bench 对从 8192 到 1048064 不等的 prompt 长度进行了压力测试，覆盖了 prompt 处理（PP）与文本生成（TG）两个阶段的吞吐表现。

硬件与模型规格

测试平台搭载一颗 AMD Epyc 9374F 服务器 CPU，配备 12 根 96GB DDR5-4800 RDIMM（共 1152GB），显卡为单张 RTX PRO 6000 Max-Q（96GB 显存）。模型使用主线 llama.cpp 转换为 GGUF 格式，文件体积约 794GB。推理期间系统内存占用约 69.3%，显存占用约 78986 MiB，整机功耗约 500W，启用 flash attention（-fa 1）与 CPU MoE 卸载（-cmoe），未使用 repack。

批量推理性能

在批量大小（-b / -ub）均为 8192、上下文长度依次递增的条件下，关键吞吐数据如下：

• 8192 tokens：PP 192.03 t/s，TG 11.73 t/s
• 16384 tokens：PP 190.66 t/s，TG 11.62 t/s
• 32768 tokens：PP 184.70 t/s，TG 11.36 t/s
• 65536 tokens：PP 175.07 t/s，TG 11.01 t/s
• 131072 tokens：PP 158.45 t/s，TG 10.42 t/s
• 262144 tokens：PP 132.90 t/s，TG 9.35 t/s

随着 prompt 长度增加，PP 吞吐从约 192 t/s 逐渐下滑到 132 t/s，TG 速度也因注意力计算成本上升而从 11.7 t/s 降至 9.3 t/s 左右。原文还给出了 524288 与 1048064 tokens 的初步数据，作者表示完整结果将在基准跑完后补充到帖子中。

llama.cpp 主线对 V4 的支持现状

作者同步介绍了主线 llama.cpp 在 DeepSeek V4 上的几个已知问题：

• 内存开销偏高，主要浪费在闪电索引器（lightning indexer）的计算缓冲区以及 top-k 临时缓冲区；相关修复 PR 已提交但仍在排队等待合并，降低 ubatch 或上下文长度可暂时缓解
• 量化 KV cache 当前存在 bug，需要多个 PR 才能彻底修复
• prompt cache 复用与 batch 准备流程仍可能存在 bug，修复难度较大

闪电索引器相关的内存问题在作者的分支中已解决，但量化 KV cache 漏洞在该分支中也尚未修复。整体而言，要在普通消费级硬件上本地运行 DeepSeek V4 Pro 仍存在较高门槛，该数据更适合拥有类似大容量 CPU/内存/GPU 工作站配置的用户作为参考。