基于 LLM 的系统需要同时考虑用户体验和单位成本。交互设计中常用约 100 毫秒、1 秒和 10 秒作为响应感知的参考尺度：较短响应接近即时，一秒左右通常能够维持注意，等待时间更长则容易使用户分心。因此，流式输出等改善感知速度的方法，与实际吞吐量同样重要。交互应用可以争取一秒以内的首个 token 时间；更长操作应通过进度提示说明当前正在执行的工作。
成本随 token 数量、上下文长度和流量变化。提示大小、文本分块、重排候选数量、缓存命中率、模型路由、批处理和自动扩缩容都会影响应用经济性。本课介绍在控制质量损失的前提下，达到 p95 延迟目标并管理成本的方法。
应当测量的指标
测量用户实际感受到的速度，以及系统实际支付的费用。
LLM 延迟通常需要分别记录以下指标。
- Time To First Token（TTFT）：从发送请求到收到第一个生成 token 的时间。
- Time Per Output Token（TPOT）：平均每个输出 token 所需时间。Inter-Token Latency（ITL）则描述相邻输出 token 的时间间隔，两者可用于观察流式输出节奏。
- Total Latency（TTLT）：从请求开始到最后一个 token 的端到端时间。
TTFT 受排队、网络和 prefill 输入处理影响；TPOT 主要反映持续解码阶段的速度。它们共同影响流式界面的响应感，应在仪表板和 SLO 中分别跟踪。
成本和用量应作为指标记录。保存输入及输出 token 数量、提供商支持时的缓存 token 数量，并将每次请求成本关联到模型、提示版本、功能开关和用户分组。两种常见方法如下。
- 使用提供商返回的用量。例如，OpenAI 流式请求设置
stream_options.include_usage=true后，可从结束前的用量数据块获取统计，再写入指标。实践部分采用提供商用量统计，暂不使用流式输出。 - 使用能够收集成本的 gateway 或可观测性工具，例如 LangSmith 的集成功能。
应统一属性 schema，减少各工程人员自行定义不同标签。
根据用户体验和成本上限设置 SLO。例如，交互聊天可以把 TTFT 的目标范围设为 300–700 毫秒，输出速度至少达到每秒 6–10 个 token；对应的 TPOT 约为每个 token 167–100 毫秒。还可以按功能规定总时间，例如回答不超过 5 秒，工具较多的流程不超过 8 秒。这些数值是需要按场景验证的设计目标。将 SLO 与最大输入 token、输出 token 及重排候选数等预算关联，便于负载增加时自动控制成本。p95 和 p99 应分别观察，长尾优化重点关注较慢请求，同时维持吞吐量。
延迟与成本优化方法
流式输出
流式输出在模型生成过程中持续传递 token，收到后立即展示。体验主要由首段文字出现时间和后续显示速度决定。即使总生成时间不变，一秒内开始且持续稳定输出，通常也能改善响应感并减少用户离开。SSE 是通过 HTTP 传递模型增量内容的一种常见方式。
- 开启提供商支持的流式选项。
- 后端收到内容后及时转发到浏览器。
- 前端按到达顺序显示数据块，通常可以直接追加文本。
还可以采用以下做法。
- 首段内容到达前显示加载占位，随后切换为流式文本。
- 减少冗长开场，让首句尽快提供有用信息。
- 工具执行较慢时，可以先提供已经确认的信息或进度，工具返回后继续补充。
减少传给 LLM 的上下文
减少提示 token：采用保留重要事实的压缩方式。较长上下文通常增加 prefill 时间和输入费用，具体关系取决于模型与服务实现。基于模型或规则的压缩，可以删除重复内容和模板性文字，同时保留引用和关键事实。将压缩实现为明确转换步骤，并通过评估测量质量与成本的取舍。
提高检索相关性并减少数量：稠密与稀疏混合检索配合重排，通常能够提高相关性，使系统降低 top_k，向模型传递更少的文本片段。可以在检索与生成之间使用轻量重排模型，或 Cohere Rerank 等托管服务，以减少上下文 token、延迟和成本。
使用结构化输出：产品只需要特定字段时，可以通过 JSON Schema 或 function/tool calling 限定输出，减少冗长内容和格式错误导致的重试。设置适当的 max_tokens，在接口支持且任务适合时使用停止序列和较低 temperature，控制随机性及输出范围。
模型选择与路由
可以使用两级或三级模型级联：小型、低成本模型处理多数请求，置信度不足、安全规则触发或验证失败时，再交给能力更强的模型。通常可以在智能体入口设置路由节点。生产系统应明确升级依据，例如可回答程度、检索覆盖或有害内容标记，并记录原因，以便通过后续改进让更多任务由低成本模型可靠处理。
自托管模型还可以使用 speculative decoding 等方法，通过草稿生成和验证，在一次步骤中处理多个 token，降低每个 token 的耗时。实际收益取决于硬件、提示和解码配置，因此需要测量端到端效果，不能直接套用论文中的加速数值。
模型服务与推理层
选择适合工作负载的推理服务。厂商 API 的批处理和调度通常由提供商管理；自托管可以使用 vLLM 等方案，通过 PagedAttention 管理 KV cache，并采用 continuous batching，在生成期间持续接纳请求和移除已完成请求，提高 GPU 利用率及容量。Triton Inference Server 提供 dynamic batching 和 ragged batching，适合某些无状态模型及可变输入形状。应调整排队等待时间和最大 batch 大小，防止批处理过度增加 TTFT，并使用真实提示长度和输出分布进行基准测试。
还应使用分布式系统中的方法管理 p99。少量阻塞请求或慢依赖可能造成长尾。可以设置分层超时和指数退避重试。对于幂等读取，可以考虑 hedged requests：短暂等待后发送备用请求，并采用首先返回的有效结果。检索、重排和工具调用也应有相应控制，减少单个慢依赖对整体交互的影响。跟踪 p99 TTFT 和各依赖超时，有助于判断瓶颈位于模型还是中间服务。
缓存与复用
语义缓存：除精确匹配缓存外，还可以使用向量存储及相似度阈值，复用语义相近请求的回答。例如，FAQ、内部知识和模板化工作流程可能具有较高命中率。缓存位于模型调用之前，命中后直接返回，并记录缓存响应指标。需要校准相似度阈值，并给缓存条目标记数据版本，防止知识更新后继续返回过时事实。
提供商提示缓存：某些提供商可以复用重复前缀的 prefill 结果，降低输入费用并改善 TTFT。大量共用系统提示、上下文前缀、稳定输出 schema 或工具说明的应用，可能从中受益。应测量实际命中情况；提示差异较大时，应用侧语义缓存可能更有价值。
Cache-Augmented Generation（CAG，缓存增强生成）可以与 RAG 结合。以下流程分别处理较稳定的信息和需要实时检索的信息。
数据预处理：
- 为 CAG 选择变化较少、又经常与查询相关的数据，将其预先处理为模型可复用的 KV cache，并保存在适当存储中。在模型、前缀和缓存条件保持兼容且缓存仍有效时，后续查询可以复用；相关内容变化或缓存失效时需要更新。
- 为 RAG 按需预先计算 embedding，并写入兼容数据库。某些任务只需普通数据库即可，无需向量检索。
- 缓存上下文
- 低频变化数据经过一次预处理，形成可重复使用的缓存上下文。
- 系统提示词与用户查询
- 用户查询与系统提示词一同进入上下文窗口。
- 检索上下文
- 按用户查询检索高频变化数据，并将结果加入上下文窗口。
查询流程：
- 组织用户查询和系统提示，说明如何使用缓存上下文及检索获得的外部上下文。
- 需要语义搜索时，对查询计算 embedding 并访问向量数据库；其他情况可直接查询实时数据库或网页。
- 将检索到的外部内容加入最终提示。
- 生成最终回答并返回用户。
无需实时响应时使用批处理
大型资料 embedding、批量归纳、审计报告和夜间历史数据处理，应与交互请求分配适当资源。提供商的批处理接口通常允许更宽松的完成时间，并提供相应成本和限额方案，例如 OpenAI Batch API；云平台也有异步预测的批处理或托管端点。应用可以设置批处理与实时模式选择，在“归纳这个空间”等任务超过实时处理范围时，转入批量流程。
LLM 推理的总拥有成本
在 AI Cloud 或本地 GPU 上部署及维护模型，需要额外工程和运维成本。部分费用随已配置 GPU 数量增加，在固定资源期间相对稳定。规模扩大时，某些人工管理成本按 GPU 分摊后可能下降，具体仍取决于系统复杂度。
Total Cost of Ownership（TCO，总拥有成本）与安全要求应共同影响厂商 API 和自托管的选择。按 token 计费的 API 成本主要随输入、输出及应用流量变化。
自托管模型需要配置计算资源。最简单的固定配置中，单位时间成本可以近似为水平线；实际生产环境通常还需要自动扩缩容，以控制每个 token 的成本并维持响应速度。
AI Cloud 的吞吐量、延迟与自动扩缩容
评估时需要明确应用所需吞吐量和延迟。
- 吞吐量：单位时间能够处理的请求数量，通常以每秒请求数衡量，也可根据推理场景记录 token 吞吐量。
- 延迟：用户等待首项有效输出的时间。聊天应用常关注 TTFT，之后的生成速度只要足够支持阅读即可。降低 prefill 时间是改善 TTFT 的一种方法，同时也需检查排队和网络时间。
增加提供服务的 GPU 容量可以提高吞吐量。有时在多台机器部署相同模型即可水平扩展，有时则需要让同一模型使用更多 GPU。具体方案取决于模型规模和服务要求。
应预估 GPU 数量和各时段流量。流量较少时所需吞吐量降低，可以通过扩容与缩容管理 TCO。
自托管还提供更详细的吞吐量和延迟控制。充分调整后，有机会在特定场景中达到低于外部 API 的延迟，但需要实际测量。将检索和其他服务部署在模型附近，例如同一区域，也可以减少网络开销。
原型开发阶段通常没有持续用户流量。按调用计费 API 可以在无调用时停止相应用量费用；支持缩容到零的云环境也可以在空闲期间停止计算资源，但仍需考虑存储等剩余费用。
厂商 API 与自托管的成本比较
可以将两类单位时间成本曲线放在同一时间轴上比较。
图中绿色区域表示 API 成本高于图示云资源成本的时段，红色区域表示 API 成本更低的时段。比较实际方案时，需要累计观察期内的费用，并将运维、容量闲置及其他支出计入 TCO。采用云端自托管时，可以通过提高有效利用率和适当扩缩容，使其在满足性能要求的同时具有成本优势。
