Together AI 推出可抢占 GPU 计算：同样算力，半价

这是什么：一句话说清身份

2026年9月10日，Together AI 发布了 Together GPU Clusters 的可抢占计算公开预览。它是该平台在 Kubernetes 集群上新增的一种 GPU 算力类型，按需费率的固定五折计费，节点可能被随时回收，但会给你最长五分钟的排水时间。官方未说明具体 GPU 型号清单和正式版时间。

打个比方：这就像学校食堂的“剩菜盲盒”——同样的饭菜只要一半价钱，但食堂随时可能把没卖完的菜收走，你得在五分钟内吃完或打包带走，而且食堂还会自动帮你再留一份，等有剩菜时补上。

为什么会有这种便宜算力

GPU 集群里总有一些算力暂时没人用，就像食堂非高峰时段有空座位。Together AI 把这些空闲容量拿出来，以固定五折的价格卖给能接受“随时被请走”的任务。价格不随市场波动，始终是按需费率的一半。

标准节点是同步交付、永不被抢占的；可抢占节点使用同样的 NVIDIA 加速计算，但来自未使用容量，当这些容量被别处需要时就会被收回。集群会保留你的可抢占目标，等容量空出来时自动补上，你不需要手动申请替换。

被回收时会发生什么：五分钟排水

当节点被回收，集群会执行最长五分钟的排水流程。T+0 时节点被隔离，触发 TogetherPreempted Kubernetes 事件，你的 Pod 收到 SIGTERM 信号。从 T+0 到 T+5:00，你的工作负载最多有五分钟（由 terminationGracePeriodSeconds 控制）来保存检查点并退出。T+5:00 时节点被移除。

这五分钟就是你的“打包时间”。如果任务能定期保存进度，就能在被打断后从最近一次检查点继续，不会白跑。如果任务不能保存进度，比如连续跑好几天且没有检查点，那就不适合用这种便宜算力。

适合谁用：能断点续跑的任务

短实验很适合，比如消融实验、配置扫描、快速微调、评估、蒸馏和批量推理。这些任务通常可以从中断处恢复或重试。像 Ray Train 和 PyTorch Lightning 这类框架能从最新检查点自动恢复，不需要人工干预。

临时突发也适合。当批量或内部推理需求突然变大，可以加一些便宜的可抢占节点来吸收突发和非关键负载，而不是为了峰值一直保留标准容量。被中断的请求会重新排队，面向用户的副本仍然留在标准节点上。

不适合谁用：不能中断的任务

没有检查点的多日连续运行不适合，因为节点随时可能消失，你没法从中间接着跑。有严格服务等级协议且没有备用方案的在线服务也不适合，因为用户请求不能等。

关键组件应该留在标准节点上，比如协调器、登录 Pod 和面向用户的副本。你可以用 compute-class 标签来强制区分，让可抢占节点只跑能中断的工作。集群至少需要一个标准节点，而且节点不能原地转换计算类型。

怎么用：设置目标和调度

准备工作负载后，设置分两步：设定可抢占目标，然后把合适的工作调度到带标签的节点上。你可以在创建集群时设定目标，也可以在已有集群上调整，用 Together Cloud 控制台、CLI 或 API 都行。API 会报告请求的目标 desired_preemptible_gpus 和当前实际分配 allocated_preemptible_gpus。

因为可抢占节点来自未使用容量，当容量紧张时，实际分配可能低于你设定的目标。调度时用 nodeSelector 指定 together.ai/compute-class: preemptible。抢占通知会以 SIGTERM、Kubernetes 事件、控制台事件时间线和 API 的 node_lifecycle_events 等方式送达。

计费与限制：按分钟算，随时可能没

计费是亚小时的，每 1 到 2 分钟计量一次。一个跑了 12 分钟的节点大约按 12 分钟收费。价格固定为按需费率的 50%，不随市场浮动。公开预览期间没有最短节点存活时间保证，所以你要频繁保存检查点，并做好容量随时消失的准备。

官方未说明可抢占节点的具体 GPU 型号清单、各区域可用性差异、公开预览结束时间、正式版发布时间、Slurm 支持的具体时间表、是否支持按秒计费、是否提供价格保护或容量保证，以及非 Kubernetes 集群的可用性。Slurm 支持、更多区域和原地转换计算类型是官方计划下一步做的。

怎么核验：自己动手确认

你可以登录 Together Cloud 控制台，查看集群的 compute-class 标签和节点命名（可抢占节点以 gpu-preemptible-xxx 命名）。用 CLI 创建或更新集群时，观察 –num-preemptible-gpus 参数的效果，并通过 API 对比 desired_preemptible_gpus 和 allocated_preemptible_gpus 是否一致。

你还可以在控制台的 Event Timeline 里查看 TogetherPreempted 事件，确认排水流程是否按五分钟执行。如果实际分配长期低于目标，说明当前容量紧张，这不是故障，而是可抢占算力的正常特性。官方文档里有处理抢占的推荐模式，可以照着做。