模式一览
单站点托管
形态: Cyberun 在 Cyberun 的基础设施上运行控制面。客户在app.cyberun.cloud 注册。
何时选它: 评估阶段、小团队、无硬件归属或数据驻留约束、首要诉求是最小化运维负担。
取舍: 零部署成本,但任务数据与团队状态存在 Cyberun 基础设施上。不具备自托管自主权。
混合控制面 / 客户代理
形态: Cyberun 运行控制面(托管)。客户在自有 GPU 机器上运行 Cyberun 代理。任务派发至客户掌控的硬件;任务状态与产物流经 Cyberun 的存储。 何时选它: 客户拥有或租用了 GPU 容量,并希望通过 Cyberun 的控制台 / MCP 使用它,但不想自己部署控制面。工作室与实验室常采用此形态。 取舍: 客户无部署负担。代理主机由客户管理,其余由 Cyberun 管理。产物会途经 Cyberun 的对象存储再到客户的存储。主权本地部署
形态: 客户在自有环境中部署完整的 Cyberun 控制面(API 服务器、代理网关、许可证服务、OIDC 颁发者)。代理运行在客户的硬件上。Cyberun 不会接触任何生产数据。 何时选它: 数据不得离开本地、客户已经在运行 Kubernetes 级别的基础设施、硬件投入在部署生命周期内优于按用量的云成本,或合规姿态禁止托管 SaaS。 取舍: 完整的运维自主权 —— 备份、升级、身份对接、可观测性都由你掌管。公开的自助安装部署运行手册正在编写中;目前此模式由合作伙伴主导(联系)。跨云
形态: 客户将 Cyberun 部署到多个云提供商(或同一提供商的多个区域),并将其加入一张信任网络。身份、调度与存储跨越多个站点。 何时选它: 跳出单一提供商风险是业务诉求、合规分区是强制要求(数据必须留在 X 区域但计算可放任何处),或跨云冗余是 SLO 目标的一部分。 取舍: 运维复杂度最高。站点联邦机制(单个 OIDC 颁发者并复制密钥,或在信任圈中放多个不同颁发者;跨站点产物复制;DR 策略)是部署期决策。多站点联邦运行手册正在编写中,目前由合作伙伴主导。在它们之间挑选
针对每种模式的容量参考数字(核数、内存、存储、单网关预期代理数)正在作为公开部署指南的一部分编写中。在它上线之前,合作伙伴部署会与 Cyberun 协同进行手工容量评估 —— 分享你的规模目标,我们将给出当前的参考数字。