vLLM 快速入门：2026 年高性能大语言模型服务

vLLM 是由加州大学伯克利分校 Sky Computing Lab 开发的高性能、内存高效的大型语言模型（LLMs）推理和部署引擎。

凭借革命性的 PagedAttention 算法，vLLM 的吞吐量比传统服务方法提高了 14-24 倍，使其成为生产环境中 LLM 部署的首选。

什么是 vLLM？

vLLM（虚拟 LLM）是一个开源库，用于快速的 LLM 推理和部署，已迅速成为生产部署的行业标准。2023 年发布时，它引入了 PagedAttention，这是一种突破性的内存管理技术，显著提高了服务效率。

主要功能

高性能吞吐量：与使用相同硬件的 HuggingFace Transformers 相比，vLLM 的吞吐量提高了 14-24 倍。这种巨大的性能提升来自于连续批处理、优化的 CUDA 内核和消除了内存碎片的 PagedAttention 算法。

OpenAI API 兼容性：vLLM 包含一个内置的 API 服务器，与 OpenAI 的格式完全兼容。这使得从 OpenAI 迁移到自托管基础设施时无需更改应用程序代码。只需将 API 客户端指向 vLLM 的端点，即可无缝运行。

PagedAttention 算法：vLLM 性能的核心创新是 PagedAttention，它将虚拟内存分页的概念应用于注意力机制。而不是为 KV 缓存分配连续的内存块（这会导致碎片化），PagedAttention 将内存划分为固定大小的块，按需分配。这减少了高达 4 倍的内存浪费，并允许使用更大的批次大小。

连续批处理：与静态批处理（需要等待所有序列完成）不同，vLLM 使用连续（滚动）批处理。一旦一个序列完成，就可以立即将新序列添加到批处理中。这最大化了 GPU 利用率，并最小化了传入请求的延迟。

多 GPU 支持：vLLM 支持张量并行和管道并行，以将大型模型分布在多个 GPU 上。它可以高效地服务那些无法在单个 GPU 内存中运行的模型，支持从 2 到 8+ GPU 的配置。

广泛模型支持：兼容流行的模型架构，包括 LLaMA、Mistral、Mixtral、Qwen、Phi、Gemma 等。支持来自 HuggingFace Hub 的指令微调模型和基础模型。

在什么情况下使用 vLLM

vLLM 在以下特定场景中表现出色：

生产 API 服务：当您需要通过 API 为许多并发用户提供 LLM 服务时，vLLM 的高吞吐量和高效批处理使其成为最佳选择。运行聊天机器人、代码助手或内容生成服务的公司可以从其每秒处理数百个请求的能力中受益。

高并发工作负载：如果您的应用程序有大量同时用户发起请求，vLLM 的连续批处理和 PagedAttention 可以在相同硬件上服务更多用户，相比其他替代方案。

成本优化：当 GPU 成本是关注点时，vLLM 的优越吞吐量意味着可以用更少的 GPU 服务相同流量，直接减少基础设施成本。PagedAttention 的 4 倍内存效率还允许使用更小、更便宜的 GPU 实例。

Kubernetes 部署：vLLM 的无状态设计和容器友好架构使其非常适合 Kubernetes 集群。其在负载下的稳定性能和简单的资源管理与云原生基础设施集成良好。

不使用 vLLM 的情况：对于本地开发、实验或单用户场景，Ollama 提供了更好的用户体验和更简单的设置。vLLM 的复杂性在需要其性能优势的生产工作负载中是合理的。

如何安装 vLLM

先决条件

在安装 vLLM 之前，请确保您的系统满足以下要求：

• GPU：NVIDIA GPU，计算能力 7.0+（V100、T4、A10、A100、H100、RTX 20/30/40 系列）
• CUDA：版本 11.8 或更高
• Python：3.8 到 3.11
• VRAM：7B 模型至少 16GB，13B 至少 24GB+，更大模型至少 40GB+
• 驱动：NVIDIA 驱动 450.80.02 或更新

通过 pip 安装

最简单的安装方法是使用 pip。这适用于具有 CUDA 11.8 或更高版本的系统：

# 创建虚拟环境（推荐）
python3 -m venv vllm-env
source vllm-env/bin/activate

