W8D1 学习手册 1.核心架构2.启动API3.非OpenAI模型4.量化 5.长度6.并发速率7.指标8.Benchmark 9.无GPU实测10.32B估算11.诚实报告12.资源 达标①达标②自测速记

FDE W8D1 学习手册 · vLLM 服务化部署与压测

W8 Day1 · B 级(工程核心)· 5h · 学完能独立部署一个兼容 OpenAI 的推理服务并给出可信的性能结论(无 GPU 也能诚实估算)

本日定位:从"会用 API"跨到"能自己把模型跑成一个服务"。候选人有 Java + 大数据 + 医疗保险背景,冲刺高级/架构/负责人岗——面试官极看重"你能不能把一个开源模型落到生产、并且用数据说话"。本日聚焦 vLLM(非 OpenAI 生态里的主流推理引擎)。
学完能回答:① vLLM 部署全流程与关键参数(量化/并发/长度);② TTFT/TPOT/ITL 各衡量什么、无 GPU 怎么诚实估算 32B 模型性能。
使用方法:先理解 PagedAttention 原理 → 逐参数看(量化/长度/并发)→ 重点背指标定义与面试话术 → 做自测清单 → 配合《FDE-W8D1-评测题.md》。选中不熟的词可标注(左下★重要 / 右下📌待查)。无 GPU 读者务必落实 s9/s10 的"小模型实测 + 公式估算"动作,不伪造数据。

一、vLLM 核心架构与 PagedAttention

1.1 为什么需要 vLLM

大模型自回归生成时,要把历史 token 的 KV Cache 常驻显存。传统方案为每个请求预分配连续显存(按 max_length 一次性占满),导致严重碎片化和浪费(实际生成常常远短于 max)。vLLM 的 PagedAttention 借鉴操作系统虚拟内存分页思想,把 KV Cache 切成固定块(block),按需分配、可非连续拼接,显存利用率从 ~30% 提升到 ~90%+。

1.2 关键组件

组件作用
Scheduler(调度器)决定哪些请求进批次、分配多少 KV block、何时抢占/换出
KVCacheManager分页管理 KV 块,处理 block 复用(相同前缀的 prompt 可共享 block)
Worker / Model Runner真正跑 GPU 前向计算,支持 Tensor Parallel(多卡并行)
Tokenizer / API Server提供兼容 OpenAI 的 /v1/chat/completions 等接口
显存占用 ≈ 模型权重 + (并发请求数 × 已生成 token 数 × 每层 KV 维度 × 2 × 字节数) ÷ 分页利用率
分页 KV 带来的直接工程价值:同样一张卡能扛的并发数翻倍。对"医疗保险理赔 Agent"这类有峰值并发的场景,vLLM 能显著压低单请求成本。架构师要会算"一张卡能并发多少",而不是拍脑袋。
vLLM 的核心是 PagedAttention——把 KV Cache 像操作系统虚拟内存一样分页,按需分配、可非连续,显存利用率从约 30% 提到 90%+,同样的卡能扛更多并发。这是它比裸 HuggingFace 推理快又省的根本原因。
① 不要说"vLLM 只是快一点",它的本质是显存利用率革命,直接决定单卡并发上限。② PagedAttention 解决的是显存碎片,不是算力问题;模型本身 FLOPs 不变。③ 分页会带来极小调度开销,但在高并发下收益远大于代价。

二、启动兼容 OpenAI 的 API 服务

2.1 一条命令起服务

# 安装
pip install vllm
# 启动(以 Qwen2.5-7B 为例,非 OpenAI 模型)
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 --port 8000 \
  --tensor-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9

2.2 接口与 OpenAI 兼容

启动后服务暴露与 OpenAI 完全兼容的端点,客户端可无缝替换 base_url:

端点用途对应 OpenAI
/v1/chat/completions对话补全相同
/v1/completions续写相同
/v1/models列出已加载模型相同
/v1/embeddings向量化(部分版本)相同
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role":"user","content":"特药理赔的免赔额一般怎么算?"}],
    temperature=0.1, max_tokens=512)
print(resp.choices[0].message.content)
"兼容 OpenAI"的工程含义 = 你现有的 LangChain / RAG 代码把 api_base 指过来就能跑,零改业务代码。对架构/负责人岗,这意味私有部署能平滑替换 SaaS API,且数据不出域(合规卖点)。
vLLM 起的 API 和 OpenAI 的端点、参数完全兼容,把客户端的 base_url 指到本地即可,业务代码零改动。私有部署的最大价值是:数据不出公司、成本可控、可定制量化。
api_key="EMPTY" 不是笔误,vLLM 默认不鉴权(生产必须前面套一层网关/鉴权)。② 端口冲突、模型名写错是最常见的启动失败原因,先看日志再看代码。③ 兼容 ≠ 功能对等(如流式、function call 支持程度随版本变化),要实测。

