深夜的城市，出租车调度中心灯火通明。调度员周师傅面前立着三块显示屏，分别连着“迅达”“平安”“快驰”三家出租车公司。每当一个乘客订单进来，他有三秒钟做决定：这个赶飞机的订单派给谁？便宜的迅达车费低，但司机常常迟到；稳定的快驰从不爽约，价格却贵了快一倍。这和企业把 AI 推理请求派发给多家云厂商，本质上是同一个难题。 多云推理负载分发，就是给 AI 推理请求当“调度员”的一套系统。它要实时观察各家云厂商的算力价格、网络延迟和健康状态，在每一次请求抵达时，动态选择最划算、最快、最稳的那朵云。本篇文章会从决策模型、跨云延迟测量、成本感知路由、故障切换机制，一直讲到基准测试与调优实践，完整拆解这套“派单智慧”的实现方案。

岗位关联

掌握多云推理负载分发，你就能在真实 AI 云服务架构中独立设计跨云流量调度方案，在保证推理体验的前提下显著降低多云成本，这是 AI 平台架构师与 MLOps 工程师的核心技能之一。

目录
  1. 可视化演示
  2. 多云分发概述
  3. 决策模型
  4. 跨云延迟测量
  5. 成本感知路由
  6. 故障切换机制
  7. 基准测试与调优
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

演示推理请求根据各云算力价格、延迟与可用性动态分发到多云节点，观察成本感知路由与故障切换机制，切换模式查看单云故障后的流量重分配。

本节配有交互动效（进入视口后自动加载，约 3KB）。

多云推理负载分发 按价格/延迟/可用性动态路由请求 成本感知路由降低推理成本 故障切换自动重分配流量 权重 = f（价格，延迟，可用性） 决策模型保障多云高可用与低成本

多云分发概述

深夜的调度中心，周师傅面前立着三块显示屏，分别连着“迅达”“平安”“快驰”三家出租车公司。他的工作不是让三家公司平均接单——而是每来一个订单，就根据三家公司此刻的报价、路况和司机在线数，把单子派给最合适的那家。遇到赶飞机的客人，就派服务最稳的快驰；遇到预算有限的穷学生，就派便宜的迅达。平均派单看起来很公平，却会让便宜的闲置、贵的一直排队，乘客和公司两头受损。

在 AI 云服务的世界里，周师傅的角色就是“负载分发器”。每次用户请求触发一个推理任务，比如调用大模型生成一段文字，分发器并不会把所有请求都发给同一家云，而是让请求在多家云厂商之间选路。每家云就是一家出租车公司：算力单价是“车费”，响应速度是“接驾时间”，服务可用性是“司机在线率”。这三项指标，决定了每一个推理请求的去向。

一个典型的多云推理分发系统由三个部件组成：接入网关负责接收请求，状态采集器定时收集各云的价格、延迟与健康指标，决策引擎把指标汇总成评分并决定请求发往何处。整个流程的目标可以写成一个优化问题：在满足服务质量约束的前提下，挑选综合成本最低的那朵云。

周师傅把三块屏称为“派单铁三角”：车费、路况、车况。多云分发器的铁三角则是成本、延迟、可用性——三者如何权衡、如何测量、如何应对突发，正是接下来每一节要拆解的细节。

