在生产级 AI 服务中，单一模型推理往往无法满足多租户、多场景的业务需求。企业通常部署数十个不同规模、不同架构的模型来应对搜索增强、代码生成、多模态理解等差异化场景。这种多模型并存的环境下，如何实现高效的请求分发与资源调度，成为影响服务可用性与成本效率的核心挑战。本文将从请求分发算法、模型异构性处理、动态扩缩容三个维度，系统阐述多模型推理集群的负载均衡工程实践。

请求分发算法的选型与配置参数

传统负载均衡算法在多模型推理场景下面临根本性挑战。简单的轮询（Round Robin）无法感知后端实例的实时负载与模型复杂度差异；最少连接数（Least Connections）算法虽然在通用 HTTP 服务中表现良好，但对推理请求的执行时长缺乏预判能力 —— 一个复杂的长序列推理任务可能占用 GPU 长达数十秒，而简单的对话补全可能只需数百毫秒，两者对后端负载的影响天差地别。

加权最小连接数（Weighted Least Connections） 是更适用于多模型场景的基线方案。该算法在最小连接数的基础上引入权重因子，允许运维人员根据模型的实际资源消耗特征为每个模型 - 实例组合分配合适的权重值。典型的权重配置需要考虑三个维度：模型参数量级（如 7B、70B、700B 模型分别赋予权重 1:10:100）、批处理能力（支持更大 batch 的实例获得更高权重）、以及硬件差异（A100 与 H100 的吞吐量比值约 0.7:1）。在实际配置中，建议将权重计算公式化为：effective_weight = base_weight * (gpu_memory_gb / model_memory_requirement) * (max_batch_size / current_batch_size)，其中 base_weight 根据模型架构预设，后续因子动态调整。

Power of Two Choices（P2C）算法 是近年来在推理服务中广泛采用的更先进方案。该算法在每次请求到来时，随机选择两个后端实例，比较其当前负载指标后选择较轻的一个。Google VLLM 项目的实践表明，P2C 在模型推理场景下可以将请求分布的方差降低 60% 以上，因为推理任务的执行时长具有高度不确定性，随机采样可以有效避免热点问题。VLLM 官方推荐的 P2C 实现中，负载指标应综合考虑三个因子：当前在队列中的请求数（queue_length）、预估的请求执行时间（通过历史执行数据拟合）、以及 GPU 利用率。权重计算建议使用 score = queue_length * avg_latency + gpu_utilization * 0.3，选择 score 最低的实例。

上下文感知的自适应分发 是更进一步的优化方向。在推理请求中，输入序列长度、输出最大 token 数、是否为流式输出等参数都会显著影响资源占用与执行时长。理想的分发策略应当在请求进入队列时即可预判其资源需求。工程实现上，建议在请求路由层增加预处理阶段：根据输入 token 数乘以每 token 预估计算量（不同模型架构有不同的系数，如 LLaMA 系列约为 0.5 GFLOPS/token/GPU）计算预估执行时间，将其作为路由决策的第四个因子纳入 P2C 算法。

模型异构性处理：从资源隔离到优先级调度

多模型集群中往往同时运行参数量差异巨大的模型，从 embedding 模型的几十亿参数到大规模语言模型的数千亿参数。这种异构性带来三个核心工程挑战：显存争抢、计算资源隔离、以及不同 SLO 要求下的优先级调度。

显存资源隔离 是首要问题。不同模型对 GPU 显存的需求差异显著 —— 一个 70B 模型在 FP16 精度下需要约 140GB 显存（超出单卡上限，需要张量并行），而 7B 模型仅需 14GB。在同一 GPU 上混合部署多个模型时，必须通过显存预留（memory reservation）机制防止显存溢出。推荐配置参数如下：每个 GPU 的显存保留阈值为总显存的 5%–8%（如 40GB 卡保留 2–3GB），用于 CUDA 运行时与中间结果缓冲；模型加载时采用分片加载策略，确保单模型显存占用不超过单卡可分配容量的 70%；当单卡部署多模型时，使用 NVIDIA MPS（Multi-Process Service）实现计算时间片轮转，但需注意 MPS 会引入约 3%–5% 的性能开销。

计算资源的时间片隔离 同样重要。在推理集群中，典型场景是多个小模型共享同一 GPU 而大模型独占 GPU。共享 GPU 时，推荐使用 NVIDIA Time-Slicing 机制，将 GPU 资源按时间片分配给不同模型。该机制的配置参数包括：时间片时长（建议 10–50ms，过短会增加调度开销，过长会导致长尾请求响应延迟）、优先级权重（高优先级模型获得更多时间片）、以及抢占策略（是否允许高优先级请求中断正在执行的低优先级任务）。对于延迟敏感型业务（如实时对话），建议将时间片缩短至 10ms 并开启抢占；对于吞吐量优先型业务（如批处理推理），可放宽至 50ms 并关闭抢占。

