单体 vs 微服务：LLM 推理服务架构选型与 LLM Twin 实践

一、推理服务的核心挑战：吞吐量与延迟的权衡在部署大语言模型（LLM）推理服务时，首先需要明确四个关键要求：吞吐量、延迟、数据和基础设施。它们相互制衡，直接影响用户体验。吞吐量：系统在单位时间内能处理的推理请求数，通常以 RPS（每秒请求数）衡量。高吞吐量需要强大的 GPU 集群和并行处理能力。延迟：单个请求从发出到收到结果的耗时。实时应用（如聊天机器人）要求低延迟，通常需要对网络 I/O、序列化/反序列化、模型推理等环节进行优化。数据：模型输入输出的格式、体积和复杂度。文本、图像或结构化数据对硬件配置和优化策略有不同要求。基础设施：包括计算资源（CPU/GPU）、内存、存储和网络。为高吞吐量需要可扩展的 GPU 集群，为低延迟需要更快的处理器（如 NVIDIA A100）甚至边缘计算。一个常见的误区是：吞吐量越高，延迟越低。但引入批处理后，延迟可能上升而吞吐量也上升，必须根据应用场景权衡。例如，单次 100ms 的批处理（处理 20 个请求）可达到 200 RPS；如果要求 10ms 延迟，则只能串行处理，吞吐量降至 100 RPS。二、三种基本部署类型根据延迟、吞吐量、数据和基础设施的不同优先级，推理服务可分为以下三种类型：类型延迟要求典型场景优缺点在线实时推理极低（毫秒级）聊天机器人、实时推荐交互性好，但资源利用率低、成本高