企业官网建设流程全解析

最近这段时间，被问得最多的一个问题就是：“本地跑模型到底用 Ollama，还是直接上 vLLM？”还有人直接把 Ollama 当服务端用，结果并发一上来整个服务卡成幻灯片，回头又跑去折腾 vLLM，却被安装配置劝退。说实话，这两个工具我都长期用过，也踩过不少坑，选型这件事选错不是能力问题，是没搞清楚工具背后的定位差异。Ollama 的目标是让“一行命令跑模型”成为现实，vLLM 的目标是让推理服务在千级并发下依然稳定。这篇就把两个工具从原理、性能、场景到迁移路径全部拆开讲一遍，适合刚入门正在纠结的人，也适合已经上线但在犹豫要不要换框架的人。

1. 两个工具的“血统”不同，选型之前先看定位

很多人的第一个误区，是默认“只要能跑模型的工具，就都差不多”。其实 Ollama 和 vLLM 从设计基因上就是两种完全不同形态的东西，一个是个人工具箱，一个是生产级服务引擎。

1.1 Ollama：为“一个人”设计的模型管理器

Ollama 给我的第一印象是：它真正把“本地跑模型”这件事的门槛压到了最低。安装完以后，一条命令从模型仓库拉取模型，再一条命令直接进入对话，整个过程不需要手动装 Python 包、不需要理解权重格式、不需要纠结显存分配。它更像一个模型管理器加运行器，把“下载模型—运行模型—提供接口”整条链路都给你包好了。

底层走的是轻量 C++ 推理栈和 GGUF 量化文件格式，这让它在 CPU 上也能跑，GPU 显存不够时还能把部分层切到 CPU 上协同计算。对大多数普通用户来说，这种“不挑机器”的宽容度非常关键。

也正因为它的设计目标是把复杂度吃掉，而不是把性能榨干，Ollama 并没有做非常激进的并发调度优化。在并发一多的情况下，请求处理基本是“先到先服务”，后来的请求只能干等前面跑完。这不是 bug，而是它的定位决定了它不该对高并发负责。

1.2 vLLM：为“成千上万个请求”设计的推理引擎

vLLM 这个名字在圈子里火起来，是因为它从诞生起就奔着“服务端推理引擎”去的。它做的事情，简单说就是把一个开源模型变成一个高性能的在线推理服务，提供兼容主流大模型服务方 API 格式的接口，让应用端只需要改一行服务地址就能切换后端。

它最大的卖点集中在三个技术点上：PagedAttention 显存管理、Continuous Batching 连续批处理、以及 CUDA Graph 算子优化。这三个东西我在后面会详细拆，这里先记住一个结论：vLLM 花大量精力做的，是如何在一个 GPU 上同时喂给模型尽可能多的请求，并且让显存利用率最大化。

代价就是部署和配置门槛明显更高，需要你有一定的 GPU 环境、会处理 Python 依赖、理解显存参数。它不是一个“装完就能聊天”的工具，而是一个“需要调试和运维的服务组件”。

1.3 混淆的根源：跑模型和服务模型是两回事

有个类比我觉得特别贴切：Ollama 像家用电饭煲，vLLM 像中央厨房的商用蒸柜。两者都能把米饭做熟，但电饭煲服务的是三五口人的饭点，商用蒸柜要扛的是每天上千份出餐，内部结构、散热、产能、维护方式完全不在一个维度上。

对应到实际使用中，我见过两种典型的选型事故。第一种，有人用 Ollama 起了个模型，自己测了几次觉得响应挺快，就直接挂到公司内部服务上，结果几十个人同时用就开始排队超时。第二种，有人听说 vLLM 性能猛，非要在自己只有 6GB 显存的笔记本上跑十几个亿参数的模型，折腾一下午连服务都没起来，最后反过来怪框架难用。

这两类问题其实都指向同一个核心：选型之前，先搞清楚你是“一个人用”还是“一群人用”，是“跑起来验证想法”还是“稳定对外提供服务”。这两件事需要的工具从来就不一样。

2. 性能差距从哪里来：PagedAttention 与 Continuous Batching 深度拆解

既然要讲选型，就必须把 vLLM 为什么能扛高并发这件事讲透。很多人只知道 vLLM 快，但不知道它快在哪。其实它的优势不是单请求速度，而是多请求并发时的整体吞吐。

2.1 PagedAttention：把显存当内存页来管理

大模型推理的时候，显存里除了模型权重，还要存一份 KV Cache，也就是模型在生成过程中不断计算出的中间状态。请求越长、并发数越多，KV Cache 占用就越大，有时候比模型本身还吃显存。

传统方案的思路是给每个请求提前预留一整块连续显存，大小按“最大生成长度”来算。问题在于，不是每个请求都会生成到最大长度，很多请求生成几个字就结束了，预留出来的那大片显存就白白浪费了。并发一多，这种浪费会让 GPU 很快爆显存。

