核心要点
vLLM：PagedAttention + 连续批处理（continuous batching），显存利用高、并发吞吐强，是 GPU 上生产化在线服务的默认首选
TGI（HuggingFace Text Generation Inference）：生产级、功能全（量化/张量并行/流式/指标），与 HF 模型与生态无缝衔接，工程化交付省心
llama.cpp：C/C++ 实现，主打 CPU、边缘设备与 Apple Silicon（Metal），配 GGUF 量化，适合本地、离线与资源受限场景
SGLang：以 RadixAttention 复用前缀缓存，擅长复杂控制流、结构化/约束输出与 Agent 多轮调用，性能同样优秀
标准回答
这四个框架定位不同，选型本质是「硬件 + 负载形态 + 生态」的匹配，而非比谁绝对更快。
vLLM：核心创新是 PagedAttention——把 KV Cache 像操作系统分页一样按块管理，几乎消除显存碎片，从而能容纳更大 batch；配合连续批处理让新请求随到随进、已完成请求即时退出，GPU 利用率和并发吞吐显著高于静态批处理。它是当下 GPU 在线高并发服务的事实标准，兼容 OpenAI 风格 API，社区与模型支持广。
TGI：HuggingFace 出品的生产级推理服务器，张量并行、连续批处理、量化、流式输出、Prometheus 指标、健康检查等一应俱全，且与 HF Hub / Transformers 生态衔接最顺。当团队已深度使用 HF 生态、追求开箱即用的工程完备度时是稳妥之选。
llama.cpp：纯 C/C++、依赖极少，支持 CPU、边缘设备和 Mac（Metal），以 GGUF 量化把大模型塞进有限内存。它不是为高并发 GPU 集群设计的，而是本地、离线、嵌入式、个人设备场景的利器（Ollama 等也基于它）。
SGLang：用 RadixAttention 以基数树自动复用共享前缀的 KV Cache，对复杂控制流、结构化/约束解码（JSON、正则）、多轮 Agent、few-shot 模板这类有大量重复前缀的负载收益巨大，吞吐与延迟表现优异。
选型维度：① 吞吐/延迟要求；② 硬件是 GPU 还是 CPU/边缘/Mac；③ 并发规模；④ 是否需要结构化输出与复杂控制流（偏 SGLang）；⑤ 现有生态（重 HF 选 TGI）。一句话：GPU 高并发在线服务选 vLLM，重 HF 工程化选 TGI，CPU/边缘/本地选 llama.cpp，结构化输出与 Agent 复杂控制流选 SGLang。
常见误区
⚠️ 常见踩坑
把「谁吞吐最高」当唯一标准，忽略硬件与负载形态——在 Mac/CPU 上硬上 vLLM 不现实，给纯文本简单问答上 SGLang 也用不到它的强项；也别误以为 llama.cpp 只能跑小模型或不能用 GPU（它支持 CUDA/Metal 等后端，只是定位偏本地与边缘）。
追问
追问 1：PagedAttention 到底解决了什么问题，为什么能提吞吐？
传统实现给每个序列预留连续显存存 KV Cache，长度不一造成大量内部碎片和过度预留，可容纳的并发请求受限。PagedAttention 把 KV Cache 切成固定大小的块、用页表非连续存储并按需分配，碎片几乎消失、显存利用率接近满载，于是能塞下更大 batch；再叠加连续批处理，GPU 不再空等，整体吞吐大幅提升。
追问 2：SGLang 的 RadixAttention 和普通 KV Cache 复用有何不同？
普通前缀缓存通常只能命中完全相同的前缀。RadixAttention 用基数（前缀）树组织所有请求的 KV Cache，能自动发现并复用任意请求间共享的前缀片段——比如相同 system prompt、few-shot 示例、Agent 多轮历史，命中率更高。对结构化输出和有大量重复前缀的 Agent 负载，省去重复 prefill，延迟与吞吐都明显改善。
追问 3：如果只在本地 Mac 上给少量用户跑模型，怎么选？
优先 llama.cpp（或基于它的 Ollama）：纯 C/C++、对 Apple Silicon 的 Metal 加速友好，用 GGUF 量化可在有限内存里跑中等规模模型，部署简单、无需 GPU 集群。这种低并发本地场景，vLLM/TGI 的高并发优势用不上，反而带来更重的依赖和运维成本。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习