传统微服务盯 QPS 和错误率就够了；LLM 系统还要盯质量和代币账单。没有观测，优化全靠感觉。
三层指标
1. 平台层（像普通服务）
- 可用性、错误码分布、饱和度（队列、GPU）
- 依赖健康：向量库、工具 API、鉴权
2. 推理层（LLM 特有）
- TTFT（首 token 时间）
- TPOT / tokens per second
- 输入 / 输出 token 数
- 截断率、安全拦截率
- 缓存命中率（prefix / KV / 语义缓存）
3. 产品质量层
- 抽样人工评分或 LLM-as-judge
- 任务成功率（Agent 是否完成目标）
- 工具调用失败率、重试次数
- 用户显式反馈（👍/👎）与隐式信号（改写、重问）
三者缺一，就会出现「延迟很好但答案很烂」或「答案还行但烧穿预算」。
Trace 要比日志重要
一次请求建议串成一条 trace：
request
├─ retrieve (vector)
├─ rerank
├─ llm.prefill / llm.decode
├─ tool.call × N
└─ response + usage每个 span 带上：model、tenant、prompt_version、token_in/out。事后才能回答：「是检索慢还是模型慢？」
成本归因
至少按下面维度拆账：
| 维度 | 用途 |
|---|---|
| 租户 / 产品线 | 谁在烧钱 |
| 模型 | 该不该降级到小模型 |
| 路由规则 | 复杂问题才上大模型是否生效 |
| 功能入口 | 哪条产品链路最贵 |
有了归因，才能谈「自动路由」和「缓存」，而不是一刀切限流。
质量观测怎么落地
不要幻想全量人工审。可行组合：
- 在线抽样 1%–5% 进评测队列
- 黄金集回归：发版前后跑固定用例
- 异常探测：空答案、超短答案、高重复 n-gram 自动打标
- 用户反馈闭环：👎 自动挂到 trace，方便复盘
alert: ttft_p95 > 2s for 10m
alert: empty_response_rate > 1%
alert: cost_per_1k_req up 30% WoW落地顺序
- 先打通 usage + latency（一天就能见效）
- 再补 trace 串联检索与工具
- 最后上 质量抽样与回归
可观测性不是仪表盘好看，而是让你在改 Prompt、换模型、动 Infra 时，知道变好还是变坏。