部署与成本优化
Deployment 与 Cost Optimization
LLM feature 上线后最容易踩的坑，不是模型效果差，而是“能跑，但跑不起”。很多 AI team 在 demo 阶段只关心 quality，等真的接进 production 才发现 latency 飙、fallback 乱、token 烧得太快，最后不是用户体验差，就是毛利直接出问题。
所以这页讲的不是单点调参，而是 AI engineer 该怎么把 deployment、reliability 和 cost 一起设计。
先说结论：先做 routing，再做优化
单纯盯着“换便宜模型”通常不够。
更有效的顺序是：
- 定义 task tier
- 给不同 task 配不同 model route
- 再优化 tokens、cache、retry 和 fallback
如果一上来所有请求都走 strongest model，后面你只会被动挨打。
部署阶段最常见的 4 个问题
| 问题 | 真实后果 |
|---|---|
| 所有请求都走大模型 | cost 爆得很快 |
| fallback 没设计好 | provider 抖一下就全站不稳 |
| prompt 越堆越长 | latency 和 token 成本一起涨 |
| rollout 没灰度 | 一次错误配置直接放大到全量用户 |
AI deployment 最怕的不是单次失败，而是可预防的问题被系统性放大。
更像 production 的部署分层
一个更稳的 LLM deployment，至少要分这几层：
| 层 | 你要管什么 |
|---|---|
| request layer | 用户请求、tenant、quota、feature flag |
| routing layer | 选哪个 model、是否 fallback、是否 regional route |
| control layer | token cap、cache、retry、timeout、budget |
| observability layer | latency、error、fallback ratio、cost delta |
这几层不分开，后面排障会非常痛苦。
Model Routing 才是成本控制的第一步
比起统一接一个模型，更实际的是按任务分 tier。
| Task tier | 例子 | 更合适的 route |
|---|---|---|
| low-complexity | rewrite、classification、light summary | small / cheap model |
| medium-complexity | structured extraction、RAG answer | balanced model |
| high-complexity | long-context reasoning、complex generation | stronger model |
| failure recovery | primary 挂了或超时 | fallback provider / smaller safe mode |
这样做的价值不是“省一点钱”，而是让系统从第一天就有可经营性。
Token Cost，不是 output 一项的问题
很多团队只盯 output token，其实 input 也会慢慢失控。
最常见的成本来源：
- system prompt 越写越长
- history 带得太多
- retrieval chunk 塞太多
- 同一个任务来回 regenerate
所以 cost optimization 常常不是模型问题，而是上下文治理问题。
一个更稳的 Cost Control Checklist
| 控制点 | 为什么要做 |
|---|---|
| input / output token cap | 防止异常请求拉爆成本 |
| history trimming / summarization | 避免长会话无限膨胀 |
| deterministic cache | 重复任务没必要重复烧钱 |
| request budget per tenant | 防止单一客户异常消耗 |
| daily alerting | 提前发现 spike，而不是月底看账单 |
如果这些没有，cost review 往往会滞后至少一周。
Reliability 和 Cost 是绑在一起的
很多人把 reliability 只看成稳定性问题。
其实它跟成本直接相关。
举例：
- retry 太激进，会把失败成本放大
- fallback 太重，会让故障时成本翻倍
- timeout 太长，会拖垮体验和 worker 资源
所以部署策略不能只追求“不失败”，还要追求“失败时别太贵”。
Rollout 一定要灰度，不要直接全量
LLM feature 最稳的上线顺序通常是：
internal
-> canary
-> 5% traffic
-> 20% traffic
-> full rollout
每一层都看 4 个信号：
- latency
- error / 429 / timeout
- fallback usage
- cost per successful task
只看成功率，不看 cost delta，是很典型的 AI infra 盲区。
多 Provider 不是为了炫，是为了 survivability
一个成熟一点的 AI system，通常会准备：
- provider alias
- fallback policy
- capability matrix
- region / compliance route
这让你可以在 provider 抖动、价格调整、功能不兼容时，不至于完全被卡死。
最值得盯的指标
| 指标 | 为什么重要 |
|---|---|
| P95 latency | 用户主观感知最明显 |
| fallback ratio | 判断主路由是否健康 |
| avg tokens per request | 发现 prompt/context 膨胀 |
| cost per successful task | 真正的经营指标 |
| error by provider/model | 快速定位问题来源 |
如果 dashboard 里没有最后两个，deployment 管理还不算完整。
Practice
拿你现在线上一个 AI feature，先补这 4 项：
- 哪类请求其实不该走 strongest model
- 当前 fallback 触发条件是什么
- 有没有
cost per successful task - rollout 时有没有看 fallback 和 cost delta
这 4 项补上后，deployment 管理会成熟很多。