AI 基础能力平台 · 平台概览与架构设计准则
1. 平台定位与愿景
1.1 我们构建的是什么？
AI 基础能力平台是一套覆盖 「算力 → 模型 → 网关 → 应用 → 业务」 全链路的 AI 基础设施平台。它不是某一个具体的工具或产品，而是一个承上启下的能力基座：
- 对下：抽象和统一管理异构的 GPU/NPU 算力资源、多元的推理引擎、碎片化的模型资产
- 对上：为业务应用提供标准化的模型推理服务、Agent 构建能力、RAG 知识检索、MCP 工具接入
1.2 平台价值主张
🏭 算力集约管理
将分散的 GPU/NPU 资源池化为统一算力，按需分配、精细计费。目标：GPU 平均利用率从行业平均的 30% 提升至 70%+。
⚡ 模型敏捷交付
从模型选型到服务上线缩短至分钟级。一键部署、灰度发布、自动扩缩容、LoRA 热加载，消除运维瓶颈。
🔗 应用快速构建
通过 Agent 平台、Dify 工作流、RAG 平台、MCP 接入四大基座，业务团队无需关注底层模型细节，直接使用平台能力构建 AI 应用。
🛡️ 安全治理闭环
全链路审计、内容安全过滤、模型级访问控制、数据不出域，满足企业级安全合规要求。
1.3 平台使用角色
| 角色 | 关注范围 | 典型行为 |
|---|---|---|
| 运维工程师 | L1 基础设施层 | 管理 GPU 集群、配置监控告警、处理故障节点 |
| MLOps 工程师 | L2 部署层 + L3 市场层 | 部署模型服务、配置扩缩容策略、管理模型版本 |
| 平台管理员 | L4 网关层 + 横切关注点 | 配置路由策略、管理 API Key、设置安全策略 |
| AI 应用开发者 | L5 基础应用层 | 构建 Agent、编排 Dify 工作流、搭建 RAG 知识库 |
| Agent 编排者 | L6 多 Agent 管理层 | 设计多 Agent 协作流程、注册 Skill/Tool |
| 业务产品经理 | L7 业务应用层 | 使用智能问数、配置数字人、创建漫剧 |
2. 核心设计原则
架构设计准则：以下六条原则是本平台所有架构决策的元规则。任何层级的任何设计决策都应回溯到这些原则进行验证。
| 原则 | 定义 | 实施要求 | 反模式 (不允许) |
|---|---|---|---|
| 🔌 分层解耦 | 每层独立演进、独立部署，仅通过标准 API 交互 | 每层有自己的 API 契约、SLA、版本号；变更向下兼容 | 跨层直接调用数据库、跨层共享代码库、上层绕过网关直接调用推理服务 |
| 🌐 开放兼容 | 兼容主流开源生态，避免供应商锁定 | API 遵循行业标准 (OpenAI-compatible、MCP Protocol)；支持多引擎/多供应商可替换 | 私有协议、单一供应商绑定、无法替换的硬编码依赖 |
| 🔒 安全可控 | 数据不出域、模型本地化、全链路审计 | 每层独立鉴权、审计日志不可篡改、敏感数据加密存储 | 明文传输模型推理数据、跳过审计日志、共享 API Key |
| 📈 弹性伸缩 | 从单机到千卡集群，按需扩缩容 | 所有服务支持水平扩展、支持 Scale to Zero、自动故障转移 | 硬编码单点、固定资源分配、无法自动恢复的故障模式 |
| 👁️ 可观测性 | 全链路追踪、指标采集、日志聚合 | 每层暴露 Metrics/Traces/Logs 三支柱、定义 SLI/SLO | 黑盒服务、无健康检查、无告警定义 |
| 🧑💻 开发者友好 | SDK/CLI/API/WebUI 多入口，降低接入门槛 | OpenAPI 文档、多语言 SDK、交互式 Playground | 仅内部 API、无文档、无示例代码 |
3. 总体架构
3.1 分层边界定义
平台采用严格的七层分层架构。每层有明确的职责边界、对外接口和依赖方向：依赖只允许从上层指向下层，不允许反向依赖或跨层穿透。
3.2 数据流向
平台的请求链路（上行）和响应链路（下行）严格遵循层级顺序。同时有两个关键分支：内部模型推理路径和外部模型代理路径。
3.3 层间关联矩阵
下表定义了所有层级之间的直接依赖关系（U=上游使用,D=下游提供）、数据传递方向和SLA 传递规则。
| L1 | L2 | L3 | L4 | L5 | L6 | L7 | |
|---|---|---|---|---|---|---|---|
| L1 | — | D: 算力/存储/网络 通过 K8s API |
禁止直接 | 禁止直接 | 禁止直接 | 禁止直接 | 禁止直接 |
| L2 | U: 调度资源 Pod/GPU请求 |
— | D: 推理服务端点 注册到 L3 |
禁止旁路 | 禁止直接 | 禁止直接 | 禁止直接 |
| L3 | 禁止直接 | U: 获取部署状态 注册模型版本 |
— | D: 模型路由表 查询接口 |
禁止直接 | 禁止直接 | 禁止直接 |
| L4 | 禁止直接 | 禁止旁路 | U: 查询路由信息 模型发现 |
— | D: 统一推理接口 OpenAI API |
禁止直接 | 禁止直接 |
| L5 | 禁止直接 | 禁止直接 | 禁止直接 | U: 调用模型推理 Agent/RAG 调用 |
— | D: 单Agent能力 平台 API |
禁止直接 |
| L6 | 禁止直接 | 禁止直接 | 禁止直接 | 禁止直接 | U: 编排单Agent 多Agent编排 |
— | D: 多Agent编排能力 编排 API |
| L7 | 禁止直接 | 禁止直接 | 禁止直接 | 禁止直接 | 禁止直接 | U: 调用编排能力 业务集成 |
— |
图例说明:
U: 上游使用 (蓝色) = 上层调用下层提供的接口 |
D: 下游提供 (绿色) = 下层暴露给上层的 API |
禁止直接/禁止旁路 (红色) = 违反分层解耦原则，不允许
4. 关键设计决策
| 决策 | 选择 | 理由 |
|---|---|---|
| 为什么是七层？ | 七层严格分层 vs 简化三/四层 | 每层的运维节奏和负责团队不同。GPU 集群运维、模型部署、资产管理、网关治理、Agent 编排是不同的专业领域。合并层级会导致变更耦合、故障爆炸半径扩大。 |
| L1-L2 为什么分离？ | 算力管理和推理服务独立 | GPU 的采购/上架/故障替换（月级）与模型部署/扩缩容/灰度发布（分钟级）是完全不同的运维节奏。 |
| L2-L3 为什么分离？ | 部署运行 vs 资产管理 | 一个模型可以在市场注册但未部署；也可以部署多个版本在市场管理。部署状态是运行时概念，模型版本是生命周期概念。 |
| L3-L4 为什么分离？ | 模型市场 vs 模型网关 | 市场是"有什么模型"，网关是"怎么访问模型"。网关需要处理鉴权/限流/路由等模型无关的横切逻辑。 |
| L4-L5 为什么分离？ | 原始推理 vs 高阶应用 | 网关提供原始 token-in/token-out 推理接口；L5 提供 Agent 循环、RAG 管线、工作流编排等高阶能力。两类能力的用户角色和 SLA 不同。 |
| L5-L6 为什么分离？ | 单 Agent vs 多 Agent | 单 Agent 的构建/运行（L5）和多个 Agent 的编排协作（L6）是不同的复杂度。L6 解决的是 Agent 间通信、任务分配、结果聚合等更高维度的问题。 |
| 为什么用 OpenAI-compatible API？ | 统一协议 + 生态兼容 | LangChain、LlamaIndex、Dify 等主流生态都使用此协议。采用它可以零适配接入大量工具，降低开发者迁移成本。 |
4.1 SLA 传递规则
上层 SLA 依赖于下层 SLA。各层需要保障自身的 SLO 以支撑上层的 SLO 目标：
| 层级 | 关键 SLI | SLO 目标 | 支撑的上层 |
|---|---|---|---|
| L1 | GPU 集群可用性 | 99.9% | L2 推理服务可用性 |
| L2 | 推理服务可用性 / P99 延迟 | 99.95% / <2s (7B), <5s (70B) | L4 请求成功率 |
| L3 | 模型元数据查询延迟 | <10ms (P99) | L4 路由决策延迟 |
| L4 | 网关可用性 / 路由延迟增量 | 99.99% / <5ms (P99) | L5 应用请求成功率 |
| L5 | 检索 Recall@5 / Agent 任务成功率 | >0.90 / >85% | L6 编排成功率 |
| L6 | 编排执行成功率 | >80% | L7 业务可用性 |
| L7 | 业务请求成功率 / P99 延迟 | >99% / 依业务而定 | 最终用户体验 |