Capability map

LuxiEdge Capabilities

Numerical compute, quant systems, AI inference, scientific solving, and verifiable execution, from CPU and ARM systems to edge accelerators and H100-class GPUs.

LuxiEdge is an execution architecture rather than a single benchmark or function library. Its capabilities span receipt-attested numerical computation, quantitative risk pipelines, transformer inference, energy-oriented GPU research, scientific solving, and local execution on systems constrained by power, memory, connectivity, or thermal budget. Each capability below is labeled according to its current maturity and evidence.

How to read the labels

Every capability on this page carries one of six visible maturity labels. Research, Demonstrated, Historical, and Planned work is never represented as Available.

Available Implemented and currently usable.
Validated Passed a defined internal or independent validation protocol.
Demonstrated Supported by a working example or saved result.
Research Experimental architecture, kernel, or measured research path.
Historical Previously implemented or benchmarked, but not currently available in the active public build.
Planned Not implemented or not currently verified.

Deterministic Numerical Execution Available

LuxiEdge provides multiple numerical execution paths for workloads that need reproducibility, throughput, acceleration, or a documented balance among those requirements. Each path carries its own precision and reproducibility contract.

f64 CPU Gold Path Available

A controlled f64 execution path designed for the strongest documented reproducibility contract. The architecture uses compensated accumulation, defined reduction behavior, explicit SIMD implementations, and controlled floating-point contraction where required.

CPU SIMD Available

Explicit numerical paths exist for AVX2, AVX-512, and ARM Neon, with scalar or platform-specific fallbacks where supported. Actual throughput depends on operation, vector size, processor, compiler configuration, and precision.

Fast f32 execution Available

Throughput-oriented f32 modes trade the strongest cross-platform bit-identity contract for higher parallelism and speed. Results may still carry receipts, but those receipts belong to the selected mode and configuration.

Portable GPU execution Available Research

LuxiEdge includes portable GPU and CUDA-oriented numerical execution paths. GPU arithmetic and receipts must be described according to the exact backend, precision, driver, and configuration used.

Receipt generation Available

SHA-256 receipts provide byte-level fingerprints of canonical result data. A matching receipt establishes identity of the material that was hashed. Complete provenance also requires preserved inputs, engine version, execution mode, configuration, and backend information.

Execution-contract scope. The f64 CPU Gold Path provides the strongest documented cross-platform reproducibility contract. Fast f32 and GPU paths use configuration-specific contracts and must not be represented as bit-identical equivalents of the f64 Gold Path.

Quant, Risk & Statistical Compute Available Demonstrated

LuxiEdge includes receipt-enabled numerical and statistical building blocks for risk processing, model validation, scenario analysis, and reproducible quantitative workflows.

Market-risk and Greeks workflows

The quant engine includes a reproducible market-risk and Greeks pipeline with selectable deterministic and accelerated execution paths.

Streaming statistics

Welford-based online mean and variance support streaming observations without requiring the complete dataset to remain in memory.

Online covariance

Single-pass online covariance and sample covariance workflows support large historical or scenario datasets while preserving the selected receipt contract.

Scenario-batch processing

LuxiEdge can process historical, synthetic, and Monte Carlo scenario batches through receipt-enabled risk, statistical, and covariance workflows.

Replay and model validation

Final result vectors can be stored with execution metadata and receipts to support later replay, regression testing, and model-validation workflows.

Scope note: LuxiEdge processes scenario batches through receipt-enabled workflows. It is not presented as a complete universal Monte Carlo platform, and it does not currently claim to supply every component of a generalized Monte Carlo system such as random-process generation, distribution sampling, seed management, path generation, and convergence analysis.

AI Inference & Transformer Execution

Two separate paths with separate evidence. Correctness results and energy research results are never combined into one claim.

Faithful Model Execution Validated prototype Active engineering

LuxiEdge has executed the complete 28-layer Qwen2-7B model through its faithful CUDA path and has produced current CPU/CUDA and Hugging Face/CUDA correctness evidence under the defined protocol. Decoder computation runs on the GPU, while the current implementation still includes identified host-side work for embedding-row gathering and final greedy selection. Performance, energy, memory, and production-serving work remain active engineering areas.

