Base models

Hosted training accepts a specific set of Tinker base models as the --model / base_model field on dn train sft and dn train rl. The platform validates the value at job creation so typos fail fast instead of wasting compute inside a sandbox minutes later.

Discover supported models

From the CLI:

dn train catalog
dn train catalog --family llama --min-size-b 7
dn train catalog --algorithm ppo --json

From the SDK:

from dreadnode.training import TINKER_MODELS, get_training_model, suggest_training_models

model = get_training_model("meta-llama/Llama-3.1-8B-Instruct")
assert model is not None
print(model.family, model.type, model.size_b, model.context_length)

# Typo hints — used by the API to build "did you mean…?" error messages.
for m in suggest_training_models("llama3", limit=3):
    print(m.tinker_id)

From the API: GET /training/catalog returns a paginated TrainingCatalogResponse. Filters match the CLI: query, family, algorithm, min_size_b, max_size_b, limit.

What’s in an entry

Each catalog entry describes one base model the platform is willing to hand to Tinker.

Field	Meaning
tinker_id	Exact string to pass as --model / base_model.
display_name	Human-readable name.
family	llama / qwen / …
type	dense or moe (MoE models are priced by active parameters).
size_b	Parameter count in billions. For MoE this is active params.
context_length	Max context tokens the base model supports.
extended_context	Whether a :peft: variant with extended context is available.
supported_algorithms	Algorithms known to work — sft, importance_sampling, ppo.
pricing	Optional upstream rates (per million tokens). Fall back to Tinker console for authoritative numbers.

Validation at job creation

When you submit dn train sft --model <id> or dn train rl --model <id>, the API validates <id> against this catalog before the job is created. Unknown ids are rejected with a synchronous error plus a “did you mean…?” hint derived from the catalog:

Unknown training base model 'meta-llama/Llama-3.1-8B-Instruc'.
 Did you mean one of: meta-llama/Llama-3.1-8B-Instruct, meta-llama/Llama-3.1-8B?

No compute is provisioned in this case — the job row is never created.

Note

The SDK and API keep independent copies of the catalog (the API cannot import from the SDK by layering rules). A drift-detection test in the SDK suite fails if the lists fall out of sync — whenever Tinker ships new models, both copies move in the same PR.

Updating the catalog

The catalog lives in two files:

• packages/sdk/dreadnode/training/models.py — the SDK source of truth (what dn train catalog lists and the ApiClient consumes).
• packages/api/app/training/catalog.py — mirrored in the API so create_job can validate without importing SDK code.

When Tinker adds a new model, update both files, run the training test suites in each package, and ship a coordinated PR. The pricing fields are optional — leave them None if we haven’t confirmed them, and reference the Tinker console for authoritative numbers.