科技媒体在报道底层基建时，往往习惯挑最耸动的数字。Meta 宣布开源 C++ 分配求解器 Rebalancer 时，不少转述直接把每天约 4000 万次分配，误读成了能单次吞吐 4000 万个对象的算力神迹。
这完全理解反了。4000 万不是单次运算的规模，而是 Meta 内部各个业务系统每天调用求解器的总频次，覆盖了超过 30 种资源建模场景。这项技术源自 Meta 在 OSDI 2024 发表的论文，并在 2026 年 9 月 21 日正式以 Apache 2.0 协议开源了代码仓库 facebook/rebalancer。它解决的不是前沿模型推理，而是数据中心里最现实的苦活：如何把成百上千个微服务分片，塞进数以万计的异构物理节点里。
算力膨胀下的调度死局
在超大规模数据中心中，分配资源本质上是经典的运筹学难题。当面对百万级对象和数千个容器时，决策变量会随着对象与容器乘积出现组合爆炸。通用规划工具如 Google OR-Tools 或传统混合整数线性规划（MIP）求解器，面对这种维度灾难，往往算上几十分钟也无法收敛。
超大规模数据中心的调度不能等。机器随时会宕机，流量随时在迁移，每次调整还伴随着高昂的重平衡抖动成本。如果算出一套完美方案需要半小时，现场机器早就崩了。
舍弃全局最优的工程取舍
Rebalancer 的核心设计极度务实：放弃对数学绝对最优解的执念。
它采用双模态架构。针对超大规模分配，核心引擎运行基于表达式图的并行增量局部搜索，提供 C++ 和 Python 接口。面对较小或中等规模、需要精确数学证明的场景，它也能把问题编译成 MIP 模型，调用外部的 HiGHS、Gurobi 或 FICO Xpress 求解。
这种妥协换来了立竿见影的生产指标。对于包含 265,000 个对象和 3,200 个桶的分配任务，Rebalancer 的求解耗时 P99 仅为 12 秒；而面对超过 100 万个对象和 5,000 个桶的超大规模问题，平均求解时间也压到了 171 秒。
在 OSDI 2024 的 Azure 数据集对比中，MIP 求解拿到了 94.6% 的放置率，Rebalancer 的随机局部搜索拿到 93.2%。为了追回那 1.4% 的放置率，传统算法要多花整整 5.2 倍的时间。
生产调度拼的不是数学洁癖，而是在系统超时前给出一个足够好的可用答案。
在工业体系里，这 1.4% 的差距完全可以靠硬件冗余吃下，但 5 倍的延迟差距却能直接拖垮整个控制面的调度节奏。
边界、妥协与真实代价
天下没有免费的算力午餐，局部搜索的捷径必然伴随着设计上的暗坑。
首先是初始约束的漏洞。如果机器在进入调度前就已经违规超载，Rebalancer 不会保证输出结果 100% 合规。它的机制是保证优化过程不引入新违规，并将原有违规作为最高优先级目标去尽量缩小。在极端恶劣的初始状态下，它返回的算力分布并不是数学意义上的严格可行解。
其次是非连续约束的局部极值陷阱。当面临特定硬性约束（例如某个存储桶必须恰好放 5 个或 8 个切片）时，局部搜索极易在原地打转，必须依赖构造 SQUARES 这类非线性惩罚目标函数或编写特定的移动算子来引导。为了帮助排查这些暗坑，Meta 同步提供了 Rebalancer Explorer 工具，供工程师做可视化调试与假设迁移测试。
- 建议.将 Rebalancer 与 Google OR-Tools 互补使用。通用约束规划和业务逻辑验证交给 OR-Tools 的 CP-SAT，而超大规模容器搬迁、散列容灾等看重吞吐时效的场景交给 Rebalancer。
大厂开源基建很少有救世主心态，大多是把内部磨烂了的妥协公之于众。Rebalancer 解决的不是数学难题，而是超大规模集群在成本、时间与稳定性之间的生存博弈。