我们实测了DeepSeek V4 Pro和Flash与Claude Opus 4.7和Kimi K2.6的对比(11分钟阅读)

TLDR AI 模型

摘要

DeepSeek于2026年4月24日以MIT许可证发布了V4 Pro和V4 Flash。在与Claude Opus 4.7和Kimi K2.6的基准测试中,V4 Pro得分77/100,价格为2.25美元,性能介于Opus 4.7(91分)和Kimi K2.6(68分)之间;而V4 Flash得分60/100,价格为0.02美元,是本次对比中最便宜的,并且到5月31日前购买V4 Pro可享受75%的折扣。

DeepSeek V4 Pro在FlowGraph基准上以2.25美元的价格获得了77/100的得分,性能介于Opus 4.7和Kimi K2.6之间。
查看原文
查看缓存全文

缓存时间: 2026/05/15 00:12

# 我们测试了 DeepSeek V4 Pro 和 Flash 对比 Claude Opus 4.7 和 Kimi K2.6 来源:https://blog.kilo.ai/p/we-tested-deepseek-v4-pro-and-flash DeepSeek V4 Pro 和 DeepSeek V4 Flash(https://api-docs.deepseek.com/quick_start/pricing)于 2026 年 4 月 24 日共同发布,采用 MIT 许可证。这是 DeepSeek 自 V3 以来首个新架构,也是首个提供双轨制(Pro 作为旗舰,Flash 作为轻量级模型)的开源权重模型系列。 [](https://substackcdn.com/image/fetch/$s_!RkaY!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb504b56e-63d8-4c77-b957-8bec78d1bfac_1080x742.png) 我们通过用于 Claude Opus 4.7 vs Kimi K2.6(https://blog.kilocode.ai/)的相同 FlowGraph 规范,对两者进行了测试。采用相同的规范、相同的提示词、相同的评分标准。 **TL;DR:****DeepSeek V4 Pro 得分 77/100**,成本 $2.25,性能介于 Opus 4.7(91)和 Kimi K2.6(68)之间。**DeepSeek V4 Flash 得分 60/100**,成本 $0.02,这是我们在此测试中从未见过的价格,但构建失败且输出缺少了一些关键部分。 [](https://substackcdn.com/image/fetch/$s_!VI4A!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdfc40c6e-2242-4f9a-aa09-9e3ab2e328eb_1456x437.jpeg) **DeepSeek V4 Flash 是本次对比中价格最低的模型,且差距巨大。** 输出 token 成本不到 Kimi K2.6 的 1/14,大约是 Claude Opus 4.7 的 1/89。 **DeepSeek 还在 DeepSeek V4 Pro 上推出 75% 折扣促销,截至 2026 年 5 月 31 日。** 折扣后,DeepSeek V4 Pro 的输入价格降至约 $0.036/M,输出降至 $0.87/M,在输入和输出两方面都低于 Kimi K2.6。DeepSeek 还将整个系列的输入缓存定价永久性地降至之前水平的十分之一。 这是我们在 Opus 4.7 vs Kimi K2.6(https://blog.kilo.ai/p/we-gave-claude-opus-47-and-kimi-k26)测试中使用的相同 FlowGraph 规范,这是一个包含 20 个端点、持久状态、租约管理、重试机制和事件流的工作流编排后端。它比我们通常的编码基准更复杂的基础设施测试,旨在将模型推向极限。 我们通过相同的设置运行了 DeepSeek V4 Pro 和 DeepSeek V4 Flash,以观察新的 DeepSeek 系列在成本和首次通过质量方面与 Claude Opus 4.7 和 Kimi K2.6 的对比情况。 我们在 Kilo CLI(https://kilocode.ai/)中运行了这两个 DeepSeek 模型,使用了与 Opus 4.7 和 Kimi K2.6 相同的提示: > “阅读 @SPEC.md 并在当前目录中构建项目。将 @SPEC.md 视为唯一权威来源。不要将其简化为模拟、玩具应用或基本 CRUD 脚手架。创建可运行项目所需的所有代码、配置、Prisma schema、测试和 README....” 两个 DeepSeek 模型均在思考模式下运行,位于各自的空目录中,没有共享状态。 [](https://substackcdn.com/image/fetch/$s_!qjeS!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59fe59f0-563b-4a61-b70d-42ebbdd1133c_1456x377.jpeg) DeepSeek V4 Pro 通过了自身的测试套件,但 TypeScript 构建失败。DeepSeek V4 Flash 的测试套件从未运行,因为其设置脚本尝试强制重置数据库,导致首次测试执行前就报错退出。 如果只看模型摘要,这两个 DeepSeek 的实现看起来会比实际情况更接近 Claude Opus 4.7。直接的代码审查加上针对隔离 SQLite 数据库的针对性复现,揭示了两个模型输出中的问题。 DeepSeek V4 Pro 在系统整体架构上基本正确。端点已连接,测试套件通过,项目结构合理。**我们发现的问题集中在与 Kimi K2.6 相同的方面**:租约过期处理、调度、验证和构建完整性。 [](https://substackcdn.com/image/fetch/$s_!qSDq!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F060370e7-c491-4821-8644-232ff08c74d7_1456x1709.png) 当工作者声明一个步骤时,系统会赋予它一个租约,该租约在设定的超时时间后过期。如果工作者停滞或崩溃,租约应过期,另一个工作者应能自由接取该步骤。一旦租约过期,原始工作者不再是该步骤的所有者,不应能够将其标记为完成。 DeepSeek V4 Pro 在心跳上强制检查了这一点,但在完成时却没有。我们声明了一个步骤,将其租约过期时间推到过去,然后要求 API 将该步骤标记为成功完成。API 返回 200 并将步骤记录为成功。原始工作者实际上在租约过期后仍完成了工作,而它已经不再拥有该步骤的所有权。 **DeepSeek V4 Pro 自己的 README 说工作者不能在租约过期后完成,但实现并没有强制这一点。** 工作流运行可以声明允许并行运行的最大步骤数。当达到该上限时,已饱和的运行不应接受更多工作,但共享同一队列的其他运行应继续推进。 DeepSeek V4 Pro 的声明逻辑每次只检查一个候选步骤。如果该候选步骤恰好属于已达到并行上限的运行,函数会放弃并返回空,而不是继续检查下一个候选步骤。 我们通过两个同时活跃并共享同一队列的运行复现了这一点。运行 A 已达到其并行限制。运行 B 有容量,且有一个优先级更高的步骤准备就绪。下一次声明请求返回了空。在生产环境中,这看起来像是工作者在空闲,而实际上有真正的工作要做,仅仅因为队列中的第一个运行恰好饱和了。 npm test 通过,但 npm run build 失败。即使修复了构建错误,项目仍然无法通过 npm start 运行。TypeScript 配置设置为不生成任何编译输出,但 package.json 期望 npm start 运行该编译输出。**如果在干净的检出上按照 DeepSeek V4 Pro 自己的 README 操作,用户将无法获得一个可工作的服务器。** **整个运行成本 $0.02,DeepSeek V4 Flash 进入了我们之前未测试过的领域。** 内部逻辑貌似合理。问题出在公共 API 上。 [](https://substackcdn.com/image/fetch/$s_!h1D4!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7b352196-67a3-4d23-af0c-813abcdb5fe4_1456x1709.png) 要使用这个系统,客户端首先通过调用特定端点创建工作流运行。如果该端点无法工作,其他一切都不可能发生。没有运行供工作者声明,没有事件流,没有步骤可完成。 DeepSeek V4 Flash 编写了该端点的处理程序,但挂载在了错误的路由前缀下。规范要求在 /workflows/key/:key/runs 处。DeepSeek V4 Flash 实际提供在 /runs/key/:key/runs 处。向运行服务器发出规范路径的请求返回 404 Endpoint not found。README 记录了规范路径,但服务器并不提供该路径。 DeepSeek V4 Flash 的测试直接调用内部函数,而不是通过 HTTP API。从测试套件的角度来看,一切正常。但从实际客户端的角度来看,系统的入口点是缺失的。 一旦工作流运行失败(因为其某个步骤用尽了所有重试尝试),该运行中的其他所有步骤都应停止。规范要求剩余的步骤进入阻塞状态,以便工作者不会接取它们。 DeepSeek V4 Flash 的恢复逻辑在开始时加载所有过期的步骤,然后逐个处理。如果第一个过期步骤用尽重试次数并导致父运行失败,同一批次中的后续步骤仍可能被提升为“准备重试”状态,即使它所属的运行已经结束。 我们通过一个运行中的两个过期步骤复现了这一点: - 步骤 a 没有剩余重试次数,被正确地标记为死亡 - 父运行被正确地标记为失败 - 步骤 b 最终处于 waiting_retry 状态,而不是 blocked 状态 轮询新工作的工作者仍然会收到步骤 b,并为已经失败的工作流执行它。Claude Opus 4.7 有一个相关的多过期租约错误。Kimi K2.6 完全错过了实时事件流。**在竞争条件下的恢复仍然是该规范中任何模型首次通过时最难处理的部分。** DeepSeek V4 Flash 存在与 DeepSeek V4 Pro 相同的过期租约完成错误。过期的租约仍然可以完成工作,即使原始工作者不再拥有该步骤。 它还拒绝有效的请求负载。规范说工作流运行的输入和元数据可以携带任意 JSON,包括数组、字符串和数字。DeepSeek V4 Flash 的验证只接受 JSON 对象。发送 JSON 数组作为输入的客户端会收到 400 响应,即使规范接受它。 上述错误是关于 DeepSeek V4 Flash 产生的输出。工具调用是另一个维度:模型在 Kilo CLI 内的表现。在这个维度上,模型的表现出人意料地好。它在编辑文件之前读取文件,在合理的点安装依赖并运行测试套件,并且没有在失败的命令上陷入重试循环。即使它生成的代码有缺陷,代理循环也运行得很干净。 **这不是我们对这个价位模型的预期。** 工具调用的可靠性通常是廉价模型首先崩溃的地方,表现为格式错误的参数、虚构的文件路径,或无限循环消耗令牌而无进展。DeepSeek V4 Flash 在我们的运行中避免了这些失败模式。 我们使用了与 Opus vs Kimi 文章相同的 7 类别评分标准。 [](https://substackcdn.com/image/fetch/$s_!67Lg!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0b201fc2-3474-47ec-9b80-ccc5e61eb982_1456x540.jpeg) DeepSeek V4 Pro 位于 Claude Opus 4.7 和 Kimi K2.6 之间。与 Opus 的差距集中在构建质量和租约处理上。DeepSeek V4 Flash 位于 Kimi K2.6 之下,几乎所有类别都有扣分。 [](https://substackcdn.com/image/fetch/$s_!nf6m!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59f37c4e-4756-4ce9-b844-04cfdd6bc72e_1090x484.png) **在此基准测试中,DeepSeek V4 Flash 的每点成本大约是 Kimi K2.6 的 1/30,是 Opus 4.7 的 1/100。** 分数较低,但绝对美元金额非常小,以至于将相同任务运行三次或四次以比较尝试,仍然比一次 Kimi K2.6 运行更便宜。 [](https://substackcdn.com/image/fetch/$s_!-zqd!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd5d34121-438e-4376-aa15-8ee999507ddd_1356x892.png) 在这次运行中,DeepSeek V4 Pro 比 Kimi K2.6 更贵,因为我们在应用官方折扣之前运行了它。如果将 DeepSeek 的 75% 促销应用于当前费率,同样的运行成本将接近 $0.55,使其在绝对成本上低于 Kimi K2.6,同时得分高出 9 分。 之前对比中的模式继续成立。开源权重模型与前沿专有模型之间的表面覆盖差距很小。在困难代码路径(租约恢复、跨运行调度、过期租约拒绝)上的正确性差距仍然存在,但也在缩小。 根据我们的测试,DeepSeek V4 Pro 是 Kimi K2.6 的实用升级。相同的总体失败模式,但整体结构更清晰,规范级别的差距更少。在 DeepSeek 官方折扣生效的情况下,与 Kimi 的价格差距缩小,而质量差距保持不变。 DeepSeek V4 Flash 则是另一回事。**全价时,它比现有的预算层级(Gemini 3.1 Flash Lite、Claude Haiku 4.5)便宜得多。** 在该规范上获得 60/100 的分数本身并不是使用它的理由,但成本是。对于可以接受粗略初稿和人工审查的任务,$0.02 每次尝试的成本会显著改变决策。 **Claude Opus 4.7 仍然领先。** 规范中更棘手的部分(任何涉及时间、恢复或移动部件之间协调的部分)是其他每个模型失分的地方。Claude Opus 4.7 只有一个可复现的错误,而其他三个模型有更多错误。 **DeepSeek V4 Pro 在这次运行中表现优于 Kimi K2.6。** 它得分高出 9 分,每个 token 列表价格更低,并且在审查下产生大致相同形状的失败。通过 DeepSeek 截至 5 月 31 日的官方折扣,成本差距进一步扩大。 **DeepSeek V4 Flash 是一个新类别。** 在没有清理环节的情况下,对于复杂的后端构建来说,它并不是完全可靠的。但是,为如此规模的后端首次尝试支付 $0.02 是一个以前不存在的价格点。如果你能接受不完美的输出,那么决策就会改变。 #### 关于此帖的讨论 ### 准备了解更多?

相似文章