VLLM

引言 vLLM 由 UC Berkeley 团队开发，凭借 PagedAttention 技术实现了接近理论峰值的 GPU 利用率。在同等硬件条件下，vLLM 的吞吐量可达 Hugging Face Transformers 的 14-24 倍。截至 2026 年，vLLM 已成为企业级 LLM 推理部署的首选引擎，被 Anthropic、Meta、字节跳动等公司广泛采用。 核心技术解析 PagedAttention PagedAttention 是 vLLM 的核心创新，灵感来自操作系统的虚拟内存分页机制。传统 LLM 推理中，KV Cache 的内存管理存在严重碎片化问题。 传统 KV Cache 问题： ┌─────────────────────────────────────────┐ │ 连续内存分配（传统方式） │ │ ┌──────┐┌──────┐┌──────┐┌──────────┐ │ │ │Req A ││Req B ││Req C ││ 空洞 │ │ │ │2GB ││2GB ││2GB ││ 1.5GB │ │ │ └──────┘└──────┘└──────┘└──────────┘ │ │ 问题：外部碎片导致 1.5GB 无法利用 │ └─────────────────────────────────────────┘ PagedAttention 方案： ...

前言 随着开源大模型的飞速发展，本地部署 LLM 已经从"极客玩具"变成了"企业标配"。无论你是想在 MacBook 上运行个人 AI 助手，还是需要在 GPU 集群上部署高并发推理服务，选择正确的部署框架都至关重要。本文将深度对比 2026 年最主流的四种本地 LLM 部署方案：Ollama、vLLM、LM Studio 和 Hugging Face TGI，从性能、易用性、扩展性和生产适用性四个维度给出全面建议。 一、参评方案概览 方案 开发商 核心语言 推理引擎 目标场景 开源 Ollama Ollama Inc. Go llama.cpp 个人/轻量级 ✅ vLLM UC Berkeley Python PyTorch + CUDA 生产/高并发 ✅ LM Studio Element Labs TypeScript/Electron llama.cpp 桌面 GUI ❌ 免费使用 TGI Hugging Face Rust + Python Transformers + Flash Attention 生产/企业 ✅ 二、核心特性对比 2.1 功能矩阵 特性 Ollama vLLM LM Studio TGI GUI 界面 ❌ CLI ❌ API only ✅ 桌面应用 ❌ API only OpenAI 兼容 API ✅ ✅ ✅ ✅ 多 GPU 支持 ⚠️ 有限 ✅ 张量并行 ❌ ✅ 量化支持 GGUF 全格式 AWQ/GPTQ/FP8 GGUF GPTQ/AWQ/BitsAndBytes PagedAttention ❌ ✅ ❌ ✅ 连续批处理 ❌ ✅ ❌ ✅ 流式输出 ✅ ✅ ✅ ✅ 模型库 Ollama Library HuggingFace HuggingFace HuggingFace Docker 支持 ✅ ✅ ❌ ✅ Kubernetes ⚠️ 社区方案 ✅ 官方 ❌ ✅ 官方 2.2 支持的模型格式 格式 Ollama vLLM LM Studio TGI GGUF ✅ 原生 ❌ ✅ 原生 ❌ Safetensors ⚠️ 转换 ✅ 原生 ⚠️ 转换 ✅ 原生 PyTorch (.bin) ⚠️ 转换 ✅ ⚠️ 转换 ✅ AWQ ❌ ✅ ❌ ✅ GPTQ ❌ ✅ ❌ ✅ FP8 ❌ ✅ ❌ ⚠️ 实验 MLX ⚠️ Mac 专用 ❌ ⚠️ Mac ❌ 三、性能基准对比 3.1 单卡推理性能 测试环境： NVIDIA RTX 4090 (24GB)，模型 Qwen2.5-7B-Instruct，FP16，批量=1 ...

静态批处理的瓶颈 传统 LLM 推理服务采用静态批处理：每个批次固定大小，所有请求必须等最长的那个请求完成后才能返回。 静态批处理示例（batch=4）： Request A: [tok][tok][tok][tok][EOS] # 生成 5 个 token Request B: [tok][tok][tok][tok][tok][tok][EOS] # 生成 7 个 token Request C: [tok][tok][tok][EOS] # 生成 4 个 token Request D: [tok][tok][tok][tok][tok][tok][tok][tok][EOS] # 生成 9 个 token 批处理完成时间：等待 D 完成（9 个 token） 实际计算：A 只需要 5 步，但等了 9 步 GPU 利用率：≈ 25/36 = 69%（因为要等待最慢的请求） 问题： 首 token 延迟：新请求必须等当前批次完成才能进入 GPU 闲置：短请求完成后，GPU 资源被浪费 吞吐低下：无法动态调度，无法"边生成边接收" 连续批处理原理 连续批处理（Continuous Batching, Orca, 2023）的核心思想是：动态管理批次，随时加入新请求，随时移除已完成的请求。 ...

