Google Cloud DNS 与传统 DNS 服务有什么区别，企业域名应该如何管理

当一个 AI 模型从单张 GPU 扩展到几十张、几百张甚至更多 GPU 时，系统首先遇到的并不是“如何把请求平均分配出去”这么简单的问题。对于传统 Web 服务来说，把请求按照轮询方式分配给多个服务器往往已经能够取得不错的效果，但大语言模型推理具有完全不同的资源特征。一条请求可能只需要几秒钟，也可能因为输入上下文很长、输出很多而持续占用 GPU 很长时间；有的请求主要消耗计算资源，有的请求则受到显存容量、显存带宽或者 KV Cache 的限制。

因此，AI 推理集群中的负载均衡，核心不是让每台 GPU 收到相同数量的请求，而是让请求、模型副本和 GPU 资源之间形成更加合理的匹配关系。

一、为什么请求数量相同不代表负载相同

假设一个集群有四台推理服务器，每台服务器当前都处理10个请求。从数字上看，负载完全平均。

但如果第一台服务器处理的是短文本生成，第二台服务器处理的是超长上下文，第三台服务器正在进行大量 token 的生成，第四台服务器刚刚完成大部分请求，那么这四台机器的实际负载可能完全不同。

大语言模型推理通常可以分成 Prefill 和 Decode 两个主要阶段。Prefill 阶段需要处理用户输入的上下文，通常具有较高的计算密度；Decode 阶段则逐步生成 token，每次生成都需要继续利用模型权重和已经保存的 KV Cache。

因此，两个“请求”并不是两个完全相同的工作单位。

如果一个请求输入只有几百个 token，输出几十个 token，而另一个请求输入几万个 token并且要求生成几千个 token，那么简单按照请求数量进行轮询，很容易产生明显的资源不平衡。

二、GPU 利用率本身也不是完整的负载指标

很多监控系统首先观察 GPU utilization。

这个指标当然重要，但不能单独决定调度策略。

一张 GPU 显示 90% utilization，并不意味着它一定比另一张显示 70% 的 GPU 更适合接收下一个请求。

还需要观察显存使用量、显存带宽压力、SM 利用率、功耗、温度、PCIe 或 NVLink 通信情况，以及当前推理队列和 KV Cache 使用情况。

对于大语言模型，GPU 可能出现计算单元利用率并不高，但显存带宽已经成为瓶颈的情况。也可能出现 GPU 计算资源还有空间，但显存已经不足以容纳新的 KV Cache。

因此，调度器不能只看一个百分比。

三、KV Cache 会改变推理集群的资源分配方式

KV Cache 是大语言模型推理中的重要资源。

模型在生成文本时，会保存 Attention 计算所需要的 Key 和 Value，从而避免每生成一个 token 都重新计算完整历史上下文。

这样可以减少重复计算，但代价是需要持续占用 GPU 显存。

KV Cache 的实际大小并不存在一个适用于所有模型的固定比例。它取决于模型层数、Attention 结构、KV heads、head dimension、数据类型、上下文长度以及批处理中请求的数量等因素。

因此，把 KV Cache 简单描述成“占模型参数量10%至20%”是不严谨的。

对于调度系统来说，更重要的问题是：某个推理实例当前还有多少显存可以分配给新的 KV Cache。

如果一个实例已经保存了大量长上下文请求，即使它当前 GPU utilization 看起来并不高，也可能已经不适合接收新的长上下文任务。

这也是为什么现代 LLM serving 系统需要把 KV Cache 纳入调度和资源管理，而不是只统计请求数量。

四、连续批处理让调度变成动态过程

传统批处理通常等待一批请求收集完成，然后一起执行。

这种方式对于 GPU 来说比较容易实现，但在生成式 AI 推理中存在明显缺陷，因为不同请求完成时间不同。

假设一个 batch 中有八个请求，其中六个请求已经生成完毕，剩下两个请求还需要继续生成。如果调度器必须等待整个 batch 结束，已经完成的计算资源就无法立即用于新的请求。