route to j∗=arg⁡min⁡j(α⋅pj+β⋅lj)s.t.aj(t)≥θ\text{route to } j^{*} = \arg\min_{j} \left( \alpha \cdot p_j + \beta \cdot l_j \right) \quad \text{s.t.} \quad a_j(t) \geq \theta
这个式子的意思是：在所有“健康度达标”的云里，找一个“价格乘以权重加上延迟乘以权重”最小的那朵云下单。
  1. 最优云下标 j\*从候选云集合中挑出使括号内数值最小的那个下标，也就是“这一单该派给谁”的最终答案。
    j∗=arg⁡min⁡j(⋅)j^{*} = \arg\min_{j} (\cdot)
  2. 单次推理价格 p_j第 j 朵云处理一次推理请求的单价，包含计算、存储与网络费用，就像出租车的起步价加每公里单价。
    pj>0p_j > 0
  3. 端到端延迟 l_j从请求发出到拿到推理结果的耗时，类似司机从接单到乘客上车的“接驾时间”。
    lj=tend−tstartl_j = t_{\text{end}} - t_{\text{start}}
  4. 权重系数 \alpha 与 \beta刻画成本和延迟在决策中的相对重要性；预算紧张时调大 \alpha，对实时性敏感时调大 \beta。
    α,β≥0\alpha, \beta \geq 0
  5. 可用性约束 s.t.subject to，候选云的健康度 a_j(t) 必须大于等于阈值 \theta，否则直接淘汰。这保证“破产的公司不参与派单”。
    aj(t)≥θa_j(t) \geq \theta

决策模型

周师傅的工位上压着一本翻得卷边的《派单评分手册》：车费便宜加 40 分，接驾时间短加 40 分，司机差评率低加 20 分。每个订单抵达的三秒内，他按手册给三家公司逐项打分，再把分数加总，谁分高就派给谁。这本手册帮他在千头万绪中保持稳定，不会因为某个司机热情寒暄两句就改变派单决定。

评分手册就是决策模型。工程实现中，这个模型把价格、延迟、健康度等维度分别归一化，再乘以各自权重求和，得到每个候选云的综合得分。得分既决定了“选谁”，还通过把得分当作概率权重做随机抽取来控制流量比例：得分高的云承接更多请求，但不会垄断全部流量。这样即使某个时刻评分计算略有误差，也不会让所有请求同时涌向同一朵云。

实现时有两个关键细节。第一是归一化：价格是“元”、延迟是“毫秒”、健康度是“百分比”，量纲完全不同，必须统一映射到 0 到 1 区间才能相加。第二是权重配置：投产初期通常平均配置，再根据压测数据逐步调整，让权重反映出业务对成本、体验、稳定性的真实偏好。

手册的价值不在于某一次打分有多准，而在于它让每一次派单都有章可循。当周师傅想多省点钱，就把“车费便宜”那栏的分值从 40 调成 60；当业务方抱怨体验下滑，就把“接驾时间”的分值调高。权重就是决策模型的手感旋钮。

Sj=∑k=1Kwk⋅qkj,∑k=1Kwk=1\displaystyle S_j = \sum_{k=1}^{K} w_k \cdot q_{kj}, \qquad \sum_{k=1}^{K} w_k = 1
综合得分等于各维度“质量分乘以权重”的累加，所有权重加起来恰好等于 1，保证各家云在同一把尺子上比较。
  1. 综合得分 S_j第 j 朵云参与竞争的总分数，分越高越容易被选中，就像评分手册上的总分。
    Sj∈[0,1]S_j \in [0, 1]
  2. 归一化质量值 q_{kj}第 j 朵云在第 k 个维度上归一化后的得分，统一到 0 到 1 区间，让不同量纲可以相加。
    qkj=原始值−min⁡max⁡−min⁡q_{kj} = \frac{\text{原始值} - \min}{\max - \min}
  3. 权重 w_k每个维度的权重，表示调度员对这个维度的重视程度；价格权重高，系统就更“抠门”。
    wk∈[0,1]w_k \in [0, 1]
  4. 权重归一化条件所有 K 个权重之和等于 1，保证评分在同一标尺上比较，不会因维度数量不同而失真。
    ∑k=1Kwk=1\sum_{k=1}^{K} w_k = 1

跨云延迟测量

