09
工程化与成本
把 Demo 变成能跑的生产系统
TERMS · 6
Prompt Caching提示词缓存●
把不变的 system / 工具描述缓存住，下次只算新增部分——大幅省钱。
Token Cost成本核算●
输入和输出 token 单价不同，要算清才能控制账单。
Rate Limit限流●
每分钟请求数 / token 数上限，触发要退避重试。
Latency / TTFT延迟与首 Token 时间●
TTFT = 用户看到第一个字之前等了多久——直接决定体感。
Async / Concurrent异步并发●
Python 里用 asyncio 并发调多个 API，不要串行等。
Fallback / Retry降级与重试●
主模型超时？降到备选模型；可重试错误？指数退避。
面试高频问答
先拆成本来源:模型单价、输入 token、输出 token、调用次数和工具链路。优化可以从缩短上下文、缓存稳定前缀、减少无效循环、换更合适的模型、批处理或把简单任务交给规则/小模型入手。
- +先用 trace 找出最贵步骤,不要凭感觉优化
- +长上下文、重复系统提示和冗长工具结果通常是成本大头
- +成本优化不能牺牲关键任务成功率,要和评估集一起看
首 Token 延迟主要受模型选择、上下文长度、网络、排队和工具前置耗时影响。可以缩短 prompt、启用 prompt caching、并行准备检索和工具、选择更快模型,并用 streaming 先把生成过程展示出来。
- +Streaming 改善用户感知,但如果前面检索很慢,首 token 仍然会慢
- +长上下文会明显增加预填充时间,减少无用上下文很有效
- +把非关键工具调用延后或并行化,能减少用户等待
要区分超时、限流、服务错误和内容拒绝,分别处理。常见策略包括指数退避重试、切备用模型、降级为简化回答、排队异步处理、提示用户稍后重试,以及保留任务状态避免重复执行危险动作。
- +重试必须有上限和幂等设计,否则会放大成本或重复下单
- +备用模型要提前评估输出差异,不能临时换了才发现格式不兼容
- +用户体验上要说明任务状态,不要让用户以为系统没响应
Prompt Caching 适合缓存稳定且重复的大段前缀,比如系统提示、工具说明、长文档上下文和固定规范。它不适合频繁变化的用户输入或每次都不同的检索结果。
- +缓存命中依赖前缀稳定,小改动也可能导致缓存失效
- +适合高并发、重复上下文多的应用,例如客服知识库和代码仓库助手
- +缓存能降成本和延迟,但要注意供应商支持方式和失效规则
要把并发控制放在应用层,根据供应商额度、模型、用户等级和任务优先级做队列与限速。不能让每个请求无限并发调用模型或工具,否则很容易触发限流并造成雪崩。
- +使用令牌桶、队列、并发池和优先级可以让系统更平稳
- +批量任务适合异步执行,前端显示进度,不要阻塞 HTTP 请求
- +限流指标要按模型和 key 维度监控,便于扩容或降级
并发适合独立的检索、多个工具查询和多候选生成,能降低总耗时。安全前提是每个并发任务相互独立、结果可合并、失败可隔离,不能把有顺序依赖或会产生副作用的操作盲目并行。
- +读操作通常更容易并行,写操作要考虑锁、幂等和事务
- +并发结果合并要处理冲突、超时和部分失败
- +多路模型调用会快速增加成本,需要预算控制和取消机制