Runtime

The MIND runtime provides deterministic execution of compiled models with minimal overhead. It supports multiple deployment modes from embedded devices to cloud servers.

Key takeaway

The open repository ships a reference CPU interpreter; production CPU, GPU and accelerator backends live in the commercial mind-runtime, and determinism is stated as three separately verifiable tiers.

Architecture

  1. Application
  2. Runtime API (C/Rust)
  3. Executor
    Memory Manager
  4. CPU reference interpreter
    Open repository, behind the cpu-exec feature
    GPU + Accelerator DriversCommercial
    Commercial mind-runtime
Each layer sits on the layers below it. The bottom row is where the open and commercial runtimes divide.
Plain-text version of the diagram
┌───────────────────────────────────────────────┐
│                  Application                  │
├───────────────────────────────────────────────┤
│              Runtime API (C/Rust)             │
├───────────────────────┬───────────────────────┤
│        Executor       │     Memory Manager    │
├───────────────────────┼───────────────────────┤
│     CPU reference     │   GPU + Accelerator   │
│      interpreter      │  Drivers (Commercial) │
└───────────────────────┴───────────────────────┘

Where the line falls

Open repository: reference CPU interpreter

A reference CPU interpreter: correct but unoptimized, gated behind the cpu-exec feature, and intended for learning, prototyping, and small workloads. It is not a production or “native” execution backend, and a few operations it does not cover return a structured Unsupported error rather than a wrong answer: those are deliberate architectural boundary markers, not gaps.

Commercial mind-runtime: production backends

Production-grade runtime backends (CPU with SIMD and tiled matmul, GPU, and accelerators such as CUDA, ROCm, Metal, and others) live in the commercial mind-runtime under a commercial license.

Compilation itself is separate from either: the open-source mindc compiles deterministic native binaries for the CPU, and the open repository contains no vendor GPU kernels.

GPU Runtime (Commercial)

GPU and multi-vendor accelerator execution ships in the commercial mind-runtime under a commercial license. Capabilities include:

CUDA / ROCm / Metal

Vendor-native GPU backends via dynamic SDK loading.

WebGPU / WebNN

Browser and edge-device acceleration targets.

Specialized accelerators

TPU, NPU, FPGA, and ASIC targets under evaluation.

Deterministic fallback

CPU reference path when a vendor SDK is unavailable.

Execution Modes

ModeUse CaseCharacteristics
AOT (Ahead-of-Time)Production deploymentFastest startup, smallest binary
JIT (Just-in-Time)Development, dynamic shapesFlexible, runtime optimization
InterpreterDebugging, conformanceReference implementation

Memory Management

Static allocation

Memory planned at compile time for AOT.

Arena allocator

Fast bump allocation for intermediate tensors.

Buffer reuse

Automatic sharing of memory between non-overlapping tensors.

Device memory

Unified API for CPU and GPU memory.

Determinism Tiers

MIND defines three independently verifiable determinism tiers. Each tier addresses a different audit consumer; each is independently observable; an implementation may satisfy any subset, but conformance to a higher tier never weakens a lower tier. The normative reference is mind-spec performance §determinism-tiers.

TierScopeClaimVerification
1CompilationSame source → same artifactSHA-256 of build output
2Runtime, within substrateSame input + same code path → same outputRepeated-invocation hash match
3Runtime, across substratesQ16.16 output byte-identical across substrates (x86 == ARM verified; GPU roadmap)SHA-256 of conformance corpus

Tier 3 implies Tier 2 for the Q16.16 path; Tier 2 implies nothing about Tier 3; Tier 1 is orthogonal to both.

Tier 1: Build determinism (required)

Build gates compare the covered mic@1 text, mic@3 binary IR, and native artifacts under fixed source, toolchain, flags, dependencies, target, and other build inputs. A same-target reproducibility result does not imply identical native ELF, cdylib, or AOT bytes across operating systems or ISAs. Verified by SHA-256 of the produced artifacts; the evidence-chain attestation (RFC 0016) anchors its trace_hash on the mic@3 binary (re-anchored 2026-05-31, prior mic@1 text anchor was lossy for function bodies).

The native-ELF self-host fixed point is closed as of the v0.10.x line, in three senses:

mic@3 binary IR

The pure-MIND front-end reproduces the canonical mic@3 binary IR of its own source byte-for-byte (the layer trace_hash anchors on).

mic@1 IR text

It reproduces the mic@1 IR-text bootstrap fixed point.

Native x86-64 ELF

It emits the native x86-64 ELF of the entire seeded module byte-identically against the Rust reference.

Running as a native ELF using only read/write/exit, the pure-MIND compiler reproduces its own compiler binary byte-identically three stages deep, with Rust and LLVM out of the loop, on the integer/control-flow subset. Gated by the keystone suite (7/7) plus a zero-Rust bootstrap loop.

Not yet done

Full-chain Rust-independence is not yet done: a full-surface native backend covering floats, tensors, and GPU is still roadmap, and the MLIR/LLVM path continues to carry that codegen.

Tier 2: Within-substrate runtime determinism (required in deterministic mode)

Same input bytes + same hardware + same selected code path → byte-identical output bytes, every invocation. IEEE 754-2008 strict for floating-point operations (including FMA). No threading non-determinism: deterministic mode disables work-stealing and ordered-reduction-violating optimizations.

// Create runtime with deterministic mode (default)
let rt = Runtime::new(RuntimeConfig {
    deterministic: true,  // IEEE 754 strict, no threading non-determinism
    seed: 42,             // RNG seed for reproducibility
});

// Same inputs always produce same outputs (Tier 2)
let out1 = model.forward(&input);
let out2 = model.forward(&input);
assert_eq!(out1, out2);  // Guaranteed

Opt-in SIMD fast paths require a fixed input, arithmetic profile, and execution path for deterministic replay. Floating-point SIMD reduction order may differ from sequential scalar order; an error bound requires the particular algorithm and input assumptions. Hardware identity alone does not establish a numerical bound.

Tier 3: Cross-substrate output identity for admitted workloads

The committed Q16.16 and exact-integer workloads produce byte-identical results on the verified CPU pair, x86 AVX2 and ARM NEON. Cross-substrate tests compare serialized computational outputs with pinned SHA-256 references. GPU output identity requires separate device evidence and remains outside this shipped claim.

Three strict floating-point fixtures are also covered: the scalar f64 chain, length-4093 f32 dot, and 64×64 f32 matrix-vector product. Their operation and accumulation orders are fixed, with exact output-bit comparisons on both CPU substrates. RFC 0015 section 5A binds the fixtures and hashes. This does not establish identity for arbitrary floating-point inputs, reduction orders, transcendental functions, or accelerator backends.

Resource Limits

let config = RuntimeConfig {
    max_memory_mb: 1024,      // Memory limit
    max_threads: 4,           // Thread pool size
    timeout_ms: Some(5000),   // Execution timeout
    ..Default::default()
};

let rt = Runtime::new(config);

Profiling

// Enable profiling
let rt = Runtime::new(RuntimeConfig {
    profile: true,
    ..Default::default()
});

model.forward(&input);

// Get profile data
let profile = rt.get_profile();
for op in profile.operations {
    println!("{}: {}ms", op.name, op.duration_ms);
}

Learn More

See the full runtime specification at mind-spec/runtime.md and the runtime is available as part of MIND Enterprise.