AI 应用负载均衡:普通服务看轮询,推理服务看聪明调度

负载均衡是分布式系统的基础设施，但在 AI 应用里有一个特殊问题：普通服务的负载均衡技术，放到推理服务上会失效。这篇文章讲清楚：非推理服务的负载均衡怎么做、推理服务为什么不一样、两种新方案怎么选。

一、非推理服务负载均衡

1. 负载均衡系统分类

• 四层负载均衡软件：基于 IP/端口转发，性能高
• 七层（反向代理类）：基于 HTTP 内容（URL、Header）转发，功能强

2. 负载均衡算法

3. 广义负载均衡：不只是"分发"

完整的负载均衡必须包含故障处理恢复机制：

故障自动发现 → 故障服务自动摘除 → 请求自动重试 → 服务恢复自动发现

案例：AI 智能体业务逻辑层某实例故障

谁来发现？→ API 网关层 / 注册中心（心跳检测）   发现后 → 自动摘除故障实例，请求不再发给它   已有请求 → 自动重试到健康实例    恢复后 → 注册中心自动发现，重新加入负载

加上熔断机制：下游持续故障时先熔断（快速失败，不再打爆故障服务），熔断后恢复机器：

物理机/虚拟机 → 杀掉进程重启    容器化环境   → 杀掉容器重新拉起

二、推理服务负载均衡：传统技术为什么失效？

传统方案（如轮询）的假设

每个用户请求对服务器的资源消耗相差不大请求执行速度快、消耗资源少    请求数量足够 → 各服务器负载相近 → 整体均衡

传统应用场景下，这个假设成立，轮询好用。

推理场景的变化

不同的请求对推理服务器的资源消耗差异很大     → 有的请求生成 100 个 Token，有的生成 10,000 个     请求执行时间长（秒级到分钟级）    消耗资源高（显存、算力）

结果：如果还用轮询——短请求分到的服务器早干完了闲置，长请求分到的服务器堆积过载，部分过载、部分闲置，整体吞吐上不去，SLO 没法保证。

三、推理服务新负载均衡：两种方案

方案一：基于代价估算的方案

接入服务 → 全局调度器      ↓      调度器用小模型快速估算每条请求的 Token 数量（代价）      ↓    根据估算代价 + 服务器负载 → 全局分发

优点：

• 分发时能考虑 KV Cache 亲和性：多轮对话分发到同一台推理服务器，复用之前的 KV Cache，减少重复计算

缺点：

• 调度逻辑复杂：要考虑服务器负载、请求估算代价、KV Cache 亲和性多指标
• 全局调度器是孤点：有性能瓶颈，需要高可用设计
• 估算模型有偏差时，会导致负载不均

方案二：基于拉取的模型

接入服务不直接把请求转发给推理服务    ↓   把请求放入缓存中间件的 Stream 结构中     ↓   推理服务空闲时，主动去拉取请求处理

优点：

• 实现简单
• 推理服务永远在最佳负载下运行（忙完才拉新的）
• 服务器间负载均衡，整体吞吐很高

缺点：

• 很难保持 KV Cache 亲和性（多轮对话可能被不同服务器拉走）
• 后续优化手段有限

四、怎么选？

选择依据：具体业务需求和系统架构。多轮对话型应用（聊天、客服、导购）倾向代价估算方案；对 KV Cache 不敏感的高吞吐场景（单轮问答、批量任务）倾向拉取模型。

写在最后

AI 应用负载均衡的关键认知：

• 普通服务：轮询就够，配上故障发现/摘除/重试/恢复的广义机制
• 推理服务：请求代价差异巨大，轮询必翻车——要么按"估算代价"聪明分发，要么"空闲自取"保最佳负载
• KV Cache 亲和性是推理负载均衡独有的新维度：多轮对话复用缓存，省的是真金白银的算力

负载均衡不是"把请求撒出去"，是"让每一份算力都物尽其用"。