目前业界大模型推理框架很多，各有什么优缺点，应该如何选择
1️⃣ 考察意图
面试官想考察的不是你背框架特性表的能力，而是工程选型的系统思维。刁钻点在于：框架对比没有绝对优劣，核心是看你在“吞吐量 vs 延迟”、“易用性 vs 极致性能”、“通用性 vs 硬件绑定”之间的取舍判断。答好了能展示你对推理整条链路（显存管理、算子优化、批处理策略）的底层理解，以及面对真实业务场景时，如何用数据驱动决策，而非凭感觉选框架。
2️⃣ 标准答
主流框架速览与核心差异
- vLLM：基于 PagedAttention 的显存管理，动态批处理（continuous batching）是杀手锏。优势是显存利用率高，支持多轮对话的 KV Cache 复用，社区活跃，API 兼容 OpenAI。劣势是自定义算子少，对 MoE 模型支持弱于 TensorRT-LLM。
- TensorRT-LLM：NVIDIA 官方出品，深度绑定 CUDA 生态。核心是图优化 + 算子融合 + FP8/INT4 量化，单卡吞吐量通常比 vLLM 高 10-20%。劣势是部署复杂，需编译优化，动态形状支持差，换模型要重新编译。
- llama.cpp：纯 CPU/边缘设备优化，用 GGUF 格式和量化（Q4_K_M 等）把模型压到 4GB 以内。优势是零 GPU 依赖，启动快。劣势是吞吐量低，不支持多卡并行，不适合高并发在线服务。
- TGI (Text Generation Inference)：HuggingFace 出品，与 Transformers 生态无缝集成。优势是开箱即用，支持 LoRA 热加载。劣势是性能中庸，显存管理不如 vLLM 激进，适合快速原型验证。
关键取舍维度
- 显存效率：vLLM 的 PagedAttention 把 KV Cache 分页管理，碎片率从 30% 降到 5% 以下【通用知识】。TensorRT-LLM 用预分配连续内存，碎片少但灵活性差。选型时看你的平均序列长度：如果长尾请求多（如 4K token 占 20%），vLLM 优势明显；如果序列长度稳定，TensorRT-LLM 更优。
- 吞吐量 vs 延迟：高并发场景（QPS > 100），vLLM 的 continuous batching 能填满 GPU 算力，吞吐量接近理论峰值。但 TTFT（首 token 延迟）比 TensorRT-LLM 高 10-30ms，因为动态批处理引入调度开销。低延迟场景（如实时对话），TensorRT-LLM 的图优化更稳。
- 量化支持：TensorRT-LLM 支持 FP8、INT4（AWQ/GPTQ），精度损失 < 1% 但吞吐量提升 2x。vLLM 的量化依赖外部库（如 AutoGPTQ），集成度低。llama.cpp 的 Q4_K_M 量化在 CPU 上跑 7B 模型能到 20 token/s，但精度损失约 3-5%。
实际落地的坑 + 解法
- 坑 1：vLLM 在长序列（>8K token）下，PagedAttention 的 page 表查询开销剧增，导致 TPOT（每 token 延迟）从 30ms 飙到 80ms。解法：用
max_num_batched_tokens限制单次批处理 token 数，或切换到 TensorRT-LLM 的 FlashAttention-2 优化。 - 坑 2：TensorRT-LLM 编译时，如果模型结构有自定义 op（如 LLaMA 的 RoPE 实现），编译失败。解法：用
trtllm-build的--plugin参数注册自定义 op，或直接改源码用官方实现。 - 坑 3：llama.cpp 在多 GPU 场景下，显存分配不均导致 OOM。解法：用
--tensor-split手动分配每张卡的层数，或切到 vLLM 的 tensor parallelism。
选型建议
- 高并发在线服务（QPS > 50，A100/H100）：vLLM 优先，社区成熟，运维成本低。如果对延迟敏感（TTFT < 200ms），用 TensorRT-LLM 做 A/B 测试。
- 边缘设备/离线推理（无 GPU，或单卡 24GB 以下）：llama.cpp 唯一选择，量化到 Q4 后 7B 模型跑在 16GB 内存上。
- 研究实验/快速迭代：TGI 或 HuggingFace 原生，LoRA 热加载方便，但别上生产。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，主流框架的核心差异——vLLM 靠 PagedAttention 优化显存，TensorRT-LLM 靠图优化压榨 GPU，llama.cpp 专攻边缘设备。第二，选型的关键取舍——高并发选 vLLM，低延迟选 TensorRT-LLM，无 GPU 选 llama.cpp。第三，实际落地要避开三个坑：vLLM 长序列性能下降、TensorRT-LLM 编译失败、llama.cpp 多卡显存不均。总结一句：没有万能框架，用数据（QPS、TTFT、显存）驱动选型。”
4️⃣ 高频追问 & 应对
追问 1：你提到 vLLM 的 PagedAttention 显存碎片率低，能具体说说原理吗？和 TensorRT-LLM 的连续内存比，哪个在显存不足时更鲁棒？
PagedAttention 把 KV Cache 分成固定大小的 page（默认 16 token），用 page table 映射逻辑地址到物理地址。碎片率低是因为它允许非连续物理内存，类似操作系统的虚拟内存。TensorRT-LLM 的连续内存是预分配一个固定大小的 buffer，如果序列长度超过 buffer 上限，直接 OOM。vLLM 更鲁棒，因为它可以动态扩展 page，但代价是 page table 查询开销。实测在 80GB A100 上，vLLM 能处理 32K token 的 70B 模型，TensorRT-LLM 只能处理 24K 左右【通用知识】。
追问 2：如果业务要求 FP8 量化，你会选哪个框架？为什么？
选 TensorRT-LLM。它原生支持 FP8 量化，通过
--quantize fp8编译，精度损失 < 0.5% 且吞吐量提升 2x。vLLM 的 FP8 支持依赖外部库（如 FP8-LM），集成度低，且需要手动校准。但注意：FP8 只对 H100 及以上硬件生效，A100 只能用 INT8。如果硬件是 A100，我会用 TensorRT-LLM 的 INT4 AWQ 量化，吞吐量提升 1.5x，精度损失 < 1%。
追问 3：你提到 continuous batching，它和 static batching 比，在什么场景下会失效？
Continuous batching 的核心是动态插入新请求到正在运行的 batch 中，提高 GPU 利用率。但失效场景：1）请求长度极度不均匀（如 90% 是 128 token，10% 是 8K token），短请求会被长请求阻塞，导致 TPOT 波动大。2）QPS 极低（< 1），batch 永远填不满，continuous batching 的调度开销反而降低效率。解法：低 QPS 时切到 static batching，或设置
max_num_seqs限制 batch 大小。
5️⃣ 避坑 · 常见错误答法
- ❌ “vLLM 就是比 TensorRT-LLM 好，因为社区活跃。” → ✅ “选型要看场景：高并发选 vLLM，低延迟选 TensorRT-LLM。社区活跃只是运维成本的参考，不是性能指标。”
- ❌ “llama.cpp 只能在 CPU 上跑，性能太差。” → ✅ “llama.cpp 的 Q4_K_M 量化在 M2 Ultra 上跑 7B 模型能到 30 token/s，适合边缘设备。但别用它做高并发服务。”
- ❌ “所有框架都支持量化，随便选。” → ✅ “量化支持深度不同：TensorRT-LLM 原生 FP8/INT4，vLLM 依赖外部库，llama.cpp 的 GGUF 量化精度损失大。选型时要看硬件和精度要求。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“长序列推理”切入，对比 vLLM 和 TensorRT-LLM 在 8K+ token 场景下的显存表现，强调 PagedAttention 对 RAG 多轮对话的优化。
- 如果你只做过传统 NLP：用“批处理策略”类比，把 continuous batching 比作动态负载均衡，static batching 比作固定线程池，展示迁移能力。
- 如果你是校招无项目：聚焦“量化对比实验”，用 llama.cpp 的 Q4 量化跑 LLaMA-7B，测量精度和速度，写一篇技术博客，面试时直接展示数据。
- vLLM 论文：Efficient Memory Management for Large Language Model Serving with PagedAttention
- TensorRT-LLM 官方文档：Best Practices for LLM Inference Optimization
- llama.cpp 量化指南：GGUF Quantization Methods and Performance Benchmarks
- 博客：Continuous Batching vs Static Batching – A Practical Comparison on A100
- 论文：FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning