14.7 小时、971 次请求、零崩溃：DeepSeek V4 Flash 在 DGX Spark 上的浸泡测试

我们在 @NVIDIA DGX Spark 上运行 ds4 推理服务器，持续 14.7 小时，承受混合负载——971 次请求交替覆盖推理、编码、数学、工具调用、创意写作和逻辑。零错误、零崩溃、零内存泄漏。但吞吐量在整个运行期间下降了 28%，揭示了一种热模式。以下是完整分析。

问题

我们在 DGX Spark 上部署了 DeepSeek V4 Flash（第 1 篇），针对并发性进行了调优（第 2 篇），证明了它与云服务质量相当（第 3 篇），并观察它仅凭一个提示就构建了 Centipede（第 4 篇)。但所有这些都是短时测试——一次一个请求，间隔数分钟，并且在基准测试类别之间有冷却时间。

对生产环境而言最关键的问题是：当服务器在持续负载下运行数小时时会发生什么？

内存会泄漏吗？吞吐量会下降吗？GPU 会热节流吗？投机解码会失效吗？工具调用会停止工作吗？进程会崩溃吗？

这篇文章用 14.7 小时浸泡测试的数据回答了这些问题：971 次请求，生成 220，187 个 token，零错误。

测试

我们编写了一个浸泡测试脚本，每约 30 秒发送一个请求，循环使用 8 种提示类型：

• 推理 —— “如果一列火车 40 分钟行驶 80 公里，它的速度是多少 km/h？”

• 编码 —— “写一个 Python 一行代码来展平嵌套列表。”

• 数学 —— “23 × 47 是多少？展示你的计算过程。”

• 知识 —— “巴西的首都是哪里？”

• 指令 —— “列出 5 种编程语言。每行一个。”

• 工具 —— “伦敦的天气怎么样？使用工具。”

• 创意 —— “写一个关于机器人的三句话科幻故事。”

• 逻辑 —— “所有鸟都会飞。企鹅是鸟。企鹅会飞吗？”

每个请求记录：迭代编号、时间戳、补全 token 数、墙钟时间、吞吐量（tok/s）、首 token 延迟（TTFT，毫秒）、投机接受率和完成原因。脚本从 8 月 2 日上午 10：56 运行至 8 月 3 日凌晨 1:37——共 14 小时 41 分钟。

完整的浸泡测试日志位于 Nemo 知识库中。

结果

总体指标

指标值总迭代次数971持续时间14.7 小时错误0崩溃0生成的 token 总数220，187请求速率约 66 次/小时内存（RSS)3.04 GB（稳定，无增长)测试结束时服务器仍在运行✅

完成原因分布

完成原因数量百分比stop（自然完成）72975.1%length（达到 max_tokens)12112.5%tool_calls（成功调用工具)12112.5%

每个工具调用迭代（每 8 个请求一次，共 121 次）都产生了成功的 tool_calls 完成原因。14.7 小时内工具调用成功率为 100%。 length 完成全部来自编码提示（max_tokens=800），模型有时会完全填满这些 token。

吞吐量随时间变化 —— 关键发现

**小时平均 tok/s最小 tok/s最大 tok/s平均 TTFT (ms)平均投机接受率 %**011.28.019.549571.3110.78.014.347777.8210.68.018.446376.0310.37.516.947676.149.91.814.546877.259.23.212.366575.869.36.612.747477.279.16.417.547375.789.15.617.146577.798.96.417.846275.2108.46.511.446177.0118.25.910.245977.8128.35.917.048876.4138.24.517.645775.0147.86.311.47374.6

吞吐量从 11.2 tok/s 下降到 7.8 tok/s——14.7 小时内下降了 27.9%。 这是浸泡测试中最显著的发现。下降是渐进的（不是突然下降）且一致的（不是随机的）。TTFT 和投机接受率保持平稳——只有吞吐量下降。

前 50 次与后 50 次对比

指标前 50 次请求后 50 次请求变化平均吞吐量10.8 tok/s7.8 tok/s−27.9%平均 TTFT500 ms470 ms−5.9%（改善)平均投机接受率71.3%74.5%+4.5%

