AI 应用成本归因与 Chargeback 体系：把 API 成本精确分摊到部门、项目、用户

"上个月 GPT API 账单 12 万，到底是哪个团队烧的？"——这是企业 AI 应用上规模后必然面对的问题。和云资源（CPU/带宽）一样，AI API 成本最终也要 精确分摊到具体的业务单元，否则就是一笔糊涂账，要么过度投入、要么被个别业务线拖垮整体预算。

一、为什么 AI 成本归因比传统云成本更难

传统云资源按实例/小时计费，资源归属基本静态（哪个项目开的机器就是哪个项目的）。AI API 成本归因有三大难点：

1. 成本和调用绑定，不和资源绑定：同一台后端服务器可能服务 5 个业务，Token 消耗是动态的

2. 单次成本波动极大：一次简单问答几厘钱，一次长文档总结几块钱，相差三个数量级

3. 用户行为难以预测：一个恶意用户在 1 小时内能把月度预算烧光

所以 AI 成本归因必须做到每一次调用都有归属标签，而且要在调用发生的瞬间记录，否则月底对账就是考古。

二、四层归因维度

一个完整的成本归因体系至少要覆盖四个维度：

成本 = f(部门, 项目, 功能, 用户)

四个维度的笛卡尔积就是"成本立方体"，任意切面都能算清楚"客服部 9 月的代码助手项目下用户 u_12345 用了多少钱"。

三、数据采集：每一次调用都要记账

归因的前提是全量调用日志。推荐在 LLM 调用层做一层统一封装，自动写入成本字段：

# llm_billing.py
import time
from dataclasses import dataclass, asdict
from openai import OpenAI

PRICING = {
    # 每百万 token 的美元价（含中转站常见价格区间）
    "gpt-5.6-sol": {"input": 2.5, "output": 10.0},
    "claude-opus-5": {"input": 15.0, "output": 75.0},
    "gemini-3.1-pro": {"input": 1.25, "output": 5.0},
    "deepseek-v3": {"input": 0.14, "output": 0.28},
}

@dataclass
class CallRecord:
    timestamp: float
    department: str
    project: str
    feature: str
    user_id: str
    model: str
    input_tokens: int
    output_tokens: int
    cost_usd: float
    latency_ms: int
    status: str

def cost_of(model, in_tok, out_tok):
    p = PRICING[model]
    return (in_tok * p["input"] + out_tok * p["output"]) / 1_000_000

def chat_with_billing(
    client: OpenAI,
    model: str,
    messages: list,
    *, department: str, project: str, feature: str, user_id: str
):
    t0 = time.time()
    try:
        resp = client.chat.completions.create(
            model=model, messages=messages, timeout=60
        )
        u = resp.usage
        cost = cost_of(model, u.prompt_tokens, u.completion_tokens)
        record = CallRecord(
            timestamp=t0,
            department=department, project=project,
            feature=feature, user_id=user_id,
            model=model,
            input_tokens=u.prompt_tokens,
            output_tokens=u.completion_tokens,
            cost_usd=cost,
            latency_ms=int((time.time() - t0) * 1000),
            status="ok",
        )
    except Exception as e:
        record = CallRecord(
            timestamp=t0,
            department=department, project=project,
            feature=feature, user_id=user_id,
            model=model, input_tokens=0, output_tokens=0,
            cost_usd=0,
            latency_ms=int((time.time() - t0) * 1000),
            status=f"error:{type(e).__name__}",
        )
        raise
    finally:
        # 异步写入日志存储（避免阻塞主流程）
        log_queue.put(asdict(record))
    return resp

调用方只需要传入业务标签：

resp = chat_with_billing(
    client, "gpt-5.6-sol", messages,
    department="客服部", project="智能客服",
    feature="多轮问答", user_id="u_12345",
)

日志落地建议用 ClickHouse / DuckDB 这类列式存储（聚合查询快），或者直接进 数据仓库（BigQuery / Snowflake）月底和财务系统对接。

四、归因查询：随时回答"钱花在哪了"

有了全量日志，常见的归因查询是 SQL 几行的事：

-- 问1：9 月各部门花了多少钱？
SELECT
  department,
  COUNT(*) AS calls,
  SUM(input_tokens + output_tokens) AS total_tokens,
  SUM(cost_usd) AS total_cost
