成本仪表:给每次调用装电表

一次调用要记哪些字段

row = dict(
  id=call_id,          # 唯一请求 id(排障、幂等都靠它)
  ts=时间戳,
  user_id=用户,        # ← 没有它,就做不了额度和封禁
  feature=功能名,       # ← 没有它,就不知道该优化谁
  model=模型名,        # 换模型时的成本对比
  in_hit/in_miss/out=token 数,   # 分开记!命中缓存的便宜十倍(ap1.4)
  cost=算好的钱,
  latency=耗时,
  ok/err=成功与否+错误,          # ← 失败也要记!
)

三个新手最容易漏的字段:

1. user_id:没有它,你永远做不了"按用户限额"(AP7)和"揪出刷量的人"(AP6);
2. feature:没有它,你看到的只有"总花费在涨",不知道是哪个功能在涨;
3. 失败记录:失败也消耗时间和排障成本,而且成功率是你最重要的健康指标。

实测:模拟一天的流量

跑本节代码(2 个用户 × 3 个功能 + 1 次故意失败),真实输出:

  ✅ [5b5005e2] u_001/chat 0.99s in=8+0 out=22 花费=0.0052分
  ✅ [9fc93a0d] u_002/extract 0.84s in=22+0 out=44 花费=0.0110分
  …
  ❌ [c8a0bbb1] u_002/chat 失败但已留痕:HTTPError: HTTP Error 400

① 按用户汇总(AP7 的额度系统就吃这张表)
  u_001: 3 次调用 | 92 tok | 0.0143 分
  u_002: 4 次调用 | 184 tok | 0.0292 分

② 按功能汇总(哪个功能在烧钱?)
  extract : 2 次 | 0.0179 分 | 平均 0.78s
  chat    : 3 次 | 0.0170 分 | 平均 1.02s
  summary : 2 次 | 0.0086 分 | 平均 0.80s

③ 健康度
  成功率: 7/8 = 87.5%
  平均延迟: 0.79s
  累计花费: 0.0435 分
  → 按这个单价,每天 1 万次同类调用 ≈ 0.62 元/天

注意 ② 那张表的价值:extract 只跑了 2 次却是最贵的功能——因为它的输出长。有了这张表,"该优化哪里"不再需要猜。

实现要点

• 失败也要落库:代码里用 finally 保证——不管成功、报错、还是中途异常,流水一定写一条;
• 先写 jsonl,再上数据库:一行一条 JSON 的流水文件几乎零成本,项目早期完全够用;规模上来了再迁到数据库表(本节代码两种都演示了);
• 价格写成常量:牌价会变、模型会换,把 PRICE 集中在一处,调价时改一行;
• 流式调用的收口:流式请求的 usage 要在流结束时统计(ap1.2 的代价 2),别漏记。

🔧 动手做:把电表装进你的项目(12 分钟)

1. 跑本节代码 cost_meter.py,看三张表(它会生成 calls.jsonl,打开看看逐条流水长什么样)。
2. 接进你自己的调用函数:把 ap1.1 那个会分诊的 ask() 包一层计量(照抄本节的 metered_call 结构),让你之后每次练习都自动记账。
3. 验证失败也记账:故意用错模型名跑一次,确认 calls.jsonl 里多了一条 ok=0 的记录。
4. 算你的单位成本:用你毕业方向的真实提示词跑 5 次,看平均每次多少钱;再乘以你预期的日活 × 人均次数 = 你的月账单预估。
5. 写进笔记:我的产品里有哪几个 feature?我预估最贵的是哪个?(AP4 做完 RAG 后回来对照——多半会被自己的预估打脸。)

✅ 做到这里你应该有:一个会自动记账的调用函数、一份你自己的 calls.jsonl、一个基于真实数据的月账单预估。

为什么:能被测量的才能被优化——这句话在成本上尤其硬。没有仪表,你的成本优化只能靠"感觉这个提示词有点长";有了仪表,AP4 做 RAG 时你能直接看到"检索片段从 5 个减到 3 个,单次成本降了多少、答案质量掉了没有"——这才叫工程决策。

我的 AI 产品有这几个功能:【列出】,用户量预计【规模】。请帮我设计成本流水的表结构:1) 该记哪些字段(含排障和额度所需);2) 用 jsonl 还是数据库,什么规模该迁移;3) 哪些指标该设告警、阈值怎么定;4) 按用户/功能/时间三个维度的常用查询各怎么写。