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 官方计费说明为准。做预算时先确认自己用到的计费项,再谈单价。

二、同样是调用,为什么账单差几倍

调用次数相同,账单可能完全不同。差异通常来自下面六个地方:

  1. 输入输出比例:客服机器人输入多、输出中等;内容生成输入短、输出长。两者的成本结构不能用同一个平均值估算。
  2. 上下文累积:多轮对话每轮都把全部历史带上,输入 Token 会随轮数快速上涨。
  3. 缓存命中率:固定前缀可以复用;时间戳、随机 ID、动态工具列表会让缓存失效。
  4. 模型档位:不同 Grok 型号的能力和单价不同,简单任务用高端型号会把预算放大。
  5. 重试次数:每次重试都是一次新请求,429 之后立刻重发容易形成重试风暴。
  6. 输出长度:输出单价通常高于输入,长回答、重复解释和不受控的格式都会增加成本。
场景 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)

金额要用你账户的实际单价去乘,单价从模型价格读取,不要沿用几个月前的截图。缓存命中的统计字段在不同兼容实现中可能叫法不同,以响应实际返回为准。

四、把成本降下来的顺序

降本有先后,顺序反了容易白忙。建议按下面七步做:

  1. 先量化基线:导出最近一周的真实请求日志,按项目、模型、场景统计输入输出 Token,先知道钱花在哪。
  2. 再做模型路由:分类、抽取、改写走小模型,复杂推理再上高端型号,按任务难度分配而不是按团队习惯分配。
  3. 减少输入:RAG 只召回相关片段,历史消息做摘要,工具返回只保留必要字段。
  4. 限制输出:设置合理的 max_tokens,要求 JSON 或固定字段,减少客套话和重复解释。
  5. 利用缓存:把 system prompt、工具定义和知识库前缀固定下来,并验证缓存是否真的命中。
  6. 治理重试:429 和超时使用指数退避加随机抖动,设置最大重试次数,避免固定间隔猛重试。
  7. 预算与告警:按项目设额度上限,每周复盘消耗排名,发现异常增长及时定位。

先做输入治理和缓存,再考虑换更便宜的模型。否则只是把不稳定的输出做得更便宜,返工成本还会回来。

五、预算和账单怎么管

  • 一个项目一把 Key,按项目设置预算上限,避免多个服务互相挤占额度。
  • 日志至少记录时间、模型、输入输出 Token、状态码和请求 ID,不记录完整 Key 与敏感内容。
  • 每月按“项目、模型、场景”三个维度对账,找出增长最快的调用。
  • 缓存、模型路由和输出限制带来的节省要单独记录,否则优化效果无法证明。
  • 需要人民币付款和发票的团队,可以用国内 AI 网关统一账单;具体价格、汇率与发票规则以模型价格为准。

常见问题

Grok API 只有输入和输出两项费用吗?

常见账单以输入和输出 Token 为主,但缓存输入、工具调用、搜索等能力可能有单独计费口径。具体包含哪些项目,以官方计费说明和账单明细为准。

为什么按平均 Token 估算不准?

平均值掩盖了长尾请求。少数超长上下文、长输出或重试请求可能贡献大部分成本。用真实日志看分布,比用一个平均数乘调用量可靠。

缓存能省多少?

取决于前缀复用率和命中率。缓存读取通常低于普通输入单价,但缓存写入可能有溢价,前缀太短或每次都变则无法命中。先用日志确认命中,再评估节省。

输出越长越贵吗?

通常如此,因为输出 Token 单独计价且单价往往高于输入。把回答限制在业务需要的长度,并采用结构化输出,通常比换模型更快见效。

国内团队怎么用人民币结算?

可以通过提供人民币充值和发票的 AI 网关调用 Grok,统一多模型账单。具体可用型号、价格和发票规则以模型价格为准。

下一步

先在中商起航 AI 网关创建测试 Key,用一批真实任务记录输入输出 Token,再按上面的公式做预算。模型可用性与价格以模型价格为准。

相关阅读: