公有模型与私有模型如何统一治理？

公有模型与私有模型不必使用完全相同的运行方式，但应遵循同一套企业治理框架：统一服务身份、访问主体、授权流程、数据边界、计量口径、变更记录和审计要求。统一治理不是强行统一技术栈，而是让不同供给方式进入一致的运营秩序。

为什么两套模型体系容易形成治理断层

公有模型通常通过外部 API 获得，接入快、弹性强；私有模型运行在企业控制的环境中，更便于处理特定数据或定制需求。两者的基础设施、接口和责任边界不同，但最终都会被企业应用消费。

常见断层包括：

• 公有模型 Key 由应用团队保管，私有模型端点由平台团队维护；
• 公有模型按 Token 计费，私有模型只统计 GPU 使用；
• 数据分类规则没有映射到模型服务；
• 同一任务在两种环境之间切换时缺少审批和记录；
• 模型升级、故障和下线流程分别执行；
• 审计只能看到请求或资源，无法形成完整链路。

统一治理应该统一什么

统一服务身份

为每项可消费能力建立稳定服务标识，记录来源、用途、版本、所有者和生命周期。应用消费的是服务契约，而不是临时端点。

统一访问主体

将用户、部门、项目、应用和自动化任务映射到企业身份体系。API Key 只是凭证，不能替代主体和责任归属。

统一授权规则

授权至少回答：谁可以访问、可以访问哪个服务、能处理什么数据、额度是多少、有效期多久。

统一计量语义

公有模型可记录输入输出 Token、请求和供应方费用；私有模型还需要记录实例、GPU 时间和资源成本。底层单位不同，但都应回到服务、调用方和成本主体。

统一生命周期

接入、评测、发布、变更、受限、弃用和下线应有共同状态与审核要求，避免私有服务成为长期无人管理的端点。

统一审计链路

调用记录应能关联调用方、服务、路由结果、时间、授权和计量。敏感内容是否记录、保留多久，需要依据企业安全政策设计。

不应该强行统一什么

差异	为什么需要保留
接口能力	模型的上下文、工具调用和多模态能力不同
部署与容量	公有服务由供应方运营，私有服务受本地资源约束
故障责任	外部供应方与企业内部团队承担不同责任
成本单位	Token 价格与自建算力全成本不能简单等同
数据处理	不同模型和环境允许处理的数据等级不同
版本节奏	外部模型更新与内部发布窗口不同

统一治理的目标是形成可比较、可执行的规则，而不是隐藏这些差异。

六步实施框架

1. 盘点供给：记录公有、私有、自部署和聚合模型服务。
2. 建立服务目录：定义用途、数据边界、所有者和状态。
3. 统一身份授权：把访问权限落到部门、项目和应用。
4. 制定路由政策：明确哪些请求可外发、哪些必须留在私有环境。
5. 连接计量成本：分别保留原始单位，再汇总到统一消费视图。
6. 建立变更审计：覆盖评测、灰度、回滚、弃用和权限回收。

一个实用的策略矩阵

判断维度	更偏向公有模型	更偏向私有模型
数据边界	可外发或已脱敏	敏感、受监管或禁止外发
能力需求	需要快速获得外部前沿能力	需要定制、可控版本或内部知识
需求波动	短期或弹性明显	稳定、可预测且有本地资源
运维能力	希望减少基础设施运维	已具备模型与算力运营能力
连续性	可接受供应方边界	需要企业掌握运行与恢复流程

矩阵不是自动决策器。质量、延迟、成本和合规仍需通过评测和业务规则共同判断。

AGIOne 如何支持跨环境治理

AGIOne 可以把外部模型、私有模型和平台部署模型纳入模型服务目录，通过统一 API、授权、API Key、策略路由和 Token 计量组织消费；公共治理域连接租户、角色、额度、账单与运营规则。

对于私有部署，算力与部署结果还需要进入服务发布和计量链路。具体环境、模型和硬件适配范围必须以已验证产品清单为准。

FAQ

统一治理是否意味着所有请求都经过同一个网关？

不一定。统一治理关注规则、身份、目录、计量和审计的一致性，具体数据路径应根据延迟、安全和架构要求设计。

私有模型一定更安全吗？

不一定。私有部署提供更强的环境控制，但安全仍取决于身份、授权、网络、日志、漏洞和运维流程。

公有模型和私有模型成本如何比较？

应分别计算供应方费用与私有环境全成本，再结合质量、延迟、利用率和运维责任比较，不能只比较单一 Token 单价。

是否应该为同一任务保留两类模型？

取决于连续性、数据边界和成本要求。如果保留备用服务，还需要健康检查、降级、恢复和定期演练。

模型品牌应该成为治理规则吗？

品牌可以影响合同和能力评估，但治理规则应优先围绕服务、数据、主体和风险等级，避免策略与单一品牌绑定。

下一步

先建立公有与私有模型供给清单，并为每项服务补齐数据边界、所有者、授权和计量字段。随后再设计路由、变更和退出政策。