周师傅的大屏上有一条实时跳动的“路况雷达”：每隔 30 秒，他向三家公司各派一辆“侦查车”，测算从乘客位置到最近司机的实际接驾时间。雷达数据总是波动的——晚高峰堵车、临时封路、司机手机断网，都会让上一秒的估计瞬间失真。如果周师傅拿一次测量值就做决策，一个异常数据就可能把订单派给一辆远在十公里外的车。

跨云延迟测量面临同样的问题。决策模型所依赖的“延迟”不能只用一次测量，而要持续探测并平滑滤波。工程上由状态采集器周期性地向各云的推理端点发送探测请求，记录往返时间，再用指数加权滑动平均把毛刺磨平。这样既跟得上真实变化，又不会被单次抖动带偏。

测量时还要注意统计口径：探测请求不能只测“网络入口”，而要覆盖完整的推理耗时，因为排队和模型计算同样是延迟的一部分。同时，观测记录应带上地域标签。一个在东南亚的用户请求，显然不该参考北美节点的延迟数据。结合地域感知，分发器可以优先把请求路由到离用户最近的可用云。

有了这套路况雷达，周师傅的派单就不再“听风就是雨”。一次偶发的堵车不会让他立刻把所有订单从平安公司撤走，而持续三分钟的路况恶化则会真实地反映在评分里——延迟测量的艺术，正是在“敏感”与“稳定”之间找到平衡点。

lˉt=α⋅lt+(1−α)⋅lˉt−1\displaystyle \bar{l}_t = \alpha \cdot l_t + (1-\alpha) \cdot \bar{l}_{t-1}
新的平均延迟等于 \alpha 乘以最新实测值，加上 (1-\alpha) 乘以历史平均值。\alpha 大则反应快但易被噪音带偏，\alpha 小则平滑但反应迟钝。
  1. 最新观测值 l_t刚发出的探测请求测得的本次往返延迟。
    lt=tresponse−tsendl_t = t_{\text{response}} - t_{\text{send}}
  2. 历史滑动平均 \bar{l}_{t-1}截止上一时刻的平滑延迟估计，相当于路况雷达的历史记忆。
    lˉt−1\bar{l}_{t-1}
  3. 平滑系数 \alpha0 到 1 之间的小数，\alpha 越大越相信最新数据，越小越依赖历史趋势。
    0<α<10 < \alpha < 1
  4. 递推更新新的平均延迟是“最新观测”与“历史记忆”的加权融合，既跟踪变化又抑制噪音。
    lˉt=α⋅lt+(1−α)⋅lˉt−1\bar{l}_t = \alpha \cdot l_t + (1-\alpha) \cdot \bar{l}_{t-1}

成本感知路由

每个月月底，周师傅都要交一份经营报表。若是总把订单派给最便宜的迅达，报表确实好看，但乘客投诉率飙升；若是总派给最贵的快驰，乘客满意了，公司却不赚钱。周师傅的解法是看“性价比”：每多花一块钱，能换来多少接驾速度和服务质量。他会选择那些“多花一点点钱、体验大幅提升”的车队。

成本感知路由的核心正是“效用最优”，而不是“最低价优先”。延迟低、成功率高是收益，单价高是代价，把收益和代价放进同一个函数里权衡，就得到每朵云的净效用。值得注意的是，成本并不只有单次推理的价格：跨云的数据传输费、预留实例与竞价实例的价差、切换到新云时的冷启动开销，都应该算进总账单。

在实现中，系统会动态调节成本敏感系数 \lambda。预算即将耗尽时调大 \lambda，系统会明显偏向便宜云；线上延迟告警频发时调小 \lambda，系统转而追求更快更稳的体验。这就好比周师傅在月末冲业绩时拼命压低车费，而在暴雨天优先保证乘客能叫到车。

经营报表上的数字终于好看起来了：乘客没多等太久，公司也没多花冤枉钱。成本感知路由教会周师傅一个道理——省钱不是目的，每一分钱换来多少体验，才是调度员真正该算计的事。

