⚠️ Experimental Pre-Release (2.0.0a1)

🌟A Functional, Compiler-Backed Framework for Scalable Evolutionary Computation🌟

🔥 News

• [2026-10-30] Released EvoX 2.0.0a1 (experimental pre-release) — EvoX is now a from-scratch functional rewrite on the EvoX Compiler (evoxc), imported as evox. [Release Notes]
• [2026-09-09] Released EvoX 1.4.0 - 🚀 A maintenance release with various fixes and improvements! [Release Notes]

Table of Contents

1. Experimental Pre-Release (2.0.0a1)
2. Overview
3. Key Features
4. Main Contents
5. Installation
6. Quick Start
7. Programming Model
8. What Changed Since 1.x
9. Documentation
10. Sister Projects
11. Community & Support
12. Citing EvoX

Overview

EvoX is a GPU-accelerated framework for scalable evolutionary computation. With a user-friendly programming model, it offers a comprehensive suite of 140+ Evolutionary Algorithms (EAs) and 240+ Benchmark Problems/Environments across the EvoX ecosystem — 30+ algorithms and 30+ benchmark problems built into this package, plus its sister libraries. For more details, please refer to our Paper and Documentation / 文档.

EvoX 2.0 keeps that catalogue but changes the machinery: every algorithm, problem, monitor and metric is plain Python — frozen configuration dataclasses, tensor-valued state, and init/step functions — and the component model's only compile site is StdWorkflow, which traces one step graph through evoxc and runs it in a loop. The same program therefore runs on a pure-NumPy interpreter or on a compiled IREE / TVM / XLA backend for CPU and GPU by changing one argument.

Key Features

🚀 Compiled, Not Interpreted

• One program, several execution modes: backend="numpy" (default, no toolchain needed), "iree" (compiled CPU / CUDA / ROCm), "tvm" (compiled CPU) or "xla" (PJRT). Only StdWorkflow(backend=..., device=...) changes; algorithm and problem configs stay identical.
• Compile once, loop on the device: StdWorkflow builds the step graph a single time and feeds outputs back as inputs, instead of re-tracing per generation.
• GPU-class throughput: in the committed harness benchmarks/evox_vs_torch/, the compiled XLA-CUDA backend runs the same PSO/DE cells 1.16–1.45× faster per step than the 1.x torch implementation on an RTX A6000, at identical convergence (BENCHMARK_RESULTS.md).

🌐 All-in-One Solution

• 32 distinct algorithm classes (27 single-objective names, one of which — VirtualLoRAES — aliases VirtualES, plus 6 multi-objective names) covering DE, ES, PSO, the training-free virtual ES family, NSGA-II/III, MOEA/D, RVEA, RVEA-a and HypE, with 140+ algorithms available across the EvoX ecosystem.
• 30+ benchmark problems: 10 basic numerical problems (9 classic functions plus a shift/affine wrapper), DTLZ1–7, all 12 CEC2022 functions, and virtual (Gaussian-noise neuroevolution) problems, with 240+ benchmark problems/environments across the ecosystem.
• Host-side hyperparameter optimization through evox.problems.hpo_wrapper (see What Changed Since 1.x for why it is host-side).

🛠️ Easy-to-Use Functional Design

• Configuration is data: every component is a frozen dataclass, usually built by a make_* constructor (make_pso(...), make_cma_es(...), make_nsga2(...)).
• State is data: init(config, key) returns a pytree of tensors, step(config, state, evaluate) returns the next one — serialize it, diff it, replay it.
• Explicit randomness: stateless keys (evox.key(seed)) live inside the state, so a single integer seed reproduces a whole run; there is no global seed.
• Plain functions everywhere: algorithms, operators and metrics are ordinary Python you can test and reuse — no framework base class to inherit.

📊 Flexible Visualization & Metrics

• Ready-to-use analysis: EvalMonitor records fitness, elite and population histories plus auxiliary channels, and EvalMonitor.plot() returns an interactive Plotly figure.
• Multi-objective metrics: gd and igd (with gd_plus/igd_plus) plus hv in evox.metrics.
• Real-time data streaming: the tailored .exv format (evox.vis_tools) serializes runs for fast, incremental loading.

Main Contents

For a comprehensive list and detailed descriptions, check the Tutorial, the API Reference, and src/evox/DESIGN.md for the binding design specification.

Installation

EvoX 2.0 requires Python ≥ 3.11. Its only runtime dependencies are evoxc >= 0.1.0 and numpy; every compiled backend is an opt-in extra, so the default install runs the pure-NumPy backend immediately.

Which version should I install?

The distribution name is evox for both lines. PyPI does not pick a pre-release unless you ask for one, so nothing changes for users on the stable line:

