LLM服务容量规划：多区域容量规划

可视化演示

从需求预测、跨区域调度到QPS换算GPU，演示如何按全球流量分布合理分配推理算力容量。

一、需求预测方法：先算好明天要备多少面

陈师傅每周日晚上都要做一件大事：翻开六个分店过去三个月的账本，找出“星期几人多、几点是高峰、节假日翻几倍”的规律，再结合天气和城市活动日历，给每家分店写下明天的备料单。备少了，顾客排队半小时骂骂咧咧；备多了，食材过夜不新鲜，全是成本。这份“备料单”，就是面馆版的容量需求预测。

在多区域容量规划中，“备料单”对应的是每个区域未来一段时间的推理请求量预估。预测依据不再是顾客账本，而是历史请求日志、用户所在时区的作息规律和节假日营销日历。不同区域差异巨大：华东的上班族高峰集中在北京时间 9 点，美西的夜猫子则在 UTC 凌晨活跃，因此必须按区域分别建模，不能套一个全局模板。

常用的预测方法包括移动平均、指数平滑和周期分解。指数平滑把“历史趋势”与“最新观测”按权重混合，实现简单、计算廉价，非常适合作为容量规划的基线预测器。

陈师傅靠着这套备料逻辑，平稳度过了春节客流翻倍，也没在淡季浪费三百碗面。多区域容量规划的起点同样如此：一份靠谱的需求预测，决定了后续调度和成本策略能否站得住脚。

二、流量调度策略：排队太长的店，把客人引到隔壁街

某天晚上，洛杉矶分店排队超过 40 分钟，而三公里外的圣莫尼卡分店只坐了两桌客人。陈师傅的 App 立刻向排队顾客推送：“隔壁店不排队，今天全场免配送费。” 这就是流量调度——把顾客（请求）从拥挤的分店（区域）引导到空闲的分店。

在 LLM 推理服务中，流量调度通常分三层：第一层是“就近路由”，按用户 IP 归属地或 Anycast 协议把请求发到最近的区域，降低网络延迟；第二层是“负载均衡”，在区域内多个推理实例之间按权重分发请求；第三层是“跨区域迁移”，当某区域排队积压时，把一部分请求转发到其他负载较低的区域。

决定要不要迁移，核心要看负载因子——一个区域有多“拥挤”：

陈师傅总结出一条经验：跨店引流必须算上“顾客打车过去的 10 分钟路程”。对应到技术层面，跨区域流量迁移带来的额外网络延迟，必须小于排队等待节省的时间，否则就是得不偿失。

三、资源弹性调拨：中央冷库与借灶台的艺术

陈师傅在曼谷建了一个中央冷库，平时各分店按预测备料，但谁也没法保证预测完全准确。于是他又定下两条规矩：第一，高峰期分店间可以互相借调厨师和灶台；第二，冷库里永远备着一批“半成品食材”，接到电话十分钟就能送到任何分店。这就是资源弹性调拨的雏形。

在 LLM 服务中，这套机制对应三层能力：按需扩缩容（高峰期自动增加推理实例）、区域间闲时借调（把需求低谷区域的算力调度给高峰区域）、热备资源池（预先拉起但未接流量的“温实例”，随时准备承接突发流量）。弹性调拨让每个区域不再孤军奋战，而是共享一张全网算力网。

判断借调效果，要看全局利用率——把全网看成一个大池子：

中央冷库和借灶台的规矩让陈师傅发现：六家分店总备料量比原来各备各的少了 25%，却几乎没有再出现“这边排长队、那边空转”的情况。多区域弹性调拨的核心价值，正是用全网冗余替代区域冗余。

四、成本优化方案：东京的面粉和曼谷的面粉

陈师傅发现一个有趣的现象：东京分店的面粉进价比曼谷贵 1.5 倍，电费也更贵。同样是煮一碗面，成本差距巨大。于是他把“可以延后制作的半成品”统一安排在曼谷集中生产，再通过冷链运到各分店；东京分店只保留应对高峰的“现煮产能”。这种精打细算，对应到 AI 基础设施就是区域间的成本优化。

LLM 服务的成本优化主要有三条路径：第一，利用区域机型和电价差异，将非实时任务（如离线批处理、模型微调）调度到算力单价更低的区域；第二，容量水位控制——不为极端峰值预留 100% 资源，而是留出 20% 左右的安全余量，其余靠弹性扩缩容兜底；第三，接入可被回收但价格低廉的竞价实例，用于跑可中断的弹性任务。

衡量成本优化效果，最直观的指标是单次请求的平均算力成本：

陈师傅把半成品生产线搬到曼谷后，总成本下降了近三成，而顾客完全没感觉到味道变化。多区域成本优化的精髓正是如此：在不影响体验的前提下，让每一份算力都花在最便宜的地方。

五、监控告警体系：后厨仪表盘与分级的铃声

现在，陈师傅给每家分店装了一块后厨仪表盘：实时显示排队人数、出餐速度、食材余量和空调温度。他还设了三档铃声——“叮”一声是普通提醒（某店客流开始上升），“叮叮”两声是警告（排队超过 15 分钟），连续急促的“叮叮叮”则是紧急（后厨产能即将耗尽，必须立刻干预）。

LLM 服务的监控体系同样分三个层次：关键指标采集（P99 延迟、GPU 利用率、请求成功率、队列深度）；异常检测算法（用统计基线判断“当前是否偏离正常”）；告警分级响应（信息级、警告级、严重级、紧急级，对应不同的处理时效）。

异常检测的常见做法是用均值加若干倍标准差作为动态阈值：

