推理延迟：衡量什么及为何变化
内容提要
本文讨论LLM推理延迟的复杂性，指出其分为首字延迟、总响应时间和代理全链路时间等指标，受队列、防护、冷启动及RAG检索影响。优化需按场景选择指标：聊天重首字，代理重总耗时，批处理重成本。语义缓存可跳过模型调用，显著降延迟和成本，Redis Iris等工具支持此优化。
延伸解读
延迟指标因场景而异
文章指出，LLM推理延迟并非单一数字，而是分为首字延迟（TTFT）、总响应时间和代理全链路时间等不同指标。这些指标可能相互矛盾，例如一个系统TTFT快但总响应慢。因此，优化前必须明确目标场景：聊天应用关注TTFT，代理系统关注总耗时，批处理任务关注成本和截止时间。选择错误的指标可能导致优化方向偏差，无法真正改善用户体验。
模型速度不等于生产延迟
模型基准测试通常只测量生成时间，但生产环境中的延迟还包括队列等待、防护过滤、冷启动和RAG检索等环节。文章提到，在测试的RAG流水线中，检索占端到端延迟的41%，且检索到的文档会加长提示词，进一步推高TTFT。因此，实际生产延迟往往远高于模型广告速度，优化时需关注模型之外的整个链路。
语义缓存：跳过模型调用
语义缓存通过向量嵌入比较查询相似性，命中时直接返回缓存结果，完全跳过模型调用，从而大幅降低延迟和成本。文章引用数据：Redis LangCache在缓存命中时响应速度提升15倍，高重复工作负载下推理成本降低73%。但需注意阈值设置过松可能导致不匹配的答案，且缓存内容可能过时，需用保守阈值和过期策略管理。
Q&A
LLM推理延迟有哪些不同的衡量指标？
LLM推理延迟不是一个单一数字，而是分为多个指标：首字延迟（TTFT，即从请求发出到第一个输出token的时间）、总响应时间（从请求到完整响应的时间）以及代理全链路时间（agent在多次调用中的总耗时）。这些指标可能相互独立，甚至对同一系统给出不同的快慢结论。
为什么LLM推理延迟会分为首字延迟和总响应时间？
因为LLM生成答案是一个token一个token流式输出的，模型先读取整个提示（prefill阶段）产生第一个token，然后逐个生成后续token（decode阶段）。因此，第一个token可能很快（如200毫秒内），但完整响应可能需要更长时间，所以需要分别衡量。
在RAG（检索增强生成）流程中，哪些环节会增加端到端延迟？
在RAG流程中，检索环节（包括嵌入查询、向量搜索、重排序等）可能占端到端延迟的41%，并且检索到的文档会加长提示，进一步提高首字延迟。此外，队列等待、防护过滤、冷启动等也会增加延迟。
对于聊天应用、代理和批处理任务，分别应该优化哪个延迟指标？
聊天应用应优先优化首字延迟（TTFT），因为用户等待第一个token的感知最重要；代理（agent）应优化全链路总耗时，因为代理需要等待每个步骤完成才能继续；批处理任务则更关注总完成时间和成本，而非单个请求的延迟。
语义缓存如何降低LLM推理延迟和成本？
语义缓存通过存储查询的向量嵌入和对应的响应，当新查询的嵌入与存储的相似时，直接返回缓存结果，跳过模型调用。这避免了prefill和decode过程，从而大幅降低延迟（如Redis LangCache报告缓存命中时响应快15倍）和成本（高重复工作负载下推理成本降低73%）。
语义缓存有哪些潜在风险？如何缓解？
语义缓存的风险包括：相似度阈值过松可能返回不匹配的答案，以及缓存内容可能因底层事实变化而过时。缓解方法包括使用保守的相似度阈值，以及对时间敏感的内容设置过期时间。
为什么模型基准测试的延迟与实际生产环境中的延迟可能差异很大？
因为模型基准测试只测量模型自身的生成时间，而实际生产环境中，用户等待的时间还包括队列等待、防护过滤、冷启动（模型加载权重）以及RAG检索等额外环节，这些都不会出现在模型基准测试中，所以广告速度可能与实际体验不符。
