企业官网建设流程全解析

最近做技术方案咨询时，被问得最多的一个问题就是：vLLM 和 Ollama 到底怎么选？问的人背景差别很大，有刚接触大模型、想在自己电脑上把模型跑起来试试的初学者，也有做产品要上线、需要给几十上百个用户提供稳定推理服务的开发者。这两个名字经常同时出现，中文社区里也都有大量教程，乍一看好像都能“把模型跑起来”，但细看会发现，它们解决的根本不是同一个问题。这篇我用实际使用中积累的经验，把两者的定位、原理、性能差距和选型逻辑一次讲透，顺便把在这两个框架上踩过的坑也列出来，方便你直接照着做决策。

1. 先把定位搞清楚：一个解决“跑起来”，一个解决“扛得住”

1.1 Ollama：把大模型变成“一键可用”的本地工具

Ollama 的目标非常明确——让一个没有深度机器学习背景的人，也能在两三分钟内把开源大模型跑起来。装完就是一行命令ollama run qwen2.5:7b，模型自动下载、量化格式自动匹配、API 自动暴露。它底层基于 llama.cpp 生态，主打 GGUF 这种量化友好的模型格式，对 CPU、内存和消费级显卡的适配做得非常到位。我在 Mac、普通 Windows 笔记本、甚至一些低配显卡机器上都跑过，基本就是“下载即用”的体验。

这个定位决定了很多设计细节：模型库集中管理、默认 5 分钟的 keep-alive 策略、通过环境变量控制并行度、支持 Modelfile 自定义推理参数。你不需要理解 KV Cache 是什么，不需要关心 CUDA 版本配对，不需要研究吞吐量怎么调优。它更像一个“模型管理工具 + 简易推理服务”的结合体，适合个人开发验证、本地离线使用、教学演示。用一个容易理解的比喻，Ollama 就是家用咖啡机：按键出咖啡，咖啡豆和研磨参数都封装好了，你不用也不该去拆开它。

1.2 vLLM：为了高吞吐和稳定服务而生的推理引擎

vLLM 的定位完全站在另一个方向。它不是一个“一行命令跑模型”的工具，而是一个高性能推理服务引擎，核心目标是在有限的 GPU 资源下，用尽可能高的吞吐量处理尽可能多的并发请求。它直接对接 Hugging Face 生态的模型权重，支持主流开源架构，内置了 PagedAttention、连续批处理、前缀缓存、投机采样、张量并行等一系列面向生产环境的优化手段。

在 vLLM 上启动模型服务，虽然也只是一条 Python 命令，但背后的行为完全不同：启动时会预分配显存、构建 CUDA graph、初始化调度器，你可以用一堆参数精细控制显存利用率、最大序列长度、并发序列上限、量化方式、并行卡数。它也许不是最适合快速体验的工具，但一旦你需要在多用户、高 QPS、长对话、多卡分布式这类真实生产场景里提供 API，vLLM 几乎是绕不开的选择。

继续用咖啡机的比喻，vLLM 更像是商用咖啡机：上手有门槛，需要理解水压、研磨度、维护周期，但出品稳定、出杯量大。很多人问“vLLM 是不是比 Ollama 更快”，这个问法本身就容易误导，因为两者的设计目标根本不在一个维度上。

1.3 核心区别：不是性能高低，而是“解决问题层次”不同

更准确的理解是：Ollama 在“把模型快速可靠地跑起来”这个层次上做得极其出色；vLLM 在“把模型作为生产级服务稳定地、高并发地跑起来”这个层次上是长期投入优化的主流选择。由于默认行为差异太大，直接比较一个数字意义不大。我把两者的主要差异列成一张表，后面再针对关键技术点逐个展开。

这张表只是宏观印象，下面来看原理层面为什么会有这些差异。

2. 从原理看差距：为什么一个像“家用工具”，一个像“调度系统”

2.1 底层引擎的不同：llama.cpp 生态 vs 独立推理引擎

