今天我们宣布 Together GPU Clusters 的抢占式计算公开预览版，已在所有区域的 Kubernetes 集群上可用。抢占式节点为团队提供了一种更低成本的方式来运行可容忍中断的工作负载——短实验、推理突发、批处理作业——在它们已经使用的同一 GPU 基础设施上，按不足一小时计费，统一为按需费率的 50%。从今天起，你可以向新集群或现有集群添加抢占式容量。
抢占式计算如何工作
抢占式计算为 Together GPU Clusters 增加了第二种计算类型。标准节点同步完成配置，且从不会被抢占。抢占式节点使用相同的 NVIDIA 加速计算，从未使用的容量中获取资源，并且当该容量在其他地方需要时可以被回收。
抢占式节点按按需费率的统一 50% 计费。该费率保持固定，而不是随现货市场波动。
当节点被回收时，集群遵循五分钟排空（最多 5 分钟）序列：
T+0——节点被封锁，一个 TogetherPreempted
Kubernetes 事件触发，你的 Pod 收到 SIGTERM。T+0 到 T+5:00——你的工作负载最多有五分钟（terminationGracePeriodSeconds
）来执行检查点并退出。T+5:00——节点被移除。
节点被移除后，集群会保留其抢占式目标，并在容量可用时自动向该目标补充。你不需要请求替换容量。
计费按不足一小时进行，使用量每一到两分钟计量一次。运行 12 分钟的节点大约按 12 分钟计费。
抢占式节点不是单独的集群类型。它们加入你现有的集群，标签为 together.ai/compute-class=preemptible
，因此可中断的工作进程在折扣容量上运行，而协调器、登录 Pod 和服务副本保留在标准节点上。
抢占式计算适用于哪里
五分钟回收序列使恢复行为成为决定性因素。可以恢复、重试或重新排队的工作可以使用抢占式容量，而关键组件应保留在标准节点上。
短实验。 消融、配置扫描、快速微调、评估、蒸馏和批量推理是很好的候选，只要工作可以从检查点恢复或在工作进程消失后重试。Ray Train 和 PyTorch Lightning 等框架可以从最新检查点恢复而无需干预。作为参考，GLM5.3 Flash 321B 参数模型的完整权重模型检查点大约为 3.5TB，即使性能下降，写入并行文件系统也需要 22 秒到 4 分钟。在五分钟排空窗口内留有余量。
临时突发。 当批处理或内部推理需求激增时，添加更便宜的抢占式节点来吸收突发和非关键工作负载，而不是持有按峰值规模配置的标准容量，或冒着突发标准计算可用性的风险。被中断的请求会重新排队；面向用户的副本保留在标准节点上。
The common thread: work that is chunked, checkpointed, or retryable. Multi-day runs without checkpointing and strict-SLO serving with no fallback are not a fit.
Together 拥有浓厚的自用文化，Together 内部的若干研究、开发/测试和非关键生产工作负载基于我们的抢占式计算 GPU 集群，使我们能够跨产品团队利用我们的闲置容量。
在启用之前
将可抢占节点视为临时节点。预览期间没有最短节点生命周期，因此要频繁设置检查点，并做好容量随时消失的准备。将关键组件放在标准节点上。协调器、登录 Pod 和面向用户的副本属于保障容量——使用 compute-class
标签来强制执行。利用排空窗口。将 terminationGracePeriodSeconds
设置为最多 300 秒，在 Pod 收到 SIGTERM 时设置检查点，并在节点被移除前退出。集群至少需要一个标准节点，且节点无法就地转换计算类型。
如何使用
在工作负载做好抢占准备后，设置分为两部分：设置可抢占目标，并将符合条件的工作调度到已标记的节点上。
你可以在创建集群时设置目标，也可以在已运行的集群上设置，使用 Together Cloud 控制台、CLI 或 API。API 会同时报告请求的目标 desired_preemptible_gpus
和当前实际运行的容量 allocated_preemptible_gpus
。由于可抢占节点从闲置容量中获取资源，当容量紧张时，已分配容量可能低于期望目标。
在新集群上
选择你的标准节点数量，然后在此基础上添加可抢占目标。
在现有集群上
当你需要额外的工作节点容量时，调高可抢占目标，工作完成后再调低。集群在整个过程中保持运行。
在可抢占节点上调度工作
显式指定可抢占节点：
抢占通知会以 SIGTERM 形式发送到 Pod，作为 Kubernetes 事件（reason=TogetherPreempted
），显示在控制台的事件时间线中，并通过 Together API 的 node_lifecycle_events
传递——处理模式已在文档中介绍。
可抢占计算现已在 Kubernetes 集群上公开预览。Slurm 支持、更多区域以及计算类型之间的就地转换将在后续推出。