Together AI B200 Training Price Cut: $9/GPU-Hour for the First Eight Weeks

Together AI recently announced on social media that its post-training service based on NVIDIA B200 GPUs is now priced at $9 per GPU-hour for the first eight weeks after activation, down from the original $11. The price cut directly targets teams that need to run frequent SFT (supervised fine-tuning) and RL (reinforcement learning) experiments—especially developers who want to keep the training loop in their own code.

What the Price Adjustment Includes

According to the official tweet, the offer has three key points: the price drops from $11/GPU-hour to $9/GPU-hour; the discount applies for the first eight weeks; and it covers post-training, including both SFT and RL workloads.

In the post-training stage, experiment iteration tends to be more frequent than in pre-training—individual runs are relatively short but numerous—so the per-hour cost has a very direct impact on total spend. Over an eight-week window, if a team occupies one B200 for 10 hours a day, the original price works out to about $6,160, versus about $5,040 at the new price—a saving of more than $1,100. For teams using multiple GPUs in parallel, the savings scale proportionally.

Why Post-Training Costs Matter

In the process of deploying large models, post-training has become a key step that determines actual model performance. SFT aligns the base model with the format of a specific task, while RL (including RLHF, DPO, GRPO and other variants) further optimizes the model's behavior under a target reward. Both share a common trait: they require repeated trial and error. Any adjustment to hyperparameters such as learning rate, data mix, reward function design, or KL coefficient means another round of training.

Lower costs aren't just about saving money. When the marginal cost of a single experiment drops, teams are more willing to run multiple configurations in parallel or shrink the scale of individual experiments to quickly validate hypotheses. In engineering practice, this ability to "try a few more times" often drives progress more than a single large-scale training run.

SFT (Supervised Fine-Tuning): Building on a pre-trained base model, continue gradient updates using labeled (input, output) pairs so the model learns to respond in the format and style required by the task. It is usually much cheaper than pre-training, but extremely sensitive to data quality—data mix, number of epochs, and learning rate all significantly affect results.

RLHF (Reinforcement Learning from Human Feedback): First train a reward model, then optimize the policy model using algorithms such as PPO so that outputs better match human preferences. The pipeline is complex and memory-intensive, typically requiring the policy model, reference model, reward model, and value function model to all be resident at once, so GPU requirements are far higher than for SFT.

DPO (Direct Preference Optimization): Skips the explicit reward model and constructs the loss function directly from preference pairs. It is simpler to implement and more stable to train, making it a lightweight alternative to RLHF.

GRPO (Group Relative Policy Optimization): Samples multiple outputs for the same prompt and uses relative scores within the group as advantage estimates, eliminating the value network. It performs notably well on reasoning tasks such as math and code.

Keeping the Training Loop in Your Own Code

The official tweet specifically emphasizes "keep the training loop in your own code." For developers familiar with post-training workflows, this points clearly to one thing: the platform provides GPU compute and scheduling, not a closed black-box training service. Teams can continue using their familiar frameworks and code structures, keeping training logic, data pipelines, and evaluation scripts in their own hands while handing only the compute load to the remote cluster.

The advantage of this model is portability. Training code isn't locked to the platform, so migration costs are lower when switching to another compute provider; when debugging and reproducing experiments, developers work with code they wrote themselves rather than platform-wrapped interfaces. For teams that need to maintain training pipelines long-term, this is a practical consideration.

A "training loop" refers to the complete control flow from data loading, forward computation, loss computation, and backpropagation to optimizer updates. Keeping it in your own code means the platform provides only bare compute (similar to spinning up a remote GPU machine) and does not take over training orchestration. In contrast, managed fine-tuning services typically wrap training scripts and hyperparameter interfaces, which are quick to get started with but offer limited customization and make it hard to reproduce internal details. For teams with an established training framework (such as PyTorch + FSDP/DeepSpeed), the former is better for debugging and migration.

Where B200 Fits in These Workloads

The B200 is NVIDIA's GPU product for large-scale AI workloads, with high memory bandwidth and compute throughput. In post-training scenarios, its value shows up mainly in two ways: first, it supports fine-tuning models with larger parameter counts; second, it shortens per-iteration time in tasks like RL that require frequent forward and backward computation.

It's worth noting that this announcement covers pricing only and does not disclose details such as specific memory configurations, interconnect bandwidth, or available cluster size. Actual experience will be affected by factors such as cluster scheduling and queueing, so teams should run small-scale tests based on their own workload size when evaluating.

The B200 is a data center GPU in NVIDIA's Blackwell architecture, using a dual-die package and equipped with high-bandwidth HBM3e memory; its per-card memory capacity and bandwidth are significantly improved over the previous-generation H100. In fine-tuning and RL scenarios, large memory means longer contexts or larger batches can fit, reducing the overhead of gradient accumulation and offloading; higher compute throughput directly shortens per-step iteration time. Note that actual post-training throughput also depends on inter-GPU interconnect (such as NVLink) and cluster networking—per-card specs alone don't fully represent end-to-end performance.

How to Tell If It Fits Your Team

From a cost-structure perspective, this offer is best suited to the following situations: intensive post-training experiments, a need for concentrated short-term compute, and a team that already has mature training code. If the workload is very small and can be handled by a single GPU, the absolute savings from the price cut will be limited; if the workload requires an ultra-large-scale cluster, you'll still need to confirm the platform's actual supply capacity.

The eight-week window is also worth factoring into planning. Teams can use these eight weeks to run a concentrated matrix of experiments, validate key hypotheses about data mix or reward functions, and then decide how to invest in compute going forward based on the results.

Summary

Together AI's cut of B200 post-training pricing to $9/GPU-hour with an eight-week promotional window sends a clear signal: post-training compute is becoming a segment that cloud vendors are competing for. For developers, the key isn't chasing the lowest unit price but turning lower marginal costs into more effective experiments. Price is the entry point; experimental efficiency and code autonomy are where the long-term value lies.

One-line Summary

Together AI cuts B200 post-training pricing to $9/GPU-hour for the first eight weeks.

Paragraph Summary

Together AI announced that its post-training service based on NVIDIA B200 GPUs is priced at $9/GPU-hour for the first eight weeks after activation, down from $11, covering both SFT and RL workloads. The article notes that post-training experiments iterate frequently—individual runs are short but numerous—so lower unit costs directly expand a team's experiment budget and make it more feasible to run multiple configurations in parallel or quickly validate hypotheses. The company emphasizes "keeping the training loop in your own code": the platform provides only compute and scheduling, while training logic, data pipelines, and evaluation scripts remain under the team's control, reducing platform lock-in and migration costs. The article also notes that the announcement doesn't disclose memory configuration, interconnect bandwidth, or cluster size, so actual experience requires small-scale testing that accounts for scheduling and queueing; the eight-week window is well suited to running a concentrated matrix of experiments.