Ollama 选择拥抱 llama.cpp 生态，这是它易用性占巨大优势的根本原因。llama.cpp 用 C/C++ 实现，核心思路是“尽量在普通硬件上把大模型跑起来”，通过 GGUF 格式和多种量化方案（q4_K_M、q5_K_M、q8_0 等）大幅降低模型体积和显存需求。这种设计对个人用户是福音。在 Ollama 里运行一个 7B 模型，默认选好量化等级，内存和显存压力远小于跑原版权重。

vLLM 则是一个从零构建的独立推理引擎，更多考量的不是“最弱的硬件能不能跑”，而是“GPU 是不是每一刻都被高效利用”。它默认使用 Hugging Face 格式的权重，因为这样可以和训练、微调工具链无缝衔接。虽然也能通过 AWQ、GPTQ、FP8 等量化方式获得显存优化，但这些方案通常需要额外的校准和转换成本，不像 GGUF 那样“下载即量化好”。这也是为什么同一个模型，你在 Ollama 和 vLLM 里跑的体验会明显不同——它们背后的技术路线就不同。

2.2 PagedAttention：显存管理的分页思路

大模型推理时会为每一条请求维护一份 KV Cache（用来缓存已经算过的那部分注意力键值），历史 token 越长，KV Cache 占用越大，而且这个内存是动态变化的。传统推理框架一般有两种做法：要么给每条请求预分配最大长度的显存，浪费严重，显存可能只有三到四成被真正利用；要么请求结束前死死占住不释放，并发一高就 OOM。

vLLM 引入的 PagedAttention，借鉴了操作系统虚拟内存分页的思路，把 KV Cache 切成固定大小的物理块，通过块表把逻辑上连续的序列映射到物理上不连续的显存块，按需分配、按需释放。这带来的直接收益是显存利用率大幅提升，同等显存下可以容纳更多并发序列。你可以把它理解成图书馆不再为每本书预留一整排书架，而是按页分配书架格子；书页之间虽然不连续，但有索引卡片把它们串起来，反而让书架的每一格都可能被用到。

Ollama 底层沿用 llama.cpp 的显存管理方式，模型切换策略和 KV 处理相对保守，更多依赖“量化模型体积小 + keep_alive 管理”来缓解压力。在单机单卡的个人场景下这不构成问题，但并发请求一多，显存碎片和预分配浪费就会让可承载的并发量明显下降。

2.3 连续批处理 vs 静态排队：吞吐量的分水岭

再说批处理。很多新手没意识到，GPU 推理要想把吞吐打上去，靠的是“同一时刻算多个请求”，而不是“一个请求算完再算下一个”。早期框架的做法是静态批处理：凑满 N 个请求组成一个 batch，算完一批再算下一批；如果中途有的请求短、有的请求长，短请求算完也只能等长请求一起结束，GPU 白白空转。

vLLM 的连续批处理把调度粒度从“请求”降到“迭代步”。每一步前向传播，调度器都会重新决定这个 step 里要算哪些序列：新请求来了，有空位就插进去；某个序列生成了结束符，下一个迭代就把它移除；输入阶段和生成阶段的序列也可以在同一步混编。这样 GPU 每一轮都在算“当前最该算的内容”，空闲很少。这也是 vLLM 在高并发下总吞吐特别稳的核心原因。

Ollama 也支持一定的批量推理，llama.cpp 本身有 batch 机制，Ollama 也提供了并行度相关环境变量。但从调度粒度和动态性来讲，它的设计目标毕竟不是“把每一毫秒 GPU 时间榨干”。在 Ollama 里开 10 个并发请求，会发现请求要么排队、要么整体变慢；同样的压力放到 vLLM 上，每个请求的延迟可能有波动，但整体吞吐通常要稳得多。这里也要诚实地说，标题里提到的“千级并发”不是指单张显卡上的一个 vLLM 进程就能做到，而是指 vLLM 作为推理服务引擎，可以通过多实例、多卡并行、前缀缓存等手段，为千级并发提供一个可扩展的底座。Ollama 的定位里基本没有这条路线。

