技术方案从 Demo 进入生产环境后，真正拉开差距的往往不是某个单点能力，而是稳定性、成本、可观测和治理边界。本文围绕近期开发者关注度较高的技术问题，整理一套可以直接落到工程实践里的分析框架，重点讨论如何把能力做成可持续运行的系统。
## 一、成本失控通常不是因为模型单价
- AI 应用工程化：把模型路由、上下文裁剪、工具调用、失败降级和效果评测拆成独立模块。
- 性能与成本优化：同时观察 P95 延迟、token 消耗、缓存命中率和重试放大倍数。
- 安全治理：把鉴权、参数校验、最小权限、审计和敏感数据脱敏放进同一条调用链。
- 部署落地：明确运行环境、网络边界、健康检查、扩缩容阈值和回滚路径。
## 技术实现参考：把每次调用变成可计算的成本记录
成本治理至少需要一张按请求落库的明细表。不要只保存总 token，还要保存场景、模型、缓存、重试和耗时：
~~~sql
CREATE TABLE llm_usage (
request_id VARCHAR(64) PRIMARY KEY,
scene VARCHAR(64) NOT NULL,
model VARCHAR(64) NOT NULL,
input_tokens INTEGER NOT NULL,
output_tokens INTEGER NOT NULL,
retry_count INTEGER NOT NULL DEFAULT 0,
cache_hit BOOLEAN NOT NULL DEFAULT FALSE,
latency_ms INTEGER NOT NULL,
created_at TIMESTAMP NOT NULL
);
SELECT
scene,
model,
COUNT(*) AS calls,
SUM(input_tokens + output_tokens) AS total_tokens,
AVG(latency_ms) AS avg_latency_ms,
SUM(retry_count) AS retries
FROM llm_usage
WHERE created_at >= CURRENT_DATE
GROUP BY scene, model
ORDER BY total_tokens DESC;
~~~
日报里建议固定观察四个派生指标：单次成功请求 token、每千次请求成本、重试放大倍数、缓存节省比例。重试放大倍数等于总调用次数除以业务请求数；这个值持续高于 1.05，通常意味着上游波动或重试策略不合理。
很多团队评估大模型成本时，会先看输入输出 token 的单价。但真实项目里，成本失控往往来自四个更隐蔽的地方：重复调用、无效上下文、错误重试和缺少拆账。
重复调用最常见。比如一个页面刷新触发多次总结，一个客服会话每轮都重新检索完整知识库，一个异步任务失败后被队列和业务逻辑各重试一次。单次调用看起来不贵，但在高频场景里很快会放大。
无效上下文也很容易被忽略。为了“保险”，开发者会把过长历史、完整文档、重复检索结果都传给模型。这样做能降低短期调试难度，但会让延迟和费用同时上升。
## 二、先做分类，再做推理
降低成本最有效的办法，不是盲目换便宜模型，而是让不同任务走不同路径。
| 任务类型 | 推荐策略 | 原因 |
| --- | --- | --- |
| 意图识别 | 小模型或规则优先 | 输出空间有限，不必复杂推理 |
| 文档问答 | 检索结果压缩后再生成 | 避免把整篇文档塞进上下文 |
| 客服兜底 | 低成本模型先答，高风险问题转人工 | 平衡成本和可靠性 |
| 代码分析 | 按文件和调用链拆分 | 避免一次性输入过大 |
| 复杂推理 | 使用强模型并记录原因 | 把高成本留给高价值任务 |
这套分层思路的关键是先识别任务，再决定模型和上下文长度。模型不是越强越好，而是要和任务价值匹配。
## 三、日志必须为成本服务
只记录“调用成功”或“调用失败”是不够的。成本治理需要把日志拆到足够细：
- 每次请求使用了哪个模型。
- 输入和输出 token 分别是多少。
- 是否命中缓存。
- 是否发生重试。
- 是否经过检索或工具调用。
- 这次调用属于哪个业务场景。
有了这些信息，优化才有方向。否则月底看到账单上涨，只能猜是用户变多、Prompt 变长，还是某个任务异常重试。
## 四、缓存不是万能，但应该优先考虑
大模型缓存最适合三类场景。第一是固定知识问答，例如价格政策、产品说明、常见问题。第二是重复度高的摘要任务，例如同一篇文档被多次打开。第三是中间结果缓存，例如检索结果、分类结果、结构化抽取结果。
不过缓存不能乱用。涉及用户隐私、强实时数据或上下文敏感的问题，不应该简单复用答案。更合理的做法是缓存可复用的中间层，例如检索片段、文档摘要、意图分类，而不是缓存最终回复。
## 五、一个实用的成本治理顺序
我建议按这个顺序做，不要一开始就追求完整平台：
1. 先把所有模型调用集中到一个调用层，避免散落在各个业务模块。
2. 给每次调用加请求 ID、场景、模型、token、耗时和状态码。
3. 把高频场景单独统计出来，优先优化这些路径。
4. 对低价值任务启用小模型、规则或缓存。
5. 对高价值任务保留强模型，但要求有明确的调用原因。
## 六、结论
大模型应用的成本优化，不是财务问题，而是工程问题。只有当调用链路、任务类型、上下文长度、缓存命中和重试行为都被记录下来，团队才有可能把成本降下来，同时不牺牲用户体验。把模型能力纳入工程治理，这一步走得越早，系统后期越稳。