三、加载非 OpenAI 模型(Qwen / DeepSeek)

3.1 模型来源

3.2 量化与权重格式

vLLM 支持 AWQ / GPTQ / FP8 / bitsandbytes 等多种量化格式,量化方式要在加载时声明

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --quantization awq            # 或 gptq / fp8 / bitsandbytes
  --dtype half                  # 权重计算精度 fp16/bf16
无 GPU 的候选人:可用 Ollama 在 Mac 本地跑 ollama run qwen3:8b 验证对话效果与结构化输出能力,再在云端 vLLM 跑同模型的量化版本做性能对比。参见 Ollama Qwen3 官方库
"非 OpenAI 模型"在面试里是加分项——它说明你不绑定厂商、能做私有化。医疗/保险客户往往数据敏感,必须用国产或开源模型(Qwen/DeepSeek)做私有部署,这直接对应"数据合规"卖点。
vLLM 能直接加载 Qwen、DeepSeek 等开源权重(HuggingFace 或本地路径),并声明量化方式与 dtype。私有部署让你不绑定 OpenAI、数据不出域,特别适合医疗/保险这类强合规场景。
① 不同量化格式对显卡架构有要求(如 AWQ/GPTQ 在老卡上可能不加速),要查 vLLM 兼容性矩阵。② --dtype 决定权重精度,bf16 在 A100 上更稳,fp16 在消费卡常见。③ 模型 tokenizer 的 chat template 必须匹配(对话格式错会导致输出怪异)。

四、量化方式:int4 / int8 / fp16 怎么选

4.1 三种量化的本质

方案显存占用精度损失速度适用
fp16(半精度)1×基准几乎无损显存够、要最佳质量
int8~0.5×很小略快显存中等紧张
int4(AWQ/GPTQ)~0.25×可控(AWQ 优)最快/最省显存紧张、边缘部署

4.2 选择原则

量化后权重显存 ≈ 参数量 × 每参数字节数(fp16=2B,int8=1B,int4=0.5B)+ KV Cache + 激活开销
架构师做技术选型时,量化是"质量 vs 成本"的旋钮。对特药理赔 Agent,最终给用户的结论不能因量化出错,所以关键链路用 fp16,旁路摘要/分类可用 int4 降本。这是"分层用模"的思路。
量化是显存/质量的权衡:fp16 无损但最占显存,int4 最省但可能有损。选法是——显存够用上 fp16;单卡想跑大模型用 int4;医疗这类精度敏感场景关键链路保 fp16,旁路任务才量化降本。
① int4 不是"免费午餐",在某些知识/推理密集任务上会掉点,务必在评测集上对比量化前后准确率。② "int4 一定能省 4 倍"是错的——实际含 KV Cache 和框架开销,省不到 4 倍。③ AWQ 通常优于 GPTQ(保留重要权重),优先选 AWQ。

五、输入/输出长度与 max_model_len

5.1 三个长度参数

参数含义设错后果
--max-model-len模型上下文总上限(输入+输出)报"序列超长"或 OOM
max_tokens(请求级)单次最多生成多少 token输出被截断
--max-num-batched-tokens一个批次内最多 token 数影响吞吐

5.2 怎么定 max_model_len

单请求峰值 KV 显存 ≈ 2 × num_layers × hidden_dim × max_model_len × 字节数(per token)
长度参数直接锁死显存预算。医疗理赔场景输入文档长,盲目设 128K 会让单卡并发从 32 掉到 4——成本翻 8 倍。架构师要把"长度"当成本旋钮管起来。
max_model_len 是输入+输出的总上限,直接决定 KV Cache 显存峰值和单卡并发。设太大显存爆、并发崩;设太小长文截断。RAG/理赔场景按真实文档长度定,别拍脑袋设 128K。
① max_model_len 不是越大越好,它和显存、并发是三角约束。② 请求的 max_tokens 超过剩余预算会被静默截断,业务逻辑要检查 finish_reason=="length"。③ 不同模型有原生上下文上限,超过要开 YaRN/ROPE 缩放(vLLM 支持),否则质量下降。

六、并发与请求速率控制

6.1 关键并发参数

