# FDE W8D1 评测题 · vLLM 服务化部署与压测

> 配套手册：《FDE-W8D1-vLLM服务化实验-学习手册.html》
> 候选人背景：36 岁，Java + 大数据 + 医疗保险；冲刺高级 / 架构 / 负责人岗。
> 共 13 题，分 L1 基础 / L2 进阶 / L3 深度 / L4 场景。每题含考察点、评分维度、折叠参考答案。
> 场景默认结合：特药理赔 Agent、企业 Agent 平台。

---

## L1 基础（概念清楚即可）

### 1. 一句话解释 PagedAttention 解决了什么问题？
- **考察点**：vLLM 核心原理、与传统 KV 预分配的区别。
- **评分维度**：是否点出"显存碎片 / 利用率（30%→90%+）"；是否类比虚拟内存分页。
<details>
<summary>参考答案</summary>

传统方案按 max_length 为每请求预分配连续 KV 显存，导致严重碎片、利用率仅约 30%。PagedAttention 借鉴操作系统虚拟内存分页，把 KV Cache 切成 block 按需分配、可非连续拼接，利用率提升到 90%+，同样显存能扛更多并发。

</details>

### 2. vLLM 起的服务怎么和现有 OpenAI 客户端代码对接？
- **考察点**：OpenAI 兼容 API 的理解、迁移成本。
- **评分维度**：能否说清 base_url 指向本地、api_key 设 EMPTY、业务代码零改动。
<details>
<summary>参考答案</summary>

vLLM 暴露与 OpenAI 完全兼容的端点（/v1/chat/completions 等）。把 OpenAI 客户端的 `base_url` 指向 `http://host:8000/v1`、`api_key="EMPTY"` 即可，RAG / Agent 业务代码无需改动。这也是私有部署能平滑替换 SaaS 的关键。

</details>

### 3. fp16 / int8 / int4 三种量化，对显存和精度的影响分别是什么？
- **考察点**：量化基础概念。
- **评分维度**：是否给出量级（int4 约 0.5B/参数）；是否提到精度损失递增。
<details>
<summary>参考答案</summary>

fp16 每参数 2 字节、几乎无损；int8 约 1 字节、损失很小；int4（AWQ/GPTQ）约 0.5 字节、损失可控但明显。显存与精度此消彼长，int4 最省但需评测集验证不掉点。

</details>

---

## L2 进阶（能讲清参数与权衡）

### 4. 启动 vLLM 时 --max-model-len 设太大或太小分别有什么后果？
- **考察点**：长度参数与显存/并发的三角约束。
- **评分维度**：是否联系 KV Cache 显存峰值；是否提到 finish_reason=length 截断。
<details>
<summary>参考答案</summary>

设太大：KV Cache 显存峰值与长度成正比，单卡并发骤降、成本翻数倍，甚至 OOM。设太小：长文档/多轮被截断，业务侧需检查 `finish_reason=="length"`。应按真实文档长度定，不拍脑袋设 128K。

</details>

### 5. --max-num-seqs 和 --request-rate 分别控制什么？两者为何不能混为一谈？
- **考察点**：并发与速率两个维度。
- **评分维度**：是否区分"同时处理数"与"发压速度"；是否提到限速/放开对 P99 的不同影响。
<details>
<summary>参考答案</summary>

--max-num-seqs 是并发上限（同时处理的请求数），--request-rate 是压测发压速度。限速下并发可能很低但延迟好；限速放开并发飙但 P99 爆。容量规划看的是"某 SLA 下的并发上限"，不是裸跑最高速。

</details>

### 6. 精确区分 TTFT、TPOT、ITL 三个指标，各自衡量什么？
- **考察点**：核心性能指标定义（面试必考）。
- **评分维度**：TTFT 含排队+prefill、TPOT 是平均、ITL 是逐次（看抖动）；是否提到 P99。
<details>
<summary>参考答案</summary>

TTFT=首字延迟（含排队+prefill），管"卡不卡才开始"；TPOT=每输出 token 平均间隔（解码均速）；ITL=相邻 token 逐次间隔，P99 更能反映流式卡顿抖动。三者要分开约束 SLA。

</details>

### 7. benchmark_throughput 和 benchmark_serving 有什么用途差异？
- **考察点**：vLLM 压测工具链。
- **评分维度**：是否指出 serving 才输出 TTFT/TPOT/ITL 等生产指标；是否提到数据集选择。
<details>
<summary>参考答案</summary>

benchmark_throughput 看纯吞吐；benchmark_serving 模拟生产请求、输出 TTFT/TPOT/ITL 等用户感知指标，并支持 --request-rate/--save-result。写容量报告要用 serving，且固定数据集（sharegpt 优于 random）并落盘。

</details>

---

## L3 深度（能推导与辨析）

### 8. 估算一个 Qwen2.5-32B-int4 在单卡 24G 上的可行性（显存与吞吐）。
- **考察点**：显存与吞吐公式估算、假设声明。
- **评分维度**：权重≈16G 计算对；指出剩 8G 仅能极低并发；吞吐用参数量反比推算并标注"未实测"。
<details>
<summary>参考答案</summary>

权重显存 ≈ 32e9 × 0.5B ≈ 16GB，fp16 则约 64GB。单卡 24G 装下 int4 权重后剩约 8G 给 KV/激活，仅能极低并发。吞吐按"同卡同量化下与参数量近似反比"：若 7B-int4 实测 ~60 tok/s/请求，则 32B 约 ~13 tok/s/请求（量级参考，未实测，生产前需校准）。注：若为 MoE（如 DeepSeek）激活参数远小于总参，不能简单按 32B 算。

