llama.cpp vs vllm

很多人是先按教程装了一个推理框架，跑了几天才发现方向选错了：本地笔记本上硬套服务端框架，显存没吃满但怎么配都跑不动；反过来在服务器上拿单机工具接业务，人一多就排队。这篇不讲哪个更先进，只讲两套东西各自为谁设计、什么信号出现时该换、换之前要算什么。

很多人是先按教程装了一个推理框架，跑了几天才发现方向选错了：本地笔记本上硬套服务端框架，显存没吃满但怎么配都跑不动；反过来在服务器上拿单机工具接业务，人一多就排队。这篇不讲哪个更先进，只讲两套东西各自为谁设计、什么信号出现时该换、换之前要算什么。

先把结论说在前面：llama.cpp 和 vLLM 不是升级关系，是两条赛道。一个是「一台机器、少量用户、先跑得动」，一个是「一批请求、把卡喂饱、先扛得住」。你的请求形态决定了八成答案，剩下的两成由显存和卡型决定。

先把定位摆正：两个框架服务的根本不是同一类人

llama.cpp 的出发点是「一台机器、少量用户、尽量跑得动」，重点是量化后塞进有限显存或内存，交互式单路体验优先。vLLM 的出发点是「一批请求同时进来、把卡喂饱」，重点是显存管理与批处理调度，吞吐优先，单条延迟不一定更好。

请求形态

人敲一句等一句，还是系统持续提交、QPS 有下限，这个答案基本决定一半

资源形态

你手里是笔记本、单张消费卡，还是多张数据中心卡

用户数量

使用者只有你自己，还是有同事或多个系统在排队调用

• 评估阶段：只想试模型效果、还没确定要不要长期跑，先别纠结框架，能把模型装上、能对话就行
• 单机自用：优先走 llama.cpp 这条线，配置面宽、对硬件要求宽松
• 内部共享：三五个同事轮流用，先看并发上限，再决定要不要上服务端框架
• 对外服务：有系统持续提交、延迟有要求，这时候再看 vLLM 这条路的收益
• 不适用场景：既没有并发压力也没打算长期跑，比较两个框架的性能对你没意义

显存和量化：先算能不能装下，再谈快不快

llama.cpp 侧通常走 GGUF 量化，档位可以压得很低，同样的卡能装下更大的模型，代价是精度和速度随档位变化。vLLM 侧主流是 FP16/BF16 或较规整的低比特权重，权重本身占的空间更实在，但换来的是批处理时的吞吐上限。

1. 估显存按参数量、量化档位和目标上下文长度估一遍显存占用，别等部署报错才回头算
2. 跑测算到站内部署测算页面用你的模型和卡跑一遍，确认能不能装下、剩多少给 KV 缓存
3. 选档位量化档位怎么取舍看站内换算工具，先保证装得下，再比较不同档位的生成速度

关键不是哪个省显存，而是你的卡装不装得下目标模型。装不下就降档或换模型，装得下再谈快不快。到站内部署测算页面把当前数字核对一遍，比凭感觉调参靠谱。

并发形态：单路流畅和多路吞吐是两套账

单用户长对话、代码补全这类交互，瓶颈常在单条延迟和首 token 时间，两个框架都能做，但调优方向不同。多用户共享一个模型服务，瓶颈变成调度与显存碎片，vLLM 的连续批处理这类机制就是为这个场景准备的。

• 并发上限：同一时刻最多几个请求同时在跑
• 可接受的排队时间：用户等多久会开始抱怨
• 单条上下文长度：对话轮次多长、要不要塞长文档
• 吞吐下限：单位时间至少处理多少请求才算达标

这三个数字不同，结论可能完全反过来。先弄清你的一张卡能撑多少并发，参考站内资源测算页面的口径；接口首字节延迟可以用站内测速工具自己量基线，别用别人的跑分替你做决定。

硬件与系统环境：卡和操作系统会把选项砍掉一半

