当前位置：首页 > news >正文

大模型本地部署，vLLM_推理优化，动手实验

news 2026/6/11 1:38:23

周末刚刷完 DeepLearning AI 一门新课，vLLM 团队联合吴恩达出品，讲的是大模型本地部署的推理优化，免费的，质量极高，直接让我理解了为什么 vLLM 能成为开源推理引擎的事实标准

这门课是什么

课程叫Fast & Efficient LLM Inference with vLLM，由 Red Hat 高级开发者布道师 Cedric Clyburn 主讲，吴恩达团队联合打造，1.5 小时 9 节视频 + 3 个动手实验

核心内容分三大块：压缩（Compress）→ 部署（Serve）→ 评测（Benchmark），覆盖了从量化模型到本地跑服务再到性能压测的完整链路

今天我重点聊聊 Part I 和 Part II 讲的推理优化三板斧——Continuous Batching、PagedAttention、Prefix Caching，以及动手跑 vLLM 服务的实操代码

下面这张图概括了 vLLM 的三板斧分别解决什么问题：

为什么需要推理优化

LLM 推理有个致命问题：每生成一个 token 都要做一次完整的前向传播，把整个模型权重从显存搬到计算单元

如果一次只服务一个请求，GPU 的 tensor cores 大部分时间都在等数据搬运，计算利用率极低。打个比方，就像你开了一辆大卡车，每次只运一个快递包裹

解决方案很简单：批处理——把多个请求打包在一起处理。读一次模型权重，给多个用户同时算。同样的内存开销，干的活儿多了好几倍

第一板斧：Continuous Batching（连续批处理）

传统的Static Batching有个大问题：一批请求里，有人问"2+2等于几"（5 个 token 就搞定），有人要一篇 2000 字小作文。短请求早就算完了，但必须等那个最慢的请求结束，整批才能释放。GPU 空转，浪费严重

Continuous Batching 的思路：不再等整批结束，而是在token 级别调度。某个请求一结束，新请求立刻补上它的槽位

效果肉眼可见——GPU 永远在干活，没有空闲槽位

第二板斧：PagedAttention（分页注意力）

即使 GPU 算力够用，还有第二个瓶颈：显存

每个活跃请求都有自己的 KV Cache（键值缓存），随着生成 token 不断增长。传统方案一上来就按最大长度预分配一整块连续内存——比如给每个请求留 2048 个 slot

问题来了：

内部碎片：请求只用了 200 个 token，剩下 1848 个 slot 白白浪费
外部碎片：两个预分配块之间的空隙放不下新请求
过度预留：还没用到的空间一直被锁着，别的请求用不了

vLLM 的论文指出，传统方案只有 20%~40%的 KV Cache 显存真正存了有用数据。其余全浪费了

PagedAttention 的核心创新：借鉴操作系统的虚拟内存分页机制。不再预分配大块连续内存，而是把 KV Cache 切成固定大小的小块（Block），散落在显存各处，用一张 Block Table 记录映射关系

KV Cache可视化

好处是：

按需分配，用多少占多少
块可以不连续，没有碎片
请求结束后块立即释放，立即可被复用
同样的显存能塞进更多并发请求

第三板斧：Prefix Caching（前缀缓存）

很多应用场景里，所有请求共享同一个 system prompt。比如你的 AI 客服可能有一段 500 token 的系统指令

没有 Prefix Caching 时，每来一个用户请求，vLLM 都要重新算这 500 token 的 KV Cache——做了大量重复计算

有了 Prefix Caching，共享前缀只算一次，后续请求直接复用

两个典型场景：

多用户共享 system prompt：算一次，所有人用
多轮对话：第二轮的上下文包含第一轮的全部内容，重复部分直接从缓存取

课程里给的数据：当缓存命中率达到 75% 时，吞吐量提升约4 倍。这是白捡的性能

动手实操：启动 vLLM 服务

理论讲完，上代码

启动一个 vLLM 推理服务只需要一行命令：

vllm serve Qwen/Qwen3-0.6B --dtype=bfloat16 --max-model-len 4096

各参数含义：

vllm serve：启动内置推理服务器，默认开启 PagedAttention + Continuous Batching + Prefix Caching，监听 8000 端口
Qwen/Qwen3-0.6B：Hugging Face Hub 上的模型 ID，首次运行自动下载
--dtype=bfloat16：以 BF16 精度加载权重
--max-model-len 4096：上下文窗口限制为 4096 token，vLLM 会据此预估 KV Cache 块池大小