分级的铃声让陈师傅能精准判断：听到“叮”只是让伙计多备点料，听到“叮叮叮”才需要亲自冲到后厨。告警分级的本质，是把稀缺的“人工注意力”留给最致命的问题。

六、容量自动化调整：半夜不用再爬起来

以前陈师傅最怕半夜接到电话：“老板，新加坡店排队爆了！” 后来他给系统接上了自动补货和自动调人逻辑：排队超过 15 分钟自动触发备用厨师到岗，食材低于安全线自动向中央冷库下单。陈师傅只需要在白天看一眼报表，晚上终于能睡个整觉。

容量自动化调整的思路与之完全一致：设定触发条件（如连续 5 分钟平均利用率超过 85%），自动执行扩缩容流程（新增或回收推理实例），并通过灰度验证逐步放量（先扩 10% 观察指标，再继续）。Kubernetes 的 HPA 和事件驱动的 KEDA 都是这套机制的典型实现。

核心计算是“目标副本数”——根据当前利用率反推需要多少个实例：

自动化系统上线三个月后，陈师傅只被紧急电话叫醒过一次——还是因为台风导致曼谷停电这种“系统外问题”。容量自动化的目标是让人类只处理例外，而让系统处理常态。

七、权衡分析决策：开店、扩厨房与备料之间的平衡

陈师傅最近在纠结：要不要在纽约开第七家分店？纽约租金高、人工贵，但客流量大；不开，高峰期顾客就会流失。他还纠结要不要扩大东京分店的厨房——扩大了能多接单，但平时会空着浪费。这些决策本质上都是多目标权衡：体验、成本、风险，三者不可能同时最优。

多区域容量规划的最终决策环节也是同样的权衡，最常见的三组矛盾是：延迟与成本（就近部署体验好但贵，集中部署便宜但远）、冗余与效率（多备容量扛得住突发但浪费，精打细算省钱但风险高）、确定性与弹性（固定预留稳定可控但僵化，动态扩缩灵活但依赖自动化可靠性）。

把这些矛盾统一到一个评分模型里，就是加权求和的决策函数：

陈师傅最终用一张“区域决策矩阵”收尾：纽约开一家小店先试点，东京厨房只扩一半，曼谷冷库加大一倍。任何容量规划都没有标准答案，只有基于预算、体验目标和风险偏好的最佳平衡。

AI 应用场景

Python 演示

import mathimport random  class Region:    def __init__(self, name, capacity, base_load):        self.name = name        self.capacity = capacity        self.base_load = base_load        self.load = base_load     def current_utilization(self):        return self.load / self.capacity     def predict_load(self, hour):        wave = 0.3 * math.sin((hour - 8) / 24 * 2 * math.pi)        return self.base_load * (1 + wave) + random.uniform(-0.02, 0.02)  class MultiRegionPlanner:    def __init__(self, regions):        self.regions = regions        self.region_map = {r.name: r for r in regions}     def predict_all(self, hour):        for r in self.regions:            r.load = r.predict_load(hour)        return {r.name: r.load for r in self.regions}     def schedule_traffic(self, hour):        self.predict_all(hour)        overloaded = [r for r in self.regions if r.current_utilization() > 0.85]        underloaded = [r for r in self.regions if r.current_utilization() < 0.60]        moves = []        for src in overloaded:            bring_back = src.load - src.capacity * 0.85            for dst in underloaded:                headroom = dst.capacity * 0.60 - dst.load                if headroom <= 0:                    continue                amount = min(bring_back, headroom)                moves.append((src.name, dst.name, round(amount, 3)))                src.load -= amount                dst.load += amount                bring_back -= amount                if bring_back <= 0:                    break        return moves     def adjust_capacity(self, hour):        moves = self.schedule_traffic(hour)        for r in self.regions:            if r.current_utilization() > 0.9:                r.capacity *= 1.2            elif r.current_utilization() < 0.4 and r.capacity > 100:                r.capacity *= 0.9        return moves  def main():    random.seed(42)    regions = [        Region("华北", 1000, 680),        Region("华东", 1200, 820),        Region("美西", 800, 420),        Region("欧洲", 600, 350),    ]    planner = MultiRegionPlanner(regions)    for hour in range(8, 22):        moves = planner.adjust_capacity(hour)        print("Hour %02d:" % hour)        for r in regions:            print("  %s load=%.0f cap=%.0f util=%.2f" % (r.name, r.load, r.capacity, r.current_utilization()))        for src, dst, amount in moves:            print("  -> move %.0f requests from %s to %s" % (amount, src, dst))  if __name__ == "__main__":    main()

1. class Region:定义一个区域对象，保存名称、容量和当前负载。
2. def predict_load(self, hour):实现需求预测，用正弦波模拟早晚高峰的周期性波动，并加入随机扰动。
3. wave = 0.3 * math.sin((hour - 8) / 24 * 2 * math.pi)周期波动建模：以早上 8 点为基准，生成一天内的流量起伏曲线。
4. def schedule_traffic(self, hour):流量调度策略：先预测所有区域的负载，再找出超载区和空闲区。
5. overloaded = [r for r in self.regions if r.current_utilization() > 0.85]找出利用率超过 85% 的超载区域。
6. headroom = dst.capacity * 0.60 - dst.load计算目标区域的空闲容量（即 60% 水位以下还能接收多少请求）。
7. moves.append((src.name, dst.name, round(amount, 3)))记录一笔调度动作：从哪个区域迁移多少流量到哪个区域。
8. def adjust_capacity(self, hour):容量自动化调整：调度完成后根据最新利用率决定扩容还是缩容。
9. r.capacity *= 1.2当利用率仍高于 90% 时弹性扩容 20%，给区域更多算力余量。

常见误区

面试题