Uj=Qj−λ⋅Pj\displaystyle U_j = Q_j - \lambda \cdot P_j
净效用等于质量得分减去 \lambda 乘以成本。\lambda 越大系统越抠门，\lambda 越小系统越注重体验。
  1. 净效用 U_j候选云的综合“划算程度”，效用越高越值得被选中。
    UjU_j
  2. 质量得分 Q_j延迟越低、成功率越高带来的正向收益，相当于乘客满意度。
    Qj=wlat⋅(1−lˉj)+wok⋅rjQ_j = w_{\text{lat}} \cdot (1 - \bar{l}_j) + w_{\text{ok}} \cdot r_j
  3. 成本 P_j处理一次请求的总花费，包含计算、传输与冷启动成本，是负向因素。
    Pj=pcompute+ptransferP_j = p_{\text{compute}} + p_{\text{transfer}}
  4. 成本敏感系数 \lambda权衡成本与质量的系数；预算越紧 \lambda 越大，越偏向便宜云。
    λ≥0\lambda \geq 0

故障切换机制

一个暴雨夜，“平安”公司的调度系统突然宕机，司机集体离线。周师傅的三秒规则瞬间被打乱：绝不能再把订单派给失联的平安，但也不能把所有订单轰地一下子涌向另外两家——那会把它们的调度台也击穿。他当机立断：先暂停向平安派单，再以每分钟 10% 的速度把积压订单匀给快驰，同时紧盯快驰的接单时长，一旦超过阈值就放缓转移速度。

这套应对方案，在工程上对应故障切换机制的四个步骤：健康探测、熔断、疏散、恢复。状态采集器持续探测每朵云的健康状况，连续失败达到阈值就触发熔断，把故障云从候选列表移除；随后“逐步”疏散流量而非一次性切换，目的是防止备用云被瞬时洪峰压垮，引发雪崩；故障云恢复后，也不能立即全量回流，而是先放 5% 的探测流量，观察稳定后再逐步回归。

多云的真正价值就在这个时刻体现——可用性冗余。假设每朵云的可用率都是 99%，两朵独立的云联合之后，整体可用性会从 99% 跃升到 99.99%。这背后的数学，是一个简洁的概率公式。

暴雨过后，平安公司恢复了系统。周师傅按流程先放了少量订单过去，确认接单顺畅，才逐步把流量切回。这一次经历让他明白：故障并不可怕，可怕的是在故障面前手忙脚乱——预先设计好的熔断、疏散、恢复流程，才是调度中心真正的“备用轮胎”。

Asystem=1−∏j=1N(1−Aj)\displaystyle A_{\text{system}} = 1 - \prod_{j=1}^{N} \left( 1 - A_j \right)
系统可用率等于 1 减去“所有云同时故障”的概率。云的数量越多，整体可用性越是呈指数级提升。
  1. 单云可用率 A_j第 j 朵云在统计周期内正常服务的概率，比如 0.99。
    Aj=成功请求数总请求数A_j = \frac{\text{成功请求数}}{\text{总请求数}}
  2. 单云故障率 (1 - A_j)第 j 朵云出故障的概率，是可用率的互补值。
    1−Aj1 - A_j
  3. 联合故障概率 \prod假设各云故障相互独立，所有 N 朵云同时故障的概率等于各故障率连乘。
    ∏j=1N(1−Aj)\prod_{j=1}^{N} (1 - A_j)
  4. 系统可用率用 1 减去“全部故障”的概率，就得到“至少有一朵云可用”的概率。
    Asystem=1−∏j=1N(1−Aj)A_{\text{system}} = 1 - \prod_{j=1}^{N} (1 - A_j)

基准测试与调优

每月第一个周一的凌晨，周师傅会做一次“实战演练”：模拟一百个突发订单同时涌入的洪峰，检验评分手册、路况雷达和熔断规则在极限压力下是否靠得住。演练结束后，他会把结果记入《调度质量月报》，标注出哪家公司的平均接驾时间超标、哪条策略在压力下失灵。