Full-model Qwen2-7B CUDA execution

The complete 28-layer model executes through the faithful CUDA path.

CPU/CUDA correctness comparison

Current matched greedy-token comparison against the CPU gold reference under the defined acceptance protocol.

Hugging Face/CUDA correctness comparison

Current matched greedy-token comparison against the Hugging Face reference under the defined acceptance protocol.

Multi-request CUDA smoke testing

A multi-request smoke test exercises the CUDA path beyond a single prompt.

Device-resident decoder computation

Decoder-layer computation runs on the GPU in the current implementation.

Known host-side boundaries

Embedding-row gathering and final greedy selection currently run host-side and are identified engineering areas.

Active serving and performance work

Performance, energy, memory, and production-serving behavior on this path are active engineering areas, not published results.

Correctness evidence and the acceptance protocol: Proof: faithful correctness. The approximately 86% energy result belongs to the separate TRADE research path below, not to this faithful path.

TRADE Transformer Research Research with measured evidence

TRADE is a separate transformer research path focused on reducing data movement and measuring GPU board energy per processed token. Its results must remain separate from faithful-model correctness claims.

Online-softmax attention

Attention computation using an online-softmax formulation.

Reduced dense-score materialization

Research execution that reduces materialization of dense attention scores.

Full-layer fusion

Fused execution across transformer layer components in the research stack.

Device-resident multi-layer execution

Multiple layers execute device-resident to reduce host round trips.

H100 board-energy measurement

GPU board energy per processed token measured under load with NVML on the tested H100 configuration. Measured results →

Processed-stack throughput

Stack-token throughput measured in the same controlled comparison. Measured results →

Long-context memory scaling

Long-context research with linear-state scaling behavior. Scaling evidence →

WNSM null-space transport

Research into carrying auxiliary payloads through available representation space without a separate host-to-device side channel. Evidence packs →

Separate AUDIT and energy-oriented execution lanes

Reproducibility receipts belong to the separately defined audit lane; energy is measured on the energy-oriented lane.

TRADE results describe the tested research configuration. They are not automatically a drop-in chat-quality replacement for the faithful model path, and they must not be combined with faithful-path correctness results as though they came from one execution configuration.

Scientific & Engineering Solvers

LuxiEdge has been used to demonstrate numerical solving and reproducibility across orbital mechanics, root finding, physics-oriented transformations, and model-related numerical workloads. Formula support, complete solvers, and benchmarked implementations are labeled separately.

Lambert orbital solver Historical Demonstrated

A Lambert time-of-flight solver was historically implemented and benchmarked using an elliptical-orbit formulation and bisection root finding. The documented test solved for a semi-major axis of approximately 6065.83 km against an expected value of approximately 6066 km. Historical work also included tight-tolerance and multi-revolution batch solving. The referenced solver source is not present in the currently checked public branch, so this capability is not represented as presently available.

Historical evidence details
  • Direct time-of-flight calculation
  • Bisection root finding
  • Tight-tolerance solve
  • Multi-revolution batch solve
  • Eight-revolution swarm benchmark
  • Approximately 0.003% error in the documented test
  • Historical benchmark date: November 2025

Orbital-mechanics workloads Demonstrated

  • Kepler eccentric-anomaly calculations
  • Vis-viva orbital velocity
  • Hohmann-transfer calculations
  • Atmospheric-drag decay
  • J2 gravitational-harmonic expressions
  • Time-of-flight calculations

These workloads demonstrate numerical evaluation and reproducibility in orbital-mechanics contexts. Individual expressions do not, by themselves, constitute a complete mission-design system.

Model-related numerical transformations Available Demonstrated

  • GELU-related computation
  • SiLU / Swish
  • Softplus
  • Tanh
  • RMSNorm-related numerical work
  • Cross-entropy components
  • Input preprocessing
  • Output calibration
  • Intermediate-value checking
  • Receipt-enabled numerical sidecars