PagedAttention 的思路取了巧：它把显存切成一页一页的物理块，每个请求的逻辑 KV Cache 可以映射到不连续的多块物理显存上，按需分配，用完释放。这个思想跟操作系统虚拟内存管理一模一样，属于把成熟技术移植到了推理场景里。

带来的收益有两个：一是显存利用率大幅提高，二是同一个 GPU 上能容纳更大的 batch。batch 一大，并发吞吐自然就上去了。这就是 vLLM 在并发场景里拉开差距的第一个关键点。

2.2 Continuous Batching：GPU 永不空闲的秘密

第二个关键点是 Continuous Batching。传统批处理是每次取一批请求，整批跑完，再取下一批。在大模型生成场景里，同一个 batch 里每个请求的生成长度差别很大，有的请求几秒钟就结束了，有的要生成几百个 token，GPU 就得等着最慢的那个，期间算力全在空转。

Continuous Batching 的做法是在生成过程中动态调整 batch：某个请求生成结束了，立刻移出去，把新来的请求插进来，GPU 在每一步都在计算真实有效的 token，而不是陪着空转。

它对线上服务的价值非常直接：首 token 延迟降低、单位时间完成的请求数大幅提升、GPU 利用率保持高位。这两个技术叠加起来，才是 vLLM 敢于打出“千级并发”这张牌的根本原因。

2.3 Ollama 在性能上做了哪些优化

不能因为 Ollama 偏个人使用，就认为它没做性能优化。实际上它在“低门槛推理”这个方向上的优化做得非常好。

首先，GGUF 量化格式对显存的压缩能力很强。一个几十亿参数的开源模型，用 4bit 量化后，显存占用能压到几 GB 级别，很多消费级显卡都能跑。其次，它支持异构分层推理，GPU 装不下的层自动放到 CPU 上跑，虽然速度会慢一些，但至少能让模型在低配机器上运行起来。

这些优化解决的是“能不能跑起来”和“吃得下多大模型”的问题，而不是“能不能扛住大量并发请求”。再加上它的请求调度机制相对简单，默认情况下并发能力有限，所以一旦把它放到服务场景里，短板立刻显现。

2.4 一组压测数据：认识“吞吐”比“单请求速度”更重要

我手头没有那种绝对标准的基准测试报告，但自己在相同硬件、相同模型规模下做过对比压测，趋势非常有参考价值。先说明，数值会随显卡型号、模型大小、量化方式变化，重点看相对差距。

看这个表很明显：单并发情况下，两个工具的速度几乎拉不开差距，甚至有些人会觉得 Ollama 就够用了。但并发数一上来，差距就变成数量级。这就是为什么我说选型要看场景量级——你只测单请求快慢，根本测不出未来线上会踩的雷。

3. 不同场景下的真实体感：从个人调试到千级并发

技术参数说完了，回到真实使用体验。我自己在不同阶段、不同项目里分别重度用过这两个工具，体感上的差异比参数更直观。

3.1 个人开发场景：Ollama 为什么“香”

个人开发、本地调试、模型效果验证，这几个场景下 Ollama 的体验是无敌的。装完即用，拉模型、跑对话、开接口，整个过程几乎没有需要动脑的地方。

我平时做 RAG 知识库 demo、文本分类实验、摘要生成测试，都是先用 Ollama 起一个本地服务，快速验证模型效果和参数调优方向。它的模型管理也很好用，切换不同模型就像切应用一样简单，多版本、多量化方式都能轻松管理。

最关键的是，它允许你在不懂底层原理的情况下先把整个流程跑通，形成正反馈。对新手来说，这个“先跑起来”的体验非常重要。但你要记住它的边界：Ollama 适合人跟模型对话，不适合大量用户同时跟模型对话。

3.2 生产服务场景：vLLM 为什么“稳”

到了生产环境，我对 vLLM 的评价是“稳”。一旦配置好，它就像一个沉默的发动机，长期稳定输出。

启动一个服务通常长这样：

vllm serve <模型权重路径> \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 64 \ --tensor-parallel-size 1

这里几个参数值得好好说。gpu-memory-utilization是告诉 vLLM 能占用多少显存，max-model-len是请求上下文的最大长度，max-num-seqs是批次里最多同时处理的请求数，tensor-parallel-size是多卡并行时的卡数。这几个值直接决定了服务的吞吐和稳定性。

生产环境真正要说的另一点是：千级并发不是“启动一个 vLLM 就行”的。单实例 vLLM 能扛住的并发量级是有上限的，真正的千级并发链路通常是：客户端请求 → API 网关 → 限流与负载均衡 → 多个 vLLM 实例 → GPU 资源池。vLLM 在其中扮演的是最核心的“单引擎”，但整条链路还需要网关、多副本、监控来配合。

3.3 “中间态”场景：并发不高但也不是只有你自己

选型不是只有“一个人用”和“千级并发”两个极端，中间态其实更常见。比如你给团队内部做一个工具，几十个人用，峰值每分钟几百个请求，GPU 有一两张，这时候怎么选？

