Overview

Magnitude’s local-model journey is a stateful chain: a catalog identity is assessed for fit, chosen by the user, downloaded as a durable artifact, loaded into the runtime, and observed through real work. Each boundary has a different owner and remedy, so Fits, Installed, and Ready are not interchangeable. Capability and resource gates precede speed, intelligence, fidelity, context, and acceleration trade-offs; unresolved performance belongs to runtime observation or controlled measurement.

Learning outcomes

Fits means an assessed plan passed under a snapshot; Ready means the model crossed current runtime admission and is resident.
Installation creates durable bytes, while loading creates a current runtime allocation and can fail after conditions change.
Selection starts with required capabilities and fit, then weighs workload trade-offs before observation tests unresolved performance.

Keywords

Magnitudereadinesscatalogacquisitionresidencyobservation

The Decision Chain: From Catalog Entry to Ready Model

Magnitude's local-model journey is now easier to see as one chain rather than a set of menu labels. This checkpoint connects catalog identity, native fit, user choice, acquisition, and runtime readiness so the reader can locate a problem when a model is missing, rejected, downloading, loading, or slow. It also turns those connections into a conditional selection rule: hard requirements come first, softer trade-offs come second, and performance questions that remain unresolved belong to runtime observation or controlled measurement.

One model, several meanings of “ready”

Imagine opening Magnitude and seeing a model that looks appropriate for an agent. At that moment, the system may know the model as a reviewed catalog configuration, but it may not yet know whether the chosen serving profile fits the current machine. After assessment, it may know that the profile fits under a particular hardware snapshot, while still having none of the model's full weights on the computer. After download, the artifact may be installed but unloaded. After loading, the inference service may be ready to accept requests, while the agent has not yet tested the model on its actual work.

Those are not pedantic distinctions. They identify different owners, triggers, and remedies. Catalog identity belongs to the reviewed configuration and its artifact references. Fit belongs to the native planning result for a serving profile and hardware topology. Acquisition belongs to the model store and its download operation. Residency belongs to the inference runtime. A failure at one boundary should not be “fixed” by changing a value owned by another boundary.

The state path below is a compact diagnostic model. A candidate becomes assessable after discovery or catalog reconciliation. Assessment can end in a fitting profile or an explicit rejection because the artifact is incompatible or the required resources are unavailable. A fitting choice still needs a user decision before a catalog download. Installation produces bytes; it does not allocate the active runtime. Loading is the point at which the current machine is checked again and native resources are committed.

stateDiagram-v2 [*] --> Candidate Candidate: Candidate / not yet assessed Assessing: Assessment in progress Fits: Fits under assessed profile Rejected: Does not fit or incompatible Chosen: User selected configuration NotInstalled: No local artifact yet Installing: Download or update in progress Installed: Artifact installed Unloaded: Installed but not resident Loading: Runtime load and current admission check Ready: Resident and ready Failed: Acquisition or runtime failure Candidate --> Assessing: discovery or catalog reconciliation Assessing --> Fits: native plan passes snapshot Assessing --> Rejected: plan fails or artifact incompatible Fits --> Chosen: user chooses before download Chosen --> NotInstalled: no local artifact yet NotInstalled --> Installing: catalog artifact is needed Installing --> Installed: acquisition completes Installed --> Unloaded: no active residency Unloaded --> Loading: load request / runtime recheck Loading --> Ready: current admission succeeds Loading --> Failed: load or admission fails Ready --> Unloaded: stop or idle/resource release Rejected --> [*] Failed --> Unloaded: recoverable state or retry

Published by DeepMox

FAQ

Why can a fitting Magnitude model still be unable to answer a request?

A fitting Magnitude model can still lack downloaded weights, be unloaded, be loading, or face changed current memory before a request is admitted. Fit is preflight evidence, while readiness and request completion are later states.

Why does Magnitude separate installation from loading?

Magnitude separates installation from loading because installation preserves model bytes, while loading commits the current runtime allocation and performs a fresh admission check. Unloading can release resources without deleting the installed artifact.

What should be measured after a Magnitude model becomes ready?

After a Magnitude model becomes ready, measure the phases and workload that matter, such as time to first token, prefill, decode, concurrency, context depth, or task-specific results. A successful load does not prove endpoint performance or harness usefulness.

Previous10 minMagnitude: Native Fit

Next10 minMagnitude: Scheduling and Streaming

Magnitude: Model Readiness

The Decision Chain: From Catalog Entry to Ready Model

One model, several meanings of “ready”

FAQ