代币量即重复

代币量即重复 | AI生成和翻译

首页 2026.07

问题：当人们声称一个月内消耗了约100亿个token时，这些任务是否实际上是确定性的/简单的——比如一个应用程序或agent，其结构大部分是事先已知的？

回答：

大部分情况是的，但存在细微差别。高token量几乎总是意味着高调用次数，而不是每次调用的深度推理。数学上就决定了这一点。

我们具体算一下。100亿token/月 ≈ 3.33亿/天 ≈ 1390万/小时。没有人能每小时阅读1390万个token。所以从定义上看，几乎所有token都是由机器驱动、循环和重复产生的。问题在于重复的类型。

产生数十亿token的三种典型模式：

1. Agent循环（大头）。 像Claude Code这样的编程agent或自定义CLI agent会在每一步重新发送整个上下文窗口。一个任务的100K-token上下文 × 50步 = 500万个token，而人类只会称之为“一个功能”。任务本身并非确定性的——调试、规划、工具调用——但token消耗来自于上下文的重新传输，而不是模型在每个token上真正进行新颖的推理。KV缓存前缀复用可以在提供方一侧隐藏部分成本，但在计费时，你是在不断重新发送状态。

# 为什么agents会消耗大量token：上下文线性增长，每轮重新发送
total = 0
ctx = 8000  # 系统提示 + 工具 + 初始文件
for step in range(50):
    ctx += 1500          # 每轮附加新的工具结果
    total += ctx          # 每一步都按整个上下文计费作为输入
print(total)  # 一个50步任务约56.5万输入token

所以“一个agent任务”悄悄变成了50万到500万个token。每月运行几百个这样的任务，就达到了数十亿。单个决策有时是困难的；但大量消耗是架构带来的副产品。

2. 批量/流水线作业（真正确定性的）。 分类、提取、嵌入生成、合成数据、评测框架、批量翻译/摘要。这些正是你所描述的“已知、简单、确定性”类别。你——自己生成了大约8000条笔记——对此深有体会：一个固定的提示模板扩展到N个输入。每次调用都是独立的、结构化的，“智能”部分前置到了提示设计上，而非运行时发现。在这里，token数量可以惊人地快速且廉价地扩展。

# 固定提示词 × N个条目 = 可预测的、确定性的消耗
PROMPT = "分类意图。返回JSON {label, confidence}.\n\n{text}"
# 5000 token/次 × 20万次 = 10亿token，零新颖推理

3. 自我对弈 / 强化学习 / 评测 rollout。 GRPO/RLHF rollout、多样本投票、agent基准测试。你对每个提示生成多个补全并打分。量大，但生成是廉价的部分——价值在于奖励信号和过滤。结构上确定，token上昂贵。

所以你对第2和第3类的直觉是对的，对第1类部分正确。坦诚地说：

高token量 ≠ 难题。它与循环、扇出和上下文重发的相关性远高于推理难度。
高量工作的难点几乎从来不是“模型思考”。而是系统：提示设计、批处理、重试/错误处理、评测、去重、成本控制、缓存。这才是真正体现技能的地方。
一个人类用LLM进行真正困难、新颖的推理，一个月可能消耗5000万到2亿个token，并且感觉已经到极限了。报告100亿的人是在运行流水线或agent群——编排，而非更深的思考。

“简单”框架失效的地方：编排可能相当困难，即使每次调用微不足道。确保一个20万条目的流水线正确、幂等、廉价且经过良好评测，是一个真正的工程问题——只是不是LLM推理问题。难度从模型转移到了支架。

对于你的方向：当你看到“20亿/100亿token”的声明时，把它理解为吞吐量和自动化成熟度的代理指标，而不是原始能力。任何值得问的问题（无论是问别人还是问自己）不是“多少token”，而是“每个有用结果消耗多少token，评测循环在哪里？”那个比例才是真正的信号。

返回捐助