一、项目背景

我们的 AI 网关早期对所有调用方一视同仁，请求进来排同一条队，先到先得。平时没问题，一到活动大促，客服系统的实时应答和营销的批量刷量挤在同一批算力上，营销那边猛灌请求，客服的实时应答被拖到好几秒才返回，客户对着转圈圈干等。关键业务被闲时流量误伤，这种事发生几次，业务方就对网关失去信任，宁可自己绕开直连模型，网关形同虚设。我们统计过，大促时段客服类请求的 P99 延迟能飙到平时的五六倍，根本没法用。更隐蔽的是，营销批量本可以半夜跑，却因为没约束在白天高峰猛发，把最贵的算力浪费在最不急的事上，算总账的时候没人算得清这笔账。

二、落地场景

我们给网关加了优先级排队。调用方按业务重要度分等级，客服、风控这类关键业务是高优，营销批量、离线打标是低优。高优请求进独立队列，算力紧张时优先调度，必要时抢占低优正在占用的算力。低优任务不是不管，我们给它留了保底带宽，保证不会被彻底饿死，只是让位给更急的。队列之间做了隔离，某个低优调用方突发刷量，只会在自己那层排队，不会波及高优。抢占有兜底，高优抢完之后低优能恢复，不会永远卡住。后台能看到各优先级队列的等待和抢占情况，调度策略透明可查。此外，低优批量也接了错峰建议，系统提示哪些时段算力空闲适合跑批量，营销把任务挪到夜里，白天高峰彻底让给客服，算力和业务节奏对上了。

三、关键技术挑战与解决思路

优先级划分不能拍脑袋。我们和业务方一起梳理，把实时、面向客户、不可降级的标高优，批量、可延迟、可重跑的标低优，但边界常有争议，比如某些营销活动当天也算关键，我们做成可配置，活动前临时升优，活动后降回。抢占调度最怕饿死低优，我们第一版抢占太猛，批处理任务永远拿不到算力，整天重试，后来加了低优保底带宽，保证它至少能慢慢跑。队列隔离要防噪声传播，低优突发不能串到高优队列，我们用硬隔离加令牌桶，低优超额直接限流在本层。抢占的粒度要细，不能一抢就把整个低优会话杀掉，我们按请求级抢占，只让出当前这批，已开始的低优计算尽量跑完，减少浪费。错峰建议也踩过坑，初期只按全局空闲提示，没考虑某个调用方自己的配额，导致大家挤同一空闲窗，后来按调用方维度分时段才匀。

案例片段（已脱敏）： 优先级队列与抢占调度配置（示意）： queue.levels: [high, low] high.preempt: true low.guaranteed_bandwidth: yes isolation: hard_token_bucket preempt.granularity: request offpeak.suggest: per_caller 某网关上线优先级后客服类 P99 从约 5 秒降到 800 毫秒内，低优任务完成率仍保持约 95%，算力利用率提升约一成，错峰后白天高峰算力释放约两成。

四、效果数据

我们主要看关键业务 P99、低优等待时长、抢占次数和算力利用率。关键业务 P99 从大促时的五六秒压到亚秒级，客服实时应答终于可用，业务方重新信任网关；低优等待虽然变长，但完成率仍保持九成五，没有被饿死。抢占次数在活动峰值时明显上升，说明优先级确实在起作用。算力利用率提升一成，因为高优不再空等，低优填了碎片时间。文中数据为项目复盘口径，已做脱敏。我们把优先级配置接到了活动日历，大促前自动给相关调用方升优，活动后自动回落，运营不用再半夜改配置，网关从被动扛压变成主动配合业务节奏。错峰跑起来之后，白天客服高峰的算力冗余明显多了，同样的机器扛住了更大的活动，扩容预算都省下一截。

五、可复用经验总结

网关排队不能一刀切，关键业务和批量刷量挤一起必出事，我们就是被大促拖垮客服才醒悟，分优先级是基本功，先到先得只适用于请求都平等的场景。抢占要温柔，别把低优往死里饿，保底带宽留一点，批处理虽然慢点但能跑完，否则低优天天重试更浪费。队列隔离必须硬，低优突发限在自己层，别让它噪声外溢到高优，令牌桶比软限流靠谱。错峰要按调用方分时段，全局提示会制造新的挤兑，我们被挤过一次才改。我现在的判断是，优先级这事最难的不是技术而是和业务对齐重要度，边界争议永远有，做成可配置比写成死规则实用，网关调度说到底是帮业务把算力花在刀刃上，这点想透了策略自然稳。

我们把抢占记录也接到了账单，高优抢占低优的次数计到低优调用方的成本里，倒逼业务方别滥用高优，资源调度和成本核算对上了。运营后来按优先级出报表，哪个业务占了多少关键算力一清二楚。

我们也给低优任务做了完成度看板，哪些批处理卡在等待、等了多久一目了然，运营不再担心它们被饿死。低优调用方看到自己的任务在排队也能安心，因为系统保证了它最终能跑完，只是晚一点。