推理系统设计面试题
Q1: 设计一个高并发LLM推理服务
答：
架构：
┌──────────────────────────────────────┐
│ 负载均衡 (Nginx/Envoy) │
├──────────┬──────────┬────────────────┤
│ vLLM-0 │ vLLM-1 │ vLLM-2 │
│ GPU:0,1 │ GPU:2,3 │ GPU:4,5 │
└──────────┴──────────┴────────────────┘
↓ ↓
Redis (缓存) PostgreSQL (持久化)关键设计：
- Continuous Batching：动态合并请求
- KV Cache管理：PagedAttention分页
- 请求队列：优先队列（高优先/低延迟）
- 流式输出：SSE/WebSocket
- 限流：token bucket algo
监控：
- TTFT (首token延迟)
- TPOT (每token延迟)
- Throughput (tokens/s)
- GPU利用率
Q2: Continuous Batching vs Static Batching
| Static Batching | Continuous Batching |
|---|---|
| 等所有请求完成后才能加新请求 | 每步可加入新请求 |
| 短板效应（等最长的） | 没有短板等待 |
| 利用率低 | 利用率高 |
| 实现简单 | 需要KV Cache精细管理 |
Q3: 模型量化的选择？
FP16：无损，2x压缩，通用
INT8：微损，4x压缩，适合通用部署
INT4(GPTQ/AWQ)：中损，8x压缩，显存受限时
选择建议：
- 多GPU → FP16
- 单GPU大模型 → INT4
- 平衡 → INT8Q4: 如何解决冷启动问题？
- 模型预热：启动时跑几个dummy请求
- 模型缓存：常驻内存
- 懒加载：按需加载LoRA adapter
- 分层启动：先加载tokenizer，再加载模型
Q5: 多模型调度策略？
方案：
1. 固定分区：每个GPU固定一个模型
2. 动态切换：GPU在不同模型间切换（冷启动问题）
3. 模型池：预加载常用模型，按需分配GPU
4. LoRA切换：基座模型不变，只换LoRA权重（推荐）