Grok 账单对账与异常定位

「这个月怎么贵了一倍？」——这个问题最难的地方不是找答案，而是先排除错误答案。多数人第一反应是查单价，翻出价格表一看没变，于是开始怀疑模型、怀疑限流、怀疑被多扣。真正的原因往往藏在三个地方：少数跨阈值请求的 token 量、缓存命中率的塌陷、或者干脆是请求数涨了但没人注意到。

这一节给一套对账顺序：先用本地记录算出「应该花多少」，再把差额归因到可核对的来源，最后才动优化。

一、问题不是「单价变了」，而是「口径对不上」

本地估算与控制台账单对不上，只有四种可能：

• 漏记请求：本地只记了主链路，异步任务、重试、定时任务没进账。
• token 低估：只算了用户问题，漏了 system、检索片段、工具返回。
• 跳档漏算：有请求跨过 20 万阈值，本地仍按低档单价算。
• 缓存假设错：本地按「命中五成」估，实际 cached_tokens 是 0。

四类的排查成本完全不同。前两类靠对数，后两类靠重算。所以对账不是「找一个数字」，而是按顺序排除。

还有一种情况值得单独说：差额可能根本不存在。官方每个响应都带 cost_in_usd_ticks（1 美元 = 10^10 ticks），已扣掉所有折扣、也已含服务端工具调用。把这些 ticks 按请求累加，就得到一份你自己的「应收账单」：拿它和官方发票对，差的是账；拿它和本地估算对，差的是口径。两条线分开跑，才不会把「估算写错了」误判成「平台多扣了」。

二、最小可运行示例：差额归因器

下面的脚本不联网、不需要真实密钥。它用本地逐类记录算出一个「应该花多少」，再与台账单比较，并根据长请求的 token 占比给出优先核对项。

"""对账归因：本地逐类记录 vs 台账单，定位差额主要来自哪一类。"""

PRICE_LOW = {"in": 2.0, "cached": 0.5, "out": 6.0}
PRICE_HIGH = {"in": 4.0, "cached": 1.0, "out": 12.0}
THRESHOLD = 200_000

def estimate(prompt: int, cached: int, output: int) -> float:
    tier = PRICE_HIGH if prompt >= THRESHOLD else PRICE_LOW
    return ((prompt - cached) / 1e6) * tier["in"] \
        + (cached / 1e6) * tier["cached"] \
        + (output / 1e6) * tier["out"]

def reconcile(rows: list[dict], actual_usd: float) -> tuple[float, float, float, str]:
    """返回 (本地估算, 差额, 长请求 token 占比, 优先核对项)。"""
    local = sum(r["requests"] * estimate(r["prompt"], 0, r["output"]) for r in rows)
    gap = actual_usd - local
    long_tokens = sum(r["requests"] * r["prompt"] for r in rows if r["prompt"] >= THRESHOLD)
    all_tokens = sum(r["requests"] * r["prompt"] for r in rows)
    share = long_tokens / all_tokens if all_tokens else 0.0
    if gap > 0 and share > 0.3:
        hint = "跳档计费与长请求 token 量"
    elif gap > 0:
        hint = "是否有漏记的请求"
    elif gap < 0:
        hint = "缓存命中与单价版本"
    else:
        hint = "本地账与账单一致"
    return local, gap, share, hint

def offline_check() -> None:
    rows = [
        {"kind": "短请求", "requests": 147_000, "prompt": 3_000, "output": 400},
        {"kind": "长请求", "requests": 3_000, "prompt": 210_000, "output": 400},
    ]
    actual = 4_100.0
    local, gap, share, hint = reconcile(rows, actual)
    print(f"本地估算：${local:.2f}")
    print(f"账单：${actual:.2f}")
    print(f"差额：${gap:.2f}（{gap / local:+.1%}）")
    print(f"长请求 token 占比：{share:.1%}")
    print(f"优先核对：{hint}")

if __name__ == "__main__":
    offline_check()

