Skip to main content

Compute Backends

DynexConfig selects which hardware handles your computation. The primary backend for all production workloads is GPU — Dynex’s own neuromorphic computing chips operated across a distributed GPU network worldwide.

Overview

GPU — Dynex Neuromorphic Chips

This is the primary compute backend. Dynex operates thousands of neuromorphic GPU chips distributed globally. When you submit a job with ComputeBackend.GPU, it runs directly on this hardware.
The GPU network is Dynex’s core infrastructure — the Digital Twin of a neuromorphic quantum computing machine, running on GPUs at scale. This backend delivers:
  • Neuromorphic parallelism — thousands of chips work on your problem simultaneously
  • No qubit limits — problems of arbitrary size are supported
  • Always available — distributed, no single point of failure
  • Linear scaling — tested up to 64 × 10⁶ variables with linear resource growth
That’s it. Credentials are loaded from DYNEX_SDK_KEY and DYNEX_GRPC_ENDPOINT environment variables, or from a .env file.

Full production example


QPU — Quantum Processing Unit

For specialized QPU hardware models built on top of the Dynex GPU infrastructure. Requires specifying a QPU model.

Available QPU models

qpu_model is required when compute_backend=QPU. Omitting it raises ValueError.
QPU hardware has tighter constraints than GPU. Use num_reads in the range 1–100, annealing_time in 10–1000, and shots up to 5.

Coefficient bounds: qpu_max_coeff

The Apollo QPU hardware requires BQM coefficients (linear and quadratic) to stay within a bounded range. The sampler automatically checks and scales your model if needed:
If any coefficient exceeds qpu_max_coeff, the entire BQM is scaled down proportionally so the maximum absolute coefficient equals the threshold. The scaling is transparent — solutions are returned in the original variable space.
If your QUBO has large coefficients (e.g. penalty terms in CQM conversion), lower qpu_max_coeff to bring them into hardware range without manually rescaling the model.

QPU sampling example


CPU

CPU workers on the Dynex network. Useful for testing network connectivity and lightweight jobs before moving to GPU.

LOCAL

Runs the dynexcore binary locally without any network connection. No SDK key required. Intended for offline development and CI/CD pipelines.
Requires the dynexcore binary in a testnet/ directory. Download from GitHub releases.
LOCAL mode is for development only. Performance does not reflect the Dynex GPU network.

Configuration via environment variables

All DynexConfig parameters can be set via DYNEX_* environment variables. Constructor arguments always take priority.

Full DynexConfig reference

Backend selection by environment