在工程上，这种演练叫基准测试。用标准化负载对多云分发系统进行压测，观察不同权重组合、不同平滑系数、不同熔断阈值下的关键指标。最重要的指标之一是 P95 延迟——把一段时间内所有请求的延迟从小到大排序，第 95 百分位的值就是 P95。它决定了用户体验的下限：哪怕平均延迟很漂亮，只要 P95 超标，就意味着每二十个用户里就有一个在漫长等待。

调优的实践路径通常分三步。第一步，用默认参数压测建立基线；第二步，逐参数扫描，比如把价格权重从 0.3 调到 0.5，观察成本与 P95 的变化曲线；第三步，用灰度发布小流量验证新参数组合，确认无回归后逐步放量到全量。整个调优过程始终盯着一组硬指标，而不是凭感觉拍脑袋。

周师傅的月报最后一栏，永远写着同一句话：“95% 的乘客在承诺时间内上车，每单成本控制在预算内。” 这就是一套好调度体系的全部含义——用数据说话，用演练检验，让每一次派单都经得起洪峰的考验。

P95(l)≤LSLO\displaystyle P_{95}(l) \leq L_{\text{SLO}}
排序后第 95 百分位的延迟必须小于等于服务等级目标（SLO），这是压测能否通过的硬标准。
  1. P_{95}(l)把所有请求的延迟从小到大排序，取第 95 百分位的值，代表“最慢的 5% 之外”的体验上限。
    P95(l)=l⌈0.95×n⌉P_{95}(l) = l_{\lceil 0.95 \times n \rceil}
  2. 服务等级目标 L_{\text{SLO}}与客户约定的延迟承诺，比如 500 毫秒，是系统的质量红线。
    LSLO=500 msL_{\text{SLO}} = 500 \text{ ms}
  3. 比较关系当 95 分位延迟仍然小于等于目标值，说明绝大多数请求达标，系统合格。
    P95(l)≤LSLOP_{95}(l) \leq L_{\text{SLO}}
  4. 调参依据压测中同时观察成本与成功率，找到满足 SLO 且每千请求成本最低的权重组合。
    min⁡Pjs.t.P95(l)≤LSLO\min P_j \quad \text{s.t.} \quad P_{95}(l) \leq L_{\text{SLO}}

AI 应用场景

多云大模型 API 统一网关

阶段：模型推理与服务编排

解决的问题：企业同时接入多家大模型云厂商时，单云价格波动大且存在区域性宕机风险。传统做法是固定调用一家，要么忍受高账单，要么在故障时手动切 DNS。统一网关把负载分发逻辑下沉到基础设施层，按价格、延迟、健康度动态路由每个推理请求。

具体案例：某电商客服助手同时接入三家云厂商的大模型 API。白天高峰时段，网关调大成本权重，把非实时请求引向性价比高的云；当某云厂商公布故障公告时，健康探测自动熔断，流量在五分钟内平滑转移到备用云，客服响应零中断。

东南亚多地域智能客服就近路由

阶段：延迟测量与地域感知路由

解决的问题：跨国业务中，用户分布在多个国家，统一入口会让远距离用户承受高延迟。通过跨云延迟探测与地域感知，系统把每个请求路由到离用户最近、且当前负载允许的云节点。

具体案例：一家出海金融科技公司在新加坡、雅加达、马尼拉三地部署推理节点。状态采集器每 30 秒探测各节点延迟并做 EWMA 平滑，当印尼节点高峰期延迟恶化时，系统自动把部分请求切换到新加坡节点，P95 延迟始终控制在 800 毫秒以内。

Python 演示

