mojo-deterministic: Deterministic Kernels for Finance

• mojo-deterministic is an open-source companion library for financial AI that guarantees bit-level reproducibility in reduction operations.
• It employs fixed reduction orders and partitioning strategies to counter IEEE 754 non-associativity, ensuring results remain stable regardless of threading or chunking.
• Designed for audit-critical computations in capital markets, the library focuses on summation, dot product, and risk aggregation, with future extensions planned for broader applications.

mojo-deterministic is an open-source companion library for financial AI in Mojo that provides deterministic versions of summation, dot product, and risk aggregation, each designed to return the same bits regardless of thread count or how the input is split across chunks (Han, 14 Jun 2026). It was introduced as a concrete response to the determinism problems that arise in GPU- and multicore-accelerated financial AI, particularly where IEEE 754 non-associativity, schedule-dependent reductions, and library-level heuristic kernel selection can undermine auditability, reconciliation, and reproducibility. In this setting, mojo-deterministic is not a general-purpose numerical framework so much as a focused library of reduction kernels intended for audit-critical computations in capital markets workflows (Han, 14 Jun 2026).

1. Definition and scope

mojo-deterministic is presented as a small open-source companion library for financial AI, available at https://github.com/hank08819/mojo-deterministic, and written to fit into Mojo’s language and MLIR-based compilation pipeline (Han, 14 Jun 2026). Its stated public surface is narrow: deterministic implementations of three common operations—summation, dot product, and risk aggregation—with the explicit guarantee that the output is independent of thread count and chunking.

The targeted computations are reduction-heavy kernels in which floating-point order matters operationally. The paper identifies three recurrent cases: floating-point sums over large arrays, vector inner products, and portfolio-level aggregations of heterogeneous risk or P&L contributions. In the paper’s framing, these are precisely the places where “fast and nondeterministic” execution is unacceptable because a regulated financial system may need to reproduce the exact numerical result used for trading, risk, or capital calculations (Han, 14 Jun 2026).

The library is also positioned architecturally rather than merely algorithmically. It is intended for scalar, SIMD, and multicore CPU execution now, while the same design principles are intended to extend to GPU execution as the Mojo GPU stack matures. This suggests a single-source determinism strategy: the library treats determinism as a property of the kernel definition itself rather than as an after-the-fact runtime flag (Han, 14 Jun 2026).

2. Numerical motivation and financial requirements

The motivating problem is IEEE 754 non-associativity. For floating-point numbers $a$, $b$, and $c$,

$(a+b)+c \neq a+(b+c)$

in general, because every addition is rounded to finite precision (Han, 14 Jun 2026). The paper gives the corresponding machine-epsilon scales as $\approx 2^{-23} \approx 1.19 \times 10^{-7}$ for float32 and $\approx 2^{-52} \approx 2.22 \times 10^{-16}$ for float64. In a single-threaded implementation, the addition order is fixed by the compiler; in multicore or GPU reductions, the combination order depends on chunking, atomic commit order, kernel heuristics, and scheduling (Han, 14 Jun 2026).

The paper’s financial argument is that such variability is not merely a numerical nuisance. In backtesting, state evolves recursively through time, so an ulp-scale perturbation can alter a future decision path. In portfolio risk, large books aggregated across many scenarios are often ill-conditioned, so reduction-order sensitivity becomes visible in final risk numbers. In regulated environments, the requirement is not approximate agreement but exact reconciliation from recorded inputs and code (Han, 14 Jun 2026).

Several experiments are used to make this concrete. In a portfolio-risk reduction experiment with 100,000 risk contributions, mixed signs, and log-normal magnitudes spanning 12 orders of magnitude, naive parallel reduction produced 8 distinct floating-point results when only the block accumulation schedule changed; the spread between smallest and largest result was $8.5\times 10^{-4}$ on a base risk number of magnitude $5.9\times 10^{11}$, or about 6.5 ULPs at that scale. A deterministic tree reduction, by contrast, produced a single value, bit-identical across all schedules and runs (Han, 14 Jun 2026).

A second illustration compares CPU and GPU execution on Apple Silicon using PyTorch’s MPS backend. For probes in which only reduction order changed, both CPU and MPS produced multiple distinct float32 results, and the same $1024\times 1024$ matmul on CPU versus MPS differed by $1.46 \times 10^{-2}$ in output. The paper interprets this as a direct cross-device reproducibility gap rather than random jitter, since a fixed execution plan produced one value on both CPU and MPS (Han, 14 Jun 2026).