参数作用
--max-num-seqs同时处理的最大请求数(并发上限)
--max-num-batched-tokens每批最大 token 数
--gpu-memory-utilization显存利用比例(默认 0.9)
--enable-prefix-caching相同前缀 prompt 复用 KV,提速省显存

6.2 请求速率(QPS / RPS)

压测时控制发请求的速度:速率太低测不出吞吐上限速率太高会堆积队列。vLLM 的 benchmark 工具可设 --request-rate(-1 表示不限速,打满)。

真实生产是"有波动的并发",不是匀速。架构师要给出 SLA 下的容量:比如 P99 延迟 ≤ 3s 时系统能扛多少并发。这需要先测出单实例上限,再算副本数与队列丢弃策略。
vLLM 用 --max-num-seqs 控制并发上限,用 benchmark 的 --request-rate 控制发压速度。生产要的是"在某个 SLA 下能扛多少并发",不是裸跑最高速。并发、长度、量化三者共同决定单实例容量。
① 把 --max-num-seqs 设得比显存能撑的大,只会触发抢占换出(preemption),反而拖慢。② 压测"不限速打满"得出的吞吐≠用户能体验的吞吐,必须结合延迟指标看。③ 速率和并发是两个维度:限速下并发可能很低但延迟好,限速放开并发飙但 P99 爆。

七、核心指标:TTFT / TPOT / ITL / 吞吐 / 端到端延迟

7.1 五个指标定义(面试必背)

指标全称衡量什么单位
TTFTTime To First Token从发请求到收到第一个 token 的延迟(含调度+prefill)
TPOTTime Per Output Token两个输出 token 之间的平均间隔(解码速度)秒/token
ITLInter-Token Latency相邻 token 的逐次间隔(比 TPOT 更细,看抖动)秒/token
吞吐Throughput单位时间生成的 token 总数(或请求数)token/s
端到端延迟E2E Latency从发请求到收完整个回复的总时长
端到端延迟 ≈ TTFT + 输出 token 数 × TPOT(近似) | TPOT ≈ 单步解码耗时 × 流水线气泡

7.2 指标的工程意义

对理赔 Agent 这种"带流式输出"的产品,TTFT 决定第一印象,ITL/TPOT 决定阅读流畅度。架构师定 SLA 时要把这俩分开约束,而不是只看平均延迟。
TTFT 是"首字延迟"(含排队+prefill),TPOT 是"每字平均间隔"(解码速度),ITL 是逐字间隔(看抖动更细),吞吐是单位时间总 token,端到端是整段回复总时长。TTFT 管卡顿感,TPOT/ITL 管吐字流畅度,要分开看。
① TPOT 是"平均",会掩盖 ITL 抖动——流式场景下 ITL 的 P99 比 TPOT 均值更反映体感。② TTFT 包含了排队时间,所以高并发下 TTFT 升高不一定是模型慢,是排队。③ 吞吐高 ≠ 体验好(可能靠堆并发但每个用户 P99 爆)。

八、vLLM Benchmark CLI 实操

8.1 两种基准脚本

# 吞吐/延迟基准(模拟请求)
python -m vllm.benchmarks.benchmark_throughput \
  --model Qwen/Qwen2.5-7B-Instruct --dataset-name sharegpt \
  --num-prompts 100 --request-rate 4

# 面向 Serving 的基准(更接近生产,输出 TTFT/TPOT/ITL)
python -m vllm.benchmarks.benchmark_serving \
  --model Qwen/Qwen2.5-7B-Instruct --backend vllm \
  --dataset-name sharegpt --num-prompts 200 --request-rate 8 \
  --save-result --result-filename my_bench.json

8.2 关键开关

开关含义
--request-rate发压速率,-1 打满
--num-prompts总请求数
--dataset-namesharegpt / random 等,模拟真实 prompt 分布
--save-result落盘,便于写报告
官方文档:docs.vllm.ai;Benchmark CLI 详解:docs.vllm.ai/en/stable/benchmarking/cli
benchmark_serving 才是"生产视角"——它统计的就是 TTFT/TPOT/ITL 这类用户感知指标。写《容量与成本》报告(Day2)时,这些数字是你成本估算的输入。
vLLM 有两个基准脚本:benchmark_throughput 看纯吞吐,benchmark_serving 看 TTFT/TPOT/ITL 这类生产指标。压测要固定 request-rate、num-prompts、dataset,落盘结果写进报告,并标注测试环境(卡型/量化/长度)。
① 用 random 数据集压出来的数字会"虚高"(prompt 短、分布不真实),写报告要说清用了哪种数据集。② 不固定环境(卡型、驱动、vLLM 版本)的数字没有可比性。③ 别只报平均,必须给 P50/P90/P99,面试官最在意长尾。

