部署LLM时，针对不同的工作场景应该如何优化部署方案？这篇Modal 发布的文章，主要探讨了 LLM 应用中三类不同的工作负载及其对应的工程优化方案。
modal.com/llm-almanac/workloads

随着开源模型（如 DeepSeek、Qwen）和推理引擎（如 vLLM、SGLang）的崛起，工程师需要深入理解不同的工作负载，以实现架构的最优化。

1. 离线/分析型工作负载
场景：批量处理数据集、视频转录摘要、大规模数据清洗。
核心需求：吞吐量高于一切。单次请求的延迟不重要，重要的是单位美元处理的 Token 数。
技术建议：
推荐使用 vLLM。它在混合批处理（Mixed Batching）和分块预填充（Chunked Prefill）的调度算法上表现更优。
策略：通过异步 RPC 发送大批量任务；尽量减少单个副本的 GPU 数量，以确保 GPU 算力被充分占满，多余资源用于开启更多副本。
硬件：老旧 GPU 往往性价比更高。

2. 在线/交互型工作负载
场景：聊天机器人、AI 辅助编程（如代码补全）、语音交互。
核心需求：低延迟（Latency）。需要在几百毫秒内响应。
挑战与对策：
宿主开销：Python 层的处理可能阻塞 GPU。推荐使用 SGLang，其宿主开销通常更低。
通信开销：网络延迟是瓶颈。应在接近用户的“边缘”部署推理资源。
多轮对话：通过“前缀感知路由”（Prefix-aware routing）来利用 KV 缓存（KV Cache），减少重复计算。
内存带宽限制：使用最新的 GPU（如 H100、B200）并采用张量并行（Tensor Parallelism）和投机采样（Speculative Decoding）。

3. 半在线/突发型工作负载
场景：从数据流中提取结构化信息（如处理 Slack 消息或 GitHub 事件）。
核心需求：弹性（Flexibility）。负载具有不确定性，需要处理瞬时的突发流量。
技术建议：
使用任何一种引擎，但关键在于极速的自动缩放（Autoscaling）。
架构需要能够处理不同副本之间极不均衡的负载。

#HOW I AI#