What are the challenges in LLM inference
1️⃣ 考察意图
面试官想看你能否系统性地拆解 LLM 推理的整条链路瓶颈，而不是只背几个“显存大、速度慢”的泛泛之谈。考察类型是系统设计 + 工程取舍。刁钻点在于：你是否能区分算法复杂度（如 Attention 的 O(n²)）、工程瓶颈（如 KV Cache 管理、动态 batching 调度）和硬件限制（如显存带宽 vs 算力利用率）。答好了能展示你对推理优化（如 FlashAttention、PagedAttention、vLLM、TensorRT-LLM）的实战理解，以及从“能用”到“好用”的工程思维。
2️⃣ 标准答
LLM 推理的挑战可以从三个层面拆解：显存瓶颈、计算瓶颈和工程调度瓶颈。每个层面都有具体的 trade-off 和落地坑。
显存瓶颈：KV Cache 与模型参数
- KV Cache 增长：自回归解码时，每生成一个 token，需要缓存之前所有 token 的 Key 和 Value。对于 7B 模型，序列长度 2048 时，KV Cache 约 1.5GB（FP16）；长度到 32K 时，暴涨到 24GB，直接撑爆单卡显存。坑：长上下文推理时，显存被 KV Cache 吃掉，留给模型参数的空间不足，导致 OOM。
- 模型参数加载：7B 模型 FP16 权重约 14GB，70B 模型约 140GB，单卡 A100（80GB）放不下。解法：模型并行（Tensor Parallelism / Pipeline Parallelism）或量化（INT8/INT4）。Trade-off：量化到 INT4 显存减半，但精度损失在复杂推理任务（如数学、代码）上可能不可接受；FP8 是当前折中方案，但硬件支持（H100）不普及。
- 实际落地的坑：动态 batching 时，不同请求的序列长度不同，KV Cache 碎片化严重。解法：vLLM 的 PagedAttention，像操作系统管理内存一样管理 KV Cache 的块（block），减少碎片，提升显存利用率 2-4 倍。
计算瓶颈：自回归与 Attention 复杂度
- 自回归串行性：生成每个 token 依赖前一个 token，无法并行，导致 GPU 利用率低（尤其在 batch size 小时）。坑：小 batch 下 GPU 算力利用率可能不到 10%，大部分时间在等显存带宽。解法：增大 batch size（动态 batching），但受限于显存。
- Attention 二次复杂度：标准 Attention 计算量随序列长度平方增长。序列 32K 时，单次 Attention 计算量是 4K 时的 64 倍。解法：FlashAttention（通过 tiling 减少显存读写，加速 2-4 倍）或稀疏 Attention（如 Longformer、BigBird）。Trade-off：FlashAttention 对短序列收益不大，且需要 Ampere 以上架构支持；稀疏 Attention 会丢失全局信息，不适合需要长程依赖的任务（如文档摘要）。
- 实际落地的坑：首 token 延迟（prefill 阶段）和逐 token 延迟（decode 阶段）的平衡。prefill 阶段计算密集，decode 阶段显存带宽密集。解法：Splitwise 架构，将 prefill 和 decode 分离到不同 GPU 集群，分别优化。
工程调度瓶颈：动态 batching 与请求管理
- 动态 batching：不同请求的输入输出长度差异大，固定 batching 会导致短请求等长请求，增加延迟。解法：Continuous Batching（如 Orca 论文），每生成一个 token 就检查 batch 中是否有请求完成，立即插入新请求，提升吞吐 2-3 倍。
- 请求调度：高并发下，需要平衡延迟和吞吐。坑：FIFO 调度会导致长请求阻塞短请求，增加 P99 延迟。解法：基于预估输出长度的优先级调度（如 Shortest Job First），或使用请求排队 + 超时机制。
- 负载均衡与容错：多 GPU 推理时，某张卡故障会导致整个服务中断。解法：使用推理引擎（如 TensorRT-LLM、vLLM）内置的容错机制，或部署多个副本 + 健康检查。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从显存、计算、工程调度三个层面回答。显存层面，核心是 KV Cache 随序列长度线性增长，导致长上下文 OOM，解法是 PagedAttention 和量化；计算层面，自回归串行性和 Attention 二次复杂度导致 GPU 利用率低，解法是 FlashAttention 和动态 batching；工程层面，变长请求的调度和负载均衡是难点，解法是 Continuous Batching 和优先级调度。总结一句：LLM 推理的挑战本质是‘显存墙’和‘计算墙’的博弈，需要算法、工程、硬件三管齐下。”
4️⃣ 高频追问 & 应对
追问 1：你说 PagedAttention 能提升显存利用率，具体怎么做的？和传统 KV Cache 管理比有什么 trade-off？
PagedAttention 将 KV Cache 分成固定大小的 block（如 16 个 token 的 block），通过 block table 映射逻辑地址到物理地址。传统方法需要连续显存，导致碎片；PagedAttention 允许非连续存储，显存利用率从 60% 提升到 95%+。Trade-off：增加了 block table 的查找开销，但相比减少的显存碎片和 OOM 风险，收益远大于成本。vLLM 实测在 7B 模型、batch size 32 时，吞吐提升 2-4 倍。
追问 2：FlashAttention 加速的原理是什么？为什么不是所有场景都用它？
FlashAttention 通过 tiling 将 Q、K、V 分块加载到 SRAM 中计算，避免频繁读写 HBM，减少显存带宽瓶颈。原理：利用 GPU 的 SRAM（约 20MB）做中间计算，一次 tiling 计算一个子块的 Attention，最后合并。不适用场景：短序列（<512）时，tiling 开销占比大，加速不明显；且需要 Ampere 架构的 Tensor Core 支持，V100 上无法使用。
追问 3：如果让你设计一个支持 100 并发请求的推理系统，你会怎么选型？vLLM 还是 TensorRT-LLM？
选型取决于场景。低延迟优先（如聊天机器人）：选 vLLM，因为 PagedAttention 和 Continuous Batching 对变长请求友好，首 token 延迟低。高吞吐优先（如批量离线推理）：选 TensorRT-LLM，因为其支持更激进的图优化和 INT4/FP8 量化，吞吐可提升 30-50%。坑：TensorRT-LLM 的编译时间长，不适合频繁换模型；vLLM 对长上下文支持更好（如 128K 序列）。折中方案：vLLM 作为前端，后端挂载 TensorRT-LLM 的优化引擎。
5️⃣ 避坑 · 常见错误答法
- ❌ 只说“显存不够、速度慢”，没有具体数字或方法名。 → ✅ 给出具体数字（如 7B 模型 KV Cache 1.5GB @ 2048 长度）和方法名（PagedAttention、FlashAttention），展示工程细节。
- ❌ 把“量化”当成万能解法，不提精度损失。 → ✅ 指出 INT4 量化在数学推理任务上可能掉点 5-10%，并给出折中方案（如 FP8 或混合精度）。
- ❌ 忽略工程调度，只谈算法优化。 → ✅ 强调动态 batching 和请求调度对实际系统吞吐的影响，并引用 Orca 论文的 Continuous Batching 概念。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从长上下文推理的显存挑战切入，说明 KV Cache 管理如何影响 RAG 的文档检索和生成质量，并提到你用过 vLLM 优化。
- 如果你只做过传统 NLP：用“序列长度 vs 计算量”类比传统 RNN 的 BPTT 问题，说明 Attention 的二次复杂度是 LLM 特有的瓶颈，并展示你理解 FlashAttention 的 tiling 原理。
- 如果你是校招无项目：聚焦 FlashAttention 和 PagedAttention 的论文复现 demo，说明你理解 GPU 显存层次和 block 管理，并提到你对比过不同 batch size 下的吞吐差异。
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness (Dao et al., 2022)
- PagedAttention: Efficient Memory Management for Large Language Model Serving with vLLM (Kwon et al., 2023)
- Orca: A Distributed Serving System for Transformer-Based Generative Models (Yu et al., 2022)
- TensorRT-LLM: NVIDIA’s Open-Source Library for LLM Inference Optimization
- Efficient Memory Management for Large Language Model Serving: A Survey (2024)