V L L M 升到零点三十二点零，DeepSeek V 四点一，真的快了吗？八卡 H 二十杠三 E 实测。

DeepSeek V 四点一 Flash，把混合专家架构与 Engram 条件记忆结合在一起，支持文本与图片输入。模型发布时，我们已经在八张 H 二十杠三 E 上，跑过部署、功能和压测。当时用的是固定支持构建，如今，V L L M 的实现已经有不少变化。

最近一些公众号和公开文章都在讨论，新版 V L L M 跑 DeepSeek，效果很好。具体到手里的 H 二十杠三 E，换一个版本，到底能快多少？长输入、长输出，是否都会受益？原来的功能和输出完整性，还能不能保证？

这次，我们把原文章使用的镜像找回来，与正式版零点三十二点零，在同一台八卡机器上先后运行，补齐了六十轮，一千九百六十八个正式请求。

结果有明显收益，也有需要继续定位的问题。八 K 输入，并发八的吞吐，从每秒九十七点六九个 Token，提高到二百一十七点四六个，约提高百分之一百二十三。单并发长输出，却基本持平。完整输出检查中，两版分别留下六个和十一个失败请求。

先把新版很快的背景说清楚。

V L L M 团队，十月七日发布过一篇性能文章，介绍 DeepSeek V 四点一 Flash，在 Agent X 场景，相对最初实现的提升。这比零点三十二点零的发布时间还早，不能把其中的倍率理解成，升级这个版本，任何机器都会这么快。

零点三十二点零，于十月十八日发布，Hopper 上优先选择 Humming 等默认行为，也发生了变化。这给了我们重新测试的理由，但具体收益，仍要放到自己的硬件、请求长度和并发里看。

本次没有追每日构建，也没有换成一零一七模型权重。比较的就是原版 DeepSeek V 四点一 Flash，以及此前文章里的 V L L M 构建，和零点三十二点零。

同一条启动命令，实际路径也会变。

两版都用八路张量并行，加专家并行，三十二 K 服务上下文，最大运行序列三十二，批处理 Token 上限八千一百九十二，显存比例零点八五。Engram 放在 GPU，关闭文本前缀缓存，没有开启 D Spark。

原文章版本，是当时固定的开发构建，完整编号保留在原文里。新版本是零点三十二点零。Torch 都是二点十三点零，加 CUDA 十三点零。Humming 从零点一点十二，变为零点一点十七。Transformers、Flash Infer，也随镜像升级。客户端与逐轮输入保持一致。

核对日志时，有个差异必须单独说明。新版默认启用了 S W A 有界重放，旧构建没有这个配置项。

S W A，是 Sliding Window Attention，也就是滑动窗口注意力。有界重放会减少部分长输入计算。新版日志明确写出，在预填充阶段，第二十层为全部 Token 写入键值缓存，其余相关工作，与第二十一到三十九层，只处理每个请求末尾的一百二十八个 Token。即使前缀缓存关闭，这条解码器优化路径，仍然可以生效。

新版也实际选用了 Humming 的 M X F P 八线性层，和专家计算路径。因此，这次得到的是整套版本升级的结果，没有把收益全部归给一个算子。要分清有界重放贡献多少，需要额外做开关实验。

长输入受益，长输出要看并发。

每个输入长度与并发组合，做三轮正式测量，预热另算。并发一、并发八、并发三十二，每轮分别发八个、十六个、六十四个请求。接下来比较的几组，两版全部请求成功，吞吐数值均为三轮中位数。

八 K 输入，一百二十八输出。单并发的吞吐，从每秒五十七点七六个 Token，提高到八十二点九四个。并发八，从九十七点六九，提高到二百一十七点四六个。后者为原来的约二点二三倍。

把请求改成一 K 输入，五百一十二输出。单并发却从每秒一百一十五个 Token，变为一百一十三点六九个，约下降百分之一点一。这组短时重复，更适合描述为接近持平。并发八，从六百零九点七三，提高到六百七十六点九三个，增幅约百分之十一。

