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 模型来源
- HuggingFace Hub:
--model Qwen/Qwen2.5-7B-Instruct、deepseek-ai/DeepSeek-V2-Lite。
- 本地路径:
--model /data/models/Qwen2.5-7B(离线/内网环境必备)。
- Ollama 拉取后转权重:Ollama 的 Qwen3 适合本地 Mac 小模型验证,再上 vLLM 跑生产。
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 选择原则
- 显存充足(如 A100 80G 跑 7B/14B):用 fp16/bf16,质量优先。
- 单卡 24G 想跑 7B:int8 或 int4 均可,int4 更稳。
- 单卡 24G 想跑 32B:必须 int4(~20G 权重)+ 限制并发,否则 OOM。
- 精度敏感场景(医疗诊断辅助、金额计算):优先 fp16/bf16,量化只做兜底。
量化后权重显存 ≈ 参数量 × 每参数字节数(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
- RAG 问答:输入含长文档+追问,建议 8K~32K。
- 理赔材料摘要:单份材料可能几千字,建议 ≥16K。
- 设太大 → KV Cache 显存占用飙升(与 max_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 五个指标定义(面试必背)
| 指标 | 全称 | 衡量什么 | 单位 |
| TTFT | Time To First Token | 从发请求到收到第一个 token 的延迟(含调度+prefill) | 秒 |
| TPOT | Time Per Output Token | 两个输出 token 之间的平均间隔(解码速度) | 秒/token |
| ITL | Inter-Token Latency | 相邻 token 的逐次间隔(比 TPOT 更细,看抖动) | 秒/token |
| 吞吐 | Throughput | 单位时间生成的 token 总数(或请求数) | token/s |
| 端到端延迟 | E2E Latency | 从发请求到收完整个回复的总时长 | 秒 |
端到端延迟 ≈ TTFT + 输出 token 数 × TPOT(近似) | TPOT ≈ 单步解码耗时 × 流水线气泡
7.2 指标的工程意义
- TTFT 高:prefill 慢(输入长/并发抢占)或排队久 → 用户觉得"卡顿才开始"。
- TPOT/ITL 高:解码慢(算力不足/量化反向拖累/批太大)→ 输出"吐字慢"。
- ITL 抖动大:批处理里混入长请求被抢占,体验差(流式卡顿)。
对理赔 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-name | sharegpt / random 等,模拟真实 prompt 分布 |
| --save-result | 落盘,便于写报告 |
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 不代表不能做实验。分两步走,绝不伪造数据:
- 小模型实测(真数据):在 Mac(Ollama 跑 qwen3:8b)或 Colab 免费 GPU 上,跑通"启动服务→兼容 API→压测→记录 TTFT/吞吐"。这部分是真实跑出来的,可写进报告。
- 32B 公式估算(标假设):用已知 7B 实测值和算力公式,推算 32B 在目标卡上的量级,并明确标注"估算、未实测"。
9.2 为什么小模型实测仍有价值
- 验证部署流程、参数、API 兼容性——这部分与模型大小无关。
- 验证你的压测脚本与指标口径正确。
- 为公式估算提供"基准点"(7B 的真实吞吐)。
对 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 与激活
- int4 + 单卡 24G:权重 16G,剩 8G 给 KV/激活,仅能极低并发。
- fp16 + 单卡 80G(A100):权重 64G,剩 16G,并发有限,更适合 2×24G 或 1×80G。
10.2 吞吐估算(经验缩放)
在相同卡、相同量化、相同批设置下,解码吞吐近似与参数量成反比(计算量更准的是与 FLOPs 成正比):
decode_throughput(32B) ≈ decode_throughput(7B) × (7 / 32) (同卡同量化近似)
例:若 7B-int4 在 24G 卡上实测 ~60 token/s/请求,则 32B-int4 约 ~13 token/s/请求(仅作量级参考,需实测校准)。
10.3 必须声明的假设
- 假设卡型、量化、max_model_len、批大小与 7B 实验一致;
- 假设无显著显存换出/抢占;
- 标注"此为公式估算,非实测,生产前需在目标卡实测校准"。
架构师给老板/客户报容量,靠的就是这种"先估算量级、再实测校准"的方法。能讲清假设和误差来源,比给一个精确但不可信的数字更有说服力。
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 反模式(面试/工作都忌)
- 把别人的 benchmark 数字当自己的结论;
- 混用实测与估算不标注;
- 只报平均不报 P99,掩盖长尾。
保险/医疗行业对"数据真实性"极度敏感(合规、审计)。作为候选人,诚实标注数据来源与假设,本身就是专业素养的体现,面试官会据此判断你的可信度。
报告要把数据分级:实测的写清环境与脚本、估算的标假设、未知的明说待补。绝混用、绝伪造、绝只报平均。诚实标注来源和假设,在医疗/保险这种强合规行业反而是加分项。
① 面试里"你的压测数字怎么来的"是高频追问,答不出环境细节=存疑。② 用 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/fp8 | int4/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 公式估算(标假设) ,二者严格分级不混用
- TTFT/TPOT/ITL 各衡量什么:TTFT 管"卡不卡才开始",TPOT 管"吐字均速",ITL 管"抖不抖"。
- 无 GPU 怎么诚实估算:① 小模型实测出真实流程与基准数字;② 用"同卡同量化吞吐≈与参数量反比"推算 32B 量级;③ 标注假设与"未实测",不伪造。
- 报告怎么写:实测写环境、估算标假设、未知明说,只报平均不报 P99 是减分项。
十五、W8D1 自测清单
- 能讲清 PagedAttention 是什么、相比传统 KV 预分配解决了什么(显存碎片)。
- 能默写"装 vLLM → 起 OpenAI 兼容 API → 客户端 base_url 指向本地"的完整命令与代码。
- 能说清 fp16/int8/int4 的显存、精度、速度差异与选型原则(含医疗精度敏感场景)。
- 能解释 max_model_len 与 KV Cache 显存、并发的关系,说出设太大的后果。
- 能列出 --max-num-seqs / --gpu-memory-utilization / --request-rate 的作用。
- 能精确定义 TTFT / TPOT / ITL / 吞吐 / 端到端延迟,并说清各自衡量什么、关注 P99。
- 能区分 benchmark_throughput 与 benchmark_serving 的用途差异。
- 无 GPU 时,能说出"小模型实测 + 32B 公式估算"的两步法,并举例假设条件。
- 能写出 32B-int4 的显存估算(约 16G 权重)与吞吐缩放公式。
- 能在报告里把"实测/估算/未知"三类数据分级标注,做到不伪造。
- 能讲清 vLLM 私有部署相比 OpenAI API 的核心卖点(数据不出域/成本可控/可定制量化)。
- 能回答达标线①(部署全流程+关键参数)与达标线②(指标含义+无 GPU 估算)。
十六、高频面试题速记卡
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》自测
📌 待查★ 重要