21 · AI 服务可靠性：限流 / 成本 / 缓存 / 评测
普通接口的可靠性指标是延迟和错误率；AI 服务还要多算两笔账：每回答一次多少钱、回答得对不对。本篇讲 AI 服务的稳定性与成本治理，这是资深工程师和"调包侠"的分水岭。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 给 AI 服务装上仪表盘和刹车：限流、成本、缓存、评测一套齐全 |
| 核心内容 | 可用性/成本/质量三维、限流与配额、token 成本治理、语义缓存、评测回归、降级与护栏 |
| 读完能回答 | AI 服务的"可靠性"到底指什么？怎么防止成本失控？怎么证明"改坏了没有"？ |
| 相关板块 | C19 · AI 服务端集成 ｜ C20 · RAG 与 Agent 落地 ｜ C08 · 可观测性 |
一、AI 服务的"可靠性"是三维的
| 维度 | 普通后端 | AI 服务额外要盯 |
|---|---|---|
| 可用性 | 延迟、错误率、可用率 | 上游模型抖动、降级路径 |
| 成本 | 忽略不计 | 每次回答都花钱，token 可量化 |
| 质量 | 结果确定可断言 | 非确定性，必须靠评测 |
一句话：普通服务上线看监控图，AI 服务上线还要看账单和评测分数。
二、限流与配额：给成本上刹车
2.1 两层限流
| 层级 | 限什么 | 返回 |
|---|---|---|
| 用户/租户配额 | 每用户每日/每分钟调用次数、token 数 | 429 + 配额信息 |
| 全局闸门 | 服务总 QPS / 单模型并发 | 拒绝或排队 |
python
# 思路：Redis 计数 + 滑动窗口（实现见 C13）
def check_quota(user_id: str, model: str) -> None:
used = redis.incr(f"quota:{user_id}:{date.today()}")
if used > DAILY_LIMIT:
raise HTTPException(429, "配额已用尽，明日再试")和前端的关系：这和你对前端接口做限流的思路一样，只是 AI 的"每次调用"更贵，所以配额要算到 token 而不是只算次数。
2.2 配额类型
| 类型 | 说明 |
|---|---|
| 次数配额 | 最多调 N 次/天 |
| token 配额 | 最多用 N token/天（更精准） |
| 并发配额 | 最多同时 N 个生成任务 |
给用户的反馈要可预期：被限流不是"报错"，而是返回"今日额度 X，还剩 Y"，让用户知道什么时候能恢复。
三、成本治理：四个抓手
3.1 记账：每笔调用都算钱
text
input_tokens × 输入单价 + output_tokens × 输出单价 + 重排/向量化成本 = 单次成本每次调用都要落库/落指标：用户、模型、token 数、单价、成本。不记账就谈不上治理。
3.2 模型路由：贵的和便宜的
| 场景 | 用贵模型 | 用便宜模型 |
|---|---|---|
| 复杂推理 | ✔ | |
| 分类/抽取/翻译 | ✔ | |
| 快速失败兜底 | ✔ |
很多服务的 70% 调用根本不需要旗舰模型，加一个"路由表"（按任务类型选模型）能省一大半成本。
3.3 Prompt 精简
- 去掉无关系统提示词
- 长上下文只保留命中切片（见 C20）
- 输出用
max_tokens封顶，禁止无限生成
3.4 语义缓存
text
新问题 → 向量化 → 与历史问题算相似度 → 命中(≥阈值) → 直接返回缓存答案
→ 未命中 → 调模型 → 写入缓存| 优势 | 注意 |
|---|---|
| 命中即省一次完整模型调用 | 相似度阈值要调，过低会答非所问 |
| 延迟从秒级降到毫秒级 | 缓存要带租户隔离 |
| 高频问题成本趋近 0 | 需要 TTL 与手动失效 |
语义缓存 ≈ 前端的 memoization，但"键"不是精确的，而是语义相近的一簇问题。
四、评测：AI 服务的"单元测试"
普通后端改一行代码跑单测；AI 服务改 Prompt 改模型，必须用评测集回归。
4.1 最小评测集
text
30-100 条高质量样本：问题 + 期望答案要点 + 期望行为(拒绝/追问/工具调用)| 质量维度 | 测什么 |
|---|---|
| 正确性 | 答案要点是否命中 |
| 忠实度 | 是否引用文档、是否编造（RAG） |
| 行为 | 越权问题是否拒绝、是否正确调工具 |
4.2 回归流程
text
改 Prompt/模型 → 跑评测集 → 分数对比基线 → 分数下降则回滚把评测当 CI 的一环：AI 服务的"代码改动"经常是改一段 Prompt，没有评测门禁就等于没有测试。
评测集构建方法见 G 域 practice/05。
五、幻觉与护栏
| 手段 | 做法 |
|---|---|
| 约束输出 | 让模型"只能基于给定上下文回答，不知道就说不知道" |
| 引用溯源 | RAG 答案带引用，用户可核对 |
| 拒绝策略 | 越权/敏感问题走统一拒绝话术 |
| 内容过滤 | 输出侧加敏感词/合规检查 |
| 可回放 | 保存输入/输出日志，出问题能复现（见 C19） |
原则：不要追求"永远不幻觉"（做不到），要追求幻觉可发现、有引用、可回滚。
六、可观测：AI 专用指标
在 C08 的基础指标上，AI 服务加这几组：
| 指标 | 作用 |
|---|---|
ai_latency_seconds | 生成耗时分位数（p50/p95） |
ai_error_rate | 上游模型 5xx/超时率 |
ai_tokens_total | 输入/输出 token 量 |
ai_cost_usd_total | 累计成本，按模型拆 |
ai_cache_hit_rate | 语义缓存命中率 |
ai_eval_score | 最近评测集得分 |
成本要按天、按模型、按租户三张报表看，成本异常（如某用户刷爆配额）当天就能发现。
自检清单
- [ ] 能给 AI 服务配用户级 + 全局级限流，超限返回可预期的
429 - [ ] 会给每次调用记账（token + 成本），并能按模型/租户出报表
- [ ] 会做模型路由和 Prompt 精简，识别可以降级的调用
- [ ] 有语义缓存且带租户隔离与失效策略
- [ ] 有评测集 + 回归门禁，改 Prompt/模型前先跑基线
- [ ] 有幻觉护栏（引用溯源、拒绝话术、输出过滤）与可回放日志
常见误区
- 误区：AI 服务上线只看延迟。 成本和质量才是 AI 特有的"生产事故"来源。
- 误区：限流 = 全局 QPS。 更要紧的是按用户/租户的 token 配额，防单点刷爆账单。
- 误区：Prompt 改了不用测试。 改 Prompt 就是改逻辑，必须跑评测回归。
- 误区：缓存一刀切。 语义缓存不做租户隔离，等于给别的用户发你的答案。
动手练习
练习 A：记账 + 限流
给 C19 的 Chat API 加 Redis 计数配额（每用户每日 N 次 + token 预算），超限返回 429 与剩余额度。
练习 B：语义缓存
用向量相似度实现语义缓存，测"同一个问题两种问法"能命中并返回同一答案。
练习 C：评测门禁
写一个 20 条的最小评测集，把评测跑进 CI，故意改坏 Prompt 确认分数下降并阻断。
相关文档
本区
- 19 · AI 服务端集成 —— LLM 调用封装与审计
- 20 · RAG 与 Agent 服务端落地 —— 缓存与降级的落地场景
- 08 · 可观测性 —— 指标与日志基础设施
其他域
- 05 · 工程化与 LLMOps —— AI 工程化全景
- 05 · 评测集构建与回归实操 —— 评测集方法
- 12 · 前端可观测性与线上排障 —— 前端侧体验对照