我的建议是先算清楚账：如果并发峰值不超过几十路，Ollama 加一个简单的网关限流也能撑住，前提是模型不要太大，显存够用。一旦观察到请求排队超过几秒、GPU 利用率打满、服务经常超时，就赶紧换 vLLM，别硬撑。

反过来，如果你明确知道未来半年会有明显增长，那干脆直接上 vLLM，一次配置到位，省得中途迁移。迁移本身虽然不复杂，但上线之后再做，总要搭上夜间维护和业务暂停的代价。

4. 选型决策框架与迁移实操：从 Ollama 平滑切到 vLLM

前面讲了那么多，最后落到实际操作。这一节我给出一套可以直接照做的决策框架，以及一套从 Ollama 平滑迁移到 vLLM 的完整路径。

4.1 一分钟决策表

先看一张速查表，帮你在 60 秒内做初步判断：

如果满足“本机演示、模型效果比较、个人开发、不追求高并发”，直接选 Ollama。如果满足“多人使用、公开服务、并发不稳定、需要长期运行、未来会扩量”，直接选 vLLM。

这个表格不能解决所有问题，但能帮你把“能不能跑”和“能不能扛”分开思考。

4.2 从 Ollama 迁移到 vLLM 的完整流程

第一步，确认模型格式。Ollama 拉下来的模型默认是 GGUF 格式，而 vLLM 更擅长加载原生权重和特定量化格式。建议迁移时从模型仓库直接下载原生权重，或者找转换为 AWQ/GPTQ 格式的版本，兼容性更好，部署更稳。

第二步，准备运行环境。装好 Python、CUDA 环境，然后用 pip 安装 vllm 依赖。装完后可以用命令行先确认版本，避免装了个空壳。

第三步，启动 vLLM 服务。用前面给的命令把模型服务拉起来，注意调整--gpu-memory-utilization和--max-model-len。启动成功后，接口会监听在默认端口上。

第四步，验证接口。用 curl 或者任意客户端发一个请求，确认返回正常。这一步能发现模型路径错误、tokenizer 配置不对等问题。

第五步，切换应用端。你的应用如果已经兼容主流大模型服务的 API 格式，只需要把接口地址改成 vLLM 的服务地址，其他代码基本不动。这一步我实际做下来，通常一小时以内能全流程跑通。

第六步，压测与调优。拿真实业务流量去打，观察 GPU 显存占用和请求延迟，微调max-num-seqs和gpu-memory-utilization。

4.3 部署 vLLM 时最容易踩的四个坑

坑一：显存利用率设置太高。gpu-memory-utilization拉满到 0.95 甚至 1.0，很容易在启动阶段就 OOM。建议从 0.80 开始往上试，留出余量给 CUDA 上下文和其他进程。

坑二：max-model-len 设太小。有些模型默认上下文长度较短，业务上需要长对话时，请求会被截断甚至报错。要根据你的业务场景，提前确认模型支持的上下文长度，再设置对应的max-model-len。

坑三：max-num-seqs 与显存不匹配。这个参数设太大，KV Cache 会把显存吃干；设太小，GPU 算力又喂不满。经验做法是从 32 或 64 起步压测，看显存占用曲线再调。

坑四：量化格式和后端不兼容。vLLM 对 GGUF 的支持程度和稳定性不如对 AWQ/GPTQ 等格式的支持，如果你有选择空间，优先用 vLLM 官方文档里明确验证过的量化格式，别自己造轮子。

4.4 双轨并用：本地调试用 Ollama，线上服务用 vLLM

很多人以为选了 vLLM 就必须抛弃 Ollama，其实完全可以双轨并行。我现在的习惯是：开发环境用 Ollama 快速起一个模型服务，验证功能、跑通逻辑，效率极高。测试和线上环境则用 vLLM 部署正式服务，专门应付性能和并发压力。

两者之间切换的成本极低，因为接口格式都兼容主流服务方 API，应用层只需要把服务地址改一下。这相当于把“快速验证”和“稳定生产”这两个需求分别交给了最合适的工具，互相不干扰。

5. 最后交代几句选型经验

见过太多人在选型上纠结到失眠，其实核心就是把两件事想清楚：你现在是什么量级，你未来可能是什么量级。如果只是自己试模型，Ollama 就是最舒服的起点；如果模型要变成服务、要被人调用、要在高负载下不崩，vLLM 才是正路。

我自己踩过几次坑之后，现在选型的习惯是先列一个清单：并发量预估、上下文长度、硬件显存、是否需要多卡、团队有没有运维能力。把这几个指标写下来，再对照文章里的决策表，答案基本就出来了。

最后一个小技巧：不要因为 Ollama 上手简单就低估它，也不要因为 vLLM 配置繁琐就放弃它。工具只有合不合适，没有绝对好坏。很多时候你纠结“选哪个”，可能只是因为你还没想清楚自己的场景到底需要什么样的服务能力。把场景量化清楚了，答案自然就浮出来了。