部署与推理优化题

一、部署系统设计框架

面试中遇到部署/推理优化系统设计题，使用以下框架：

需求分析：模型大小、QPS、延迟 SLA、预算
硬件选型：GPU 类型、数量
推理引擎：vLLM / TensorRT-LLM / SGLang
优化技术：量化、KV Cache、批处理、推测解码
系统架构：负载均衡、自动扩缩容、监控

二、典型面试题

题目 1：设计一个高吞吐 LLM 服务

问题："如何设计一个服务 70B 模型、支持 1000 RPS、P99 延迟 < 2 秒的系统？"

回答框架：

硬件选型：

70B INT4 模型：~35 GB 权重
单 GPU 推理：需要 1x A100 80GB（含 KV Cache）
1000 RPS 估计需要 8-16 GPU（取决于上下文长度）

推理引擎：

选择 vLLM：PagedAttention + 连续批处理
配置前缀缓存（共享系统提示的 KV Cache 复用）

量化策略：

AWQ 4-bit 量化：质量损失极小
如延迟要求更严：FP8（H100）

系统架构：

用户请求 -> 负载均衡 -> 多个 vLLM 实例
                      -> 共享 KV Cache (前缀缓存)
                      -> 自动扩缩容 (K8s + KEDA)

监控指标：

TTFT, TPOT, E2E 延迟
GPU 利用率、显存使用
QPS, 错误率
每 token 成本

题目 2：如何降低推理延迟

问题："TTFT 太高怎么办？推理吞吐太低怎么办？"

回答框架：

降低 TTFT（预填充优化）：

量化模型减少计算量
分离式 Prefill/Decode（专用 GPU 处理 prefill）
减少输入上下文长度（截断/摘要）
前缀缓存（复用共享 prompt 的 KV Cache）
使用更高效的注意力实现（FlashAttention）

提升吞吐（解码优化）：

连续批处理（vLLM/TensorRT-LLM）
推测解码（小模型草稿 + 大模型验证）
更大批处理（GPU 利用率提升）
MoE 架构（减少每 token 计算量）
多节点并行推理（tensor parallelism）

降低成本：

量化（INT4/INT8）
模型蒸馏（大模型 -> 小模型）
请求路由（简单请求 -> 小模型）
Spot 实例 + 自动扩缩容
语义缓存（相似请求复用响应）

题目 3：量化方案选择

问题："GPTQ vs AWQ vs GGUF 怎么选？"

回答框架：

方案	最佳场景	优势	劣势
AWQ	GPU 服务端推理	质量最好	需要校准数据集
GPTQ	GPU 服务端推理	通用性好	质量略低于 AWQ
GGUF	本地/CPU/混合	灵活，跨平台	GPU 推理不如 AWQ 快
FP8	H100/B200	硬件原生支持	需要最新硬件
SmoothQuant	W8A8 场景	权重+激活都量化	精度限制

选择建议：

云端 GPU 服务：AWQ 4-bit（质量最好）
本地开发/边缘：GGUF（最灵活）
最新硬件：FP8/FP4
极端成本：GPTQ 4-bit

题目 4：多租户 LoRA 服务设计

问题："如何同时服务 1000 个不同的 LoRA 适配器？"

回答框架：

核心挑战：

每个适配器虽然小（10-100MB），但 1000 个就是 10-100GB
动态加载/卸载的开销
不同适配器请求的批处理

解决方案：S-LoRA / LoRAX

共享基座模型（常驻 GPU）
适配器统一存储（SSD/内存）
动态加载：请求到来时将对应适配器加载到 GPU
统一批处理：将使用同一适配器的请求批量处理
PagedAttention 管理不同请求的 KV Cache

架构：

请求 -> 路由层（识别 tenant_id -> 映射 adapter_id）
     -> LoRA 调度器（检查 adapter 是否在 GPU）
       -> 已加载：直接推理
       -> 未加载：从存储加载到 GPU（可能需驱逐旧 adapter）
     -> 批处理推理
     -> 响应

三、其他高频问题

Q: "PagedAttention 是什么？" "A: vLLM 的核心创新。将 KV Cache 按固定大小的 block 管理，类似操作系统的虚拟内存分页。解决了传统 KV Cache 的内存碎片问题，将 GPU 内存利用率从 60-80% 提升到 95%+。支持不同请求的 KV Cache 灵活分配和共享。"

Q: "推测解码的原理？" "A: 用小模型（草稿模型）快速生成 K 个候选 token，大模型一次性并行验证。匹配的 token 直接接受，第一个不匹配的位置之后重新生成。输出与大模型直接生成完全一致（无损）。加速比取决于小模型和大模型的一致率，通常 2-3x。"

Q: "如何做自动扩缩容？" "A: 基于 GPU 利用率和请求队列深度自动扩缩容。使用 KEDA（K8s Event-driven Autoscaling）监控 vLLM 的请求队列长度，超过阈值自动扩容 GPU Pod。冷却期设置防止抖动。使用 Spot 实例降低成本。"