| Q38 | What is batch inference, and how does it differ from single-query inference
1️⃣ 考察意图
面试官想确认你是否真正理解 LLM 推理的底层工程原理，而非仅背概念。这题看似基础，但“刁钻点”在于：你是否能区分静态批处理（static batching）和动态批处理（continuous batching），以及能否量化批处理对吞吐量（throughput）和延迟（latency）的 trade-off。答好了，能展示你对 GPU 计算特性（如计算密集型 vs 内存密集型）的直觉，以及在生产环境中优化推理系统的实战经验。
2️⃣ 标准答
核心定义：Batch inference 是将多个独立输入请求合并为一个批次，一次性通过模型前向传播，利用 GPU 并行计算能力同时生成输出。Single-query inference 则一次只处理一个请求。
关键差异：
- 吞吐量 vs 延迟：单查询延迟低（首 token 延迟通常 < 100ms），但 GPU 利用率低（尤其小 batch 时，计算单元空闲）。批处理吞吐量高（queries/s 可提升 10-100x），但延迟会线性增加（因为要等批次中所有请求完成）。
- 计算特性：LLM 推理是内存密集型（尤其 decoder 阶段，需反复读取 KV cache）。批处理能摊薄模型参数加载和注意力计算的固定开销。例如，batch size 从 1 到 8，吞吐量可能提升 5x，但延迟只增加 2x（因为计算瓶颈在内存带宽而非算力）。
- 填充（Padding）开销：批处理要求输入长度一致，短序列需填充到最长序列长度。这导致计算浪费（填充 token 的注意力计算是无效的）。实际工程中，可用动态批处理（continuous batching）解决：不等待所有请求完成，而是将新请求插入到正在运行的批次中（如 vLLM 的调度策略），减少填充浪费。
实际落地的坑 + 解法：
- 坑：静态批处理中，若请求长度差异大（如 10 token vs 1000 token），填充浪费可达 90%+，吞吐量反而不如小 batch。
- 解法：使用动态批处理（如 vLLM 的 PagedAttention 和调度器），或分桶批处理（bucket batching）：按长度分桶（如 0-50 token、50-200 token 等），桶内批处理，桶间串行。这能平衡填充开销和批大小。
工具与实现：
- Hugging Face pipeline：
pipeline("text-generation", model=model, batch_size=8)实现静态批处理。 - vLLM：原生支持 continuous batching，吞吐量比 HF pipeline 高 10-20x（【通用知识】）。
- TensorRT-LLM：支持 inflight batching（类似 continuous batching），并优化了 KV cache 管理。
工程取舍：
- 离线 vs 在线：离线任务（如数据标注、批量摘要）用大 batch（如 64-128），追求吞吐量；在线服务（如聊天机器人）用小 batch（如 1-4）或动态批处理，保证首 token 延迟 < 200ms。
- 模型大小：小模型（如 7B）对 batch size 更敏感，大模型（如 70B）受显存限制，batch size 通常更小（如 1-8）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，定义与差异——批处理利用 GPU 并行性提升吞吐量，但牺牲延迟；单查询反之。第二，工程细节——批处理需要填充，导致计算浪费，动态批处理（如 vLLM 的 continuous batching）能缓解。第三，场景取舍——离线任务用大 batch，在线服务用小 batch 或动态批处理。总结一句：批处理是吞吐量-延迟的 trade-off，核心在于用 GPU 内存带宽换计算效率。”
4️⃣ 高频追问 & 应对
追问 1：动态批处理（continuous batching）具体怎么实现？和静态批处理比，性能提升多少？
动态批处理的核心是调度器：不等待批次中所有请求完成，而是每步（step）检查是否有请求完成（如生成了 EOS token），立即将其移出批次，并插入新请求。vLLM 用 PagedAttention 管理 KV cache，支持请求级抢占和调度。性能上，【通用知识】在 ShareGPT 数据集上，vLLM 的 continuous batching 比 HF pipeline 的静态批处理吞吐量高 10-20x，且延迟分布更平滑（P50 延迟接近单查询）。关键 trade-off：调度器开销（每步检查）和显存碎片（PagedAttention 的 page 管理）。
追问 2：批处理时，batch size 怎么选？有没有公式或经验法则？
没有固定公式，但可基于显存预算和延迟约束估算。显存占用 = 模型参数 + KV cache（batch_size * seq_len * num_layers * 2 * dtype_size）。例如，7B 模型（FP16）参数占 14GB，若 batch_size=8，seq_len=2048，KV cache 约 820483222 = 2GB，总显存 16GB（A100 40GB 够用）。经验法则：在线服务 batch_size 不超过 4（保证首 token 延迟 < 200ms）；离线任务从 32 开始，逐步增加直到显存 OOM 或吞吐量不再线性增长。可用吞吐量-延迟曲线（如 vLLM 的 benchmark）找到拐点。
追问 3：批处理对生成质量有影响吗？比如 batch 内请求互相干扰？
理论上无影响，因为每个请求独立计算注意力（mask 确保互不干扰）。但实践中，若使用采样（如 top-k, temperature），随机种子不同，结果独立。唯一潜在问题：填充 token 的注意力计算是无效的，但不会污染有效 token 的表示。若使用beam search，批处理需独立维护每个请求的 beam，显存开销更大。质量无影响，但效率有影响（填充浪费）。
5️⃣ 避坑 · 常见错误答法
- ❌ “批处理就是把多个请求拼在一起，一次推理，速度更快。” → ✅ “批处理提升吞吐量，但延迟会因等待批次填满和填充而增加。必须区分静态和动态批处理，并说明填充开销。”
- ❌ “批处理适合所有场景，单查询已过时。” → ✅ “批处理不适合实时交互（如语音助手），因为延迟敏感。在线服务需用动态批处理或小 batch 保证首 token 延迟。”
- ❌ “批处理 batch size 越大越好。” → ✅ “batch size 受显存和延迟约束，过大导致 OOM 或延迟不可接受。需用吞吐量-延迟曲线找到最优值。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从文档检索后的批量摘要切入，说明如何用 batch inference 处理大量查询（如 1000 个 query 同时生成摘要），并对比单查询的耗时差异。
- 如果你只做过传统 NLP：类比传统模型（如 BERT）的 batch inference，强调 LLM 的 decoder 架构导致 KV cache 管理更复杂，需用 continuous batching 优化。
- 如果你是校招无项目：聚焦 Hugging Face pipeline 的 batch_size 参数实验，展示你理解填充开销和吞吐量-延迟 trade-off，并提及 vLLM 论文（如 PagedAttention）作为延伸。
- vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention (OSDI 2023)
- TensorRT-LLM: Inflight Batching and Multi-Instance GPU for LLM Inference
- Hugging Face Pipeline:
pipeline("text-generation", batch_size=...)官方文档 - 论文：Orca: A Distributed Serving System for Transformer-Based Generative Models (OSDI 2022)
- 博客：LLM Inference Performance Engineering: Batch Size, Latency, and Throughput (Anyscale)