九、无 GPU 实测方案:小模型跑通 + 32B 公式估算

9.1 无 GPU 也要"动手"

没有 A100/H100 不代表不能做实验。分两步走,绝不伪造数据

  1. 小模型实测(真数据):在 Mac(Ollama 跑 qwen3:8b)或 Colab 免费 GPU 上,跑通"启动服务→兼容 API→压测→记录 TTFT/吞吐"。这部分是真实跑出来的,可写进报告
  2. 32B 公式估算(标假设):用已知 7B 实测值和算力公式,推算 32B 在目标卡上的量级,并明确标注"估算、未实测"

9.2 为什么小模型实测仍有价值

对 36 岁、有大数据背景的候选人,面试官更看重"方法论可信"——你能清晰说明"哪些是我实测的、哪些是我估算的、假设是什么",这比一个漂亮但存疑的数字值钱得多。
无 GPU 就分两步:① 用 Mac/Colab 小模型(如 qwen3:8b)真实跑通流程、记录真实指标;② 用算力公式从 7B 实测值推算 32B 量级,并明确标注"估算、假设为…"。实测算真值、估算标假设,绝不混为一谈。
① 绝不可把 7B 实测数字直接说成 32B 的。② "估算"必须写清假设(卡型、量化、批大小、并发),否则无意义。③ 面试官一追问"这个 32B 数字你实测过吗",诚实说"按公式估算"反而加分。

十、32B 模型性能公式估算与假设条件

10.1 显存估算(能否装下)

权重显存(int4) ≈ 32e9 × 0.5B ≈ 16 GB;fp16 ≈ 64 GB;再加 KV Cache 与激活

10.2 吞吐估算(经验缩放)

相同卡、相同量化、相同批设置下,解码吞吐近似与参数量成反比(计算量更准的是与 FLOPs 成正比):

decode_throughput(32B) ≈ decode_throughput(7B) × (7 / 32) (同卡同量化近似)

例:若 7B-int4 在 24G 卡上实测 ~60 token/s/请求,则 32B-int4 约 ~13 token/s/请求(仅作量级参考,需实测校准)。

10.3 必须声明的假设

架构师给老板/客户报容量,靠的就是这种"先估算量级、再实测校准"的方法。能讲清假设和误差来源,比给一个精确但不可信的数字更有说服力。
32B 显存:int4 约 16G、fp16 约 64G,要据此判断几张卡能装。吞吐可用"同卡同量化下与参数量近似反比"从 7B 实测值推算,但必须声明假设(卡型/量化/批/长度),并注明"估算非实测"。
① 反比是粗近似,真实还受 KV Cache、批效率、MoE 结构影响(DeepSeek 是 MoE,激活参数远小于总参数,不能简单按 32B 算)。② 千万别把"估算"包装成"实测"。③ 不同架构(Dense vs MoE)算力利用天差地别,估算要先说明模型结构。

十一、诚实报告:不伪造性能数据

11.1 报告里的数据分级

数据类别写法示例
实测(有环境)"在 A100 80G、Qwen2.5-7B-int4、max_len=8K 下,P99 TTFT=1.2s,吞吐=820 tok/s(n=200,官方基准脚本)。"
估算(标假设)"32B-int4 在单卡 24G 的吞吐,按 7B 实测线性推算约 13 tok/s/请求(假设同量化同批,未实测)。"
未知"32B 在目标生产卡的实测待补充,本报告结论以 7B 实测 + 公式估算为准。"

11.2 反模式(面试/工作都忌)

保险/医疗行业对"数据真实性"极度敏感(合规、审计)。作为候选人,诚实标注数据来源与假设,本身就是专业素养的体现,面试官会据此判断你的可信度。
报告要把数据分级:实测的写清环境与脚本、估算的标假设、未知的明说待补。绝混用、绝伪造、绝只报平均。诚实标注来源和假设,在医疗/保险这种强合规行业反而是加分项。
① 面试里"你的压测数字怎么来的"是高频追问,答不出环境细节=存疑。② 用 random 数据集却声称"生产级结论"=不专业。③ 把估算当实测说,一旦被识破直接不及格——这比"我没卡测不了"严重得多。

十二、学习资源(B站 / 官方文档,中文非 OpenAI)

12.1 官方文档(首选,权威)

