vLLM与Ollama本地部署大模型：从脚本到生产的实战指南

为什么单机脚本调用无法满足生产需求

在上手大模型时，很多人的第一步是下载一个开源模型（如 Qwen），然后用 ModelScope 或 Transformers 加载分词器和模型，实例化 tokenizer 和 model，最后调用 model.generate() 完成文本生成。

model.generate() 是 Hugging Face Transformers 库提供的文本生成方法，底层实现了自回归解码（autoregressive decoding）过程：模型每次根据已有的 token 序列预测下一个 token，然后将新 token 拼接到序列末尾，循环往复直到满足停止条件。这一过程支持多种解码策略，包括贪心搜索（Greedy Search）、束搜索（Beam Search）、Top-k 采样和 Top-p（Nucleus）采样等。虽然接口简洁，但它是单线程、同步阻塞的调用方式，不具备请求排队、批处理（batching）和异步响应能力，因此无法直接用于多用户并发的生产场景。

这套流程确实能跑通，但它有一个根本性的局限：只能在模型下载所在的那台服务器上操作。

换句话说，这种方式本质上只是加载权重文件做了一个 demo 级别的生成演示，与真实的生产环境相去甚远。在实际业务中，一个大语言模型（LLM）需要接受来自各式各样用户的请求，这些请求可能来自多个不同的服务器；甚至你的业务代码和模型部署都不在同一台机器上——代码在 server1，模型在 server2，这种跨机部署的场景非常普遍。

大模型需要接受各式各样用户的请求

要解决这些问题，就需要把模型做本地化部署，将它从一个孤立的脚本变成一个可以被广泛调用的服务。

大模型部署的三大核心目标

在选择 vLLM 或 Ollama 这类具体工具之前，先要搞清楚大模型本地部署到底要解决什么问题。总结下来主要有两大方向：高效部署与可被访问。

显存与性能的平衡：追求最优性价比

高效部署首先体现在显存的性价比上。关键不是追求最小显存，也不是盲目堆砌最高配置，而是找到性价比最高的方案。核心是要平衡「显存占用与推理速度」和「模型性能」这两组关系。

如果把模型的全部权重参数都放到显存上做推理，效果无疑最好，但显存占用也最大。以 7B 参数的模型为例，FP16（半精度浮点数）下每个参数占 2 字节，仅模型权重就需要约 14GB 显存，加上 KV Cache（注意力层的键值缓存）、激活值和框架开销，实际需求通常在 16-20GB 以上。反过来，如果为了省显存把所有权重全塞到 CPU 上，虽然不占用 GPU，但推理速度会慢到几乎不可用。

为降低显存压力，业界广泛采用量化（Quantization）技术，如 GPTQ、AWQ、GGUF 等格式，将权重从 FP16 压缩到 INT8 甚至 INT4，可将显存占用降至原来的 1/2 到 1/4，代价是模型精度会有一定程度的损失。找到量化精度与模型表现之间的最佳平衡点，正是「显存性价比」这一命题的核心所在。因此，如何用合理的显存部署出最高效的模型，是本地大模型面向生产时必须考虑的成本问题，而部署方案正是其中的关键变量。

以合理的、性价比高的显存做部署

部署的便捷性：一两行命令搞定

第二个维度是部署的便捷程度。理想的部署方式应该是「一两行命令就能解决」，而不是写一大堆代码再反复调试。我们期望有统一、稳健的 API 接口，能够适配各类模型的部署需求。

当前业界已形成以 OpenAI API 格式为事实标准的接口规范，主要包括 /v1/chat/completions（对话补全）和 /v1/completions（文本补全）两个端点，请求和响应均使用 JSON 格式。vLLM 和 Ollama 都支持这一兼容格式，这意味着原本为 OpenAI 编写的客户端代码，只需修改 base_url 指向本地服务地址，即可无缝切换到本地模型，无需改动业务逻辑。这种标准化大大降低了模型迁移和多模型切换的工程成本。

统一而稳定的部署接口，可以大幅降低上手门槛和后期维护成本。

部署前需要费用核算

高并发承载能力

第三个维度是并发能力。在生产级应用中，同时请求模型服务的用户可能非常多——从几个到几十上百个用户同时发起请求都很常见。能够扛住更高并发量的部署方案，显然更具竞争力。

