分布式AI推理基础：推理服务架构、请求处理流程与性能指标
在讨论自动扩缩容之前，必须先建立对分布式AI推理服务本身的清晰认知。扩缩容的本质是“根据负载动态调整资源”，而负载的形态、资源的瓶颈、以及服务质量的好坏，全部由推理服务的架构与请求处理链路决定。如果脱离这些基础去谈扩缩容策略，很容易陷入“只加机器、不解决问题”的误区。本章将围绕推理服务的典型架构、一次请求的完整生命周期，以及衡量系统健康度的三大类性能指标展开，为后续的调优与自动扩缩容设计奠定共同的语义基础。
2.1 推理服务架构：从单体到分布式
生产环境中的分布式AI推理服务通常不是单一组件，而是由多个职责不同的模块组成的系统。理解这些模块的边界与协作关系，是定位瓶颈、设计扩缩容策略的前提。下图展示了一个典型的分布式推理服务架构，重点标出了请求入口、调度层、推理引擎与状态存储之间的连接关系。
该架构中，API网关负责统一的入口控制，包括身份验证、流量限速和协议适配；推理调度器是核心决策节点，它根据队列长度、实例健康状态和模型版本，决定将请求分发到哪个具体的推理引擎实例；推理引擎实例组是真正执行模型前向计算的部分，通常运行在GPU或NPU上；状态存储用于记录实例的注册信息、心跳和实时负载，为调度器提供决策依据；监控与指标采集则独立于请求链路，持续收集吞吐、延迟和资源使用数据，是自动扩缩容控制器的“眼睛”。
需要特别指出的是，推理引擎实例组是扩缩容的主要对象。每个实例通常对应一个模型副本，加载了相同的模型权重，但可能配置了不同的批处理大小（batch size）或并发上限。实例的启动与关闭并非瞬时完成——加载一个数GB的大语言模型到GPU显存可能需要数十秒甚至数分钟，这直接决定了扩缩容策略必须具有“提前量”，而不能等到请求堆积后才开始扩容。
2.2 推理请求处理流程：一次请求的完整生命周期
理解请求如何穿过上述架构，是分析延迟瓶颈和设计弹性策略的关键。一次典型的分布式推理请求处理流程可以划分为以下六个阶段：
- 客户端发起请求：客户端通过HTTP/gRPC将输入数据（如文本、图像张量）发送至API网关。
- 网关预处理：网关完成身份验证、请求大小检查、限流判断，并将请求转换为内部统一的RPC格式。
- 调度器排队与路由：调度器将请求放入优先级队列，根据实例的当前负载（如GPU利用率、排队长度）和亲和性策略，选择一个目标实例。
- 推理引擎执行：目标实例接收请求后，进行数据预处理（tokenization、归一化）、模型前向计算、后处理（softmax、采样）。这是计算最密集的阶段。
- 响应返回：推理结果经调度器、网关逐级返回客户端。
- 指标上报：各阶段产生的耗时、错误码、资源消耗数据异步上报至监控系统。
从性能分析的角度，上述流程可以简化为两个关键区间：排队等待时间（请求到达调度器到开始被实例处理之间的时间）和推理执行时间（实例实际计算所花费的时间）。两者之和构成了用户感知的端到端延迟。自动扩缩容的核心目标之一，就是通过调整实例数量，将排队等待时间控制在合理范围内，同时避免因实例过多导致资源闲置。
2.3 性能指标：吞吐量、延迟与资源利用率
性能指标是扩缩容决策的“输入信号”。如果指标定义不清晰或采集口径不一致，任何自动扩缩容算法都会失去意义。本节定义三个最核心的指标族，并说明它们之间的相互制约关系。
2.3.1 吞吐量（Throughput）
吞吐量指系统在单位时间内成功处理的请求数或Token数。在AI推理场景中，常用的吞吐量单位包括：
- QPS（Queries Per Second）：每秒处理的完整请求数，适用于图像分类、目标检测等短请求场景。
- Tokens/s：每秒生成的Token数，更适用于大语言模型的流式生成场景，因为单个请求可能生成数百个Token。
- Batch Size × 并发数：在离线批处理场景下，吞吐量通常表示为“每秒处理的样本总数”。
吞吐量是扩容决策中最直接的“业务压力”信号。当QPS持续超过当前实例组的承载上限时，系统必然出现排队和超时，此时扩容是必要的。
2.3.2 延迟（Latency）
延迟是用户可感知的服务质量核心指标。在分布式推理中，需要区分以下延迟口径：
| 延迟类型 | 定义 | 扩缩容关联性 |
|---|---|---|
| 端到端延迟 | 客户端发出请求到收到完整响应的时间 | 受排队和推理执行共同影响 |
| 排队延迟 | 请求在调度器队列中等待的时间 | 随实例数增加而显著下降 |
| 推理延迟 | 实例执行模型前向计算的时间 | 与实例规格、batch size相关，扩容不直接改善 |
| P99 / P95 延迟 | 排序后处于99%/95%分位的延迟值 | 反映长尾效应，扩缩容需关注此值而非平均值 |
在自动扩缩容设计中，P99延迟通常被用作SLO（服务等级目标）的判定依据。例如，设定“P99延迟小于500ms”作为目标，当P99延迟持续超过该阈值时触发扩容。
2.3.3 资源利用率（Resource Utilization）
资源利用率反映实例对硬件（GPU、CPU、内存、显存）的使用效率。常见的利用率指标包括：
- GPU利用率：GPU计算核心的忙碌百分比，是判断算力是否饱和的关键。
- 显存占用率：已用显存占总显存的比例。显存不足会导致模型加载失败或OOM（内存溢出）。
- CPU利用率：数据预处理、后处理阶段的CPU消耗。
- 端到端资源效率：吞吐量除以资源总量，用于评估单位资源的产出。
资源利用率与扩缩容的关系需要辩证看待：利用率过低（如GPU利用率长期低于30%）意味着资源浪费，应触发缩容；利用率过高（如持续超过90%）则可能导致延迟飙升，应触发扩容。但利用率并非唯一依据——如果请求量很小但单个请求计算量极大，即使GPU利用率高，扩容也未必能改善延迟，因为瓶颈可能在单卡算力上限。
2.4 案例：一个在线翻译服务的指标联动分析
假设我们运维一个基于Transformer的在线翻译服务，部署在4个GPU实例上。某日监控数据如下：
时间: 14:00 - 14:10
QPS: 1200（持续上升）
P99 延迟: 850ms（SLO目标为500ms）
GPU 利用率: 平均 95%
显存占用: 平均 70%
排队长度: 调度器队列平均 200 个请求分析：QPS上升导致排队长度增加，P99延迟超标；GPU利用率已达95%，说明现有实例的计算能力已接近饱和。此时扩容是正确选择——增加2个实例后，QPS被分散到6个实例上，排队长度下降，P99延迟回落至420ms，GPU利用率降至75%。
但若监控数据变为：GPU利用率仅40%，P99延迟却高达800ms，则问题可能出在调度器配置（如批处理大小不合理）或模型本身计算效率低，此时盲目扩容只会增加成本，无法解决延迟问题。