Skip to main content

The Model Flywheel

Where this sits

The infrastructure decides where work runs; the Model Flywheel governs how each expert improves over time. For the surrounding model — capacity tiers, execution lanes, placement and privacy — see Private Agentic Infrastructure.

ColabHive treats merge and retrain-on-top as first-class, generic operations. Together they form a flywheel: you can combine capabilities that already exist, train new capability on top of the result, and feed that result back in as the base for the next round — indefinitely, without anything hardcoded.

   base model ──merge──► combined model ──retrain──► specialized model
        ▲                                                   │
        └───────────────── use as new base ─────────────────┘

Every step produces an ordinary model_version. A merged model is not a special artifact: it is served through the normal inference path and reused as a base exactly like any trained model.

Two operations, one primitive​

Under the hood both operations are the same primitive — a job that stages artifacts (a base and/or adapters/sources) resolved from the catalog by reference, and produces a model_version with lineage.

Merge​

base + [adapters] (or several full sources) → a new full model (framework=transformers, precision=bf16).

  • Merging is weight arithmetic and runs on CPU — it does not consume GPU.
  • Methods: adapter_merge (default, fold LoRA adapters into the base), slerp, ties, dare (combine full models). Extensible.
  • Chains are never re-quantized — precision stays bf16 so quality does not decay round to round.

→ POST /training/merges

Retrain-on-top​

A normal training run whose base is an existing model_version (trained or merged) instead of a HuggingFace repo. Produces an adapter/model with parent_job_id + base_model_version_id recorded.

→ POST /training/runs with a base

Both resolve their base/artifacts generically, by catalog reference — never by a hand-written storage path.

References, not paths — the ArtifactRef​

You point at inputs by reference, and the platform resolves them to storage + metadata, validates ownership, and stages them:

typeUse it for
hfA HuggingFace repo (repo_id, optional revision)
model_versionAny trained or merged version you own or that is public (version_id)
jobA training job's output version (job_id)
storageAdvanced escape-hatch: a direct s3:// URL

Visibility reuses ColabHive's existing rules — public versions are usable by anyone; private versions only by their owner. To let another account build on your model, publish it. Lineage always records the origin. Full type reference: ArtifactRef.

Lineage & naming​

  • Full traceability. Every model exposes its chain — which base it came from, with which job/dataset, what it merged — via base_model_version_id / parent_job_id. Query it with GET /models/{id}/lineage.
  • Editable names. A version's name is a mutable label. Renaming does not break lineage, because identity is the version_id, not the name. (PATCH /models/{id}/versions/{version_id})

Governance​

  • Quota. A merge is a job — it counts against your account's training quota, same as any run.
  • Lifecycle. A merged/retrained model enters as candidate, passes an inference test, then is promoted to ready before it is treated as production-ready.
  • Flywheel knobs (optional, generic). Anti-forgetting replay (mix 20–30% of prior history) and periodic re-baselining are available as ordinary training hyperparameters with sane defaults — applicable to any chain, not wired to any specific case.

Where to go next​

Authors: José Luis Minich, Maximiliano Lucius.