python113 行
import random  class Cloud:    def __init__(self, name, price, latency, reliability):        self.name = name        self.price = price              # 单次推理价格(元)        self.latency = latency          # 基础延迟(ms)        self.reliability = reliability  # 单次请求成功概率        self.request_count = 0        self.total_cost = 0.0        self.total_latency = 0.0        self.failed = False     def inference(self):        """执行一次推理, 返回(是否成功, 延迟)"""        if random.random() <= self.reliability:            return True, self.latency        return False, 0     def record(self, lat):        self.request_count += 1        self.total_cost += self.price        self.total_latency += lat  class Dispatcher:    def __init__(self, clouds, w_price=0.4, w_latency=0.4, w_reliability=0.2):        self.clouds = clouds        self.w_price = w_price        self.w_latency = w_latency        self.w_reliability = w_reliability        self.failover_count = 0     def _score(self, cloud):        """加权评分: S = w_price*(1-p') + w_latency*(1-l') + w_reliability*r"""        if cloud.failed:            return 0.0        max_price = max(c.price for c in self.clouds)        max_lat = max(c.latency for c in self.clouds)        norm_price = cloud.price / max_price        norm_lat = cloud.latency / max_lat        return max(0.0, self.w_price * (1 - norm_price)                   + self.w_latency * (1 - norm_lat)                   + self.w_reliability * cloud.reliability)     def pick(self):        """按评分做轮盘赌, 选出目标云"""        candidates = [c for c in self.clouds if not c.failed]        if not candidates:            return None        scores = [self._score(c) for c in candidates]        total = sum(scores)        r = random.uniform(0, total)        acc = 0.0        for c, s in zip(candidates, scores):            acc += s            if r <= acc:                return c        return candidates[-1]     def serve(self, n_requests):        """处理 n 个请求, 返回成功数"""        success = 0        for i in range(n_requests):            if i % 300 == 0:                self._recover_all()            cloud = self.pick()            if cloud is None:                continue            ok, lat = cloud.inference()            if ok:                cloud.record(lat)                success += 1            else:                cloud.failed = True                self.failover_count += 1                backup = self.pick()                if backup is not None:                    ok2, lat2 = backup.inference()                    if ok2:                        backup.record(lat2)                        success += 1        return success     def _recover_all(self):        """周期性健康检查: 冷却结束后让故障云重新参选"""        for c in self.clouds:            c.failed = False  def main():    clouds = [        Cloud("云A", price=0.9, latency=20, reliability=0.95),        Cloud("云B", price=0.5, latency=45, reliability=0.88),        Cloud("云C", price=1.3, latency=15, reliability=0.99),    ]    dispatcher = Dispatcher(clouds)    total = 1000    success = dispatcher.serve(total)    print("请求总数: {}".format(total))    print("成功数: {}".format(success))    print("故障切换次数: {}".format(dispatcher.failover_count))    for c in clouds:        avg_lat = c.total_latency / c.request_count if c.request_count else 0        print("{}: 请求={} 成本={:.2f}元 平均延迟={:.1f}ms 状态={}".format(            c.name, c.request_count, c.total_cost, avg_lat,            "故障" if c.failed else "正常"))    print("总成本: {:.2f}元".format(sum(c.total_cost for c in clouds)))  if __name__ == "__main__":    main()
目的：实现一个带加权评分、熔断与故障切换的多云推理分发模拟器，跑完 1000 个请求后输出各云的分单量、成本与延迟统计。
  1. def _score(self, cloud):实现加权评分公式 $S_j = \sum w_k q_{kj}$，综合价格、延迟与可靠率。
  2. norm_price = cloud.price / max_price归一化到 0 到 1 区间，消除“元”和“毫秒”的量纲差异。
  3. if cloud.failed: return 0.0故障云直接得零分退出竞争，这就是熔断的简化实现。
  4. r = random.uniform(0, total)生成随机数，模拟轮盘赌的“转盘指针”。
  5. for c, s in zip(candidates, scores):遍历候选云，按评分占比命中目标，实现加权随机分发。
  6. if i % 300 == 0: self._recover_all()模拟周期性健康检查，让故障云冷却后重新参选。
  7. cloud.failed = True单次推理失败即触发熔断标记，演示故障切换的触发条件。
  8. backup = self.pick()自动从剩余健康云中重新挑选备用云，完成故障切换。
  9. if ok: cloud.record(lat)成功请求记录成本与延迟，用于最终统计与调优分析。

