MiniMax M3.1 Flash Post-Training on Together: Limits and GPU Pricing

Together AI announced MiniMax M3.1 Flash support for its Post-Training service on October 26. Developers can adapt the model through supervised fine-tuning or reinforcement learning using their own data and training logic. The useful change is control over model behaviour, rather than another endpoint for the unchanged model.

The announcement extends an existing service. Together introduced Post-Training on October 19, and MiniMax's earlier API and open-weight releases are separate events. This addition gives teams a managed route for experimenting with a customised MiniMax checkpoint.

MiniMax M3.1 Flash training limits

Together's supported-model catalog lists MiniMax M3.1 Flash with the following configuration. These are training-service limits, not the model's general inference specifications.

Setting	Published configuration
Model ID	MiniMaxAI/MiniMax-M3.1-Flash
GPU type	B200-SXM
Training mode	LoRA
Maximum training sequence	262,144 tokens
Generator context	262,144 tokens
Maximum LoRA rank	32
Adapter sessions per resource	3
Full-weight training	Not supported

LoRA trains smaller adapter parameters while leaving the base model frozen. A larger collection of downloadable weights therefore does not imply that every parameter can be updated through this service. The catalog also says Post-Training currently supports text models; image fine-tuning uses a different offering.

Do not copy the inference context window into a training plan. The training limit applies to a complete sample, including its prompt and response. Long agent trajectories need to fit that budget, even when the application normally calls a model with a larger context window.

What the developer controls

In Together's session-based workflow, the developer's Python code runs the loop and remote GPUs do the expensive computation. The loop chooses batches, computes or supplies the training objective, requests gradient calculations and applies optimiser steps.

For reinforcement learning, the service also generates candidate responses. The application scores those responses, trains on the results and synchronises updated weights to the generators before subsequent sampling. Supervised fine-tuning can run without generators because it learns from prepared examples instead.

Consider an agent that must modify a repository and pass its tests. A supervised dataset can show successful changes, while a reinforcement-learning environment can score new attempts against the tests. Neither approach makes a test suite complete: a model can improve its measured reward while still producing undesirable changes that the tests do not catch.

This is why control over the loop matters. A team can inspect intermediate results, change its curriculum or stop an unhelpful experiment rather than submitting a fixed job and waiting for the final checkpoint. That flexibility also creates more application-side work than a standard upload-and-train service.

GPU pricing is different from API pricing

Together's current pricing page lists Post-Training B200 usage at a promotional $9 per GPU-hour, against an $11 rate, with the promotion marked valid until December 14, 2026. That is a per-GPU rate, not the price of a complete MiniMax training resource or experiment.

The billing documentation says resources accrue charges by the minute while ready. The number of GPUs depends on the model, training configuration and generator replicas. Its cost-estimation API returns a configuration's hourly total without provisioning it, which is more useful for budgeting than multiplying the headline rate by a guessed GPU count.

Resources can keep billing after a script exits unless they are stopped. Cookbook recipes handle their created resources' cleanup, while custom code needs an explicit lifecycle. The documentation also requires at least $100 in project credit or credit limit before creating a resource. That balance requirement is not a flat training fee.

The comparison worth running

A team evaluating this release should compare the adapted model with the existing MiniMax API workflow on held-out tasks. Keep tool access and acceptance checks consistent, then measure complete successful jobs, retries and inference time. Training loss alone cannot establish that the production agent improved.

The second comparison is economic. Include data preparation, scoring, training experiments and the eventual serving deployment, rather than only the cost of one successful run. A cheaper model call can still be a more expensive product feature if the adaptation needs constant maintenance.

Managed post-training makes that experiment easier to organise. The important result would be evidence that a small, repeatable adaptation improves a real workflow enough to justify operating a custom model. The release supplies infrastructure for finding that answer, not the answer itself.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain model launches and infrastructure tradeoffs in writing that developers and founders can use.

Book a 30-minute call.