一句话定义：负载均衡（Load Balancing）就是当一堆请求涌进来、而背后有多张 GPU 卡或多台机器时，决定"哪个请求交给谁处理"的那套调度规则。
为什么需要它
单张大卡的算力总有上限。当模型变大、并发变多，常见做法是横向扩展：多插几张卡，或者干脆拉起多台机器组一个推理集群。但一堆机器摆在那儿不会自动变快——如果所有请求都挤在同一张卡上排队，其余几张卡在旁边闲着，集群的整体吞吐就等于最忙那张卡的水平。负载均衡要解决的，就是把这个"忙闲不均"抹平。
打个比方：超市开了八个收银台。顾客进门后如果凭直觉挑队伍，很容易全挤到靠门那一列，后面的人干等；真正的做法是门口站个引导员，按某种规则把人分到最短的队。负载均衡器就是这个引导员，只不过它面对的不是顾客，而是每秒成百上千条推理请求。
常见的分流规则
- 轮询（Round Robin）：按顺序一个接一个发，第 1 个给 A 卡、第 2 个给 B 卡，转一圈再来。实现简单，但假设了每个请求"分量"相同。长文本生成和短问答混在一起时，这个假设就不成立了。
- 最少连接（Least Connections）：谁手上正在处理的请求少就给谁。比轮询更贴近真实负载。
- 加权分配（Weighted）：给性能强、显存大的节点更高权重，让强卡多扛一点。
- 一致性哈希（Consistent Hashing）：按请求里的某个 key（比如会话 ID）固定映射到同一节点，适合需要缓存命中、多轮对话状态复用的场景。
- 延迟/负载感知：实时看每张卡的排队长度、显存占用、GPU 利用率，动态挑最闲的那个。
| 规则 | 看什么 | 适合什么 |
|---|---|---|
| 轮询 | 次序 | 请求大小均匀、节点同构 |
| 最少连接 | 在途请求数 | 请求耗时差异大 |
| 加权 | 预设权重 | 卡型/机器配置不一致 |
| 一致性哈希 | 请求 key | 有缓存、有会话状态 |
| 负载感知 | 实时指标 | 生产环境、流量波动大 |
和相邻概念的区别
负载均衡常和并行策略混为一谈，其实分工不同。张量并行（Tensor Parallelism）、流水线并行（Pipeline Parallelism）解决的是"一个模型怎么拆到多张卡上"，属于模型内部；负载均衡解决的是"多个请求怎么分到多个副本上"，属于服务外部。前者决定单次推理能不能跑起来，后者决定同时能跑多少次。另外它也和自动扩缩容（Autoscaling）相关但不等同：扩缩容改的是节点数量，负载均衡决定的是流量往哪儿走，两者常常配合使用。
对从业者的实际意义
如果你在部署推理服务，会看到负载均衡通常有两层：前面一层是网关级的，把请求分给各个服务实例；后面一层是实例内的调度，把这批请求切成 batch 再喂给 GPU。真正难的地方在于，GPU 推理的耗时跟输入输出长度强相关，长短请求混跑容易出现"长请求拖住整批"的长尾问题，所以不少系统会做请求分级、分池，让短请求走短请求的通道。
对普通职场人来说，这个概念的价值在于一个直觉：任何"资源有限、需求很多"的场合，排队规则本身就是效率的一部分。同样的机器，换个分配策略，吞吐可能差出一截。具体产品支持哪些策略、默认值是什么，以官方文档为准。