大模型 API 的话题绕不开 token。无论是调用 OpenAI、DeepSeek、Claude 这类外部大模型接口还是自建网关统一管理多个模型供应商token 都会同时出现在两个完全不同的层面一个是计费层面模型把文本切分成 token按 token 数量结算费用另一个是认证层面API token 是请求的身份凭证标记你是否有权限调用某个接口。在实际项目里这两个概念经常被混在一起。网上会看到“什么任务消耗的 tokens 大”“Claude 的 58k tokens 是多少”“credits 在 AI 平台里指什么”这类问题也会看到有人在寻找低价获取 token 的非正规渠道。作为一个长期和 API 打交道的开发者我的建议很明确token 用量可以优化费用可以控制但凭证本身的获取和使用必须走正规渠道。这篇文章就用工程视角把 token 的计费逻辑、限流逻辑、凭证安全、用量监控和常见报错讲清楚并解释为什么“低价 token”这条路绝对不能碰。1. 先分清 API 语境下的两种 token别搞混1.1 大模型计费中的 token分词单元与费用单位在自然语言处理中token 是模型处理文本的最小单元。英文里一个单词通常对应一个或多个 token中文里一个汉字大致对应一个 token具体取决于分词器和模型。模型不直接读字符而是把文本编码成 token 序列再转成向量参与计算。主流模型厂商都会提供分词工具。OpenAI 生态里常用 tiktoken能准确统计一段文本会被拆成多少个 tokenimport tiktoken enc tiktoken.get_encoding(cl100k_base) text 你好世界。Hello, world. tokens enc.encode(text) print(token 数量:, len(tokens)) print(token 列表:, tokens)这段代码的输出可以直观看到中文和英文的切分差异。统计 token 的意义不在于好奇而在于成本估算。绝大多数大模型 API 按“输入 token 数 输出 token 数”计费模型不同、输入输出单价也不同。一次请求消耗的 token 越多账单就越高。这里要特别注意输入 token 不只是你这次发的一句话。对聊天类接口系统提示词、历史消息、工具定义、RAG 检索回来的上下文都会计入输入 token。很多团队上线后发现账单暴涨往往不是用户问题而是这些隐藏输入被忽略了。1.2 API 访问凭证中的 token身份认证与权限载体另一种 token 是 API 凭证。它像一把钥匙证明请求来源是已授权的应用或账号。常见形态包括API Key一串随机字符串直接放在请求头里。Bearer Token通常在 Authorization 头里以 Bearer 前缀携带。JWT包含用户信息和过期时间的签名凭证适合分布式系统。调用大模型接口时请求头大概长这样curl https://api.example.com/v1/chat/completions \ -H Authorization: Bearer sk-xxxxx \ -H Content-Type: application/json \ -d {model: gpt-4o-mini, messages: [{role: user, content: 你好}]}对后端服务来说这个凭证必须保存在服务端绝不能出现在前端页面、移动端包里或公开仓库里。它是费用和权限的载体只要泄露别人就可以用你的配额调用模型账单由你承担。1.3 两类 token 的混淆与典型误解很多新手会问“买 token 划算吗”这个说法本身就说明两类概念被混在一起了。所谓“买 token”如果是买计费额度那应该走厂商官网的充值、赠费或企业账户如果是买 API Key那涉及的是凭证交易风险完全不同。可以用一张表区分对比项计费 tokenAPI 凭证 token本质文本切分后的计算单位身份认证凭证决定因素分词器、输入输出长度账号权限、密钥生成规则影响费用配额、权限、数据安全常见获取方式官方计费、免费试用额度、预算控制官方控制台生成非正规交易后果额度盗用、封号凭证泄露、数据被截取、法律风险把这两类 token 的关系理清之后后续讨论成本控制和凭证安全才有共同语言。2. 为什么会出现“低价 token”路子为什么不能碰2.1 非正规渠道的 token 从哪里来大模型服务按 token 收费官方价格对个人开发者来说不算便宜于是出现了各种“低价 token”“共享账号”“代充优惠”的信息。这些非正规渠道的 token 来源通常有三种盗用的开发密钥有人把 API Key 提交到公开仓库被自动化脚本扫到后批量转售。共享账号或中转接口多人共用一个账号或者有人搭建第三方转发服务再低价卖给其他人。利用平台风控漏洞批量注册账号消耗免费试用额度后转卖。无论哪一种作为使用方你都无法确认这个 token 背后是什么人在收你的请求。这里的核心问题不是“便宜不便宜”而是“你发出的数据会经过哪些环节”。注意正规的大模型服务并不存在所谓“更低价 token 批发市场”。任何明显低于官方报价的渠道都是在成本和风险之间做了你不可控的取舍。2.2 使用非正规渠道 token 的实际后果从工程视角看使用非正规 token 的风险是实实在在的凭证随时失效。卖家用的是盗用来的密钥或测试账户一旦被厂商检测到就会被封禁你的服务会突然不可用而且没有任何可用性保障。数据泄露。通过第三方中转服务调用模型时你的提示词、业务数据、用户问题都会经过别人服务器对方完全可以记录、分析甚至用于训练。合规风险。企业内部数据处理需要遵守数据安全要求把业务数据发送到不可控的第三方通道会直接构成安全事件。账单追溯。即使你买到的不是偷来的密钥厂商的风控也会识别异常调用最终可能追溯到你的服务 IP导致封号或账号拉黑。可以把风险整理成一张速查表风险现象影响程度密钥失效服务突然 401/403高数据泄露提示词被第三方记录极高配额超限共享账号互相挤占高法律合规数据流向不可审计极高2.3 正确做法把 token 当作生产凭证管理正确路线是回到正规渠道在模型厂商官方控制台申请 API Key用企业账号管理账单开通预算提醒把密钥放进秘密管理工具。如果觉得贵应该从模型选型、提示词压缩、缓存、本地部署这些工程手段入手降低成本而不是去碰非正规渠道。有些平台在注册后会赠送一定量的免费 token 或 credits这是正规渠道的体验额度和第三方转卖不是一回事。体验额度的用途是评估模型能力、跑通链路不是支撑生产流量的。这句话值得重复一遍token 的成本问题靠工程优化解决token 的获取问题靠官方渠道解决。这两者都不能靠“买便宜货”来解决。3. 估算 token 消耗先学会算账再谈控制成本3.1 一次请求的 token 构成一次普通聊天补全请求计费 token 由三部分组成输入 token系统提示词、示例、多轮历史消息、用户消息、工具定义、检索回来的文档片段。输出 token模型生成的回答通常受 max_tokens 或 max_completion_tokens 参数限制。保留占位一些实现会为输出预留 token 空间输入剩余窗口不足时会收到报错。估算公式很简单单次请求费用 输入 token 数 × 输入单价 输出 token 数 × 输出单价举个例子。假设某模型输入单价是每百万 token 5 元输出单价是每百万 token 15 元。一次请求输入 8000 token、输出 2000 token费用是8000 / 1000000 * 5 2000 / 1000000 * 15 0.04 0.03 0.07 元单看不贵但如果每天有 10 万次这样的请求一天就是 7000 元。成本控制的核心是理解请求量和单请求 token 数这两条线。部分平台把预付费额度称为 credits一次调用会从 credits 里扣减本质上也是 token 费用的另一种表示。无论叫 token 还是 credits最终都要落到“输入量、输出量、单价”这三个数上。3.2 什么任务会把 token 消耗撑大结合社区里常问的“什么任务消耗的 tokens 大”最典型的几类场景是多轮对话应用。每轮都要把全部历史消息发给模型聊天轮次越深输入 token 增长越快。Agent 应用。Agent 内部会做多步推理、调用工具、观察结果、继续推理一次用户提问可能触发多次模型调用每次调用都有完整上下文。RAG 检索问答。检索回来的文档块往往很长直接拼进提示词会把输入 token 撑大好几倍。长文档处理。全文摘要、合同解析、代码审查这类任务一次输入就可能达到数万 token。这里就可以回答“Claude 的 58k tokens 是多少”这类问题了。它讨论的通常是模型的上下文长度或单次请求消耗量一个请求如果占用了 58k token已经接近很多模型上下文窗口的一半甚至更多对吞吐和费用都会产生明显影响。具体上限以各个模型官方文档为准不能拍脑袋。3.3 用 TPM 和 RPM 理解限流配额除了费用token 还直接关系到限流。模型厂商通常按 TPM 和 RPM 限制 API 用量TPMtokens per minute每分钟内输入 token 和输出 token 的总和。例如 TPM 为 100k意味着这一分钟内所有请求累计消耗的 token 不能超过 100k。RPMrequests per minute每分钟最大请求数。TPM 的公式在很多平台文档里都写得很直白TPM 输入 token 输出 token 的总和。一个 58k token 的单次大请求就可能直接占掉每分钟一半以上的配额。这也是为什么有些应用“才调了几次就被限流”。3.4 降低成本的可复用清单成本控制不是等到月底看账单才做而是在设计阶段就介入选择合适模型不需要最强能力时用轻量模型。压缩系统提示词去掉冗余说明。限制输出长度合理设置 max_tokens。缓存历史摘要而不是每次发送全部聊天记录。对长文档先切片只把相关片段送入上下文。Agent 任务设置最大轮数和超时时间。为每个业务模块分配独立 key便于按模块统计。开通预算告警设置每日和每月上限。4. 在生产环境安全使用 API token4.1 不要把凭证写进代码最典型的反面写法是把 API Key 直接写在源码里# 错误示例千万别这样提交 OPENAI_API_KEY sk-abcdef123456这段代码只要进到 Git 仓库就可能被公网爬虫扫到。正确写法是从环境变量读取import os api_key os.getenv(OPENAI_API_KEY) if not api_key: raise RuntimeError(缺少 OPENAI_API_KEY 环境变量)在本机调试时可以把密钥放在 .env 文件并在 .gitignore 中忽略它# .gitignore .env *.env4.2 使用密钥管理服务和部署平台能力项目进入测试、生产环境后环境变量也不一定是最安全的。更稳妥的做法是使用密钥管理服务例如 Vault、云厂商的 Secret Manager、Kubernetes Secret或者部署平台自带的密钥配置项。以 Kubernetes 为例密钥可以存放在 Secret 中再以环境变量方式注入apiVersion: v1 kind: Secret metadata: name: llm-secret type: Opaque stringData: OPENAI_API_KEY: sk-xxxxxapiVersion: apps/v1 kind: Deployment metadata: name: llm-service spec: template: spec: containers: - name: app image: your-image:latest env: - name: OPENAI_API_KEY valueFrom: secretKeyRef: name: llm-secret key: OPENAI_API_KEY注意即使是 Kubernetes Secret也只是 base64 编码不代表加密。生产环境要依赖访问控制、审计日志和密钥轮换来保护它。4.3 密钥轮换、隔离与最小权限生产实践中应该做到开发、测试、生产环境使用不同密钥避免一次泄露全盘暴露。定期轮换密钥理解轮换窗口内旧密钥的失效策略。删除不再使用的密钥和测试账号。在厂商控制台配置按部门或项目分配的 API Key配合使用量查看权限。对敏感模型接口启用额外审计记录调用者身份。如果使用云厂商的统一网关还可以在网关层做更细的权限控制例如只允许特定服务 IP 调用禁止密钥在其他地域使用。4.4 日志与监控中的脱敏日志里不要打印完整 token。打印请求日志时要先把凭证遮盖掉def mask_secret(value: str) - str: if not value: return if len(value) 8: return **** return value[:4] **** value[-4:]logger.info(call llm, api_key%s, model%s, mask_secret(api_key), model)这条规则同样适用于异常堆栈、错误消息上报、链路追踪。一旦 token 出现在日志系统里就等于扩大了泄露面。5. 用量监控与异常排查5.1 需要盯住的核心指标在生产环境中不能只看业务是否正常还要盯住 token 相关的资源指标指标含义异常信号Token 消耗量每 5 分钟或每小时的输入和输出 token突然翻倍请求量 RPM每分钟请求数突增或突降错误率4xx、5xx 比例401/429 集中出现余额与配额账户剩余额度快速下降调用地域请求来源 IP出现境外或异常地域平均输入长度每次请求的输入 token持续上涨监控数据可以来自模型厂商控制台的用量页也可以用自有网关记录每次请求的 usage 字段。以常见的 OpenAI 风格响应为例usage 字段会返回 token 明细{ usage: { prompt_tokens: 1200, completion_tokens: 300, total_tokens: 1500 } }把这个字段存入时序数据库或日志系统是后续做用量审计和成本分摊的基础。5.2 如何发现 token 可能被盗用很多团队发现 API Key 泄露时账单已经异常了。更早的发现路径是按信号排查调用地域异常账户从未有过海外调用突然出现境外 IP。时间模式异常业务在本地夜间没有流量夜里却持续有高并发调用。用量曲线异常token 消耗在某个时间点突然陡增且调用内容与业务不匹配。错误码变化出现大量认证相关错误说明可能有人在测试一批密钥。账单异常单日费用远超历史峰值。发现信号后第一步是立即吊销疑似泄露的密钥而不是先去定位谁在用。密钥轮换后再结合网关日志分析来源 IP 和请求内容。5.3 常见报错和排查路径不同模型厂商的错误码命名略有差异但通常可以按下面这张表定位错误现象常见原因检查方式处理建议401 authentication_error / invalid_api_keyAPI Key 错误、被吊销、格式不对检查环境变量、控制台密钥状态重新生成密钥并更新配置403 permission_denied账号无权限、模型不可用查看账号权限、模型地区支持调整权限或换合规模型429 rate_limit_exceeded超出 TPM 或 RPM 限制查看用量页面、计算累计 token降并发、加缓存、申请提高配额429 insufficient_quota账户余额不足查看余额充值或等待配额重置400 context_length_exceeded输入超过上下文窗口统计 prompt token压缩上下文、截断历史、切片500/502/504服务端异常或网络问题查看供应商状态页加退避重试避免雪崩排查顺序建议从最基础的开始先确认密钥有效再确认余额和配额再看模型和参数最后看网络和服务端状态。不要一上来就怀疑厂商故障。5.4 一次排查的示例流程假设线上突然出现大量 429查看用量页确认当前 TPM 是否已经打满。如果是定位是哪一个业务模块消耗最大。查看该模块的请求日志统计平均输入 token 和输出 token。如果平均输入 token 很大检查是否把完整历史消息都发给了模型。如果请求量很大检查是否有循环调用或异常重试。处理后在网关层增加令牌桶或并发限制避免再次打满配额。6. 常见坑、可复用清单与扩展方向6.1 实际项目中经常踩的四个坑坑一在前端代码里保存 API Key。现象浏览器请求直接携带模型厂商密钥控制台的抓包就能看到完整凭证。原因前端代码没有秘密可言任何静态资源都可以被读取。处理把模型调用放到后端前端只请求自己的服务端接口。坑二把上下文窗口当成可随便使用的空间。现象设计系统提示词时塞入大量内容认为只要不超过上下文长度就没事。原因上下文窗口还同时受 TPM 限流和费用约束一个占 58k token 的请求会吃掉大量分钟配额。处理在提示词设计阶段就统计 token并设置输入长度上限。坑三Agent 应用没有设置最大轮数。现象Agent 在工具调用链中反复重试一次用户提问产生几十次模型调用token 消耗暴涨。原因Agent 的循环和错误重试会让单次任务成本放大数倍。处理设置最大推理步数、限制工具调用次数、加入超时和熔断。坑四日志和错误上报里打印了完整密钥或完整请求内容。现象日志系统里出现 API Key 或完整 Prompt。原因直接使用参数占位符打印请求对象。处理统一封装日志方法做脱敏后再输出。6.2 发布前检查清单把下面这份清单放在项目上线检查项里可以避开大多数 token 相关问题[ ] 代码仓库和历史提交中不存在 API Key。[ ] 所有环境都从环境变量或密钥管理服务读取凭证。[ ] 开发、测试、生产使用不同密钥且具备最小权限。[ ] 模型调用都记录了 usage 字段便于用量统计。[ ] 日志和错误上报已脱敏不包含完整凭证和敏感 Prompt。[ ] 已设置余额告警和用量告警。[ ] 后端接口对模型调用做了限流和并发保护。[ ] Agent 任务设置了最大轮数和超时。[ ] 上下文发送前有 token 统计和截断逻辑。[ ] 对第三方中转或不明确的调用通道做过排查并下线。6.3 扩展方向从外部计费走向内部治理长期来看token 管理不只是“交不交得起费用”的问题而是变成平台工程的一部分。可以考虑的扩展方向包括自建模型网关。统一封装多个模型供应商集中做密钥管理、限流、重试、用量统计和成本分摊。引入缓存层。对重复问题使用语义缓存或提示词缓存减少重复计费 token。本地或私有化部署模型。对数据敏感、调用量大的场景把模型部署到内部用固定算力成本替代按 token 计费。结合 Spring AI 等框架。Java 项目可以通过 Spring AI 的抽象层统一管理模型调用、密钥配置和提示词模板减少重复代码。建设成本大盘。把每个业务的 token 消耗、费用、响应时延、错误率放在一个看板上让成本变成可观测指标。这些方向的共同点是用工程治理取代“省着点用”的直觉让 token 消耗变得可预测、可控制、可审计。AI token 管理的本质是两件事一是把费用模型理解清楚让每次请求的消耗可计算、可优化二是把凭证当生产资产保护起来让非法渠道没有可乘之机。理解 tiktoken 的切分逻辑看懂 TPM 和 RPM 的限流公式配置好密钥轮换和用量告警再在 Agent、RAG、多轮对话这些高消耗场景里做好截断和兜底一个团队的 AI 应用就能从“能跑”走向“可控”。
