16G 消费级显卡跑本地大模型：vLLM、SGLang、Transformers 到底怎么选
最近看到一个很典型的问题：
16G 消费级 A 卡跑本地大模型时，为什么感觉 vLLM / SGLang 还不如 Transformers 省显存，甚至速度也不一定更快？
这个问题不能简单回答成"哪个框架更强"。
因为 vLLM、SGLang、Transformers 的目标并不完全一样。它们不是同一类工具的三个皮肤，而是偏向不同推理场景的三套取舍。
如果只拿一张 16G 消费级显卡、一个模型、一个 prompt 跑一下，就直接下结论，很容易误判。
这篇先不做榜单，讲一个更稳的选型框架。
1. 先说结论
如果你只有一张 16G 消费级显卡，尤其是 AMD 消费卡，优先考虑顺序通常是：
- 先用 Transformers / llama.cpp / Ollama 这类路径确认模型能稳定跑起来
- 需要 OpenAI-compatible API、批量请求、服务化部署时，再看 vLLM
- 需要复杂 Agent、结构化生成、多轮状态管理、prompt program 时，再看 SGLang
- 如果只是个人单用户聊天，不要为了"听起来更专业"强行上高吞吐推理框架
更关键的是：任何结论都必须带上测试条件。
至少要写清楚：
- GPU 型号和显存容量
- CUDA / ROCm / 驱动版本
- Python、PyTorch、Transformers、vLLM、SGLang 版本
- 模型名称和参数量
- FP16、BF16、INT8、INT4、AWQ、GPTQ、GGUF 等量化方式
- 上下文长度
- batch size / 并发数
- prefill 和 decode 是否分开统计
- 显存统计方式是 nvidia-smi、rocm-smi、框架日志，还是 PyTorch allocator
没有这些条件，"谁更省显存"基本没有可复用价值。
2. 为什么同样 16G，体验会差很多
本地大模型推理的显存占用不只是"模型大小"。
粗略拆开看，至少有几块：
- 模型权重
- KV Cache
- 激活和临时 buffer
- CUDA/ROCm runtime、kernel workspace
- 框架自己的内存池和调度结构
- tokenizer、scheduler、server 进程等额外开销
很多人只盯着权重。
比如一个 7B 模型，FP16 权重大约十几 GB，看上去 16G 勉强能跑。但只要上下文变长，KV Cache 会继续吃显存；如果框架为了吞吐预留 block、使用 paged attention、启用 CUDA graph 或额外 workspace，显存曲线就和单纯 Transformers 不一样了。
所以你看到的现象可能是：
- Transformers 单请求跑起来更省，因为它没有服务化调度的额外结构
- vLLM 初始显存占用更高，因为它倾向为吞吐和 KV Cache 管理做预分配
- SGLang 在简单单请求场景下优势不明显，因为它的价值更多在复杂生成流程和服务化调度
- AMD ROCm 环境下，部分 kernel、算子、量化后端和框架适配没有 CUDA 路径成熟
这不代表 vLLM 或 SGLang 差。
这只能说明：你当前测试场景没有触发它们擅长的收益，反而先承担了它们的成本。
3. Transformers 适合什么场景
Transformers 最大的优势是确定性和生态兼容。
适合：
- 单用户、本地调试
- 验证模型能不能跑
- 研究模型结构、tokenizer、generation config
- 做脚本级推理
- 想快速定位显存爆在哪里
- AMD/ROCm 环境下先确认基础链路
它的好处是路径直接。你可以先用它建立 baseline：模型能否加载、chat template 是否正确、量化方式是否可用、当前驱动和 PyTorch 是否稳定。
这类代码不适合高并发服务，但非常适合建立第一条可解释的基线。
如果 Transformers 都跑不稳，直接上 vLLM 或 SGLang，排障会更痛苦。
4. vLLM 适合什么场景
vLLM 的核心价值不是"单次请求最省显存"，而是服务化和吞吐。
它擅长：
- OpenAI-compatible API
- 多用户并发
- continuous batching
- PagedAttention / KV Cache 管理
- 更高吞吐的在线推理服务
- 把模型作为一个长期运行的后端服务
但在 16G 显卡上，几个参数非常敏感：
- max model length 越大，KV Cache 预算越大
- gpu memory utilization 越高，框架越倾向吃满显存
- batch / 并发越高，吞吐收益越明显，但显存压力也更大
- 量化后端是否支持当前 GPU，决定"理论省显存"能不能落地
所以如果你只是单用户问一句话，看到 vLLM 初始显存占用比 Transformers 高，不奇怪。
vLLM 是为了服务化吞吐设计的，不是为了在任意单请求场景下显存最低。
5. SGLang 适合什么场景
SGLang 更适合复杂推理程序。
比如：
- 多轮对话状态管理
- Agent 工作流
- 多阶段 prompt
- 结构化输出
- constrained decoding
- 多请求复用和服务化生成
如果你的任务只是"输入一个 prompt，输出一段回答"，那 SGLang 的优势不一定明显。
但如果你的任务是"先抽取需求，再生成 SQL，再校验字段，再让模型修正，最后输出 JSON"，SGLang 的工程价值会更容易体现。
也就是说，SGLang 更像"推理程序框架"，不是单纯的"更快 generate"。
6. 16G 显卡最容易踩的坑
6.1 只看参数量，不看上下文长度
7B 模型能不能跑，和你开 2K、8K、32K 上下文是两回事。KV Cache 会随上下文长度增长。长上下文不是免费能力。
6.2 混淆单请求延迟和服务吞吐
Transformers 单请求可能更快。vLLM 在并发起来后吞吐可能更好。这两个指标不是一回事。
6.3 拿 CUDA 经验套 AMD ROCm
AMD 卡不是不能跑，但生态成熟度和 CUDA 路径不同。同一个框架在 NVIDIA 和 AMD 上，kernel 支持、量化后端、安装复杂度、bug 密度都可能不同。
所以"别人 16G 能跑"不等于"你的 16G A 卡也能同样跑"。
6.4 把框架预分配当成实际用量
有些框架会预留显存。rocm-smi / nvidia-smi 看到占用高，不一定等于这部分都在存模型权重，也可能包含 cache block、allocator、workspace。
测试时要同时看框架日志和实际请求表现。
7. 推荐测试口径
如果要认真比较，建议固定变量：
| 维度 | 建议记录 |
|---|---|
| 硬件 | GPU 型号、显存、CPU、内存 |
| 驱动 | NVIDIA driver / CUDA 或 AMD driver / ROCm |
| 软件 | Python、PyTorch、Transformers、vLLM、SGLang 版本 |
| 模型 | 模型名、参数量、上下文长度、chat template |
| 精度 | FP16/BF16/INT8/INT4/AWQ/GPTQ/GGUF |
| 请求 | prompt token、output token、并发数、batch |
| 指标 | 首 token 延迟、输出 tokens/s、峰值显存、稳定性 |
最低限度，跑三组：
- 单请求，短上下文：看启动成本和基础延迟
- 单请求，长上下文：看 KV Cache 压力
- 多请求并发：看服务化框架是否开始体现收益
只跑第一组，就很容易得出"Transformers 最好"的结论。但那只是"个人调试场景最好"，不代表"线上服务最好"。
8. 我的选型建议
如果是个人开发者或独立开发项目：
- 先用 Ollama / llama.cpp / Transformers 跑通模型
- 再决定是否需要 OpenAI-compatible API
- 没有并发需求，不急着上 vLLM
- 没有复杂生成流程，不急着上 SGLang
- AMD 16G 卡先验证 ROCm 支持和量化后端，不要只看 README
如果是小团队内部服务：
- 先明确并发量、平均上下文长度、峰值请求
- 再用 vLLM 做服务化验证
- 尽量固定模型和量化方式，避免每天换环境
- 把显存、首 token 延迟、tokens/s、失败率纳入监控
如果是 Agent 或复杂工作流：
- Transformers 适合调试单步模型行为
- vLLM 适合当模型服务后端
- SGLang 适合把复杂生成逻辑工程化
9. 最后
16G 消费级显卡不是不能玩本地大模型，但它没有太多浪费空间。
在这种资源约束下，框架选型不能只看"谁更火"，更要看：
- 你的请求是单用户还是多并发
- 你的上下文是 2K 还是 32K
- 你的目标是调试、服务化，还是复杂推理程序
- 你的显卡生态是 CUDA 还是 ROCm
- 你的模型有没有可靠量化后端
我的建议很简单：
先用最直接的工具跑通，再用更复杂的框架解决明确的问题。
别为了框架而框架。
本地推理真正的门槛，不是把命令跑起来，而是知道每一 GB 显存花在了哪里。