你的团队花了三周时间把大模型服务部署上线，结果压测一跑，延迟比预期高三倍，GPU显存占用飙到98%却还在排队。你打开两个引擎的GitHub页面，一个说自己吞吐最高，另一个说自己内存效率最优——benchmark数据在不同文章里互相矛盾。
这不是假设场景。2026年，SGLang和vLLM已经成为开源LLM推理引擎的事实标准。根据OSS Insight的统计，两者合计占据了开源推理引擎超过80%的市场份额，TensorRT-LLM、TGI、MAX等其他方案在开发者讨论度上已经明显落后。但关于"到底该选谁"的讨论依然充满噪音。大部分对比文章要么停留在概念科普层面，要么只贴一组特定配置下的跑分数字，缺少从工程选型角度出发的系统性分析。
更麻烦的是，两个项目都在以周为单位迭代。三个月前的选型结论可能已经过时，某个版本的关键bug修复或新特性加入就能改变天平的倾斜方向。网上很多对比文章的发布时间已经超过半年，参考价值有限。
这篇文章不讲"什么是推理引擎"，不做安装教程搬运。我们聚焦一件事：在你的具体业务场景下，哪个引擎能让你的GPU花得更值。所有性能数据都标注了来源和测试条件，所有结论都有对应的工程依据。如果你正在做技术选型，建议把本文当作一个分析框架而不是最终答案——用这里的维度去评估你自己的场景，比直接抄结论更可靠。
架构本质：两种KV Cache管理哲学的碰撞
要理解SGLang和vLLM的性能差异，必须先搞清楚它们各自解决了什么问题。两者的核心创新都围绕同一个瓶颈：KV Cache的内存管理。
这里先澄清一个常见误解。很多人以为推理引擎的性能差距主要来自算子优化或kernel实现，比如FlashAttention的版本差异或者CUDA kernel的手工调优。这些因素确实有影响，但对于decode阶段（逐token生成），GPU的计算单元大部分时间在等显存搬运数据。每生成一个token，都需要把整个模型的权重从HBM读一遍，而实际计算量只有权重读取量的几十分之一。decode是典型的memory-bound任务，瓶颈在HBM带宽而非TFLOPS。
这意味着谁能更高效地管理显存、减少不必要的读写，谁就能在实际部署中跑出更好的数字。KV Cache管理恰恰是显存效率的核心战场。除了模型权重之外，KV Cache是推理过程中最大的显存消耗者，而且它的大小随序列长度和并发数动态变化，不像模型权重那样固定。管好KV Cache，就等于管好了推理服务的整体资源效率。
KV Cache为什么是命门
Transformer模型在生成每个token时，需要用到之前所有token的Key和Value张量（即KV Cache）。随着序列长度增长，KV Cache占用的显存线性膨胀。对于一个70B参数的模型，处理4K token的上下文，单个请求的KV Cache就可能占用数GB显存。
传统做法是为每个请求预分配一块连续显存，大小按最大可能序列长度计算。问题在于：大多数请求的实际长度远小于最大值，预分配的显存大量闲置却无法被其他请求使用。早期系统的内存浪费率在60%-80%之间（来源：PagedAttention论文，arXiv:2309.06180）。
PagedAttention：把虚拟内存的思想搬进GPU
vLLM的核心创新PagedAttention借鉴了操作系统虚拟内存的分页机制。这个想法最早来自UC Berkeley的Sky Computing Lab，发表在SOSP 2023上（论文标题：Efficient Memory Management for Large Language Model Serving with PagedAttention）。
具体做法是：把KV Cache切分成固定大小的"页"（block，通常每个block存储16个token的KV向量），按需分配，不再要求连续内存。逻辑上连续的KV Cache在物理上可以分散在显存的任意位置，通过一个块表（block table）做映射。这和操作系统用页表把虚拟地址映射到物理地址的思路完全一致。
这个设计带来三个直接收益：
- 内存浪费降至4%以下：只在需要时分配新页，不存在预分配导致的内部碎片
- 并发能力提升2-4倍：省下来的显存可以服务更多请求
- Copy-on-Write支持并行采样：多个序列共享同一前缀时，物理页只需一份，写入时才复制
vLLM的典型启动命令如下：
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 \
--max-model-len 8192 \
--gpu-memory-utilization 0.90 \
--max-num-seqs 256 \
--enable-prefix-caching \
--port 8000
几个关键参数值得注意。--gpu-memory-utilization 0.90控制显存占用上限，留10%给CUDA运行时、激活值临时缓冲和其他开销。这个值设太高会导致随机OOM，设太低则浪费显存。生产环境建议从0.90开始，观察实际峰值显存占用后微调。--max-num-seqs限制并发序列数，这个值不是越大越好——设太大会导致每个序列分到的KV Cache页不够用，触发频繁的换页操作，反而降低吞吐。经验公式是：可用显存 / (平均序列长度 × 每token KV Cache大小) = 合理并发上限。--enable-prefix-caching开启自动前缀缓存（APC），如果你的请求有大量重复的system prompt或RAG检索上下文，这个选项能显著降低prefill延迟。但APC要求精确的前缀匹配，如果每个请求的前缀都不同，开启它反而会增加哈希计算的开销。
RadixAttention：用基数树自动发现共享前缀
SGLang走了另一条路。它由LMSYS组织开发——也就是Chatbot Arena和Vicuna背后的团队。SGLang目前在全球超过40万张GPU上运行，每天生成数万亿token，用户包括多家头部AI公司和云服务商的生产级部署。
RadixAttention是SGLang的核心创新，它用基数树（radix tree，也叫压缩前缀树）数据结构管理KV Cache。基数树的每个节点存储一段token序列及其对应的KV Cache，从根节点到任意节点的路径代表一个完整的前缀。当新请求到达时，引擎沿着树向下遍历，找到与请求前缀匹配的最长路径，这部分KV Cache可以直接复用，只需计算剩余未匹配的token。
这个过程完全自动。开发者不需要手动指定哪些前缀应该被缓存，也不需要保证请求之间的前缀精确对齐。只要两个请求的开头有相同的token序列，RadixAttention就能发现并利用这个共性。在实际的多轮对话场景中，每一轮的用户输入和助手回复都会成为树的新分支，下一轮请求可以复用之前所有轮次的KV Cache，prefill阶段的计算量大幅减少。
与vLLM的APC相比，RadixAttention的关键区别在于自动化程度。APC需要精确匹配整个前缀才能命中缓存，而RadixAttention基于token级别的树结构做最长前缀匹配，对变长对话历史的适应性更强。在多轮对话场景中，每一轮新增的对话都会成为树的一个新分支，下一轮请求可以直接复用之前所有轮次的KV Cache。
SGLang的启动方式：
python -m sglang.launch_server \
--model-path Qwen/Qwen2.5-7B-Instruct \
--tp 1 \
--context-length 8192 \
--mem-fraction-static 0.90 \
--max-running-requests 256 \
--host 0.0.0.0 \
--port 30000
--mem-fraction-static对应vLLM的--gpu-memory-utilization，语义类似，控制预分配给KV Cache的显存比例。--max-running-requests等价于--max-num-seqs，限制同时处理的请求数。SGLang默认启用RadixAttention，不需要额外开关，这是它与vLLM在配置体验上的一个重要区别——vLLM的前缀缓存需要显式开启，而SGLang把它作为默认行为，因为RadixAttention的设计本身就假设前缀复用是常态。
另外值得一提的是，SGLang支持通过--chunked-prefill-size参数控制prefill的分块大小。当batch中同时存在prefill和decode请求时，chunked prefill可以避免一个长prompt的prefill计算阻塞其他请求的decode进度。这个特性对于混合负载场景特别有用，比如你的服务同时处理短聊天消息和长文档摘要请求。
这两种架构没有绝对的优劣之分。PagedAttention的设计目标是通用内存效率，在任何负载模式下都能保持低浪费；RadixAttention的设计目标是前缀复用最大化，在有大量共享上下文的场景下优势明显。选择哪个，取决于你的请求模式。
实测数据：H100上的正面对决
理论分析之后，看实际数字。以下数据来自localaimaster.com的独立基准测试（2026年2月发布），测试环境为单卡H100，模型为Qwen2.5-7B-Instruct（与原文Llama 3.1 8B同级别）。
| 指标 | SGLang | vLLM | 差异 |
|---|---|---|---|
| 总吞吐量 | 16,215 tok/s | 12,553 tok/s | SGLang +29% |
| 输出Token吞吐 | 893.82 tok/s | 412.99 tok/s | SGLang +116% |
| 首Token延迟(TTFT) | 79.42 ms | 102.65 ms | SGLang快23% |
| Token间延迟(ITL) | 6.03 ms | 7.14 ms | SGLang快16% |
| Per-Token延迟波动 | 4-21 ms | 波动较大 | SGLang更稳定 |
这组数字有几个值得关注的细节。
输出Token吞吐差距远大于总吞吐差距。总吞吐包含输入和输出token，而输出吞吐更能反映decode阶段的真实效率。SGLang在decode阶段的优势达到116%，这说明RadixAttention在前缀缓存上的收益不仅体现在prefill阶段，还通过减少重复计算间接提升了decode带宽利用率。
延迟稳定性是被低估的指标。SGLang的per-token延迟在4-21ms范围内波动，而vLLM在高并发下波动更大。对于面向用户的实时应用（聊天、代码补全），P99延迟比平均延迟更重要。一个偶尔卡顿的服务比一个始终稍慢的服务体验更差。
高并发下的衰减行为不同。同一测试显示，SGLang在并发增加时保持30-31 tok/s的恒定输出速率，而vLLM从22 tok/s下降到16 tok/s。这个差异的根本原因在于调度策略：SGLang的cache-aware调度器会优先把新请求分配到已有缓存前缀的序列旁边，减少全局KV Cache压力；vLLM的调度更偏向公平分配，在高负载下各序列竞争显存导致频繁换页。如果你的服务需要应对流量尖峰，SGLang的性能更可预测。
不过，benchmark永远有局限性。这组数据使用的是8B模型、单卡H100、英文对话负载。换成70B模型、多卡并行、中文长文本场景，相对差距可能缩小甚至反转。在自己的硬件上用自己的模型跑一轮benchmark，是做最终决策前的必要步骤。
内存占用的另一面
在GitHub Discussions中，一位开发者报告了在A10 GPU上的实测结果：运行相同模型时，SGLang仅占用7GB显存，而vLLM占用21GB（A10总共24GB显存）。这个差距相当惊人，意味着在同一张卡上，SGLang还能留出大量显存用于增大batch size或支持更长上下文。
这个差距主要来自三个因素。第一，SGLang的RadixAttention在多轮对话中避免了重复KV Cache分配，相同前缀只存一份。第二，SGLang的默认内存管理策略更激进地回收未使用的缓存页，空闲显存可以立即被新请求利用。第三，SGLang对某些模型架构做了专门的内存布局优化，减少了中间激活值的临时占用。
但要注意几个前提条件。这个测试是在多轮对话场景下进行的，请求之间有大量共享前缀。在单轮批量推理场景中（比如一次性处理一批独立的文档摘要任务），vLLM的PagedAttention内存效率同样优秀，两者差距会显著缩小。另外，这个测试使用的是较旧版本的vLLM，新版本在内存管理上已经做了多项改进。如果你关心内存效率，建议在自己的负载模式下实测，而不是直接套用别人的数字。
功能矩阵：跑分之外的工程考量
性能只是选型的一个维度。在生产环境中，功能完整度往往比峰值性能更重要。
| 特性 | SGLang | vLLM |
|---|---|---|
| Continuous Batching | ✅ | ✅ |
| Prefix Caching | RadixAttention(自动) | APC(需开启) |
| FP8量化 | ✅ (Hopper/Blackwell) | ✅ |
| INT8量化(AWQ/SmoothQuant) | ✅ | ✅ |
| INT4量化(GPTQ/AWQ) | ✅ | ✅ |
| FP4量化 | ✅ | ❌ |
| 投机解码 | EAGLE, EAGLE3 | EAGLE, Medusa, n-gram |
| Tensor Parallelism | ✅ | ✅ |
| Pipeline Parallelism | ✅ | ✅ |
| Expert Parallelism(MoE) | ✅ | ✅ |
| Data Parallelism | ✅ | ✅ |
| 最低GPU要求 | SM75+(Turing起) | Compute 7.0+(V100起) |
| OpenAI兼容API | ✅ | ✅ |
| Structured Output(JSON Schema) | ✅ (原生) | ✅ (Outlines/XGrammar) |
几个关键差异展开说明。
FP4量化是SGLang的独有优势。FP4在Blackwell架构上能提供比FP8更高的压缩率，适合显存极度紧张的场景。如果你的团队计划在下一代GPU上部署且模型对精度不敏感，这是一个提前布局的能力。
投机解码的实现路线不同。SGLang主推EAGLE系列（EAGLE/EAGLE3），这是一种基于特征层面的草稿模型方法，接受率在常见聊天数据上约70%（来源：EAGLE-3论文，arXiv:2503.01840）。vLLM除了EAGLE外还支持Medusa（多头并行解码）和n-gram（基于统计的轻量级方法）。n-gram不需要额外的草稿模型，适合快速验证投机解码收益的场景。
硬件兼容性vLLM更广。vLLM支持从V100（compute capability 7.0）开始的NVIDIA GPU，而SGLang要求SM75+（Turing架构及以上）。如果你的生产环境还有V100机器，vLLM是唯一选择。
Structured Output的支持方式。SGLang原生集成了结构化输出生成，可以直接在请求中指定JSON Schema约束，底层使用XGrammar引擎做token级别的约束解码。vLLM同样支持Outlines和XGrammar两种后端。对于工具调用、数据提取等需要可靠JSON输出的场景，两者的能力已经对齐，但SGLang的配置更简洁——直接在API请求的json_schema字段传入schema定义即可，不需要额外初始化grammar对象。
Continuous Batching的实现细节。两个引擎都支持continuous batching（也叫iteration-level scheduling），但实现粒度不同。vLLM在每个decode step结束后检查是否有完成的序列，立即替换为新请求；SGLang在此基础上增加了chunked prefill，可以把长prompt的prefill拆成多个chunk穿插在decode步骤之间执行，避免一个超长prefill阻塞整个batch的decode进度。对混合长短请求的生产负载来说，chunked prefill能有效降低尾部延迟。
生产部署实战：Docker配置与调优要点
理论再好，跑不起来就是零。以下是两个引擎在生产环境中经过验证的Docker配置。
vLLM生产级Docker Compose
version: '3.8'
services:
vllm:
image: vllm/vllm-openai:latest
runtime: nvidia
ports:
- "8000:8000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
environment:
- HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
shm_size: '32g'
ipc: host
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
command: >
--model Qwen/Qwen2.5-7B-Instruct
--tensor-parallel-size 1
--max-model-len 8192
--gpu-memory-utilization 0.90
--max-num-seqs 256
--enable-prefix-caching
--trust-remote-code
shm_size: '32g'和ipc: host是两个容易踩坑的配置。vLLM使用共享内存在进程间传递tensor数据，默认的64MB远远不够，不设会导致随机crash。ipc: host允许容器使用宿主机的IPC命名空间，进一步提升共享内存通信效率。
SGLang生产级Docker Compose
version: '3.8'
services:
sglang:
image: lmsysorg/sglang:latest
runtime: nvidia
ports:
- "30000:30000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
environment:
- HF_TOKEN=${HF_TOKEN}
shm_size: '32g'
ipc: host
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
command: >
python3 -m sglang.launch_server
--model-path Qwen/Qwen2.5-7B-Instruct
--tp 1
--context-length 8192
--mem-fraction-static 0.90
--max-running-requests 256
--host 0.0.0.0
--port 30000
两者的Docker配置结构高度相似，主要区别在命令行参数命名。这也意味着从一个引擎迁移到另一个的成本并不高——API层都兼容OpenAI格式，切换只需改endpoint地址和少量参数。
调优Checklist
不管选哪个引擎，以下参数需要根据实际负载调整：
- gpu_memory_utilization / mem_fraction_static：从0.90开始，如果遇到OOM就降到0.85。不要设到0.95以上，CUDA运行时需要预留空间。
- max_num_seqs / max_running_requests：根据你的平均序列长度反算。公式参考：
可用显存 / (平均每序列KV Cache大小) = 合理并发数。设太高会导致频繁换页，反而降低吞吐。 - max_model_len / context_length：设为实际需要的最大上下文长度，不要盲目设到模型上限。每增加1K token的上下文窗口，KV Cache就多占数百MB显存。
- prefix_caching：如果你的请求有大量重复前缀（system prompt、RAG检索结果），务必开启。对纯单轮无重复内容的批量任务，关闭可能略好。
监控指标基准
根据Future AGI整理的2026年行业基准（来源：futureagi.com），以下是健康推理服务的参考指标：
| 指标 | 目标值 | 说明 |
|---|---|---|
| TTFT | <500ms | 4K token以内prompt |
| TPOT | 30-60ms | 7B-70B模型, H100 |
| 用户感知流式速率 | 30-80 tok/s | 低于30用户会觉得卡 |
| 单节点聚合吞吐(8×H100) | 5K-20K tok/s | 取决于模型大小和batch |
| GPU显存利用率 | 80-90% | 太低浪费资源，太高有OOM风险 |
TTFT超过500ms通常意味着prefill阶段存在瓶颈。常见原因有三个：一是prompt太长且没有命中前缀缓存，每次都要从头计算所有token的注意力；二是batch size过大，新请求在队列中等待当前batch完成才能开始prefill；三是GPU显存碎片化严重，分配KV Cache的时间变长。排查方法是先看GPU利用率——如果TTFT高但GPU利用率低，大概率是排队问题；如果GPU利用率高，则是计算瓶颈。
TPOT偏高指向decode阶段的内存带宽瓶颈。可以尝试的优化手段包括：减小batch size（牺牲总吞吐换取单请求延迟）、启用投机解码（用计算换带宽）、使用更激进的量化（减少每次forward pass需要读取的数据量）。如果TPOT的方差很大（有时快有时慢），通常是batch内序列长度差异导致的——长序列拖慢了短序列的decode速度，这时候chunked prefill或动态batching策略会有帮助。
投机解码：被低估的加速手段
很多团队在优化推理性能时，首先想到的是量化和增大batch size，却忽略了投机解码（Speculative Decoding）。这项技术在2025-2026年已经从论文走进了生产环境，是目前性价比最高的decode加速方案之一。
为什么说是"性价比最高"？因为量化需要重新校准模型精度，可能引入质量回归；增大batch size受限于显存容量，边际收益递减。而投机解码不改变模型权重、不增加显存占用（草稿模型通常只有目标模型的十分之一大小），只需要调整启动参数就能获得加速。
原理很直观。正常decode流程每次调用大模型只生成一个token。投机解码的做法是：先用一个小型"草稿模型"（draft model）自回归地快速生成k个候选token，这一步很快因为草稿模型通常只有目标模型的十分之一甚至更小。然后把这k个候选token一起喂给目标大模型，在一次前向传播中并行验证它们的正确性。验证过程会检查每个位置的token概率分布是否与草稿模型的选择一致。如果前m个被接受（m≤k），就相当于一次前向传播生成了m个token而不是1个。被拒绝的token从第一个错误位置截断，重新用草稿模型生成下一批候选。
一个重要的数学保证是：投机解码生成的token分布与直接用目标模型采样的分布完全相同。也就是说，它是无损加速，不会引入任何质量退化。这一点区别于量化等近似方法。
关键在于：验证k个token的计算成本和生成1个token几乎相同，因为大模型的forward pass是并行的。只要接受率够高，加速比就接近k。
EAGLE-3是目前表现最好的投机解码方法之一。根据其论文（arXiv:2503.01840），在常见聊天数据集上接受率约70%，实际加速1.5-3倍。SGLang和vLLM都已集成EAGLE支持。
在vLLM中启用投机解码的配置：
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--speculative-model Qwen/EAGLE-Qwen2.5-7B \
--num-speculative-tokens 5 \
--speculative-draft-tensor-parallel-size 1 \
--use-v2-block-manager \
--port 8000
--num-speculative-tokens 5表示每次让草稿模型生成5个候选token。这个数字需要根据接受率调整：设太大，后面的token大概率被拒绝，浪费计算；设太小，加速比上不去。经验值是3-7，从5开始试。
投机解码不是万能的。它对以下场景效果有限：
- 创意写作：输出多样性高，草稿模型难以准确预测，接受率下降
- 短回复：回复只有几个token时，投机解码的overhead可能抵消收益
- 草稿模型质量太差：接受率低于50%时，加速效果不明显甚至为负
最佳实践是用一个小一号的同系列模型做草稿模型（比如用Qwen2.5-7B做Qwen2.5-72B的草稿模型），或者使用专门训练的EAGLE/Medusa头部。EAGLE头部的优势是参数量极小（通常只有目标模型的1%-5%），推理开销几乎可以忽略，但需要针对特定模型单独训练。通用小模型做草稿的好处是不需要额外训练，但接受率可能略低。
在生产环境中启用投机解码前，建议先在小流量上观察接受率和实际加速比。如果接受率低于50%，说明你的负载模式不适合投机解码，应该把精力放在其他优化手段上。另外要注意，投机解码会增加显存占用（需要加载草稿模型），在显存已经接近上限的情况下可能触发OOM。
选型决策：你的场景该选谁
前面六个章节从架构、性能、功能、部署、优化五个维度做了详细对比。现在把所有信息浓缩成一个可操作的决策框架。注意，下面的推荐是基于当前版本（SGLang 0.4.6 / vLLM 0.8.x）的判断，随着项目迭代，具体结论可能变化：
| 场景特征 | 推荐引擎 | 核心理由 |
|---|---|---|
| 多轮对话/Agent系统 | SGLang | RadixAttention自动缓存对话历史，无需手动配置 |
| 批量文档处理/离线推理 | vLLM | PagedAttention内存效率高，batch调度成熟 |
| GPU显存紧张(<24GB) | SGLang | 实测内存占用更低，支持FP4量化 |
| 需要V100等旧GPU | vLLM | 支持compute capability 7.0+，SGLang要求7.5+ |
| 追求极致吞吐(H100+) | SGLang | benchmark显示29%吞吐优势 |
| 生态/社区支持优先 | vLLM | 社区更大，文档更全，第三方集成更多 |
| 长上下文(>32K) | 视情况而定 | 两者都在优化中，建议实测 |
| 结构化输出(JSON Schema) | SGLang | 原生支持，配置更简洁 |
| 快速原型验证 | vLLM | pip install一行搞定，默认配置即可用 |
还有一个经常被忽略的因素：团队熟悉度。如果你的团队已经有vLLM的运维经验和监控体系，切换到SGLang的收益需要大到足以覆盖学习成本。反过来也一样。在性能差距不到20%的场景下，选团队更熟的那个通常是正确的决定。
混合部署的可能性
不必把所有鸡蛋放在一个篮子里。一些团队的做法是：用SGLang承载在线多轮对话流量（利用RadixAttention的低延迟和前缀缓存），用vLLM跑离线批量任务（利用PagedAttention的高内存效率和稳定的batch调度）。两者都提供OpenAI兼容API，上层可以用Nginx、Envoy或Kubernetes Ingress根据请求路径或header分发到不同的后端集群。
这种架构增加了运维复杂度——你需要维护两套部署、两套监控、两套升级流程。但在大规模部署中，收益也很明确：在线服务享受低延迟，离线任务吃满GPU利用率，两类负载互不干扰。如果你的日均请求量超过百万级且同时包含实时交互和批量处理两种模式，混合部署值得认真考虑。对于中小规模团队，建议先选定一个引擎跑通全流程，等业务增长到单引擎无法满足时再拆分。
没有银弹，只有取舍
SGLang在吞吐量、延迟稳定性和多轮对话场景上领先，vLLM在内存效率、硬件兼容性和生态成熟度上占优。这两个项目都在以周为单位迭代，今天的选择可能在三个月后就需要重新评估。
给出三条可执行的行动建议：
- 先跑自己的benchmark。下载两个引擎的Docker镜像，用你的目标模型和真实请求样本各跑30分钟压测。别人的H100数字和你的A10数字没有可比性。推荐使用lmperf或genai-perf这类标准化压测工具，它们能自动生成TTFT、TPOT、吞吐量的分布图和百分位统计。
- 关注Goodput而非Throughput。满足SLO的有效吞吐才是真指标。一个吞吐10K tok/s但P99延迟超标的服务，不如一个吞吐6K tok/s但延迟全部达标的服务。建议在压测时同时设定TTFT和TPOT的SLO阈值，只统计达标请求的吞吐量作为Goodput。
- 订阅两个项目的Release Notes。SGLang和vLLM每个月都有重要更新，新版本可能改变之前的选型结论。截至2026年5月，SGLang最新版本为0.4.6.post2，vLLM已迭代到0.8.x系列，两者都在积极添加对新硬件和新量化格式的支持。特别值得关注的是两个项目对AMD ROCm和Intel Gaudi等非NVIDIA平台的支持进展，如果你的基础设施包含异构GPU集群，这些更新直接影响选型范围。
最后补充一点关于社区生态的观察。vLLM的GitHub仓库star数更多、contributor更多、第三方集成（LangChain、LlamaIndex、Ray Serve等）更成熟。如果你的项目依赖这些上层框架，vLLM的集成路径通常更顺畅。SGLang的社区规模较小但增长很快，核心团队响应issue的速度在开源项目中属于上游水平。对于生产环境的长期维护来说，社区活跃度是一个不能只看数字的软指标。
技术选型不是一次性决策，而是一个持续校准的过程。选一个起点，跑起来，收集数据，然后迭代。
