Snowflake's Cortex Training is now in preview: a serverless service that lets you run supervised fine-tuning (SFT) and reinforcement learning (RL) on open-weight language models while Snowflake operates the GPUs. The release note is dated October 30, 2026, and the service reached wider attention on November 3. If you have wanted to post-train a Qwen-class model without renting a cluster, this is another place to do it, and it sits inside a data warehouse platform.
The short version: the product is real and documented, the pricing and model list are not in the headline pages, and one widely repeated claim (an OpenHands integration) is not in the docs we read. This post separates the three.
TL;DR: what is confirmed
| Question | Answer, with source |
|---|---|
| What is it? | A serverless service for customizing open-weight LLMs. You run the loop, Snowflake runs the GPUs (release note) |
| Which methods? | SFT and RL, LoRA or full-parameter training |
| Where does it run? | All commercial AWS regions, and it requires enablement via your account team |
| How is it billed? | AI Credits, per second, no minimum (user guide) |
| How do I call it? | The cortex_training Python namespace, a cortex-training CLI, and the CortexTrainingClient class |
| Do I need a GPU locally? | No. A laptop or CPU-only VM is enough, and you do not download weights |
| Where can the model go? | An OpenAI-compatible endpoint with streamed chat completions |
| Is the price published? | Not on the pages we read. The guide points to the Service Consumption Table |
| Is OpenHands supported? | Claimed on X, not found in the docs we read |
What Cortex Training actually is
Most fine-tuning services take a dataset and return a model. Cortex Training works at a lower level. The release note describes the GPU work as "forward and backward passes, optimizer steps, and generation", and you drive those steps from code. A job contains training sub-jobs (forward-backward and optimizer steps) and sampling sub-jobs (generation). Each job gets a Snowflake ML Experiments run, and checkpoints are saved to the experiment run's stage.
That design matters for RL. A reinforcement-learning loop alternates between sampling rollouts from the current policy, scoring them, and updating the weights. If the service only offered a "submit a dataset" button, you could not write that loop. By exposing training and sampling as separate primitives, Snowflake lets you bring your own reward function and your own rollout logic.
The user guide names the open-source frameworks that can drive the service: VeRL, SkyRL, AReal, Unsloth and Axolotl. Prime-RL is mentioned as a way to run a job, with a caveat that integration status varies and you should check with your account team. You authenticate with a Snowflake programmatic access token, and training data can come from Snowflake tables, internal stages, or S3 buckets through external stages.
The client lives in the snowflakedb/cortex-training GitHub repository, according to the guide.
A worked example from Snowflake's own tutorial
Snowflake publishes a developer guide that shows the workflow end to end. It is a vendor tutorial with a synthetic task, so read the numbers as a demonstration, not a benchmark.
- Base model: Qwen3-8B, tuned with LoRA at rank 32 on attention and MLP projections.
- Task: teach a fictional company's five-step reorder policy and house output format, without putting the policy in the prompt.
- Training: 60 optimizer steps, batch size 4, learning rate 1e-4, maximum sequence length 1,024, on 200 synthetic decisions with half of them sitting right at a threshold.
- Evaluation on 20 held-out SKUs: the base model scored 0 of 20 on correct decisions and 0 of 20 on house style. In the run shown, the tuned model scored 20 of 20 on both. In another run it got 19 of 20 on decisions, with one wrong policy code.
- Compute: about 20 to 30 minutes of GPU time, using eight H200 GPUs for training and sampling, then four GPUs for the evaluation endpoint.
- Deployment: the checkpoint is served as an OpenAI-compatible endpoint, called with the standard OpenAI Python SDK pointed at the deployment's base URL.
The code in the notebook uses primitives named forward_backward, optim_step, sync_weights, ask and release_job, plus create_model_deployment and drop_model_deployment for serving. The guide notes the deployment holds GPUs until you drop it, so the last cell is a teardown step.
Two practical points from the prerequisites. Model deployments are enabled separately from training, and without that setting deployment fails with an HTTP 403 saying deployments are not enabled. You also need an organization policy that allows role-restricted programmatic access tokens.
Training GPU cluster grid for serverless fine-tuning in Snowflake Cortex Training
Where Arctic RL fits
Snowflake AI Research published Arctic RL on June 29, 2026, an open-source RL backend that handles GPU orchestration and system optimizations so training frameworks can focus on algorithms. It integrates with VeRL and SkyRL, with PrimeRL in progress.
The headline technique is ZoRRo, short for Zero Redundancy Rollouts. It cuts repeated prompt computation using split attention for training and forest cascade attention for inference. Snowflake reports up to 6x actor-update acceleration and a 3.5x end-to-end speedup. The 3.5x figure comes from a Snowflake production run of its Arctic-Text2SQL-R2 model on four nodes (32 H200 GPUs) against an evaluated VeRL baseline, cutting training from about five days to about 36 hours. Snowflake itself says these are internal tests that may vary by model, workload and infrastructure.
The post also reports open recipes: a text-to-SQL run on Qwen3-32B that rose from 59.92 percent to 70.35 percent on BIRD dev, and a long-context multi-hop QA run that moved average accuracy from 69.6 to 72.3 percent. The article does not name a license, so check the repository before you depend on it.
A reasonable reading is that Cortex Training is the managed front door and Arctic RL is the engine research. Snowflake has not said in the pages we read that Cortex Training runs Arctic RL under the hood, so we do not claim it. A third-party write-up links the two stories, and aggregator coverage says the service was built by Snowflake's AI Research team and its Arctic RL group. Treat that as likely but unconfirmed by the docs.
The OpenHands claim: announced, not documented
Aggregated X coverage of the launch says Cortex Training integrates with the OpenHands agent harness so developers can post-train models using their existing agent tasks and configurations. The quoted source is the OpenHands account on X. We searched Snowflake's release note, user guide and developer material and found no OpenHands mention.
That does not make the claim false. A partner can announce an integration before the docs page mentions it. It does mean you should check with your Snowflake account team before planning a project around it. If it holds, it would be the interesting part for agent builders: you could turn the tasks you already run in an agent harness into RL training data without rebuilding an environment.
How it compares with other post-training services
The "bring your own loop, rent the GPUs" model is now a crowded category. This table compares only what the vendors say themselves.
| Service | You write | Vendor runs | Billing signal | Our coverage |
|---|---|---|---|---|
| Snowflake Cortex Training | SFT or RL loop in Python | GPUs, checkpoints, serving | AI Credits per second | this post |
| Together Post-Training | Full SFT or RL loop | GPUs, parallelism, rollouts | Per GPU-minute, B200 promo at $9 per GPU-hour | Together Post-Training |
| Amazon SageMaker training session APIs | Your own training loop, GRPO | Managed GPUs | See the post | SageMaker APIs |
| Open-source RL stacks | Everything | Nothing, you rent hardware | Hardware only | RL as a service stacks |
The differences that matter are about where your data lives and who you already pay. Snowflake's pitch is that training data can come straight from tables and stages in your account, so a team already on Snowflake avoids exporting data to a separate vendor. Together and SageMaker pitch breadth of models and control over the loop. If your data is not in Snowflake, the data-gravity argument disappears, and you should compare on model coverage and price instead.
For a sense of what post-training buys, look at the measured company write-ups we have covered: a fine-tuned Qwen3 model that beat Claude Opus on alarm triage, and Shopify's post-trained Nemotron model. Both are company-reported results, and both show the same pattern: a small open model, tuned on narrow data, can match a frontier model on one task at a fraction of the cost. That pattern is why these services exist. It is also the argument in our open-weight cost-savings piece.
Fine-tuning chisel shaping an open-weight model for a narrow task with serverless SFT
What the release note does not tell you
A preview release note is short, and this one leaves real gaps. Here is the list to take to your account team.
- The model list and context limits. The guide links to a Cortex Training models page for supported models and the LoRA and full-parameter context-length limits. A third-party article names Qwen and Mistral families, but we could not confirm that from Snowflake pages. The tutorial uses Qwen3-8B.
- Per-credit rates. The guide says on-demand rates live in the Service Consumption Table and that reserved capacity goes through your account team. Without a rate you cannot compare against Together's per-GPU-hour numbers.
- Quotas and concurrency. No limits are listed on the pages we read.
- Region details. The pages say all commercial AWS regions. Other clouds are not mentioned.
- Enablement lead time. The service needs enablement through the account team, and model deployments are a second switch.
- Data handling. Snowflake says training data stays in Snowflake. Read the data-use terms for your contract before you train on regulated data.
Should you try it?
Try it if your data already sits in Snowflake, you have a narrow task where a small open model could replace a frontier API call, and you can write a reward function or assemble a few hundred good examples. The 20 to 30 minute tutorial footprint is a cheap way to learn the primitives, though you should ask for the price before you run it.
Skip it for now if you need a specific model that is not on the list, if your data lives elsewhere, or if you want local training on your own machine. For the local route, see Unsloth Desktop. For RL-heavy research stacks, see how RadixArk's Miles frames frontier post-training.
A sensible first test looks like this:
- Pick one task with a clear pass or fail check, such as a classification, a SQL generation task, or a structured-output format.
- Hold out at least 20 to 50 examples and score the base model first, as Snowflake's tutorial does.
- Train with LoRA before you try full-parameter training. It is cheaper and easier to roll back.
- Deploy the checkpoint, compare it on the held-out set, and drop the deployment right away.
- Compare the cost per task against your current API bill, not against list price per token.
What this means for what you build or pay
Post-training is turning into a utility that sits next to your data, not a research project that needs its own cluster. For builders, the practical effect is price pressure and choice: when three or four vendors offer per-second or per-GPU-minute training with your own loop, the cost of testing "can a small open model do this job" drops to an afternoon. For buyers, the risk is lock-in through data gravity, so keep your training sets and reward code portable.
If you run agents in production, remember that a tuned model is a new component with its own failure modes. Evaluate it on held-out cases, keep the base model as a fallback, and watch for reward hacking when you use RL.
Frequently asked questions
Is Cortex Training generally available? No. Snowflake labels it a preview and says it requires enablement through your account team.
Can I use my own training framework? Yes, according to the guide, which names VeRL, SkyRL, AReal, Unsloth and Axolotl as supported, with Prime-RL status varying.
Does it train on my data in place? The release note says your training data stays in Snowflake. Data can come from tables, internal stages, or S3 through external stages.
Where can I read more about the Snowflake side? Start with the release note, the Cortex Training user guide and the Arctic RL post.
Related reading
- Together Post-Training: B200s at $9 an Hour
- Open-source RL as a service: the post-training stacks
- Amazon SageMaker training session APIs
- SageMaker multi-turn RL on GPT-OSS 20B
- Exowatt's fine-tuned Qwen3 vs Claude Opus
- Shopify Sidekick post-trained Nemotron
- Unsloth Desktop for local training
Details reflect Snowflake's documentation and posts as of November 4, 2026. Preview features, rates and model lists change, so confirm them with Snowflake before you commit budget.