引子：先对齐约束，再谈优化
大模型网关的负载均衡，首先不是一个“分流技巧”问题，而是一个“约束对齐”问题。 在真实生产环境里，多数大模型厂商都以 RPM（每分钟请求数）和 TPM（每分钟 token 数）进行限流。 如果网关调度不直接围绕这两个预算做决策，那么系统内部看似平衡，外部却仍会频繁触发限流，最终表现为吞吐下降、拒绝上升和尾延迟恶化。
基于这个前提，本文只讨论一套新范式：以 RPM/TPM 为核心预算，以资源分配思想驱动负载均衡设计。
一、问题重述：我们到底在分配什么
在大模型场景中，每个请求的成本差异很大。 短请求可能只消耗几百 token，长请求可能消耗数千甚至上万 token。 因此网关并不是在“平均分配请求”，而是在“分配有限预算”：
- 请求频率预算：RPM
- token 消耗预算：TPM
由此我们采用统一资源利用率指标：
max(rpm_util, tpm_util)
它表示当前系统最紧张维度的利用水平，也决定了系统距离极限还有多远。
二、新算法设计：从预算感知到策略分化
围绕 RPM/TPM 预算，我们实现了两类可热切换策略，并在同一仿真框架下进行对比。
1) Traditional（预算感知的基线策略）
- 随机采样实例
- 选择较低并发实例承接请求
- 严格预算校验（RPM/TPM 不足即拒绝或等待）
这类策略结构简单、行为稳定，适合作为基线。
2) Pool-First（资源复用优先策略）
- 通过对象池优先复用处理通道
- 结合预算校验进行接纳控制
- 在高压场景下采用更积极的排队与复用策略
其目标不是“盲目加速”，而是在预算不变前提下，降低资源抖动与分配开销，提升有效吞吐并抑制 GC 频率上升。
三 设计启发：从内存分配算法到动态分桶思路
在持续的压测与数据分析中，我们发现一个关键现象：请求长度的分布变化，对系统性能的影响远大于总流量的变化。这一现象让我们从传统的 “请求分流” 视角，转向更本质的 “资源分配” 视角 —— 大模型场景下，不同 Token 规模的请求争夺同一 TPM 预算池，与内存分配中不同大小的内存块争夺堆空间，在问题结构上高度相似。
由此，我们提炼出两大核心设计启发，成为后续优化的重要依据：
基于以上两点，我们形成了 ** 动态分桶（Adaptive Bucketing）** 的设计思路：通过历史 Token 分布数据实时调整分桶边界，再根据各桶的压力反馈动态优化预算份额，最终实现 “流量结构变化→分配策略自适应调整” 的闭环管理，让预算分配更贴合实际业务需求。
四、实验方法：让差异在正确场景里被看见
为了避免“指标看起来都一样”的假象，实验不是只扫单一维度，而是分三层推进：
实验关注四类指标：
- 吞吐：actual_rpm
- 资源逼近度：max(rpm_util, tpm_util)
- 稳定性成本：gc_avg
- 服务质量：TTFT p95 与 reject_rate
五、结果解读：差异出现在“结构压力”下
前两组实验说明：当瓶颈主要是统一预算上限时，不同策略可能都快速逼近上限，曲线接近并不意外。 真正能拉开差距的是第三组——长请求占比持续上升的异构流量场景。
在 long_ratio = 0.65 时，代表性结果如下：
- Throughput（RPM）：Traditional 2633.47 vs Pool-First 3645.69
- Reject rate：Traditional 0.6488 vs Pool-First 0.5138
- GC frequency（/s）：Traditional 3.0270 vs Pool-First 2.4414
这说明在“预算固定 + 结构变重”的压力下，Pool-First 在吞吐、拒绝率、GC 三个维度同时取得优势。 与此同时，TTFT 尾部会因为策略偏好产生权衡，这提醒我们：算法优化不是单指标最大化，而是目标函数选择。
六、成果图展示
长请求占比扫描
七、结论
这次探究的核心结论可以归纳为三句话：
最终，我们得到的不是某一个“万能算法”，而是一套可验证、可解释、可调优的负载均衡方法论： 预算对齐 -> 结构感知 -> 策略分化 -> 指标闭环。
大模型负载均衡中台仓库：FuShang114/MoonCell-ModelHub
