首个Token在撒谎：为什么上下文加载——而非推理——才是AI功能延迟的真正瓶颈
大多数关于AI延迟的讨论都搞错了方向。团队痴迷于GPU利用率、模型量化和批处理大小。与此同时，真正让用户感到烦躁的延迟——AI开口说话前的那段停顿——几乎完全由推理开始前发生的事情决定。瓶颈在于上下文，而非算力。
首Token时间（TTFT）是决定AI功能感觉灵敏还是迟钝的关键指标。而TTFT主要由预填充阶段主导：在生成任何输出Token之前，处理完整输入上下文所需的时间。对于128K Token的上下文，预填充可能耗时数秒。GPU在努力工作，但用户什么也看不到。
解决方案不是更好的GPU，而是在用户提问之前就预先加载好上下文。
这正是上下文预热工程师所做的事：他们构建基础设施，在正确的时机将正确的Token就位，使得当用户消息到达时，预填充成本已经提前支付了一部分。这是一门独立于推理优化的工程纪律，将两者混为一谈会导致团队把钱花在算力上，而用户依然在等待。
上下文工程与推理优化
两者的区别至关重要。推理优化关注的是：一旦你把Token交给模型，它处理的速度有多快——硬件并行化、KV缓存复用、投机解码、预填充-解码分离。这些确实能带来真实的收益；在合适的工作负载下，将预填充和解码阶段分散到不同硬件上可以实现2到7倍的吞吐量提升。
上下文工程关注的是：你交给模型的是哪些Token，以及何时交。这是一门从无限可能的信息宇宙——用户历史、工具Schema、检索到的文档、领域知识——中为有限的上下文窗口选择最有价值Token的纪律，并确保这些Token以尽可能低的成本到达模型。
上下文预热是两者的交集：在用户输入任何内容之前发生的会话前工作。与其在请求到达后被动地组装上下文，不如在请求到达前主动地投机性组装。当用户消息落下时，你跳过了昂贵的冷启动组装步骤，直接进入温热的预填充。
这不是小幅度的提升。在生产环境的语义缓存中，61%到68%的命中率可以完全消除大多数查询的API调用，将数秒的延迟压缩到个位数毫秒。GitHub Copilot在上下文扩展前预选工具Schema，在A/B测试中将平均延迟降低了400毫秒。这些数字来自会话前工作，而不是从解码内核中再挤出5%。
上下文预热的三个杠杆
预获取用户历史
上下文预热最简单的形式是在会话开启前拉取用户历史。理论上很直接——在用户历史交互中运行相似性搜索，获取其偏好和近期指令，并在推理之前将结果注入上下文——但实践中需要严格的纪律。
完整的对话历史几乎总是错误的预加载对象。一个与你的系统有过2000条消息交互的用户，不需要将所有2000条都注入进来。前1990条是被稀释的信号。摘要上下文虽然有损耗，但可将Token减少70%到90%，在切换时生成大约需要500毫秒到1.5秒。正确的方法是选择性的：预加载最近5到10轮对话、一个紧凑的偏好摘要以及领域特定的指令。
这里重要的失效模式是预获取过早导致数据过时。如果用户五分钟前更新了偏好，而你的预获取缓存尚未失效，你就构建了一个自信地无视用户实际偏好的个性化功能。温热的上下文感觉很快，但携带的是错误的状态。
预热嵌入缓存
对于由向量搜索支持的功能——RAG系统、语义搜索、智能体记忆——检索管道往往是隐藏的延迟来源。嵌入计算需要时间，而冷嵌入缓存意味着每次查询都从零开始。
解决方案是主动缓存预热：在查询到来之前，为高概率查询预先计算嵌入。历史访问日志告诉你哪些查询会重复出现。领域知识告诉你哪些问题在结构上与预期的用户意图相似。预先填充了这些嵌入的缓存，将一个耗时数百毫秒的检索操作变成了一次单次查询。
这方面的数学计算是明 确的。如果某个查询模式出现在历史查询的前10%中，嵌入该模式需要20毫秒，但每次缓存命中可节省400毫秒，那么你只需要超过5%（20/400）的命中率，预计算就值得了。实际上，经过良好调优的语义缓存在集中查询分布上能实现60%以上的命中率，使得经济效益压倒性地为正。
相似度阈值需要仔细校准。太严格会遗漏使用不同措辞但语义等价的查询。太宽松则会提供不匹配实际问题的缓存响应——这比缓存未命中更糟糕，因为它是以低延迟自信地给出错误答案。
投机性加载工具Schema
使用工具的智能体系统——函数调用、API、MCP服务器——每个会话都要支付设置成本：加载和解析智能体可能调用的每个工具的Schema。在有50多个工具的系统中，将完整的Schema集注入上下文在Token方面代价过高。但懒加载Schema——在用户提出需要某个工具的问题之后——会在用户期待响应的时刻增加明显的停顿。
解决方案是嵌入引导的投机性加载。在会话开启前，将用户可能的意图（从会话历史或第一条消息推断）与可用工具的向量表示进行比较。预加载前k个候选工具的Schema。当用户的实际请求到来时，你已经为最可能用到的工具提前支付了Schema加载成本。