Against this background, mojo-deterministic is framed as a library for eliminating ambiguity at the reduction level rather than as a universal solution to all sources of numerical drift.

3. Kernel design and operational model of determinism

The library’s central design principle is deterministic reduction order. The paper states that the kernels are designed to be independent of thread count and chunking, which implies a fixed reduction tree or another prescribed accumulation order over the global index order (Han, 14 Jun 2026). Parallelism is permitted, but the combining phase is controlled rather than delegated to schedule-dependent atomics.

A typical implementation pattern is described in four stages. First, the input is partitioned deterministically by index range. Second, each worker computes a local deterministic reduction over its block, using a fixed sequential order and optionally compensated summation or pairwise summation. Third, each worker writes its partial result into a dedicated slot. Fourth, the partial sums are combined in a fixed, index-based order. The explicit avoidance of atomic accumulation is essential, because atomics would reintroduce schedule-dependent commit order (Han, 14 Jun 2026).

The paper also emphasizes careful handling of IEEE 754 and round-off, citing “deterministic patterns, such as adding partial sums in a fixed order or using compensated summation” and referencing Demmel and Nguyen’s work on reproducible summation (Han, 14 Jun 2026). The numerical objective is not solely error minimization. Rather, if $b$0 is the true sum and $b$1 the computed sum, determinism requires that $b$2 be fixed for a given input, even if several reduction orders would each satisfy a conventional backward-error bound such as

$b$3

The operational definition of determinism in the paper is bit-level. For a given input, a kernel should produce the same floating-point bit pattern for any thread count, chunking strategy, and schedule. The test evidence is aligned with this definition. On a 50,000-element ill-conditioned input, the deterministic implementations of summation, dot product, and risk aggregation matched an exact rational-arithmetic reference, whereas a naive parallel reduction over the same input produced 10 different floating-point results under different accumulation orders (Han, 14 Jun 2026).

The performance cost is described as local rather than global. The paper states that the overhead is a per-kernel overhead local to each operation, substantially lower than the global penalty incurred when torch.use_deterministic_algorithms(True) is enabled in PyTorch, where throughput typically drops by 2–5× and unsupported operators may cause the program to error out (Han, 14 Jun 2026). This localized-cost model is a defining part of the library’s design philosophy.

4. Integration with Mojo and the compilation stack

mojo-deterministic relies on Mojo’s systems-language properties. The broader survey describes Mojo as a Python-like systems language with native interoperability, low-level control over memory, and an MLIR compilation pipeline capable of targeting scalar, SIMD, multicore, and GPU execution from a single codebase (Han, 14 Jun 2026). In the library context, the relevant features are static typing, unboxed numerics, mutable locals, SIMD types, and multicore execution primitives such as parallelize, all of which allow the reduction order to be expressed explicitly rather than hidden behind a high-level runtime (Han, 14 Jun 2026).

The MLIR layer matters because determinism depends not only on algorithm design but also on code generation. The paper notes that preserving determinism requires the compiler to respect ordering semantics and avoid algebraic transformations that change associativity, such as -ffast-math-style reassociation or uncontrolled fused multiply-add behavior (Han, 14 Jun 2026). The article does not describe IR-level annotations, but it treats determinism as part of the algorithmic contract and assumes that compilation preserves that contract.

Related financial-AI work in Mojo illustrates the same implementation style in a different algorithmic setting. An exact nearest-neighbor study implemented all high-performance paths in Mojo and used single-threaded search, ahead-of-time specialization, contiguous flat-buffer storage, and compile-time vectorized distance computation. Important parameters such as feature dimension, SIMD width, leaf size, and $b$4 were comptime constants, enabling fully unrolled, branch-free kernels and a fixed instruction stream for a given build. That work verified equivalent prediction quality across four exact KNN implementations on 8 datasets, which supports the view that Mojo can host deterministic-friendly kernels when data layout, traversal order, and floating-point reduction order are all fixed (Han et al., 8 Jun 2026).

A broader reliability perspective comes from MojoBench, which characterizes Mojo as a language with static typing, manual memory management, SIMD support, and compilation to native machine code via MLIR. In that benchmark, compilation failures and type mismatches are deterministically observable, which is relevant because deterministic execution in Mojo often begins with making the control and type structure explicit enough that invalid behavior fails early rather than being tolerated dynamically (Raihan et al., 2024).

5. Financial workloads and usage boundaries

