模型的时薪：为什么 Token 单价还不够

我们已经习惯用每百万 Token 的价格比较模型。

输入多少钱，缓存多少钱，输出多少钱。数字精确到小数点后好几位，排行榜看起来一目了然。可这种精确有时很像超市货架上的每克单价：它准确描述了计量单位，却没有回答你究竟要花多少钱吃饱。

如果模型只是一个补全文本的 API，Token 或许已经够用。但当模型开始读仓库、调用工具、等待网络、修改文件、运行测试，并在十几分钟后交付一项工作，Token 就越来越像一种内部原料。使用者真正感受到的，不再只是消耗了多少字符，而是它占用了多少时间、完成了多少工作，以及在此期间人需要等多久。

于是，一个有些冒犯、却很难摆脱的问题出现了：

如果把模型看成一种正在提供认知劳动的生产要素，它的时薪是多少？

从一张价目表到三张账

要看见模型时薪，不能只看厂商价目表，还要把价格放回真实请求。

一份约 168 万条脱敏消费日志的快照，保留了模型、渠道、输入与输出 Token、首字响应时间和总请求时长。过滤到具有有效时间字段的流式请求后，约 88 万条记录可以进入时间分析。最终可视化覆盖 38 个模型、114 个“模型 × 渠道”组合，并把同一批请求展开成三张账：

• “平均 Token”描述每次请求搬运了多少上下文、复用了多少缓存、生成了多少内容。
• “费用/请求”描述按照给定价格表，每完成一次调用要付多少钱。
• “隐含时薪”描述这些费用落在实际占用时间上，形成了怎样的单位时间价格。

三张账没有哪一张更“真实”。它们只是回答不同问题。平均 Token 是工作量，费用/请求是账单，隐含时薪是费用密度。

同一个模型在不同渠道上的结果尤其能说明这一点。以快照中的 DeepSeek V4 Flash 为例，两个主要渠道呈现出这样的关系：

指标	渠道 A	渠道 B
平均非缓存输入	约 12.3K Token	约 2.2K Token
平均输出	约 781 Token	约 628 Token
输入隐含时薪	约 $0.57/h	约 $1.02/h
输出隐含时薪	约 $0.080/h	约 $0.089/h
总隐含时薪	约 $0.371/h	约 $0.282/h

渠道 A 每次处理的输入明显更重，单次费用也更高；但它的输入和输出分阶段时薪反而更低，因为相同类型的费用分摊在更长的时间上。与此同时，它的总时薪又更高，因为总时薪把请求中的全部费用结构放回总时长，工作量差异重新占据了主导。

这不是统计上的矛盾，而是一个提醒：所谓“模型的时薪”从来不是一个孤立标量。它至少是一组同时描述输入处理、输出生成、缓存复用与整体吞吐的指标。

什么是模型的隐含时薪

模型并没有工资卡。这里的“时薪”不是厂商报价，而是一个派生指标：把某类 Token 费用除以它对应占用的时间，再折算到一小时。

对于流式文本请求，可以先采用一套可操作的归因：

输入阶段时间 = 首字响应时间
输出阶段时间 = 总请求时长 - 首字响应时间

输入隐含时薪 = 输入费用总额 / 输入阶段时间总额 × 3600
输出隐含时薪 = 输出费用总额 / 输出阶段时间总额 × 3600
总隐含时薪 =（输入费用 + 缓存费用 + 输出费用）总额 / 总请求时长总额 × 3600

这里故意使用“总额除以总时间”，而不是先算每条请求的时薪再取平均。后一种做法会让极短请求产生巨大的比率，并由少数分母接近零的样本控制结果。

这三个数也不能混成一个数：

• 输入隐含时薪衡量首字出现前，输入费用相对于等待时间的密度。
• 输出隐含时薪衡量持续生成阶段，输出费用相对于生成时间的密度。
• 总隐含时薪把缓存也计入费用，更接近整段请求占用时间上的综合价格。

“隐含”两个字很重要。首字时间不等于纯粹的输入计算时间，它还可能包含排队、路由、网络、前缀缓存查找和上游调度。把它归到输入阶段，是一种运营上的分摊办法，不是对模型内部计算过程的物理测量。

所以，模型时薪不是藏在 API 里的客观常数。它始终是下面这个函数的结果：