常见误区

误区我只要把请求轮流发给各家云，就算是多云负载分发了，简单又公平。

正解轮询把各家云一视同仁，忽略了价格和延迟的差异——原本 50 毫秒就能完成的请求，可能被轮到一家 200 毫秒的云上，账单还贵了一倍。正确的做法是像调度员用评分手册那样，按加权评分动态分配流量，让表现好的云接更多单，表现差的云少接单，而不是机械地轮流。

为何常见：单云时代用惯了 round-robin 负载均衡，习惯性把“轮流”迁移到多云场景，却没意识到多云之间的资源是异质的。

误区网络延迟是稳定的，部署前测一次各云的延迟，之后直接用这个数值做路由决策就行。

正解公网延迟会随链路拥塞、路由切换、对端负载不断波动。周师傅的路况雷达每 30 秒就要重测一次，负载分发器同样需要周期性探测并使用 EWMA 平滑。用一次测量值做长期决策，等于拿着昨晚的路况指挥今天的早高峰。

为何常见：忽略了网络环境的动态性，把“测量”当成了“安装配置”这种一次性动作。

误区某朵云挂了，我立刻把所有流量切到备用云，越快越彻底越好。

正解瞬间切换会让备用云流量瞬间翻倍乃至数倍，极易把备用云也压垮，形成雪崩。正确做法是熔断故障云后，按每分钟 10% 的比例逐步疏散流量，同时监控备用云的延迟与错误率，一旦恶化就放慢甚至暂停转移。

为何常见：把“快速恢复”误解为“一次性全部转移”，忽略了系统的容量是有限的这个基本事实。

误区成本感知路由嘛，就是每次请求都挑单价最低的那朵云，成本自然最低。

正解最便宜的云往往延迟高、成功率低，用户投诉和重试带来的隐性成本可能远超省下的账单。正确做法是用效用函数 $U = Q - \lambda P$ 综合权衡：便宜但慢的云只在预算紧张时被倾斜，而不能永远垄断流量。

为何常见：把“成本感知”望文生义地理解成“贪心选低价”，忽略了质量维度对总成本的反向影响。

面试题

Q1. 多云推理负载分发的核心目标是什么？

单选题 · easy

  • A.把请求均匀分配到所有云上
  • B.综合价格延迟可用性选择最优云← 正确答案
  • C.只选择价格最低的那一朵云
  • D.固定使用一家自建的云

答案：B。负载分发的核心不是平均，也不是单纯贪便宜，而是像调度员看评分手册一样，综合价格、延迟、可用性三个维度动态选择最优云。均匀分配会忽视云间差异，只选最便宜会牺牲体验，固定单云则放弃了多云冗余的价值。

Q2. 决策模型中权重 w_k 的作用是什么？

单选题 · easy

  • A.表示各质量维度的重要性← 正确答案
  • B.表示云厂商的物理位置
  • C.控制网络重传的频率
  • D.加密推理请求的密钥

答案：A。权重刻画的是调度员对价格、延迟、健康度等维度的重视程度，权重越大说明该维度越关键。它和物理位置、网络传输、加密机制都没有关系。

Q3. EWMA 公式中平滑系数 α 越小，延迟估计会怎样变化？

单选题 · mid

  • A.对最新观测越敏感，波动越大
  • B.越依赖历史数据，曲线越平滑← 正确答案
  • C.完全停止更新，数值冻结
  • D.自动放大测量噪声两倍

