AI 应用上线后，运维团队最怕的一件事是：模型服务挂了。

单点接入大模型时，一旦 API 不稳定、余额耗尽、或者厂商限流，所有调用都会失败。轻则用户等待超时，重则核心业务停摆。生产环境里这种情况很常见——某次凌晨主流厂商接口抖动，公司内部所有 Agent 集体卡死，第二天才被发现。

更现实的问题是，AI 应用通常不会只用一家模型。中文场景用国内大模型，国际场景用国际大模型，私有化场景用开源模型。每接一个模型，都要写一套调用代码、配置一套认证参数、处理一套异常逻辑。模型越多，运维成本越高。

解决这个问题的核心思路有两个：一是 统一接口抽象，把不同厂商的差异屏蔽在适配层；二是 资源池 + 负载均衡 + 故障隔离，让模型调用具备高可用能力。这两个设计做好了，AI 资源管理才能从"能用"走向"稳定用"。

一、多模型适配：让业务代码只认 SN，不认厂商

业务侧只想调用一个接口

AI 应用里有几十个 Agent，每个 Agent 都要调用 LLM。如果每个 Agent 都要关心"我现在调的是哪家厂商的哪个模型"，业务代码就会被厂商差异淹没。

AIGS 框架的解法是 统一资源抽象层。框架内部对主流厂商做了适配，覆盖国内大模型、国际大模型、开源部署、云服务四大类场景。

业务侧调用模型时，只需要提供 资源 SN——这是框架分配给每个模型资源的唯一编码。框架根据 SN 找到对应的厂商适配器，按适配器的协议发起请求。业务代码完全不感知底层厂商，切换模型只需要在资源管理中心改配置。

这种设计带来三个好处：接口统一、配置隔离、透明切换。业务代码只关注"用哪个 SN"，认证参数由资源中心独立管理，切换厂商不需要改一行业务代码。

二、负载均衡：用均衡组模式实现高可用

单点模式的隐患

如果只用单个资源承接所有请求，一旦这个资源挂了就全军覆没。生产环境里至少要准备两个同类资源做冗余。

AIGS 框架提供两种资源组织形式：

资源项模式：单一资源直接使用，适用于测试环境或特殊模型。

均衡组模式：多个同类资源组成一个组，由负载均衡器统一调度。这是生产环境推荐的方式。业务代码调用时只需要提供均衡组的 SN，框架自动从组内选出一个可用资源处理请求。如果某个资源失败，下一次调用会自动路由到其他健康资源。

均衡组内部的资源选择通常采用 轮询 思路，每次调用按顺序分配给组内资源，避开单点过载。业务代码调用时，框架返回选中的资源实例，业务方无需关心"我这次用到了组里的哪个具体资源"，均衡组对调用方是透明的。

三、故障隔离：让一次失败不拖垮整个调用

负载均衡解决了"请求分散"的问题，但没有解决"失败资源拖垮请求"的问题。如果一个资源持续失败，不做隔离的话，每次轮询到它都会失败一次，浪费时间和重试预算。

AIGS 框架内置了 故障隔离机制，核心思想是：失败计数 + 临时隔离 + 成功复位。

工作机制：

失败回报：某次调用失败，框架把该资源的连续失败计数累加。如果达到阈值，触发隔离，资源在隔离期内不参与分配。

成功回报：某次调用成功，框架把该资源的连续失败计数清零，并取消隔离状态。资源恢复正常参与分配。

这个设计的工程价值是 让临时性的网络抖动不会演变成持续故障。比如某个资源因为网络问题连续失败触发隔离，后续请求都分配给其他健康资源。等隔离结束，如果该资源恢复成功，就重新加入分配。

一次故障处理的时间线

把"故障隔离 + 负载均衡"组合起来看，一次真实故障的恢复路径大致是这样的：

• 00:00:00 调用失败。 资源 A 返回异常，框架把 A 的连续失败计数加 1，计数变为 1。
• 00:00:01 路由切换。 下一轮请求被均衡组路由到资源 B，B 返回成功，业务不感知。
• 00:00:05 累计失败。 资源 A 在接下来 5 秒内又被选中 2 次，连续失败计数达到阈值，触发隔离。
• 00:00:05 ~ 00:00:35 隔离期。 后续隔离时长内所有请求都分配给 B 和 C，A 不参与。
• 00:00:36 隔离结束。 A 重新参与分配，假设恢复成功，计数清零。
• 00:01:00 业务平稳。 用户侧只感知到一次轻微延迟，没有失败。

这条时间线说明：故障隔离的设计目标不是"让失败消失"，而是"让失败局限化"。一个能稳定处理局部故障的系统，比一个号称永不出错的系统更可信。

四、Embedding 资源管理：维度一致性的坑

LLM 之外，Embedding 向量模型也是 AI 资源的重要组成部分。Embedding 资源的管理思路与 LLM 相同——SN 寻址、均衡组、故障隔离。

Embedding 管理有一个容易踩的坑——同一个均衡组内的资源必须维度相同。比如均衡组里同时有低维模型和高维模型，查询时返回的向量长度不一致，会直接导致检索异常。

正确的做法是均衡组内全部用相同维度的模型。切换 Embedding 模型后还要注意一件事：必须重新对知识库做向量化——不同模型的向量不具备互换性，原来的向量数据在新的模型下完全用不了。

五、向量数据库资源：统一 VDB 接口

向量数据库（VDB）是知识库检索的核心存储。AIGS 框架对多种主流 VDB 做了适配，覆盖开源版、商业版、云服务版等。

业务侧调用时通过 VDB 资源 ID 标识，框架内部按类型路由到对应适配器。资源中心统一管理连接信息和运维参数。

这种设计与 LLM 资源管理是同一个思路——业务代码只认资源 ID，不认底层数据库。VDB 切换时，业务代码不用改。

六、实战建议

1. 生产环境优先用均衡组模式，单点资源做测试或非关键场景用。
2. 同组资源放不同厂商或不同账号，避免单一厂商故障影响整个组。
3. Embedding 均衡组确保维度一致，切模型前先确认维度。

总结

AI 资源管理的核心是 多模型适配 + 负载均衡 + 故障隔离。统一接口抽象让业务代码只认 SN 不认厂商，均衡组模式实现请求分散和高可用，故障隔离机制避免单点失败拖垮整体调用。Embedding 和向量数据库资源也采用同样的管理思路——统一接口、SN 寻址、按需切换。

JBoltAI 通过资源管理中心把这套体系做了标准化封装，覆盖 LLM、Embedding、VDB 等核心资产类型，配合均衡组、轮询调度、故障隔离等机制，让 AI 资源具备生产级的稳定性。这是一条可参考的工程化落地路径。

最后留一句反共识的话：评估 AI 资源管理做得好不好，不要看"接了多少家模型"，要看"切掉其中一家，业务能不能 5 分钟内恢复"。接得多但切不动，等于在用高可用架构堆一个单点系统。