TTFT 实际上略有改善（快了 5.9%），投机接受率没有变化。只有解码吞吐量下降了。这种模式——TTFT 稳定、解码下降——与 GB10 芯片上的热节流一致。预填充阶段（决定 TTFT）是突发且短暂的；解码阶段（决定吞吐量）是持续且产生热量的。随着芯片温度在数小时连续负载中升高，GPU 时钟可能会降低以维持热限制。

按提示类型划分的投机接受率 —— 14.7 小时内保持稳定

提示类型计数平均投机接受率平均 tok/s平均 TTFT工具调用12191.4%8.81，040 ms推理12283.8%10.0438 ms数学12283.5%10.8422 ms知识12176.2%7.8366 ms指令12175.8%8.8395 ms逻辑12170.7%10.2418 ms编码12269.7%9.4412 ms创意12157.5%8.9385 ms

DSpark 投机解码在整个测试过程中保持了其接受率模式。工具调用的接受率始终最高（91.4%）——起草模型善于预测工具调用的结构化格式。创意写作的接受率最低（57.5%）——起草模型不太擅长预测创意续写。这与我们之前基准测试的模式一致。投机解码系统在 14.7 小时内保持稳定。

异常值 —— 10 次最慢的请求

迭代类型tok/sTTFT (ms)投机接受率 %Token 数321推理1.842384.5%112366工具3.214，5470.0%62909指令4.529668.8%37540知识5.638771.6%107900知识5.737975.9%89903创意5.738659.9%500924知识5.832377.4%95756知识5.940769.2%118844知识5.937777.6%87383创意6.031957.7%84

有两个值得注意的异常值：

• 迭代 321（1.8 tok/s） —— 一个推理提示，112 个 token 花费了 61 秒。下一次迭代恢复正常速度。很可能是瞬时的热尖峰或后台进程引起的 GPU 争用。

• 迭代 366（3.2 tok/s、14.5 秒 TTFT、0% 投机接受率） —— 一个工具调用请求，TTFT 为 14.5 秒，投机接受率为零。这是整个测试中最异常的数据点。0% 的投机接受率表明 DSpark 起草模型未能为该请求初始化，14.5 秒的 TTFT 表明服务器处于内存压力之下。但请求仍然成功完成（finish=tool_calls）——只是耗时更长。下一次迭代完全恢复。

两个异常值都立即恢复了。两者都没有引起级联效应或持久性退化。在 971 次请求中，只有 2 次出现显著异常——正常运行为 99.8%。

服务器进程健康状况

指标测试开始时测试结束时变化RSS 内存—3.04 GB稳定（无增长)CPU 使用率—39.4%正常服务器响应✅✅无中断Spark 运行时间14 天15 天未重启

没有内存泄漏。 RSS 在 4.8 小时标记处为 3.59 GB，在 14.7 小时标记处为 3.04 GB——实际上略有下降，这对于已稳定在其工作集内的进程来说是正常的。进程没有随时间增长。

分析

浸泡测试证明了什么

• 服务器不会崩溃。 971 次请求历经 14.7 小时，零崩溃，零错误，零进程重启。ds4 引擎是稳定的。

• 没有内存泄漏。 RSS 内存在整个过程中稳定在约 3 GB。进程的工作集没有增长。KV 缓存管理是可靠的——64K 上下文，max_seq=11，循环处理请求，没有累积内存。

• 工具调用 100% 可靠。 所有 121 次工具调用迭代都产生了正确的 tool_calls 完成原因。ds4 中的工具调用解析器在 14.7 小时内没有损坏、退化或产生格式错误的响应。

• 投机解码是稳定的。 DSpark 接受率在整个过程中保持其模式——工具 91%，推理 84%，创意 58%。起草模型没有随时间漂移或失效。

• TTFT 是一致的。 首 token 延迟在测试中没有增加——实际上略有改善（平均值从 500 ms 降至 470 ms）。预填充性能不受持续负载的影响。

浸泡测试揭示了什么