# 安装 vLLM
pip install vllm

# 验证安装
python -c "import vllm; print(vllm.__version__)"

对于具有不同 CUDA 版本的系统，请安装适当的 wheel：

# 对于 CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# 对于 CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

通过 Docker 安装

Docker 提供了最可靠的部署方法，特别是在生产环境中：

# 拉取官方 vLLM 镜像
docker pull vllm/vllm-openai:latest

# 使用 GPU 支持运行 vLLM
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

--ipc=host 标志对于多 GPU 设置非常重要，因为它启用了适当的进程间通信。

从源代码构建

对于最新功能或自定义修改，请从源代码构建：

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

vLLM 快速入门指南

运行第一个模型

使用命令行界面启动 vLLM 并加载模型：

# 下载并使用 OpenAI 兼容 API 服务 Mistral-7B
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM 会自动从 HuggingFace Hub 下载模型（如果未缓存），并启动服务器。您将看到输出显示服务器已准备就绪：

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

发起 API 请求

一旦服务器运行，您可以使用 OpenAI Python 客户端或 curl 发起请求：

使用 curl：

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "用一句话解释什么是 vLLM:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

使用 OpenAI Python 客户端：

from openai import OpenAI

# 指向您的 vLLM 服务器
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM 默认不需要身份验证
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="用一句话解释什么是 vLLM:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

聊天补全 API：

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "你是一个乐于助人的助手。"},
        {"role": "user", "content": "什么是 PagedAttention？"}
    ],
    max_tokens=200
)

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

高级配置

vLLM 提供了许多参数来优化性能：

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # 使用 95% 的 GPU 内存
    --max-model-len 8192 \            # 最大序列长度
    --tensor-parallel-size 2 \        # 使用 2 个 GPU 进行张量并行
    --dtype float16 \                 # 使用 FP16 精度
    --max-num-seqs 256                # 最大批处理大小

关键参数解释：

• --gpu-memory-utilization：使用多少 GPU 内存（0.90 = 90%）。更高的值允许更大的批处理，但内存峰值空间更少。
• --max-model-len：最大上下文长度。减少此值可以为更大的批处理节省内存。
• --tensor-parallel-size：将模型拆分到多少个 GPU 上。
• --dtype：权重的数据类型（float16、bfloat16 或 float32）。FP16 通常是最佳选择。
• --max-num-seqs：一个批处理中处理的最大序列数。

vLLM 与 Ollama 对比

vLLM 和 Ollama 都是本地 LLM 托管的热门选择，但它们针对不同的使用场景。了解何时使用每种工具可以显著影响项目的成功。

性能和吞吐量

vLLM 是为多用户场景下的最大吞吐量而设计的。其 PagedAttention 和连续批处理使得高效地服务数百个并发请求成为可能。基准测试显示，vLLM 的吞吐量比标准实现提高了 14-24 倍，比 Ollama 在高并发下提高了 2-4 倍。

Ollama 优化了单用户交互使用，专注于单个请求的低延迟。虽然它在多用户吞吐量上不如 vLLM，但为开发和个人使用提供了出色的性能，冷启动时间更快，空闲资源消耗更少。

易用性

Ollama 在简洁性上胜出。安装只需一个命令（curl | sh），运行模型只需 ollama run llama2。它包括一个模型库，包含针对不同硬件配置优化的量化版本。用户体验类似于 Docker – 拉取、运行、即可。

vLLM 需要更多的设置：Python 环境管理、CUDA 安装、对服务参数的理解以及手动模型指定。学习曲线更陡峭，但您获得了对性能优化的精细控制。这种复杂性在需要从硬件中榨取最大性能的生产部署中是合理的。

API 和集成

vLLM 提供了开箱即用的 OpenAI 兼容 REST API，使其成为现有应用程序中 OpenAI API 的即插即用替代品。这对于从云提供商迁移到自托管基础设施而不更改代码非常重要。

Ollama 提供了一个更简单的 REST API 和一个专用的 Python/JavaScript 库。虽然功能齐全，但不是 OpenAI 兼容的，需要更改代码以集成到期望 OpenAI 格式的应用程序中。不过，社区项目如 Ollama-OpenAI 适配器填补了这一差距。

内存管理