The paper that introduced mojo-deterministic surveyed four financial-AI workloads: Monte Carlo option pricing, LLM sentiment inference, multi-asset backtesting, and portfolio Value at Risk (Han, 14 Jun 2026). The library was not presented as the benchmarked engine for every operation in those workloads; rather, it was the reusable mechanism for the reduction stages that determine auditable outputs.

In Monte Carlo option pricing, the critical reduction is the sum of simulated payoffs. The surrounding Mojo benchmarks on Apple Silicon reported 291.3 ms for a pure Python loop over 1M paths, 16.6 ms for NumPy vectorized execution, 54.8 ms for Mojo serial, and 11.9 ms for Mojo parallelize, corresponding to 24.6× faster than Python for the parallel Mojo version (Han, 14 Jun 2026). The paper states that Mojo’s price matched analytic Black–Scholes to within 0.016. In this context, mojo-deterministic is intended for the payoff aggregation step when the result must be bit-identical across deployment configurations.

In LLM sentiment inference, the paper identifies reduction-sensitive components such as attention softmax denominators, layernorm statistics, and logit sums. It reports that Mojo+MAX can reach ~4.5× PyTorch+HuggingFace throughput at batch size 64 on an H100, based on external benchmarks (Han, 14 Jun 2026). mojo-deterministic is not claimed to provide deterministic implementations of all these operators; rather, the library is presented as the initial toolkit for the subset of reductions whose outputs directly determine trading decisions.

In multi-asset backtesting and portfolio VaR, the fit is more immediate. These workloads repeatedly aggregate exposures, P&L, and risk contributions across time, assets, or scenarios. The paper includes a worked risk-reconciliation example using the deterministic kernels in an auditable pipeline, and the earlier 100,000-contribution experiment is effectively a VaR-style aggregation test (Han, 14 Jun 2026).

The broader quantitative message is that the library is meant to be used at “audit-critical seams”. This suggests a selective deployment model: deterministic kernels where exact reconciliation matters, and conventional high-throughput kernels elsewhere.

6. Limits, misconceptions, and ecosystem context

The main limitation is coverage. The current library includes only three primitives—sum, dot product, and risk aggregation—and the paper explicitly identifies deterministic matrix multiplication, softmax and attention, layernorm and batchnorm, convolutions, and more complex reductions as future extensions (Han, 14 Jun 2026). The library therefore addresses a narrow but important subset of determinism problems.

A second limitation is portability. Mojo is described as still in beta (1.0.0 beta1), with expected breaking changes, especially around the GPU module and FFI, and the paper states that it did not benchmark Mojo's GPU compilation path end to end against CUDA (Han, 14 Jun 2026). Cross-hardware bit identity is treated as a goal rather than a solved property. The paper notes that guaranteed cross-hardware bit equality would require stable control over fused versus unfused multiply-add, rounding modes, and backend behavior across architectures (Han, 14 Jun 2026).

A common misconception addressed in the paper is that fixing random seeds is sufficient. Seed control only constrains random number generation; it does not constrain reduction order, atomic scheduling, asynchronous execution, or library heuristic kernel choice. mojo-deterministic therefore targets the arithmetic itself rather than the RNG (Han, 14 Jun 2026).

A broader ecosystem misconception would be to equate deterministic kernels with full-system reliability. MojoBench shows that reproducible evaluation in Mojo can be made practically deterministic through compile-to-native execution, hand-validated test suites, pass@1 scoring, and a fixed Seed = 42 during finetuning, but it also shows that determinism at the benchmark level depends on controlled tasks, decoding, and execution harnesses rather than on the language alone (Raihan et al., 2024). MOJOFuzzer makes the complementary point from the testing side: because Mojo is new and rapidly evolving, compiler and runtime bugs remain consequential. Its large-scale fuzzing study uncovered 13 previous unknown bugs, of which 9 were confirmed and patched, including a random-module bug in which random_si64 always returned a fixed value and a Python interop/NumPy bug involving module acquisition and extension calls (Huang et al., 11 Oct 2025). Those findings underscore that bit-exact reduction kernels do not by themselves eliminate defects in randomness APIs, interop layers, or compiler behavior.

Within that broader context, mojo-deterministic is best understood as a precise and deliberately scoped response to one class of failures: schedule-dependent floating-point reductions in financial AI. Its significance lies less in inventing new summation theory than in packaging deterministic numerical kernels inside a Python-like systems language that is explicitly aimed at reducing the long-standing research-to-production gap in quantitative finance (Han, 14 Jun 2026).