很多人第一次本地跑模型，教程一会儿让你装 Ollama，一会儿又让你起 vLLM，看着像两个竞品，装完才发现命令行、模型文件、报错方式全不一样。这篇不评比谁强，只把两者的分工讲明白：一个是给单人用的省事入口，一个是给多人并发用的服务引擎，顺带给你一份按场景对号入座的判断顺序。
第一次本地跑模型的人，大概率会被教程绕晕：这篇让你装 Ollama，那篇让你起 vLLM，看着像两个互斥选项。装完才发现命令行不一样、模型文件放的位置不一样、报错方式也不一样。其实它们压根不是同一条线上的对手，一个解决「怎么让模型跑起来省事」，一个解决「怎么让一堆请求同时进来还不卡」。
这篇不评比谁强，只把分工讲清楚，再给一份按场景对号入座的判断顺序。看完你至少能回答三个问题：我这台机器该先装哪个、什么时候两个都得留、以及拿不准时先去哪查。
各是什么：一个是服务引擎，一个是使用入口
vLLM 的定位是推理服务引擎。它关心的是当多个请求同时打进来时，怎么把显存和算力尽量吃满，对外通常暴露的是一套标准 API 服务，方便被应用或团队调用。它更像后端服务端里的一个组件，你不太会「随手打开它聊两句」。
Ollama 的定位是单机使用入口。它把拉模型、存模型、切换模型、起一个本地接口这几步打包成一条命令，重点是让人几分钟内看到输出。它更像个人工作台上的一个工具，日常试提示词、连本地知识库，用它起步阻力最小。
- 推理服务引擎
- 把模型加载并驻留，按请求调度算力，核心指标是并发下的吞吐和延迟
- 使用入口
- 把模型下载、管理、起接口做成顺手操作，核心指标是你多久能跑出第一个输出
- 并发
- 同一时间有多个请求在等结果，人一多，调度方式的差别就被放大
两者都会起一个本地 HTTP 接口，所以经常被摆在一起比。但结构上，vLLM 更靠近生产服务端，Ollama 更靠近个人工作台。想先把这些术语对齐，可以到 /ai-dict/category/infra 把推理服务相关的词过一遍，术语统一了，后面看文档会顺很多。
什么场景归谁：按并发、按人来分
最可靠的切分维度是「同一时间谁在用」。一个人坐在电脑前反复调提示词、验证效果、喂给本地知识库，这类场景优先考虑 Ollama 这种省事入口，不用上来就想配置参数。
反过来，如果接口要对外开放、要给团队用、要接进某个应用，或者要求同一时间稳稳撑住一批请求，那就得往 vLLM 这类引擎方向走。这不是谁更高级的问题，是负载形态决定了工具形态。
- 单人本地试模型、调提示词、做原型验证：优先省事入口，先跑起来再说
- 多人共用同一台机器、要给应用提供接口：优先服务引擎，稳定性和并发是刚需
- 先验证再上服务：用入口把模型和效果定下来，再换引擎去扛流量，是常见的两段式
- 偶尔跑一次、用完就关：没必要为了这点负载折腾调度参数
- 接口要长期挂着、有人天天调用：得有人负责重启和看日志，这时简单入口反而更稳
有不适用的情况：如果机器本身显存放不下目标模型，纠结选哪个框架属于把顺序搞反了——先解决能不能加载，再谈跑得好不好。判断模型和显存的匹配关系，可以在 /models/deploy 对一遍再决定。
选型动作：三步对号入座
- 第一步，问并发同时只有你一个人用，优先省事；要接应用或多人共享，优先服务能力。先把这个答案写下来，后面两步都受它约束。
- 第二步，问模型确认要跑的那一档权重有没有对应的加载支持。权重格式或量化档位不匹配时，框架再顺手也起不来，这一步不通就地解决，别硬换框架。
- 第三步，问运维谁来重启、谁看日志、出问题谁排查。没人管长期服务的话，简单入口是更稳的选择，宁可牺牲一点并发能力。
| 判断维度 | 偏向省事入口 | 偏向服务引擎 |
|---|---|---|
| 同时使用人数 | 基本只有自己 | 多人或应用调用 |
| 接口是否需要长期挂着 | 不需要，用完即关 | 需要，得有人值守 |
| 是否要先验证模型选型 | 先验证效果再谈性能 | 模型已经定下来，要扛量 |
| 机器与显存余量 | 够不够先加载再说 | 有余量才谈调度和并发 |
三步都走完还是拿不准，就去 /models/deploy 把参数量、量化档位和显存占用的关系过一遍，再回头看框架，比先选框架再找模型省事得多。
跑起来之后：先量基线再谈优化
不管先用哪个，第一步都是量基线：这台机器在当前模型上的首字延迟、生成速度、连续跑一批请求时的表现。没有基线，后面改任何参数都不知道是变好了还是变差了。
调参方向两家侧重不同。省事入口那边，常见的是显存占用、模型档位、上下文长度；服务引擎那边，更多是并发数、显存利用率和批处理相关参数。别拿一个框架的观察结果去推另一个框架能撑多少并发，两者调度方式不一样。
- 先固定一个模型、一段固定输入，反复跑，把基线记录下来
- 一次只改一个参数，改完再跑同一段输入做对比
- 换框架之后重新量，不要沿用旧框架的数字
- 把当时用的模型档位、上下文长度一并记下，否则数据没法复现
想快速量一条接口延迟，可以用站内的 /tools/speed-test 起一条自己的基线记录，比手动掐表可靠。至于当前各家接口的实际价格、不同档位模型的实测表现，这类数字会变，一律到 /price-watch 和 /rankings 核对当时的口径，别拿旧截图当依据。
选框架之前先想清楚谁在用、要撑多久，比先装哪个都重要。下一步把你的并发人数、机器显存和目标模型找齐，去部署资料页对一遍显存占用，再回到这三步判断，基本就能定下来先装哪个。→
常见问题
vLLM 和 Ollama 是竞争关系吗，只能留一个吗？
不是竞争关系，很多人两个都装。Ollama 用来快速试模型和本地日常调用，vLLM 用来对外提供稳定服务。小团队常见的做法是先 Ollama 验证，再换 vLLM 上并发，两套模型文件分开存就行。
我只有一张消费级显卡，是不是用不上 vLLM？
不一定。单卡也能跑 vLLM，只是它的优势主要体现在多请求并发上，单人低频使用感受不到差别，反而多了一层服务配置。如果你的使用形态就是一个人偶尔问几句，先用简单入口更划算。
为什么同一个模型，两个框架跑出来速度不一样？
因为它们对显存的调度方式和批处理策略不同，同一张卡上能塞多少请求、显存怎么分配都不一样。这不是谁跑错了，而是设计目标不同。想确认差异有多大，到 /tools/speed-test 用同一提示词各测一轮最直接。