# stable 1.x line — unaffected by these pre-releases
pip install "evox[default]"

To try the 2.0 pre-release without disturbing that, use a separate virtual environment:

python -m venv .venv-evox2 && . .venv-evox2/bin/activate   # Windows: .venv-evox2\Scripts\activate
pip install --pre evox==2.0.0a1
# or, tracking every 2.0 pre-release from this point on:
pip install "evox>=2.0.0a1"

Pin the exact version (evox==2.0.0a1) if you need reproducibility: 2.0 is a pre-release line and its API may change between pre-releases.

Backends and optional extras

pip install --pre "evox[vis]"          # plotting on top of the pre-release
pip install --pre "evox[iree]"         # IREE: compiled CPU / CUDA / ROCm
pip install --pre "evox[compilers]"    # IREE + TVM

The compiled backends come from the compiler's own extras; evoxc[iree] / evoxc[tvm] / evoxc[compilers] are the equivalent spellings when you manage evoxc directly. The XLA backend has no pip extra: it loads a PJRT plugin that you supply, and evoxc finds it through the EVOXC_PJRT_PLUGIN environment variable, which must be exported before the process starts:

export EVOXC_PJRT_PLUGIN=/path/to/pjrt_c_api_cpu_plugin.so

From source

git clone https://github.com/EMI-Group/evox.git
cd evox
pip install -e .

src/evox and src/evox_ext are PEP 420 namespace packages, so uninstalled checkouts need PYTHONPATH=src (the runnable scripts under examples/ add it for you). Contributor setup, the test venv and the suite layout are documented in the Developer Guide.

Quick Start

A single-objective run — PSO on the 10-D Sphere function — uses the default NumPy backend and needs nothing but evoxc and NumPy:

from evox import EvalMonitorConfig, StdWorkflow
from evox.algorithms import make_pso
from evox.problems import Sphere

dim = 10
workflow = StdWorkflow(
    algorithm=make_pso(100, lb=[-100.0] * dim, ub=[100.0] * dim),
    problem=Sphere(),
    monitor=EvalMonitorConfig(),
    opt_direction="min",
    num_generations=50,
    backend="numpy",  # "iree" / "tvm" / "xla" compile the very same program
)
workflow.run(50, seed=42)                     # init + 50 generations

print(workflow.monitor.get_best_fitness())    # optimum of Sphere is 0.0
workflow.monitor.plot()                       # Plotly figure (needs `evox[vis]`)

The run prints the best fitness found after 50 generations (the Sphere optimum is 0.0):

0.027914267033338547

A multi-objective run — NSGA-II on 2-objective DTLZ2 — driven generation by generation, which is the same loop run() performs:

import numpy as np
from evox import EvalMonitorConfig, StdWorkflow
from evox.algorithms import make_nsga2
from evox.problems import DTLZ2

dim = 5
workflow = StdWorkflow(
    algorithm=make_nsga2(pop_size=40, n_objs=2, lb=[0.0] * dim, ub=[1.0] * dim),
    problem=DTLZ2(d=dim, m=2),
    monitor=EvalMonitorConfig(),
    opt_direction=["min", "min"],   # one direction per objective
    num_generations=50,
)

state = workflow.init(seed=42)
state = workflow.init_step(state)
for _ in range(49):
    state = workflow.step(state)
workflow.flush()                                 # hand the last generation to the monitor

pareto = workflow.monitor.get_pf_fitness()       # (n_pareto, n_objs), un-negated
# the DTLZ2 Pareto front is the unit sphere, so |f| == 1 for every optimal point
print(pareto.shape, np.abs(np.linalg.norm(pareto, axis=1) - 1.0).max())

It prints the size of the approximate Pareto front, then the largest deviation of its points from the true unit sphere:

(350, 2) 0.005379677

Programming Model

EvoX 2.0 is functional end to end, in three steps:

1. Describe the components with frozen configs. make_pso(...), make_nsga2(...), Sphere(), DTLZ2(d=5, m=2), EvalMonitorConfig() all return dataclasses holding static hyperparameters (Python scalars and flat float tuples). Configs are never mutated and never traced.
2. Let StdWorkflow own the loop. StdWorkflow(algorithm=..., problem=..., monitor=..., opt_direction=..., num_generations=..., backend=...) builds one step graph through evoxc and runs it in a same-device loop: wf.run(n, seed=42) for the whole run, or wf.init(seed=...) → wf.init_step(state) → wf.step(state) → wf.final_step(state) when you want to drive it yourself.
3. Read results from the monitor. The workflow keeps a host-side EvalMonitor at wf.monitor (get_best_fitness(), get_best_solution(), get_fitness_history(), get_pf_fitness(), plot()), so nothing has to be pulled out of a compiled graph by hand.

