手里一台机器、一个模型文件，到底装 vLLM 还是 llama.cpp？网上说法两头倒，一个是「高并发才用」，一个是「本地跑就用」，但真到动手时还是不知道该看哪几个指标。这篇不讲原理教科书，只给一条判断顺序：先看你的请求量和显存形态，再看模型权重是什么格式，最后才谈调优。中间会附上什么情况下这套判断不适用。
手里一台机器、一个模型文件，到底装 vLLM 还是 llama.cpp？网上说法两头倒，一个说「高并发才用」，一个说「本地跑就用」，真到动手时还是不知道该看哪几个指标。这篇不讲原理教科书，只给一条判断顺序：先看请求量和显存形态，再看权重是什么格式，最后才谈调优。中间会附上什么情况下这套判断不适用。
一个前提先摆前面：这俩不是同一类东西的强弱之分，只是为不同场景长出来的两套工程取舍。你选错的那次，八成不是参数没调好，而是从一开始就站错了场景。下面按四条线拆：各自定位、并发基线、权重格式、场景清单。
先分清这两个东西各自是为谁做的
vLLM 是给服务端多并发场景设计的推理引擎，核心卖点是连续批处理和显存复用。注意这句话的适用范围：一个人用、一次一个请求时，它的优势基本体现不出来，你甚至会感觉部署完还多了一层麻烦。llama.cpp 是从个人设备跑量化权重起家的，核心卖点是能塞进小显存，CPU 和 CPU+GPU 混合卸载都能跑，单请求延迟也不难看，但并发一上来吞吐就顶不住。
| 维度 | vLLM 更常见的选择 | llama.cpp 更常见的选择 |
|---|---|---|
| 主要场景 | 服务端、多请求同时在线 | 单机、个人、边缘设备 |
| 并发表现 | 并发叠起来后优势明显 | 单请求尚可，并发一多就吃力 |
| 硬件形态 | 偏 GPU 服务器 | CPU、小显存 GPU、混合卸载 |
| 权重取向 | 原始权重加主流量化方案 | 自己的那套量化文件 |
| 运维成本 | 依赖多，部署和升级更重 | 单文件为主，搬起来省事 |
- 先把「谁在用、几个人用、会不会同时用」写下来，这一步比看任何评测都准
- 再把机器的硬件形态确认清楚：有没有可用的 GPU、显存多少、CPU 能不能顶
- 最后确认真实权重文件是什么格式，格式不匹配时转换成本要提前算
- 如果这三条里有两条指向不同框架，以「权重格式 + 并发量」这条线为准
先量你的并发和延迟基线，再决定看谁
把「同时有多少个请求在等」和「单个请求能忍多久」分开记录。前者决定要不要上批处理引擎，后者决定能不能接受小设备方案。很多人把这两个指标混成一个「快不快」，结果既说不清需求，也看不出换框架是变快还是变慢。
- 量现状基线用站内的接口测速把自己现有的延迟基线量出来，没有基线就没有对比对象，换完框架只能凭感觉说好或不好。
- 估算显存上限按模型参数量和量化档位到部署测算页走一遍，大致看出你这张卡能容纳多少并发。
- 按顺序排查模型能不能装下 → 单请求够不够快 → 并发够不够用；前一步不成立就别往下一步调参。
- 记下结论把每一步的结论写一行，三行填不满就先别下单买卡。
延迟和吞吐要分开看：在线服务里用户感知强的是首字延迟，离线批处理里真正决定成本的是整体吞吐。两条指标打架时，先按你的业务形态定优先级，再回头看框架，而不是反过来让框架决定业务。
权重格式和量化档位，往往比框架先决定成败
同一个模型，量化档位选得激进虽然能塞进小显存，但输出质量会掉；档位保守可能根本装不下。这是选型里最早要拍板的一件事，拍错了后面框架选得再对也白搭。
- GGUF
- llama.cpp 常用的量化权重文件格式，单机部署时比较省事，转换和加载都比较直接。
- 原始权重
- 未量化的模型权重，服务端方案里更常见，显存占用大但质量损失小。
- 量化档位
- 同一模型不同压缩程度的版本，档位越高越省显存，输出质量可能相应下降。
- 格式转换
- 把一种权重格式转成另一种，涉及时间和验证成本，转换前后都要跑一遍抽样对比。
vLLM 更偏向服务端常用的量化方案，llama.cpp 走的是 GGUF 那一套。如果手里的权重已经是其中一种，硬转换的成本和风险要提前算进去。想知道量化档位在质量、显存、吞吐上的取舍，对照站内 AI 模型库里同一个模型的规格页看，比听别人一句「我用着挺好」靠谱得多。
按场景对号入座的自查清单
上面三条线都量完，最后一步是对号入座。下面几种典型场景，判断逻辑差别很大，别拿一类场景的经验去套另一类。
- 小团队内部工具、三五个人偶尔用：先考虑部署省事那条路，别为了理论吞吐上重框架，运维成本会吃掉省下的时间
- 面向外部用户、请求会叠在一起：重点看批处理和显存管理，吞吐是硬指标，单请求延迟可以通过限流和排队缓解
- 离线批量跑数据、不要求实时返回：瓶颈在总吞吐而非首字延迟，选择逻辑和在线服务完全不一样
- 边缘设备、显存很小甚至只有 CPU：可选项本就有限，先确认有没有跑得动的量化权重，再谈框架
- 不确定自己属于哪类：先写清每天大概多少请求、峰值叠几个、能忍几秒，答案基本自己就浮出来了
这些判断之外还有两类坑常被忽略：一是团队的运维能力，重型方案的部署、升级、故障排查都需要人跟；二是后续换模型的频率，如果你两三个月就要换一个新模型，部署轻的那条路通常更抗折腾。两类都指向同一个结论：先按你的场景定框架，再按框架收敛方案。
下一步把每天请求量、峰值并发、可接受延迟这三个数写下来，再去站内把这两类框架的实际部署和测速记录翻一遍，对着自己的数看，比在群里问一句选哪个快得多。→常见问题
单机自己用，是不是随便选一个都行？
大体上是的，但有两个前提：模型权重的格式得跟框架对得上，显卡或者 CPU 的可用内存得装得下你选的量化档位。这两条不满足，框架再合适也跑不起来。反过来说，如果这两条都满足、请求量又很低，那纠结框架的时间不如拿去调提示词或者换量化档位。
换框架能明显提升速度吗？
要看瓶颈在哪。瓶颈在显存装不下、每次都要反复加载权重时，换框架帮助有限，先解决量化档位和显存的问题。瓶颈在多个请求排队时，服务端批处理型框架的优势才会显现。建议先按站内测速页量出你现在的基线，改完再量一次对比，别凭感觉说变快了。
量化档位和框架要一起决定吗？
建议一起看，但顺序是先定档位再定框架。因为档位直接决定模型能不能装进你的显存，装不下后面全是空谈。档位定了之后，权重格式往往就限定了可选的框架范围，这时候再比较两个框架的并发表现才有意义。
