Grok API 由 xAI 提供,按 Token 计费,输入和输出分开计价。很多团队做预算时只盯着模型单价,上线后却发现账单和估算差出一大截:历史消息每轮重传、输出写得过长、重试没有退避、长文档反复加载,都会把成本放大。
本文不写死任何单价,而是把 Grok API 的计费结构拆开,给一套可复现的测算方法和成本控制顺序。具体单价、可用模型与上下文长度,以 xAI 官方文档和站内模型价格为准。
说明:xAI、Grok 是其权利人的商标,本文仅作技术介绍。模型名称、接口与价格可能调整,采购前请核对官方页面和站内模型价格。
一、Grok API 的账单由哪些部分组成
Grok API 采用 OpenAI 兼容的 Chat Completions 形式,账单通常以输入 Token 和输出 Token 为主。实际项目中,还要把缓存、工具调用、长上下文和失败重试一起考虑。
| 计费项 | 什么时候产生 | 常见放大因素 | 控制手段 |
|---|---|---|---|
| 输入 Token | 系统提示、历史消息、工具定义、文档 | 每轮都重传完整历史 | 摘要、裁剪、检索召回 |
| 缓存输入 | 重复使用相同前缀 | 前缀不稳定导致不命中 | 固定 system 与工具顺序 |
| 输出 Token | 模型生成的内容 | 回答冗长、格式不受控 | 设置 max_tokens、结构化输出 |
| 工具调用 | 函数调用、搜索等附加能力 | 多轮循环、重复查询 | 限制轮次、缓存结果 |
| 长上下文 | 长文档、长对话 | 整库塞入、重复读取 | 分段处理、只取相关片段 |
| 重试 | 429、超时后的重发 | 无退避、并发过高 | 指数退避、幂等检查 |
不同模型和不同能力可能有单独的计费口径,例如缓存输入是否计价、工具调用是否另算,都要以 xAI 官方计费说明为准。做预算时先确认自己用到的计费项,再谈单价。
二、同样是调用,为什么账单差几倍
调用次数相同,账单可能完全不同。差异通常来自下面六个地方:
- 输入输出比例:客服机器人输入多、输出中等;内容生成输入短、输出长。两者的成本结构不能用同一个平均值估算。
- 上下文累积:多轮对话每轮都把全部历史带上,输入 Token 会随轮数快速上涨。
- 缓存命中率:固定前缀可以复用;时间戳、随机 ID、动态工具列表会让缓存失效。
- 模型档位:不同 Grok 型号的能力和单价不同,简单任务用高端型号会把预算放大。
- 重试次数:每次重试都是一次新请求,429 之后立刻重发容易形成重试风暴。
- 输出长度:输出单价通常高于输入,长回答、重复解释和不受控的格式都会增加成本。
| 场景 | Token 结构 | 主要成本 | 优化方向 |
|---|---|---|---|
| 客服机器人 | 输入多、输出中等 | 历史消息反复传输 | 摘要加缓存 |
| 文档抽取 | 输入长、输出短 | 文档被重复读取 | 检索加小模型 |
| 代码助手 | 输入输出都大 | 工具结果与思考过程 | 裁剪工具输出、模型路由 |
| 内容生成 | 输入短、输出长 | 输出 Token | 分段生成、限制长度 |
三、算清一次请求的成本
把一次请求拆开,成本可以用下面的公式表示:
单次请求成本 =
未缓存输入 Token × 输入单价
+ 缓存输入 Token × 缓存单价
+ 输出 Token × 输出单价
+ 工具或搜索等附加费用
公式本身不难,难的是拿到真实的 Token 数。不要按字数猜,直接读响应里的 usage 字段:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["GROK_API_KEY"],
base_url=os.environ.get("GROK_BASE_URL", "https://ai.zhongshangqihang.com/v1"),
)
resp = client.chat.completions.create(
model="grok-4",
messages=[{"role": "user", "content": "把这段需求拆成五个开发任务。"}],
max_tokens=512,
)
usage = resp.usage
print("输入 Token:", usage.prompt_tokens)
print("输出 Token:", usage.completion_tokens)
print("合计 Token:", usage.total_tokens)
金额要用你账户的实际单价去乘,单价从模型价格读取,不要沿用几个月前的截图。缓存命中的统计字段在不同兼容实现中可能叫法不同,以响应实际返回为准。
四、把成本降下来的顺序
降本有先后,顺序反了容易白忙。建议按下面七步做:
- 先量化基线:导出最近一周的真实请求日志,按项目、模型、场景统计输入输出 Token,先知道钱花在哪。
- 再做模型路由:分类、抽取、改写走小模型,复杂推理再上高端型号,按任务难度分配而不是按团队习惯分配。
- 减少输入:RAG 只召回相关片段,历史消息做摘要,工具返回只保留必要字段。
- 限制输出:设置合理的
max_tokens,要求 JSON 或固定字段,减少客套话和重复解释。 - 利用缓存:把 system prompt、工具定义和知识库前缀固定下来,并验证缓存是否真的命中。
- 治理重试:429 和超时使用指数退避加随机抖动,设置最大重试次数,避免固定间隔猛重试。
- 预算与告警:按项目设额度上限,每周复盘消耗排名,发现异常增长及时定位。
先做输入治理和缓存,再考虑换更便宜的模型。否则只是把不稳定的输出做得更便宜,返工成本还会回来。
五、预算和账单怎么管
- 一个项目一把 Key,按项目设置预算上限,避免多个服务互相挤占额度。
- 日志至少记录时间、模型、输入输出 Token、状态码和请求 ID,不记录完整 Key 与敏感内容。
- 每月按“项目、模型、场景”三个维度对账,找出增长最快的调用。
- 缓存、模型路由和输出限制带来的节省要单独记录,否则优化效果无法证明。
- 需要人民币付款和发票的团队,可以用国内 AI 网关统一账单;具体价格、汇率与发票规则以模型价格为准。
常见问题
Grok API 只有输入和输出两项费用吗?
常见账单以输入和输出 Token 为主,但缓存输入、工具调用、搜索等能力可能有单独计费口径。具体包含哪些项目,以官方计费说明和账单明细为准。
为什么按平均 Token 估算不准?
平均值掩盖了长尾请求。少数超长上下文、长输出或重试请求可能贡献大部分成本。用真实日志看分布,比用一个平均数乘调用量可靠。
缓存能省多少?
取决于前缀复用率和命中率。缓存读取通常低于普通输入单价,但缓存写入可能有溢价,前缀太短或每次都变则无法命中。先用日志确认命中,再评估节省。
输出越长越贵吗?
通常如此,因为输出 Token 单独计价且单价往往高于输入。把回答限制在业务需要的长度,并采用结构化输出,通常比换模型更快见效。
国内团队怎么用人民币结算?
可以通过提供人民币充值和发票的 AI 网关调用 Grok,统一多模型账单。具体可用型号、价格和发票规则以模型价格为准。
下一步
先在中商起航 AI 网关创建测试 Key,用一批真实任务记录输入输出 Token,再按上面的公式做预算。模型可用性与价格以模型价格为准。
相关阅读:
