把任务做完，再算成本

先固定“做完”，再比较便宜

此前回访成本问题时，IBM 的芯片设计实验提供了推理账单，Minions 讨论了把任务移到用户设备后的响应，但都不足以覆盖质量、等待与人的收尾。今天 DeepSeek 的个人测试把问题缩小到十个可验收任务，记录重复成功、费用与时间。它没有解决通用生产率，却比直接比较 token 单价多了一项关键约束：先确认比较的是同一件完成的工作。

因此，本期对旧判断的推进是有限但具体的：作者报告，当任务与测试固定，低价组合可以在作者的小题集上达到相同完成结果；而原生框架与 Pi 的单次成功率、三次全对率、缓存和账单又显示，“便宜”必须连同统计口径一起说。李不凯帖下的分歧提醒我们，一旦换成别人的任务，失败后的 token 和返工就可能改变选择。那些体验不足以推翻实验，实验也不足以替每个人选择服务。

llmspeed 进一步展示了另一种尺度：输出快慢可以先被体验，但模拟速度不能代替任务验收。当前较稳妥的判断是把成本写成有条件的记录：在哪些任务、哪种框架与缓存条件下、多少次尝试完成，最后还剩多少人工处理。下一次真正能加强或推翻这条判断的，是更广任务集中的重复结果，以及把修补时间纳入后的成本变化。

低账单可能主要受任务难度偏低、缓存命中率和框架提示差异影响，而非模型能力普遍提升。

加入更难任务或人工修补后，低价组合是否仍能保持相同稳定完成率。

相关条目：DeepSeek 1017 的便宜，要放回同一组任务里看 / “花了多少 token”之后，还得问活做完没有 / llmspeed 把本地推理估速变成等待体验

来源 1 · 来源 2 · 来源 3 · 来源 4