大模型 Token 的消耗可能是一笔糊涂账

作者：望宸

如果您正在部署大模型应用，务必提前和 CEO 打好预防针，大模型应用远不如 Web 应用在资源成本上那么可控。

经典的 Web 应用，例如电商、游戏、出行、新能源、教育和医疗等，CPU 的消耗是可控的，和应用的在线人数和登陆时长成正相关，如果计算资源突增，可能是运营团队在做活动，也可能是预期外的突发流量，通过服务器弹性扩容后，稳定一段时间就会缩容到平时的状态，后端所消耗的资源是可追踪、可管控的。但大模型的 token 消耗并不是。

目录

01 大模型 token 消耗和哪些因素有关

02 大模型 token 消耗的隐蔽性来源

03 Agent 的资源消耗账本更加复杂

04 如何控制 token 的异常消耗初探

05 总结

01 大模型资源消耗和哪些因素有关

根据量子位的一篇文章[1]，当输入“树中两条路径之间的距离”，DeepSeek 就会陷入无限的思考，笔者实测消耗思考时间长达625秒（如下图），输出字数达2万字。这句话并不是复杂且意义不明的乱码，看上去完全就是一个普通的问题，非要挑刺的话，也就是表述得不够完整。

这种无限的重复思考，是模型自身的精神内耗，更会造成算力资源的浪费。如果被黑客滥用，无异于是针对推理模型的 DDoS 攻击。那么大模型的 token 消耗，除了和在线人数和时长有关，还和哪些因素有关呢？

本文仅以 DeepSeek 为例，其他大模型 API 调用的计费规则和影响计费的因子是类似的。

根据 DeepSeek 官方给出的【模型和价格】的计费文档上看[2]，API 调用费用和以下参数有关：

• 模型类型：V3 和 R1 的百万 tokens 的单价不同，R1 因为带有推理功能，定价比 V3 高
• tokens 的输入数量：按百万 tokens 计费，用量越多，费用越高
• tokens 的输出数量：按百万 tokens 计费，用量越多，费用越高，输出单价高于输入
• 是否命中缓存：缓存命中的单价低于未命中的
• 忙时和闲时：闲时的单价更低
• 思维链：会消耗 token 的输出数量

此外，联网搜索过程中的搜索请求和对返回的数据处理（在内容生成前前的过程），也会计入 token 使用。但凡唤醒大模型意识的，其实都会消耗 token。

根据这个计费规则，大模型的资源消耗会和以下因素有关：

• 用户输入文本的长度：用户输入文本越长，消耗的 token 越多。通常 1 个中文词语、1 个英文单词、1 个数字或 1 个符号计为 1 个 token。
• 模型输出文本的长度：输出文本越长，消耗的 token 越多。以 DeepSeek 为例，输出的 token 消耗单价是输入的4倍。
• 用户输入的上下文大小：上下文的情况下，由于模型在生成内容前要读取上几轮的对话内容，会显著增加模型的输入，导致 token 上涨。
• 任务的复杂性：复杂的任务可能需要更多的 token。例如，生成长篇文本（例如论文翻译和解读）、进行复杂的推理（如数学、科学类问题），都需要更多的 token；如果是多模态、复杂 Agent 的形态，通常要比对话机器人消耗的 token 更多。
• 特殊字符、格式和标记：可能会增加 token 消耗，例如，HTML 标签、Markdown 格式或特殊符号会被拆分成多个 token。
• 不同语言和编码方式：对 token 消耗有影响，例如，中文通常比英文消耗更多的 token，因为中文字符可能需要更多的编码空间。
• 和模型自身有关：例如同一个模型，参数高输出的内容翔实程度可能性更多，导致更容易消耗 token，就像越高越壮的人单位运动时内会消耗更多的能量；再例如，推理层未优化或优化少的，输出无效、低质量的内容更多的可能性更高，更容易消耗 token，就像同一个人训练过、掌握技巧后会控制自己的呼吸节奏，运动过程中少消耗能量。
• 是否使用了深度思考功能：输出 token 数包含了思维链和最终答案的所有 token，因此打开深度思考，token 消耗更多。
• 是否使用了联网功能：联网要求模型搜索外部知识库或网站，以获取外部知识，这些会作为输入 token 进行消耗，输出内容包含了外部链接和外部知识库内容，这些会作为输出 token 进行消耗。
• 是否采用了语义缓存功能：由于缓存命中和未命中单价不同，采用语义缓存功能，可以降低资源消耗；若自行进一步优化缓存算法，可以降低更多资源消耗。