FROM llm_calls
WHERE timestamp >= '2026-09-01' AND timestamp < '2026-10-01'
GROUP BY department
ORDER BY total_cost DESC;

-- 问2：客服部智能客服项目里，哪些用户最费钱？
SELECT
  user_id,
  SUM(cost_usd) AS user_cost
FROM llm_calls
WHERE department = '客服部'
  AND project = '智能客服'
  AND timestamp >= '2026-09-01'
GROUP BY user_id
ORDER BY user_cost DESC
LIMIT 20;

-- 问3：批量总结功能 vs 多轮问答，哪个更费钱？
SELECT
  feature,
  AVG(input_tokens + output_tokens) AS avg_tokens,
  SUM(cost_usd) / NULLIF(COUNT(*), 0) AS avg_cost_per_call,
  SUM(cost_usd) AS total_cost
FROM llm_calls
GROUP BY feature;

把这些查询封装成 BI 仪表盘（Metabase / Looker / Superset），财务和管理层能自助查询。

五、Chargeback：把账单推送给业务方

归因的目的不只是"看清楚"，而是让成本回到使用方手里。典型的 Chargeback 月度账单：

==============================================
AI API 使用账单（2026 年 9 月）
部门：客服部
项目：智能客服
负责人：张三
==============================================

功能细分：
  多轮问答    ¥45,230  (1.2M 次调用)
  文档总结    ¥18,500  (45K 次调用)
  知识库检索  ¥ 6,200  (800K 次调用)
  其它        ¥ 2,100
  ──────────────────────
  小计        ¥72,030

Top 5 高消费用户：
  u_12345 (李四)   ¥ 8,900
  u_23456 (王五)   ¥ 6,200
  ...

模型成本分布：
  GPT-5.6 Sol     ¥48,000  (67%)
  Claude Opus 5   ¥20,000  (28%)
  DeepSeek V3     ¥ 4,000  (5%)

同比上月：+18% （主因：双 11 客服咨询量上涨）
建议：批量总结功能可迁移至 DeepSeek V3，预计节省 ¥12,000/月
==============================================

实现方式：每月 1 号跑一个脚本拉上月数据 → 生成账单 PDF/邮件 → 推送给部门负责人 + 抄送财务。

六、预算控制：归因之后的闭环

归因 + Chargeback 之后，下一步是预算控制，否则账单只是事后报告。预算分三层：

实现示例：

class BudgetGuard:
    def __init__(self, project, monthly_budget_usd):
        self.project = project
        self.budget = monthly_budget_usd

    def check(self, estimated_cost):
        used = get_current_month_cost(self.project)
        ratio = used / self.budget
        if ratio >= 1.2:
            raise QuotaExceeded("预算已超额，需主管审批")
        elif ratio >= 1.0:
            return "downgrade"   # 切到便宜模型
        elif ratio >= 0.9:
            notify_manager(f"[告警] {self.project} 预算已达 90%")
        return "allow"

七、模型路由优化：把成本归因变成省钱工具

归因数据最大的副产品是模型选型优化。同一业务不同模型的成本差可能高达 50 倍：

归因数据让"哪个业务该换模型"一目了然，而不是凭感觉优化。

八、常见反模式

• ❌ 没有调用日志：月底对着 LLM 供应商账单一脸茫然
• ❌ 只有总量的归因：知道 9 月花了 12 万，但不知道是哪个项目
• ❌ 归因数据不自动化：靠人工 Excel 统计，月底才出报表
• ❌ 没有预算控制：账单到了才发现某项目烧爆了预算
• ❌ Chargeback 只是"通知"：没有和预算/审批/降级机制挂钩

九、总结

AI API 成本归因是企业 AI 治理的基础设施。从"每一次调用都打标签"开始，逐步建立"实时归因 → 月度账单 → 预算告警 → 自动降级"的完整闭环。归因数据本身也是优化模型选型、识别异常流量、和业务方透明对话的依据。

想了解 Token 成本怎么进一步压低，可以看 AI API 成本优化技巧；要选便宜稳定的 API 来降低单位成本，可以去 openairouter.net 比较各家中转站的实时报价。