vLLM 的 PagedAttention 算法在并发请求中提供了卓越的内存效率。与简单实现相比，它可以使用相同 VRAM 服务 2-4 倍的并发用户。这直接转化为生产部署中的成本节约。

Ollama 使用适合单用户场景的简单内存管理。它根据活动自动管理模型加载/卸载，这对开发很方便，但不适合高并发的生产使用。

多 GPU 支持

vLLM 在原生张量并行和管道并行方面表现出色，可以高效地将模型分布在 2-8+ GPU 上。这对于服务大型模型（如 70B 参数 LLM）非常重要，这些模型无法放入单个 GPU 的内存中。

Ollama 目前的多 GPU 支持有限，主要适用于单个 GPU。这使其不太适合需要分布式推理的大型模型。

使用场景推荐

选择 vLLM 的情况：

• 需要为许多并发用户提供生产 API 服务
• 在云部署中优化每请求成本
• 在 Kubernetes 或容器编排平台中运行
• 需要 OpenAI API 兼容性以用于现有应用程序
• 服务需要多 GPU 支持的大型模型
• 性能和吞吐量是关键要求

选择 Ollama 的情况：

• 本地开发和实验
• 单用户交互使用（个人助手、聊天机器人）
• 快速原型设计和模型评估
• 学习 LLM 而不涉及基础设施复杂性
• 在个人工作站或笔记本电脑上运行
• 优先考虑简单性和易用性

许多团队同时使用两者：用 Ollama 进行开发和实验，然后用 vLLM 进行生产部署。这种组合提供了开发效率，同时保持生产性能。

vLLM 与 Docker 模型运行器对比

Docker 最近推出了 Model Runner（以前称为 GenAI Stack）作为其本地 AI 模型部署的官方解决方案。它与 vLLM 的对比如何？

架构理念

Docker Model Runner 希望成为“AI 的 Docker”——一种简单、标准化的方式，用与运行容器相同的便捷性在本地运行 AI 模型。它抽象了复杂性，并提供了跨不同模型和框架的一致接口。

vLLM 是一个专注于 LLM 服务并追求最大性能的专用推理引擎。它是一个较低层次的工具，您需要用 Docker 容器化它，而不是一个完整的平台。

设置和入门

Docker Model Runner 的安装对 Docker 用户来说很简单：

docker model pull llama3:8b
docker model run llama3:8b

这种与 Docker 图像工作流程的相似性使它对已经使用容器的开发人员来说立即熟悉。

vLLM 需要更多的初始设置（Python、CUDA、依赖项）或使用预构建的 Docker 镜像：

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

性能特征

vLLM 由于 PagedAttention 和连续批处理，在多用户场景中提供了优越的吞吐量。对于处理每秒数百个请求的生产 API 服务，vLLM 的优化提供了比通用服务方法好 2-5 倍的吞吐量。

Docker Model Runner 更注重易用性而不是最大性能。它适合本地开发、测试和中等工作负载，但没有实现使 vLLM 在规模上表现优异的高级优化。

模型支持

Docker Model Runner 提供了一个精选的模型库，可以一键访问流行模型。它支持多种框架（不仅仅是 LLMs）包括 Stable Diffusion、Whisper 和其他 AI 模型，使其在不同 AI 工作负载上更加通用。

vLLM 专注于 LLM 推理，对基于 transformer 的语言模型有深入支持。它支持任何 HuggingFace 兼容的 LLM，但不扩展到其他 AI 模型类型，如图像生成或语音识别。

生产部署

vLLM 在 Anthropic、Replicate 等公司经过实战检验，每天服务数十亿个令牌。其性能特征和在高负载下的稳定性使其成为生产 LLM 服务的默认标准。

Docker Model Runner 是较新的，定位更多是开发和本地测试场景。虽然它可以服务生产流量，但缺乏生产部署所需的经过验证的记录和性能优化。

集成生态系统

vLLM 与生产基础设施工具集成：Kubernetes 操作符、Prometheus 指标、Ray 用于分布式服务，以及 OpenAI API 与现有应用程序的广泛兼容性。

Docker Model Runner 自然地与 Docker 生态系统和 Docker Desktop 集成。对于已经标准化在 Docker 上的团队，这种集成提供了连贯的体验，但缺少专门的 LLM 服务功能。