真正对账时，把 rows 换成你日志里按类型聚合的结果——类型可以按「普通 / 长文档 / 工具调用」分，只要能对上 token 量就行。归因器不替你查日志，它只负责告诉你先查哪一类。

三、异常定位表与排查顺序

对账结论出来后，按下表定位，顺序不要颠倒：

三件要强调的事：

• 先看长上下文，再看缓存，最后看调用量。原因是杠杆量级不同：跨阈值请求能单独吃掉大半账单（见 1.3 的 67%），缓存命中率的波动通常在几十个百分点，调用量则是线性放大。顺序反了，会在小变量上耗掉排查时间。
• 按 token 量比，不按请求数比。2% 的请求可以占近六成 token（本节示例就是 58.8%）。只看请求数占比，会得出「长请求不用管」的错误结论。
• 单价必须带版本。价目会调整，本地常量如果还是旧值，差额会被误判成「被多扣」。对账前先确认本地单价与官方页同一日期。
• 对账粒度能降到请求级。过去只能拿月账单对一个总数，差额靠推断；现在逐请求的 cost_in_usd_ticks 就摆在响应里，聚合一次就能把差额定位到「哪一类请求、哪一天、哪个模型」，不必再用占比反推。这一步做完，上面那张归因表更多是兜底，而不是首选手段。

四、预期输出与异常分支

运行归因器，预期输出：

本地估算：$3769.20
账单：$4100.00
差额：$330.80（+8.8%）
长请求 token 占比：58.8%
优先核对：跳档计费与长请求 token 量

换成真实账单时，若出现异常，按下面顺序处理：

最后一行的情形很常见：账对得上，但团队觉得「花得比预期多」。那不是对账问题，是预算设定问题——账没错，是当初的估算太乐观。

五、判据卡

这张卡的重点是先排除错误答案。四类现象里「账单高、占比高」和「请求数没变却翻倍」常常同源：长请求或缓存失效在主导，表现一个是总额一个是突变，但修法都要回到 token 量与前缀稳定性上。

六、来源与核验

• 官方定价页：https://docs.x.ai/developers/pricing（核验日期 2026-11-04）。两档单价与缓存价以该页为准；本节数值为教学算例，实际以控制台账单与官方页当前显示为准。
• 官方模型页：https://docs.x.ai/developers/models（核验日期 2026-11-04）。20 万阈值整包跳档的规则来自该页注释。
• 官方 Prompt Caching Usage & Pricing：https://docs.x.ai/developers/advanced-api-usage/prompt-caching/usage-and-pricing（核验日期 2026-11-04）。cached_tokens 字段与长上下文阈值含缓存 token 的说明来自该页。
• 官方成本追踪页：https://docs.x.ai/developers/cost-tracking（核验日期 2026-11-04）。cost_in_usd_ticks 为逐请求实际费用、已含折扣与工具调用、不跨轮累计，均以该页为准（F54–F56）。
• 官方 Management API 账单页：https://docs.x.ai/developers/rest-api-reference/management/billing（核验日期 2026-11-04）。发票列表 GET /v1/billing/teams/{team_id}/invoices、当期预览 GET /v1/billing/teams/{team_id}/postpaid/invoice/preview、账单主体信息 billing-info 均以该页为准（F57）。要点两条：invoiceStatus 有 PENDING / PAID / FAILED / INVALID / WILL_NEVER_BE_CHARGED 五种取值，未出账的月份不能用「没发票」当成「没花钱」；billing-info 存的是名称、地址与税号，不含余额或额度，别指望它查欠费。

七、动手试

1. 把 rows 换成你项目的真实聚合数据，跑一遍，看差额主要落在哪一类；再把它与 5.3 的预算守卫结论对照。
2. 给 reconcile() 加一个参数，支持「按模型分组」对账：同一批请求分别用 4.7 与 4.3 计费，观察差额如何变化，并说明这能否解释你实际账单的偏差。
3. 设计一份月度对账模板：至少包含请求数、prompt token、cached_tokens、跨阈值请求数、本地估算、台账单六列，并写明哪一列异常时该先查什么。