摘要
多租户 GPU 集群让 AI 原生公司能够在团队之间共享计算能力，同时不牺牲隔离性或控制权。正确的架构在基础设施层池化 GPU，同时为每个团队提供专用节点、存储和自助调度，从而消除闲置容量浪费，避免真正共享基础设施带来的政治问题。本指南涵盖核心设计原则、常见故障模式，以及 Together AI 等平台如何在实际中实现多租户。
为什么多租户 GPU 集群设计是 AI 原生公司的核心基础设施问题
AI 原生公司的扩展速度超过了其基础设施策略的跟进能力。每个新团队都会启动新的模型实验、训练运行，并对共享计算提出需求。结果是 AI 平台工程师面临一个熟悉的情况：组织对 GPU 的需求不断增长，但 GPU 仍然稀缺且昂贵。
直觉往往是隔离，给每个团队自己的集群和资源。但这种方法在经济上不可扩展。专用集群在夜间、周末以及训练运行提前完成时处于闲置状态。你最终为无人使用的容量付费，而其他团队却在排队等待他们无法访问的资源。
更好的架构是共享，但共享的方式要让团队感觉集群像是自己的。这就是 AI 原生规模下多租户的核心设计挑战：池化经济，而非池化混乱。
什么是多租户 GPU 集群？
多租户 GPU 集群是一个共享计算环境，多个团队在同一底层硬件上运行，同时保持有意义的隔离，包括数据访问边界、凭据、存储卷和计费可见性。
与传统的共享集群不同，多租户集群具有隔离保证。在精心设计的多租户集群中，一个团队的训练作业不会影响另一个团队。硬配额、预留窗口和调度护栏防止资源过度使用成为跨团队问题——当模型、推理和研究团队都在竞争同一批 GPU 时，这一点至关重要。
多租户的核心要求是什么？
要使多租户工作，需要同时满足三个要求：
池化容量： 一个统一的 GPU 池在团队之间共享，消除闲置容量浪费。单位经济性只有在 GPU 利用率跨工作负载（训练运行、微调作业和推理）聚合时才有效，而不是每个团队隔离。租户隔离： 每个团队需要专用节点、存储、单独的凭据和直接面向租户的计费可见性。当每个租户都感觉自己在操作自己的集群，且相邻工作负载无法跨越明确边界时，共享基础设施效果最佳。自助访问： 团队需要直接预订容量，查看实时可用性，并在几分钟内（而不是几天内）启动环境。
如何构建你的基础设施层？
AI 原生基础设施最清晰的模式是两层：底层是共享基础设施，顶层是每个租户的基础设施。
在共享层，一个集中式控制平面位于高性能共享存储和通用网络架构之上，通常东西向集群内流量（对于大规模分布式训练至关重要）使用 InfiniBand，南北向流量使用以太网。GPU 和 CPU 计算节点集中管理，Together AI 的 IaaS 控制平面是该模式的典型参考实现。
在此共享基础之上，每个团队获得一个完全隔离的虚拟环境：专用 GPU 节点、专用存储 PVC，以及他们选择的编排层——Kubernetes、Slurm 或其他取决于工作负载类型的配置。运行基础模型训练、微调或推理工作负载的团队各自在自己的集群中操作，对相邻租户零可见性。
Together AI 的多租户集群是该模式的具体实现，展示了面向 AI 原生团队的裸机性能与云般灵活性相结合的实践，按实际使用量直接向每个租户计费。
如何防止一个团队消耗所有 GPU 容量？
在任何 AI 原生环境中，基于配额的分配至关重要。管理员为每个团队设置防护栏，通过 GPU 数量、总支出或预留窗口长度进行限制——在调度器级别强制执行，而不仅仅是软策略。
调度器还应处理提前预订并内置冲突预防。团队为特定窗口预留集群（例如，一个月的预训练运行或两周的微调冲刺），系统防止重复预订。实时容量可用性显示在 UI 中，以便团队在承诺前确切了解可用资源。容量感知调度意味着可预测的计划：运行过程中无意外或跨团队干扰。
对于需要超出配额的突发需求的团队，正确的设计支持自动溢出到按需公共费率。Together AI 无需管理员批准即可处理此问题，因此生产速度不会因基础设施官僚作风而受阻。
多租户平台应为 AI 团队提供哪些配置灵活性？
共享基础设施中的一个常见失败模式是固执己见的默认设置。强制特定编排层、驱动版本或存储配置的平台会带来隐藏的权衡——AI 原生团队最终会调整其工作流以适应平台，而不是相反，这完全本末倒置。
正确的模式是在预订时提供点菜式配置：编排层、CUDA 驱动版本、共享内存大小和存储卷，全部由团队根据其工作负载需求指定。没有默认设置或强制权衡。在 Slurm 上运行 Llama 微调的团队不应被迫与在 Kubernetes 上提供推理端点的团队使用相同的配置。
一旦配置完成，集群应具备自动创建和拆除功能，开箱即用的 Grafana 可观测性，以及即时 SSH 访问。
在多租户环境中，GPU 健康和节点修复应如何工作？
共享集群中的硬件故障可能产生连锁反应。它们不仅影响一个训练任务，还可能级联影响共享同一物理层的多个团队。健全的健康检查和修复生命周期是必需的。
最佳实践是在每个节点移交给租户集群之前，对其进行自动验收测试。测试应包括 DCGM 诊断、GPU 压力测试、单节点和多节点 NCCL 测试，以及跨 CPU-GPU 延迟和带宽维度的 NVBandwidth 测量。
团队还应能够在集群生命周期的任何时刻（而不仅仅是配置时）直接从 UI 触发按需健康检查。当检测到问题时，响应应分层：软件问题触发快速重新配置，硬件故障导致集群迁移。在整个修复生命周期中，租户应具有完全的可见性——无需猜测训练运行缓慢是模型问题还是节点问题。
多租户 GPU 基础设施适合您的团队吗？
当您有多个 AI 团队运行异构工作负载（基础模型训练、微调、推理和研究）且同时进行时，多租户集群能带来最大价值。对于 AI 原生组织，数学计算强烈支持资源池化。
关键问题不在于是否共享基础设施，而在于您的 AI 平台如何有效地实施隔离。当流程无缝运行时，您将获得数据中心的单位经济效益，而无需承受公共云的性能妥协，以及 AI 原生团队所期望的自助服务速度。
立即开始构建多租户 GPU 基础设施
Together 的多租户集群专为需要共享 GPU 基础设施而无需共享麻烦的 AI 原生组织而构建。池化您的容量，隔离您的团队，并以您的模型所需的速度前进。
常见问题解答
多租户集群中的团队能否看到彼此的模型、数据或训练运行？
不能，在正确架构的环境中不会。每个租户使用专用的 GPU 节点、专用的存储卷和独立的凭据。
当团队需要的容量超过其配额时会发生什么？
设计良好的平台支持在团队超出其池分配时自动突发到按需费率，无需手动管理员批准。AI 原生的速度不应因计划容量边缘的基础设施官僚主义而受限。
多租户平台应支持哪些编排框架来处理 AI 工作负载？
至少：用于推理和服务的 Kubernetes，以及用于分布式训练的 Slurm on Kubernetes。AI 原生团队通常需要同时运行两者，因此平台需要支持混合配置。