答案：B。EWMA 中 α 控制新旧数据的比重。α 越小，(1-α) 越大，历史平均占的权重越高，曲线越平滑但反应越迟钝；α 越大才越追随最新值。数值不会冻结，也不会放大噪声。

Q4. 熔断机制的主要作用是什么？

单选题 · mid

  • A.提升单次推理的运算速度
  • B.避免备用云被瞬时流量压垮← 正确答案
  • C.降低云厂商的计费精度
  • D.增加请求在队列里的等待时间

答案：B。熔断把故障云从候选列表移除后，如果所有流量瞬间涌向备用云，备用云同样会被击穿，这就是雪崩效应。熔断配合逐步疏散，正是为了给备用云留出容量缓冲，和运算速度、计费精度、等待时间无关。

Q5. 成本感知路由中的“成本”通常包括哪些部分？（多选）

多选题 · mid

  • A.单次推理的计算单价← 正确答案
  • B.每千token的模型调用费← 正确答案
  • C.跨云数据传输与带宽费← 正确答案
  • D.开发工程师的月薪支出

答案：ABC。成本感知路由关注的是每次推理直接产生的费用：计算单价、按 token 计费的模型调用费、跨云传输与带宽费都属于运行时成本。工程师薪资是人力成本，不属于请求路由决策中的成本项。

Q6. 跨云延迟测量通常采用什么机制？

单选题 · mid

  • A.定期发送探测请求实测← 正确答案
  • B.用GPS定位请求来源
  • C.登录控制台人工观测
  • D.根据历史文档推算

答案：A。延迟测量必须靠状态采集器周期性发送探测请求，记录往返时间并做 EWMA 平滑。GPS 定位、人工观测和文档推算都无法获得实时、可自动化的延迟数据，无法支撑动态路由决策。

Q7. 故障切换的正确流程包括哪些环节？（多选）

多选题 · hard

  • A.连续失败达到阈值触发熔断← 正确答案
  • B.将故障流量逐步摘除转移← 正确答案
  • C.恢复后立即将所有流量切回
  • D.冷却期后小流量验证再回流← 正确答案

答案：ABD。故障切换四步是健康探测、熔断、逐步疏散、冷却恢复。连续失败达到阈值才熔断，流量要逐步摘除防止雪崩，恢复后必须先小流量验证再逐步回流。立即全量切回属于错误做法，容易再次引发故障。

Q8. 基准测试中 P95 延迟指标的含义是什么？

单选题 · hard

  • A.95% 的请求延迟低于该值← 正确答案
  • B.平均延迟乘以95%的结果
  • C.最低延迟的95倍数值
  • D.测试时长的95个百分点

答案：A。P95 延迟是把所有请求延迟排序后取第 95 百分位的值，意味着 95% 的请求都比他快。它衡量“尾部延迟”，比平均值更能反映用户体验的下限，与平均值的百分比运算无关。

Q9. 两朵可用率均为 99% 的独立云，联合后的系统可用率约为多少？

单选题 · easy

  • A.99.99%← 正确答案
  • B.99.00%
  • C.98.01%
  • D.50.00%

答案：A。根据公式 $A_{\text{system}} = 1 - (1-0.99) \times (1-0.99) = 0.9999$，联合可用率约等于 99.99%。这就是多云冗余的价值：两朵 99% 的云叠加后，故障率从 1% 降到 0.01%。

Q10. 决策模型动态更新时需要哪些实时输入？（多选）

多选题 · hard

  • A.各云实时的价格波动数据← 正确答案
  • B.延迟探测的滑动平均值数据← 正确答案
  • C.健康状态与熔断标记记录← 正确答案
  • D.随机数生成器的种子值

答案：ABC。决策模型的三类输入是价格、延迟、健康状态：实时价格波动决定成本项，延迟滑动平均值决定体验项，健康状态与熔断标记决定候选资格。随机数种子只影响模拟实验的可复现性，不参与真实路由决策。