vllm sglang llama.cpp

本地跑模型的人常卡在这一步：模型权重下好了，框架却挑不定，随手装一个，跑起来不是显存吃满就是并发一上来就排队。这篇不讲谁快谁慢的榜单结论，只给一套能自己走完的判断顺序：先看硬件和量化，再看并发量级，最后看你要不要长期维护服务。走完这三步，该选哪个基本就定了。

把模型权重拉下来之后，真正卡人的不是下载，是框架挑哪个。三个名字你一定都刷到过：一个偏服务端高吞吐，一个偏结构化输出和多轮复用，一个偏单机轻量和 CPU 兜底。它们不是同一场比赛的选手，硬排个高下意义不大。

这篇给一条能自己走完的判断顺序：先按硬件和量化把候选砍掉一半，再按并发量级和延迟要求筛，最后看你愿不愿意长期为这套服务花运维精力。三步走完，选型基本就有答案了。具体数字不带，去哪查我会写清楚。

第一步：先按硬件和量化把范围砍一半

别一上来就比吞吐。先看手里是什么硬件：几张卡、单卡多大显存、有没有统一内存或纯 CPU 的兜底需求。这一步决定了候选集，而不是相反。

重服务形态

面向对外的批量接口，多请求并发打进来，追求整体吞吐，单个请求慢一点可以接受

重结构化形态

面向多轮对话、格式约束输出、前缀高度重复的场景，跨请求复用带来的收益比单次峰值更重要

轻量形态

面向单机试用、笔记本、CPU 或混合推理，依赖少、启动快、装完就能跑是第一优先级

• 先数清卡数和单卡显存，别按整机显存算，多卡还会有切分和通信开销
• 确认量化档位：能不能直接吃现成的量化权重，还是要自己转换，转换脚本能不能跑通
• 确认是否必须支持 CPU 或统一内存兜底——如果必须，服务端那套基本可以放一放
• 把「模型大小 + 量化档位 + 单卡显存」代入站内的显存测算页面，得出大概需要几张卡
• 显存这关过不了，后面并发和运维都不用聊了

第二步：按并发量级和延迟要求选

并发是真正的分水岭。单人交互、小团队内网工具、对外的批量接口，这三种负载对调度和显存碎片的要求完全不是一个量级。你要算的不是模型参数量，而是同时几个请求、每个请求多长上下文。

1. 估峰值并发问一句：一天里最忙的时候同时有几个请求在跑？取这个数，别取平均值
2. 定单请求上下文系统提示词加上历史对话再加上这次输入，算一个偏高的值，宁大勿小
3. 代入测算把并发和上下文一起填进站内的显存与并发测算页面，得出大概卡数
4. 回头看框架卡数够了，再比较三个框架在你这档并发下的调度方式，哪个更省显存碎片就选哪个

第三步：看你愿意为运维付多少成本

前两步是技术能不能跑起来，这一步是你愿不愿意一直养着它。要长期对外服务，版本升级、权重加载兼容、日志监控、容器化部署这四件事迟早会撞上，选一个文档水平和你团队技能匹配的，比选一个纸面参数漂亮的省心。

• 升级路径：从当前版本升上去会不会破坏现有配置，有没有明确的变更说明
• 权重兼容：换模型时是改配置就行，还是要重新转换、重写加载逻辑
• 可观测性：日志、指标、健康检查能不能接进你现有的监控体系
• 容器化：官方镜像和启动参数文档跟不跟得上，还是全靠自己拼
• 扩展特性：要接多模态、结构化输出、前缀复用这类能力，先确认目标框架当前分支到底支持到什么程度

这一步最容易踩的坑是：上线前才发现某个特性还停在实验分支或者需要打补丁。验证顺序上，把扩展特性的验证放到压测之前，别等量都跑完了再回头改框架。

换框架前先过一遍的迁移清单

决定换框架之后，别直接在生产上原地替换。按一条固定顺序验证，每一步都留可回滚的状态，出问题能马上退回去。

1. 确认格式看权重格式和量化格式能不能被目标框架直接加载，不能就先转换
2. 做输出比对转换脚本的产出和原模型跑同一批输入，逐条对比输出是否一致
3. 跑通单请求先确认模型文件、启动参数、显存占用和单请求正确性这四件事
4. 小并发压测用远低于峰值的并发量跑一轮，看显存曲线和延迟是否平稳
5. 留回退方案旧框架的启动脚本和配置原样保留，确认能随时切回去再继续

上量之前，用站内的测速页面量一次你自己的延迟基线，换完之后用同样口径再量一次。别拿别人的跑分跟自己的环境比，硬件、量化档位、上下文长度任何一项不同，数字就没有可比性。量化档位和部署细节可以到 /guides 的部署与量化分类里核对当时的资料。

还有一点值得提醒：三个框架没有绝对的优劣，只有和你的硬件、并发、团队技能是否匹配。同一家公司在不同业务线上同时用其中两个，是很常见的事。