vllm ollama llama cpp 对比

本地跑模型最常卡在第一步：工具装了一堆，Ollama 拉得动但并发一上来就顶不住，vLLM 起得来却在小机器上水土不服，llama.cpp 编译过了却不知道该拿它干什么。这篇不评谁更强，只按你的机器、你的调用方式和你的交付形态，给一套能对照着打勾的选型流程，顺带说清什么时候该换、什么时候不必换。

这篇不排座次，只解决一件事：你手上这台机器、你的调用方式、你要交付的形态，到底该选哪一个。很多人卡在第一步不是因为工具不好用，而是因为拿它们当同类在比。Ollama 拉得动但几个人一起用就顶不住，vLLM 在大卡上跑得欢但搬到小机器上起不来，llama.cpp 编译过了却不知道拿它干什么，这三种情况根子上都是定位错位。

下面按硬件、并发、量化格式、接口形态四条线走一遍，每一节都给出可以直接对照着打勾的判断标准和动作。全程不写死任何数字，凡是需要具体数值的地方都告诉你去哪个站内页面按你当时的机器和权重核对。哪一步判断不下就先别装，装完再换的成本比想清楚高得多。

先分清三者不是同类竞品

把 Ollama 和 vLLM 放在同一栏比吞吐，是这类对比里最常见的误区。Ollama 省的是安装和运维的时间，vLLM 省的是高并发下的排队时间，两者换来的东西根本不是一个维度。llama.cpp 则是给你一个可控的实现底座，代价是模型管理、日志、限流这些都得自己写。先想清楚你缺的是时间还是吞吐，再往下看。

第一步：按手里这台机器划掉不可能的选项

这一步不是选优，是排除。装完跑不动再回头换框架，浪费的是你最不想浪费的那部分时间。先把显存和内存这条硬门槛过掉，再谈其他三条线。

1. 先算装不装得下把你打算用的模型和量化档位代进去，到 /models/deploy 的部署测算里按你的卡跑一遍，得到显存与内存占用。凭感觉估是这类选型翻车最多的地方。
2. 再按硬件形态划范围只有 CPU 或核显、或者用苹果笔记本，基本只剩 llama.cpp 与 Ollama 这条线；有大显存独显且要对外提供服务，才轮到 vLLM 上场。这一步能直接砍掉一半纠结。
3. 最后处理超规格的情况多卡、多机、单卡放不下的模型属于另一个量级的活。先确认你选的框架是否支持拆分，别等装完才发现根本跑不起来。具体支持情况到站内模型资料库对应条目里核。

第二步：按并发形态决定服务端还是桌面端

判断标准不是「我的并发数大不大」，而是「有没有人因为你这里排队而抱怨」。没人抱怨的时候，为了并发能力提前上一套服务端引擎，是拿运维复杂度换一个你用不上的能力。反过来，已经有人在等了，再靠桌面工具硬扛就是拿体验换省事。

• 自己一个人用、偶尔问几句、或者跑本地脚本批处理：Ollama 与 llama.cpp 的效率损失可以接受，省下的运维时间更值钱
• 多个客户端同时打、要给内部小团队做统一入口：要看框架在批处理与队列上的表现，这时服务端引擎的优势才体现出来
• 处在两者之间、只是偶尔两三个人同时用：先用现有方案跑一阵，记录实际排队感受，别按想象中的峰值来买配置
• 判断依据固定为一条：有没有人因为你这里等待而投诉。有投诉再迁，没投诉就继续用

还有一类容易漏掉的情况：瓶颈其实不在推理，而在磁盘加载速度或网络回包。这时候换框架不解决问题，先量一次冷启动和首次响应耗时，确认瓶颈位置再决定要不要迁。

第三步：量化格式决定了你可能没得选

这一步经常被跳过，但它是硬约束。不同框架对量化格式的接受度不一样，同一份权重未必能在三个框架里通用。选型前先确认你要用的那个模型，有没有对应格式的现成权重，没有的话你要花多少时间自己转。

量化格式

权重的压缩表示方式，框架支持哪些格式是有清单的，不是随便塞进去都能跑

量化档位

越高越吃资源、通常质量越好；越低越省但可能有损，档位取舍要结合你的任务容忍度

格式锁定

当上游只放出某一种格式的权重时，你的框架选择其实已经被限定，不必再纠结另外两个

换算方式

概念到 /ai-dict 对应词条理解清楚，资源和质量的取舍再到部署测算页按你的硬件比

如果你的任务是结构化输出、代码补全这类对字面准确性敏感的活，量化档位和质量取舍要更保守；如果是摘要、闲聊这类容错高的活，可以更省资源。具体档位带来的质量变化不在文字里拍板，按你自己的评测集实际跑一遍再定。

第四步：看接口形态和你的下游怎么接

这一步决定的是长期维护成本，不是启动成本。同样能跑同一份权重，接不同的下游工具，改动量差别很大。

一个实操建议：不管你选哪个，先把接口和鉴权方式一次性对齐。迁移当天最怕的不是性能不达标，而是下游工具集体报错，那会让你在压力下做出更差的决定。接口对齐之后，换引擎这件事才真的只是换引擎。

什么情况下该从 Ollama 换到 vLLM，或反过来

迁移要满足条件才做，不是觉得「新一点」就换。下面这几条是信号，出现两条以上再考虑动手；一条都没出现，换过去大概率只是把问题换个地方。

• 该换的信号：排队明显、延迟被投诉、显存利用率上不去、同一张卡能塞下更大批但没塞
• 不该换的情况：只有你一个人用，或者瓶颈在磁盘加载和网络而不是推理本身
• 方向相反的迁移同样成立：从大引擎退到小工具，适合你发现需求其实只是单人本地调用
• 迁移前先在一个隔离环境里，用同一份提示词和同一批请求跑对照，确认输出风格没有明显漂移再切

切换当天的保护动作也要提前定好：保留旧环境一段时间不删，出问题能立刻退回去；同时把新旧两边的延迟基线记录下来，否则你没法回答「这次迁移到底赚了还是赔了」。

常见选错与排查顺序

下面的顺序很重要：先怀疑资源，再怀疑格式，最后才怀疑参数配置。反过来查会绕很大一圈。拿不准具体数值就回到 /models/deploy 核对。

1. 装完跑不动先查显存与内存，再查权重格式是否匹配，最后才怀疑参数配置。顺序反了会浪费大量时间在调参数上。
2. 跑起来但很慢先量延迟基线，再判断是模型加载慢还是逐 token 生成慢，这两者的优化手段完全不同。
3. 多人用就崩先看是否有人在长上下文任务上占满资源，再看并发调度，最后才考虑升级框架。
4. 照教程装完版本对不上先固定一套能跑通的环境并记录在案，再谈升级。别边跑边升，出问题分不清是哪一步引入的。

本地推理选型，先问装不装得下、谁在用、下游怎么接，再问性能。前三个问题答完，答案往往已经只剩一个。