02 大模型资源消耗的隐形因素

除了上文提到的因素外，还有不少隐形因素会导致大模型应用资源的异常消耗。

代码逻辑漏洞

• 循环调用失控：因错误配置重试机制，导致单用户会话产生产生重复调用。
• 缓存机制缺失：高频重复问题未启用缓存，导致 Token 用于重复生成相似答案。

提示词工程缺陷

• 冗余上下文携带：若携带完整对话历史，单次请求的 Token 量会大幅增加，上下文对话越长，消耗量越大。
• 低效指令设计：未结构化的提示词，会降低模型生成效率。

生态依赖风险

• 插件调用黑洞：未限制插件调用深度，单次查询触发重复多次链式调用。
• 第三方服务波动：向量数据库响应延迟导致超时重试，间接增加 Token 消耗。

数据管道缺陷

• 数据预处理过程中产生的缺陷：数据清洗、预处理与标准化是提升输入质量的常规手段，例如用户输入时的错别字、缺失值、噪声数据等，可以通过数据清洗、预处理与标准化进行输入补全和纠正，但也存在某种可能，在补全和纠正过程中导致输入缺陷，从而产生资源的异常消耗。

03 Agent 的资源消耗账本更加复杂

说起 Agent，不得不提最近又火起来的 MCP。

1月，我们科普过《MCP十问｜快速理解模型上下文协议》

3月，我们发布《MCP 货币化浅析》

MCP 在大模型和第三方数据、API、系统的交互过程中，用单一的标准协议取代碎片化的集成方式[3]，是 N x N 向 One for All 的演进，省去了不同外部系统接口代码的重复编写和维护工作，能以更简单、更可靠的方式让人工智能系统获取所需数据。

MCP 出现之前，Agent 需要借助 tool 去对接外部系统，planning 的任务越复杂，调用的外部系统数量和次数会越多，会带来很高的工程化成本。以下方的 Higress AI Agent 的流程图为例，当用户发出“我想在北京五道口附近喝咖啡，请帮推荐一下”，Agent 需要通过 tool 调用高德、点评的 API，若引入模型自我矫正过程，调用频次会进一步增加。

MCP 出现之后，将会加速诞生一波提供 MCP server 提供商。

例如 Firecrawl 今年1月通过与 Cline 平台的集成，正式引入了 MCP 协议，用户通过 Firecrawl 的 MCP 服务器调用其网页全自动爬取能力，避免逐一去对接目标网页的爬取过程，加速 Agent 的发展。昨天 OpenAI 发布 Responses API，并开源Agents SDK，相信 MCP 和 OpenAI 会作为 Agent 重塑劳动力市场的两条故事主线。

我们会越加理解这一观点，“AI 将目标对准的是企业的运营费用，而不是针对传统软件的预算。” 点击了解更多2025关于 AI 的前瞻观点。

说回 Agent，相比对话机器人，Agent 的 planing 和执行过程更加复杂，会消耗更多 token，下方是来自知乎作者@tgt 制作的图，从中我们可以看到，从输入开始，Agent 的计划、记忆、调用外部系统、执行输出，这些过程都会唤醒大模型，从而消耗 token，如果在输出内容前，再添加自我纠错的过程，以提升输出效果，token 更会成本增加。

近期爆火的 Manus，虽然展示很多执行效果不错的 user case，但带来的是背后算力的巨大消耗。总的来说，Agent 的成熟，会大幅提升对基础模型的调用量。

04 如何控制 token 的异常消耗初探 由于引起模型资源消耗的因素众多且复杂，不仅是一个产品或者方案就可以解决的，需要从事先、事中、事后建立建立完整的工程体系，由于我们仍处于 token 消耗的初期，以下仅作抛砖引玉，相信会看到精益大模型成本的更多实践。

（1）异常调用发生前：预防措施

a. 建立实时监控与阈值预警系统

- 监控系统：部署资源监控仪表盘，实时跟踪 metric、log、trace 和 token 等基础观测指标，一旦发生异常调用，可快速排查故障，以及用于限流。[4]
- 访问控制：对用户身份（如API Key）进行权限分级和访问控制，提供消费者鉴权功能，例如限制高频调用，避免恶意或误操作导致突发性资源占用。[5]

