本地跑模型跑到一半，常卡在三件事：单机试玩挺好，一上并发就崩；量化档位随手选，质量掉得莫名其妙；服务跑起来了，商用许可证却没看清。这篇不讲空泛概念，只给一套可执行的判断顺序——Ollama、llama.cpp、vLLM 各自适合什么形态的负载，怎么按显存和并发反推配置，什么情况下该换、什么情况下别折腾。
本地跑模型跑到一半，常卡在三件事：单机试玩挺好，一上并发就崩；量化档位随手选，质量掉得莫名其妙；服务跑起来了，商用许可证却没看清。这篇不讲空泛概念，只给一套可执行的判断顺序——Ollama、llama.cpp、vLLM 各自适合什么形态的负载，怎么按显存和并发反推配置，什么情况下该换、什么情况下别折腾。
先说清楚立场：这三个不是同一层的竞品，硬比谁更强没有意义。它们的差异集中在调度方式、量化支持和工程依赖上，而不是模型能力本身。你手里的权重文件基本都能在三者上跑起来，真正决定体验的是你的负载长什么样、卡有多大、运维能力有多少。
先搞清楚你的负载长什么样，再谈选谁
三类典型负载基本对应三条技术路线：单人交互式试用、单机多用户中低并发、面向多路请求的服务端吞吐。它们的主场几乎按这个顺序排列。选之前先回答几个问题：同时在线几个人、请求会不会排队、能不能接受首字延迟、服务要不要常驻不重启。
- 单人交互式试用：重点是上手快、模型管理省心，跑通链路比压榨性能更重要
- 单机多用户中低并发：重点是在有限显存里塞进更大的模型，量化支持是否齐全比什么都重要
- 面向多路请求的服务端吞吐：重点是调度效率和显存利用率，代价是部署门槛高、对卡和驱动更挑
- 如果负载形态三个月内会变（比如从试用转成对外服务），别一次选型定死，先留一层可替换的接口
不适用的场景也要说清楚：如果你的服务对首字延迟极其敏感且请求量很小，那套面向高吞吐的调度策略反而可能带来额外开销；反过来，如果同时在线人数稳定在几十以上，用轻量方案硬扛只会让你在半夜被拖慢的响应叫醒。判断信号是「有没有排队」，不是「现在跑得动跑不动」。
三者的能力边界：别只比谁的说明文档好看
把三者放在同一张表里看，各自的强项和别扭之处会清楚很多。注意这里的「强项」都带着代价，选它就得接受那部分代价。
| 路线 | 强项 | 别扭的地方 | 适合谁 |
|---|---|---|---|
| 开箱即用型 | 模型拉取和管理省心，桌面端常驻方便，快速验证链路快 | 想深度改参数或接复杂调度会别扭，调优空间有限 | 个人开发者、快速验证、桌面端常驻 |
| 底层可控型 | 量化格式全，CPU 与混合推理是强项，窄硬件上能极限压榨 | 服务化能力要自己搭，多用户并发得自己写调度 | 边缘设备、单机极限压榨、窄硬件、想深度改参数的人 |
| 服务端吞吐型 | 面向多路并发与吞吐设计，调度和显存利用是重点 | 环境依赖重、部署门槛高、对卡和驱动更挑 | 有运维能力的团队、对外提供多用户服务 |
共同点值得单独强调：三者都能跑同一批开源权重，差别不在模型本身。所以「换个框架模型会不会变差」这个担心基本可以放下，真正会变的是单位时间能处理多少请求、首字延迟多长、显存还能剩多少。
按显存和量化档位反推配置：一份可照着走的清单
顺序颠倒最容易白买卡。正确顺序是：先定模型规模，再定量化档位，然后留出 KV 缓存和并发余量，最后才决定卡数。很多人反过来，先看卡再想模型，结果要么塞不下要么浪费一半显存。
- 定模型规模按任务难度选一个够用的规模，别一上来就冲最大；用小模型先跑通链路，再决定要不要往上加。
- 定量化档位先确认目标框架支持哪些量化格式，再看质量损失能否接受，最后才看省了多少显存；档位不是越低越好。
- 留并发余量KV 缓存要单独算，并发数上去后显存和延迟同时变差，别拿单请求的实测数字去估线上。
- 决定卡数前面三步都定了再算卡数；跨卡还要考虑通信开销，不是简单叠加。
关于数字：显存占用、量化后的质量差异、不同并发下的吞吐，这些都随版本、驱动、卡型变化。到 /models/deploy 和 /compute/sizing 用当时的测算口径核一遍，别抄旧结论。你可以在 /tools/speed-test 和 /tools/quality-check 上跑自己的基线，得到的数字比任何二手结论都可靠。
许可证与迁移：上手前先花的两次十分钟
这两件事都只花十分钟，但省下的是后面几天甚至几周的返工。第一件是许可证，第二件是迁移成本。两件都不做就开工，出问题的概率不低。
- 权重许可证
- 决定模型能不能商用、能不能再分发，和框架无关
- 框架许可证
- 决定你用的推理引擎本身能不能商用，和模型无关
- 量化格式复用
- 换框架时原来的量化文件能不能直接用，往往决定迁移是几小时还是几天
- 接口层可替换
- 把调用接口做成配置项，换框架就是改配置不是改代码
迁移成本主要在三处：量化格式能不能复用、调用接口要不要重写、显存配置要不要重算。把接口层做成可替换的，换框架就是改配置；否则每换一次都要动业务代码。什么情况下这两步可以直接跳过：如果只是本地跑个 demo 给自己看，不对外提供服务，那许可证和迁移都可以先放一放，别为了「将来可能要商用」把起步拖死。
一分钟决策表与落地步骤
把前面的判断收敛成一张表，对着自己的情况选一行，然后按落地顺序走一遍。
| 你的情况 | 优先方向 | 先别做什么 |
|---|---|---|
| 单人交互、想快点看到结果 | 从最省事的那条路起步 | 别一上来就搭服务端框架 |
| 单机、硬件窄、想塞更大模型 | 底层可控、量化支持全的那条路 | 别硬追高吞吐调度 |
| 多用户、要稳定吞吐、有运维 | 直接按服务端框架搭 | 别先用轻量方案再返工 |
| 负载形态还没定 | 留一层可替换接口 | 别把选型写死在业务里 |
落地顺序建议：先用小模型跑通链路，量出单请求延迟与显存占用，加并发压一遍，再决定是否换框架。到 /tools/speed-test 和 /tools/quality-check 做基线，比凭感觉调参靠谱得多。基线要记下来，换框架或改配置后拿同一套用例复测，才知道是真变好还是心理作用。
- 跑通链路：小模型加载、单请求返回正常
- 量基线：记录单请求延迟、显存占用、首字延迟
- 压并发：按目标并发数跑，观察排队与显存增长
- 再决策：基线不达标才换框架，达标就别折腾
常见问题
我只想在自己电脑上跑个模型玩玩，需要纠结这三个吗？
不用。单人交互式使用，选上手最快、模型管理最省心的那个就行，另外两个的优势在这个场景里基本体现不出来。等你遇到「多人同时用」「显存不够塞下想要的模型」「要长期常驻当服务」这三类问题之一，再回头看这篇的对照表。
为什么我按别人的配置抄，跑起来还是爆显存？
大概率是三处对不上：量化格式和框架不匹配、上下文长度设得比对方长、并发或批大小没对齐。显存占用是模型权重加缓存再加运行开销的总和，任何一项变了结论就变。建议按「模型规模→量化档位→缓存余量→并发」的顺序自己重算一遍，别直接抄数值。
选错框架了，换起来麻烦吗？
取决于你有没有把调用接口和框架绑死。如果业务代码里到处是对具体框架的调用，换一次要动很多地方；如果中间隔了一层统一的 HTTP 接口，换框架基本就是改配置再重测。另外量化格式不一定能平移，显存配置通常要重算，这两项预留出时间。
