本地跑模型的人迟早会卡在这一步：机器就那一台，模型权重也下好了，到底用 llama.cpp 还是 vLLM？网上说法一半对一半，照着装完才发现方向错了。这篇不站队，只给一套按硬件形态、并发量、离线还是在线三个维度走的判断顺序，顺带说清哪些情况下两边都能用、不用纠结。
本地跑模型的人迟早会卡在这一步：机器就那一台，模型权重也下好了，到底用 llama.cpp 还是 vLLM？网上说法一半对一半，照着装完才发现方向错了。这篇不站队，只给一套按硬件形态、并发量、离线还是在线三个维度走的判断顺序，顺带说清哪些情况下两边都能用、不用纠结。
先说结论性的思路：这不是「谁更强」的问题，而是「你的机器和你的请求长什么样」的问题。选型之前先把自己的场景写下来，再对照后面的清单逐条排除，比看一堆横评有用得多。
先认清两个框架各自是从哪长出来的
llama.cpp 起家于在消费级硬件和 CPU 上把模型跑起来，重单机、重量化、重跨平台；vLLM 起家于服务端批量推理，重吞吐、重调度、重多卡。两者不是升级关系，是两种目标函数的产物：一个是「这台机器能跑」，一个是「这批请求要并发地跑完」。
- 单机取向
- 让有限硬件尽量跑得动，愿意为省显存牺牲一点调度灵活性
- 服务取向
- 让同一批硬件同时服务更多请求，愿意为吞吐接受更重的部署和依赖
判断自己属于哪一类，先回答一个问题：你的请求是一次一个，还是一次来几十上百个。这个答案基本能砍掉一半纠结。
第一步看硬件形态，不是看参数表
硬件形态是最硬的约束，也是最容易被忽略的一步。很多人先看别人推荐哪个框架，再回头看自己的机器，顺序反了。
- 只有 CPU、或者核显/集显、或者 Mac 统一内存：llama.cpp 这条路基本没有悬念
- 消费级单卡、显存刚好卡在模型边缘：先算显存账，去站内 /tools 里的换算工具和 /compute/sizing 按模型过一遍，再决定选哪边
- 多张数据中心卡、显存富裕：优先把 vLLM 当作默认候选，除非你的场景根本不需要并发
- 混合场景（部分层卸载到 CPU）要提前想清楚：这条路对两个框架的代价完全不一样
什么情况下这条判断不适用？当你的硬件是「勉强够」而不是「明显够」的时候。显存刚好卡边缘时，两个框架都可能有额外开销，这时候必须实测，不能只看硬件类型下结论。
吞吐和延迟：先分清你要的是哪个
单请求低延迟和整体高吞吐是两件事，很多时候不能同时拿满。先把指标定死再选框架，不然永远选不对。
| 场景 | 更在意的指标 | 选型倾向 |
|---|---|---|
| 离线批量生成语料 | 整批跑完的总时间 | vLLM 的批量调度更有优势 |
| 在线对话服务 | 每个请求的首字延迟 | 看并发量，低并发两边都能用 |
| 本机写代码辅助 | 响应是否跟手 | llama.cpp 更省心 |
| 跑评测集 | 单位时间处理样本数 | 按并发量实测后再定 |
并发一上来，批处理和显存管理策略的差别会被放大，这就是为什么服务端场景的讨论绕不开 vLLM。在线对话、API 网关这类请求间隔短、要持续接客的场景，和离线批量生成语料、跑评测集的场景，选型结论可能相反。
量化格式决定你能走哪条路
llama.cpp 生态围绕 GGUF 这类为低比特和混合卸载设计的格式；vLLM 更偏服务端常见的量化与并行方案，两边的权重不一定通用。选框架前先确认你手上的权重格式有没有对应支持，否则后面全是白折腾。
- 量化档位直接影响显存占用和质量，档位怎么选要看站内 /ai-dict/category/tech 里的概念说明，别凭感觉挑最低比特
- 同一个模型在两个框架下可用档位不同，拿不准就先查格式支持情况
- 如果模型只有一种格式可用，那选型空间其实已经被压到只剩一条路
- 换框架往往意味着重新下权重、重新验证效果，这个成本要算进决策
部署和运维的隐形代价
环境依赖、容器化难度、驱动版本耦合程度，这些不写在对比表里，但决定了你后期加班多少。一个人维护的小项目和一个有值班的团队，该选的方案大概率不一样。
| 成本项 | llama.cpp 侧 | vLLM 侧 |
|---|---|---|
| 依赖复杂度 | 相对轻，跨平台好装 | 偏重，与环境耦合更紧 |
| 多机多卡 | 通常不是它的主场 | 常见部署形态 |
| 上手门槛 | 单机本地化跑通较快 | 服务化配置需要经验 |
| 出问题找人 | 社区资料偏本地场景 | 社区资料偏服务端场景 |
团队里谁能维护它：如果只有一个人懂，选那个出问题时社区资料更好找的。更新模型、换权重、回滚版本的流程要提前想，别等到线上出问题才补。
并发涨上来之后会发生什么
vLLM 的优势在并发下才显现，低并发时它的复杂度可能是纯负担；反过来 llama.cpp 在单请求场景往往更省心。所以并发估算是选型的核心输入之一，不能拍脑袋。
- 估显存余量按模型大小和量化档位反推显存余量，参考站内 /compute/sizing 的思路，再看你要的并发数能不能放下
- 定峰值并发要不要多卡多机，取决于峰值并发而不是平均值；平均很低、峰值很高的业务要按峰值准备
- 找瓶颈位置扩容之前先确认瓶颈在显存、在算力还是在调度，不然加卡不一定有用
- 小规模验证用同一模型、同一批请求量在两个框架各跑一次，比较实际表现再定
这条判断在什么情况下不适用？当你的业务并发几乎恒定、没有明显峰值时，按平均值准备也问题不大，但这类业务本来就少见。
许可证和合规别放到最后
框架本身的开源许可证和模型权重的许可证是两回事，两个都要看，别只看模型能不能商用。权重许可证的细节容易埋坑，特别是再分发和商用边界。
- 拿不准就去站内 /ai-dict 相关条目把概念对齐，别照搬别人的结论
- 如果模型要进内网或对外提供服务，合规判断要前置到选型阶段，不然后面可能推翻重来
- 再分发权重的场景要额外确认授权范围，这一步很多人会漏
- 开源权重不等于随便用，具体条款以你实际下载的那份为准
一张能直接照着走的判断清单
把前面几节压缩成五个问题，顺着走一遍基本能得出结论。如果两个框架都满足条件，那就说明这个场景选哪个都能跑，不必继续纠结。
- 问题一：硬件只有 CPU 或 Mac？是，则基本选 llama.cpp，跳到问题五
- 问题二：并发并发请求常年只有一两个？是，则优先 llama.cpp，除非你明确要服务化
- 问题三：服务化多张卡、并发几十以上、要持续对外供服务？是，则优先 vLLM
- 问题四：权重格式你的权重格式只有一种可用？那就按格式定框架，别按偏好定
- 问题五：实测把上面结论拿去做一次小规模实测，用同一模型、同一提示词、同一批请求量对一遍，再最终定下来
选框架不是选立场，是把硬件、并发、格式这三个约束按顺序排除掉。
最后提醒一句：任何对比表都只是起点。你机器上的显存、驱动、权重格式，才是真正决定答案的东西。先跑起来，再谈优化。
下一步把你手上机器的实际表现和站内资料对照一遍，再决定要不要换框架。→常见问题
llama.cpp 和 vLLM 能不能在同一个项目里同时用？
可以，但要想清楚分工。常见做法是把批量离线任务和在线低并发入口放一边，把高并发的服务接口放另一边，两边各自跑各自擅长的模型格式。代价是你要多维护一套环境和权重，人少的时候这个代价不一定划算。
我只有一张消费级显卡，是不是就一定选 llama.cpp？
不一定，取决于并发。如果只是自己用、一次一个请求，选 llama.cpp 更省事，量化档位也更灵活。如果这张卡要同时接好几个用户，就得先按模型和量化算显存余量，再判断 vLLM 在你的卡上是否跑得起来，别默认它一定行。
换成 vLLM 之后速度没变快，是什么原因？
大概率是并发没上去。vLLM 的收益主要来自批处理和显存调度，单请求场景下它和别的方案差别很小，甚至更慢。先确认你的实际并发量，再去排查是不是配置或参数没调对，具体报错和排查顺序可以对照站内相关部署文章。
量化档位选低一点，是不是就能用更小的卡跑？
显存占用确实会降，但质量损失和速度变化要一起看，不是越低越好。同一模型在不同档位下的表现差异，建议用你自己的任务集实测一遍，别只看别人的对比结论。档位与精度损失的原理可以去站内的技术词典条目补一下。
选框架的时候，价格要不要一起算？
要，但要看你走的是自建还是租卡。自建看的是硬件一次投入和电费，租卡看的是按时计费下的吞吐效率——吞吐高意味着同样任务占用的时长更短。具体租金和口径别凭记忆，去站内的算力和比价页面看当时的数字。