These transformations can support model preprocessing, post-processing, validation, calibration, and numerical sidecar workflows. They do not replace a complete inference framework.

This page does not claim to replace PyTorch, ONNX, TensorRT, vLLM, SGLang, or a full transformer runtime.

Edge & Embedded Compute

Implemented foundation Current device validation pending

LuxiEdge began with CPU-first, low-overhead numerical execution intended for systems constrained by power, memory, connectivity, or thermal budget. That foundation includes ARM64 support, explicit SIMD, local execution, offline operation, and receipt generation at the point of computation. Modern Raspberry Pi and Jetson validation remains a separate future evidence sprint.

ARM64 and ARM Neon

LuxiEdge includes ARM64-oriented execution and ARM Neon numerical paths for supported workloads. Current device-specific power, thermal, and sustained-performance claims require new physical-device measurements.

x86 edge and industrial systems

AVX2, AVX-512, and scalar execution paths support CPU servers, workstations, compact systems, and industrial deployment environments according to the selected build and workload.

Offline and disconnected execution

Numerical evaluation and receipt generation can operate locally without requiring a cloud round trip after the software and workload are deployed.

Local numerical sidecar

LuxiEdge can serve as a local numerical sidecar for sensing, navigation, scoring, preprocessing, post-processing, regression checking, and replay.

Potential deployment applications

Drones Robotics Remote monitoring Industrial systems Navigation Sensor calibration Local anomaly scoring Model preprocessing Model post-processing Offline verification

These are potential deployment applications for the architecture. Not every listed application is currently integrated or validated on a specific device.

Where It Runs

EnvironmentCurrent status
CPU servers and workstationsAvailable
x86 AVX2 systemsAvailable
AVX-512 systemsImplementation available; device-specific validation varies
ARM64 systemsAvailable where supported by current build
Raspberry Pi 5Current validation pending
Jetson OrinCurrent validation pending
Narrow CUDA numerical microkernelResearch
H100 transformer researchValidated research according to the exact path
Offline/disconnected environmentAvailable for supported numerical workloads

No theoretical or projected device figures are published here. Device-specific energy, battery, and thermal numbers require new physical-device measurements.

Large-Vector & API Execution Demonstrated

Four-million-element receipt-attested API demonstration

A saved end-to-end run submitted four million f64 values through the sin(x)*cos(x) evaluation endpoint, returned four million results, and produced a SHA-256 receipt. The recorded run completed in 1.732 seconds, approximately 2.31 million evaluated elements per second.

  • Elements: 4,000,000
  • Precision: f64
  • Expression: sin(x)*cos(x)
  • Elapsed time: 1.732 seconds
  • Throughput: approximately 2.31 million evaluated elements per second
  • Result receipt: recorded
  • Scope: end-to-end API request and response

This is an end-to-end API demonstration that includes payload construction, JSON transfer, server evaluation, response serialization, and receipt generation. It is not a kernel-only benchmark and is not the same test as the historical L4 experiment.

CUDA Numerical Microkernel Research

LuxiEdge contains a narrow CUDA path for an FP16 sin·cos numerical microkernel. The implementation includes device initialization, host-to-device transfer, FP16 conversion, PTX loading, configurable launch geometry, kernel execution, and device-to-host result transfer.

Scope: this microkernel is not evidence that the entire expression engine, quant pipeline, Lambert solver, or every scientific workload executes on the GPU.

Numerical Function Reference

Composable and receipt-enabled numerical evaluation across documented functions and workflows.

The currently checked narrow REST server supports these fixed expression strings:

sin(x)*cos(x) sin(x) cos(x) exp(x) ln(x) sqrt(x) x^2 x^3 erf(x) normcdf(x) normpdf(x) gamma(x)
Important limitation. The checked narrow REST server uses a fixed expression match and does not establish a complete general-purpose expression parser. Unknown expressions in that implementation are not evidence of broader parser support.

Evidence first

Every measured claim on this page links to the evidence hub. Statuses on this page are maintained against the internal capability register.