背景：为什么需要新的推理引擎 vLLM 以 PagedAttention 革新了 KV Cache 管理，但在实际生产中仍存在痛点： 前缀缓存粒度粗：vLLM 的 Prefix Cache 是 block 级别，命中率受限于前缀完全匹配 多轮对话效率低：每轮对话的 KV Cache 无法跨请求高效复用 缺乏结构化生成：JSON/Regex 约束生成需要额外引擎（如 Outlines） SGLang（Structured Generation Language）由 LMSYS 团队开发，从设计之初就针对这些问题。 SGLang 架构 核心组件 ┌──────────────────────────────────────────────┐ │ SGLang Frontend (Python) │ │ @function 装饰器 / sgl.gen() DSL │ ├──────────────────────────────────────────────┤ │ SGLang Runtime (Server) │ │ RadixAttention + Cache Manager │ │ + Constrained Decoding (Regex/JSON) │ ├───────────────┬──────────────────────────────┤ │ Scheduler │ Model Worker │ │ (Batching) │ (Tensor Parallel) │ ├───────────────┴──────────────────────────────┤ │ GPU Workers (CUDA) │ └──────────────────────────────────────────────┘ RadixAttention 原理 RadixAttention 是 SGLang 的核心创新。与 vLLM 的 PagedAttention 相比，关键区别在于 KV Cache 的组织方式： ...

vLLM 架构总览 vLLM 由 UC Berkeley 团队开发，核心创新是 PagedAttention——一种受操作系统虚拟内存启发的注意力机制。其架构层次： ┌─────────────────────────────────────────────┐ │ OpenAI Compatible API │ │ (Streaming / Function Calling) │ ├─────────────────────────────────────────────┤ │ Request Scheduler │ │ (Continuous Batching + Priority Queue) │ ├──────────────┬──────────────────────────────┤ │ PagedAttention│ ParallelWorker │ │ KV Cache Mgr │ (Tensor Pipeline Parallel)│ ├──────────────┴──────────────────────────────┤ │ GPU Workers (CUDA) │ │ FlashAttention / FlashInfer Backend │ └─────────────────────────────────────────────┘ PagedAttention 原理 核心问题 传统 LLM 推理中，KV Cache 按最大序列长度预分配连续显存。这导致： 内部碎片：实际序列 < 最大序列，浪费 60-80% 显存 外部碎片：频繁分配/释放产生碎片 无法共享：相同前缀的请求各自维护 KV Cache PagedAttention 方案 借鉴 OS 的分页机制，将 KV Cache 分割为固定大小的 block（通常每 block 存 16 个 token 的 KV）： ...

vLLM 性能基石 vLLM 的核心性能优势来自三大技术： 技术 解决的问题 性能提升 PagedAttention KV Cache 内存碎片 2-4x 吞吐 连续批处理 静态批处理浪费 3-8x 吞吐 高效注意力 标准 Attention 慢 2x 推理速度 PagedAttention 原理 传统 KV Cache 为每个请求预分配连续内存，导致大量碎片： 传统方式: [请求A: ████░░░░] [请求B: ██░░░░░░] [请求C: ██████░░] 预分配8块, 用4块 预分配8块, 用2块 预分配8块, 用6块 浪费4块 浪费6块 浪费2块 总利用率: 12/24 = 50% PagedAttention: [块0:A1] [块1:A2] [块2:B1] [块3:C1] [块4:C2] [块5:A3] [块6:C3] [块7:空闲] 按需分配, 几乎无浪费 总利用率: 7/8 = 87.5% KV Cache 被分成固定大小的 block（通常 16 token/block），通过页表映射，类似操作系统的虚拟内存。 ...

