A18 Neo / tiny systems
Minimize resident state. Prefer compact views, bounded context, and conservative fallbacks.
STATUS / target-class designVOLUME I / DEPLOYMENT MODEL
Heterogeneous
first.
Prism is designed around one question: how do we deploy the same frontier model across machines that do not share the same memory, kernels, accelerators, or failure modes?
A model should describe the work.
The deployment system should describe the machine.
The deployment system should describe the machine.
One semantic workload.
Many physical homes.
Prism separates the model's logical execution requirements from the hardware that will satisfy them. The compiler and planner preserve the workload semantics while selecting representations, memory tiers, execution lanes, transfers, and validation gates for a particular target.
EDGEsmall resident set
minimal scratch
local fallback
→minimal scratch
local fallback
CONSUMERunified memory
Metal / CPU
interactive latency
→Metal / CPU
interactive latency
ACCELERATORprovider capabilities
phase placement
explicit handoff
→phase placement
explicit handoff
DATACENTERshards · lanes
KV movement
coordination
KV movement
coordination
Different machines.
Same requirement.
The serving requirement can stay constant while the physical plan changes. Prefill may run on one provider, KV state may cross an explicit boundary, and decode or streaming may run on another provider. The planner chooses a legal composition from capability descriptions rather than baking one vendor into the workload.
WORKLOADServe frontier modellatency · memory · quality policy
PHASE 01Prefillprovider capability + admission
HANDOFFKV transferexplicit memory boundary
PHASE 02Decode + streamprovider capability + receipt
Researcher detail
The heterogeneous-serving fixture expresses a fixed serving requirement and provider phase capabilities for prefill, KV handoff, decode, and token streaming. Replacing the capability descriptions changes the plan without changing the serving requirement or orchestration contract.
Deployment profiles are explicit.
Prism does not assume that a “GPU backend” is one universal target. A target profile can constrain memory, bandwidth, scratch, resident views, context, sharding, and preferred execution lanes.
M-base / M-Pro
Balance unified memory, fused Metal decode, scratch budgets, and interactive latency.
STATUS / primary Apple pathANE / Tenstorrent / SambaNova
Describe provider capabilities, phase support, transfer costs, and validation obligations.
STATUS / integration and development surfacesM-Max / M-Ultra / clusters
Use layer locality, wide streaming, sharding, KV ownership, and explicit coordination.
STATUS / planning and prototype surfacesPrism does not pretend
to be the accelerator.
Prism owns the deployment contract: workload identity, capabilities, admission, placement, residency, ownership, transfers, receipts, and recovery. A provider owns its physical topology, kernel implementation, queue mechanics, and transport primitives.
PRISM OWNS
semantic workload
physical plan
KV ownership
admission policy
execution receipts
PROVIDER OWNS
kernels
queues
memory handles
fabric transport
device topology
Frontier models can travel
without becoming identical.
A single model family can have multiple deployment identities: a compact edge image, a Metal-oriented consumer image, an accelerator composition, or a sharded datacenter plan. The logical model remains comparable while the physical artifact reflects the machine.
Edgesmall image
bounded memory
offline execution
bounded memory
offline execution
MacMetal fused decode
unified memory
local serving
unified memory
local serving
Specializedcapability-driven phases
explicit handoffs
provider validation
explicit handoffs
provider validation
Datacentershards and stripes
KV coordination
replayable evidence
KV coordination
replayable evidence
What is implemented today?
Apple Silicon compilation and Metal execution are the primary supported path. Linux CPU execution is under active hardening. AMD, Intel, NVIDIA, Tenstorrent, SambaNova, ANE, and distributed execution are represented at differing levels of integration, planning, simulation, or prototype maturity; they should not be described as uniformly production-ready.
THE PRISM PAPERS / VOLUME I
Heterogeneous hardware
should be a planning input.
Prism's long-term claim is not that every device executes the same way. It is that a coherent compiler and evidence contract can make those differences explicit enough to plan, compare, and recover.
Read the architecture ↗ Back to Prism Engine ↗