优先级队列与抢占机制 是保障不同 SLO 的关键。生产环境中，搜索、对话等在线业务的延迟要求通常在 200ms 以内，而离线批处理、数据预处理等任务的延迟容忍度可达分钟级。负载均衡层需要实现多级优先级队列：建议配置至少三级优先级（priority_high: 延迟敏感，priority_normal: 标准推理，priority_batch: 批处理），每级队列内部仍使用 P2C 算法分发。抢占策略建议采用非抢占式与抢占式混合模式：高优先级请求进入队列时，若当前 GPU 正在执行低优先级任务，不强制中断，而是在下一个计算迭代完成后立即切换（通过 CUDA 流的优先级机制实现）。该策略可以将高优先级请求的 P99 延迟降低 40% 以上。

动态扩缩容：指标选取与触发策略

多模型推理集群的流量特征通常呈现显著的日周期性与突发性。白天高峰期可能需要数百个推理实例，夜间低谷期可能仅需数十个。高效的动态扩缩容可以在保障服务质量的前提下显著降低资源成本。

扩缩容指标的选取 直接决定调度策略的有效性。传统 CPU 利用率指标在 GPU 推理场景下代表性不足 ——GPU 计算密集型任务的 CPU 利用率可能仅为 20%–30%，但 GPU 利用率已接近饱和。推荐的核心指标组合包括：GPU 利用率（目标阈值 70%–85%，超过 85% 触发扩容，低于 70% 触发缩容）、请求队列长度（超过预设阈值如 100 个请求时触发扩容）、Token 吞吐量（每秒处理的 token 数持续低于目标值的 60% 时触发缩容）、以及 P99 延迟（连续 5 分钟超过 SLO 目标的 1.5 倍时触发扩容）。指标采集窗口建议设置为 60 秒滑动平均，以过滤瞬时波动。

水平扩容的触发策略 需要平衡响应速度与资源浪费。激进扩容虽然响应快，但容易在流量高峰后造成资源闲置；保守扩容则可能导致服务质量下降。推荐采用分层触发机制：第一层预警当 GPU 利用率连续 3 分钟超过 75% 时发出扩容预警；第二层触发当利用率超过 85% 或队列长度超过 200 时正式触发扩容，扩容步长为当前实例数的 20%–30%；第三层应急当队列长度超过 500 或 P99 延迟超过 SLO 的 2 倍时，执行最大幅度的紧急扩容（50% 实例数增量），同时触发告警。缩容策略应当更为保守，建议在利用率低于 40% 且持续 15 分钟以上时触发，缩容步长为 10%–15%，以防止流量突增时资源不足。

垂直扩容在推理场景中同样重要。不同于传统微服务的垂直扩容（CPU / 内存规格调整），推理集群的垂直扩容主要指 GPU 资源升级与模型实例的资源再分配。当某模型实例频繁触发扩容阈值时，应考虑将该模型迁移至更强大的 GPU（如从 H20 迁移至 H100），或将张量并行度从 1 提升至 2。垂直扩容的触发判断条件为：连续 1 小时内扩容触发次数超过 5 次，或单实例日均处理请求量超过 10 万且延迟持续接近 SLO 上限。

工程落地：监控、告警与回滚

负载均衡策略的有效性最终体现在监控体系的完善程度与响应速度。多模型推理集群的监控应覆盖四个层面：入口层（请求到达率、分发成功率、错误率）、路由层（各模型队列长度、分发延迟、实例健康状态）、计算层（GPU 利用率、显存占用、Token 吞吐、推理延迟分布）、以及资源层（实例数、扩缩容事件、资源利用率）。

核心告警规则 建议配置如下：P99 延迟超过 SLO 目标（2 倍）持续 5 分钟为严重告警，需立即响应；GPU 利用率持续 15 分钟超过 90% 为警告告警，考虑扩容；请求队列长度超过 500 为警告，超过 1000 为严重；扩缩容触发频率过高（每小时超过 10 次）需要检查策略配置是否合理。

回滚机制 是保障线上稳定性的最后防线。任何负载均衡策略的变更（如算法切换、权重调整、阈值修改）都应当灰度发布：先在 5% 的流量上验证新策略的效果，观察 30 分钟无异常后逐步扩大至 20%、50%、100%。同时保留旧策略的配置参数，支持一键回滚。回滚触发条件建议设为：P99 延迟上升超过 30%、错误率上升超过 0.5%、或任何服务不可用事件。

总结

多模型推理集群的负载均衡是一个多层次的系统工程。在请求分发层面，P2C 算法配合上下文感知权重可以显著提升请求分布的均匀性；在异构处理层面，显存隔离、时间片轮转、多级优先级队列保障了不同模型与不同 SLO 要求的共存；在动态扩缩容层面，综合 GPU 利用率、队列长度、延迟等多维指标的触发策略，可以在保障服务质量的同时实现资源成本的最优化。工程实践中，监控体系的完善程度与回滚机制的建设质量，往往决定了负载均衡策略能否在生产环境中安全落地。

参考资料