Interview: 如何设计一个能处理异构请求（不同长度、不同模型）的LLM推理集群？
题目解析
实际生产环境中的推理集群面临多维异构性：请求长度从几十到几万token不等，需要服务多个不同大小的模型，硬件也可能异构（A100/H100混合）。如何设计调度策略和资源管理机制来最大化整体吞吐量和资源利用率，同时满足不同请求的SLA要求，是一个复杂的系统设计问题。
解答思路
核心架构设计：1）路由层——根据请求特征(模型、长度、优先级)路由到对应的worker pool；2）模型放置策略——热门模型常驻GPU，冷门模型按需加载或使用LoRA切换；3）请求调度——长请求和短请求分开调度避免队头阻塞；4）弹性伸缩——监控队列深度自动扩缩容。关键设计决策：是否让一个GPU同时服务多个LoRA adapter（共享base模型）？是否将prefill和decode分离到不同GPU池？
关键要点
- S-LoRA方案：一个base模型GPU可以同时挂载数百个LoRA adapter，通过unified paging管理adapter权重
- 长短请求分离：短请求（<1K token）追求低延迟，长请求（>10K token）追求高吞吐
- 预测输出长度辅助调度：训练一个小模型预测请求的输出长度，优化调度决策
- 故障容错：GPU故障时的请求迁移和KV Cache重建策略
加分回答
可以参考Alpa、AlpaServe的设计理念——自动搜索最优的并行策略组合(TP/PP/DP)来适配异构硬件。还可以讨论model multiplexing技术：通过快速模型切换在一组GPU上轮流服务多个模型，结合请求到达的时间规律（如不同时区的用户）来优化切换调度。另外KV Cache的跨节点迁移也是实现请求漂移(request migration)的关键技术。
常见踩坑
- 简单的轮询负载均衡不考虑请求长度差异，导致严重的负载不均
- 忽略模型加载的冷启动时间——大模型加载需要数十秒
- 过度优化峰值吞吐忽略了尾部延迟，导致SLA违约