Runtime

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

Architecture

┌─────────────────────────────────────┐
│              Application                  │
├───────────────────────────────────────────┤
│          Runtime API (C/Rust)             │
├───────────────────────────────────────────┤
│   Executor   │   Memory Manager           │
├──────────────┼────────────────────────────┤
│ CPU reference│  GPU + Accelerator Drivers │
│ interpreter  │      (Commercial)          │
└──────────────┴────────────────────────────┘

Where the line falls. The open repository ships a reference CPU interpreter — correct but unoptimized, gated behind the cpu-execfeature, 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.

Production-grade runtime backends — CPU with SIMD and tiled matmul, GPU, and accelerators (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

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.

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: 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), it reproduces the mic@1 IR-text bootstrap fixed point, and 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. 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.

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

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.