</details>

### 9. 某压测报告写"平均 TTFT 0.8s，吞吐 900 tok/s"，你觉得还缺什么信息才可信？
- **考察点**：数据可信度、报告完整性。
- **评分维度**：是否要求 P99、测试环境（卡型/量化/长度/版本）、数据集、并发/速率设定、是否实测。
<details>
<summary>参考答案</summary>

缺：① P50/P90/P99（平均掩盖长尾）；② 测试环境（卡型、量化、max_model_len、vLLM 版本、驱动）；③ 数据集类型与规模；④ request-rate、num-prompts；⑤ 是否实测。无这些则数字不可比、不可信。

</details>

### 10. 为什么 PagedAttention 提升的是显存利用率而非模型算力？这对成本意味着什么？
- **考察点**：原理边界、成本关联。
- **评分维度**：是否说清它不改 FLOPs；是否推导出"同卡并发↑→单请求成本↓"。
<details>
<summary>参考答案</summary>

PagedAttention 解决显存碎片，不改变模型每次前向的 FLOPs。但它让同样显存承载更多并发请求，摊薄每张卡的固定成本（GPU 时租），从而降低单请求推理成本——这正是私有部署成本优势的来源之一。

</details>

### 11. int4 量化在医疗理赔场景可以直接上吗？要注意什么？
- **考察点**：量化落地的风险意识。
- **评分维度**：是否提到精度敏感链路保 fp16；是否提到需在评测集对比量化前后准确率；是否提到分层用模。
<details>
<summary>参考答案</summary>

不能直接全量上。理赔金额/诊断结论等精度敏感链路应保 fp16；摘要、分类等旁路可用 int4 降本。且必须在真实评测集上对比量化前后准确率，确认不掉点再上线。这是"质量 vs 成本"的分层权衡。

</details>

---

## L4 场景（结合实际业务设计/判断）

### 12. 场景：你要为"特药理赔 Agent"做私有化部署方案，客户数据不能出域。请说明你会怎么选模型、量化、长度与压测方法，并诚实说明无 GPU 时怎么给客户报性能。
- **考察点**：综合落地能力 + 数据诚实。
- **评分维度**：国产/开源模型选型（Qwen/DeepSeek）、私有部署合规卖点、量化取舍、长度设定、压测方法论、无 GPU 两步法（小模型实测+32B 公式估算并标假设）。
<details>
<summary>参考答案</summary>

选型：用 Qwen2.5 或 DeepSeek 等开源权重做私有部署，数据不出域（合规核心卖点）。量化：关键结论链路 fp16，旁路 int4。长度：按真实理赔材料长度设 max_model_len（如 16K），避免盲目设大。压测：用 benchmark_serving 固定 request-rate 出 TTFT/TPOT/ITL 的 P99 并落盘。

无 GPU 时诚实报法：① 用 Mac(Ollama qwen3:8b) 或 Colab 实测小模型，给出真实流程与基准数字；② 用"同卡同量化吞吐≈与参数量反比"推算 32B 量级，明确标注假设（卡型/量化/批/长度）与"未实测"；③ 报告分级（实测/估算/未知），绝伪造。

</details>

### 13. 场景：企业 Agent 平台要给多个租户提供模型服务，你发现高峰期 TTFT 从 0.5s 涨到 4s。请定位可能原因并给出排查与优化路径。
- **考察点**：线上问题定位 + 容量/队列思维。
- **评分维度**：是否区分"排队 vs prefill 慢"；是否提到 --max-num-seqs/队列、prefix caching、副本扩容、量化降本、限速与降级。
<details>
<summary>参考答案</summary>

定位：TTFT 含排队，高峰骤升多半是并发超 --max-num-seqs 触发排队，或长 prompt 扎堆导致 prefill 慢。排查：看队列长度、单请求输入长度分布、GPU 利用率。

优化：① 提高 --max-num-seqs（受显存约束）或加模型副本做负载均衡；② 开 --enable-prefix-caching 复用相同系统提示 KV；③ 对非关键链路用 int4 提并发；④ 入口做请求限速+优先级队列，超阈值降级到小模型/转人工；⑤ 用 Benchmark 复现并验证 P99 回到 SLA 内。

</details>

---

## 评分汇总表

| 层级 | 题号 | 主题 | 达标要求 |
|------|------|------|----------|
| L1 基础 | 1-3 | 原理/兼容/量化 | 概念准确，无硬伤 |
| L2 进阶 | 4-7 | 参数/指标/工具 | 能讲清权衡与口径 |
| L3 深度 | 8-11 | 估算/可信度/成本 | 能推导、能辨析、标假设 |
| L4 场景 | 12-13 | 理赔 Agent / 企业平台 | 综合落地 + 数据诚实 |

### 计分
- 每题按"概念准确度 / 完整性 / 业务结合度"三档：✅ 到位 / ⚠️ 部分 / ❌ 缺失。
- **达标线①（部署与关键参数）**：L1(1-3) + L2(4,5,7) 全 ✅，能完整讲出"装→起 API→量化/长度/并发→压测"流程。
- **达标线②（指标 + 无 GPU 估算）**：L2(6) + L3(8,9) + L4(12) 全 ✅，能精确定义 TTFT/TPOT/ITL 且能诚实估算 32B 并分级标注数据。
- 任一达标线出现 ❌ 即未达标，需回看对应手册章节重做自测清单。