Continuous Batching，也就是连续批处理，改变了这种模式。

系统可以在推理迭代过程中不断移除已经完成的请求，同时加入新的请求，使 GPU 尽量保持有足够的工作量。

因此，负载均衡器与 serving scheduler 之间实际上存在紧密关系。

入口层负责把请求送到合适的推理实例，而实例内部的 scheduler 再根据当前 batch、KV Cache 和 GPU 状态决定具体如何执行。

这也是为什么不能简单地把“负载均衡”理解成 Nginx 做一次轮询就结束。

五、模型副本的位置会影响请求应该发送到哪里

如果同一个模型完整复制在多台 GPU 服务器上，那么负载均衡可以在模型副本之间分配请求。

例如：

GPU服务器A 模型副本
GPU服务器B 模型副本
GPU服务器C 模型副本
GPU服务器D 模型副本

入口系统可以根据队列长度、并发请求数、GPU 状态等信息选择目标实例。

但如果模型本身需要多个 GPU 才能运行，情况就复杂很多。

例如一个模型通过 Tensor Parallel 或 Pipeline Parallel 部署在多张 GPU 上，那么一次请求可能需要进入整个 GPU 组，而不能只把请求随机发送给其中一张 GPU。

因此，调度单位可能不是单张 GPU，而是一个完整的推理实例、GPU worker group 或模型副本。

六、GPU 异构时不能简单平均分配

不同 GPU 的计算能力、显存容量和显存带宽存在明显差异。

例如 NVIDIA A100 和 H100 都可以用于 AI 推理，但它们并不是性能完全相同的设备。H100 的 Tensor Core、显存系统和整体架构都针对新一代 AI 工作负载进行了增强。

如果一个集群同时存在不同 GPU 型号，那么简单按照“每台服务器一个请求”进行轮询，会导致更快的 GPU 和更慢的 GPU 获得相同数量的任务，却承担不同的实际工作量。

更合理的方式是建立 GPU capacity 的概念。

调度器可以根据历史吞吐、当前资源状态以及模型和精度，对不同 GPU 计算出不同的有效处理能力。

例如某一类型 GPU 每秒能够稳定处理更多 token，那么它可以承担更大的请求权重。

但这个权重也不能完全固定，因为 batch size、上下文长度、量化方式和模型版本都会影响实际吞吐。

七、网络拓扑同样会影响调度

当模型只运行在单张 GPU 上时，网络因素相对简单。

但当一个模型跨多张 GPU 运行时，GPU 之间的数据交换就会进入关键路径。

系统可能使用 NVLink、NVSwitch、PCIe 或服务器之间的高速网络进行通信。

如果模型采用 Tensor Parallel、Pipeline Parallel 或其他分布式执行方式，GPU 之间的同步和数据交换可能影响请求延迟。

因此，一个调度器不能只知道“这台服务器还有两张空闲 GPU”，还需要知道这些 GPU 是否属于同一个适合运行该模型的拓扑结构。

如果把一个需要高速 GPU 间通信的工作负载错误地放到通信条件较差的节点组合上，即使 GPU 数量完全足够，性能也可能明显下降。

八、Prefill 和 Decode 可以采用不同的调度策略

大语言模型推理还有一个非常重要的特点，就是 Prefill 和 Decode 的资源行为不同。

Prefill 负责处理输入上下文。输入越长，需要处理的 token 越多，因此它可能形成明显的计算压力。

Decode 则需要持续生成 token，每一步都需要访问模型权重和 KV Cache，往往表现出不同的资源特征。

这意味着某些大型 serving 系统会考虑把 Prefill 和 Decode 分离部署，也就是让不同资源池承担不同阶段。

这样做可以减少两类工作互相影响。

例如大量长上下文请求进入 Prefill 阶段时，如果它们全部占用同一个推理资源池，就可能影响已经进入 Decode 阶段的实时对话请求。

