模型崩了，业务没停！DeepSeek 中断 5 小时后的 AI 网关实战复盘

10 月 15 日早间，DeepSeek 网页端与 App 出现“服务器暂时不可用”提示。据澎湃新闻报道，此次故障从北京时间 8 时 11 分开始，官方状态页于 13 时 04 分更新为服务恢复，前后接近五小时。

DeepSeek 也是 ZStack 日常使用的主力模型之一。这次中断，ZStack 同样经历了。

后续回溯 Zentrix 的调用日志，我们才发现：DeepSeek 中断期间，模型自动切换已经发生，备用模型接替了原来的调用！

业务侧几乎无感，调用记录里却留下了模型切换的过程。Zentrix 根据预先配置的规则处理了上游异常，应用继续通过原来的网关入口调用模型，上游目标的变化由网关处理。

这也让我们能够在事后查看切换情况。业务有没有受到影响，要结合应用运行情况判断；请求最终交给了哪个模型、备用调用是否完成，则可以沿着 Zentrix 的调用记录回查。

接下来回看 Zentrix 留下的调用记录，看看 DeepSeek 中断时，请求如何转向备用模型，以及切换后的流量、安全和费用怎样管理。

在看这次实际调用记录之前，先看 Zentrix 的故障切换逻辑。

正常情况下，业务请求通过 Zentrix 发往主要目标。管理员提前配置备用目标，并设定连接失败、超时或上游返回指定状态码等转移条件。主要目标出现符合规则的异常时，Zentrix 就尝试将请求转发给备用目标，应用继续使用原来的网关地址和凭据。

Zentrix 故障切换逻辑：请求按规则转向备用目标，整次请求的尝试次数与总耗时设有上限。

看下这次实际调用：DeepSeek 是主要目标，阿里云百炼 qwen-plus 是备用目标。业务应用统一向 Zentrix 发起请求，两家供应商的凭据都保存在网关侧。

调用记录：客户端提交 deepseek-chat，请求最终由备用模型 qwen-plus 完成。

客户端提交的模型是 deepseek-chat，主要目标 DeepSeek 显示“未提交”，最终执行的是阿里云百炼 qwen-plus，返回状态码 200。Zentrix 在同一条记录中展示了原始请求、最终模型以及各个目标的尝试结果。

故障转移规则配置好、备用模型通过业务验证之后，上游异常就可以先由 Zentrix 按规则处理，减少业务团队临时寻找供应商、修改接口和等待发布的工作。

一次请求转向备用模型之后，后面还会有新的请求进来。如果 DeepSeek 一直没有恢复，每个请求都重新尝试主力目标、等待超时，再切到备用模型，就会反复消耗用户的等待时间。

Zentrix 可以配合熔断规则处理这种情况。启用熔断后，当失败情况达到设定阈值，网关会暂时跳过异常目标，让后续请求进入备用路径。管理员不需要等各个应用分别报错，再逐一修改供应商配置。

主力服务恢复后，Zentrix 再通过预设的恢复检查，判断原目标是否重新可用，并按规则恢复相应调用。故障期间的切换、持续异常时的跳过，以及恢复后的回切，都在网关侧管理。

下面的实时流量记录截图中，记录了 4 次故障转移，均由备用目标完成；主力目标与备用目标的调用次数、结果和耗时都可以分别查看。

实时流量记录：故障转移 4 次，均由备用目标完成，可查看各目标的调用次数和执行结果。

业务侧看到的是请求继续得到处理，管理员则可以通过这些记录，检查备用模型是否接住了请求，以及切换后是否出现明显的耗时变化。

请求由备用模型处理之后，接下来要确认的是：备用供应商能否接收当前业务数据，调用费用归到哪里，以及这次切换是否留下了完整记录。这些要求需要和备用模型一起配置。

备用模型的价格可能与主力模型不同，但切换后的调用仍属于原来的部门、成员或应用。Zentrix 通过网关凭据及其身份归属汇总调用，并按已配置的额度规则进行约束。管理员调整备用模型时，可以同时检查价格与预算，避免切换后费用归属不清。

Zentrix 网关总览：按组织范围和时间查看用量、费用及调用结果。

日常运行中，Zentrix 的调用记录可以帮助团队查看请求交给了谁、最终有没有完成，以及失败发生在哪个环节。用量和按配置价格计算的费用可以辅助复盘，最终支出再与供应商账单核对。

通过这些记录，团队也可以继续检查备用模型的结果和响应时间。如果某类任务在备用模型上表现不符合要求，就调整备用选择或应用的处理方式；如果请求耗时过长，再检查超时和尝试次数。切换方案也会随着实际使用不断调整。

对于涉及个人信息的请求，Zentrix 可以按规则识别，并执行脱敏或拦截。命中脱敏规则的内容处理后转发，被拦截的请求则停止调用。对数据流向要求更严格的业务，可以提前把备用目标设为企业私有部署的模型，并确认相应策略覆盖这条调用路径。

这次自动切换能在需要时发生，依赖的是故障前已经准备好的模型和规则。日常接入模型时，就要确定备用目标、配置切换条件和等待时限，并验证切换后的业务结果。

备用模型也要拿实际业务任务验证。客服要求的回答格式、代码助手依赖的工具调用、知识问答用到的上下文长度，都可能影响替换后的效果。接口返回成功之后，还要确认应用能够正确处理结果。对备用模型仍无法完成的任务，业务系统也应提前安排转人工或延后处理等方式。

随着企业里的客服、知识库和研发工具都开始使用大模型，如果各团队分别维护供应商凭据、接口适配和切换逻辑，同一家供应商故障就可能引发多处调整。Zentrix 将这些模型调用集中到同一个入口，让管理员在网关侧维护模型和规则，业务应用保持相对稳定的接入方式。

ZStack Zentrix 为企业提供统一的模型调用入口，把供应商凭据、备用模型、流量规则和调用记录放在一起管理。日常接入模型时，就可以把故障转移、恢复机制以及相应的安全和额度规则一并准备好。

企业可以先选一项已经接入大模型的业务，验证主力模型不可用时，备用模型能否接手任务，等待时间是否符合要求，以及切换后的数据、费用和记录是否按预期处理。把这些准备做在平时，上游出现异常时，Zentrix 就有条件按既定规则处理请求，业务团队也能更快定位仍需人工介入的问题。