本地调用一次模型成功，只能证明链路通了。真正上线后，首字延迟、输出速度、并发、缓存命中、失败重试和成本会一起出现。用户感受到的“快不快”，也不只是总耗时。

先拆开延迟

我通常关注三个时间：请求进入到开始推理、首个 token 返回、完整回答结束。首字延迟决定对话是否有即时反馈，生成速度决定长回答是否拖沓，而排队时间会在并发升高时突然放大。

如果只记录一个总耗时，很难判断应该优化网络、检索、提示词长度还是模型服务。

上下文也是计算预算

把所有历史对话、所有检索片段和完整工具输出塞进上下文，既慢又容易分散注意力。可以通过摘要、结构化状态、去重和相关性阈值控制输入长度。

提示词缓存与前缀复用适合大量请求共享固定系统指令的场景；连续批处理能够提高吞吐，但会在吞吐与单请求延迟之间做交换。选择哪一种，要看真实流量，而不是跑分榜。

重试不能制造更大的事故

网络读取失败可以重试，设备控制和支付类操作却不能简单重复。每个带副作用的工具调用都应有幂等键，运行时要区分“请求没有送达”和“已经执行但响应丢失”。

熔断与降级同样重要。主模型不可用时，可以切换小模型、只返回检索结果，或明确提示稍后再试。悄悄返回一段没有依据的答案，是最糟糕的降级。

一条请求需要完整轨迹

日志至少要把请求 ID、模型版本、输入输出 token、检索文档 ID、工具调用、各阶段耗时和错误类型串起来。涉及用户数据时保存脱敏摘要，而不是无限期保留原文。

指标之外还需要抽样质检。低延迟、低错误率不代表回答正确，技术系统最终仍要评估事实一致性、引用有效性和用户任务是否完成。

优化的顺序

我更倾向于先减少无效上下文和重复调用，再做缓存与并发，最后才考虑更复杂的推理框架。因为每增加一层优化，就增加一层需要观测和解释的状态。

上线后的模型不是一个 API，而是一条持续运行的生产链路。能测量、能定位、能回滚，往往比单次回答更聪明重要。

参考资料：