但 Prefill 和 Decode 分离并不是所有系统都需要采用的架构。它增加了系统复杂度，也引入了额外的数据传输和调度问题，需要根据模型规模、流量结构和延迟目标决定。

九、实时请求和离线任务不能采用同一种调度目标

AI 推理集群通常同时存在不同类型的任务。

在线聊天、代码补全、搜索问答等应用比较关注首 token 延迟，也就是 TTFT，以及后续 token 的生成速度。

批量摘要、离线分类、文档处理等任务可能更加关注整体吞吐量。

如果所有任务都按照同一种 FIFO 队列处理，低延迟请求可能被长任务拖慢。

因此，实际 serving 系统可以按照优先级、租户、模型、最大上下文长度以及延迟目标划分不同队列。

高优先级在线请求可以获得更快的调度机会，而后台批处理任务则可以利用剩余资源。

这类策略本质上不是简单的“请求平均分配”，而是资源调度问题。

十、负载均衡还需要考虑请求粘性

对于普通 HTTP 服务，请求发送到哪台服务器通常没有太大区别。

但 LLM serving 存在一个特殊问题：已经建立的 KV Cache 是有状态的。

如果一个请求已经在 GPU A 上运行并积累了大量 KV Cache，下一次生成步骤又被随机发送到 GPU B，那么 GPU B 没有这些 KV Cache，就需要重新建立状态或者进行额外的数据传输。

这会降低效率。

因此，某些系统需要考虑 request affinity，也就是让同一个请求在生命周期内尽量保持在合适的推理实例上。

这并不意味着所有请求都必须永久绑定一台 GPU，而是调度器需要理解推理状态，而不是把每一个 HTTP 请求当成完全独立的无状态任务。

十一、Prefix Cache 又是另一个调度因素

如果多个请求共享相同的系统提示词、文档前缀或者其他长文本上下文，serving 系统可能利用 Prefix Caching 减少重复的 Prefill 计算。

这意味着请求发送到哪个实例可能会影响缓存命中率。

假设服务器 A 已经保存了某个大型公共文档的前缀缓存，而服务器 B 没有这份缓存。

如果每次都随机轮询，那么请求可能不断在不同实例之间移动，缓存优势也就难以发挥。

因此，在支持 Prefix Cache 的系统中，调度器可能需要考虑 cache locality。

这与传统 Web 服务器的简单 round-robin 有明显区别。

十二、真正有效的负载均衡需要持续观察系统状态

一个成熟的 AI 推理集群通常需要监控很多指标，包括：

请求队列长度
并发请求数量
TTFT
Token 间延迟
每秒生成 Token
Prefill 吞吐
Decode 吞吐
GPU 利用率
GPU 显存使用量
显存带宽
KV Cache 使用量
KV Cache 命中率
GPU 温度和功耗
PCIe 或 NVLink 通信
网络吞吐
请求错误率
请求超时

这些数据共同决定调度器下一步应该把请求放到哪里。

例如某个节点 GPU utilization 只有60%，但 KV Cache 已经接近容量上限，那么它可能并不适合接收新的长上下文请求。

反过来，另一台 GPU utilization 为75%，但拥有大量可用显存和较短的请求队列，反而可能更适合接收新的任务。

十三、负载均衡并不意味着所有 GPU 利用率必须一样

这是设计 AI 集群时非常容易产生的误解。

一个优秀的调度器并不追求：

GPU A 80%
GPU B 80%
GPU C 80%
GPU D 80%

然后认为这就是最优状态。

如果 GPU A 是 H100，GPU B 是 A100，而两个 GPU 的任务类型也不同，那么它们即使利用率相同，也可能拥有不同的吞吐能力。

更合理的目标是根据业务指标优化整体系统，例如降低 P95 或 P99 延迟、提高 tokens per second、提高 GPU 有效利用率，同时避免显存不足、队列堆积和请求超时。

换句话说，负载均衡的目标应该是系统级性能，而不是监控面板上的几个百分比看起来一样漂亮。

