大模型网关私有化部署，要把应用入口、模型出口、管理后台和运行数据安排好。
MAI Gateway 支持私有部署、统一模型接入、组织权限、费用管理、安全策略和审计。企业可以连接公共模型，也可以接入已有私有模型，按业务需要分配访问权限与调用路线。
下面按单机试点、生产集群和本地模型三种部署方式展开。
一 先确定数据经过哪些位置
私有部署以后，网关由企业运行。请求最终发到哪里，仍由上游模型和路由策略决定。
公共模型路线会把处理后的请求送到外部供应商。私有模型路线则调用企业自己的推理服务。完全离线环境只能访问内网已有的模型与服务。
| 部署路线 | 网关位置 | 推理位置 | 适合的业务 |
|---|---|---|---|
| 私有网关加公共模型 | 企业机房或专有VPC | 外部模型供应商 | 需要统一管理的办公与研发应用 |
| 私有网关加私有模型 | 企业网络 | 内部推理节点 | 客户资料、合同、研发数据处理 |
| 混合部署 | 企业网络 | 公共与私有模型并存 | 按数据类型和任务分流 |
| 完全离线 | 隔离网络 | 内部推理节点 | 无外网连接的业务环境 |
MAI Gateway 官网还提供带本地 GPU 和预装模型的 S 系列算管一体机，适合需要同时部署推理与管理能力的企业。
二 单机试点架构
单机方案适合先验证模型、令牌、预算和业务接入。下面是部署职责示意。
flowchart LR
A["企业应用与测试客户端"] --> B["HTTPS入口"]
B --> C["MAI Gateway"]
C --> D["公共模型API"]
C --> E["企业私有推理服务"]
C --> F["配置与用量持久化"]
C --> G["调用日志与告警"]
H["管理员"] --> C三 生产环境推荐拓扑
MAI Gateway 支持高可用集群和水平扩展。生产部署可以采用以下拓扑，将入口、业务副本与持久化服务分别管理。
flowchart TB
A["办公应用／研发工具／业务Agent"] --> B["企业负载均衡与HTTPS入口"]
subgraph P["网关运行区"]
B --> C1["MAI Gateway副本A"]
B --> C2["MAI Gateway副本B"]
end
subgraph S["内部支撑服务"]
D["配置与用量存储"]
E["共享配额／缓存服务"]
F["日志与监控平台"]
end
C1 --> D
C2 --> D
C1 --> E
C2 --> E
C1 --> F
C2 --> F
C1 --> G["受控模型出口"]
C2 --> G
G --> H["公共模型供应商"]
C1 --> I["内部推理节点"]
C2 --> I
J["管理员／企业身份系统"] --> K["受限管理入口"]
K --> P这是生产部署建议图。数据库、缓存和配额状态的具体组件按交付版本配置。
这张图里有三项部署要求。
第一，副本分散到不同服务器。两个容器放在同一台主机，无法覆盖主机故障。
第二，业务需要共享的配置、配额和消费状态保持一致。请求落到不同副本后，权限和预算不能各算一份。
第三，支撑服务也要有恢复方案。网关副本增加以后，数据库、共享限流服务和负载均衡仍可能影响整体可用性。
四 单机、虚拟机集群与Kubernetes怎么选
| 方式 | 适合阶段 | 优点 | 运维工作 |
|---|---|---|---|
| Docker单机 | 试点、内部测试、可接受停机的轻量业务 | 组件少，排障直接 | 数据持久化、备份、升级 |
| 多虚拟机加负载均衡 | 已有虚拟化平台的生产环境 | 与现有运维方式接近 | 副本分布、配置一致性、依赖高可用 |
| Kubernetes | 已有容器平台的企业 | 便于编排、探针、滚动发布与资源管理 | 集群、存储、网络和应用配置 |
| 算管一体机 | 需要本地模型与GPU的企业 | 推理和网关一并交付 | 模型容量、设备维护和扩容 |
没有 Kubernetes 平台时，不必为了部署一个网关单独建设集群。已有成熟容器平台时，则可以复用现有发布、监控和备份体系。
五 网络按四条路径配置
业务访问路径
应用通过固定域名和 HTTPS 调用网关。入口超时、请求体大小和流式响应设置，要与实际业务匹配。
模型调用路径
网关访问批准的公共供应商或内网推理服务。公共出口与私有模型路线分别配置，便于控制和排障。
管理路径
管理员通过企业内网、VPN 或其他受控入口访问后台。管理端口不必向所有业务应用开放。
运维路径
网关访问日志、告警、备份和必要的运行依赖。离线环境还要准备镜像、安装包、证书和升级包的内网交付路径。
MAI Gateway 支持令牌分发、组织权限、调用监控与审计。网络访问规则与产品权限一起使用，才能把应用调用和后台管理安排清楚。
六 容量按请求特征估算
稳态条件下，平均在途请求数可以用下面的关系估算。
平均在途请求数 ≈ 每秒进入的请求数 × 平均请求持续时间例如，平均每秒进入 10 个请求，每个请求持续 20 秒，平均约有 200 个请求同时在途。这是计算示例，不代表某款设备的承载指标。
容量评估至少看这些变量。
| 变量 | 对部署的影响 |
|---|---|
| 峰值请求速率 | 网关处理、上游配额和限流 |
| 请求持续时间 | 同时保持的连接数量 |
| 上下文长度 | 内存、请求体和安全处理开销 |
| 图片、音频与文件 | 带宽、上传限制与处理时间 |
| 日志记录量 | 存储、写入压力和保留成本 |
| 重试次数 | 故障时额外放大的请求量 |
扩容时也要观察上游模型。网关资源充足，上游额度或限流仍会限制最终吞吐。
七 健康检查要区分三种情况
Kubernetes 将启动、存活和就绪检查分开处理。启动检查给应用初始化留时间，存活检查判断是否需要重启，就绪检查决定是否继续接收流量。
部署 MAI Gateway 时，可以沿用这个分工。
| 检查 | 需要回答的问题 |
|---|---|
| 启动检查 | 服务是否完成初始化 |
| 存活检查 | 进程是否还能正常工作 |
| 就绪检查 | 当前副本是否适合接收新请求 |
外部模型供应商暂时不可用时，优先使用路由、回退和告警处理。把供应商故障直接等同于网关进程故障，可能导致所有副本反复重启。
八 网关产品架构图
