将LLM使用规模扩展至数十亿标记 | AI生成和翻译

Home 2026.05

问题：一个人如何能在一年内消耗约 100 亿个 token（使用大语言模型），已知有哪些这样的人（例如来自 TiDB 的黄东旭）？

答案：

若真想达到每年数十亿 token 的消耗量，仅靠日常闲聊是无法实现的。你需要将 LLM 的使用视为系统化、高吞吐量的工作流，而非偶尔的提示输入。

让我们理性拆解一下。

1. “每年 100 亿 token” 的实际含义

100 亿 token/年 ≈

~2700 万 token/天
~110 万 token/小时（24 小时连续运行）

这已超出人类交互的范畴。这是流水线 + 自动化的规模。

所以，如果你想像“只是多提几个问题”那样操作，是行不通的。你需要机器向机器提问。

2. 达到此规模的仅有 3 种方式

（A）程序化使用（最重要）

不是：

你 → 提示 → 阅读 → 提示

而是：

代码 → 生成提示 → 发送给 LLM → 处理输出 → 循环

典型模式：

批量处理数据集
自动评估循环
合成数据生成
多智能体模拟

示例：

for item in dataset:
    response = llm(prompt_template(item))
    store(response)

仅此一项，每小时就能生成数百万 token。

（B）迭代式流水线（LLM 调用 LLM）

重度使用者并非只调用一次——他们会串联调用：

草稿 → 评审 → 改进 → 总结 → 评估
或者：
- 生成器模型
- 评审器模型
- 优化器模型

这会将每项任务的 token 使用量增加 5–20 倍。

（C）长上下文工作流

使用：

32k / 128k / 1M 的上下文窗口

活动包括：

输入整本书/代码库
重复再分析
基于记忆的智能体

单次运行即可消耗：

数十万到数百万 token

3. 你达到高 token 使用量的实用方法

如果你的目标是刻意为之（学习/构建），以下是一些具体策略：

1. 构建一个“思考循环系统”

不要只问一次：

提问 → 获得答案
让模型进行评审
让模型进行改进
让模型进行压缩
重复

这将使得：

1 次提示 → 10–50 次提示

2. 对所有阅读内容使用 LLM

你提到：

提示 + 阅读 + 迭代

将其升级为：

粘贴文章/书籍/代码
提问：
- 总结
- 提取结构
- 生成问题
- 辩论正反方

你将 token 使用量乘以：

输入 token（大量）
输出 token（大量）

3. 合成数据生成

这是真正构建者所做的：

生成：
- 问答对
- 训练数据
- 边界案例
然后：
- 过滤
- 评分
- 重新生成

这正是人们消耗数十亿 token 的方式。

4. 持续后台作业

运行脚本，例如：

“每天生成 1 万个问题”
“模拟 1 千次对话”
“将数据集重写 5 遍”

这是你从：

数百万 → 数十亿 跨越的方式。

5. 多智能体系统

创建能进行以下活动的智能体：

辩论
规划
执行
反思

每一步 = 多次 LLM 调用。

这会自然地使 token 使用量激增。

4. 已知的极端 LLM 使用者

黄东旭

在工程圈内以以下方面闻名：
- 深入的技术探索
- 重度实验心态
代表了 “通过大规模实践学习的构建者” 这一原型。

Andrej Karpathy

谈及：
- “token 是新的计算单位”
- 将 LLM 视为可编程系统
鼓励高容量的实验。

Sam Altman

曾提到：
- 部分用户消耗巨大的 token 量
内部的重度用户是：
- 研究人员
- 构建流水线的初创公司

Emad Mostaque

倡导：
- 大规模生成
- 合成数据循环

5. 现实考量（重要）

如果你进行的是：

手动提示 + 阅读

你可能达到：

100 万–1000 万 token/年（已是重度使用）

要达到：

10亿+ token → 需要自动化
100亿+ token → 需要基础设施

因此，真正的转变是：

从“用户” → “系统构建者”

6. 一个更好的思维模型

这样思考：

Token = 燃料
提示 = 程序
LLM = CPU

如果你想消耗燃料： → 你需要持续运行的程序

7. 为你量身定制的实用路径（基于你的背景）

鉴于你已：

从事机器学习
构建系统

你应该尝试：

构建一个数据集生成器
添加：
- 评估循环
- 改进循环
每日运行

仅此一项就能将你推入：

1亿–10亿 token/年 的范围

如果你愿意，我可以为你量身设计一个个性化的“100亿 token 系统架构”（基于你的全栈 + ML 技能）。

Back Donate