本文选自 Horizon 2026年9月1日技术简报。
摘要
聊天窗口给人的感觉很简单：输入一句话，稍作等待，答案便逐字出现。服务器内部处理的对象却远不止这句话。系统提示词、工具定义、历史对话、长期记忆、检索资料和本轮输入会先被拼成一份临时文档，经过安全检查和分词后进入共享推理集群。模型随后依次完成预填充与解码，推理引擎还要处理连续批调度、KV Cache 分配、前缀缓存与流式输出。理解这条链路，有助于解释几个常见现象：同一个模型为什么在不同产品中表现不同，长对话为什么越来越慢，工具调用为什么明显增加延迟，以及企业部署大模型时为什么不能只关注模型参数量。
聊天框只是入口，上下文才是模型收到的请求
用户按下回车时，前端通常会先完成鉴权、会话定位、附件登记和请求路由。到达模型之前，应用层会围绕用户输入构造完整上下文。最前面通常是系统指令，用于定义角色、边界、输出格式和优先级；随后可能是可用工具及其参数定义、从长期存储取回的用户偏好、知识库检索片段、此前的对话记录，最后才是用户刚刚写下的内容。
这一步常被称为上下文工程。它与早期“提示词技巧”的区别，在于关注对象已经从一句措辞扩展为一套运行时信息系统：哪些信息应该进入上下文，按什么顺序排列，是否保留原文，何时压缩，哪些工具描述可以延迟加载，以及不同来源发生冲突时如何处理。两个产品即使调用同一模型，只要上下文装配方式不同，输出质量、速度和成本就会显著不同。
上下文并非越长越好。模型的注意力预算有限，长文档会增加预填充计算量，也会让关键约束被大量低价值材料稀释。企业知识库常见的问题不是“检索不到”，而是一次塞入过多近似文档；智能体常见的问题也不是“工具不够”，而是把几十个工具的完整接口都放进每一轮请求。较成熟的系统会先做意图判断，再按任务加载必要工具和资料，把稳定规则、动态证据与临时状态分开管理。
模型没有聊天记忆，历史需要在每一轮重新提供
多数在线推理服务在请求之间是无状态的。界面上连续的聊天，是应用保存历史并在下一轮重新提交后形成的体验。假设系统指令为1000个 token，每轮问答各100个 token，那么对话越长，每次重传和重新处理的输入越大。输出长度可能相对稳定，累计输入成本却会随轮数快速增长。
工程上通常有三种处理方式。最简单的是滑动窗口，超过长度后删除最旧消息，成本低但容易丢失早期约束。第二种是阶段性摘要，把已经完成的讨论压缩为决策、事实和待办事项；它节省空间，却可能在摘要过程中损失细节。第三种是把材料放在上下文之外，通过向量检索、关键词检索、结构化状态库或文件索引按需取回。实际系统往往组合使用，并为关键事实设置不可压缩区。
这也解释了为什么长会话偶尔会“忘事”。被遗忘的未必是模型能力不足，可能是应用删掉了旧消息，摘要遗漏了限定条件，或检索没有把相关记录取回。要让企业智能体稳定工作，应把任务状态、审批结果、数据版本和证据来源写入外部状态层，不能完全寄托在自然语言聊天记录中。
Token 化与排队：请求进入计算集群之前
上下文构造完成后，文本会被转换为 token。token 并不等同于汉字或英文单词，而是由分词器依据词频和字节模式形成的片段。不同模型采用不同词表，同一内容在不同语言、不同模型中的 token 数量可能差距很大。这直接影响上下文容量、计费和延迟，也意味着多语言产品不能简单用英文样本估算所有地区的服务成本。
请求随后进入调度队列。大模型权重体积庞大，如果一张加速卡一次只服务一条短请求，大量时间会耗在读取权重，算力利用率很低。因此推理服务会把多名用户的请求组成批次。传统静态批处理要等待整个批次中最长的回答结束；连续批处理则在 token 步级别调度，一个序列完成后立刻补入新序列，从而显著提高吞吐率。
连续批处理也带来取舍。批次越大，单位请求成本越低，但排队和尾延迟可能上升。长输入会占用更多预填充计算，一次性进入批次时可能阻塞正在解码的短请求。现代推理引擎因此会采用分块预填充，把长输入拆成若干片段，穿插在其他序列的解码步骤之间。面向交互产品时，调度目标通常不只是每秒生成多少 token，还包括首 token 延迟、输出平滑度和高分位响应时间。
Prefill 与 Decode：停顿和“打字速度”来自两类工作
Transformer 推理可粗略分为预填充和解码。预填充阶段读取全部输入 token，计算各层中间状态并建立 KV Cache。因为输入位置已知，许多计算可以并行执行，更接近计算受限任务。输入越长，预填充时间通常越长，因此一段很深的对话即使只问一句短问题，首字出现前也可能等待较久。
解码阶段每次产生一个新 token，下一个 token 依赖之前的结果，时间维度上难以完全并行。每一步都要读取模型权重和已有缓存，因而常受显存带宽限制。用户看到的逐字输出主要对应这一阶段。评价交互体验时，首 token 延迟与每个输出 token 的间隔应分开测量；只看总吞吐率，会掩盖排队、预填充和调度造成的等待。
这两类工作对硬件的要求并不完全相同。预填充偏向矩阵计算能力，解码更依赖内存带宽和批处理效率。高并发平台可以把预填充与解码放在不同设备池中，按负载独立扩缩容；本地部署规模较小时，则要在架构复杂度与资源利用率之间权衡。
KV Cache：大模型服务真正稀缺的运行时资源
模型若在生成每个 token 时都重新计算全部历史，成本会高得无法接受。注意力层会把此前 token 的 Key 和 Value 保存起来，后续步骤直接复用，这就是 KV Cache。缓存大小随层数、序列长度、并发数和数据精度增长。对于大模型和长上下文，单条会话的缓存可达到数 GB；高并发时，显存往往先被 KV Cache 耗尽，而不是先被计算能力限制。
早期系统会按照序列最大长度预留连续显存，许多空间最终没有使用。分页式注意力借鉴操作系统虚拟内存思想，把缓存切成固定大小的块，按实际需求分配并通过映射表访问，减少内存碎片和预留浪费。这类方法使服务端能够承载更多并发序列，也成为 vLLM 等推理框架的重要基础。
前缀缓存则利用不同请求之间的共同开头。如果大量请求共享系统提示、工具描述或固定文档，推理引擎可复用已经计算的前缀缓存。因此上下文结构最好保持“稳定内容在前，变化内容在后”。若时间戳、随机标识或用户变量出现在开头，哪怕后面内容完全相同，也可能破坏缓存命中率。提示结构由此从语言问题变成了系统成本问题。
流式输出、护栏与工具调用形成的新循环
流式输出不会让模型算得更快，却能让用户更早开始阅读。困难在于输出安全检查：若等完整答案生成后再审核，流式体验就不存在；如果边生成边展示，已经显示的内容无法真正收回。工程系统会组合使用输入分类器、增量输出检测、敏感工具权限控制和结果后审计。对高风险业务，宁可牺牲部分流式速度，也应把不可逆操作放到显式确认之后。
工具调用让直线式推理变成循环。模型本身不会真的浏览网页、执行 SQL 或操作文件，它只生成结构化调用意图。应用执行工具后，把结果重新放入上下文，再次经历装配、检查、排队、预填充和解码。一次包含多轮搜索与校验的任务，实际上进行了多次完整推理。工具返回若过长，还会不断扩大后续上下文，因此需要截断、结构化摘要、结果缓存和并行调用。
企业智能体的性能优化也应沿这条链路展开：减少无关上下文，延迟加载工具，缓存稳定前缀，压缩工具结果，控制串行循环次数，并把确定性逻辑交给普通程序执行。单纯更换参数更大的模型，往往只能改善局部能力，无法消除架构层的延迟与成本。
结语
聊天机器人的短暂停顿，是应用编排、数据检索、安全控制、集群调度和神经网络推理共同形成的结果。模型只是其中最核心的一段，却不是全部。对于准备建设企业级大模型平台的团队，值得长期观测的指标至少包括上下文长度、检索命中率、首 token 延迟、输出速率、KV Cache 占用、工具调用轮数、缓存命中率和单任务总成本。把这条链路看清之后，许多看似随机的体验问题，才会转化为可以定位和优化的工程问题。
参考资料
- ByteByteGo, What Happens Inside an AI Chatbot Between Enter and the First Word?
- Anthropic, Effective Context Engineering for AI Agents
- Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention
- Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models
- Hugging Face, LLM Inference Endpoints and Continuous Batching Documentation