b. 数据预处理

- 格式检查：在调用模型前，对用户输入进行格式、长度、敏感词等校验，过滤无效或异常请求（如超长文本、特殊符号攻击），减少无效 Token 消耗。
- RAG 效果优化技术：在向量检索前使用元数据进行结构化搜索，从而精准找到目标文档并提取相关信息，缩短输入长度，降低 Token 使用量。
- 语义缓存：通过在内存数据库中缓存大模型响应，并以网关插件的形式来改善推理的延迟和成本。在网关层自动缓存对应用户的历史对话，在后续对话中自动填充到上下文，从而实现大模型对上下文语义的理解，以减少缓存未命中的 token 消耗。[6]

c. 参数调优

- 温度参数调优：对模型的参数进行调优，以控制模型的输出行为。例如，调整温度（temperature）参数可以影响模型输出的随机性。降低温度值可以使模型输出更加确定性，减少不必要的 Token 生成。例如 DeepSeek 官方建议代码生成/数学解题，温度设置为0.0，通用对话，温度设置为1.3。
- 输出长度预设：在调用模型时，预先设定输出的最大长度。根据具体任务的要求，明确告知模型输出的大致范围。例如，在生成摘要时，设置输出长度不超过 4k，避免模型生成过长的文本。DeepSeek 最高输出长度支持 8K。

（2）异常调用发生时：实时处理

a. 报警和限流阻断机制

- 报警：针对 Token 消耗量、调用频率、失败率等核心指标，设置动态基线阈值，一旦超过阈值，就触发警报。
- 限流和熔断：当检测到 Token 消耗突增或失败率异常，可以是 URL 参数、HTTP 请求头、客户端 IP 地址、consumer 名称、cookie中 key 名称，自动触发限流，甚至阻断，保障核心功能，控制爆炸半径。[7]

b. 异常调用溯源与隔离

- 临时封禁：通过日志分析定位异常调用来源（如特定用户、IP或API接口），临时封禁异常请求方，防止资源进一步浪费。

（3）异常调用发生后：恢复与优化

a. 数据补偿与代码修复

- 减少统计误差：统计对因数据更新延迟导致的统计误差（如 Token 消耗记录缺失），通过离线计算任务重新校准数据，确保计费和监控系统的准确性。
- 代码审查与修复：对调用大模型的代码进行审查，修复可能存在的逻辑错误或漏洞。例如，检查是否存在循环调用模型的情况，避免无限循环导致的异常 Token 消耗。

b. 攻击溯源与防御策略升级

- 分析异常调用日志：识别是否为对抗性攻击 （如投毒攻击或恶意生成请求），更新黑名单规则并部署输入过滤模型。
- 增强身份认证机制：如双因素验证，防止 API Key 泄露导致的资源滥用。
- 自动化预警与处理机制完善：完善自动化预警和处理机制，提高系统对异常 Token 消耗的响应能力。例如，优化警报规则，使警报更加准确和及时；改进异常处理流程，提高处理效率。

c. 长期优化措施

- Token 分级管理 ：为不同业务分配不同权限的 Token，降低核心服务Token的暴露风险。
- 自动化测试与演练 ：定期模拟 Token 异常场景（如过期、失效），验证容错机制的有效性。

05 总结

过去，我们投入了大量时间和精力在基础设施资源利用率的提升上；当下，所有从事 AI Infra 的企业都专注在资源的利用率上，从底层硬件、模型层、推理优化层，以及在往上的网关入口层，这将是一场工程和算法比翼的长跑。

参考链接

[1] https://mp.weixin.qq.com/s/eBqg2hHFQTKCrNKCJHV-Iw

_[2] _https://api-docs.deepseek.com/zh-cn/quick_start/pricing

_[3] _https://mp.weixin.qq.com/s/zYgQEpdUC5C6WSpMXY8cxw

[4]_ _https://help.aliyun.com/zh/api-gateway/cloud-native-api-gateway/user-guide/ai-observability

[5]_ _https://help.aliyun.com/zh/api-gateway/cloud-native-api-gateway/user-guide/configure-consumer-authentication

[6]_ _https://help.aliyun.com/zh/api-gateway/cloud-native-api-gateway/user-guide/ai-cache

[7] https://help.aliyun.com/zh/api-gateway/cloud-native-api-gateway/user-guide/ai-token-throttling