2.4 前缀缓存、投机采样和分布式：生产场景的加分项

如果只是并发高，vLLM 还有几项能力让它在生产场景里更实用。第一是前缀缓存，多轮对话和带固定 system prompt 的请求会共享一段前缀，vLLM 可以复用这些前缀的 KV Cache，省掉大量重复计算。第二是投机采样，用一个更小的草稿模型先预测多个 token，再让目标模型一次性验证，生成速度有明显提升。第三是张量并行和流水并行，多张卡时能把一个模型切到多卡上，或者把不同层的计算分到不同卡上，为超大模型打开了空间。

这些特性在 Ollama 的个人使用场景里几乎用不上，也不是它应该补的方向。换句话说，vLLM 的“强”不只是表面上的性能数字，而是它把调度、显存、批处理、前缀、并行这些决定服务水平的东西都做了系统性的优化。拿它和 Ollama 比，相当于拿调度系统跟家用自动化工具比——两者都是好东西，但服务层次不同。

3. 实操记录：把两个框架都跑一遍

3.1 Ollama 快速上手：从安装到 API 调用

我仍然建议所有想入门的朋友先从 Ollama 开始，不是因为它最强，而是因为你不能在 10 分钟内看到一个模型真的跑起来，后面再强大的技术都跟你没关系。以 Linux 环境为例，一条脚本指令就能装完；Windows 和 macOS 有原生客户端，体验更简单。装完后执行ollama run qwen2.5:7b，第一次会下载模型，之后本地启动，直接进入交互式对话。

交互式对话背后其实是一个常驻服务进程，默认监听 11434 端口。你甚至不用进入交互界面，直接用 API 就能调用：

curl http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b", "prompt": "用一句话介绍什么是大模型"}'

更常见的做法是走 OpenAI 兼容接口：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}]}'

如果你只需要在代码里调用本地模型，这个接口基本可以无缝替换原来的 SDK 调用方式。我平时做原型验证的时候，甚至不需要改任何业务代码，只把 base_url 换成http://localhost:11434/v1就行。

Ollama 还有几个命令值得记住：ollama list查看本地模型；ollama ps查看当前加载的模型和显存占用；ollama cp复制模型做修改；ollama show查看模型信息。要自定义推理参数，可以写一个 Modelfile，比如设置 temperature 和上下文长度，然后用ollama create生成一个新的本地模型。这一步对只想微调行为、不想改动权重的人来说非常实用。

3.2 vLLM 部署：把显存当作需要规划的预算

vLLM 的安装多数人直接用 pip 装即可，但建议先确认 Python 版本和 CUDA 驱动满足要求，Linux 环境最顺；Windows 用户要折腾 WSL。装好之后，启动一个 OpenAI 兼容服务的方式大致如下：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

这段命令背后发生的动作很值得理解。--model指向一个 Hugging Face 格式的模型目录；--max-model-len决定你允许的最大上下文长度，直接影响 KV Cache 的容量预算；--gpu-memory-utilization 0.9表示让 vLLM 预占约 90% 的显存用于模型权重和 KV Cache，剩下 10% 留给 CUDA graph 以及其他零碎开销。

启动后同样可以用 curl 测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "/data/models/qwen2.5-7b-instruct", "messages": [{"role": "user", "content": "你好"}]}'

vLLM 冷启动一般比 Ollama 慢，因为要做模型加载、显存分配、CUDA graph 构建。7B 模型在一张普通显卡上大概 10 到 30 秒内可以就绪，大模型或者多卡时间更长。第一次启动如果看到 CUDA graph 相关报错，可以先加--enforce-eager关掉相关优化，把问题定位清楚再决定。启动后还有自带的/metrics端点，可以接入 Prometheus 看吞吐、排队时长等指标，这一点对生产很有用。

3.3 性能测试：不要凭感觉对比

