v1.0.2

See the cwtrain release notes.

v1.0.1

See the cwtrain release notes.

v1.0.0

See the cwtrain release notes.

Initial release

The first release of the CoreWeave Inference Cookbook and of cwtrain, its Python library and CLI.

Use them to train with reinforcement learning against a live
CoreWeave Dedicated Inference deployment.
After each training step, the trainer publishes its new weights by checkpoint hot-load
(RL Rollouts). Every replica swaps them
in place, and the next rollouts come from the deployment's OpenAI-compatible endpoint. The trainer
runs no inference engines of its own.

Install

pip install cwtrain
pip install "cwtrain[nemo-rl]"   # adds torch and safetensors for the NeMo-RL integration

cwtrain needs Python 3.12 or newer and is tested on 3.12, 3.13 and 3.14.

cwtrain

Deployments. The cwtrain deployment commands (create, get, delete, parameters) and
cwtrain.infra handle the deployment that a run samples from:

• create it from a CreateDeploymentRequest body;
• wait until it is READY and get its rollout_base_url;
• delete it at the end.

Every create sends an ID chosen by the client, so a retry never creates a second resource. A
request file that still has a <placeholder> is refused.

Checkpoint hot-load. The cwtrain hotload commands (publish, trigger, wait, status,
list, inspect, check) and HotLoader publish the trainer's weights and wait until every
replica serves them.

• Snapshot formats. A snapshot is either a full HuggingFace safetensors checkpoint or a delta.
  A delta holds only the changed tensors, as a zstd-compressed XOR with an Adler-32 checksum per
  tensor. The engine checks the checksums before it serves the weights.
• Immutable identities. Uploads record the SHA-256 of every object. Retrying an interrupted
  upload is safe. Different bytes under an existing identity are refused with
  SnapshotConflictError.
• Safe retries. Only one hot-load runs per deployment at a time. A retried create request
  returns the hot-load that already exists.
• Rollback. HotLoader.rollback(identity) hot-loads an earlier completed snapshot again.
• Permission check. Before training, cwtrain hotload check and
  python -m cwtrain.integrations.preflight check that the trainer can list, read and write the
  snapshot prefix. They leave nothing behind.

Framework integrations.

• miles and slime: the post-write hook cwtrain.integrations.slime.hook publishes every weight
  version. In delta mode it keeps a local weight mirror and publishes a full snapshot every 20
  versions (CWTRAIN_HOTLOAD_FULL_EVERY).
• NeMo-RL: the coreweave generation backend, HotLoadWeightSynchronizer and
  CoreWeaveDTensorPolicyWorker.
• Rollout sampler (cwtrain.integrations.rollout), which every recipe uses:
  • it sends one /v1/completions request per GRPO group and retries failed requests;
  • where the endpoint supports them, it uses token-ID prompts and exact response token IDs;
  • it is configured with the CWTRAIN_ROLLOUT_* variables.

Recipes

Recipe	Framework	What it runs	Tested with
miles	miles	GRPO on Qwen3-4B, synchronous or one step ahead	radixark/miles:v0.1.1
slime	slime	GRPO on Qwen3-4B	slime 8ee9c1e
NeMo-RL	NeMo-RL	GRPO on Nemotron 3.5 Lightning BF16, optional NeMo Gym rollouts	NeMo-RL v0.7.0
NeMo Gym	NeMo Gym	Scored evaluation against a temporary deployment	NeMo Gym v0.6.0

The training recipes run on Kubernetes and train on DAPO-Math-17k. Each one ships:

• Kubernetes manifests;
• an example deployment request;
• an example bucket policy;
• an example organization access policy for the trainer.

The trainer runs as a Kubernetes service account of its own, through Workload Identity Federation.
It can write only under the hot-load prefix, and it has no rights to delete objects or to change
the policy. Every training recipe writes snapshots under the same prefix, hotload. The slime and NeMo-RL
launchers apply small patches to their framework; miles needs no changes.

Requirements

• RL Rollouts enabled for your organization. RL Rollouts is in preview; CoreWeave support turns
  it on. Until then, creating a deployment with a hotLoad section fails with
  hot-load is not enabled for this organization.
• A hot-load deployment. It must use engine dynamo-vllm and have a hotLoad section, and all
  its gateways must be in one zone. You can enable hot-load only when you create a deployment.
• An API token with the Inference Admin role.
• An AI Object Storage bucket whose policy lets the Dedicated Inference service account read
  it. The storage region has no default: set AWS_REGION to the bucket's Availability Zone.

Known limitations

• cwtrain is alpha, so its API may change before 1.0.
• A replica that starts with no peer to copy from replays the chain from object storage, and it
  handles at most 63 deltas. Publish a full snapshot at least every 64 versions. The integrations
  publish one every 20 versions by default.
• The API has no rollback. rollback needs the earlier snapshot's objects to still be in the
  bucket.
• On large models, a hot-load takes minutes. By default, the integrations pause training until it
  completes.
• The integrations keep one or two extra copies of the checkpoint on the trainer's local disk.

Documentation

• Repository README
• cwtrain README:
  CLI, API layers, snapshot layout and configuration
• RL Rollouts product documentation
• Report security issues as described in
  SECURITY.md, not in a
  public issue.

Licensed under Apache-2.0.