为什么选 vLLM Ollama 适合本地开发，但生产环境需要高吞吐：vLLM 是目前最快的开源 LLM 推理引擎。 引擎 吞吐量 并发 显存利用 适用场景 Ollama 1x 低 中 本地开发 vLLM 5-10x 高 极高 生产部署 TGI 3-5x 高 高 生产部署 TensorRT-LLM 8-12x 高 极高 极致性能 核心技术：PagedAttention 传统 KV Cache: ┌──────────────────────────────────┐ │ Request A: [████████░░░░░░░░░░░] │ 预分配，大量浪费 │ Request B: [██████████████░░░░░] │ │ Request C: [██░░░░░░░░░░░░░░░░░] │ └──────────────────────────────────┘ 显存利用率：~40% PagedAttention: ┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐ │A1│A2│B1│B2│B3│C1│A3│B4│A4│B5│ 按需分配，零浪费 └──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘ 显存利用率：~95% 快速部署 Docker 部署 docker run --gpus all \ -v /models:/models \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:latest \ --model /models/Qwen3-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 Python 部署 from vllm import LLM, SamplingParams llm = LLM( model="/models/Qwen3-7B-Instruct", tensor_parallel_size=1, # GPU 数量 gpu_memory_utilization=0.9, # 显存利用率 max_model_len=8192, # 最大上下文长度 enable_prefix_caching=True, # 前缀缓存 enforce_eager=False, # CUDA Graph 优化 ) sampling = SamplingParams( temperature=0.7, top_p=0.9, max_tokens=1024, ) # 批量推理 outputs = llm.generate( ["你好", "解释RAG", "写一段Python代码"], sampling, ) OpenAI 兼容 API 服务 # 启动 API 服务 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3-7B-Instruct \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --enable-prefix-caching \ --served-model-name qwen3-7b # 客户端调用（与 OpenAI SDK 完全兼容） from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="vllm") response = client.chat.completions.create( model="qwen3-7b", messages=[{"role": "user", "content": "你好"}], stream=True, ) 性能调优 1. 批处理配置 llm = LLM( model="/models/Qwen3-7B-Instruct", # 批处理 max_num_seqs=256, # 最大并发序列数 max_num_batched_tokens=8192, # 每批最大 token 数 # KV Cache gpu_memory_utilization=0.9, # 显存利用率（0.8-0.95） swap_space=4, # CPU 交换空间 (GB) # 量化 quantization="awq", # AWQ 量化（省 50% 显存） ) 2. 前缀缓存 # 启用前缀缓存：相同 system prompt 的请求共享 KV Cache llm = LLM( model="/models/Qwen3-7B-Instruct", enable_prefix_caching=True, ) # 效果： # 第一个请求：1.2s（生成 KV Cache） # 后续相同 system prompt 的请求：0.3s（复用 KV Cache） 3. Speculative Decoding # 用小模型猜，大模型验 llm = LLM( model="/models/Qwen3-7B-Instruct", speculative_model="/models/Qwen3-0.5B", # 草稿模型 num_speculative_tokens=5, # 每轮猜 5 个 token ) # 效果：吞吐量提升 1.5-2x # 原理：小模型快速生成 5 个候选 token，大模型一次性验证 4. 量化部署 # AWQ 量化（推荐） # 模型大小：14GB → 5GB # 性能损失：<2% llm = LLM( model="/models/Qwen3-7B-Instruct-AWQ", quantization="awq", max_model_len=8192, ) # GPTQ 量化 llm = LLM( model="/models/Qwen3-7B-Instruct-GPTQ", quantization="gptq", ) # FP8（H100 以上 GPU） llm = LLM( model="/models/Qwen3-7B-Instruct", quantization="fp8", ) 多 GPU 部署 张量并行 # 4 GPU 张量并行 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3-72B-Instruct \ --tensor-parallel-size 4 \ --port 8000 # 原理：将模型权重切分到 4 张 GPU # GPU 0: attention layers (1/4) # GPU 1: attention layers (2/4) # GPU 2: attention layers (3/4) # GPU 3: attention layers (4/4) # 每次前向传播需要 4 GPU 通信 流水线并行 # 2 GPU 流水线并行 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3-72B-Instruct \ --pipeline-parallel-size 2 \ --port 8000 并行策略选择 策略 适用 通信开销 显存效率 张量并行 同机多 GPU 高（每层通信） 高 流水线并行 跨机多 GPU 低（层间通信） 中 数据并行 多副本 低 低 监控 # vLLM 内置 Prometheus 指标 # 访问 http://localhost:8000/metrics # 关键指标： # vllm:num_requests_running - 运行中的请求数 # vllm:num_requests_waiting - 排队中的请求数 # vllm:gpu_cache_usage_perc - GPU 缓存使用率 # vllm:time_to_first_token - 首 Token 延迟 # vllm:time_per_output_token - 每 Token 生成时间 # vllm:e2e_request_latency - 端到端延迟 # Prometheus 配置 scrape_configs: - job_name: 'vllm' static_configs: - targets: ['localhost:8000'] metrics_path: '/metrics' 生产部署清单 # docker-compose.yml version: '3.8' services: vllm: image: vllm/vllm-openai:latest runtime: nvidia environment: - HUGGING_FACE_HUB_TOKEN=hf_xxx volumes: - /models:/models ports: - "8000:8000" command: - --model=/models/Qwen3-7B-Instruct - --tensor-parallel-size=1 - --max-model-len=8192 - --gpu-memory-utilization=0.9 - --enable-prefix-caching - --served-model-name=qwen3-7b - --uvicorn-log-level=info healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"] interval: 30s timeout: 10s retries: 3 deploy: resources: reservations: devices: - capabilities: ["gpu"] 成本对比 以 Qwen3-7B 为例，处理 100 万 Token： ...