一、项目背景

我们的 AI 网关统一接了多家模型实例（自研底座的不同版本、以及少数外部模型），业务侧只调一个地址。早期网关的路由是"静态权重轮询"，结果发现一个问题：某个模型实例因为显存碎片或长请求堆积进入亚健康状态，吞吐掉了一半、延迟飙了三倍，但网关还在往它上面均匀分发，导致一批请求超时；另一个实例悄悄开始返回 5xx，轮询照样发给它。等我们人工发现，已经影响了一波业务。根因是网关"看不见"后端实例的健康度，路由是瞎的。

二、落地场景

我们在网关路由层加了一套"主动健康探测 + 健康度路由"。网关定期对每个模型实例做探针：发一个轻量探活请求，记录响应延迟、错误率、显存占用；再结合实例实时上报的队列长度、吞吐，给每个实例算一个健康分。路由时优先把请求发给健康分高的实例，亚健康实例自动降权，连续失败或健康分跌破阈值就临时摘除，等探活恢复再自动回切。对单请求而言，如果命中实例在推理中失败，网关直接兜底切到下一个健康实例，业务侧几乎无感。

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

第一，健康探测不能太重。探活请求要轻量、不能影响业务实例，我们做成独立探针通道，探测频率自适应（健康时低频、波动时高频）。第二，健康分的建模。单看错误率会误判（比如实例正在处理一个超长请求），我们综合"探活延迟、错误率、队列深度、显存余量"四维加权，再平滑成一个 0–100 的分。第三，摘除与回切的安全性。摘除要快（避免持续打亚健康实例），回切要稳（探活连续多次正常才加回，防抖动），我们设了"摘除即告警、回切需 N 次连续健康"。第四，请求级兜底。单实例推理失败要秒级切到备选，且同一请求不重复打同一个坏实例。

案例片段（已脱敏）： 健康探测与路由权重的配置（示意）：yaml health_probe:  target: /v1/health  interval: 10s          # 健康时低频  interval_unstable: 2s  # 波动时高频 routing:  score_weights: {latency:0.3, error_rate:0.3, queue:0.2, gpu_free:0.2}  eject: score < 30 for 3 consecutive  rejoin: score > 70 for 5 consecutive fallback:  on_inference_fail: reroute_to_next_healthy

四、效果数据

上线后统计：模型实例故障从"人工发现平均滞后约 20 分钟"变成"网关探测秒级摘除"，亚健康实例被自动降权后，相关业务请求成功率从波动期的约 92% 恢复到约 99.5% 以上；因单实例 5xx 导致的请求失败，在兜底路由下几乎被完全吸收，失败重发率下降明显；路由准确（把请求发到健康实例）保持在高位。探活本身的开销极低，不计入业务延迟。数字脱敏示意，趋势一致。

五、可复用经验总结

网关路由的第一课：路由先要有健康度，看不见后端的路由就是瞎子过马路。第二，健康探测要轻量且自适应频率，重探测本身会变成新负担。第三，健康分要多维加权+平滑，单看错误率会误判长请求实例。第四，摘除要快、回切要稳，用"连续多次"做门槛防抖动，别让实例在健康/摘除间反复横跳。第五，请求级兜底必须做，单实例失败秒级切备选，业务侧才无感。这套"探测—健康分—摘除回切—请求兜底"，是网关稳定分发多模型的基础能力。

结语

网关路由如果看不见后端健康度，就等于蒙眼发牌。我们这套机制上线后，最大的收益其实是"故障静默消化"——亚健康实例被自动降权、摘除，业务侧几乎感知不到，运维不用半夜爬起来手动切，告警也从"生产挂了"降级成"某实例被摘除已自愈"。

但要强调一点：健康分必须多维加权。曾经我们单看错误率，结果把一个正在处理超长合法请求、错误率为零但队列爆满的实例当成健康，继续往里灌流量，反而更堵。加上队列深度和显存余量后，这类误判才消失。路由的"智能"，来自对后端状态的全面感知，而不是某一个指标。另外摘除要快、回切要稳，用连续多次健康做门槛防抖动，别让实例在健康与摘除之间反复横跳——那比不摘除还伤业务。看得见、判得准、切得稳，是网关稳定分发多模型的三个前提。

最后说一个运维视角的收获：健康分我们做了可视化看板，每个实例的实时分数、队列、显存一目了然，值班同学不用再登机器翻日志。一次某实例健康分从 95 慢慢掉到 60，看板上一眼看到趋势，我们提前把流量迁走，避免了一次可能的雪崩。路由的"智能"如果不可见，运维就不敢信；可见、可观测，是这套机制能长期跑下去的关键。我们后来把它接入了统一监控，和 GPU 利用率、网关错误率放在一张图里，一次看全，排障从"猜"变成"看"。

顺带说一个边界情况：健康探测本身也可能成为故障源，如果探针请求太重，反而把实例压垮。我们的做法是探针走独立轻量通道、低频探活，且探测失败连续多次才判定实例异常，避免单次抖动误摘。摘除后也不是永久拉黑，而是进入"观察名单"，探活恢复连续达标再回切。这套"慢判异常、慢回切"的策略，让我们的路由在过去一年里几乎没因为探测本身引发过事故。路由的稳定性，来自对"误判代价"的敬畏：摘错比漏摘更贵，所以判异常要保守。