我在帮别人做选型时，最反对直接拿一个 prompt 在两套环境里敲一遍，看谁打字快就下结论。性能对比必须控制变量并明确场景。同样的模型、同样的输入输出长度、同样的并发数，才有一点可比性。

简单测试可以用脚本并发打请求。一个最小思路是：准备几十个并发请求，每个请求带固定输入文本，统计所有请求完成所需的总时间和平均每个 token 的输出速度。可以直接用 Python 写，也可以直接用 hey、wrk、k6 这类压测工具。vLLM 的/metrics里有requests_total、generation_tokens_total、time_to_first_token等指标，我一般用这些做更长周期的观测。

以我手头常见环境（单张消费级显卡、7B 模型、中等输入长度）的经验来看：Ollama 单请求体验很好，首字延迟和生成速度都挺体面；一旦并发数拉到 8 到 16，请求排队和总完成时间就会明显变差，整体吞吐上不去。vLLM 在同样的并发压力下，单请求首字延迟略有增加，但整体吞吐可以稳定在数倍于前者的水平，随着并发继续拉高优势会更明显。注意这是经验值，不是 benchmark 结论，不同模型、不同上下文长度下差距会变化，但方向基本一致。

3.4 我的参数调优心得

Ollama 侧真正值得调的参数不多，但几个环境变量要记住：OLLAMA_NUM_PARALLEL控制一个模型最多同时处理的请求数；OLLAMA_MAX_LOADED_MODELS控制最多同时驻留几个模型；OLLAMA_KEEP_ALIVE控制模型在内存和显存里的保活时长，默认 5 分钟对反复测试可能不够，长任务前可以设大一点。如果并发上去了发现 Ollama 响应变慢，先看是不是这几个环境变量没设。

vLLM 侧优先调三个参数。一是--max-model-len，它决定 KV Cache 预算，设太大浪费显存、设太小长对话直接报错；二是--gpu-memory-utilization，一般 0.85 到 0.95 比较稳妥，不要顶到 1.0；三是--max-num-seqs，限制单 batch 内最多序列数量，避免极端并发下单请求延迟过高。有条件还可以开--enable-prefix-caching，固定 system prompt 或多轮对话场景收益明显。至于量化参数，我建议先跑 fp16 或默认精度，确认功能正常后再尝试 AWQ、GPTQ，省得混在一起排查问题。

4. 选型决策：到底怎么选

4.1 先回答六个问题

我总结了一个自查清单，帮你在五分钟内锁定方向。

1. 使用者是只有你，还是一组人？给自己玩，优先 Ollama；给别人提供 API，老实考虑 vLLM。
2. 预期并发是多大？并发个位数且不强调稳定，Ollama 完全够；要扛几十上百甚至更高并发，选 vLLM。
3. 模型文件是什么格式？GGUF 拿来就跑，选 Ollama；Hugging Face 权重、要做精细控制，选 vLLM。
4. 你的硬件是什么层次？消费级单卡、Mac、CPU 环境，Ollama 更省心；有多卡、要跑大模型，vLLM 的分布式能力是刚需。
5. 你打算投入多少运维精力？不想管环境、希望 10 分钟出结果，选 Ollama；愿意学习调度参数、做监控调优，选 vLLM。
6. 后续会不会接到生产服务里？哪怕今天只是 Demo，如果明天就要接 API，直接从 vLLM 起步可能更划算。

这个清单不是教条，而是一个提醒：选型失败往往不是因为工具不好，而是因为对场景的预判和工具定位不匹配。

4.2 场景对照表

为了决策更直观，我把常见场景列成一张表。

看完这张表你会发现一个规律：以“我”为中心的工具，Ollama 赢面大；以“系统”为边界的产品化服务，vLLM 赢面大。这不是性能高低决定的，而是工具的使命决定的。

4.3 有一种更聪明的用法：混合方案

