Luxi has two engines. LuxiQuant is a deterministic numerical engine, ready for pilot. The Luxi Inference Engine runs transformer workloads in stages: prefill and decode. Everything below explains what each engine does, and how energy and determinism are measured against explicitly defined units.
LuxiQuant Risk State Engine accepts a customer-supplied scenario-by-position numerical matrix and maintains deterministic incremental risk state under named contracts. CPU is canonical for hierarchical totals, empirical VaR/ES, and tail state; optional CUDA authenticates canonical tiles and does not price or generate scenarios. It is available through a paid confidential evaluation. LuxiBook remains the separate downloadable public option-pricing and receipt demonstration.
The Luxi Inference Engine runs transformer workloads - the kind of models behind modern AI assistants - in two stages:
Reads the prompt. This stage has an independent measured baseline and a stronger internal matched result, kept clearly separated as research evidence.
Produces output tokens. This stage matches the reference next-token result under the defined numerical audit; the next serving-readiness milestone is locking end-to-end quality, throughput, and board energy.
Energy and determinism are always measured against explicitly defined units - for example, GPU-board joules per prefill position, or a byte-identical output hash under a documented configuration. A number without its unit and scope is not a claim we make.
The largest reproducibility risks typically arise from order-sensitive reductions, fused versus unfused operations, different math-library implementations, precision changes, compiler optimization choices, backend-specific execution, and uncontrolled concurrency or state.
When those factors are uncontrolled, small rounding differences compound - and the same code with the same input can produce different low-order bits across runs, builds, or machines.
This breaks:
Without receipts, yesterday's results can't be reproduced - by anyone. LuxiQuant's receipts make reproduction routine.
Regulators require predictable behavior.
Receipts pin down the exact run, so a failure can be replayed and fixed instead of guessed at.
Lu(x)iEdge controls the factors that cause drift, so supported workloads can be reproduced and compared byte-for-byte under the documented conditions.
Operations follow the documented engine path rather than an uncontrolled reduction order
Inputs, modes, and output serialization are normalized for reproducible comparison
Rust reduces common classes of memory-safety risk
Receipts allow byte-level output comparison when the same documented conditions are reproduced
Determinism claims apply to the documented engine version, execution mode, precision, canonical input, and supported/tested platform combination.
Some deterministic engines - physics libraries such as Box2D and Rapier are well-known examples - accept reduced acceleration in exchange for reproducibility. For games, that tradeoff works.
For quant finance pipelines, or safety-critical systems that need both real-time performance and reproducible evidence, giving up acceleration is a hard price to pay. (Luxi Book itself does not do Monte Carlo or VaR - it prices a supplied option book.)
Lu(x)iEdge is designed to preserve defined reproducibility properties while using accelerated CPU and GPU paths. Performance and supported behavior depend on backend, precision, operation, and workload.
The public Luxi Book binaries today are macOS ARM64 (CPU), Linux x86_64 (CPU), and Linux x86_64 CUDA. There is no macOS GPU Book binary, and Metal, Vulkan, RISC-V, and WASM are not Luxi Book backends - the table below describes the broader numerical-engine research surface only.
| Backend | Status |
|---|---|
| CPU with SIMD (x86-64) | Available and tested in the evaluated environments |
| ARM64 and ARM Neon | Internal benchmark: direct-engine, no-service-overhead run with the receipt contract. Independent validation next. |
| NVIDIA CUDA (H100 tested) | Available and tested in the evaluated environments |
| Vulkan | Available but experimental |
| Apple Metal | Implemented and internally exercised through the portable wgpu GPU path on macOS. Same-hardware reproducibility follows the declared GPU path and receipt contract, scoped to the declared path. |
| Bare-metal-capable / no_std core path | Implemented in source; hardware run scheduled. |
| RISC-V | Historical work reported; re-validation on the roadmap. |
| WASM | On the validation roadmap. |
Platform evidence note: Edge and constrained ARM systems are deployment environments for the LuxiQuant engine, not a separate product. Implemented means a supported code path exists. Internal benchmark means LuxiEdge has exercised that path in its own testing or demonstration. Historical work means earlier results are reported with re-validation on the roadmap. Validation roadmap means the evidence run is planned.
TestFort numerical-engine footnote (December 2025, not Luxi Book): in the defined H100 evaluation, the tested seven-function workload sustained 286.94 billion aggregate operations per second.
Every Lu(x)iEdge response includes a SHA-256 hash of the output. Store the hash at computation time; re-run the same canonical input later under the same documented engine version, mode, and configuration, and a matching hash confirms the output bytes are identical. A complete reproducibility record should also preserve the canonical input, engine version, execution mode, precision, backend, and configuration - an output hash alone does not prove who ran the computation or which input produced it.
$ ./luxi-book price --book example_book.csv --out report.csv # writes report.csv (prices + five Greeks) # and receipt.json with the run's signed receipt $ cat receipt.json | grep sha256 "sha256": "4a21b1e708fa5c69..." # re-run the same book under the same binary and inputs, # then compare the SHA-256: a match confirms identical output bytes
For a fixed workload, faster completion can reduce total board energy when the increase in power is smaller than the reduction in execution time. This must be measured for each workload - race-to-idle is not an automatic guarantee of facility or cooling savings.
The engine ships as a single compact binary that runs locally with no cloud dependency. On supported builds it selects an appropriate backend for the host - SIMD on CPU, CUDA on tested NVIDIA GPUs - with minimal configuration. Supported operating systems, GPU APIs, binary size, and startup behavior are documented per release with the published downloads.
Most benchmarks test isolated operations. That is like playing a single note on a piano.
The Art of Fugue is a defined reproducibility workload combining several numerical expressions and execution patterns - three concurrent "voices" of conflicting intensity: trigonometric identities, logarithmic decay, and discontinuous transcendentals. Its purpose is to expose drift and compare receipts across documented implementations and environments.
The output is captured as a single SHA-256 hash, so any drift between documented runs shows up as a hash mismatch. The public GitHub repository contains the workload definition and the published receipts.
The Art of Fugue covers the core trigonometric and transcendental function suite. Separately, TestFort QA Lab independently evaluated a defined deterministic numeric workload, including the statistical function suite and GPU endurance testing (December 2025); that evaluation did not certify every function, platform, backend, or expression.