模型时薪 = f（模型、渠道、请求结构、缓存策略、延迟、价格版本、统计窗口）

离开这些条件，只谈“某模型时薪多少”，就像离开城市、资历、工种和工时制度谈一个人的工资。数字仍然可以说出口，但含义已经所剩无几。

时间在分母上

时间在分母上。费用相同的情况下，越慢，隐含时薪越低，而不是越高。

如果时薪是从既有 Token 费用反推出来的，那么更长的耗时会摊薄单位时间价格。一个渠道可以同时满足：

• 每次请求更贵，因为它承接了更长的上下文或更多输出；
• 隐含时薪更低，因为处理这些请求花了更久；
• 用户体验更差，因为人等待首字的时间更长。

这三句话并不矛盾。它们分别描述请求账单、机器吞吐和人的等待体验。

这使模型时薪与人的等待成本呈现出一个有趣的反向关系：模型越慢，派生出来的模型时薪可能越低；但人被阻塞得越久，整个系统付出的人力成本却越高。

也正因如此，“低时薪”未必是赞美。它可能意味着模型便宜，也可能意味着模型慢。对于后台批处理，前者很有吸引力；对于人坐在屏幕前等待的交互式任务，后者可能把节省下来的 API 费用，以更昂贵的人类时间重新付一遍。

这也解释了为什么模型时薪不能脱离服务等级来比较。同样是 $1/h，在允许排队的夜间批处理任务中可能极具竞争力，在需要工程师实时协作的调试任务中却可能昂贵得不可接受。价格相同，时间的机会成本不同。

Token 价格回答的是生产者问题

Token 是非常出色的计费单位。它可数、可审计，与计算量存在关联，也方便供应商把不同长度的请求放进同一张价目表。

但它主要回答的是生产者问题：这次推理消耗了多少可计量资源，我该收多少钱？

使用者真正面对的通常是另一组问题：

• 我多久能拿到第一个可用反馈？
• 一小时内能完成多少次有效迭代？
• 为了得到可接受结果，需要重试几次？
• 人要花多少时间等待、检查和返工？
• 上下文复用和缓存究竟节省了成本，还是只改变了账单结构？

这就像云计算从“每核秒多少钱”走向“每笔订单的基础设施成本”。前者是资源计量，后者才进入单位经济学。

模型时薪的意义，正在于它把机器世界的 Token 第一次翻译成了人类组织熟悉的时间。Token 很难与工程师的等待成本直接相加，小时可以。

模型小时不是钟表小时

时间成为计价单位之后，并行也有了更清楚的表达。

十个 Agent 各自工作六分钟，一共消耗一个模型小时；但如果它们同时开始，人只需要等待六分钟。模型小时是可以相加的资源消耗，钟表小时则是人实际经历的交付时间。

这两种时间的分离，是 Agent 经济学与传统人力经济学最大的不同之一。人的一个工作小时通常无法被无损复制，模型小时却可以通过并发在更短的日历时间里集中购买。组织面对的不再只是“用哪个模型更便宜”，还包括“愿意为缩短多少等待时间，多购买多少并行模型小时”。

于是，模型时薪可以把并行策略放在一条成本与速度的前沿上：

• 串行执行消耗较少的并发容量，但交付更慢。
• 并行探索会重复读取上下文、产生更多 Token，却可能显著缩短人的等待。
• 当任务存在多个可独立验证的分支时，增加模型小时可能降低钟表时间和人力机会成本。
• 当任务高度依赖同一条推理链时，盲目并行只会增加费用，不会等比例加快交付。

Token 账单能告诉我们并行多花了多少原料，模型时薪则开始告诉我们：这些额外资源换回了多少时间。

缓存是一种上下文资本

在 Agent 工作负载里，缓存不只是输入费用中的一个折扣项。它更像一种上下文资本：过去已经读取和组织过的仓库、文档、指令与对话状态，可以在后续任务中反复使用。

普通输入是当期消耗，缓存则把过去的计算带进现在。缓存命中率越高，同一段上下文服务的任务越多，前期建立上下文的成本就被摊得越薄。这与工厂购买设备、团队建设知识库有相似之处：成本发生在前面，价值在多次复用中释放。

但缓存有费用，却未必对应一段能从请求日志中独立辨认的时间。因此，在模型时薪中，更合适的处理是：

