Skip to main content
A Base model is the catalog model a Training starts from. Every Training Run uses a pinned upstream snapshot, and every published Model Version records the Base model it needs.

Catalog

List the current catalog from the CLI:
Inspect one entry:
Both commands show the upstream repository and pinned revision.

Method compatibility

SFT publishes a LoRA adapter, so all four catalog entries are supported. Gisting publishes full weights. Only qwen3-4b and qwen3-8b fit within Model Version size limits. Creating a gisting Training on a larger tier is rejected with:
The eight-GPU SFT models process about eight times as many estimated tokens within the six-hour wall-time limit. For the same token count, their maximum charge is about the same as a one-GPU model except where the per-GPU minimum charge dominates.

Model sources

A new Training can start from either:
  • A catalog Base model, passed as --base-model <id>.
  • A LoRA adapter Model Version in the same project, passed as --model-version <id>.
Starting from a Model Version continues from its adapter weights. SFT continues training the adapter. Gisting merges the adapter into its Base model before learning gist tokens. A full-weight Model Version cannot be a Training source. The platform rejects it with:
After the first Training Run creates the output Model, changing the source is allowed only when the replacement has the same Base model.

Pinned revisions and lineage

Each Training Run resolves a pinned snapshot from the Base model catalog. A Model Version records its Base model ID, content kind, file manifest, and training parent. It does not persist the upstream repository or revision; the catalog carries the current values. An adapter’s adapter_config.json may omit the revision, so the file may not identify the trained snapshot. Before serving a downloaded adapter, inspect its configuration and the Base model catalog. If the adapter has no revision and the catalog may have changed since training, confirm the compatible snapshot rather than assuming the current catalog reconstructs its history. The platform does not host or serve the adapter or full model.

Output shape

An SFT Model Version contains adapter_model.safetensors, adapter_config.json, and any additional validated .json files from the run. A gisting Model Version includes config.json and either model.safetensors or a complete numbered set of model-*.safetensors weight shards. Tokenizer files, merges.txt, and chat_template.jinja are optional sidecars, not guaranteed contents. The learned prompt is represented by <|gist_…|> tokens in that full Model Version. Model Version file and download constraints are listed in Training limits.