Ollama与VLLM部署实战：Qwen3-0.6B本地化部署指南

在本地跑通一个大模型Demo，和把大模型部署成生产级服务，是两件完全不同的事。前者只需要用 transformers 加载权重、调用 model.generate 生成文本，后者却要回答一系列工程问题：显存怎么花、服务怎么暴露、并发怎么扛、部署代码能不能少写几行。本文结合 B 站教程内容，梳理大模型本地化部署的目标与工具选型，并给出使用 VLLM 部署 Qwen3-0.6B 的实战路径。

从Demo到生产：为什么本地调用脚本不够用

上节课演示的调用脚本，本质是用 ModelScope 或 transformers 加载分词器与模型，实例化后传入一句话完成文本生成。这套流程有个明显局限：它只能运行在模型权重所在的那台服务器上，代码与模型强绑定。

它需要接受各式各样用户的一些请求

生产环境下，LLM 要接受来自多个服务器的请求，代码文件和模型部署位置往往不在同一台机器上——代码在 server1，模型在 server2 是常态。此时需要的是一个对外暴露端口、通过通用 HTTP 协议通信的模型服务，而不是一段本地推理脚本。

Transformers 与 model.generate

Hugging Face 的 transformers 是目前最主流的模型加载与推理库，它统一了分词器（tokenizer）、模型权重和配置文件的加载接口，几行代码即可完成「加载-编码-生成-解码」的完整链路。model.generate() 是其中的自回归文本生成入口，内部封装了贪心搜索、beam search、采样（top-k / top-p / temperature）等解码策略，并支持 max_new_tokens、do_sample 等参数控制输出。

但 model.generate 的定位是「单次推理调用」而非「服务」：它没有请求排队、批处理调度、并发连接管理、流式返回等能力，也不暴露网络端口。每个请求都要独立跑一遍前向计算，GPU 利用率低。这正是它适合本地验证、却难以直接支撑生产的原因——生产需要的是把推理能力包装成一个可被多客户端并发访问的服务，而非一次函数调用。

大模型部署的四个核心目标

教程把部署目标归纳为四个维度，这四个维度也构成了后续工具选型的评判标准。

目标一：性价比高的显存占用

第一方面的话

部署不是显存越小越好，也不是把全部参数塞进 GPU 就万事大吉。全量参数上显存推理效果最好，但显存开销最大；全部放 CPU 最省显存，但推理速度慢到无法接受。真正的目标是找到显存占用与推理速度之间的平衡点，在费用核算的前提下做部署方案设计。这是面向生产的模型应用开发绕不开的前置环节。

目标二：更快更便捷的部署方式

理想的部署方式是一两行代码搞定，而不是写一堆代码再做各种调试。统一、稳健的 API 能覆盖不同类型模型的部署需求，部署效率本身就是竞争力。

目标三：扛住高并发

生产级应用中同时请求模型服务的用户可能达到几十上百个。哪种方案能扛住更高的用户并发，哪种方案就更有优势。

目标四：服务可被广泛访问

那么这里就要求

模型服务需要对暴露端口，只要网络连通，无论请求方是手机还是另一台服务器，都能通过通用的 HTTP 协议调用。协议越基础通用，接入成本越低。

显存与推理速度的权衡：量化与 KV Cache

部署中「显存怎么花」主要由两部分构成：模型权重本身，以及推理时产生的 KV Cache。权重方面常见的折中手段是量化——把 FP16 权重压缩成 INT8 或 INT4，显存可降至原来的 1/2 或 1/4，代价是精度与部分推理速度的损失。KV Cache 则随并发数和上下文长度线性增长，在长文本、高并发场景下往往比权重更吃显存。

因此「性价比高的显存占用」不是单纯追求最小显存，而是综合考虑量化精度、批大小、最大上下文长度后的配置调优。Qwen3-0.6B 这类小模型权重仅约 1-2GB，显存压力主要来自 KV Cache 与并发，正好适合练习这些调参环节。

Ollama与VLLM：两种部署路径的定位差异

围绕上述目标，本地部署工具大致可以分为两类思路。

Ollama 走的是轻量与便捷路线，安装后即可拉取模型并启动服务，适合个人开发者快速验证、本地调试与轻量应用场景，部署体验接近「一两行命令解决」。

VLLM 走的是高吞吐与生产服务路线，核心优势在于推理调度与显存管理，面向的是需要扛并发、需要稳定 API 服务的工程场景。教程选择 VLLM 来部署 Qwen3-0.6B，正是因为它更贴近生产部署的目标。

这个就是就是大模型在做应用开发

两者的取舍本质上是部署目标的取舍：如果只是本地跑通、快速看效果，Ollama 更顺手；如果要对外提供服务、考虑并发与显存效率，VLLM 更合适。实际项目中两者并不互斥，开发阶段用轻量工具验证，上线阶段切换到生产级方案是常见做法。

VLLM 的核心机制：PagedAttention 与 Continuous Batching

VLLM 之所以能扛高并发，关键在于两项技术。其一是 PagedAttention，它借鉴操作系统虚拟内存分页的思路，把 KV Cache 切分成固定大小的 block 进行非连续存储，从而大幅减少显存碎片、提升显存利用率，让同样显存能容纳更多并发序列。其二是 Continuous Batching（连续批处理），传统批处理要等整批请求全部生成完才释放资源，而 VLLM 在序列级别动态调度，某个请求一结束就立刻插入新请求，显著提高吞吐。

这两项机制共同解释了为什么 VLLM 在「显存性价比」和「高并发」两个目标上优于朴素的 transformers 推理。理解这一点，也就理解了 VLLM 与 Ollama 的定位分野：前者是面向吞吐优化的生产级推理引擎，后者更侧重开箱即用的易用性。

使用VLLM部署Qwen3-0.6B的实战要点

选择 0.6B 量级的 Qwen3 模型做部署练习，好处是显存门槛低，可以在单卡上完整走通服务启动、接口调用、并发验证的流程，把注意力放在部署链路本身而非硬件资源上。

实战中需要关注的几个环节：模型权重的本地准备与路径配置；启动 VLLM 服务并确认端口对外暴露；用 HTTP 请求验证服务可用性；以及在多请求场景下观察服务的响应表现。这套流程走通后，换成更大的模型或更复杂的业务接口，部署结构基本不变。

需要提醒的是，部署方案的选择始终由业务目标倒推。显存预算、并发量级、调用方分布这三个问题想清楚，工具选型自然清晰；反过来先选工具再补需求，往往会在上线阶段返工。