Together AIAnnouncement
Introducing preemptible compute: the same compute, half the price
Summary
Together GPU Clusters is introducing preemptible compute in public preview for Kubernetes clusters in all regions, offering interruptible GPU capacity at a flat 50% of the on-demand rate. Preemptible nodes use the same NVIDIA accelerated compute, can be reclaimed when unused capacity is needed, and receive a maximum five-minute drain window for checkpointing and graceful exit. Clusters retain the requested preemptible target and automatically refill as capacity returns, while usage is metered every one to two minutes and billed sub-hourly. The feature suits resumable, retryable, or requeueable work such as experiments, batch inference, and temporary bursts, but critical services, uncheckpointed multi-day runs, and strict-SLO serving should remain on standard nodes; users must schedule eligible pods with the together.ai/compute-class=preemptible label.
Context
Preemptible compute is in public preview on Together GPU Clusters’ Kubernetes clusters in all regions. It is an additional compute type within an existing cluster, not a separate cluster type, and clusters still require at least one standard node.
Approach / What changed
The implementation draws preemptible nodes from unused capacity at a fixed 50% of the on-demand rate. When capacity is reclaimed, Kubernetes nodes are cordoned, pods receive SIGTERM and a TogetherPreempted event, workloads get up to five minutes to checkpoint and exit, and the cluster automatically refills toward its configured preemptible target when capacity becomes available.
Takeaways
Preemptible capacity is billed at a fixed 50% of the on-demand rate, with usage metered every one to two minutes and charged sub-hourly.
A reclaimed node has a maximum five-minute drain window; checkpointing can be triggered by SIGTERM, while Kubernetes events and API lifecycle events expose the preemption notice.
Preemptible nodes are intended for resumable, retryable, or requeueable workloads. Coordinators, login pods, serving replicas, and other critical components should stay on standard nodes.
FAQ
What happens when a preemptible node is reclaimed?
The node is cordoned, pods receive SIGTERM, and a TogetherPreempted Kubernetes event is emitted. Workloads have up to five minutes to checkpoint and exit before the node is removed, after which the cluster refills toward its target when capacity returns.
How should workloads select preemptible nodes?
Eligible pods should target the label together.ai/compute-class=preemptible. Critical components should remain on standard nodes, and terminationGracePeriodSeconds can be set to as much as 300 seconds to use the drain window.
Which workloads are a poor fit for preemptible compute?
Multi-day runs without checkpointing and strict-SLO serving with no fallback are not suitable. The feature is intended for work that can resume, retry, or requeue after a worker disappears.
Source and freshness
- Source
- together.ai
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.