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

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 包含一个与 OpenAI 格式完全兼容的内置 API 服务器。这使得从 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 等公司中经过生产验证，每天处理数十亿个 token。其性能特征和在高负载下的稳定性使其成为生产 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
• 检查 CPU 是否成为瓶颈（使用 htop）——考虑更快的 CPU
• 使用 nvidia-smi 检查 GPU 利用率——应为 95%+
• 如果使用 FP32，启用 FP16：--dtype float16

首个 token 延迟高

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

解决方案：

• 对于延迟关键的应用，使用更小的模型
• 启用前缀缓存用于重复提示
• 减少 --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 延迟 180 毫秒，P99 延迟 420 毫秒，在 100 req/s 下
• 标准服务：P50 延迟 650 毫秒，P99 延迟 3,200 毫秒，在 100 req/s 下
• 结果：vLLM 在高负载下保持一致的延迟

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

成本分析

了解选择 vLLM 的成本影响：

情景：每天服务 100 万个请求

使用标准服务：

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

使用 vLLM：

• 需要：2x A100 GPU（80GB）
• AWS 成本：约 $8/小时 × 24 × 30 = $5,760/月
• 每 100 万个 token 的成本：约 $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 网络策略示例
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+ tokens）和其他前沿的注意力机制。

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

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

有用的链接

本网站相关文章

• 本地LLM部署：2025完整指南 - Ollama、vLLM、LocalAI、Jan、LM Studio及其他 - 对12+本地LLM部署工具进行全面比较，包括对Ollama、vLLM、LocalAI、Jan、LM Studio等的详细分析。涵盖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模型库 - 包含与vLLM兼容的开源LLM的综合仓库。可根据模型大小、任务、许可证和性能特征搜索合适的模型。

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

• NVIDIA TensorRT-LLM - NVIDIA的TensorRT-LLM，用于在NVIDIA GPU上进行高度优化的推理。作为vLLM的替代方案，采用不同的优化策略，有助于比较和理解推理优化的格局。

• OpenAI API参考 - vLLM API兼容的官方OpenAI API文档。在构建需要与OpenAI和自托管vLLM端点互操作的应用程序时，可参考此文档。