What are the techniques by which you can optimize the inference of LLM for higher throughput
1️⃣ 考察意图
面试官想考察你对 LLM 推理全栈优化的系统性理解，而非零散知识点。这是典型的“系统设计 + 工程取舍”题，刁钻点在于：吞吐量提升往往以延迟或显存为代价，你需要展示如何平衡。答好了能展示你从模型层到系统层、再到硬件层的优化视野，以及实际部署中踩坑后的经验，这是大厂做高并发服务（如 API 网关、实时对话）的核心能力。
2️⃣ 标准答
优化 LLM 推理吞吐量，核心思路是“减少计算量 + 提高并行度 + 降低显存瓶颈”。我从模型、系统、硬件三个层面展开。
模型层优化
- 量化：将权重从 FP16 降到 INT8 或 INT4。常用 GPTQ（逐层量化，精度损失小）和 AWQ（基于激活感知的量化，对 outlier 更鲁棒）。例如 Llama 2-7B 用 INT4 量化后，显存占用从 14GB 降到 4GB，批处理大小可翻倍，吞吐量提升 2-3 倍。坑：量化后激活值可能溢出，需用动态缩放或 SmoothQuant 预处理。
- 架构改进：用 Group Query Attention (GQA) 替代 Multi-Head Attention (MHA)。GQA 将 KV 头数减少（如 32 头变 8 组），显存占用降 4 倍，且计算量减少。Llama 2 70B 用 GQA 后，推理吞吐量提升 30%。取舍：GQA 会轻微降低模型质量（约 0.5% 困惑度），但吞吐量收益远大于损失。
- FlashAttention：通过 tiling 和重计算，避免显存中存储完整注意力矩阵，将 O(N²) 显存占用降到 O(N)。在长序列（如 8K tokens）下，FlashAttention-2 可让吞吐量提升 2 倍，且不牺牲精度。
系统层优化
- 连续批处理（Continuous Batching）：传统批处理需等整个 batch 完成才释放资源，而 vLLM 的 PagedAttention 实现“请求级调度”——一个请求生成完 token 后立即退出，新请求插入。实测在 Llama 2-7B 上，吞吐量提升 2-4 倍。坑：连续批处理需要动态管理 KV 缓存，vLLM 用虚拟内存分页解决碎片问题，但页表开销在 batch 极大时（>256）会成瓶颈。
- KV 缓存管理：使用 Prefix Caching（如 SGLang 的 RadixAttention）缓存公共前缀的 KV 值，对多轮对话或系统提示（如 2K tokens 的 prompt）可减少 50% 计算量。取舍：缓存命中率依赖请求相似度，在随机查询场景下收益低。
- 请求调度：用动态批处理（Dynamic Batching）将短请求合并，减少 GPU 空闲。TensorRT-LLM 的 inflight batching 支持在解码阶段动态插入新请求，吞吐量提升 30%。
硬件层优化
- 张量核心（Tensor Cores）：利用 NVIDIA GPU 的 FP8/INT8 Tensor Cores，计算速度比 FP16 快 2 倍。需确保算子（如 matmul）对齐到 16 的倍数，否则退化为 CUDA core。
- 模型并行：张量并行（Tensor Parallelism）将单个层切分到多 GPU，适合单机多卡（如 8x A100）；流水线并行（Pipeline Parallelism）将层分段，适合跨机。坑：张量并行通信开销大（all-reduce 延迟），在 batch 小时（<4）反而降低吞吐量，需用 1F1B 调度（一次前向一次后向）隐藏通信。
实际落地组合：用 vLLM + INT4 量化 + FlashAttention + 连续批处理，在 1x A100 上部署 Llama 2-7B，吞吐量可达 2000 tokens/s（batch=32），延迟 < 100ms。若用 TensorRT-LLM + FP8 + 张量并行（2x A100），吞吐量可再翻倍。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从模型层、系统层、硬件层三个层面回答。模型层用量化（如 INT4 的 GPTQ）和架构改进（如 GQA）减少计算量；系统层用连续批处理（vLLM 的 PagedAttention）和 KV 缓存管理提升并行度；硬件层用 Tensor Cores 和模型并行压榨 GPU。总结一句：吞吐量优化是计算-显存-通信的三角平衡，需根据场景选择组合。”
4️⃣ 高频追问 & 应对
追问 1：你提到量化会损失精度，具体怎么评估？在什么场景下不可接受？
评估指标：用 perplexity 变化（<1% 可接受）和下游任务（如 MMLU）准确率下降（<0.5%）。不可接受场景：代码生成（如 CodeLlama）中 INT4 量化可能引入语法错误，需用 INT8 或 AWQ 的 per-group 量化。实际做法：先跑 benchmark，若 perplexity 上升 >2%，回退到 FP16 或改用 SmoothQuant。
追问 2：连续批处理中，如果请求长度差异很大（如 100 tokens vs 10K tokens），怎么优化？
核心问题是显存碎片和负载不均。解法：1）用 vLLM 的 PagedAttention 按页分配，避免碎片；2）实现“长度感知调度”，将短请求优先处理，长请求单独批处理；3）用动态 chunking，将长请求拆成多个短段，但需注意上下文丢失。取舍：chunking 增加调度开销，在长请求占比 <10% 时收益低。
追问 3：你提到了 FlashAttention，它和普通 attention 比，在吞吐量上具体差多少？
在 8K 序列长度下，FlashAttention-2 比 PyTorch 原生 attention 快 2-3 倍，显存占用从 O(N²) 降到 O(N)。但注意：FlashAttention 只优化计算和显存，不改变算法复杂度，在短序列（<512 tokens）下收益可忽略，甚至因 kernel launch 开销更慢。实际部署中，建议序列长度 > 2K 时才启用。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提量化，说“用 INT4 就能提升 4 倍吞吐量” → ✅ 量化只减少显存，吞吐量提升依赖批处理大小，需结合连续批处理才能翻倍。
- ❌ 说“模型并行一定能提升吞吐量” → ✅ 模型并行引入通信开销，在 batch 小时反而降低吞吐量，需用 1F1B 调度或流水线并行隐藏延迟。
- ❌ 忽略 KV 缓存，只讲计算优化 → ✅ KV 缓存是显存瓶颈，尤其长序列下，Prefix Caching 可减少 50% 计算量。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从 KV 缓存管理切入，讲如何用 Prefix Caching 缓存系统提示（如 2K tokens 的检索 prompt），减少重复计算，提升吞吐量 30%。
- 如果你只做过传统 NLP：用“批处理优化”类比，讲传统 NLP 的 batch 是静态的，而 LLM 需连续批处理，结合你之前做过的请求调度经验（如 Web 服务负载均衡）。
- 如果你是校招无项目：聚焦 FlashAttention 论文复现，讲你如何用 CUDA 实现 tiling 和重计算，并对比 PyTorch 原生 attention 的吞吐量差异，展示底层理解。
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness (Dao et al., 2022)
- vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., 2023)
- AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (Lin et al., 2023)
- TensorRT-LLM: NVIDIA’s Open-Source Library for LLM Inference Optimization
- Efficient Large Language Model Inference: A Survey (2024, arXiv:2312.03014)