What is batch inference, and how does it differ from single-query inference
1️⃣ 考察意图
面试官想确认你是否真正理解 LLM 推理的底层工程逻辑，而非只背概念。这道题表面是“定义对比”，实际考察三点：吞吐量与延迟的取舍（trade-off）、变长序列的工程处理（padding/attention mask）、动态批处理的实现原理。刁钻点在于：很多人能说出“批处理快”，但说不清为什么快、代价是什么、以及如何在实际系统中平衡。答好了能展示你对 GPU 计算特性（SM 利用率、显存带宽）和推理框架（vLLM、TGI）的实战理解，这是大厂做高并发服务的基础硬实力。
2️⃣ 标准答
核心定义
- 单查询推理：一次只处理一个输入序列，模型从输入到输出串行完成。适用于低延迟场景（如聊天机器人），但 GPU 利用率极低——因为 GPU 擅长并行计算，单序列只能利用一小部分 SM（Streaming Multiprocessor）。
- 批推理：将多个独立请求合并为一个 batch，同时送入模型。模型参数在 batch 内共享，计算矩阵维度从
[1, seq_len, hidden]变为[batch_size, seq_len, hidden]，大幅提升吞吐量（tokens/s）。
关键差异与工程细节
- 变长序列处理：单查询无需处理长度差异；批推理必须解决。常用方法：
- Padding：将所有序列填充到 batch 内最大长度，浪费计算和显存（例如 90% 序列长度 100，一个序列 1000，则 90% 的 padding token 被无效计算）。
- Attention Mask：通过 mask 让模型忽略 padding token，但计算量不变。
- 更优方案：vLLM 的 PagedAttention 和 Continuous Batching 动态管理 KV Cache，避免 padding 浪费；TGI 的 FlashAttention 支持非对齐序列，减少无效计算。
- 延迟 vs 吞吐量取舍：
- 单查询：延迟低（毫秒级），但吞吐量受限于单次推理时间（例如 1 秒只能处理 1 个请求）。
- 批推理：延迟略高（需等待 batch 填满或超时），但吞吐量随 batch size 线性增长（例如 batch size=8 时，吞吐量提升 5-7 倍，延迟增加 20-50%）。实际落地的坑：batch size 过大时，显存 OOM 或延迟飙升（因为 GPU 计算时间随 batch size 超线性增长），需通过实验找到最优 batch size（通常 8-32）。
- 动态批处理：生产环境不固定 batch size，而是用调度器实时聚合请求。例如 vLLM 的 Iteration-level Scheduling：每个解码步骤动态决定哪些序列继续生成、哪些结束，避免等待整个 batch 完成。工程取舍：动态批处理增加调度开销（CPU 侧），但能明显提升 GPU 利用率（从 30% 到 80%+）。
实际落地的坑 + 解法
- 坑：Padding 导致显存浪费，batch 内长序列拖慢短序列（“木桶效应”）。
- 解法：使用 FlashAttention 或 PagedAttention 消除 padding；或对请求按长度分组（类似 bin packing），减少长度差异。
总结：批推理是 LLM 服务高吞吐的核心，但必须处理变长序列、平衡延迟、并选择合适调度策略。单查询适合低延迟场景，批推理适合高并发场景。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，定义层面——单查询一次处理一个序列，批推理合并多个序列并行计算；第二，工程差异——批推理必须处理变长序列（padding/attention mask），而单查询不用，这导致显存和计算效率的取舍；第三，实际系统——动态批处理（如 vLLM 的 Continuous Batching）能平衡延迟和吞吐量，但需要调度开销。总结一句：批推理通过牺牲少量延迟换取大幅吞吐量提升，是 LLM 服务高并发的基石。”
4️⃣ 高频追问 & 应对
追问 1：批推理的 batch size 怎么选？为什么不是越大越好？
选 batch size 需考虑三点：显存限制（每个序列的 KV Cache 占用显存，batch size 过大导致 OOM）、计算效率（GPU 利用率随 batch size 增加先升后降，因为 SM 饱和后计算时间超线性增长）、延迟要求（batch size 越大，单个请求等待时间越长）。实际做法：用 profiling 工具（如 NVIDIA Nsight）测试不同 batch size 下的吞吐量和延迟曲线，找到拐点（通常 batch size=8-32）。例如，在 A100 上，batch size=16 时吞吐量接近峰值，再增加收益递减。
追问 2：Continuous Batching 和 Static Batching 有什么区别？
Static Batching：固定 batch 大小，等待所有请求完成再释放资源，导致空闲等待（例如一个长序列拖慢整个 batch）。Continuous Batching（vLLM 提出）：每个解码步骤动态决定哪些序列继续、哪些结束，新请求可立即加入空闲 slot。代价是调度复杂度高（需管理多个序列的 KV Cache 状态），但 GPU 利用率从 50% 提升到 90%+。TGI 也支持类似机制，但实现细节不同（vLLM 用 PagedAttention，TGI 用 FlashAttention）。
追问 3：批推理时，变长序列的 padding 怎么优化？
核心优化是避免 padding 带来的无效计算。方法一：FlashAttention 支持非对齐序列，通过分块计算减少 padding 影响；方法二：PagedAttention 将 KV Cache 分页管理，每个序列独立存储，无需 padding；方法三：请求按长度分组（如长度 1-100 一组，101-200 一组），减少 batch 内长度差异。实际工程中，vLLM 的 PagedAttention 是主流方案，因为它同时解决了显存碎片和 padding 问题。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“批推理就是同时处理多个请求，速度更快” → ✅ 正确切入：批推理不是“更快”，而是“吞吐量更高”，延迟反而可能增加（因为等待 batch 填充）。必须强调 trade-off。
- ❌ 说“批推理不需要处理变长序列，模型会自动处理” → ✅ 正确切入：必须明确 padding 和 attention mask 是批推理的核心工程难点，并提到 FlashAttention/PagedAttention 等优化方案。
- ❌ 说“batch size 越大越好” → ✅ 正确切入：batch size 受显存和计算效率限制，需通过实验找到最优值，并提到 OOM 和延迟拐点。
6️⃣ 简历呼应
- 如果你有 LLM 推理部署项目：从实际调优经验切入，例如“我在部署 7B 模型时，用 vLLM 的 Continuous Batching 将吞吐量从 50 tokens/s 提升到 300 tokens/s，但发现 batch size=16 时显存瓶颈，改用 PagedAttention 解决”。
- 如果你只做过传统 NLP 模型：用类比迁移，例如“传统 NLP 中批处理也面临变长序列问题（如 RNN 的 padding），但 LLM 的 KV Cache 让问题更复杂，需要动态管理”。
- 如果你是校招无项目：聚焦论文复现，例如“我读过 vLLM 论文，理解 PagedAttention 如何通过分页管理 KV Cache 消除 padding 浪费，并复现了简单 demo 验证吞吐量提升”。
- vLLM 论文：Efficient Memory Management for Large Language Model Serving with PagedAttention
- TGI 文档：Text Generation Inference 的 Continuous Batching 实现
- FlashAttention 论文：Fast and Memory-Efficient Exact Attention with IO-Awareness
- NVIDIA 博客：Maximizing LLM Inference Throughput with Dynamic Batching
- 博客：LLM Inference 性能优化实战——从 Single Query 到 Continuous Batching