何时使用每种

使用 vLLM 的情况：

• 生产 LLM API 服务
• 高吞吐量、多用户部署
• 云部署中需要最大效率的成本敏感场景
• Kubernetes 和云原生环境
• 需要经过验证的可扩展性和性能时

使用 Docker Model Runner 的情况：

• 本地开发和测试
• 运行各种 AI 模型类型（不仅仅是 LLMs）
• 投资于 Docker 生态系统的团队
• 无需基础设施设置的快速实验
• 学习和教育目的

混合方法：许多团队在本地使用 Docker Model Runner 进行开发和实验，然后在生产中使用 vLLM 进行部署。Docker Model Runner 图像也可以用来运行 vLLM 容器，结合两者的方法。

生产部署最佳实践

Docker 部署

创建一个生产就绪的 Docker Compose 配置：

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Kubernetes 部署

在 Kubernetes 上部署 vLLM 以进行生产规模：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

监控和可观测性

vLLM 暴露了 Prometheus 指标用于监控：

import requests

# 获取指标
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

关键指标：

• vllm:num_requests_running - 活动请求
• vllm:gpu_cache_usage_perc - KV 缓存利用率
• vllm:time_to_first_token - 延迟指标
• vllm:time_per_output_token - 生成速度

性能调优

优化 GPU 内存利用率：从 --gpu-memory-utilization 0.90 开始，根据观察行为进行调整。更高的值允许更大的批次，但风险在流量高峰期间出现 OOM 错误。

调整最大序列长度：如果您的用例不需要完整的上下文长度，减少 --max-model-len。这会释放内存用于更大的批次。例如，如果您只需要 4K 上下文，设置 --max-model-len 4096 而不是使用模型的最大值（通常是 8K-32K）。

选择适当的量化：对于支持的模型，使用量化版本（8 位、4 位）以减少内存并提高吞吐量：

--quantization awq  # 对于 AWQ 量化模型
--quantization gptq # 对于 GPTQ 量化模型

启用前缀缓存：对于具有重复提示的应用（如带有系统消息的聊天机器人），启用前缀缓存：

--enable-prefix-caching

这会缓存常见前缀的 KV 值，减少共享相同提示前缀请求的计算。

常见问题排查

内存不足错误

症状：服务器崩溃并出现 CUDA 内存不足错误。

解决方案：

• 将 --gpu-memory-utilization 降低到 0.85 或 0.80
• 如果您的用例允许，减少 --max-model-len
• 降低 --max-num-seqs 以减少批次大小
• 使用量化模型版本
• 启用张量并行以分散到更多 GPU 上

吞吐量低

症状：服务器处理的请求数少于预期。

解决方案：

• 增加 --max-num-seqs 以允许更大的批次
• 如果有余量，提高 --gpu-memory-utilization
• 使用 htop 检查 CPU 是否瓶颈 – 考虑使用更快的 CPU
• 使用 nvidia-smi 验证 GPU 利用率 – 应该是 95%+
• 如果使用 FP32，启用 FP16：--dtype float16

首个令牌时间慢

症状：生成开始前的延迟高。

解决方案：

• 对于延迟关键的应用，使用较小的模型
• 启用前缀缓存以处理重复提示
• 减少 --max-num-seqs 以优先考虑延迟而非吞吐量
• 对于支持的模型，考虑使用推测解码
• 优化张量并行配置

模型加载失败

症状：服务器无法启动，无法加载模型。

解决方案：

• 验证模型名称是否与 HuggingFace 格式完全匹配
• 检查与 HuggingFace Hub 的网络连接
• 确保 ~/.cache/huggingface 中有足够的磁盘空间
• 对于受限制的模型，设置 HF_TOKEN 环境变量
• 尝试手动下载：huggingface-cli download <model>

高级功能

推测解码

vLLM 支持推测解码，其中较小的草案模型提出令牌，较大的目标模型验证这些令牌。这可以将生成速度提高 1.5-2 倍：

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

LoRA 适配器

在基础模型上服务多个 LoRA 适配器，而无需加载多个完整模型：

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

然后在每个请求中指定要使用的适配器：

