你手上有几张卡、一个要上线的模型，框架选错了后面并发和延迟都难受。vLLM 和 SGLang 经常被放在一起比，但两者的强项并不重叠：一个偏通用稳定，一个在多轮对话和结构化输出上更省算力。这篇不讲空话，先给对照维度，再给一套按你自己业务量出结论的试用流程。
手上的卡就那几张，模型要上线，框架选错了后面并发一压就崩、延迟一抖就查不出原因。vLLM 和 SGLang 经常被拿来比，但两者强项真不重叠：一个偏通用稳定，路子宽；一个在多轮对话和结构化输出上更省算力。先别急着站队，把差异拆到具体层，再拿自己的流量去试，才是靠谱的顺序。
这篇不讲概念复读，先给对照维度，再给一套按你自己业务量出结论的试用流程。凡是涉及具体价格、吞吐数字、跑分名次这类会变的数，一律不回写死值，到站内对应页面核对当时的情况就行。
先分清两者的差异出在哪一层
很多人比框架，比的是别人博客里的峰值数字，那东西换张卡、换个模型就全变了。真正影响你上线体验的差异集中在三个地方：调度与批处理、前缀缓存、结构化输出。先把这三层想明白，后面的试用才有方向。
- 调度与批处理
- vLLM 的连续批处理与分页注意力是通用底座；SGLang 在前后端分离的请求编排上做了更多工作，适合请求形态复杂的服务
- 前缀缓存
- 多轮对话、长系统提示重复度高时，缓存命中率直接决定单位算力能服务多少路请求，这是长会话场景最值钱的一项
- 结构化输出与约束解码
- 需要严格 JSON、正则或语法约束时，看框架是否原生支持；不支持就得自己在外面兜一层，多一跳就多一份延迟和出错面
| 对比维度 | 重点看什么 | 判断不适用的情况 |
|---|---|---|
| 调度模型 | 请求编排方式是否匹配你的调用形态 | 请求全是同构短请求，差异被抹平 |
| 前缀缓存 | 多轮/长提示场景的命中率与复用效果 | 每路请求上下文完全不同，缓存吃不到 |
| 结构化输出 | 约束解码是否原生，外部兜底成本多大 | 输出是自由文本，不涉及格式约束 |
| 部署成本 | 显存占用、冷启动、扩容速度是否可接受 | 已有固定部署流程且一直没出过问题 |
按你的负载画像对号入座
选型不是选最强，是选最合身的。先用一句话把你的负载画像写下来：并发高不高、请求长不长、上下文重不重复、输出有没有格式要求。写不出来就说明业务还没摸清，这种时候先按通用方案起步，别押注。
- 高并发短请求、多租户共享底座：优先看前缀缓存与吞吐表现，先到 /tools/speed-test 量自己的延迟基线再比，别用别人的数
- 长系统提示加多轮会话的 Agent 类服务：重复上下文多，缓存收益明显，这类优化更容易体现出来
- 大批量离线推理、吞吐优先：两者都能跑，重点先确认你的量化格式和权重是否被支持，别卡在加载环节
- 团队只维护一套栈、没有专职调优人力：稳定和文档比峰值数字更值钱，保守选通用方案不丢分
- 流量形态还在变、业务没定型：留一套可切换的部署脚本，比现在就把框架焊死更重要
试用与迁移的判断流程
下面这套流程的目的不是得出「谁更好」，而是让你在自己的机器上得出一组能对比的数。顺序别乱，变量别换，跑完你心里就有底了。
- 固定变量同一模型、同一量化、同一张卡、同一批提示词，对比时只换框架，别顺手把配置也调了，否则结论无效
- 量三个数首 token 延迟、单路输出速度、稳定并发下的总吞吐。记在同一个表格里，换框架复测，用同一批提示词跑两轮取稳定值
- 看显存与冷启动容器化部署时冷启动时间直接影响扩容速度，常被忽略。重启一次服务，掐表记下从起进程到能接请求的耗时
- 查权重兼容到 /models/deploy 按模型和卡算一遍，确认权重格式与量化支持，避免选完框架才发现模型加载不了
- 留回退路径两套服务并行跑一段，用流量切分灰度，出问题能立刻切回，不要一次性替换
上线后容易被忽略的成本项
选型只是开头，真正吃掉人力和预算的是上线后的运维成本。这几项在选型阶段就该放进评估表，等到出问题再补就晚了。
| 成本项 | 怎么评估 | 出问题的信号 |
|---|---|---|
| 显存碎片与长稳 | 做长周期压测，不只跑峰值 | 跑几小时后延迟明显抬高 |
| 监控口径 | 并发数、队列深度、超时率统一采集 | 换框架后数字没法横向比 |
| 扩容边界 | 单卡跑满后是加卡还是拆服务，提前定 | 流量涨一点就整体排队 |
| 硬件适配 | 国产卡与特殊硬件先确认分支适配 | 部署时才发现跑不起来 |
- 监控指标要在切换前后保持一致口径，不然换完框架你连变好还是变坏都说不清
- 扩容方案提前想：单卡跑满后是加卡还是拆服务，两种路线的运维复杂度差很多
- 到 /compute/sizing 按模型估算卡数，给扩容留出余量，别卡着上限跑
- 涉及特殊硬件时先做小规模验证，别指望和通用卡完全一致的体验
常见问题
小团队只跑一两个模型，值得为框架选择折腾吗？
先用你手上已有经验的方案把服务跑起来，把并发和延迟数字量清楚。只有当出现明确的瓶颈——比如多轮对话重复上下文太贵、结构化输出经常解析失败——再考虑换，否则换来换去的时间成本比那点性能收益高。
两个框架能不能同时部署、按请求分发？
技术上可行，但要评估运维复杂度：两套依赖、两套监控、两套故障处理流程。如果只是为了某类请求快一点，先确认收益是否覆盖得住人力，多数小团队更适合单栈加参数调优。
怎么判断现在的框架到底够不够用？
在 /tools/speed-test 上先把延迟基线量出来，再对照你的业务超时阈值和并发目标。如果稳定并发下超时率在可接受范围、显存还有余量，说明当前方案没到瓶颈；反之再谈换框架。
