单个 AI Gateway 位于一组工作 AI 服务器前端。应用程序通过一个 URL 和一个密钥连接到网关，就像连接到单个 AI Server 一样；在其背后，网关将每个请求负载均衡分配给各个工作服务器，进行健康检查，并在工作服务器出现故障前将流量转移到健康服务器，确保调用方无感知 [1]。这不是一个独立产品。AI Gateway 是以集群前端模式运行的 AI Server，因此兼容 OpenAI /v1/* 和 Ollama 兼容的 /api/* 接口，暴露的单一服务器功能与集群暴露的完全一致 [1]。
一个 URL 和一个密钥，背后是一整个集群
网关平衡平台支持的所有请求类型：聊天、嵌入、图像生成、视觉和音频，包括实时语音 WebSocket [1]。请求由您选择的策略分配——轮询、最低延迟、最少连接数、加权或基于客户端的粘性。模型感知路由将请求发送到已加载所需模型的工作服务器，避免了冷启动惩罚，防止请求被较冷的机器处理 [1]。
添加 GPU 服务器即可扩展容量；客户端无需更改。维护时关闭服务器，其流量会优雅地转移，确保无正在进行的请求被丢弃。我们在自测套件中故意中断工作服务器以验证此保证：出现故障的服务器请求会在健康服务器上重试，故障切换在网关内部完成，客户端不会看到错误 [1][3]。
集群引入的信任边界
集群改变了凭证的持有者，设计保持边界严格。客户端的网关密钥永远不会传递给工作服务器。网关为每个工作服务器提供独立密钥，因此泄露的网关密钥无法直接重放到工作服务器，且每个工作服务器的凭证仅限集群内部使用 [2]。调用方身份，即发起请求的应用及安装信息，会传递给工作服务器。每个工作服务器的无内容审计日志因此记录真实发起者，而非全部归因于网关 [2]。
背压机制替代超时
当所有工作服务器均已饱和时，网关返回明确的“请稍后重试”信号，而非保持连接直至超时 [1]。调用方获得可响应的信号。两个发布控制机制基于同一路由层：金丝雀发布在新服务器承载全部负载前，分配固定流量；零停机升级则先排空服务器，升级后再返回集群，端点始终在线 [1]。
无需手动编辑池的 Kubernetes
在 Kubernetes 上，工作节点会随着扩展自动被发现，因此自动扩展的集群无需手动编辑网关的工作节点列表。该方案从一个产品中提供三种形态：用于单机演示的 Docker Compose、Kubernetes 清单和用于集群的 Helm Chart。无论是一台笔记本还是 GPU 集群，产品、API 和许可证都是相同的。
运营一个集群的成本
每台服务器（包括网关）都托管自己的实时仪表盘，并暴露原生的 Prometheus 指标，用于监控集群的健康状况、延迟、使用率和容量。集群可视化通过一个仪表盘实现，而非在首次请求前组装的监控堆栈。网络服务在每个节点都受到限制：非回环地址绑定失败会自动关闭，除非该节点拥有 Pro 授权和至少一个 API 密钥，这防止了未授权或无密钥的设备在局域网中悄然暴露自己。
网关集群是平台可用性保障的拓扑结构：当某台设备宕机时，AI 端点依然在线，且请求路径中不经过任何供应商云。它作为 Pro 商业版的一部分授权，而非单独销售的产品。