KV Cache & Inference Optimizations: 解释连续批处理（continuous batching）与静态批处理的差异。

Core Concept: 静态批需等整批完成才能换新请求（GPU 空转）；连续批在每步迭代后动态插入/移除请求，大幅提升吞吐。

数学机理：<strong>静态批处理（static batching）</strong> 把一批请求一起提交、一起等待完成：因为不同请求的输出长度不同，整个批的耗时由<strong>最长的那个</strong>决定；短请求完成后其占用的资源<strong>空闲但无法被利用</strong>（必须等整批结束）。故 GPU 利用率 = （总有效计算）/（批耗时 × 资源），在长度差异大时利用率很低（可能 <50%）。<strong>连续批处理（continuous batching，又称 iteration-level scheduling，Yu 等 2022 Orca）</strong> 的核心：<strong>在每个 decode step 之后重新组批</strong>——已完成（生成 EOS 或达到上限）的请求<strong>立即移出</strong>、腾出的槽位<strong>立即补入</strong>等待队列中的新请求。这样 GPU 几乎始终满负荷，吞吐大幅提升（Orca 报告 2~36 倍，取决于长度分布）。<strong>关键前提</strong>——(a) <strong>KV cache 需能动态分配/释放</strong>（PagedAttention 提供块级管理）；(b) <strong>注意力需支持批内不同长度</strong>（变长序列的批处理，用 mask 与 ragged tensor）；(c) <strong>调度器</strong>需在每步决定'谁进谁出'（如按 FCFS、或按优先级/公平性）。<strong>与 chunked prefill 的结合</strong>——新请求的 prefill（长 prompt）会占用大量算力、阻塞 decode；故现代引擎把 prefill 切块（chunked）并与 decode 混批，进一步优化延迟与吞吐。

深度剖析与工程权衡：① <strong>为什么这是'吞吐'而非'延迟'优化</strong>——连续批提升的是整体吞吐（单位时间处理的请求数）；单请求延迟可能略增（因为要与其他请求竞争）。故它适合'高负载服务'。② <strong>调度策略的权衡</strong>——(a) <strong>FCFS</strong>（先来先服务）公平但可能被长请求阻塞；(b) <strong>优先级调度</strong>（如区分交互式与批处理）；(c) <strong>公平调度</strong>（如 vLLM 的'公平共享'，防止某请求长期占用）；调度器是推理引擎的核心竞争力之一。③ <strong>与 PagedAttention 的协同</strong>——连续批需要'动态分配与回收 KV 块'，而 PagedAttention 的块级管理正好提供这一能力；两者是配套技术（vLLM 同时实现）。④ <strong>变长注意力的实现</strong>——批内序列长度不同，注意力 kernel 需支持'每个序列有自己的 KV 长度'（用块表与变长 mask）；这是工程复杂度所在。⑤ <strong>与投机解码的交互</strong>——投机解码使每个请求每步推进的 token 数不同（取决于接受长度），进一步增加调度的动态性。⑥ <strong>面试要点</strong>——被问'如何提升推理吞吐'，应给出'<strong>连续批处理（动态组批）+ PagedAttention（动态 KV 管理）+ chunked prefill（混批）</strong>'的组合，并说明'静态批的浪费来自最长请求'；能提到调度策略（FCFS/优先级/公平）是深度理解的标志。