真实面经题目 · 原创解析
这题考 LLM 推理引擎的系统理解，而不是问两个项目谁更快。好答案要说明 vLLM 的核心公共概念是提升 serving 吞吐和显存利用率，典型抓手包括 PagedAttention、KV cache 分页管理、continuous batching 和 prefix caching；SGLang 更强调面向复杂 LLM 应用的编程/运行时，围绕结构化生成、多轮/多调用流程、前缀复用、调度和缓存优化降低复杂请求的执行成本。比较时要从 KV 管理、前缀复用、请求调度、结构化输出、内存压力和 workload fit 讲边界，避免虚构版本特性。
我会先把二者放在同一张推理链路图里说：LLM serving 的核心瓶颈是 GPU 计算、KV cache 显存、动态请求调度、长上下文复用和复杂应用的控制流。vLLM 更像高吞吐模型 serving 引擎，重点解决 GPU batch 利用率和 KV cache 内存碎片问题。它的代表性思想是 PagedAttention：把每个请求的 KV cache 拆成 block/page 管理，逻辑序列连续但物理显存可以非连续，从而减少为最大长度预留带来的浪费，支持更多并发请求，并配合 continuous batching 在 decode 过程中动态加入和移除请求。prefix caching 则让相同系统提示词、few-shot、长文档前缀不必重复计算。SGLang 更偏面向 LLM 应用的语言和运行时：用户可以表达多轮对话、分支、并行采样、工具/函数式流程、约束或结构化生成，运行时再做前缀复用、调度和缓存优化。它解决的不只是单次 completion 的吞吐，也包括复杂 prompt 程序里重复前缀、结构化输出和多阶段调用的执行效率。比较时可以按四点：PagedAttention/KV 分页上，vLLM 是最典型的 serving 侧显存管理方案；前缀复用上，两者都重视 cache 命中，但 SGLang 的程序化表达让复杂流程里的共享前缀更显式；调度上，vLLM 强调 continuous batching 和高吞吐 serving，SGLang 强调面向复杂请求图的运行时调度；工作负载上，普通 OpenAI-compatible completion/chat、高并发短请求或混合长短请求常优先看 vLLM，复杂多步骤 LLM workflow、结构化生成、分支采样和前缀共享明显的应用更适合讨论 SGLang。最终选择要用真实 workload 的 TTFT、tokens/s、p95/p99、KV 命中率、显存峰值、OOM 率和开发复杂度评估。
LLM 推理服务既要让 GPU 忙起来，又要管理越来越大的 KV cache，还要处理请求长度不同、到达时间不同、前缀重复和应用控制流复杂的问题。vLLM 和 SGLang 都在提升推理效率，但侧重点不同：一个更偏 serving 吞吐和内存管理，一个更偏复杂 LLM 程序的运行时。
vLLM 的稳定公共概念包括 PagedAttention、KV cache block/page 管理、continuous batching 和 prefix caching。它的目标是减少 KV cache 预留和碎片造成的显存浪费，让更多请求同时留在 GPU 上，并在 decode 阶段持续调度新请求，提升吞吐和显存利用率。
传统实现容易为每个请求按最大长度预留连续 KV cache，长短请求混合时浪费显存。PagedAttention 把 KV cache 拆成固定大小 block，逻辑 token 序列通过 block table 映射到物理显存块。这样可以按需分配、复用和回收 KV，降低碎片，支持更高并发。
SGLang 的价值不只是跑一次文本生成，而是让复杂 LLM 应用可以表达多轮调用、分支、并行采样、结构化输出和约束生成。运行时基于这些结构做前缀复用、缓存、调度和批处理优化，适合有重复 prompt 模板、检索上下文、多阶段步骤或结构化生成的场景。
prefix caching 的目标是相同前缀只 prefill 一次，后续请求复用已有 KV。vLLM 中它服务于高并发 chat/completion 的公共前缀复用；SGLang 的程序化表达让复杂流程中的共享系统提示词、few-shot、检索上下文和分支前缀更容易被运行时识别和复用。
continuous batching 的关键是请求不必等一个固定 batch 全部结束，decode 时可以动态加入新请求、移除完成请求，提高 GPU 利用率。vLLM 的回答重点通常是 serving 调度和 token 级 batch；SGLang 还要考虑程序步骤、并行分支、约束解码和缓存命中对调度的影响。
如果需求是标准 chat/completion API、高并发 serving、显存紧张和混合长度请求，vLLM 是很自然的候选。如果需求是复杂 prompt program、结构化输出、多阶段调用、分支采样或大量共享前缀，SGLang 的表达和运行时优化更值得评估。实际选型还要看模型支持、生态接口、部署复杂度和团队熟悉度。
因为 LLM decode 阶段每个请求都要保留 KV cache。若按最大长度连续预留，短请求和提前结束的请求会浪费显存，导致并发数下降。PagedAttention 将 KV 拆成 block/page 按需分配，逻辑连续、物理可离散，减少碎片和预留浪费，让同一 GPU 能容纳更多活跃请求。
主要优化重复前缀的 prefill 成本。系统 prompt、few-shot、长文档或 RAG 模板相同时，复用前缀 KV 可以避免重复跑前面那段 token。decode 仍要为新生成 token 逐步计算，但前缀越长、命中率越高，TTFT 和吞吐收益越明显。
普通 batching 往往把一批请求绑定在一起，受最长请求拖累。continuous batching 在每个 decode step 或调度周期动态维护活跃请求集合，完成的移除，新来的加入，从而提高 GPU 利用率。代价是调度、KV 管理和请求隔离更复杂。
当应用不是一次简单 chat completion，而是有多轮模板、分支采样、并行候选、结构化输出、工具步骤或大量共享前缀时，SGLang 的程序化表达和运行时优化更容易发挥价值。它能让前缀复用和调度从应用结构中获得更多信息。
用真实请求分布测试：prompt 长度、输出长度、并发、前缀重复率、结构化输出比例、模型和 dtype 都要一致。指标看 TTFT、TPOT、tokens/s、p95/p99、显存峰值、OOM、KV cache 命中率、失败率和开发接入成本，而不是只跑单条样例。
