sglang vs vllm vs unsloth

团队要上线一个接口服务，或者要拿自己的数据微调一版模型，多半会在 SGLang、vLLM、Unsloth 这三个名字里挑。它们经常被放在一起搜，但其实不干同一件事：有的跑推理，有的管训练。这篇按「你要做什么任务」来拆，给判断标准和上手验证步骤，选错了返工代价不小。

团队要上线一个接口服务，或者要拿自己的数据微调一版模型，多半会在 SGLang、vLLM、Unsloth 这三个名字里挑。它们经常被放在一起搜，但其实不干同一件事：有的跑推理，有的管训练。这篇按「你要做什么任务」来拆，给判断标准和上手验证步骤，选错了返工代价不小。

先把一句话记住：前两个解决「怎么把训好的模型服务出去」，第三个解决「怎么在有限显存里把微调跑完」。这条线不清楚，后面比较速度、比显存、比生态都没有意义。

先分清：一个是推理服务，一个是训练工具

• SGLang 和 vLLM 的重点在吞吐、并发、KV 缓存和批处理调度，衡量的是服务能力。
• Unsloth 的重点在显存占用和训练速度，衡量的是单卡能不能跑得动。
• 判断口诀：只有权重、要对外提供服务，看前两个；还有数据、要改模型行为，看后一个。
• 两者不冲突，常见做法是先微调、再把产物导进推理框架上线。

推理侧怎么挑：SGLang 还是 vLLM

这一节只管你手上只有权重的情况。先看负载形状：大量重复前缀的对话、多轮 Agent、带结构化约束的输出，值得重点测 SGLang；标准化的批量问答和高并发补全，vLLM 的生态和文档成熟度通常更省心。

1. 列出真实请求样本从线上日志里摘一条最有代表性的提示词，连同它的长度分布一起记下来，不要用玩具例子替代。
2. 确认接口能不能直接替换很多网关、编排平台、前端按 OpenAI 兼容协议对接，先确认目标框架的兼容接口能不能无缝顶上，不行就要预留一层适配的工作量。
3. 先查硬件和量化支持你的卡型、量化格式在这两个框架上的支持程度不一样，国产卡和较新的卡尤其要提前查，别等上线才发现跑不起来。
4. 小模型先压一轮用一个较小的模型把服务起来，测延迟和吞吐，再换成真正要用的模型复测，两轮都过再定型。

微调侧怎么挑：什么时候该上 Unsloth

微调的判断标准是显存和数据类型。单卡、数据量在几千到几万条、做的是 LoRA 一类参数高效微调，这类组合下 Unsloth 的显存优势才体现得出来。任务和硬件对不上，工具再好也帮不上忙。

• 适合上的：单卡、中小数据集、参数高效微调、想快速迭代几个版本试试效果。
• 不适合上的：全参数微调、要打通多机多卡、或者流程里还要接更多训练特性，这时通用训练框架的覆盖面更全。
• 微调本身不是必选项：补知识和控格式，检索增强加提示词的成本和迭代速度往往更好。
• 只有要稳定改变输出风格或固定行为模式时，才值得动权重，否则成本容易失控。
• 数据量很少、任务本身很通用时，微调收益大概率撑不起这套流程的维护成本。

决定上微调之后，先用几百条样本跑一个短周期，记录显存峰值和单步耗时。如果显存已经贴着上限，后面加数据、加长度都很难办，这时候要么换更小的模型，要么回到参数高效的路子上。具体显存和费用口径，到 看当时的数字。

一条可执行的组合路线

1. 第一步：先定任务是「服务已有模型」还是「改变模型行为」，这一步决定你看哪边，别两边同时铺开，容易互相拖进度。
2. 第二步：小规模验证推理侧用一个真实提示词压一轮并发；微调侧用几百条样本跑一个短周期。看显存峰值和耗时能不能接受。
3. 第三步：试接现有链路服务出去的接口格式对不对、微调完的权重能不能顺利合并并加载到推理框架里，这一步最容易卡住，要提前试。
4. 第四步：再算成本租卡、存储、维护各占多少，到 和 /compute/finetune> 对一遍口径，数字以页面当时显示的为准。

常见踩坑与不适用边界

• 把推理框架当训练工具用：文档里出现的训练相关能力往往只覆盖特定场景，别默认它能替代完整微调流程。
• 只看别人的速度数字选型：卡型、模型、并发一变，结论就变，别人的数只能当方向。
• 许可证只看框架不看模型：框架开源不等于你用的权重能商用，上线前把权重许可和框架许可分开核一遍。
• 把三条路当成互斥选项：更常见的做法是微调在小机器上做，产物导到推理框架里上线。
• 忽略数据的合规与来源：微调用的数据能不能入境、能不能留存，往往比选哪个框架更早决定方案。

先把任务分成推理和训练两类，再比工具；顺序反了，比到最后还是在挑一个用不上的东西。