服务启动后暴露 OpenAI 兼容的 HTTP API，直接用openai官方 Python SDK 调用，无需改代码

用 OpenAI SDK 连接本地 vLLM

import time, requests, json, osVLLM_URL = "http://localhost:8000"# 等待服务就绪print("Waiting for vLLM server...")for attempt in range(60): try: r = requests.get(f"{VLLM_URL}/v1/models", timeout=5) if r.status_code == 200: MODEL = r.json()["data"][0]["id"] break except requests.ConnectionError: pass time.sleep(5)print(f"Connected to {VLLM_URL} — model: {MODEL}")

连接上之后，用标准 OpenAI client 发请求：

from openai import OpenAIclient = OpenAI(base_url=f"{VLLM_URL}/v1", api_key="unused")resp = client.chat.completions.create( model=MODEL, messages=[{"role": "user", "content": "What is PagedAttention in one sentence?"}], max_tokens=80, temperature=0.7, extra_body={"chat_template_kwargs": {"enable_thinking": False}},)print(resp.choices[0].message.content)

注意api_key="unused"—— 本地服务不需要真的 API key，但 SDK 要求传一个非空值。base_url改成本地地址就行，应用代码零修改即可从 OpenAI 切换到自部署模型

查看 Logprobs：模型到底有多确定

vLLM 还能让你看到模型对每个 token 的置信度：

resp = client.chat.completions.create( model=MODEL, messages=[{"role": "user", "content": "The capital of France is"}], max_tokens=15, temperature=0.0, logprobs=True, top_logprobs=5, extra_body={"chat_template_kwargs": {"enable_thinking": False}},)for tok in resp.choices[0].logprobs.content[:8]: print(f" Chosen: '{tok.token}' (logprob {tok.logprob:.2f})")

在课程实验里，模型对 “Paris” 的置信度高达 92.5%——这对于判断模型是"知道答案"还是"瞎猜"非常有用

实战：Continuous Batching 效果观测

发 5 个并发请求，观察 vLLM 的 metrics：

import concurrent.futuresprompts = [ "What is quantization?", "Explain KV caching briefly.", "What is continuous batching?", "Why is LLM inference memory-bound?", "What is PagedAttention?",]def _ask(prompt): return client.chat.completions.create( model=MODEL, messages=[{"role": "user", "content": prompt}], max_tokens=60, temperature=0.7, extra_body={"chat_template_kwargs": {"enable_thinking": False}}, )start = time.time()with concurrent.futures.ThreadPoolExecutor(max_workers=5) as pool: futures = {pool.submit(_ask, p): p for p in prompts} for f in concurrent.futures.as_completed(futures): resp = f.result() print(f" done: \"{futures[f][:40]}\" -> {resp.usage.completion_tokens} tokens")elapsed = time.time() - startprint(f"\nAll 5 completed in {elapsed:.2f}s")

关键观察：5 个请求的总耗时远小于逐个串行的 5 倍，因为 Continuous Batching 让调度器把这些请求打包在同一个 batch 里并行生成

实战：Prefix Caching 效果验证

发 5 个请求，共享同一个 system prompt：

SYSTEM_PROMPT = ( "You are a helpful AI teaching assistant for a course on " "LLM optimization. You specialize in explaining concepts like " "quantization, inference optimization, and model serving. Keep " "answers concise -- one or two sentences.")questions = [ "What is weight quantization?", "How does vLLM handle memory?", "What is continuous batching?", "Why use prefix caching?", "What is GPTQ?",]for i, q in enumerate(questions): t0 = time.time() resp = client.chat.completions.create( model=MODEL, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": q}, ], max_tokens=60, temperature=0.7, extra_body={"chat_template_kwargs": {"enable_thinking": False}}, ) dt = time.time() - t0 print(f" [{i+1}] {q:<35} {dt:.2f}s")

通过/metrics端点可以看到prefix_cache_queries计数持续增长——vLLM 确实在复用 system prompt 的 KV Cache。课程实验里从 235 涨到 550，每次请求都省掉了 system prompt 的重算开销

KV Cache 到底占多大显存

来算笔账（以 Qwen3-0.6B 为例）：

num_layers = 28num_kv_heads = 8 # GQA: 16 Q heads, 8 KV headshead_dim = 128dtype_bytes = 2 # BF16per_token = 2 * num_layers * num_kv_heads * head_dim * dtype_bytes# = 114,688 bytes ≈ 112 KB / token