What ‘Fits’ Really Means
Magnitude can recommend a local configuration only after it answers a more exact question than “is this model small enough?” This chapter examines the relationship among an artifact, a serving plan, and the machine's physical memory so the reader can distinguish stored size from runtime demand, a catalog label from native evidence, and a preflight result from a guarantee that every later load will succeed.
A model is an artifact plus a plan
A model name is a convenient handle, not a complete runtime identity. The same family can be offered in several quantization variants, with different fidelity and storage costs. Its serving choice can also change the context length, device placement, cache types, or acceleration material. A multimodal configuration may need a projector in addition to the text model. A configuration using speculative decoding may need a separate draft artifact. Architecture determines which tensors are active, how state grows with context, and which native operations the runtime must perform. Each of these facts can affect whether a configuration is useful on a particular machine.
Magnitude's curated catalog records those distinctions instead of presenting a list of friendly names. A catalog configuration can carry a model identity, architecture class, total parameters and, for a mixture-of-experts model, active parameters, variant and quantization information, context, capabilities, license, and quality-score provenance. It can also declare an associated projector or a reviewed speculative-decoding draft. These are not decorative fields. They identify the thing being assessed and the conditions under which its performance and memory claims make sense.
The distinction between total and active parameters is especially easy to misuse. A dense model uses the relevant dense weights throughout its decoder. A mixture-of-experts model stores a large pool of experts but routes each token through only a selected subset, along with always-active components such as routers, shared experts, attention, embeddings, or output layers. That can reduce the computation performed for one token without removing the need to store the model components required by the runtime. “Active” therefore helps describe executed work; it is not a synonym for download size or total memory requirement.
Quantization creates a similar trap. A label such as Q4 describes a family of tensor representations, but speed depends on the actual runtime operation, backend, device, and placement. Fidelity is a separate concern: a higher-fidelity local artifact may preserve more of the source model while consuming more storage or memory. The correct comparison is not “four bits equals one fixed speed and one fixed footprint.” It is “this exact artifact, under this native plan, has these resource and performance consequences.”
Context is part of that plan. It describes how much conversation and working material the serving configuration can hold, not merely the maximum number printed on a model card. Longer context can increase memory demand and can increase decode traffic for attention-based layers. Other architectures may retain some recurrent or sliding-window state whose work scales differently. Magnitude therefore assesses a selected serving context rather than assuming that the largest advertised context is automatically the practical choice.
The catalog's lock information makes artifact identity reproducible. Target packages, and separately packaged draft packages where required, are associated with immutable repository commits. Release generation resolves those references and derives planner inputs from the inspected GGUF metadata. If two catalog references use the same immutable package, they can share package identity and bundled planner payloads. The operational consequence is straightforward: a recommendation can point to a known artifact rather than to whatever file happens to have a similar display name at download time.
That does not make the catalog the final authority on every runtime detail. The repository's architecture reference says that similar parameter counts or marketing names are not enough to reuse an architecture model, and that exact GGUF metadata plus the pinned native runtime remain authoritative. The catalog supplies reviewed context for a choice; native inspection reconciles that context with the artifact that will actually be loaded. This is also why a catalog change needs architecture coverage and why a current catalog entry should not be assumed to inherit another family's cost model merely because its size looks familiar.
A practical example makes the distinction concrete. Suppose two configurations are both described as roughly the same parameter scale. One is dense and the other is a mixture of experts. Their stored weights, active per-token work, routing overhead, context state, and device placement can differ. Or suppose two variants share a model family but use different quantization. One may preserve more source-model behavior while requiring more memory; the other may fit a constrained machine but deliver a different fidelity trade-off. A recommendation that retains only the family name would conceal the very facts that determine whether the choice is viable.
The artifact is therefore the first half of “fits.” The second half is the serving plan: the context, batching, sequence count, key-value cache choices, offload policy, and placement that the native engine intends to create. A file can be unchanged while its memory requirement changes because the plan changes. Magnitude's assessment has to bind the exact bytes to the exact plan before a result means anything.
The diagram separates two quantities that are often collapsed. Download size belongs to the artifact and describes acquisition. Required runtime memory belongs to the assessed plan and describes loading. They are related, but neither is a safe replacement for the other.
Fit is native planning, not a guess
ICN—the native inference component inside Magnitude—uses a model-fit pipeline shared by downloaded inventory models and load previews. It resolves the artifact metadata, inspects the complete component set available to the planner, builds a graph without allocating the model for inference, and evaluates the requested execution profile against the hardware snapshot. This lets Magnitude perform meaningful admission work before committing to a full weight download.
The hardware snapshot is more than a total-RAM number. It records physical memory domains, native device views, capacities, and the bindings that show which device views share which physical pools. A memory topology then interprets an allocation location as a physical domain. That distinction matters on machines where a CPU and accelerator share unified memory, and on systems where backend names expose several views of one device. The accounting model does not infer shared memory from a platform label or device name; it resolves the native evidence through the snapshot-owned topology.
The planner accounts for different kinds of runtime demand separately. Model storage is the persistent weight and component footprint. Context state represents sequence memory such as a key-value cache or other architecture-specific state. Compute workspace supports the native graph. Auxiliary allocations cover additional runtime needs represented by the assessment. Each physical domain receives its own breakdown, and applicable device-local limits are checked alongside the physical-domain capacity. This is why a single total-memory comparison is not enough for a split model or a discrete accelerator: the location and limit of each charge can matter.
Suppose a model places some work on an accelerator and some in system memory. The relevant question is not simply whether the two capacity numbers add up to a large enough total. The planner must know which allocation belongs to which physical domain, whether an accelerator-local constraint is also active, and whether the selected placement creates transfers between domains. On a unified-memory machine, CPU and accelerator views may refer to one physical pool even though their operation calibrations differ. On a discrete-device machine, system RAM and device memory should not be merged as if either were freely interchangeable. The topology exists to preserve those distinctions while avoiding a second, conflicting set of platform-specific formulas.
The four-part breakdown also gives Magnitude a way to explain changes in a plan. Reducing context primarily changes context state; changing quantization changes the storage and operation characteristics of the artifact; changing offload or placement changes where charges are made and may add transfer costs; adding a draft or projector can add auxiliary demand. These changes can lead to different outcomes even when the friendly model name remains constant. They also explain why a user may solve a failure by choosing another context or placement rather than abandoning the model family entirely.
The causal path is therefore more disciplined than a memory guess. First the artifact supplies the tensor and component facts. Then the serving profile says what the runtime intends to create. The hardware snapshot says which physical domains and device constraints are available. The topology resolves each native allocation location to those domains. The accountant aggregates the breakdowns and compares them with capacity. Only after those steps does the system produce a fitting or non-fitting assessment. Each boundary prevents a different shortcut: the artifact prevents name-based inference, the profile prevents context-blind sizing, and the topology prevents device-label-based accounting.
A successful result is reported as Fits; an unsuccessful one is DoesNotFit or an incompatibility result. The evidence is more useful than the label alone because the result identifies the selected profile and reports, by domain, model, context, compute, auxiliary, required, available, and margin values. A failure can therefore point to a limiting resource rather than leaving the user with an unexplained “no.” In Magnitude's local provider projection, a non-fitting model is disabled for insufficient resources instead of being offered as if preference ranking could overcome the deficit.
The preview is valuable because it reduces an expensive mistake. If a configuration cannot fit the assessed plan, there is little reason to download its full weights merely to discover the same problem at load time. The preview can also compare several serving contexts or placements without forcing the engine through a complete runtime allocation for each one. In this sense, fit assessment is a resource filter that protects the later recommendation and acquisition steps.
It is not the final safety boundary. Runtime loading reassesses the concrete requested profile before allocating resources. The same artifact identities, native build, device topology, execution policy, and capacity policy participate in the cache key for preview and load. Rechecking matters because the machine can change between assessment and use: another model may be resident, an application may consume memory, the selected context may differ, or the available device capacity may no longer match the earlier snapshot. A configuration that fit under one observation can therefore require a new decision at the moment it is admitted.
The word “fit” also needs a boundary around what the planner does not claim. The documented native diagnostic is a planner estimate, not an observed peak-resident-set measurement. Its stated limitations include multimodal projector or draft-model allocations, other models already loaded by ICN, transient allocations during model loading, and an operating-system reserve beyond supplied margins. Free device memory is a point-in-time observation, and integrated or unified-memory backends can expose one physical pool through more than one native role. These qualifications do not make the assessment useless; they tell the reader where a strong preflight result stops being a complete runtime forecast.
The distinction between planning and observation is important for failure diagnosis. If the artifact is incompatible, changing a speed preference cannot help. If the profile exceeds a physical memory domain, the reader may need a smaller context, a different placement, or another variant. If the preview fits but the load fails after the machine changes, the problem is current admission rather than a contradiction in the catalog. If the model loads but generation is slow, the problem has moved from fit to performance and must be interpreted through the separate speed estimate or a controlled endpoint measurement.
This is also why Magnitude avoids deriving architecture behavior from a catalog ID. Native model loaders and graph builders know which tensors, state structures, and operations the exact GGUF artifact requires. A parameter count or family name can help a person orient themselves, but it cannot safely stand in for that inspection. For recurrent, sliding-window, sparse, or mixture-of-experts architectures, the relationship between stored components, active work, context, and memory is not uniform. The planner must use the artifact and plan that the engine will execute.
The resulting mental model is compact. First, identify the exact artifact, not only the display name. Second, identify the serving profile that will be created. Third, map the plan's charges onto the machine's physical memory domains and device limits. Fourth, treat Fits as evidence that the assessed plan passed under that snapshot. Fifth, let runtime load perform the final admission check. A fit result is stronger than a guess, but narrower than a promise about every future state of the computer.
That boundary is what makes the recommendation stage trustworthy. Magnitude can rank only after it has separated configuration identity from runtime fit, and it can explain a failure without pretending that all resource problems are speed problems. The next checkpoint will connect these states into one decision chain—from a catalog entry, through assessment and user choice, to installation and readiness—before the series turns to what happens once tokens actually begin to stream.