• 输入隐含时薪只对应非缓存输入费用与首字时间。
• 输出隐含时薪只对应输出费用与持续生成时间。
• 缓存费用进入总费用和总时薪，但不强行归入输入或输出阶段。

这会让“总时薪”与输入、输出两个分阶段时薪呈现不同方向。它不是两个分阶段数字的简单平均，而是把缓存复用、请求结构与总时长一起纳入后的综合结果。

由此可以得到一个更有意思的经营指标：每单位上下文资本，在其有效期内支持了多少次可验收任务。对长时间运行的 Agent 来说，这个数字可能比单次缓存 Token 价格更重要。

时薪比较有明确边界

时薪只有在费用和时间可以落到同一工作单元时才成立。文本模型通常按输入、缓存和输出 Token 计费，能够与首字时间和生成时间建立相对清晰的对应关系；图像、音频和视频模型则可能按张数、分辨率、音频秒数、生成时长或专用模态 Token 计费。

如果日志只记录通用文本 Token，就不能把这些模型强行塞进同一张时薪排行榜。最终结果中，无法可靠折算的模型会保留原始使用量，但不展示虚构的费用和时薪。

这种边界并不削弱“模型时薪”的价值。恰恰相反，它说明这个指标的目的不是把所有模型压成一个数字，而是为计费单位、耗时阶段和工作成果真正可比的场景建立共同尺度。

时薪不是价值

“模型时薪”很容易让人联想到用 AI 替代谁，或者比较模型与人的工资。这种联想有启发性，也很危险。

时薪只描述单位时间的价格密度，不描述这一小时产出了什么。一个模型可以以很高的隐含时薪快速生成大量无用内容，也可以用更高的单次费用一次解决昂贵问题。就像人类劳动力市场中，工资与价值相关，却从不等同。

如果把可验收任务作为产出，模型时薪还必须除以生产率：

模型成本/有效任务 = 模型隐含时薪 / 每模型小时的可验收任务数

“可验收”是这个公式里最昂贵的三个字。生成一份答案不等于完成一项工作；代码要通过测试，分析要经得起复核，操作要达到预期状态。没有验收，所谓生产率只是输出速度。

如果真正关心一项工作的经济性，至少还要继续走到“任务成本”：

有效任务成本
= API 费用
+ 人类等待成本
+ 审核成本
+ 失败概率 × 返工成本

再往前一步，还要加入结果质量、机会成本和完成速度带来的收益。

这时我们会看到一个反直觉的可能性：Token 单价更贵、模型时薪也更高的模型，只要首遍成功率足够高，最终任务成本反而可能更低。相反，一个极便宜的模型如果需要反复提示、长时间等待和大量审核，它只是把账单从 API 供应商转移给了使用它的人。

所以，可以把模型经济学分成三层：

层次	典型指标	回答的问题
计量层	每百万 Token 价格	消耗了多少原料？
资源层	模型隐含时薪、延迟、吞吐	占用了多少机器与人的时间？
价值层	每个有效任务成本、成功率、返工率	最终买到了什么结果？

Token 价格没有过时。它只是停在第一层。

当模型进入劳动时间

过去的软件几乎不以“工作时长”出现在我们面前。编译器不会因为编译了十分钟，就让人产生它工作了十分钟的直觉；搜索引擎也不会在后台连续操作半小时后回来交付一份报告。

Agent 改变了这种感受。它有任务开始和结束，有等待，有重试，有并行，有监督，也有交付。它越来越像一个占据时间窗口的行动者，而不只是一个瞬时返回值的函数。

当一种技术开始进入劳动的时间结构，人们迟早会尝试用劳动的语言理解它。模型时薪就是这种翻译的早期形式。

它并不完美。它依赖日志口径，无法单独表达质量，也容易被“模型像人”这个比喻带偏。但它迫使我们离开供应商给定的计量单位，转而询问组织真正失去和得到的东西：时间、注意力、迭代速度与完成的工作。

也许未来真正重要的模型价格，不会写成每百万 Token 多少美元，也不会只写成每小时多少美元，而是：在给定质量、监督强度和时间约束下，完成一项可验收工作需要多少钱。

但走到那里之前，我们需要先学会问出中间这个问题。

模型不领取工资。可当它开始像同事一样占据我们的时间，它就已经拥有了某种时薪。