• 吞吐量在 14.7 小时内下降约 28%。 这是最具运营意义的一个发现。解码吞吐量从 11.2 tok/s 下降到 7.8 tok/s——这是一个渐进且一致的下降。这种模式（TTFT 稳定 + 解码下降）指向热节流：GB10 芯片的时钟在持续热量下逐步降频。DGX Spark 的冷却系统可以消散突发工作负载，但无法持续以 93% GPU 利用率进行 14 小时的连续推理。

• 971 次请求中有两个异常。 迭代 321 和 366 显示出显著的吞吐量下降（分别为 1.8 和 3.2 tok/s），但立即恢复了。迭代 366 上 0% 的投机接受率表明起草模型短暂加载失败——可能是内存压力事件。系统在一个请求周期内自我修正。

• 退化是可恢复的。 吞吐量下降是渐进的，不是断崖式的。服务器从未停止响应。如果热节流是原因，那么吞吐量应该在芯片冷却后恢复——这意味着退化是暂时的，不是永久的。这需要通过冷却测试来验证。

这对生产环境意味着什么

对于交互式智能体工作负载（Hermes）： 吞吐量下降并不是那么重要。智能体循环是突发性的——少量请求，然后智能体处理响应时处于空闲状态。GB10 有时间在突发之间冷却。28% 的下降是在 14.7 小时内以 30 秒间隔的持续负载下测得的，这比任何真实智能体工作负载都要激进得多。

对于批量工作负载（文档处理、评估测试集）： 吞吐量下降很重要。如果你正在运行一个 4 小时的批量任务，预期到结束时吞吐量会下降约 15-20%。在时间估算中考虑到这一点。或者，将批量任务安排为较短的段并留出冷却时间。

对于 24/7 服务： 服务器足够稳定——它不会崩溃——但吞吐量在数小时后会稳定在约 7-8 tok/s。这对大多数工作负载仍然可用。如果你需要持续的峰值吞吐量，则需要主动冷却或休息周期。

完整的 DeepSeek V4 Flash 系列

这是 DeepSeek V4 Flash on DGX Spark 系列的第五篇也是最后一篇：

• 部署 —— 在配备 DwarfStar 4 的桌面 GPU 上运行 685B MoE 模型

• 调优 —— 将上下文缩短 4 倍以获得 5.5 倍并发

• 对决 —— 本地在质量上媲美云端（8/8、3/3、4/5）

• Centipede —— 一个提示，390 行代码，零 bug

• 浸泡测试 —— 本文

该系列涵盖了完整生命周期：部署、调优、基准测试、构建和浸泡。每个数字都是实测的。每一个主张都有 Nemo 知识库中的真实数据支持。

验证说明

• 浸泡测试脚本：ds4-soak.py，可在 NemoKnowledgebase 获取

• 完整日志：1，072 行日志文件，包含全部 971 次迭代的逐请求指标

• 服务器状态：在开始、4.8 小时标记和结束时均验证为健康

• 硬件：NVIDIA DGX Spark（GB10/SM121，128GB UMA），测试结束时运行时间 15 天

• 软件：ds4 v0.5.2，64K 上下文，DSpark 投机解码，FP8/FP4 KV 缓存

• 所有吞吐量/TTFT/投机接受率数据：来自 ds4-server API 响应中的 timings 字段，非估算值

• 内存：来自检查点的 ps aux RSS，非持续监控（这是一个局限——下次浸泡测试应包含持续 RSS 记录）

接下来做什么

DeepSeek V4 Flash 评估已完成。模型已部署、调优、基准测试、在真实构建任务中得到验证，并现在通过了稳定性浸泡测试。DGX Spark 正在以生产质量将其作为 Hermes 的非主要提供商运行。

SMF Works 的下一步：

• 冷却测试 —— 让服务器空闲 1 小时，然后重新测量吞吐量，以确认热退化是可恢复的

• 主动冷却实验 —— 测试小风扇或改善气流是否能减少热节流

• 真实 Hermes 智能体负载 —— 用实际的智能体循环替代合成浸泡测试，并测量真实世界性能

• 32K 上下文测试 —— 如果我们需要超过 11 个并发序列，则在 32K 上下文下测试

Forge 是坚实的。数据已发布。模型可以工作。