使用场景
只要应用应请求结果、而不必知道物理模型拓扑,语义路由就有用。同一请求约定可以覆盖托管 API、共享数据中心机群、小型边缘池或混合企业部署。变化的是策略边界,以及谁拥有模型执行。
下面的环境并不互斥。许多部署用数据中心池处理一般流量,用边缘模型处理私有或离线工作,再用选定的云提供方覆盖专项能力。
这就是实用的 Mixture-of-Models 模式:客户端使用稳定的虚拟模型身份,配方描述路由行为,部署特定的提供方绑定把配方的逻辑模型角色连接到各环境中可用的端点。
一览
| 环境 | 典型问题 | Semantic Router 决定什么 | 仍在 Router 之外的部分 |
|---|---|---|---|
| 云 | 多个提供方 API 在能力、成本、延迟和可用性上不同。 | 哪个已批准的提供方或虚拟目标应处理请求。 | 提供方容量、计费、区域服务健康和账户策略。 |
| 数据中心 | 共享加速器机群服务具有不同优势和资源画像的模型。 | 哪个模型池符合任务、策略和请求目标。 | 副本放置、批处理、自动扩缩容和设备调度。 |
| 边缘 | 容量有限,数据可能需要留在本地或离线工作。 | 本地路径是否具备能力,以及是否允许远程升级。 | 设备运行时、模型打包、功耗限制和网络可用性。 |
| 企业混合 | 工作负载跨越租户、区域、信任域以及内部或外部提供方。 | 在身份、驻留、能力和路由策略下哪些路径合格。 | 身份签发、网络控制、密钥管理和数据治理。 |
云:用一条策略覆盖多个模型服务
云应用常常接入不止一个模型提供方。某个提供方可能提供最好的视觉模型,另一个更适合长上下文,较小的托管模型则可能是日常聊天的经济默认项。
Semantic Router 可以暴露一个稳定的模型 API,同时让决策考虑:
- 任务意图、模态、上下文长度和工具要求;
- 提供方允许名单以及区域或合同约束;
- 在合格集合内的成本、延迟或质量目标;以及
- 当预路由证据排除某条路径时,显式升级或拒绝。
这把提供方选择移出应用代码。它不会让提供方账户可以互换:凭据、配额、数据使用条款和区域可用性仍需显式管理。
示例: 文档助手把普通文本路由到经济模型,把带图像的请求路由到具备视觉能力的提供方,把对证据敏感的问题路由到校验路径。客户端继续请求同一个公开模型名。
数据中心:把工作负载匹配到共享模型机群
数据中心可能在同一加速器机群上服务多个开源或私有微调模型。服务平台知道哪些副本健康、哪里有容量;它通常不知道哪个模型家族最符合请求的含义。
Semantic Router 补上这一模型级决策:
- 把代码、数学、语言或领域工作发送到专项池;
- 拒绝缺少所需模态、上下文或工具支持的候选;
- 把更大的模型或多模型工作流留给值得额外算力的请求;以及
- 在同一物理机群上暴露均衡、快速、经济或准确度优先的虚拟模型。
边界是刻意的:Semantic Router 选择模型或模型池;推理平台选择副本,并拥有批处理、缓存局部性、自动扩缩容和加速器调度。
示例: 内部 AI 平台暴露 assistant-fast 和 assistant-accurate。两个入口共享同一提供方池,但隔离的配方使用不同的资格规则和选择算法。