同样是升级后跑模型，长输入检索，和单用户连续生成，得到的体感，很可能不同。

再看首内容等待，也就是发出请求后，等到第一个内容 Token 的时间。八 K 输入、并发八时，百分之九十五分位的等待，从九点二零六秒，降到三点四二九秒，缩短约百分之六十二点八。这里先算每轮的百分之九十五分位，再取三轮中位数。

单并发长输出的百分之九十五分位，每 Token 时间，则是从八点三四二毫秒，变为八点五二零毫秒，没有同步变快。

前一批同机配对实验，还保留了一组完整的四 K 输入，一百二十八输出，并发三十二。吞吐从每秒二百零三点二二个 Token，变为四百六十三点二零个，约提高百分之一百二十七点九。两版都是三百八十四个请求，全部成功。那批使用另一台同规格节点，单独统计，没有和这批的轮次混在一起。

这两个版本，都遇到了状态码二百，但是没有正文。

本轮两版各执行三十轮，九百八十四个正式请求。原版九百七十八个成功，六个失败。新版九百七十三个成功，十一个失败。分别有五轮，和九轮，包含失败请求。

这些失败有一个共同点。H T T P 状态码是二百，流里有结束标记，用量统计也说生成了 Token，实际的文本，却一直为空。

如果只看状态码、健康检查，或压测进程退出码，就容易把它们算成成功。这里保留原分母，把空文本判为失败。含失败的场景，仍记录结果，但是没有拿来计算前面那几组全部成功场景的收益。

目前还不能把根因指向 Humming、某个 GPU 计算内核，或认定它只属于新版。两版都能出现，下一步应固定合成提示词和 Token 编号，对照流式、非流式、特殊 Token 与解码输出，再逐项切换优化。这些比例，来自合成固定长度负载，也不能直接当成生产故障率。

看一下实际运行的过程。

原文保留了两张实际监控截图。一张是 GPU 利用率、显存、功率与温度，另一张是请求吞吐、首内容等待、排队与错误。

截图时间为十月二十七日，上午九点四十五分，到十一点零四分，使用北京时间。前半段，是原文章构建，后半段，是零点三十二点零。显存中间的下降和重新上升，对应版本切换、加载和初始化。图中的资源指标，为八卡平均。

两版按同样的场景顺序运行，但是新版每个场景的耗时不同。看图时，要按场景对应，不能比较同一个横坐标时刻。监控窗口的吞吐和直方图分位数，用来解释过程。正式分数，以逐轮文件为准。

本轮两版的文本、完整流基础检查、工具解析，与单图、双图顺序样例，均通过。视觉仍用原来的两千零四十八 Token 预算。这说明这些样例能运行，不能代替完整的准确率和长任务回归。

最后，部署上怎么取舍？

如果服务以长提示词、检索增强生成，或智能体历史上下文为主，零点三十二点零，值得安排灰度。重点看首内容等待、排队，与有效输出比例。新版默认的有界重放，也要进入任务质量回归范围。

如果主要是单用户、短输入、长时间连续生成，不要预期仅换版本，就让解码速度翻倍。本轮单并发长输出接近持平，应该围绕实际的逐 Token 延迟目标测试。

如果准备提高并发，先把空文本的定位与验收补齐。固定镜像摘要、模型快照和依赖，保留旧镜像与回滚方式，再用真实提示词建立容量结论。

这次升级，确实带来了明显的长输入收益。更有用的经验是，升级验收要同时看请求形状、默认执行路径和完整输出，不能只记住一个最快的吞吐数字。

完整配置、十个场景的成绩与失败分母，以及脱敏逐轮数据，都保留在对应公开文章里。以上，就是本次八卡 H 二十杠三 E，运行 DeepSeek V 四点一 Flash 的版本升级实测。