先给结论：如果主要是纯文本、代码修改和高频 Agent 循环，先试 DeepSeek V4 Flash；如果任务必须理解截图、图表、扫描文档或视频，直接把 Kimi K3 放到首选；如果你愿意为更强的仓库适配多付一些钱，但又不想承担 Kimi 的直连价格，就让 GLM-5.2 与 Flash 做一轮同仓库测试。
这不是“国产大模型总排名”。三者都宣称支持约 100 万 tokens 上下文，真正会改变选择的是：输入模态、推理控制、API 单价，以及在你的验收条件下能否一次完成任务。
本文价格和产品事实核验于 2026 年 8 月 6 日，之后可能调整。
先按任务选，不要先按跑分排队
| 你的任务 | 先测谁 | 为什么 |
|---|---|---|
| 纯文本、代码生成、批量 Agent | DeepSeek V4 Flash | 官方直连 token 价格最低，适合先扩大样本再谈胜负 |
| 图像/视频理解、视觉参与的长任务 | Kimi K3 | 三者中官方模型卡明确标注原生多模态 |
| 复杂仓库任务，Flash 反复返工 | GLM-5.2 | 官方直连价位居中，支持多档推理强度，适合作为代码 Agent 挑战者 |
| 需要 provider 独有功能 | 对应官方 API | 聚合接口未必完整复现推理、缓存和多模态 contract |
先核对准确名称：deepseek-v4-flash 不是 DeepSeek V4 Pro；kimi-k3 不是 Kimi K2.5 或 K2.6。把 Pro 的 benchmark 放进 Flash 一列，或者拿旧 Kimi 的价格推导 K3，都会让结论失真。
DeepSeek 的官方价格页列出了 thinking/non-thinking、tool calls、JSON 输出与 384K 最大输出；官方模型卡显示它是 284B 总参数、13B 激活参数的 MoE，并以 MIT 许可开放权重。
Kimi 的K3 官方价格页说明模型始终进行推理，可用 low、high、max 调整 reasoning_effort；Kimi K3 模型卡标注 2.8T 总参数、104B 激活参数和原生多模态。它采用 Kimi K3 License，不应被简单写成 MIT。
GLM-5.2 的官方模型卡强调 1M 上下文、长任务、编程和多档推理强度，也提供本地部署路线与 MIT 许可。参数规模或厂商定位只能说明“值得测什么”，不能替代你的仓库验收。
同一 token 结构下，官方直连成本差多少？
只看“每百万输出多少钱”仍然不够。这里固定一个容易复算的工作量：100 万未缓存输入 + 10 万输出。
- DeepSeek V4 Flash：
1 × $0.14 + 0.1 × $0.28 = $0.168 - Kimi K3：
1 × $3.00 + 0.1 × $15.00 = $4.50 - GLM-5.2：
1 × $1.40 + 0.1 × $4.40 = $1.84
这些数字来自三家当前官方价卡，只代表这组输入/输出假设。它们没有计算税费、工具调用、重试、缓存写入和第三方 provider 加价，也不是订阅产品的一次会话报价。
真正适合采购的公式是：
每个成功任务成本 = 全部尝试的输入、缓存、输出、工具和重试费用 / 最终通过验收的任务数
假设 Flash 做一次只要几分钱，但连续三次都未通过 tests，那么“单次请求便宜”还不能说明“交付便宜”。反过来，Kimi K3 的文本 token 价格明显更高，它必须通过多模态能力、显著更少的人工介入或更高的一次通过率，把价差赚回来。
缓存命中会改变账单，但不会自动发生
核验时的缓存输入价分别是：DeepSeek $0.0028/M、Kimi $0.30/M、GLM $0.26/M。对重复系统提示词、稳定仓库地图和固定资料包，缓存设计可能比榜单上的一两分更影响总成本。
不要把“支持缓存”理解成“整个请求都会命中”。应记录 provider 返回的 cached tokens，把稳定前缀和持续变化的工具结果、用户指令、生成历史分开。如果使用第三方网关，要按网关自己的缓存规则和价卡计算，不能直接套上游数字。
三个模型各自在什么条件下更合理？
DeepSeek V4 Flash：低成本扩大测试样本
Flash 最适合先做有明确验收的文本与代码任务：修复 bug、实现有 tests 的小功能、批量转换或多轮工具调用。它的低直连价格让团队可以用 20 个真实任务，而不是一个漂亮 demo，判断模型是否稳定。
简单改写可先试 non-thinking；规划、调试和多步骤工具任务再启用 thinking。不要从“13B 激活参数”直接推导 tokens/s：最终速度还受 provider 硬件、排队、输出长度和 Agent harness 影响。
Kimi K3：让多模态成为硬门槛
如果 Agent 必须读截图、图表、页面渲染、扫描件或视频，Kimi K3 的原生多模态会直接改变候选集。此时不必强行让两个文本模型靠 OCR 或外接视觉模型拼接成“同一场比赛”。
但多模态以外的文本任务，需要更严格的收益标准：是否显著减少澄清和返工？是否能完成另外两者无法完成的长任务？是否让每个成功结果的总成本下降？调用生产媒体前，还应重新查看 hosted API 当前接受的媒体格式；开放权重模型卡不等于云 API 的完整请求 contract。
GLM-5.2：用仓库表现证明中间价位
GLM-5.2 同样面向长任务与代码 Agent，官方价位处在 Flash 与 K3 之间。它适合在 Flash 出现循环、遗漏项目约束、工具调用修复过多时作为第二候选。
“价格居中”不是优势本身。如果 GLM 与 Flash 的通过率、人工介入和总耗时接近，就保留更便宜或更容易运维的一方。只有 GLM 在第二批代表性任务上也持续减少返工，它的溢价才有证据。
为什么你看到的榜单会互相打架？
模型卡里的 benchmark 可以帮助提出假设，但不同表格往往使用不同条件：
- Agent harness 的文件选择、上下文压缩和工具修复不同；
reasoning_effort、temperature、最大输出和重试次数不同；- 有的任务允许联网或工具，有的完全离线；
- judge、任务版本、超时与成功判定不同；
- 官方直连与第三方 provider 的延迟、限流和缓存不同。
因此，一个 coding benchmark 领先与另一个长任务 benchmark 落后可以同时成立。没有公开任务集、provider、缓存状态和完整配置的热帖数字，只能当作“值得复测”的线索，不能直接指导采购。
用 10–30 个私有任务做同条件测试
选择能代表真实付费工作的任务：多文件 bug、带 tests 的小功能、一次资料与数据综合、或需要数次工具调用的支持流程。不要用一道玩具题，也不要一开始就投进去一周迁移项目。
- 三个模型从同一 commit、相同文件和同一份需求开始。
- 尽量使用同类 provider；不要把拥堵的免费端点与付费高性能端点写成模型差异。
- 固定工具权限、上下文包、推理强度策略、timeout 和重试预算。
- 运行前定义验收：tests、schema、事实校验、页面截图或业务结果。
- 记录通过率、人工介入、端到端耗时、输入/输出/cached tokens、工具费和重试。
- 对临界任务复跑，最终比较“每个被接受结果成本”。
| 记录项 | 应写下什么 |
|---|---|
| 验收结果 | 通过/失败，以及未通过哪项检查 |
| 人工介入 | 追问、审批、手工修复、重启次数 |
| 端到端耗时 | 从开始到可接受结果，而非首 token |
| 计费 | 未缓存输入、缓存输入、输出和工具费用 |
| 运行摩擦 | 工具格式错误、丢上下文、拒绝、重试 |
| 最终经济性 | 全部费用 ÷ 被接受结果数 |
当某个模型缺少硬性模态、超出预算上限，或在第二批代表任务中仍稳定领先时，就可以停止比较。如果差异还落在正常波动内，先保留更便宜的默认项，等模型或工作流有实质更新再复测。
最终建议：先给谁第一批真实任务？
对大多数纯文本和代码团队，先把第一批任务交给 DeepSeek V4 Flash，因为当前官方直连价差足以支持更大的测试样本。Kimi K3 是多模态和高价值长任务的专用选择。GLM-5.2 是需要用更少返工来证明自己的代码 Agent 挑战者。
需要某家的特定推理、缓存或多模态 contract 时，优先使用官方 API。如果希望用统一的 OpenAI-compatible 接口管理多模型，可以查看老张 API 文档和实时 Models 列表；不要在未查看当前控制台前假设三者已经全部可用。如果你的候选还包括西方闭源 coding agent，可继续看同语种的 GPT-5.6 Sol 与 Claude Fable 5 选型。