你手上有一台机器、一个开源模型，想跑起来却卡在两个框架之间：一个听说吞吐高、适合多并发，一个听说在消费级显卡甚至纯 CPU 上都能转。两边文档都在说自己好，但没人告诉你在你这台机器上该用哪个。这篇按部署场景拆开讲，先看硬件和并发需求，再看显存占用和量化格式的差别，最后给一份跑之前的检查顺序。
你手上有一台机器、一个开源模型，想跑起来却卡在两个框架之间：一个听说吞吐高、适合多并发，一个听说在消费级显卡甚至纯 CPU 上都能转。两边文档都在说自己好，但没人告诉你在你这台机器上该用哪个。
这篇按部署场景拆开讲，先看硬件和并发需求，再看显存占用和量化格式的差别，最后给一份跑之前的检查顺序。全程不给绝对答案，只给判断标准和能落地的动作，数字部分请到站内对应页面核对当时的实测结果。
先看场景：谁在什么情况下该用哪个
选型第一步不是比框架，而是把你自己的调用方式写清楚：同时有几个人在用、请求是突发还是持续、模型文件要不要随手换、机器是不是只有你自己碰。这几条决定了后面所有对比有没有意义，因为两个框架的强项压根不在同一个维度上。
| 使用场景 | 更适合的路线 | 原因 |
|---|---|---|
| 单人本地试用、笔记本或纯 CPU | llama.cpp 这条线 | 权重可卸载、支持纯 CPU 推理，装起来不挑环境 |
| 多人共享、常驻 API 服务 | vLLM 这条线 | 批量调度和并发排队处理是它的主场 |
| 2-3 人小团队、单卡、偶尔并发 | 两边都装，实测再定 | 没有标准答案，得看你这台机器的真实延迟基线 |
| 硬件无官方适配分支 | 先别比性能 | 没有适配结论基本不成立，对比数据不可信 |
判断的分水岭不是模型大小，而是同时有几个人在调用、以及你愿不愿意为显存利用率做参数调优。愿意调、并发放得开，就往批量调度那侧走；只想插上就跑、随时换模型文件，就往轻量那侧走。
- 写清调用画像统计同时调用人数、峰值请求频率、是否需要常驻不重启。写不出来就先按最坏情况估。
- 确认硬件在不在支持列表到 /compute/gpus 和 /compute/domestic 核对型号与驱动，不在列表里就别继续比。
- 两种都装上跑同一批请求用同一批 prompt、同一量化档位，到 /tools/speed-test 量出你这台机器的延迟基线再决定。
显存占用：差在权重格式和缓存策略上
同一个模型，两边吃显存的方式不同：一边偏向整块权重常驻显存再加 KV 缓存，一边支持把部分层卸载到内存甚至纯 CPU 跑，卸载比例直接决定你能把模型开到多大。所以别拿同一个模型文件在两边比显存占用，前提都不一样。
量化格式是另一个变量。GGUF 那一套是为低显存和 CPU 场景准备的，GPU 侧的量化方案在吞吐上通常更占优，具体档位的取舍看 /quantization-tier-choice 和 /quantization-gguf-awq-explained，里面有格式对照和适用边界。
- 先按 /models/deploy 的口径算一遍权重加缓存的账，再留出余量给并发，余量留多少和上下文长度强相关
- 上下文长度直接决定 KV 缓存大小，把它设得比显存能扛的还大是最常见的返工点
- 打算把上下文开到模型上限、又同时扛并发时，显存账要按最坏情况算，日常跑得动不代表峰值跑得动
- 卸载比例、分片数、并发上限这三个参数互相牵制，调一个记得看另外两个的表现
- 权重常驻
- 整个模型放进显存，换来更低的单次延迟，代价是显存被一口吃满
- 分层卸载
- 把部分层放到内存或 CPU，能跑更大的模型，代价是延迟波动变大
- KV 缓存
- 随上下文长度和并发数增长，往往比权重更容易把显存撑爆
吞吐与并发：数字别跨机器横着比
两边的吞吐差距会随并发数变化：低并发时可能互有胜负，并发拉高后批量调度那一侧的优势才显现。所以只测单条请求的生成速度会得出误导结论，你测出来的其实是延迟，不是吞吐。
比较的前提是同型号卡、同量化档位、同上下文长度，换任何一项，结论就换了。站内的对比数字请到 /inference 和 /tools/speed-test 核对当时的条件和结果，不要脱离条件看结论。
- 固定变量锁定模型、量化档位、上下文长度、卡型号，先一次只改并发数。
- 逐级加压从低并发开始，每次加一档，记录平均延迟和峰值显存，别一步跳到高并发。
- 找拐点延迟开始非线性上涨、显存贴顶的那个并发数，就是你这台机器的真实上限。
- 留出生产余量把拐点当成硬上限，生产环境的并发限制设在拐点以下，避免排队雪崩。
动手前的检查清单与常见返工点
跑通之前先过一遍清单，能把大部分返工挡在前面。顺序别乱：先确认硬件，再确认模型，再确认显存账，最后才是服务配置和许可证。
- 确认卡的型号与驱动版本，对照 /compute/gpus 的支持范围
- 确认模型权重的格式和量化档位，跟打算用的框架是否匹配
- 确认显存够不够按并发峰值算，不是按单条请求算
- 确认服务端口、鉴权方式和容器里的模型目录挂载路径
- 确认许可证允许你的用途，框架开源不等于模型权重可以随便商用，边界看 /open-weight-license-basics
| 返工点 | 典型表现 | 怎么提前避免 |
|---|---|---|
| 权重格式与框架不匹配 | 启动就报错或加载后无法推理 | 装之前先查框架支持的格式清单 |
| 上下文长度超显存 | 跑一会儿就被系统杀掉 | 按峰值并发加最大上下文算显存账 |
| 并发上限没设 | 请求堆积、延迟一路走高 | 用压测拐点作为并发限制 |
| 容器没挂模型目录 | 容器里找不到模型文件 | 启动参数里显式挂载并对路径做权限检查 |
跑通之后再谈优化，先保证能稳定响应，再去看 /vram-optimization-guide 里的分片和卸载手段。顺序反了容易同时在调三个变量，最后根本不知道是哪个改动起了作用。
先让服务稳定应答，再让服务跑得更快，把这两件事分开做。下一步把你的硬件型号、模型格式和预期并发写下来，对照站内的支持列表和压测工具走一遍，比看十篇对比文都管用。→
常见问题
我的显卡显存不大，是不是只能用 llama.cpp？
不一定。关键看你打算跑多大的模型、用什么量化档位、要不要同时接多个请求。显存小但只服务一两个人的话，慢一点也能接受；反过来如果必须扛并发，就得先算清权重加缓存的最低需求，再决定是降量化还是换卡。按 /models/deploy 的口径先算一遍，比凭感觉猜靠谱。
两个人团队、一台单卡机器，值得为吞吐额外折腾吗？
先算调用量。如果一天几百次请求、大家都是手动触发，延迟差个几百毫秒基本无感，挑一个装起来简单、升级模型省事的就够。只有当请求会排队、或者你要把它挂给自动化流程反复调用时，批量调度带来的差别才开始值钱。建议先用 /tools/speed-test 量出基线再判断。
同一份模型权重能两边通用吗？
通常不能直接共用，因为两边倾向的权重格式和量化方式不同，需要转换或各自准备一份。转换前先确认目标框架是否支持该量化格式，转完拿一小批固定提示词各跑一遍，比对输出是否一致。如果模型本身较新，还要确认框架的适配分支有没有跟上，否则容易出现加载失败。