The component contract is equally plain: an algorithm module exposes init(config, key) -> state and step(config, state, evaluate) -> state (optionally init_step/final_step), a problem exposes evaluate(config, state, candidates), and a monitor exposes init/step/record_*. Randomness is a stateless key — evox.key(seed) and evox.random.* — stored in the state and advanced there, so runs are reproducible without any global seed. Internally everything minimizes; opt_direction="max" (or a per-objective list) makes the workflow flip signs. Only algorithms, problems and the step graph live in a trace: monitors, metrics and HPO stay host-side.

What Changed Since 1.x

EvoX 2.0 is a rewrite, not a wrapper: import evox loads the functional package and touches neither the 1.x code nor PyTorch. The 1.x object-oriented API — ModuleBase, Parameter/Mutable, evox.core.compile/vmap/use_state, class-based components, the enable_distributed multi-rank switch and the Triton kernel package — has been removed; the evox import name is kept, but it now resolves to the functional 2.0 tree, and there is no deprecation shim.

Not in this pre-release yet (each was deliberately dropped rather than half-ported):

• No distributed multi-rank workflow. Every workflow is single-device; run one process per GPU or scale with your own launcher.
• No Brax / MuJoCo Playground / supervised-learning problems. Only the virtual (Gaussian-noise neuroevolution) problems are ported, so there is no reinforcement-learning environment integration yet.
• No ParamsAndVector / torch.nn interop. Virtual problems take pre-flattened parameter shapes and layer specs instead of a torch.nn.Module.
• No Triton kernels. The hand-written CUDA kernels had no compiler analogue; the virtual-population noise they accelerated is regenerated in-graph by a deterministic splitmix64 + Box-Muller implementation.
• No torch.compile / vmap internals. There is nothing to decorate: the workflow compiles one graph with evoxc.build and runs it, and operators are already batched tensor functions.
• HPO is host-side, not a Problem. HPOProblemWrapper runs a fresh inner StdWorkflow per candidate on the host instead of nesting a compiled workflow inside an outer trace (which the compiler cannot do); drive it with random_search or any external optimizer. See examples/hpo/ for working scripts.

If you are porting 1.x code, read the migration guide: it maps every removed API to its replacement.

Documentation

• Installation guide — English · 中文
• Tutorial (7 parts) — English · 中文
• Developer guide (architecture, custom algorithms/problems/monitors, contributor setup) — English
• Advanced guide (backends, operators, metrics, visualization/.exv, HPO, extensions) — English
• API reference — English
• Examples — English, plus runnable scripts in examples/ (quickstart.py, examples/hpo/)
• Design and history — src/evox/DESIGN.md (binding spec), REFACTOR_REPORT.md (1.4 → 2.0 refactor report), benchmarks/evox_vs_torch/ (backend comparison harness and results)

Sister Projects

• EvoRL: GPU-accelerated framework for Evolutionary Reinforcement Learning. Check out here.
• EvoGP: GPU-accelerated framework for Genetic Programming. Check out here.
• EvoMO: GPU-accelerated library for Evolutionary Multiobjective Optimization (EMO). Check out here.
• TensorNEAT: Tensorized NeuroEvolution of Augmenting Topologies (NEAT) for GPU Acceleration. Check out here.
• TensorRVEA: Tensorized Reference Vector Guided Evolutionary Algorithm (RVEA) for GPU Acceleration. Check out here.
• TensorACO: Tensorized Ant Colony Optimization (ACO) for GPU Acceleration. Check out here.
• EvoXBench: A real-world benchmark platform for solving various optimization problems, such as Neural Architecture Search (NAS). It operates without the need for GPUs/PyTorch/TensorFlow and supports multiple programming environments. Check out here.

Together with EvoX, these and the other EvoX-related libraries published by the EMI-Group form an ecosystem providing 140+ algorithms and 240+ benchmark problems/environments.

Stay tuned - more exciting developments are on the way! ✨

Community & Support

• Join discussions on the GitHub Discussion Board.
• Connect via Discord or QQ group (ID: 297969717).
• Visit Offical Website.

Citing EvoX

If EvoX contributes to your research, please cite it:

@article{evox,
  title = {{EvoX}: {A} {Distributed} {GPU}-accelerated {Framework} for {Scalable} {Evolutionary} {Computation}},
  author = {Huang, Beichen and Cheng, Ran and Li, Zhuozhao and Jin, Yaochu and Tan, Kay Chen},
  journal = {IEEE Transactions on Evolutionary Computation},
  year = 2024,
  doi = {10.1109/TEVC.2024.3388550}
}

License Notice

EvoX is licensed under the GNU General Public License v3.0 (GPL-3.0). For full terms and conditions, please refer to the LICENSE file.