OpenCode 公布的一组数字把 DeepSeek Flash 推上了热搜：8 月 1 日单日处理 8 万亿 tokens，其中 5 万亿来自免费使用，另外 3 万亿来自 OpenCode Go。相关帖子获得 79.8 万次浏览，随后出现了“DeepSeek 一天消耗了 8 万亿”的微博话题。
这个数字足够惊人，但对开发团队更有价值的问题不是“8 万亿有多大”，而是：tokens 如何统计、免费流量会怎样改变产品负载，以及 AI 编程工具该如何建立自己的用量账本。
8 万亿 tokens 代表流量，不等于 8 万亿次请求
Token 是模型处理文本的计量单位，一次请求通常同时包含输入和输出：
total_tokens = input_tokens + output_tokens
AI 编程工具的输入可能包括系统提示词、用户指令、当前文件、相关代码、对话历史以及工具执行结果。一次看似简单的“修复这个函数”，经过多轮检索、生成和验证后，累计 token 数可能远高于用户直接输入的文本。
因此，8 万亿 tokens 不能直接推导出用户数、请求数或生成了多少行代码。缺少平均上下文长度、平均输出长度、重试率、缓存命中率和活跃用户数时，下面这些结论都不能从总量单独得出：
- 有多少独立开发者使用了服务；
- 每个用户发起了多少任务；
- 推理成本和服务利润是多少；
- 流量中有多少来自自动重试或 Agent 循环；
- 统计口径是否包含缓存读取、工具结果和内部请求。
标题中的“消耗”也容易让人误解。对工程系统而言，这更接近模型处理量，而不是可以直接换算为某个固定金额的资源账单。
5 万亿免费用量，暴露的是容量设计问题
根据 OpenCode 公布的数据，8 万亿 tokens 中有 5 万亿来自免费使用，3 万亿来自 OpenCode Go。免费部分占总量的 62.5%。这说明至少在该统计日，免费入口承担了主要流量。
免费套餐能快速降低试用门槛，但它也会把压力传递到整个调用链：API 网关需要处理突发请求，调度器需要限制并发，模型服务需要维持吞吐，产品侧还要识别脚本滥用、无限循环和异常重试。
对于 Agent 型编程工具，只限制“每天可发送多少条消息”通常不够。一个任务可能触发多次模型调用，因此更实用的控制维度包括：
- 每分钟请求数与并发任务数；
- 每日输入、输出及总 token 配额；
- 单次请求的最大上下文和最大输出；
- 单个 Agent 任务允许的最大步骤数；
- 超时、重试次数和重复请求去重；
- 免费、付费与内部流量的独立标签。
这些指标能区分“用户增长”和“单个工作流失控”。两者在总 token 曲线上可能看起来完全相同，处理方式却截然不同。
可以这样实践：建立一份可审计的 token 账本
来源没有给出 OpenCode 或 DeepSeek Flash 的具体计费 API。下面是一个可改造的通用示例，假设模型响应中已经包含 usage.prompt_tokens 和 usage.completion_tokens。脚本只使用 Python 标准库，可以直接运行。
将以下内容保存为 token_ledger.py，然后执行 python token_ledger.py：
from collections import defaultdict
from datetime import datetime, timezone
import json
responses = [
{
"plan": "free",
"model": "deepseek-flash",
"usage": {"prompt_tokens": 12000, "completion_tokens": 1800},
},
{
"plan": "go",
"model": "deepseek-flash",
"usage": {"prompt_tokens": 8400, "completion_tokens": 2200},
},
{
"plan": "free",
"model": "deepseek-flash",
"usage": {"prompt_tokens": 15600, "completion_tokens": 3100},
},
]
ledger = defaultdict(lambda: {"requests": 0, "input": 0, "output": 0})
for response in responses:
usage = response["usage"]
key = (response["plan"], response["model"])
ledger[key]["requests"] += 1
ledger[key]["input"] += usage["prompt_tokens"]
ledger[key]["output"] += usage["completion_tokens"]
report = {
"generated_at": datetime.now(timezone.utc).isoformat(),
"groups": [],
}
for (plan, model), values in sorted(ledger.items()):
report["groups"].append(
{
"plan": plan,
"model": model,
**values,
"total": values["input"] + values["output"],
}
)
print(json.dumps(report, ensure_ascii=False, indent=2))
接入真实服务时，应把示例中的 responses 替换为 API 返回值，并额外记录 request_id、租户、任务类型、缓存状态、延迟和错误码。不要记录完整提示词或源代码，除非已经获得授权并设置了严格的保存周期与访问控制。
如果服务端提供 Prometheus 指标，可以进一步按套餐和模型累计 token：
ai_tokens_total{plan="free",model="deepseek-flash",direction="input"} 27600
ai_tokens_total{plan="free",model="deepseek-flash",direction="output"} 4900
ai_tokens_total{plan="go",model="deepseek-flash",direction="input"} 8400
ai_tokens_total{plan="go",model="deepseek-flash",direction="output"} 2200
标签必须保持低基数。不要把用户 ID、请求 ID 或仓库名放进 Prometheus 标签，否则监控系统自身可能先被时间序列数量拖垮。这些明细更适合写入日志、数据仓库或专门的计量系统。
从热搜数字回到工程决策
单日 8 万亿 tokens 展示了 AI 编程工具可能形成的巨大模型流量，也提醒团队不要只盯着订阅价格或消息条数。OpenCode 的数据属于一家工具在特定日期公布的统计，不能直接代表 DeepSeek 的全部平台流量，也不应被外推为整个市场规模。
准备接入类似模型时，可以用下面的清单做上线检查：
- 明确输入、输出、缓存和重试是否计入 token；
- 分开统计免费、付费、测试与内部流量；
- 给 Agent 设置步骤、并发、时间和 token 上限；
- 对异常增长按用户、版本、任务类型和模型拆分；
- 在保存提示词、代码和遥测数据前完成隐私评估；
- 用真实工作负载压测，不用单次聊天请求代替 Agent 场景。
8 万亿是传播力很强的数字，但成熟的工程判断要继续追问统计口径、流量结构和单位任务效率。真正值得长期优化的指标，不只是一天处理了多少 tokens，而是每百万 tokens 完成了多少有效任务。