本篇目标：装好 vLLM，跑起第一个生产级推理服务，理解 vLLM 的核心逻辑

---

vLLM 是什么？

一句话：把模型常驻显存，以高吞吐量为目标的生产级推理引擎。

和 Ollama 的「按需加载、用完就释放」不同，vLLM 的设计目标是：模型一旦加载，就一直占着显存，持续不断地处理请求，直到你手动关掉。

这听起来有点「霸道」，但这是故意的——因为 GPU 和显存之间的数据搬运是最大的性能损耗来源之一。vLLM 把模型常驻显存，就是为了省掉每次请求都要重新加载的开销，在高并发场景下吞吐量可以比 Ollama 高出数倍。

适用场景：

• 对外提供 API 服务（需要稳定高吞吐）
• 需要同时处理多个并发请求
• RTX 5090 / RTX 4090 / 多卡工作站
• 生产环境部署

不适用场景：

• 只是在本地偶尔跑一跑 → Ollama 更省事
• 显存很小（8GB 以下）→ 能跑但效率低
• 需要频繁切换不同模型 → Ollama 更灵活

---

第一步：安装

vLLM 的安装比 Ollama 稍复杂一点，主要因为它需要编译 CUDA 内核，但也不难，跟着走就行。

Windows：推荐用 WSL2

⚠️ vLLM 官方对 Windows 原生支持有限，建议在 WSL2（Windows 的 Linux 子系统）里跑，体验和性能都更好。

安装 WSL2（如果没有）：
打开 PowerShell（管理员），运行：

wsl --install

重启电脑，然后进入 Ubuntu：

wsl -d Ubuntu

验证 WSL2 能看到你的显卡（关键步骤）：

进入 Ubuntu 后，运行：

nvidia-smi

如果看到显卡型号和显存信息，说明 WSL2 已正确识别 NVIDIA 驱动，可以继续。

💡 如果 nvidia-smi 报错或找不到显卡，请回到 Windows 确认已安装 NVIDIA 驱动 for WSL2（不是普通的 Windows 显卡驱动），下载地址：nvidia.com/drivers，选择「GRD, Notebook」类别下的「NVIDIA Driver for CUDA on WSL」。

在 WSL2 里安装 vLLM：

# 更新包管理器
sudo apt update && sudo apt upgrade -y

# 安装 Python（需要 3.8+）
sudo apt install python3 python3-pip -y

# 安装 vLLM（这一步会从源码编译，需要 10~20 分钟）
pip install vllm

💡 为什么要这么久？ vLLM 里面有一段 CUDA 内核代码需要针对你的显卡型号现场编译，第一次安装会编译好，之后就快了。如果你用的是 RTX 4060/4090/5090，编译一般都能顺利完成；如果遇到报错，通常是 CUDA 版本不匹配的问题，看最后 FAQ 部分。

验证安装成功：

python3 -c "import vllm; print('vLLM 版本:', vllm.__version__)"

macOS / Linux

pip install vllm

Linux 用户如果有 NVIDIA 显卡，确保已安装 CUDA Toolkit。

---

第二步：启动你的第一个 vLLM 模型（单卡部署）

单卡部署（RTX 5090 示例）

vllm serve Qwen/Qwen2.5-14B-Instruct \
    --tensor-parallel-size 1 \
    --quantization fp8 \
    --max-model-len 8192 \
    --port 8000

参数解释：

参数	含义	推荐值
--tensor-parallel-size	用几张卡（单卡=1，双卡=2）	1 或 2
--quantization	量化精度：fp8（高性能）/ fp16（高精度）	RTX 5090 推荐 fp8
--max-model-len	最大上下文长度（token 数）	4096（省显存）/ 8192（完整上下文）
--port	HTTP 服务端口	8000

💡 RTX 5090 + Qwen2.5-14B + fp8 + max-model-len 8192：显存占用约 20~22GB，5090 的 32GB 显存妥妥够，还能留点余量跑并发请求。

RTX 4060 8GB 呢？
8GB 显存跑 14B 太勉强，建议跑 7B 模型：

vllm serve Qwen/Qwen2.5-7B-Instruct \
    --tensor-parallel-size 1 \
    --quantization fp8 \
    --max-model-len 4096 \
    --port 8000

⚠️ RTX 4060 跑 vLLM 不是最佳选择——显存太小，vLLM 的高吞吐优势发挥不出来。RTX 4060 更适合用 Ollama。

启动成功后会看到什么？

INFO:     Started server process [12345]
INFO:     Uvicorn running on http://0.0.0.0:8000

看到这行就说明服务跑起来了，API 地址是 http://localhost:8000。

---

第三步：API 调用（基础）

vLLM 的 API 格式和 Ollama 一样，都是 OpenAI-compatible：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"    # vLLM 不需要真实 key
)

response = client.chat.completions.create(
    model="Qwen/Qwen2.5-14B-Instruct",
    messages=[
        {"role": "system", "content": "你是一个专业的中文技术助手。"},
        {"role": "user", "content": "用一句话解释什么是量子纠缠"}
    ],
    temperature=0.7,
    max_tokens=200
)

print(response.choices[0].message.content)

---

理解 vLLM 的显存逻辑

这是 vLLM 和 Ollama 最大的区别，理解了这个你就知道什么时候该用它。

Ollama 的逻辑：按需加载

请求1来了 → 加载模型到显存 → 推理 → 释放显存
请求2来了 → 重新加载模型到显存 → 推理 → 释放显存
...

优点：显存不会一直占用，你可以随时换模型。
缺点：每次请求都要重新加载，多个并发请求无法同时复用同一份显存。

vLLM 的逻辑：常驻显存

服务启动 → 加载模型到显存（一直占着）
↓
请求1来了 → 直接推理（不重新加载）
请求2来了 → 直接推理（不重新加载）
请求3来了 → 直接推理（不重新加载）
...
↓
服务关闭 → 释放显存

优点：高并发下吞吐量极高，显存利用率稳定。
缺点：模型一直占着显存，其他任务用不了；换模型需要重启服务。

KV Cache 是什么？

vLLM 高性能的核心是 KV Cache——每次推理产生的中间结果（Key 和 Value 矩阵）会被缓存起来，下次处理相似上下文时直接复用，不用重新计算。

这就是为什么 vLLM 在长上下文、连续对话场景下特别快——KV Cache 命中率高，省了大量计算。

---

本篇小结

你做到了	说明
✅ 理解了 vLLM 的核心逻辑	常驻显存，高并发高吞吐
✅ 在 WSL2 里装好了 vLLM	Windows 推荐 WSL2 方案
✅ 单卡启动服务（RTX 5090）	Qwen2.5-14B fp8 示例
✅ API 调用	OpenAI-compatible，Python 示例
✅ 理解显存管理逻辑	KV Cache、按需 vs 常驻

---

下一步

• 想尝试多卡部署、压测性能、深度排障？→ 跳到第③篇进阶篇：[vLLM实战——进阶篇：多卡部署、压测与排障]
• 想完全不用命令行？→ 跳到第④篇：[LM Studio：5分钟尝鲜的正确姿势]

基础篇到此结束。如果你只是想跑起来试试，这些内容够了。如果想榨干显卡性能、做生产部署，继续看进阶篇。