自服务 GPU 平台：从组件到 GPU-as-a-Service
平台的价值不在组件清单，而在用户能不能自助拿到算力：不需要懂 Kubernetes，也不需要找管理员开权限。
组合架构回答了“集群怎么治”，六种组合把共享、隔离与队列拼成了可评审的方案。但从“集群治理良好”到“用户用得起来”之间还有最后一公里：用户要的是一个入口，填个表单就能拿到 GPU 训练作业，或一个 OpenAI 兼容的模型端点。本章讲这一层的组装公式：
GPU 共享 + 模型服务 + 队列 + 自服务门户 = GPU-as-a-Service
为什么“整卡独占”养不起平台
两个叠加的经济事实：
- 重复部署。没有共享模型服务时，每个团队各自部署一套推理实例“以备不时之需”，平台上散布着大量重复的同款模型副本，每个副本都整卡独占。
- 负载形态与卡的错配。轻量模型、低批量推理的算术强度很低（见Roofline 模型），独占一张卡时物理上就有大量算力闲置，原文给出的量级是“高达 90% 的晶体管空闲”。
出于严谨，必须同时说明：“利用率低”本身不是充分的行动信号。解码型负载受带宽屋顶线约束，5% 的算力占用可能已是物理最优（见GPU 指标语义）。平台要消灭的不是“低利用率数字”，而是**“保留但空闲”（reserved but idle）**：资源被某个租户占着，却没在产出。这正是共享与队列要联手解决的问题。
四层组件：砖你已经有了
本章不重复组件内部机制（它们各自有专章），这里只确认每一层在产品中的角色：
| 层 | 组件 | 在产品中的角色 | 深入阅读 |
|---|---|---|---|
| 数据平面 | MIG / 时间片 / HAMi | 把一块卡变成多个可分配单位，消灭“整卡独占” | 数据平面 |
| 工作负载 | vLLM / KServe | 把模型变成 OpenAI 兼容端点，多租户共享一个实例 | vLLM |
| 控制面 | Kueue | 决定“谁现在拿到 GPU”：配额、准入、抢占、到期释放 | Kueue |
| 体验层 | Backstage 门户 | 让用户不写 YAML、不要集群权限就能申请算力 | 本章 |
前两层把资源的“粒度”与“形态”做对，第三层把“秩序”立起来（没有队列的共享平台会退回到“谁先抢到算谁的”，作业要么 Pending 到天荒地老，要么被 OOM 杀掉）。剩下的体验层，是本章的新内容。
自服务门户：用户不需要学 Kubernetes
门户层的选型在开源世界已有事实标准：Backstage（CNCF 项目，Red Hat Developer Hub 即其企业发行版）。关键机制是 Scaffolder 软件模板：平台团队把 Kueue Job、InferenceService 等 YAML 做成带参数的模板。用户在表单里填 GPU 数量、镜像、队列名，门户渲染出 YAML 并经 GitOps 提交到目标集群。
门户层解决的是平台的三类“软成本”：
- 权限收敛。用户不需要任何集群权限：模板由平台团队评审维护，提交走 Git 仓库，天然形成审批边界；原文实现中用户连 cluster-admin 的概念都不需要知道。
- 模板治理。最佳实践（资源请求、镜像规范、标签约定）固化在模板里，而不是指望每个用户都记得住。
- 审计与归因。每一次申请都是一次 Git 提交，谁在什么时候要了多少 GPU，都可按队列/项目出账，直接对接可观测与计量。
多集群场景（平台服务于一个集群舰队）用 hub-spoke 模式：门户在管理集群，GitOps（如 Argo CD）把渲染出的工作负载放置到合适的成员集群。
推理网关：在线负载的“队列”
Kueue 管的是离线作业（训练、批处理）的准入；在线推理的共享则需要另一个对偶机制：网关的认证与限流。
共享模型服务的价值在于合并部署：一个共享实例替代 N 个团队的重复副本，显存与算力按需复用。但共享立刻带来公平性问题：任何一个消费者都可以打满并发，把其他租户的尾延迟打爆。解法是在端点前加一层：
- 认证：每个消费方独立的凭据（原文实现中是 Red Hat Connectivity Link，上游等价物是 Istio/Envoy 网关）；
- 限流：按消费方设 RPM/并发上限，超限者排队或拒绝。这就是推理多租户的“队列”，与 Kueue 的训练队列构成一内一外的对偶。
于是完整的治理图景是：训练与批处理负载由 Kueue 准入，在线推理负载由网关限流，两者背后是同一批被共享的 GPU。两种机制任缺其一，平台都会在某一类负载上失去公平性。
验收：怎么知道“平台”成立了
沿用能力模型的语言，自服务平台对外是一个可验收的能力单元。落地后按这张清单核对：
- 用户从提交表单到作业拿到 GPU 的时间可度量、有基线（“时间到第一块 GPU”）
- 用户全程不需要 Kubernetes 权限，也没有人需要手工改 YAML
- “保留但空闲”的 GPU 占比趋零（队列到期释放 + 抢占生效）
- 训练类申请全部经过队列准入（Kueue 配额覆盖），无人能绕过
- 推理端点全部经过网关（认证 + 按消费方限流）
- 每份 GPU 消耗都能归因到队列/项目，可出账（对接可观测与计量）
- 模板变更有评审记录（Git PR），平台团队之外无人能改模板
基础设施不是终点
原文的结论值得原样保留：平台能力本身不产生 ROI，真实的工作负载才产生。推理服务、Agent、训练任务、合成数据生成，只有这些负载真实地跑在平台上，共享与队列带来的利用率提升才能兑现为业务价值。否则一个空转的平台只是把“GPU 空闲”换了个记账科目。这也是容量经济反复强调的：算力的分母永远是业务产出，不是平台本身。
总结
GPU-as-a-Service 不是新产品，而是把本书各部分已经讲透的组件按一个产品公式组装：数据平面出资源单位，推理服务出共享端点，Kueue 出秩序，门户出体验，网关限流补上在线负载的公平性。判断组装是否成功，不看组件清单，看验收清单：时间到第一块 GPU、保留但空闲归零、每一份算力可归因。下一章能力模型把这套“可交付、可验收”的思路抽象成通用的平台能力语言。
参考资料
- Alinahid, Maximise GPU utilisation and self serve GPU as a Service，本章产品化框架与 Red Hat OpenShift AI 参考实现的来源
- Backstage（含 Scaffolder 软件模板）
- KServe 文档与 OpenShift AI: Model as a Service
- Kueue 文档