response = client.completions.create(
    model="sql-lora",  # 使用 SQL 适配器
    prompt="将此转换为 SQL：显示本月创建的所有用户"
)

多 LoRA 服务

vLLM 的多 LoRA 服务允许托管数十个微调适配器，内存开销最小。这对于服务客户特定或任务特定的模型变体非常理想：

# 带有特定 LoRA 适配器的请求
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "编写 SQL 查询"}],
    extra_body={"lora_name": "sql-lora"}
)

前缀缓存

启用自动前缀缓存以避免重复提示前缀的 KV 缓存重新计算：

--enable-prefix-caching

这特别适用于：

• 带有固定系统提示的聊天机器人
• RAG 应用程序中的一致上下文模板
• 跨请求重复的少样本学习提示

前缀缓存可以将共享提示前缀的请求的首次令牌时间减少 50-80%。

集成示例

LangChain 集成

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("用简单的话解释 PagedAttention")
print(response)

LlamaIndex 集成

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("vLLM 是什么？")
print(response)

FastAPI 应用程序

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

性能基准测试

实际性能数据有助于说明 vLLM 的优势：

吞吐量比较（Mistral-7B 在 A100 GPU 上）：

• vLLM：约 3,500 tokens/秒，64 个并发用户
• HuggingFace Transformers：约 250 tokens/秒，相同并发
• Ollama：约 1,200 tokens/秒，相同并发
• 结果：vLLM 比基本实现提高了 14 倍

内存效率（LLaMA-2-13B）：

• 标准实现：24GB VRAM，32 个并发序列
• vLLM 带 PagedAttention：24GB VRAM，128 个并发序列
• 结果：相同内存下并发请求量提高 4 倍

负载下的延迟（Mixtral-8x7B 在 2xA100 上）：

• vLLM：P50 延迟 180ms，P99 延迟 420ms，100 req/s
• 标准服务：P50 延迟 650ms，P99 延迟 3,200ms，100 req/s
• 结果：vLLM 在高负载下保持一致的延迟

这些基准测试说明了为什么 vLLM 成为了生产 LLM 服务的默认标准，特别是在性能至关重要的场景中。

成本分析

了解选择 vLLM 的成本影响：

场景：每天服务 100 万次请求

使用标准服务：

• 所需：8x A100 GPU（80GB）
• AWS 成本：约 $32/小时 × 24 × 30 = $23,040/月
• 每 100 万 tokens 成本：约 $0.75

使用 vLLM：

• 所需：2x A100 GPU（80GB）
• AWS 成本：约 $8/小时 × 24 × 30 = $5,760/月
• 每 100 万 tokens 成本：约 $0.19
• 节省：$17,280/月（75% 的减少）

随着规模的扩大，这种成本优势会进一步增加。使用 vLLM 的优化服务而不是基本实现的组织每月可以节省数十万美元的令牌。

安全考虑

认证

vLLM 默认不包含认证。对于生产环境，请在反向代理级别实现认证：

# Nginx 配置
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

或使用 Kong、Traefik 或 AWS API Gateway 等 API 网关实现企业级认证和速率限制。

网络隔离

在私有网络中运行 vLLM，不要直接暴露在互联网上：

# Kubernetes NetworkPolicy 示例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

速率限制

实现速率限制以防止滥用：

# 使用 Redis 进行速率限制的示例
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # 60 秒窗口
    
    if requests > 60:  # 每分钟 60 次请求
        raise HTTPException(status_code=429, detail="速率限制超出")
    
    return await call_next(request)

模型访问控制

对于多租户部署，控制哪些用户可以访问哪些模型：

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # 所有模型
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

迁移指南

从 OpenAI 迁移到 vLLM

由于 API 兼容性，迁移到自托管 vLLM 很简单：

迁移前（OpenAI）：

from openai import OpenAI

client = OpenAI(api_key="sk-. ..")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "你好"}]
)

迁移后（vLLM）：

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # 如果添加了认证
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "你好"}]
)

只需更改 base_url 和 model 名称。所有其他代码保持不变。

从 Ollama 迁移到 vLLM

Ollama 使用不同的 API 格式。以下是转换：

Ollama API：

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': '为什么天空是蓝色的？'
    })

