In-depth analysis · About 5 min read
Together Post-Training separates the training loop you control from the GPUs it operates
The October 19 service supports custom SFT and RL workflows, with dedicated resources and a time-limited B200 usage price rather than a flat subscription.
- Source published
- Published here
- Source checked
Together AI introduced Post-Training on October 19 as a service for customizing open-weight models through supervised learning and reinforcement learning. Developers define the loop while Together operates the training and rollout infrastructure. The announcement describes more control than a fixed fine-tuning job, but it does not remove the need for data, evaluation or a compute budget.
Listen to the news
Read this article aloud or keep listening to the news.
Preparing the reader…
Device voice
Speech is handled by your browser or device. AISubHub does not send the text to an audio API. Voice availability and playback with a locked screen vary by device.
Resuming may repeat a short phrase.
At a glance
- LoRA experiments can share a Model Resource; full-weight experiments are available for select models. Trainer and Generator components let developers decide when policy weights are synchronized.
- Model Resources are billed per GPU-minute. The announced reduced B200 rate is $9 per GPU-hour for the first eight weeks, not a complete job price or monthly subscription.
- The source lists Muse Spark Open, GLM 5.3, Kimi K3 and Qwen 3.8-27B at launch. That is service support, not a new release of every listed model.
Control over experiments is the product boundary
The service supports SFT from supervision data and RL from environment rewards. Unlike Together's separate fine-tuning service, the entire training loop is developer-defined, including custom data, environments, agent harnesses, logging and external evaluation steps. Standard losses are offered, while developers may compute a custom objective locally and send its gradients for updates. That is useful flexibility, but the correctness of a reward or evaluation remains a project responsibility. Together also offers forward-deployed engineering assistance; its involvement is described as collaboration, not proof that every customer can skip experiment design. Our reading is to treat the service as managed infrastructure with a programmable interface, not an automatically successful customization recipe.
Dedicated resources contain distinct training sessions
A Model Resource is a GPU allocation not competing with other customers' requests, and can contain several Training Sessions using the same base model. Each session has a Trainer for forward/backward computation and weight updates, and Generators for policy rollouts. SFT can use zero generators to avoid unnecessary generation expense. Developers control synchronization, and asynchronous RL is supported for long rollouts. Several LoRA adapters may share capacity; full-weight training is limited to select models. The release lists Muse Spark Open, GLM 5.3, Kimi K3 and Qwen 3.8-27B, with future expansion planned. Sharing adapters does not mean that every model or experiment needs the same amount of hardware.
Numerical alignment is a quality claim to test
Together emphasizes differences between training and inference engines that can cause policy drift even with the same weights. It describes routing replay, caching, parallelism and sequence packing as ways to improve quality and throughput. After training, Dedicated Model Inference can serve multiple LoRA adapters in one deployment; the company also claims quality preservation when merging for FP4 serving. We have not reproduced those claims. Customer statements about concurrent experiments or matching a closed model are testimonials and offline evaluations, not general benchmarks for a visitor's workload. A useful pilot would compare the actual served checkpoint, its task acceptance criteria and rollout behavior, rather than assume that efficient training alone establishes reliable production output.
Usage pricing and promotional terms are not a monthly plan
Each Model Resource is billed per GPU-minute. The article offers a reduced B200 rate of $9 per GPU-hour for the first eight weeks, without establishing the total cost of a multi-GPU experiment or a permanent price. The number of generators, resource size, experiment duration and serving setup can change spending. Together argues that its optimized stacks can beat token-based pricing as experiments scale; that is an attributed economic claim, not a universal saving verified here. It provides SDK, cookbook and Tinker-migration links, but we did not run them. Model weights, licenses, application data rights and deployment conditions still require checking for a particular project; the blog is not itself a blanket commercial permission.
Why it matters
The practical opportunity is to keep research control while delegating complex GPU operations. Teams can examine whether shared LoRA resources and separately sized rollout capacity fit their experiments. The useful success measure is an accepted task result from the deployed model at a measured total cost, not the number of training runs completed. The announcement offers a service path, not guaranteed parity with frontier systems.
Limits and availability
We read the complete official launch account and its launch pricing, but did not inspect linked SDKs, cookbooks or migration documentation. We did not train, serve or purchase a model. Introductory pricing, model support and vendor quality claims have limited scope; none grants free compute, a consumer subscription or identical rights across different base-model licenses.
Sources and evidence
Source published: Oct 19, 2026 · Source checked: Oct 20, 2026
AI-assisted editorial articles checked against linked primary sources. Vendor claims are attributed; inclusion is not endorsement.