15 请求链路

15.1 生命周期

一次请求分两段：先把输入读完，再一个字一个字往外吐。这两段叫 prefill（预填充）和 decode（解码），它们消耗完全不同的硬件资源，这是整个推理经济学的地基。模型生成文本的方式是逐 token 预测：看完已有的全部内容，预测下一个 token，接到末尾，再预测下一个。所以输出一千个 token 要跑一千次前向计算，而读入输入只需要一次，因为整段输入可以并行处理。

15.2 两段负载

prefill 受限于算力，decode 受限于显存带宽。这一句是本章最值钱的一句，几乎所有推理优化手段都能归到这两个瓶颈中的一个。prefill 阶段，几千个 token 同时参与矩阵运算，GPU 的计算单元被喂满，瓶颈是每秒能做多少次浮点运算。decode 阶段，每次只算一个 token，计算量极小，但仍要把全部模型权重从显存读到计算单元一次；对一个几百 GB 的模型，每吐一个字就要搬几百 GB 数据，瓶颈是显存带宽，计算单元大部分时间在等数据。

要补一句边界：prefill 算力密集、decode 带宽密集是工程倾向，不是物理定律。模型大小、输入长度、批次、量化、MoE 结构、投机解码和内核都会改变瓶颈，最终结论要来自算子剖析和端到端时序，不能只凭阶段名称定位。但这个倾向解释了一个常见现象：一个大 prefill 插进统一批次，会占用较长执行时间，让正在 decode 的请求出字卡顿。第 17 章的分块预填充和第 18 章的 PD 分离都是针对这类干扰。

15.3 八个节点

用户等待的是整条请求链，GPU 执行只是其中一段。一次请求穿过八个控制点：客户端、网关鉴权、限流排队、模型路由、调度批处理、GPU 执行、流式返回、计量日志。每一点既是功能，也是失败边界：

诊断慢要按同一请求标识建立跨层时间线：何时到达、何时完成分词、何时入队、何时被调度、何时产生首 token、每个 token 何时发送、何时完成计量。服务端首 token 很快而客户端晚收到，问题在代理缓冲或跨境网络；入队前就慢，问题在鉴权或分词；队列很长，优化内核只能缓解一部分。把首字延迟拆成时间线之后，它才会变成动作。

15.4 队列反馈

排队解决的是资源暂时不足时谁先运行，但它也会隐藏容量问题：只要入口继续接收，系统表面上没有失败，用户等待却不断变长。典型的反馈循环是：请求率略高于处理率，队列开始增长；请求等待更久，占用连接和网关内存；客户端超时重试，重复请求抬高到达率；系统进一步变慢。没有幂等和重试预算时，一次局部过载会被用户行为放大。所以生产服务需要背压、并发上限或主动丢弃：系统超出安全容量时，明确拒绝、降级或延后批量任务，比把所有请求拖进高尾延迟更可控。BD 要理解的一点是：允许无限排队会暂时让接收率好看，却在破坏 SLA 和信任。

15.5 流式形态

流式响应改变的是时间形态，不是工作量：首 token 可以早于完整响应，感知等待改善，但生成同样数量 token 的计算一分不少。流式连接带来状态问题：系统要知道哪些 token 已经发送、客户端是否取消、断线后是重试整次请求还是继续、工具调用是否已产生副作用、计量如何收口。非流式客户端只在完整响应后收到数据，测得的首 token 时间可能实际是总响应时间，这一点在对比性能数字时经常造成错觉。核

15.6 取消重试

取消、超时和重试是一组状态机。客户端取消后，后端是否立即停止生成？网关断开但调度器没收到取消，GPU 会继续计算无人消费的 token。取消要从入口穿到调度器和引擎，并在计量层记录已完成的实际用量。超时要分层设计：客户端 30 秒、网关 60 秒、服务端无上限的组合，会让客户端先重试而旧请求仍在运行，新旧请求共同占用容量。重试策略至少回答四个问题：哪些错误可重试，在哪一层重试，最大次数和退避是什么，有没有幂等键。对纯文本生成，重试可能得到不同答案；对已经发邮件、下订单的 agent，盲目重试会重复副作用，推理服务的边界与上层应用的幂等控制必须在接口上写清。

多租户入口是控制面，不只是转发地址：只按请求数限流会低估长提示词，只按 token 计量又无法预知输出长度，实践中要组合请求率、输入 token、并发、输出上限和动态负载，并为交互与批量任务设不同队列。验收也不应只测正常返回：无效密钥、配额耗尽、长输入、中途取消、网关断连、服务端过载、单副本摘流、计量延迟与重复请求，每个场景都要定义协议结果、在途 GPU 工作是否停止、是否计费、是否可重试。