Choose and inspect models

Choose a ready specialist model or an off-the-shelf vision-language foundation, then inspect the exact runtime and version.

Source reviewed 2026-09-23. Availability depends on your installation, permissions, and compatible runtimes. A supported path is not a guarantee of model quality or production readiness.

Outcome

Select the right starting artifact instead of training every model from scratch.

Start here

What you need to know first

Check the inputs below before starting. If you are new, begin with the first-project guide. A dataset holds media and labels; a model produces results; a deployment makes a selected model version callable. Creating one does not create the others.

Bring these inputs

Pretrained or trained model artifacts
Model card metadata and evaluation evidence

Expected output and limits

Version-addressable registry entries
Workflow, test, fine-tuning, and deployment bindings

Core workflow

01
Choose the capability first
Start from the output you need: detection, segmentation, classification, or vision-language. The catalog separates ready specialist versions from off-the-shelf VLM foundations so availability is never mistaken for runtime readiness.
02
Inspect the model card
Read names as family + scale + variant. Review provider, task, provenance, evaluation evidence, runtime profile, and version history as separate fields. Satori 2B Grounded is the Score-managed grounded foundation; Qwen3-VL 8B Instruct is available with a compatible runtime connection.
03
Select a version
Bind a specific artifact to a workflow, test session, or fine-tuning run.
04
Promote with evidence
Use evaluation and conformity results to decide which version can enter production.

What this surface supports

Available public and authorized private models
Curated specialist model library
Satori and Qwen3-VL foundation selection
Rich model cards
Version and deployment lineage

Expert section

Contracts, signals, and failure modes

Use this section when you are defining acceptance criteria, automating the surface, or reviewing whether its output is safe to promote downstream.

Quality and operating signals

Benchmark quality
Latency, memory, and model size
Artifact and license provenance

Common failure modes

Comparing metrics from different benchmarks
Using an unpinned latest version
Ignoring runtime or license constraints

Expert release checklist

Inputs and dependencies are pinned to immutable versions.
Acceptance metrics include critical classes and operating slices.
Failure, retry, cost, and rollback behavior are understood.
The resulting artifact has an owner and a downstream review path.

Engineering safeguards

Artifacts are versioned
Evaluations identify their benchmark
Production eligibility remains visible