Composable Distillation Intelligence ™ (CDI) Framework
Simplicity · No Recurring Token Cost · Flexibility · Data Sovereignty
Apex Strategic Intelligence LLC
August 2026
Executive Summary
Most small and mid-sized businesses evaluating AI adoption are sold a single architecture: a large, cloud-hosted, general-purpose model, billed per token, with data leaving the premises on every call. That architecture optimizes for the vendor's economics, not the SMB's. Apex Strategic Intelligence proposes an alternative: a Small Language Model (SLM) stack designed around four properties SMBs actually need — simplicity, no recurring token cost, flexibility, and data sovereignty.
Those four properties, however, do not require a single deployment path. This brief presents two architectural constructs — On-Premises and Private Cloud — that both satisfy the same four design properties but trade capital cost, management burden, and scalability differently. On-premises suits firms with existing IT capacity and a hard sovereignty mandate; private cloud suits smaller SMBs for whom capital outlay and infrastructure management are the binding constraints. Both are mapped onto the same 7-layer OSI-based reference model, differing only at the physical and data-link layers.
The Problem With the Default Architecture
The dominant commercial AI deployment pattern couples four things that do not need to be coupled: model size, hosting location, billing model, and data custody. A frontier LLM accessed via API is large by necessity, hosted off-premises by design, billed per token because that is how the vendor recovers massive training and inference cost, and therefore requires the client's data to leave its own environment on every request.
For an SMB, none of those four properties is a requirement — they are simply bundled defaults. An SLM architecture unbundles them. But unbundling them still leaves a real architectural choice: who owns and operates the physical infrastructure the model runs on. That choice is the subject of this brief.
Two Architectural Constructs
Both constructs deliver the same stack, the same CDI-based model behavior, and the same four design properties. They differ only in where the bottom two layers — Compute Hardware and Inference Runtime — physically live and who is responsible for them.
Construct A — On-Premises
The client purchases Apex hardware outright and runs inference entirely on its own premises, with no external network dependency required for the model to function. This is the maximum-sovereignty, maximum-capital-outlay end of the spectrum, best suited to firms that already carry IT headcount and infrastructure budget.
Construct B — Private Cloud
The client's compute runs on a dedicated, single-tenant partition within a private cloud environment — architecturally and contractually isolated from the provider and from every other tenant, but not physically housed on the client's premises. This trades a small amount of sovereignty purity for materially lower upfront cost and no on-site hardware to manage, which is often the more realistic construct for smaller SMBs.
The 7-Layer SLM Reference Model
Layers 3 through 7 are identical regardless of which construct a client chooses — routing, context handling, session memory, distillation, and the business application sit above the infrastructure decision and are unaffected by it.
OSI # | OSI Layer | SLM Equivalent | Function |
|---|---|---|---|
7 | Application | Business Logic Layer | SMB-facing UI/workflow delivered by the MSP. No model complexity exposed to the end user. Identical in both constructs. |
6 | Presentation | Distillation / Adapter Layer | CDI™-style compression and fine-tuning translate a general SLM into a domain-specific one; formats raw output into business-usable structure. Identical in both constructs. |
5 | Session | State & Memory Layer | Local or tenant-isolated vector store and conversation memory. Persists context within the client's controlled boundary — never round-trips to a third-party foundation-model vendor. |
4 | Transport | Context Pipeline Layer | Manages prompt assembly, chunking, and delivery to the model reliably — the token-level analogue of guaranteed delivery. Identical in both constructs. |
3 | Network | Model Routing Layer | Routes tasks across a mesh of small, specialist models rather than one large generalist; swap models per task without re-architecting. Identical in both constructs. |
Figure 1. Layers 3–7 of the Apex Sovereign Inference Stack — identical across both constructs.
Layers 1 and 2 are where the two constructs diverge. The table below shows the same OSI positions filled by two different implementations.
OSI # | Layer | On-Premises Construct | Private Cloud Construct |
|---|---|---|---|
2 | Data Link → Inference Runtime | Local runtime (e.g., llama.cpp / ONNX-style) executes directly on client-owned hardware, fully offline-capable. | Same runtime software, executed inside a dedicated, single-tenant virtual instance the client controls but does not physically host. |
1 | Physical → Compute Hardware | Apex Desktop, Enterprise, or Cluster tier — physical silicon purchased outright and installed on the client's premises. | Reserved or dedicated capacity on a private cloud partition (e.g., a client-owned VPC), billed as fixed monthly infrastructure, not metered by usage. |
Figure 2. Layers 1–2 — On-Premises vs. Private Cloud implementations.
Comparing the Two Constructs
Neither construct is categorically superior; each optimizes for a different combination of capital availability, IT capacity, and sovereignty requirement. The table below lays out the trade-offs directly.
Dimension | On-Premises Construct | Private Cloud Construct |
|---|---|---|
Upfront cost | Higher — hardware purchased outright | Lower — no capital outlay for compute |
Recurring cost | None beyond power/maintenance | Fixed monthly infrastructure fee (not usage-metered) |
IT management burden | Client or MSP maintains physical hardware | Provider maintains underlying infrastructure; MSP manages the SLM stack |
Data sovereignty | Data never leaves client premises | Data stays in a client-isolated tenant; contractually and architecturally segregated from the provider and other tenants |
Scalability | Bounded by purchased hardware; scaling requires new hardware | Elastic within the reserved private partition; capacity adjusts without a hardware purchase |
Best-fit segment | Firms with existing IT staff, capital budget, and a hard sovereignty requirement (e.g., regulated, defense-adjacent, or highly compliance-sensitive SMBs) | Smaller SMBs with limited IT staff and capital, prioritizing predictable monthly cost and offloaded infrastructure management |
Figure 3. On-Premises vs. Private Cloud — decision matrix.
How the Four Design Properties Hold Across Both Constructs
No Recurring Token Cost
On-premises: once hardware is purchased, inference costs electricity, not per-token fees. Private cloud: the client pays a fixed monthly infrastructure fee for reserved capacity — a predictable line item, not a metered charge that scales with usage. In both cases, the defining departure from hyperscaler LLM economics holds: cost does not increase with the volume of tokens processed.
Data Sovereignty
On-premises delivers sovereignty in its purest form — data physically never leaves the client's four walls. Private cloud delivers sovereignty through architectural and contractual tenant isolation: the client's model instance, context, and session state occupy a dedicated partition that is not accessible to the provider, to other tenants, or to any third-party foundation-model vendor. For most SMBs, this satisfies the sovereignty requirement; for firms in the most compliance-sensitive verticals, on-premises remains the stronger guarantee.
Flexibility
Layer 3 model routing is unaffected by the construct choice — a client can swap or reweight specialist models in its mesh identically whether that mesh runs on owned hardware or a private cloud partition. Construct choice itself is also flexible: a client can start in private cloud and migrate to on-premises later (or vice versa) as its IT capacity and capital position change, without altering Layers 3–7.
Simplicity
Both constructs preserve strict layer independence, so each layer can still be sold, supported, and upgraded as a discrete unit. Private cloud adds a second simplicity benefit specific to smaller SMBs: it removes physical hardware management from the client's list of responsibilities entirely, which is often the more meaningful simplification for a firm with no dedicated IT staff.
Choosing a Construct by Firm Profile
- Choose On-Premises when: the firm already has IT staff and infrastructure budget, operates in a highly regulated or compliance-sensitive vertical, or requires inference to function with zero external network dependency.
- Choose Private Cloud when: the firm is a smaller SMB with limited or no dedicated IT staff, prefers predictable monthly cost over capital outlay, or needs to scale capacity without a hardware purchase cycle.
- Either construct: satisfies all four Apex design properties and sits on the identical Layer 3–7 stack — the choice is an infrastructure decision, not a re-architecture of the model layer.
Commercial Implications for MSP-Led Delivery
- Two-tier hardware/infrastructure offering: MSPs can sell Apex Desktop/Enterprise/Cluster hardware tiers alongside a Private Cloud partition tier, letting the client self-select on cost and IT capacity rather than being locked into one construct.
- Layered pricing, either construct: each OSI-mapped layer remains an independent line item — infrastructure, runtime, routing, adapters — rather than a single opaque subscription.
- Migration as a service: MSPs can offer construct migration (private cloud → on-premises, or the reverse) as a discrete engagement, since Layers 3–7 do not need to change.
- Sovereign-by-default positioning: because data custody is structural in both constructs, sovereignty remains a default property of the architecture rather than a contractual promise layered on top of a public cloud vendor's stack.
Conclusion
Framing SLM deployment through the OSI model does two things at once: it gives technical buyers a mental model they already trust, and it forces architectural discipline — each layer must do one job and expose a clean interface to its neighbors. Extending that model to two infrastructure constructs — On-Premises and Private Cloud — acknowledges that SMBs are not a single buyer profile: capital position and IT capacity vary sharply across the segment, and the right construct is the one that fits the firm, not the one that fits a single reference architecture. In both cases, simplicity, cost predictability, flexibility, and data sovereignty remain direct consequences of where processing happens and who owns each layer — not marketing claims layered on top.