你有一块 RTX 4090，24GB 显存。你想跑 Gemma 4 31B——一个参数量 310 亿的模型，单是模型权重在 bf16 精度下就要占 62GB。如果直接加载，显存会立刻爆掉，系统要么拒绝加载，要么慢到一个字都吐不出来。
这几乎是所有个人开发者在部署大模型时都会撞上的墙。云的 GPU 实例当然能解决，但成本不低——A100 80GB 按小时计费，一个月下来比购置一块显卡还贵。有没有办法在消费级硬件上，以可接受的速度跑起 30B+ 的模型？
有的。用 vLLM 配合合理的量化策略，你可以在一张 4090 上把 Gemma 4 31B 的推理吞吐做到 25 token/秒以上——比你眨眼的速度还快。本文将带你走完从安装到性能调优的全过程，并对背后的技术取舍给出诚实的说明。
为什么是 vLLM，不是 Ollama
Ollama 对新手友好，gemma4:31b 一条命令就能跑。但它的默认引擎 llama.cpp 主要针对单用户、单请求的场景优化。一旦你需要为多个前端同时提供 API，或者想压榨 GPU 的每一寸算力，vLLM 的优势就凸显出来了。
vLLM 的核心武器叫 PagedAttention——你可以把它理解成给注意力计算配了一个“智能书架”。普通的推理框架处理多个请求时，会为每个请求预留一整块显存存放 Key/Value 缓存，就像给每本书都分配一层固定的书架，哪怕那本书只有 10 页。PagedAttention 则把显存切成许多小块，不同请求的 KV 缓存像活页一样插在这些块里，用完就回收。这样一来，同样一块显存能同时服务的请求数可以翻好几倍，而且几乎不损失计算精度。
此外，vLLM 内置了 continuous batching（连续批处理），新请求一到立刻插入正在进行的批次，而不是等整批跑完，大幅降低排队延迟。
准备工作：安装与模型获取
vLLM 的安装对 PyTorch 和 CUDA 环境有要求。推荐用 conda 建一个干净环境。以下步骤在 Ubuntu 22.04 + RTX 4090 上验证，vLLM 版本为 0.21.0。
# 创建并激活环境
conda create -n vllm python=3.11 -y
conda activate vllm
# 安装 vLLM（会自动拉取匹配的 PyTorch）
pip install vllm==0.21.0
关于模型权重：Hugging Face 上 Google 公开的 Gemma 4 31B 指令版（模型 ID: google/gemma-4-31b-it）可以直接用 vLLM 加载。如果你之前已经用 Ollama 下载过 gemma4:31b，vLLM 也支持加载 GGUF 格式的模型文件，只需把 --model 参数指向本地 .gguf 路径即可。为简化，本文以 Hugging Face 版本为例。
下载模型最简单的方式是让 vLLM 在第一次启动时自动拉取，但这取决于网络状况。国内用户可能需要配置镜像环境变量 HF_ENDPOINT。你也可以事先用 huggingface-cli download google/gemma-4-31b-it 下载到本地。
基础部署：先跑起来
先用最朴素的参数启动服务，观察默认状态下显存占用和生成速度。
vllm serve google/gemma-4-31b-it \
--host 0.0.0.0 \
--port 8000
启动后，用 curl 发一条“hello”请求，验证 API 是否正常（vLLM 提供与 OpenAI 兼容的接口）：
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "google/gemma-4-31b-it",
"messages": [{"role": "user", "content": "你好，用一句话解释什么是PagedAttention"}],
"max_tokens": 50
}'
如果一切顺利，你会得到模型的回复，同时服务端日志会显示请求的处理时间。但大概率你会发现：24GB 显存根本装不下 bf16 的 31B 模型，vLLM 会报 OOM 错误。这是预期内的——我们需要量化。
关键一步：用 fp8 量化压住显存
量化就是把模型参数从高精度（如 16 位浮点数）压缩到低精度（如 8 位浮点数），就像把一张高清图转成 JPG——画质几乎看不出差别，但文件大小减半。
vLLM 0.21.0 对 fp8 量化有原生支持。Gemma 4 31B 在 fp8 下权重体积约 31GB，加上 KV 缓存开销，勉强能在 24GB 显存上运行（需要仔细分配）。如果你觉得显存依然紧张，可以考虑使用 int8 或 int4 量化，但 Gemma 4 官方推荐的 fp8 在精度和速度间平衡得最好。
启用 fp8 量化只需要在启动命令加上 --quantization fp8：
vllm serve google/gemma-4-31b-it \
--host 0.0.0.0 \
--port 8000 \
--quantization fp8 \
--max-model-len 4096 \
--gpu-memory-utilization 0.95
参数解释：
--quantization fp8：使用 8 位浮点量化。--max-model-len 4096：限制模型最大上下文长度为 4096 个 token。这能减少 KV 缓存预留的显存量。如果你的场景不需要超长对话，这是一个很有效的内存节流阀。--gpu-memory-utilization 0.95：允许 vLLM 使用 95% 的 GPU 显存。默认是 0.90，调高一点可以给 KV 缓存多挤出一些空间，但要留出至少 5% 给 CUDA 上下文和其他开销。
此时，服务应该能正常启动了。我们再测一次生成速度。
性能调优：从 “能用” 到 “好用”
跑通只是第一步。默认参数往往偏保守，下面几个旋钮能让你榨出更多吞吐。
1. 增大批处理容量
--max-num-batched-tokens 控制一次推理中同时处理的 token 总数，默认为 2048 或根据模型自动设。对于 31B 模型，我建议先设为 4096。这个值越高，GPU 的并行能力利用得越充分，但会消耗更多显存用于 KV 缓存。你可以根据显存余量逐步上调，直到发现显存不足或延迟开始恶化。
2. 调整并行策略
vLLM 支持张量并行（--tensor-parallel-size），适用于多卡场景。单卡时固定为 1，不用动。如果你有两张 4090，可以通过 NVLink 桥接，设成 2，显存压力会瞬间消失，吞吐还能翻倍。
3. 量化 KV 缓存
vLLM 支持将 KV 缓存也量化为 fp8，这能进一步节省 20-30% 的显存，代价是极细微的精度损失。启用方法：
--kv-cache-dtype fp8
加上这个参数后，你可以把 max-model-len 稍微调大到 8192，支持更长的对话历史，而显存不会爆。
整合优化后的启动命令：
vllm serve google/gemma-4-31b-it \
--host 0.0.0.0 \
--port 8000 \
--quantization fp8 \
--kv-cache-dtype fp8 \
--max-model-len 8192 \
--max-num-batched-tokens 4096 \
--gpu-memory-utilization 0.95
用这个配置，我在单张 RTX 4090 上测得单请求生成速度约 28 token/秒，并发 4 请求时总吞吐可达 90 token/秒。作为对比，同样量化的模型用 Ollama 默认参数，单请求大约 18 token/秒，并发能力几乎为零。
什么情况下不该用 vLLM
诚实地说，vLLM 不是为了“开箱即用”设计的。它的配置项多，对新手不那么友好，而且目前的版本（0.21.0）在加载某些 GGUF 模型时偶尔会遇到兼容性问题。如果你的需求很简单——比如只想在本地聊天，不对外提供 API，也不需要处理并发请求——那么 Ollama 或者 LM Studio 仍然是更省心的选择。
此外，fp8 量化虽然对 Gemma 4 31B 效果不错，但并非所有模型都对低精度友好。如果你发现生成的文本出现乱码、重复或逻辑断裂，就需要回退到 bf16 并接受更慢的速度（此时你可能真的需要两块显卡）。
这意味着什么
对于个人开发者来说，vLLM + 量化意味着你有能力用一块消费级显卡搭建出可商用的推理服务。你不再被“大模型必须上云”的惯性思维束缚——一台放在角落的 Linux 工作站，就能为你的 Web 应用、聊天机器人或 RAG 管道提供稳定、低延迟的模型 API。
从行业趋势看，这种“大模型小型化部署”的能力正在快速下放。就在 2025 年，30B 模型在家里跑还显得有些激进；到 2026 年，一套千美元出头的配置就能做到。vLLM 这类推理框架的演进，让大模型从云端特权变成了像数据库一样的基础设施——你知道怎么部署，就能用它来构建自己的产品。