消费级卡、核显、苹果芯片、纯 CPU：优先考虑 llama.cpp 这类适配面宽的方案，服务端框架往往对卡型和驱动有更硬的前置要求。数据中心卡、多卡并行、容器化编排：vLLM 的收益更明显，也更方便做水平扩展。

国产卡或非主流加速卡这一条要单独说：先确认有没有对应适配分支，站内国产算力页和显卡资料库里有可查的口径。如果团队没有运维能力，选再强的服务端框架也会被环境问题拖死，宁可先跑通再升级。

切换成本：换框架不是重装一遍那么简单

权重格式要重新处理，量化产物通常不能直接复用，这一步的耗时和磁盘占用要提前留出来。接口层要对齐：OpenAI 兼容接口两边都有，但参数名、默认值、上下文长度上限和停止条件常有差异，客户端代码要过一遍。

1. 盘权重确认模型权重能否拿到、目标框架支持什么格式，把转换和磁盘时间算进排期
2. 对接口把客户端调用的参数逐项对齐，尤其是上下文长度上限和停止条件，别等上线才发现截断
3. 备回退保留旧框架的启动脚本和权重，新框架先用影子流量或少量并发验证
4. 压并发用接近真实分布的并发跑一段时间，观察失败率、延迟和显存波动
5. 再切换上面每一步都过了再切全量，任何一步没过就停在原地别硬上

落地顺序：从能跑到能扛，分三步走

第一步单机验证：同一模型、同一提示词，在两个框架各跑一遍，记录首 token 时间和生成速度，判断差距是否在你的可接受范围。这一步不用追求绝对值，只要知道两者差多少、值不值得折腾。

第二步并发验证：用接近真实分布的并发跑一段时间，看吞吐是否线性上升、显存是否稳定、有没有请求被静默丢弃。第三步长期观察：接上质量与可用性监控，关注超时率和显存波动，容器化部署参考站内集群与整机口径。

• 单机验证：同一提示词各跑一遍，记录首 token 时间和生成速度
• 并发验证：按真实分布压一段时间，重点看失败率和静默丢弃
• 长期观察：接监控，看超时率和显存波动是否稳定
• 许可证核对：框架和模型权重的授权条件分开看，别只看框架是开源的

别忘了许可证：框架本身和模型权重的授权条件分开看，商用边界到站内安全合规页和模型库页确认。框架开源不等于你用的模型能商用，量化产物再分发也可能有限制。

容易忽略的两件事：许可证与运维口径

自建推理的成本结构和在线 API 完全不同：算的是电费、折旧和人力，不是按次计费。推理服务的计费与额度口径也和在线 API 不一样，到站内自建成本页看三年账口径，把显卡折旧和运维人力都算进去。

• 模型版本谁管：谁负责更新权重、谁负责回滚
• 配置变更谁批：参数调整走不走流程
• 出问题找谁：夜里服务挂了有没有人响应
• 量与边界：如果只是临时用、量又小，直接调 API 可能比自建更省事

团队协作场景要提前定这三件事：谁来管模型版本、谁来管配置变更、出问题找谁，否则框架选对了流程也会乱。这条分界线不在本篇讨论范围，但选型时心里要有数。

一张对照表快速定位你该选哪边

把前面的维度收拢成一张表，按你的实际情况对号入座。判断顺序建议：先看用户数量，再看卡型，最后看并发要求。三个维度里有一个明显偏向某一边，就先按那边选。

两种都有的做法：把 llama.cpp 放在边缘或单机侧做轻量推理，vLLM 放在中心侧做批量服务，接口层统一成 OpenAI 兼容格式，减少客户端改动。这样切换时客户端几乎不用动，代价是多维护一套部署。

至于具体跑分、显存占用和延迟数字，别用这篇里的描述当结论，到站内测速工具和部署测算页面看你自己的硬件在当时的数字。硬件、驱动和模型版本都会变，别人环境里的数字对你参考有限。