很多团队最后实际跑通的方案，并不是二选一，而是两套都留。开发工程师本地用 Ollama 跑一个小模型，负责验证 Prompt 逻辑和业务代码；测试环境和生产环境用 vLLM 部署正式模型，承担真实并发。两者都暴露兼容接口，所以业务代码只需要切换 base_url，迁移成本很低。

需要注意两个细节。第一是模型格式：本地 Ollama 用的 GGUF 可能转不回 vLLM 需要的权重格式，转换后要在目标环境重新验证输出质量；第二是参数差异：两边对 temperature、top_p 等采样参数的解释基本一致，但 API 返回结构里有些字段不完全一致，业务尽量只依赖choices里的核心字段。另外，如果你只有一个后端服务，但希望同时负载本地实验和生产流量，也可以用一个路由层做分流。不过我不建议把问题搞复杂，绝大多数场景下，开发环境 Ollama、生产环境 vLLM，已经是很平衡的架构。

5. 常见问题与避坑实录

5.1 我实际踩过的坑

第一，vLLM 启动没多久就显存溢出。最常见原因是--max-model-len设得过大，或者--gpu-memory-utilization顶到 1.0，导致没有给 CUDA graph 留余量。我的习惯是先按 0.9 设，再用实际业务里最长的上下文需求反推max-model-len，别图省事拉满。

第二，Ollama 某次调用模型很慢，以为是坏了，其实是默认 keep-alive 把之前模型卸载了，重新加载要花时间。后来在自动任务里显式把keep_alive参数调大，问题就消失了。遇到“第一次请求明显变慢、后续变快”的情况，十有八九是保活机制在作祟。

第三，模型格式混用导致的困惑。我在本地用 GGUF 测得好好的，换到 vLLM 才发现不能直接加载，要么转格式要么重新下载对应权重。现在我的习惯是：涉及可能要上生产的模型，从一开始就下载对应权重；纯粹本地玩的模型，才用 GGUF。

第四，量化模型的精度陷阱。AWQ、GPTQ、GGUF 的 q4 量化确实能显著省显存，但在代码生成、数学推理这类高精度任务上，量化常常导致输出质量肉眼可见地下降。建议先用未量化的版本跑一遍正确性测试，再决定要不要为省显存接受精度损失，不要一上来就压到最低精度。

5.2 常见问题速查表

这个表可以说是我自己排查问题时的最小备忘，遇到类似现象的时候直接照着方向查，能省不少时间。

5.3 几个容易被忽视的小技巧

还想在这里补几个平时教程里不太会讲的细节。Ollama 如果跑在服务器上，建议不要把默认端口直接暴露到公网，加一层鉴权或者只在内网使用，因为它的默认 API 没有身份校验。vLLM 也类似，生产环境前面通常要放一个网关，负责限流、鉴权和负载均衡，vLLM 本身并不负责这些事。

另一个技巧是，如果你在 vLLM 里要频繁跑长 prompt 的批量评测，强烈建议开前缀缓存，并且把评测数据的公共提示词统一到最早的位置，这样缓存命中率会非常高。Ollama 侧没有对应的显式开关，但可以通过固定 system prompt 和尽量复用相同上下文来获得类似收益。

还有一个习惯问题：无论选哪个框架，模型文件本身都建议单独挂载在独立磁盘上，不要跟系统盘混在一起。大模型文件动辄几十 GB，系统盘空间被撑爆导致服务崩溃的案例，我见过不止一次。

我自己现在的工作流，基本就是一个混合架构：桌上电脑里跑着 Ollama，用来日常调试、检验 prompt 效果；生产环境跑着 vLLM，由监控和压测数据来驱动参数调整。这两个工具放在各自的位置上，都很好用。非要逼我用一句话总结，那就是：如果你还不知道模型怎么跑，选 Ollama；如果你的模型要跑给别人看，选 vLLM。至于更具体的数字和调参，还是要回到你自己的硬件和业务场景里去实测，别人的经验只能帮你少走弯路，不能替你踩坑。