文章指出模型接收的是组装后的文档而非原始输入，且每次请求都无状态重建对话历史，深入解析了Token化、批处理、缓存与安全检测等环节。
AI解读：这条新闻解释了为什么每次与AI聊天时按下回车后会有停顿，以及之后文字为何能流畅输出。核心事实是：模型本身没有记忆，每次对话都要从头重建全部历史，导致长对话变慢变贵；同时回复过程分为一次性读取全部输入的预填充阶段（造成停顿）和逐字生成的解码阶段（打字般的速率）。对普通用户而言，这意味着对话越长，等待首次回复的时间越长，但打字速度基本不变，且提供商可能会自动压缩或截断早期内容。对企业开发者来说，理解这些机制有助于优化提示词结构（稳定内容放前面以利用缓存降低成本）和选择是否集成外部工具（每次工具调用都会触发完整的处理循环，显著增加延迟和成本）。当前技术已通过连续批处理和缓存将服务成本大幅降低，但语言间的Token效率差异（最多15倍）仍意味着某些语言的用户获得的有效上下文空间更小。
ByteByteGo发布长文详解AI聊天机器人在用户按下回车到首个字词出现之间发生的处理流程。文章指出，模型收到的并非用户输入的原始句子，而是围绕该句子组装的一份文档，且模型本身无状态，每次对话都从头重建。
这份文档包含系统提示词、可用工具定义、记忆内容、检索到的知识库文档、完整对话历史以及用户新消息。文档的组装与取舍被称为“上下文工程”，由于模型的注意力预算有限，输入越长精度会逐渐下降。
模型无状态与成本的重建机制
模型在消息之间不保留任何信息，屏幕上看到的对话历史每次都会完整重建并重新发送。以一个系统提示词1000 token、每轮消息和回复各约100 token的产品为例，第一轮处理约1100 token，第二轮约1300，第三轮约1500，到第20轮接近4900 token。输入量逐轮叠加而输出基本不变，导致输入成本通常占对话产品总花费的大部分。
针对长对话，文章列出三种优化方式：丢弃最早轮次、用摘要压缩对话、或将材料存储在上下文窗口之外按需检索。但长对话仍然会变慢变贵，因为每轮都要重新处理此前所有内容。
安全检测与资源共用的循环流程
生成回复前，组装好的文档会先通过一个独立的小型安全检测模型，该模型与主模型分离，可单独训练和监控。早期分类器在真实系统中增加了约24%的计算开销和0.38个百分点的无害请求误拒率，限制了其部署范围；新方案采用级联设计，先用廉价验证筛选所有流量，仅对可疑对话使用昂贵分类器，开销降至约1%，误拒率降至0.05%。
模型本身不会搜索网页、读取文件或查询数据库，而是通过文本请求工具执行，应用层调用工具后将结果放回上下文，触发新一轮完整处理循环。一次包含三次网络搜索的回复可能经历多次完整往返，成本急剧上升。
同一台硬件同时服务多个请求，通过连续批处理在单个生成步骤层面调度新请求，基准测试显示吞吐量可提升至原来的23倍，并改善中位响应时间。但由于数值运算对请求数量敏感，即使关闭随机性，相同提示词发送一千次也可能得到80种不同结果。
回复两阶段分析与缓存优化
回复分两阶段：第一阶段一次性读完整份文档并并行处理所有输入token，这导致用户感知的停顿；第二阶段逐token输出，因依赖关系无法并行化，速度受限于内存带宽。首token时间覆盖从发送到出现首个输出的全部时间，每个输出token的时间则决定后续打字速度。长输入可能导致批处理中其他请求延迟，但可通过分块交错生成缓解。
预填充阶段的计算结果会被存储并复用，但状态占用大：70亿参数模型持8000 token对话约需数GB，并发对话可能超出高端加速器内存。早期系统预留整块连续内存导致60%-80%浪费，改进后按需分配小块使浪费降至4%以下，吞吐量提升2-4倍。提示词缓存使缓存部分的输入成本约为正常输入价的十分之一，缓存项数分钟不刷新即过期。