vLLM 等效：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="为什么天空是蓝色的？"
)

您需要更新代码库中的所有 API 调用，但 OpenAI 客户端库提供了更好的错误处理和功能。

从 HuggingFace Transformers 迁移到 vLLM

直接 Python 使用迁移：

HuggingFace：

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("你好", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM：

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("你好", sampling_params)
result = outputs[0].outputs[0].text

vLLM 的 Python API 更简单，且在批处理推理方面更快。

vLLM 的未来

vLLM 继续快速发展，有令人兴奋的功能在路线图上：

解耦服务：将预填充（提示处理）和解码（令牌生成）分离到不同的 GPU 上，以优化资源利用率。预填充是计算密集型的，而解码是内存密集型的，因此在专用硬件上运行它们可以提高效率。

多节点推理：将非常大的模型（100B+ 参数）分布在多台机器上，使能够服务那些在单节点设置中无法运行的模型。

增强量化：支持新的量化格式如 GGUF（由 llama.cpp 使用）和改进的 AWQ/GPTQ 集成，以在量化模型上实现更好的性能。

推测解码改进：更高效的草案模型和自适应推测策略，以在不损失准确性的情况下实现更高的加速。

注意力优化：FlashAttention 3、环形注意力（用于极长上下文，100K+ 令牌）和其他前沿的注意力机制。

更好的模型覆盖：随着新模型的出现，扩展对多模态模型（视觉-语言模型）、音频模型和专用架构的支持。

vLLM 项目持续活跃开发，有来自 UC Berkeley、Anyscale 和更广泛的开源社区的贡献。随着 LLM 部署在生产系统中变得越来越重要，vLLM 作为性能标准的作用继续增长。

有用的链接

本网站相关文章

• 本地LLM部署：2026年完整指南 - Ollama、vLLM、LocalAI、Jan、LM Studio及其他 - 对包括Ollama、vLLM、LocalAI、Jan、LM Studio等在内的12+本地LLM部署工具进行全面比较，涵盖API成熟度、工具调用支持、GGUF兼容性及性能基准，帮助选择合适的解决方案。

• Ollama速查表 - 完整的Ollama命令参考和速查表，涵盖安装、模型管理、API使用及本地LLM部署的最佳实践。对于使用Ollama（或替代vLLM）的开发人员至关重要。

• Docker模型运行器 vs Ollama：该如何选择？ - 对Docker模型运行器和Ollama在本地LLM部署方面的深入比较，分析性能、GPU支持、API兼容性及使用场景，帮助理解vLLM所处的竞争格局。

• Docker模型运行器速查表：命令与示例 - 实用的Docker模型运行器速查表，包含用于AI模型部署的命令和示例。对于比较Docker方法与vLLM专用LLM服务功能的团队非常有用。

外部资源与文档

• vLLM GitHub仓库 - vLLM官方仓库，包含源代码、全面文档、安装指南及活跃社区讨论。是了解最新功能和解决技术问题的重要资源。

• vLLM文档 - 官方文档涵盖vLLM从基本设置到高级配置的所有方面，包括API参考、性能调优指南及部署最佳实践。

• PagedAttention论文 - 介绍PagedAttention算法的学术论文，该算法为vLLM的效率提供了支持。是理解vLLM性能优势背后技术创新的必读内容。

• vLLM博客 - 官方vLLM博客，发布版本更新、性能基准测试、技术深入解析及来自生产部署的社区案例研究。

• HuggingFace模型库 - 全面的开源LLM仓库，包含与vLLM兼容的模型。可根据模型大小、任务类型、许可证及性能特征进行搜索，找到适合您使用场景的模型。

• Ray Serve文档 - Ray Serve框架文档，用于构建可扩展、分布式的vLLM部署。Ray提供了自动扩展、多模型服务及资源管理等高级功能，适用于生产系统。

• NVIDIA TensorRT-LLM - NVIDIA的TensorRT-LLM，用于在NVIDIA GPU上实现高度优化的推理。与vLLM相比，采用不同的优化策略，有助于比较和理解推理优化的全景。

• OpenAI API参考 - vLLM API兼容的OpenAI官方API文档。在需要与OpenAI和自托管vLLM端点互操作的应用程序开发中作为参考。