模型分析

豆包 / 阶跃追加测试日志简报

数据口径

• 原始日志和账单截图只保留在本地归档，不随公开页面或 GitHub 发布；公开版只发布汇总表、交叉对比 CSV 和结论。
• 抽取数据在 extracted/：平台账单、OpenCode 逐轮调用/耗时/得分、历史模型粗略参照、cross-model-comparison.csv 横向对比表。
• 2026-06-24 后公开 /test 默认采用复合评分：graph-weighted 基础分 + 全量图谱稳定性复核。旧 graph-weighted 文件保留为归档证据。
• “调用数”采用 OpenCode 本地数据库里的 assistant message 数，近似为 LLM API 往返次数。平台日志本身没有逐请求调用数。
• Step 平台账单和 OpenCode token 口径不同；Doubao 新增了控制台截图口径，以下把平台侧统计与 OpenCode 运行统计分开看。
• 追加前模型的现金花费来自用户补充账单口径：Claude Opus 4.8 202.5 元、Kimi 164.6 元、Qwen 23.5 元、MiniMax 23.2 元、DeepSeek 17.1 元。GLM 5.2 无本地现金账单，按国内 API 价格折算约 40.1-41.6 元。
• 没有各平台逐项账单明细时，不能把总花费精确拆成官方 input/output/cache 单价；本文里的“每百万 cache read token 成本”是 总花费 / OpenCode cache read token 的有效摊销成本，用来比较缓存成本压力。

核心对比

账单与 token

横向位置

成本与缓存

GLM 5.2 的估算采用国内 API 价：输入 8 元/M tokens、输出 28 元/M tokens、缓存命中 2 元/M tokens、缓存存储限时免费。按本地记录的 708,364 输入、249,889 输出、53,939 reasoning、13,709,312 cache read 计算，如果 reasoning token 按输出价计费，总成本约 41.59 元；如果 reasoning 已经包含在输出口径里或不单独计费，总成本约 40.08 元。其中 cache read 本身约 27.42 元，约占总成本三分之二。若完全没有缓存折扣，同样 token 量约 123.85 元，缓存折扣大约省下 82.26 元。

缓存观察：Kimi 的缓存命中 token 很多，达到 24.90M，而且按实付总额摊到每百万 cache read token 是 6.61 元，显著高于 Qwen、Doubao、DeepSeek、MiniMax、Step。因此 Kimi 的实际推理/输出本身未必夸张，但缓存命中 token 体量大、摊销价格高，确实会吃掉大部分成本。MiniMax 则是相反案例：cache read token 最高，38.08M，但总花费只有 23.2 元，每百万 cache read 摊销只有 0.61 元，所以它虽然调用和缓存量最大，现金账单却低。

结论

1. Doubao 的产出质量明显更好，但工程成本也更高。复合均分高 Step 9.34 分，且有 r4/r9 两个 96 分 A 档；但 r6 因知识图谱严重抖动从旧分 100 调整为 88.8。有效 10 轮耗时约为 Step 的 2 倍，含失败/重跑后总耗时 128.91 分钟。

2. Step 不是“低调用一次性完成”的模型。它最终 10 轮调用数 433，高于 Doubao 的 382，只是执行速度很快，平均每轮 5.67 分钟。它的短板主要在图谱和视觉：文章页基本稳定满分，但图谱均分低，拉低总分。

3. Doubao 的“慢”是有数据支撑的。它最终调用数并不夸张，但单轮耗时长，且有 8 个非最终 session，说明中断、重跑、重复尝试成本高。也就是说，它不是疯狂调用型，而是慢调用加重跑型。

4. Doubao 平台截图的调用数是 477，高于 OpenCode benchmark 相关 session 的 449。这个差额不改变结论，反而说明平台账单口径更宽，可能把烟测、失败启动、非最终尝试或 provider 侧额外请求也算进去了；排行榜分析仍以 OpenCode session 口径做逐轮对比。

5. 调用数和分数不是线性关系。Doubao 的高分轮次 r4/r6 都是 50 次左右调用，r9 只有 31 次也拿到 96；Step 的 r7 调用 79 次但只有 75.4，r6 调用 25 次反而拿到 87.8。真正决定分数的还是图谱是否做实。

6. 和本机同目录历史 OpenCode 记录粗略对照：Qwen3.7 约 218 次调用、53 分钟；Kimi K2.7 Code 约 423 次调用、90 分钟；MiniMax M3 约 653 次调用、154 分钟。Step/Doubao 的总调用数都接近 Kimi，但 Step 明显快，Doubao 更慢且重跑更多。

7. Doubao 的质量位置确实不是第一梯队：它排在 Kimi 之后、MiniMax 之前，领先 MiniMax 只有 0.20 分。它赢 MiniMax 主要靠图谱项更高（14.7 vs 11.9）和文章项略稳；视觉项反而明显不如 MiniMax（14.9 vs 18.8），所以肉眼看会觉得 MiniMax 更像“好站点”。

8. Doubao 的价格压力不是来自“调用数特别高”。它的调用数低于 MiniMax，但高于 Kimi/GLM/Opus/Qwen/DeepSeek；可见 token 负载也低于 MiniMax 和 Kimi。Doubao 的实付 41.34 元高于 Qwen/MiniMax/DeepSeek，主要是因为 token 负载比 Qwen/DeepSeek 大，且不像 MiniMax/Step 那样有极低的缓存摊销成本。它不是最烧调用的，但性价比不如 Qwen、MiniMax、DeepSeek。

9. Opus 和 Kimi 是现金成本最重的两档。Opus 只有 306 次 OpenCode 调用，但花费 202.5 元，说明贵在单价和缓存摊销，而不是调用次数。Kimi 调用数 423 次、cache read 24.90M，现金 164.6 元；它的缓存命中 token 很多，而且摊销成本高，是这次高账单的核心解释。

10. GLM 5.2 如果按当前国内 API 价格折算，成本并不属于 DeepSeek/MiniMax 那种低价档，而是大约与 Doubao 持平。但因为它本轮复合均分第一，单位分数成本约 0.48 元，显著优于 Doubao、Kimi 和 Opus；它更像“中等偏高成本、高质量产出”的位置。

简短判断

Doubao 更像“质量略高于 MiniMax、低于 Kimi，但现金成本和耗时偏重”的模型；Step 更像“跑得很快，文章产物完整，现金成本极低，但图谱和视觉容易薄”。如果排行榜只看最终产物，Doubao 的复合分有价值，但 r6 的抖动不能再按满分理解；如果未来加一个工程效率维度，Doubao 会被耗时/实付成本扣分，Step 会在耗时和现金成本上加分，但不会在调用数上占优。缓存成本维度上，Kimi 和 Opus 最值得单独标注：它们不是简单“生成多”，而是大量 cache read token 以较高摊销价格进入账单。