What phases, dtypes, layouts, and workloads the provider can execute.
PRISM ENGINE × GENERAL COMPUTE
Make unusual
hardware legible.
SambaNova is a useful test of Prism’s heterogeneous-first architecture: the accelerator is not treated like a generic GPU, and the model is not forced to pretend every phase has the same physical home.
GENERAL COMPUTESpecialized accelerator capability+PRISM ENGINEDeployment plan and evidence
A provider and a planner.
General Compute brings the physical execution system: SambaNova accelerators, their memory behavior, kernels, queues, and provider-specific capabilities. Prism brings the layer that turns a workload requirement into a legal, inspectable composition across those capabilities.
GENERAL COMPUTE / SAMBANOVAPhysical executionaccelerator · memory · kernels · queues · transport
capability contract →PRISM ENGINEDeployment planningadmission · phase placement · handoff · receipt
One serving request.
Several physical phases.
A frontier-model serving path does not have to assign prefill, KV state, decode, and streaming to the same provider. Prism can represent the phase requirements and ask the capability model for the lowest-latency legal composition.
PHASE 01PREFILLprocess prompt
produce KV state
produce KV state
BOUNDARYKV HANDOFFexplicit transfer
ownership + cost
ownership + cost
PHASE 02DECODEtoken generation
state residency
state residency
PHASE 03STREAMobservable output
terminal receipt
terminal receipt
Researcher detail
The repository’s heterogeneous-serving fixture models provider capabilities for prefill, KV handoff, decode, and token streaming. The serving requirement remains fixed while changing capability descriptions changes the physical plan. The SambaNova path is a planning and integration surface, not a claim of general production support.
The accelerator stays itself.
Prism does not flatten SambaNova into a Metal-shaped abstraction. It preserves provider-specific capabilities while making their implications visible to the deployment planner.
Which phase should run where under latency, memory, and compatibility constraints.
Where KV or other state crosses a physical memory or provider boundary.
What was admitted, executed, measured, and recorded for replay.
Clear boundaries prevent fake portability.
GENERAL COMPUTE OWNSProvider reality
SambaNova topology
Accelerator execution
Memory and queues
Provider transport
Kernel behavior
PRISM ENGINE OWNSDeployment reality
Workload semantics
Capability matching
Phase placement
KV ownership
Receipts and recovery
Compare plans, not slogans.
The useful question is not whether SambaNova behaves like a GPU. It is whether Prism can represent its capabilities, produce a legal plan, execute the selected phases, and compare the resulting evidence against another deployment.
INPUTsame model
same workload
same quality policy
same workload
same quality policy
PLAN AApple / Metal
local consumer path
local consumer path
PLAN BSambaNova
specialized path
specialized path
OUTPUTlatency
memory
quality
receipts
memory
quality
receipts
Current boundary
SambaNova and General Compute integration is represented as a heterogeneous planning and development surface. The architecture is designed to make that path testable without overstating its production maturity.
GENERAL COMPUTE × PRISM ENGINE
Different hardware
should improve the plan.
SambaNova gives Prism a concrete non-mainstream accelerator boundary. Prism gives General Compute a way to express where that accelerator is strongest in a larger deployment system.
Read Heterogeneous First ↗ Back to Prism Engine ↗