REAP 剪枝版 DeepSeek 在 Ascent GX10 长上下文测试

一位本地推理爱好者在 Reddit r/LocalLLaMA 板块分享了其在 Ascent GX10 工作站上的实测结果：在「单卡 Spark」上运行经过 REAP 剪枝并量化为 NVFP4 格式的「DeepSeek-V4-Flash」模型，借助 vLLM 后端提供 262k 上下文服务，并在不同并发档位与上下文长度下记录吞吐与首 token 时延。发帖者称，方案在上下文从约 4k 一直拉到约 163k 的过程中，预填充吞吐始终保持在较高水平，呈现「长上下文下表现稳定」的结论。

需要说明的是，原文模型名为「DeepSeek-V4-Flash」，但 DeepSeek 官方目前公开的版本为 V3、V3.1、V3.2-Exp 等，并不存在 V4 系列；该名称可能是原作者笔误，也可能是内部或预览版本，本文按原文照录，并在标题与正文中加以提示。原文末尾的部分数据行存在截断（最后一行记为「789169.74 ±…」），下文整理仅基于可读到的数据点。

测试环境与配置

发帖者使用 Ascent GX10 工作站中单卡 Spark 进行测试，模型为 REAP 剪枝后的 NVFP4 量化版本（剪枝工作由 0xSero 完成），推理后端为 vLLM，对外上下文窗口为 262k。为了便于观察运行状态，原作者用 Hermes 「vibe coding」的方式搭了一个 Grafana 看板，把 raw log 可视化出来。

• 模型：DeepSeek-V4-Flash（REAP 剪枝 + NVFP4 量化）
• 推理框架：vLLM（262k 上下文窗口）
• 硬件：Ascent GX10 单卡 Spark
• 配套镜像：eugr/spark-vllm-docker（已打补丁）

长上下文下的吞吐表现

测试覆盖了 4092、16384、65536、131072、162816 五档上下文长度，每档分别跑了 tg=128 与 tg=512 的生成请求。单并发（c1）下预填充吞吐（pp，单位 t/s）随上下文增长的变化如下：

• pp4092：约 827–835 t/s
• pp16384：约 768–769 t/s
• pp65536：约 655–656 t/s
• pp131072：约 559–574 t/s
• pp162816：约 535 t/s

单并发下的文本生成吞吐（tg）则维持在 18–23 t/s 区间，未随上下文长度明显下降。首 token 时延（ttfr）从约 4.9 秒（4k）逐步升至约 304 秒（162k），与上下文长度近似线性关系。

多并发下的衰减情况

在 c2 与 c4 并发下，预填充吞吐出现一定折损，但 c1 与 c2 之间的差距相对有限：

• pp65536：c1 约 655 t/s → c2 约 622 t/s → c4 约 613 t/s
• pp131072：c1 约 559 t/s → c2 约 549 t/s → c4 约 547 t/s
• pp162816：c1 约 535 t/s → c2 约 521 t/s → c4 约 519 t/s

文本生成端在高并发下下降更明显，例如 pp65536 / tg128 档位，c1 仍有约 18 t/s，c4 已降至约 1.5 t/s；tg512 档位相对更稳，c4 仍可保持在 5–13 t/s 左右。

一点观察

从原始数据看，作者「长上下文下吞吐稳定」的结论在单并发场景下基本成立：4k 到 163k 上下文，预填充吞吐仅从约 835 t/s 降至约 535 t/s，文本生成吞吐也基本保持在 20 t/s 上下。但 c4 并发下，首 token 等待时间明显恶化——例如 pp131072 从单并发约 234 秒跳到 c4 的约 602 秒，说明并发调度与显存带宽仍是这一尺寸模型本地部署的主要瓶颈。该结果为单台 Ascent GX10 的实测记录，并未与其他工作站或云端部署做直接横向对比，仅供参考。