十四、模型路由也属于负载均衡的一部分

现在很多 AI 服务并不只有一个模型。

同一个平台可能同时提供：

大型推理模型
小型快速模型
代码模型
Embedding 模型
视觉语言模型

此时入口系统首先需要决定请求应该进入哪个模型服务，然后才涉及该模型内部的 GPU 调度。

例如简单分类任务没有必要占用大型推理模型的 GPU 资源，而复杂推理任务又不能为了节省资源强行发送给小模型。

因此，AI 基础设施中的负载均衡实际上可能包括模型路由、模型副本选择、GPU worker 选择以及 batch 内部调度多个层次。

十五、故障转移也是负载均衡设计的一部分

GPU 集群不可能永远没有故障。

GPU 可能发生 Xid 错误，服务器可能掉线，模型 worker 可能崩溃，网络也可能出现异常。

调度器需要知道哪些实例健康，哪些实例正在启动，哪些实例已经停止接收新请求。

如果某个 GPU worker 出现故障，新的请求不能继续发送过去。

对于已经运行中的请求，还需要根据系统设计决定是重试、迁移还是直接返回错误。

LLM 请求的重试尤其需要谨慎，因为请求可能已经产生部分输出，重复执行也可能带来额外 GPU 消耗。

因此，健康检查、超时、重试、熔断和请求生命周期管理同样属于 AI serving 基础设施的重要组成部分。

十六、简单轮询什么时候仍然有用

这并不是说 Round Robin 没有价值。

如果一个集群拥有完全相同的 GPU、相同的模型版本、相同的 batch 策略，而且所有请求长度和业务特征都比较接近，那么简单轮询仍然可以作为一种非常有效的基础策略。

问题出现在工作负载开始复杂之后。

当 GPU 异构、模型不同、上下文长度差异巨大、KV Cache 占用明显、请求存在不同优先级，并且系统采用 Continuous Batching 时，单纯依赖请求数量就很难反映真实负载。

这时候才需要逐渐引入更加丰富的调度信息。

十七、AI 推理集群的负载均衡最终是一个资源调度问题

从工程角度看，一个成熟的 AI serving 平台通常需要把几个层次连接起来。

入口层负责接收请求并进行基础路由。

模型路由层负责决定使用哪个模型和哪个模型版本。

实例调度层负责选择合适的推理 worker。

Serving scheduler 负责管理 batch、Prefill、Decode 和 KV Cache。

GPU 资源管理层则负责处理 GPU、显存以及 GPU 间通信资源。

监控系统持续提供队列、延迟、吞吐、显存和 GPU 状态等信息，让调度策略能够根据实时情况变化。

这套体系的目标并不是把每一台 GPU 的请求数量变得一样，而是在满足延迟目标的同时尽可能提高整个集群的有效吞吐，并避免某一个资源先成为瓶颈。

对于小型 AI 服务，可能只需要反向代理加上几个模型副本，再配合基本的健康检查和队列管理就足够。

当模型规模扩大到多 GPU、多服务器以及多模型以后，负载均衡就开始与 KV Cache、Continuous Batching、模型并行、GPU 拓扑、网络通信和请求优先级发生关联。

这也是 AI 推理基础设施和传统 Web 服务器负载均衡最大的区别之一。传统 Web 服务经常把请求视为相对独立的无状态任务，而生成式 AI 推理中的请求可能携带长上下文、KV Cache 和不同的计算阶段，服务器的实际资源状态也会随着每一个 token 的生成不断变化。

因此，按照“每台 GPU 当前处理多少请求”来判断集群是否平衡，只能算是最初级的指标。真正需要优化的是请求队列、GPU 计算资源、显存、KV Cache、通信拓扑以及延迟和吞吐之间的整体关系。对于 AI 推理系统来说，负载均衡最终不是一个简单的网络转发问题，而是一个贯穿模型路由、Serving 调度和 GPU 资源管理的系统工程问题。