高并发处理能力的关键技术之一是 Continuous Batching（连续批处理）。传统的静态批处理（Static Batching）要求一批请求中所有序列都生成完毕后才能处理下一批，导致短序列请求被长序列拖慢，GPU 计算资源大量空转。Continuous Batching 则允许在每个解码步骤动态地加入新请求、移除已完成的请求，使 GPU 始终保持高利用率。这一机制配合高效的显存管理，可以在单张 GPU 上同时服务数十甚至上百个并发请求，吞吐量相比逐条推理可提升一个数量级。

模型服务化：让部署的模型可被外部访问

部署的另一大核心目标，是让模型「能被大家访问到」。这要求我们部署的不再是一段本地脚本，而是一个真正的模型服务（Model Server）。

在工程实践中，启动一个服务后，它会对外暴露一个端口（比如 8000、9000 等）。一旦端口暴露出来，只要网络互通，来自任意位置的用户都可以访问这个服务。无论请求方是手机、client server1 还是 client server2，服务端都不需要关心具体来源，只要双方遵循 HTTPS 等通用协议，就能调用模型。

部署的模型能被大家访问

这种服务化的设计，正是解决「跨机部署」「多用户并发请求」等问题的根本思路。模型服务化后，通常还需要考虑负载均衡、健康检查、自动重启等运维层面的配套能力，以保障服务在生产环境中的稳定性和可用性。

vLLM 与 Ollama 对比：两条主流本地部署路线

基于上述目标，业界形成了几套成熟的大模型本地化部署方案，其中 vLLM 和 Ollama 是最具代表性的两个工具，它们分别面向不同的使用场景。

vLLM：面向生产的高性能推理引擎

vLLM 是一个专注于高吞吐量、高并发的大模型推理框架。它通过 PagedAttention 等核心技术显著提升了显存利用率和推理速度，非常适合生产环境下的高并发请求场景。

PagedAttention 是 vLLM 团队在 2023 年提出的核心创新，灵感来源于操作系统的虚拟内存分页管理机制。在传统 Transformer 推理中，每个请求的 KV Cache 需要预先分配一块连续的显存空间，由于序列长度不可预知，系统往往按最大长度预分配，导致大量显存碎片和浪费，实际利用率有时不足 50%。PagedAttention 将 KV Cache 拆分成固定大小的「页」（block），按需动态分配，不同请求的页可以在物理显存中不连续存放，通过页表映射实现逻辑连续。这一机制使显存利用率提升到接近 100%，直接带来 2-4 倍的吞吐量提升，是 vLLM 在高并发场景下远超朴素实现的关键原因。

vLLM 还原生实现了 Continuous Batching，配合 PagedAttention 可以在单张 GPU 上同时服务大量并发请求。当你需要同时服务大量用户、追求推理性能与显存性价比的最优平衡时，vLLM 往往是首选方案。

Ollama：零门槛的本地大模型部署工具

Ollama 的定位更偏向「开箱即用」。它把模型的下载、加载、服务启动封装得极为简洁，真正做到了几行命令就能在本地跑起一个模型服务，并对外暴露标准 API。

Ollama 底层基于 llama.cpp 构建，后者是一个用纯 C/C++ 实现的 LLM 推理框架，支持在 CPU、Apple Silicon、CUDA GPU 等多种硬件上高效运行。Ollama 默认使用 GGUF（GPT-Generated Unified Format）模型格式，这是 llama.cpp 生态定义的二进制格式，将模型权重、分词器、元数据统一封装在单个文件中，支持多种量化级别（如 Q4_K_M、Q5_K_S、Q8_0 等）。这种一体化设计使 Ollama 无需额外安装 Python 环境或深度学习框架，真正做到了下载即用。

不过，由于 llama.cpp 主要针对单用户或少量并发优化，Ollama 在高并发吞吐量上通常不及 vLLM。对于希望快速验证想法、注重数据隐私、想在本地体验大模型的开发者来说，Ollama 是理想的入门工具。

小结

从单机脚本到服务化部署，是大模型从「玩具」走向「生产」的关键一步。理解部署的三大核心目标（显存性价比、便捷性、高并发）以及服务化的核心思路（对外暴露端口、遵循通用协议），能帮助你在面对 vLLM、Ollama 等工具时做出更合理的选择。

结合 Qwen 等优秀开源模型，用 Ollama 快速起步验证、用 vLLM 扛住生产级高并发压力，再配合纯本地部署带来的数据隐私优势，普通开发者也能构建出既好用又可靠的大模型应用。