摘要
1) 一句话总结 本文详细介绍了一种基于单节点 OpenShift 构建的企业级本地多租户 GPUaaS 架构，通过自动化控制循环、严格的 Kubernetes 命名空间隔离和精细的 GPU 划分，为 AI 团队提供安全、自助且成本可控的实验与生产平台。
2) 关键要点
- 硬件与底层基础：部署于单台 Cisco UCS C845A 服务器（配备 2 块 NVIDIA RTX PRO 6000 Blackwell GPU、3.1TB NVMe），采用单节点 OpenShift (SNO) 集群架构。
- GPU 划分策略：采用混合策略，GPU 0 通过 MIG 划分为 4 个
1g.24gb切片（适合 7B-14B 模型），GPU 1 保持 96GB 完整显存（适合 70B+ 模型或全精度推理）。 - 时间切片 (Time-slicing)：完整 GPU 设置 4 个副本，MIG 切片设置 2 个副本，允许在单个会话中并发运行多个 GPU 加速容器。
- 三层架构设计：
- 调度平面：基于 FastAPI 和 React UI，利用 PostgreSQL 咨询锁防止 GPU 预订冲突。
- 控制平面：基于 Python 的协调器（Reconciler）以 30 秒为周期运行幂等循环，负责同步数据库期望状态与集群实际状态，并处理资源清理与垃圾回收。
- 运行时平面：为每个会话提供完全隔离的 Kubernetes 命名空间、600GB NVMe 存储及预缓存的推理引擎（vLLM、Ollama 等）。
- 安全与资源隔离：通过命名空间级别的 RBAC 限制用户权限（无集群级访问权），并利用 ResourceQuota 和 LimitRange 强制执行硬性资源上限。
- 灵活的分配模式：用户可按需选择“交互式 ML”（工作区直接挂载 GPU 用于训练/调试）或“推理容器”（轻量级工作区，GPU 专用于部署推理服务）。
- 成本量化模型：采用“每百万 Token 成本”作为统一指标，通过预订系统和 GPU 划分最大化硬件利用率以降低单 Token 成本。
3) 风险与局限性（基于原文）
- 物理隔离部署复杂性：对于受监管行业，无法使用便捷的联网辅助安装，必须提前下载镜像并同步到本地注册表进行离线安装。
- 时间切片的性能折损：时间切片会导致工作负载共享显存和计算带宽，吞吐量存在权衡，不适合对延迟极其敏感的生产环境推理（此类场景需使用专用 MIG 或完整 GPU）。
- 节点 OOM 风险：如果未严格强制执行 ResourceQuota 硬性资源上限，失控的训练任务可能会导致节点内存耗尽（OOM）。
- 早期阶段的成本劣势：虽然本地部署在稳态企业级需求下具有成本优势，但在测试、演示和 POC（概念验证）阶段，云端方案通常更便宜。
正文
AI 技术正在迅速发展，软件工程师不再需要死记硬背代码语法。然而，像架构师一样思考，并理解如何让系统在规模化下安全运行的技术，正变得越来越有价值。
作为思科的 AI 解决方案工程师，在过去的一年里，我每天都在与医疗保健、金融服务、制造业和律师事务所等不同行业的客户打交道。他们都在试图解答几乎相同的一组问题：
- 我们的 AI 战略是什么？
- 哪些用例真正适合我们的数据？
- 选择云端、本地部署还是混合模式？
- 成本是多少——不仅是现在，而是规模化之后？
- 我们如何保障其安全性？
一旦你试图将 AI 从概念验证（POC）推向实际运营，这些现实的约束条件就会立刻显现。
最近，我们在实验室增加了一台 Cisco UCS C845A 服务器。它配备了 2 块 NVIDIA RTX PRO 6000 Blackwell GPU、3.1TB NVMe 存储、约 127 个可用 CPU 核心以及 754GB 内存。我决定在此基础上构建一个共享的内部平台——为团队提供一个一致的、自助式的环境，用于运行实验、验证想法并积累 GPU 的实操经验。
我将该平台部署为单节点 OpenShift (SNO) 集群，并在其上构建了多租户的 GPUaaS（GPU 即服务）体验。用户通过日历 UI 预订计算容量，系统会自动配置一个隔离的机器学习环境，其中预装了 PyTorch/CUDA、JupyterLab、VS Code 等工具。在该环境中，用户可以运行按需推理、迭代模型训练和微调，并构建生产级别的微服务原型。
本文将详细介绍这一架构——系统如何做出调度决策、如何隔离租户，以及平台如何进行自我管理。我们在构建这个实验室平台时所做的决策，正是任何认真对待 AI 生产环境的组织都会面临的决策。
这是规模化企业 AI 的基础。多智能体架构、自助式实验、安全的多租户隔离、成本可预测的 GPU 计算，这一切都始于构建一个正确的平台层。
初始设置
在平台成型之前，我们面对的只是一台裸金属服务器和一个黑屏。
引导节点启动 服务器出厂时没有操作系统。对于 OpenShift，安装通常通过 Red Hat Hybrid Cloud Console 的辅助安装程序（Assisted Installer）开始。它通过引导流程处理集群配置，完成后会生成一个发现 ISO（预配置的 RHEL CoreOS 镜像）。通过 Cisco IMC 将 ISO 映射为虚拟媒体并启动，节点会连接控制台，随后即可开始安装。几小时内，你就能拥有一个运行中的集群。
这种工作流假设设备已连接互联网。但对于许多在物理隔离（Air-gapped）环境中运行的受监管行业客户来说，流程则有所不同：需要在本地生成配置，提前下载镜像并同步到本地的 Quay 注册表中，然后指向该注册表进行安装。辅助安装更为简便，而物理隔离路径则是受监管行业生产环境的真实写照。
配置 GPU 安装 NVIDIA GPU Operator 后，我通过两个 ConfigMap 配置了这两块 GPU 的呈现方式：
- 物理分区 (MIG)： 采用混合策略。GPU 0 被划分为 4 个
1g.24gb的 MIG 切片（每个切片约有 24GB 独立显存）；GPU 1 保持完整，供需要全部 96GB 显存的工作负载使用。MIG 提供了真正的硬件隔离，工作负载会将 MIG 实例视为独立的物理设备。 - 时间切片 (Time-slicing)： 允许多个 Pod 通过快速的上下文切换共享同一个 GPU 或 MIG 切片。我将完整 GPU 设置为 4 个副本，每个 MIG 切片设置为 2 个副本。这使得在单个会话中可以并排运行多个推理容器。
基础存储 3.1TB 的 NVMe 由 LVM 存储 Operator 管理。我配置了两个 PVC：一个用于支持 PostgreSQL，另一个用于 OpenShift 内部镜像注册表的持久化存储。
系统架构
平台的架构分为三个平面：调度平面、控制平面和运行时平面，并以 PostgreSQL 数据库作为单一事实来源。
在平台管理命名空间中，有四个常驻部署：
- 门户应用 (Portal app)： 运行 React UI 和 FastAPI 后端的单一容器。
- 协调器 (Reconciler)： 持续使集群状态与数据库匹配的控制循环。
- PostgreSQL： 存储用户、预订、令牌和审计历史的持久化状态。
- 缓存守护进程 (Cache daemon)： 节点本地服务，预先暂存大型模型和推理引擎，以便用户快速启动。
调度平面 这是面向用户的入口。用户查看资源池（GPU、CPU、内存），选择时间窗口和 GPU 分配模式，然后提交预订。
GPU 是昂贵的硬件，无论是否使用都有实际的每小时成本。预订系统将日历时间和物理容量视为组合约束，就像预订会议室一样，只不过这个“会议室”拥有 96GB 显存且价格不菲。系统在底层使用咨询锁（advisory locks）查询重叠的预订，以防止重复预订。FastAPI 服务器非常轻量，它只负责验证输入、持久化预订并返回结果，从不直接与 Kubernetes API 交互。
控制平面 平台的核心是基于 Python 的协调器（Reconciler）。它以 30 秒为周期持续循环运行，负责推动系统达到期望状态。
数据库保存期望状态，协调器读取该状态，并与 Kubernetes 集群的实际状态进行对比和收敛。如果协调器崩溃，重启后会准确地从中断处继续，因为事实来源（期望状态）完好无损地保存在数据库中。
每个协调周期按顺序评估四个事项：
- 停止过期或取消的会话，并删除命名空间（级联清理内部所有资源）。
- 修复失败的会话，清理因配置未完成而遗留的孤儿资源。
- 当预订时间到达时启动符合条件的会话——配置并向用户交付工作区。
- 维护数据库，清理过期令牌并执行审计日志保留策略。
启动会话的每一步都是幂等的（如果中断可以安全地重新运行）。协调器是唯一与 Kubernetes API 交互的组件。此外，垃圾回收也内置在同一个循环中（以约 5 分钟的较慢频率运行），用于清理跨命名空间的孤儿资源。系统设计始终假设故障是常态，具备强大的自我修复能力。
运行时平面
预订窗口开始时，用户通过浏览器进入一个完整的 VS Code 工作区，其中预装了整个 AI/ML 技术栈，并在其会话命名空间内拥有 kubectl 访问权限。
常用的推理引擎（如 vLLM、Ollama、TGI 和 Triton）已缓存在节点上，部署模型服务器只需几秒钟。每个会话分配了 600GB 的持久化 NVMe 存储。
每个会话都是一个完全隔离的 Kubernetes 命名空间。协调器会配置命名空间级别的 RBAC，授予该边界内的完全管理员权限，但用户没有集群级别的访问权限。ResourceQuota 强制执行硬性资源上限（防止失控的训练任务导致节点 OOM），LimitRange 会自动为每个容器注入合理的默认值。
用户可以自由部署推理服务器、数据库或自定义服务，平台则负责提供安全护栏。预订结束时，协调器会彻底删除该命名空间及其内部的所有内容。
GPU 调度
MIG 与时间切片 从调度角度来看，GPU 0 被划分为 4 个 MIG 切片（适合 7B–14B 参数模型），GPU 1 保持完整（适合 70B+ 模型训练或全精度推理）。
预订系统将它们视为不同的资源类型。会话的 ResourceQuota 会硬性拒绝非预订类型的资源请求。如果你预订了 MIG 切片，即使完整 GPU 处于空闲状态，你也无法请求它。
时间切片允许 1 个物理 GPU 显示为 4 个可调度资源，每个 MIG 切片显示为 2 个。这意味着用户预订一个物理 GPU 后，可以在其会话中并发运行多达四个 GPU 加速容器（例如同时运行 vLLM、Ollama、TGI 和一个自定义编排服务）。
两种分配模式 在预订时，用户可以选择 GPU 预算的分配方式：
- 交互式 ML： 工作区 Pod 直接挂载 GPU。用户打开 Jupyter 即可获得 CUDA 访问权限进行训练或调试。
- 推理容器： 工作区是轻量级的，不挂载 GPU。所有时间切片容量都可用于用户部署的推理容器。
时间切片在吞吐量上存在权衡（工作负载共享显存和计算带宽），这对于开发和测试非常合适。但对于对延迟极其敏感的生产环境推理，应使用专用的 MIG 切片或完整 GPU。
GPU “Token 经济学” (Tokenomics)
真实部署场景 在生产环境中，几乎没有人只在一个端点后运行单一模型。常见的模式是“模型舰队”：7B 模型处理简单分类（运行在 MIG 切片上），14B 模型处理摘要，70B 模型处理复杂推理。请求会根据复杂度和成本约束路由到合适的模型。
在多智能体系统中，智能体订阅消息总线并处于待机状态（没有冷启动惩罚）。编排智能体评估请求，将其路由给专业智能体（检索、代码生成、摘要等），然后合成响应。网络策略在集群级别强制执行边界，确保工具访问权限由基础设施而非应用逻辑控制。
量化成本 为了将架构转化为商业案例，我开发了一个 Token 经济学框架，将基础设施成本简化为一个统一指标：每百万 Token 成本。
利用率是影响单 Token 成本的最强大杠杆。硬件和电力成本是固定的，平台在 80% 利用率下运行的单 Token 成本几乎是 40% 利用率下的一半。这就是预订系统、MIG 和时间切片的核心意义——让昂贵的 GPU 在尽可能多的可用时间内持续处理 Token。
与云服务相比，云提供商已经将利用率、冗余和开销计入了 API 定价中。对于稳定的企业级 GPU 需求（如多智能体架构产生的稳态推理流量），本地部署在成本上更具优势。但在测试、演示和 POC 阶段，云端通常更便宜。
结论
客户最常问的问题——AI 战略、用例、云与本地部署、成本、安全——最终都需要同一个答案：一个能够调度 GPU 资源、隔离租户，并为团队提供从实验到生产的自助服务路径的平台层。
本文介绍的架构基于 Kubernetes、PostgreSQL、Python 和 NVIDIA GPU Operator 构建，运行在实验室的单台 Cisco 服务器上。它切实解决了调度、多租户、成本建模以及保持 GPU 基础设施可靠性的日常运维问题。
这并不像看起来那么令人生畏。相关工具已经成熟，你可以在自己拥有完全控制权的基础设施上，使用熟悉的基础模块组装出类似云的工作流，且数据永远不会离开企业内部。当扩展到多个 AI 节点时，这里的调度平面、协调器模式和隔离模型都可以直接复用。