12.2 B站中文实战(搜关键词,按需学习)

建议学习顺序:先看 1 个部署视频跑通(s2)→ 再跟压测视频出一组真实数字(s8)→ 最后回看 PagedAttention 原理视频(s1)把"为什么快"讲透。无 GPU 用 Ollama 在本地 Mac 先验证对话与结构化输出。

十三、面试达标线①:vLLM 部署流程与关键参数

环节关键动作 / 参数要能讲清的点
安装启动pip install vllm + api_server一条命令起 OpenAI 兼容服务
模型加载--model(HF 或本地路径)Qwen/DeepSeek 等非 OpenAI 权重
量化--quantization awq/gptq/fp8int4/int8/fp16 取舍与显存影响
长度--max-model-len与 KV Cache/并发的三角约束
并发--max-num-seqs / --gpu-memory-utilization并发上限与显存预算
压测benchmark_serving(request-rate)TTFT/TPOT/ITL 输出与 P99
一句话达标:能从头讲"装 vLLM → 指定模型+量化 → 设长度/并发 → 起 OpenAI 兼容 API → 用 benchmark 压测出 TTFT/吞吐并落盘报告",并把量化/长度/并发三个旋钮对显存和成本的影响讲清楚。

十四、面试达标线②:指标含义 + 无 GPU 诚实估算

TTFT=首字延迟(含排队+prefill)| TPOT=每字平均间隔(解码)| ITL=逐字间隔(看抖动) 吞吐=单位时间总 token | 端到端=整段回复总时长 无 GPU:小模型(Mac/Colab)实测真值 + 32B 公式估算(标假设) ,二者严格分级不混用
  1. TTFT/TPOT/ITL 各衡量什么:TTFT 管"卡不卡才开始",TPOT 管"吐字均速",ITL 管"抖不抖"。
  2. 无 GPU 怎么诚实估算:① 小模型实测出真实流程与基准数字;② 用"同卡同量化吞吐≈与参数量反比"推算 32B 量级;③ 标注假设与"未实测",不伪造。
  3. 报告怎么写:实测写环境、估算标假设、未知明说,只报平均不报 P99 是减分项。

十五、W8D1 自测清单

十六、高频面试题速记卡

Q:vLLM 为什么比原生 HuggingFace 推理快又省?
核心是 PagedAttention,把 KV Cache 分页按需分配、可非连续,显存利用率从约 30% 提到 90%+,同样显存能扛更多并发。
Q:怎么把 vLLM 接进现有 RAG 代码?
它 API 与 OpenAI 完全兼容,把客户的 base_url 指向本地 8000 端口、api_key 设 EMPTY 即可,业务代码零改。
Q:选 fp16 还是 int4?
显存够用上 fp16(无损);单卡想跑大模型用 int4(最省);医疗等精度敏感场景关键链路保 fp16,旁路任务才量化降本。
Q:TTFT 高说明什么?
可能是输入长导致 prefill 慢、或并发高在排队。高并发下 TTFT 升高多半是排队而非模型慢,要分开看。
Q:TPOT 和 ITL 有何区别?
TPOT 是每 token 平均间隔,ITL 是相邻 token 逐次间隔;ITL 的 P99 更能反映流式卡顿抖动。
Q:没有 GPU 怎么准备性能数据?
两步法:① Mac/Colab 小模型(如 qwen3:8b)真实跑通流程记数字;② 用"同卡同量化吞吐≈与参数量反比"推算 32B 量级,并标注"估算未实测"。
Q:max_model_len 设太大有什么后果?
KV Cache 显存峰值与长度成正比,设太大→显存爆/单卡并发骤降→成本翻数倍;设太小长文截断。
Q:压测报告只给平均延迟为什么不够?
平均掩盖长尾;面试官/生产最在意 P99——高峰下少数用户卡顿最影响口碑,必须给 P50/P90/P99。
Q:私有部署相比 OpenAI API 的核心优势?
数据不出域(合规)、成本可控(按 GPU 时租而非 token 黑盒)、可自选量化与模型(Qwen/DeepSeek 等)。
Q:32B-int4 单卡 24G 能跑吗?
权重约 16G 能装下,但剩 8G 给 KV/激活,仅能极低并发;若要像样并发需 2×24G 或更大显存,且吞吐按参数量反比估算约 13 tok/s/请求(未实测)。
FDE W8D1 学习手册 · vLLM 服务化部署与压测(面试级)· 配合《FDE-W8D1-评测题.md》自测
📌 待查★ 重要