TTFT、缓存命中与上下文工程一个“好用的 LLM”有一半是接口层调出来的聊大模型的时候大家最关心的问题往往是“哪家模型最强”。但用过一段时间之后很多人会慢慢意识到另一个真相同样的模型不同的调用方式体验可以差出一个档次。一个“好用的 LLM”有一半是接口层调出来的。这篇文章把两份公开资料放在一起对照一份是 Google Cloud Vertex AI 官方文档《使用大语言模型 (LLM) 的最佳实践》页面最后更新时间为 2026-02-19另一份是 Manus 团队的工程博客《AI代理的上下文工程构建Manus的经验教训》。前者代表平台方的官方建议后者代表一线 Agent 开发的实战经验。两者拼起来恰好能回答“模型能力之外调用方式如何决定一个 LLM 好不好用”这个问题。一、延迟不是玄学官方定义的两个指标很多人抱怨“模型太慢”但很少拆解“慢”到底慢在哪。Google Cloud 的官方文档把 LLM 延迟拆成了两个明确的指标TTFTTime To First Token首个词元时间模型收到提示后生成第一个词元所需的时间。文档特别指出这个指标对使用流式传输的应用尤其重要——用户要的是“即时反馈”哪怕答案还没写完先蹦出第一个字体感就完全不同。TTLTTime To Last Token末个词元时间衡量模型处理提示和生成完整回答所花费的总时间。这两个指标对应两类不同的优化目标TTFT 关乎“响应感”TTLT 关乎“总等待时间”。一个交互式聊天应用优化 TTFT 的收益往往更大一个批量处理管道则更该盯着 TTLT。二、官方给出的降延迟手段其实都是提示工程有趣的地方在于Google 官方文档列出的缩短延迟策略几乎不需要改任何基础设施全在提示和参数层面。根据《使用大语言模型 (LLM) 的最佳实践》提示写短一点。提示越短从发出提示到获得第一个 token 的时间就越短。清晰简洁地传达意图砍掉不必要的细节和冗余。用系统说明控制回答长度。比如明确指示模型“给出简洁答案”或“限制在 N 句以内”这直接缩短 TTLT。调低 0。官方文档提到较低的 temperature 值可以产生更短、更有针对性的回答较高的值则倾向于更多样化也可能更长的输出。用 0 设置输出上限。防止模型输出过长但文档也提醒要小心——回答可能在句子中间被截断。这些手段的共同点是成本几乎为零但经常被忽视。很多团队花大力气换模型、换 GPU却没意识到自己的系统提示里塞着两千字的废话temperature 开到 1.0 还在问“请简短回答”。三、缓存命中Manus 团队的三条实战经验如果说官方文档讲的是“单次调用的质量”Manus 的博客讲的则是“反复调用时的经济学”。Agent 应用的特点是同一个上下文会被反复送进模型这时KV 缓存命中率直接决定了延迟和成本。Manus 团队在《AI代理的上下文工程构建Manus的经验教训》中给出了几条非常具体的经验保持提示前缀稳定。由于 LLM 的自回归特性哪怕只有一个 token 的差异也会使该 token 之后的所有缓存失效。文中点了一个常见错误在系统提示开头放时间戳——尤其是精确到秒的时间戳。这让模型“知道当前时间”了但代价是缓存命中率暴跌。让上下文只追加append-only。不要修改之前的操作或观察记录。另外要确保序列化是确定性的——很多语言库序列化 JSON 时不保证键顺序稳定这会“悄无声息地破坏缓存”。在需要时明确标记缓存断点。有些推理框架不支持自动增量前缀缓存需要手动插入断点分配断点时要考虑缓存过期问题至少保证断点覆盖系统提示的结尾。如果用 vLLM 之类框架自托管模型要确认启用了前缀/提示缓存并用会话 ID 等技术在分布式工作节点间一致地路由请求。把这部分和 Google 的官方建议对照看会发现一个有趣的分工官方告诉你怎么让单次回答更快更好Manus 告诉你怎么让第一百次调用和第一次一样便宜。两者叠加才是完整的接口层优化。四、上下文工程不是塞得越多越好Manus 博客里还有几点对 Agent 开发者特别有价值文件系统当外部记忆。即便前沿模型提供 128K 甚至更大的上下文窗口真实 Agent 场景中网页、PDF 等非结构化数据产生的观察结果很容易撑爆上下文而且文档指出超过一定长度后模型性能会下降——技术上支持窗口大小不等于用好它。保留错误的尝试。Manus 团队认为改善 Agent 行为最有效的方法之一出奇地简单把失败的行动和对应的堆栈跟踪留在上下文里。模型看到失败后会隐式更新内部信念降低重复犯错的概率。他们甚至认为错误恢复是真正代理行为的最明显指标之一而这一点在大多数学术工作和公共基准测试中代表性不足。别被少样本示例困住。语言模型是优秀的模仿者。如果上下文里充满相似的“行动-观察”对模型会倾向于重复这个模式。文中举的例子是用 Manus 审查 20 份简历时Agent 容易陷入节奏仅仅因为上下文里是这样就重复类似行动导致偏离、过度泛化甚至幻觉。五、适用范围与局限这套“接口层决定好用程度”的思路适用于大多数基于 Transformer 的对话式和 Agent 式应用但要注意几点边界具体参数效果因模型而异。temperature、maxoutputtokens 的行为细节应以你所用模型的参数参考文档为准Google 文档描述的是 Vertex AI 环境下的情况。缓存策略依赖推理框架。自动前缀缓存、缓存断点、分布式路由等能力不同提供商和自托管框架支持程度不同落地前需要确认。保留错误上下文有代价。历史越长TTLT 和成本越高什么时候截断、截断什么需要结合自己业务的容错需求权衡。基准分数仍有意 义但不是全部。Manus 团队自己也指出公共基准测试关注理想条件下的任务成功对错误恢复等真实能力的覆盖不足。所以选型时别只看榜单也别把搜索热度当成流量保证——最终决定用户体验的往往是 TTFT、缓存命中率和上下文设计这些“不起眼”的接口层细节。模型能力是天花板接口层决定你离天花板有多近。把这两份资料里的清单逐条对照自己的系统检查一遍可能比换一个新模型带来的提升更实在。参考资料以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中资料内容与适用范围以原始页面为准。使用大语言模型 (LLM) 的最佳实践 | Generative AI on Vertex AI | Google Cloud DocumentationAI代理的上下文工程构建Manus的经验教训 
长河君 · 2026/10/30 8:33:15 · 阅读 1.2k TTFT、缓存命中与上下文工程：一个‘好用的 LLM‘有一半是接口层调出来的——从 Google 官方延迟文档到 Manus 的实战经验
TTFT、缓存命中与上下文工程一个“好用的 LLM”有一半是接口层调出来的聊大模型的时候大家最关心的问题往往是“哪家模型最强”。但用过一段时间之后很多人会慢慢意识到另一个真相同样的模型不同的调用方式体验可以差出一个档次。一个“好用的 LLM”有一半是接口层调出来的。这篇文章把两份公开资料放在一起对照一份是 Google Cloud Vertex AI 官方文档《使用大语言模型 (LLM) 的最佳实践》页面最后更新时间为 2026-02-19另一份是 Manus 团队的工程博客《AI代理的上下文工程构建Manus的经验教训》。前者代表平台方的官方建议后者代表一线 Agent 开发的实战经验。两者拼起来恰好能回答“模型能力之外调用方式如何决定一个 LLM 好不好用”这个问题。一、延迟不是玄学官方定义的两个指标很多人抱怨“模型太慢”但很少拆解“慢”到底慢在哪。Google Cloud 的官方文档把 LLM 延迟拆成了两个明确的指标TTFTTime To First Token首个词元时间模型收到提示后生成第一个词元所需的时间。文档特别指出这个指标对使用流式传输的应用尤其重要——用户要的是“即时反馈”哪怕答案还没写完先蹦出第一个字体感就完全不同。TTLTTime To Last Token末个词元时间衡量模型处理提示和生成完整回答所花费的总时间。这两个指标对应两类不同的优化目标TTFT 关乎“响应感”TTLT 关乎“总等待时间”。一个交互式聊天应用优化 TTFT 的收益往往更大一个批量处理管道则更该盯着 TTLT。二、官方给出的降延迟手段其实都是提示工程有趣的地方在于Google 官方文档列出的缩短延迟策略几乎不需要改任何基础设施全在提示和参数层面。根据《使用大语言模型 (LLM) 的最佳实践》提示写短一点。提示越短从发出提示到获得第一个 token 的时间就越短。清晰简洁地传达意图砍掉不必要的细节和冗余。用系统说明控制回答长度。比如明确指示模型“给出简洁答案”或“限制在 N 句以内”这直接缩短 TTLT。调低 0。官方文档提到较低的 temperature 值可以产生更短、更有针对性的回答较高的值则倾向于更多样化也可能更长的输出。用 0 设置输出上限。防止模型输出过长但文档也提醒要小心——回答可能在句子中间被截断。这些手段的共同点是成本几乎为零但经常被忽视。很多团队花大力气换模型、换 GPU却没意识到自己的系统提示里塞着两千字的废话temperature 开到 1.0 还在问“请简短回答”。三、缓存命中Manus 团队的三条实战经验如果说官方文档讲的是“单次调用的质量”Manus 的博客讲的则是“反复调用时的经济学”。Agent 应用的特点是同一个上下文会被反复送进模型这时KV 缓存命中率直接决定了延迟和成本。Manus 团队在《AI代理的上下文工程构建Manus的经验教训》中给出了几条非常具体的经验保持提示前缀稳定。由于 LLM 的自回归特性哪怕只有一个 token 的差异也会使该 token 之后的所有缓存失效。文中点了一个常见错误在系统提示开头放时间戳——尤其是精确到秒的时间戳。这让模型“知道当前时间”了但代价是缓存命中率暴跌。让上下文只追加append-only。不要修改之前的操作或观察记录。另外要确保序列化是确定性的——很多语言库序列化 JSON 时不保证键顺序稳定这会“悄无声息地破坏缓存”。在需要时明确标记缓存断点。有些推理框架不支持自动增量前缀缓存需要手动插入断点分配断点时要考虑缓存过期问题至少保证断点覆盖系统提示的结尾。如果用 vLLM 之类框架自托管模型要确认启用了前缀/提示缓存并用会话 ID 等技术在分布式工作节点间一致地路由请求。把这部分和 Google 的官方建议对照看会发现一个有趣的分工官方告诉你怎么让单次回答更快更好Manus 告诉你怎么让第一百次调用和第一次一样便宜。两者叠加才是完整的接口层优化。四、上下文工程不是塞得越多越好Manus 博客里还有几点对 Agent 开发者特别有价值文件系统当外部记忆。即便前沿模型提供 128K 甚至更大的上下文窗口真实 Agent 场景中网页、PDF 等非结构化数据产生的观察结果很容易撑爆上下文而且文档指出超过一定长度后模型性能会下降——技术上支持窗口大小不等于用好它。保留错误的尝试。Manus 团队认为改善 Agent 行为最有效的方法之一出奇地简单把失败的行动和对应的堆栈跟踪留在上下文里。模型看到失败后会隐式更新内部信念降低重复犯错的概率。他们甚至认为错误恢复是真正代理行为的最明显指标之一而这一点在大多数学术工作和公共基准测试中代表性不足。别被少样本示例困住。语言模型是优秀的模仿者。如果上下文里充满相似的“行动-观察”对模型会倾向于重复这个模式。文中举的例子是用 Manus 审查 20 份简历时Agent 容易陷入节奏仅仅因为上下文里是这样就重复类似行动导致偏离、过度泛化甚至幻觉。五、适用范围与局限这套“接口层决定好用程度”的思路适用于大多数基于 Transformer 的对话式和 Agent 式应用但要注意几点边界具体参数效果因模型而异。temperature、maxoutputtokens 的行为细节应以你所用模型的参数参考文档为准Google 文档描述的是 Vertex AI 环境下的情况。缓存策略依赖推理框架。自动前缀缓存、缓存断点、分布式路由等能力不同提供商和自托管框架支持程度不同落地前需要确认。保留错误上下文有代价。历史越长TTLT 和成本越高什么时候截断、截断什么需要结合自己业务的容错需求权衡。基准分数仍有意 义但不是全部。Manus 团队自己也指出公共基准测试关注理想条件下的任务成功对错误恢复等真实能力的覆盖不足。所以选型时别只看榜单也别把搜索热度当成流量保证——最终决定用户体验的往往是 TTFT、缓存命中率和上下文设计这些“不起眼”的接口层细节。模型能力是天花板接口层决定你离天花板有多近。把这两份资料里的清单逐条对照自己的系统检查一遍可能比换一个新模型带来的提升更实在。参考资料以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中资料内容与适用范围以原始页面为准。使用大语言模型 (LLM) 的最佳实践 | Generative AI on Vertex AI | Google Cloud DocumentationAI代理的上下文工程构建Manus的经验教训