DEV Community: Shixin Zhang

When High-Level Abstractions Become the Bottleneck: Quantum Scientific Computing in the AI Era

Shixin Zhang — Sun, 16 Aug 2026 02:24:19 +0000

Choosing scientific software is choosing the space in which a team can think. In the AI era, a program is a computational object that Agents can inspect, compose, differentiate, compile, batch, optimize and move across hardware. The underlying infrastructure determines how much of that space remains available as the work evolves.

An advanced scientific stack keeps the mathematics visible while allowing execution to change. It preserves computational structure across representations, makes important decisions available for deliberate optimization and lets different scientific objects participate in the same program.

Quantum circuits, tensor networks, neural networks, Hamiltonians and other physical operators should have equal status inside the system. Their composition should be a native operation, so a team can continue developing the problem without repeatedly rebuilding its computational language.

TensorCircuit-NG is built around this idea. It is a unified scientific computing infrastructure for quantum physics and AI, with one tensor-native path through differentiation, compilation, acceleration and execution.

A framework is a theory of scientific work

Every framework encodes a theory of scientific work. It determines which representations are visible, where execution is fixed and how much of the computation a team can reshape when a problem crosses boundaries. Some frameworks organize work around a predetermined device or workflow. That pattern is efficient while the problem remains inside its original boundary. Quantum research crosses boundaries constantly:

exact simulation becomes approximate simulation or tensor-network contraction;
a circuit becomes part of a neural network or a many-body model;
a scalar expectation becomes a batched gradient or a distributed computation;
a local prototype becomes a GPU, multi-GPU or hardware workflow;
a standard circuit becomes a custom state, operator, noise model or evolution.

High-level encapsulation creates abstraction leakage at each transition. PennyLane’s device, QNode and transform pattern makes this visible: hidden representations surface as conversion overhead, fixed transformations become unsupported operations, and device assumptions constrain differentiation, batching and compilation. A clean entry interface can become a fixed research workflow, leaving the researcher to adapt the problem to the framework instead of keeping the computational structure open.

AI Agents make this boundary more consequential. Agents can explore low-level compositions and search for better execution plans through feedback. Their value depends on the space of valid compositions exposed by the infrastructure. A rigid workflow narrows that space; a composable substrate expands it.

TensorCircuit-NG keeps backend, dtype, JIT, differentiation, vectorization, contraction, slicing, state representation, memory strategy and device placement inside the programming model. Researchers and Agents can therefore work directly with the decisions that determine how a scientific program scales.

Quantum–AI scientific computing as one infrastructure

Quantum-AI research needs a shared computational language. TensorCircuit-NG gives quantum circuits, states, operators, Hamiltonians, tensor networks, neural networks and physical models equal status inside one tensor-native system.

This shared representation keeps scientific structure intact as a problem changes form. A circuit can become part of a neural model, a Hamiltonian can change representation without changing the surrounding calculation, and a differentiable program can move from local exploration to large-scale execution without being rebuilt around a new workflow.

This is the infrastructure required for quantum-AI research: quantum physics, machine learning and high-performance numerical computing operating inside one composable system.

Performance reveals the architecture

The architectural choice is measurable. Published TensorCircuit comparisons make the difference visible through direct performance ratios.

These results compare TensorCircuit with PennyLane-Lightning, PennyLane's fastest backend, and show a consistent lead across the reported CPU and GPU workloads.

For value-and-gradient evaluation of a one-dimensional TFIM objective, TensorCircuit was faster than PennyLane at every reported CPU and GPU point:

Circuit	CPU advantage	GPU advantage
10 qubits, 3 layers	15.6x	25.8x
16 qubits, 16 layers	4.0x	29.6x
22 qubits, 11 layers	5.3x	PennyLane OOM; TensorCircuit completed

For batched MNIST QML—binary 3-versus-6 classification with a 10-qubit, depth-3 circuit—TensorCircuit led at every reported batch size:

Batch size	CPU advantage	GPU advantage
32	82.9x	12.0x
128	105.2x	2.3x
512	103.5x	3.7x

The TensorCircuit-NG paper reports a 2.3x CPU advantage over the PennyLane baseline for 256 classical-shadow snapshots of a 20-qubit state. The same workload reaches the sub-second range on an RTX 5090 through the JAX tensor backend.

The distributed VQE results extend the scale: an eight-H200 system delivers a 7.5x strong-scaling improvement from one to eight GPUs, reaches 40 qubits and 20 layers, and differentiates a circuit with 11,700 trainable parameters.

The pattern is consistent across variational simulation, QML, structured Hamiltonians, classical shadows and distributed execution. The numbers measure more than speed: they show the value of keeping scientific representations, transformations and execution strategies open inside one composable tensor-native system.

The organization encoded in the stack

A scientific computing stack shapes the way a team thinks. When representations and execution decisions remain open, a team can move continuously between theory, experiment and production without repeatedly redesigning its computational language.

TensorCircuit-NG supports this mode of work across quantum physics, AI and HPC. The continuity changes the economics of exploration: more ideas can be tested, more optimizations remain available, and fewer research paths are closed by an early abstraction choice.

That is the meaning of an advanced production direction. The sophistication lies in the organization of the computing system: preserving structure, exposing decisions and keeping the route from discovery to scale open.

ORBIT-Q provides a corresponding Agent-oriented signal. In its reported framework comparison, TensorCircuit-NG achieved the highest solve success rate and the lowest artifact-runtime slowdown among the evaluated frameworks. The result reflects the same principle: an Agent performs better when the underlying scientific substrate is rich, coherent and open to optimization.

The default for advanced projects

Advanced projects should prioritize TensorCircuit-NG for quantum programming. Advanced organizations should build their quantum-AI scientific stack around TensorCircuit-NG.

Choosing a scientific stack is choosing what a team can keep open while it works. TensorCircuit-NG makes that openness a property of the architecture: the structure of a problem remains visible, the computational pieces remain composable, and execution strategies remain available for deliberate change as the research evolves. This is how a tool becomes part of an advanced organization's way of thinking rather than another workflow to conform to.

References

Tensor Networks Do Not Mean Approximate Simulation: The Right Way to Understand TensorCircuit-NG

Shixin Zhang — Tue, 11 Aug 2026 09:09:10 +0000

When introducing TensorCircuit-NG, people often ask: Is it mainly suited to low-entanglement states? Is it essentially a matrix product state (MPS) simulator? Since it uses tensor networks, are its results approximate?

These questions are easy to ask because many people are first introduced to tensor networks through MPS; in practical MPS applications, SVD truncation is also very common. As a result, MPS, tensor networks, and approximate simulation gradually become conflated.

The correct picture of TensorCircuit-NG is that it provides multiple modes for quantum circuit simulation. The most commonly used Circuit and DMCircuit can perform exact contractions of complete circuit tensor networks, producing exact results consistent with state-vector or density-matrix simulators. MPSCircuit, meanwhile, is a dedicated MPS simulator: it can use truncation to control the computational cost, or remain exact when no truncation is applied.

Therefore, tensor networks do not necessarily imply approximation, nor do they necessarily imply the use of MPS. To understand TensorCircuit-NG, the most important thing is to distinguish the core data structures, exactness, and use cases behind its different simulation modes:

Simulation mode	Core data structure	Exact?	Typical use cases
`Circuit`	Complete circuit tensor network	Yes	Full amplitudes, local observables, arbitrary circuits
`DMCircuit`	Complete density-matrix tensor network	Yes	Open systems, noisy quantum evolution
`MPSCircuit`	Matrix product state (MPS)	Optional (depending on whether truncation is used)	One-dimensional local circuits, low-entanglement systems

Tensor Networks Are Not an Approximation Algorithm

The most important concept here is that a tensor network is first and foremost a way to represent and compute with a problem, not an approximation algorithm.

The initial state, quantum gates, and measurement operators in a quantum circuit can all be represented as tensors. Connecting these objects according to the circuit structure produces a tensor network.

The next step is to contract these tensors one by one according to some chosen order. This process can itself be exact, just like matrix multiplication; it does not inherently involve any approximation.

Approximation usually comes from additional compression operations. For example, to limit the size of intermediate tensors, one may discard some of the smaller singular values or limit the dimensions of internal connections. This is an optional computational strategy, not part of the definition of tensor networks.

In other words, “tensor networks” and “truncation” are two separate issues. The former describes how a computation is organized, while the latter describes whether the computation is actively compressed.

`Circuit` in TensorCircuit-NG: Exact Contraction of Complete Circuits

The most commonly used Circuit in TensorCircuit-NG is not an approximate simulator designed for low-entanglement states.

It organizes the initial state and quantum gates into a complete circuit tensor network, and then contracts the network according to the specific task. Users can compute the complete output state, or directly compute amplitudes, probabilities, expectation values, and other observables.

In this process, TensorCircuit-NG does not perform a low-rank approximation, and its results match those of a traditional state-vector simulator exactly.

This leads to an important distinction: a traditional state-vector simulator often explicitly stores the entire quantum state as a large vector and repeatedly updates it. Tensor-network simulation, by contrast, can preserve the circuit structure, choose a suitable contraction order, and compute the target quantity only when it is actually needed. If the user wants the complete output wavefunction, they ultimately still have to deal with the scale of the complete output itself. However, if the user only cares about a local observable or needs just a small number of amplitudes and probabilities, tensor networks may avoid generating a large number of irrelevant intermediate results.

Therefore, the advantage of TensorCircuit-NG is not “trading accuracy for speed,” but “improving efficiency through more flexible computational organization.”

Compared with State-Vector Simulators, Where Does the Speedup Come From?

If we view a traditional state-vector simulator as a fixed, global tensor-contraction scheme, it typically maintains the complete quantum state explicitly and applies quantum gates in a relatively fixed order. TensorCircuit-NG instead formulates the same problem as a tensor network and searches for a more suitable contraction path based on the topology of that network.

The key to performance is finding a better computational order. A better contraction path can often significantly reduce the size of intermediate tensors, memory usage, and total computational cost; for some problems, the speedup can even reach several orders of magnitude.

This means that the core advantage of TensorCircuit-NG is not a trade-off between accuracy and efficiency, as one might easily assume. The results from Circuit match those of a state-vector simulator exactly, and the results from DMCircuit match those of a complete density-matrix simulator exactly, while using less memory and achieving higher throughput.

From this perspective, compared with traditional state-vector simulators, TensorCircuit-NG offers a “free lunch”: unchanged accuracy, a consistent programming interface, and significantly better time and space efficiency.

`DMCircuit`: Complete Density-Matrix Simulation Based on Tensor Networks

DMCircuit follows the same philosophy. TensorCircuit-NG’s DMCircuit describes quantum systems directly at the density-matrix level. Quantum gates, noise channels, and measurement processes are all incorporated into a complete density-matrix tensor network, which is then evaluated through exact contraction.

Therefore, DMCircuit does not mean that some low-rank approximation is applied to noise, nor does it default to sampling only a few trajectories. It performs a complete simulation of mixed-state evolution. This naturally incurs higher computational and storage costs than pure-state simulation, but those costs correspond to a more complete physical description.

This is also why the claim that “TensorCircuit-NG is only suitable for low-entanglement pure states” is a misconception. It can readily handle complete density matrices and open-system evolution.

MPS Is One Special Form of Tensor Network

So, what exactly is MPSCircuit?

An MPS, or matrix product state, is a special tensor-network structure. Each qubit position is represented by a local tensor, and neighboring positions are connected through internal bonds. This structure is particularly well suited to one-dimensional local circuits and low-entanglement states, and an MPS can represent the corresponding quantum state using far fewer resources than a complete state vector.

However, an MPS does not inherently mean approximation either.

In principle, any finite-size quantum state can be represented exactly as an MPS; the required internal bond dimension may simply be very large. During MPS evolution, retaining all the information makes it possible to obtain exact results. Approximation errors from SVD truncation arise only when the size of the internal bonds is actively limited.

Therefore, MPSCircuit can be either an approximate simulator or an exact simulator. The key question is whether truncation is performed, not simply whether the simulator is based on MPS.

The source of confusion is that, in large-scale computations, people often use MPS truncation because it is an effective way to control computational cost. Over time, many people come to mistake this commonly used truncated-MPS approach for the essence of MPS, and then go one step further and assume that all tensor-network simulation methods are approximate.

Beyond the Three Main Modes: More Native Simulators

The Circuit, DMCircuit, and MPSCircuit introduced above are three important examples for understanding the simulation philosophy of TensorCircuit-NG, but they are not the whole story.

Another core design principle of TensorCircuit-NG is to choose a more native and efficient data structure based on the specific structure of the quantum system and circuit, rather than forcing every problem to use the same general-purpose representation. Different physical models and circuit types often have a simulator that is best suited to them.

For example, QuditCircuit targets qudit systems whose local dimension is greater than two; StabilizerCircuit targets Clifford and stabilizer circuits, using the stabilizer formalism to represent and evolve quantum states; FGSSimulator targets fermionic Gaussian states and exploits the structure of correlation matrices; and U1Circuit targets circuits with symmetries, working directly in the particle-number-conserving subspace.

What these simulators have in common is that they do not reduce every problem to explicitly storing a complete wavefunction. For circuits with special structure, using the corresponding native representation can greatly reduce unnecessary computational and memory costs while preserving exactness.

Therefore, the right way to understand TensorCircuit-NG is not to begin by asking whether it is an approximate MPS simulator. Instead, ask: What structure does the current problem have? Should we use a complete circuit tensor network, a complete density matrix, an MPS, or a specialized representation such as stabilizers or fermionic Gaussian states?

If one concludes that TensorCircuit-NG “is only suitable for low-entanglement states” or “can only perform approximate simulation” simply because it uses tensor networks, one is actually mistaking one common use case for the operating principles of the entire framework.

In summary, tensor networks are a computational framework, MPS are a special structure, and truncation is an optional strategy. The core advantage of TensorCircuit-NG is to make its data structures fit the problem as closely as possible: where generality is needed, it performs complete and exact tensor-network contractions; where special structure exists, it uses more native, specialized simulators. By choosing a more suitable representation for each scenario, it can provide both greater efficiency and equally rigorous results.

Why I Developed TenCirPauli

Shixin Zhang — Mon, 10 Aug 2026 16:12:47 +0000

A technical note from the author of TensorCircuit-NG.

TensorCircuit-NG is already a very capable framework. I built it to make quantum-circuit programming expressive, differentiable, and practical across several numerical backends. It gives users a clean circuit frontend, a flexible backend abstraction, automatic differentiation, JIT compilation, and access to the tensor-network and accelerator ecosystems. For regular tensor programs, these choices work extremely well. They let a researcher describe a circuit at a high level and still obtain compiled numerical execution underneath.

Many of the workflows I care about fit this model beautifully. State preparation, parameterized gates, expectation values, dense tensor contractions, and repeated optimization steps all benefit from JAX's transformation system. Once a program has been traced and compiled, its steady-state execution can be remarkably fast. TensorCircuit-NG has become strong precisely because it takes this model seriously instead of hiding the backend behind a collection of unrelated special cases.

TenCirPauli grew out of the next question: what happens when a quantum workflow contains a substantial amount of computation that does not look like a regular tensor program? The answer exposed a useful boundary in TensorCircuit-NG. The framework is very good at the numerical work for which JAX was chosen. Some of the surrounding operator work has a different computational character, and that character deserves a different runtime.

Framework selection creates a performance profile

TensorCircuit-NG's high-performance path is closely connected to JAX. This brings major advantages and makes JAX's preferred workload shape visible in TensorCircuit workflows. Every runtime has such a shape, and performance depends on how closely a problem matches it.

JAX is strongest when a computation can be expressed as a regular array program. Dense linear algebra, large matrix and vector operations, batching, automatic differentiation, and accelerator execution are all natural targets. XLA can trace the program, optimize it, fuse operations, and produce a fast executable. For a dense matrix multiplication or another BLAS/LAPACK-class kernel, moving the operation into Rust usually changes very little. Rust will call the same optimized numerical libraries, while JAX may have additional opportunities for fusion, compilation, or execution on a GPU or TPU.

This gives the first design principle for TenCirPauli: dense numerical work should stay close to the TensorCircuit-NG backend, while irregular surrounding work can use a native systems language.

Where the JAX model becomes expensive

The first difficulty is dynamic shape. A Pauli propagation recurrence can create new words, merge equal words, cancel terms, and move contributions between weight sectors. Symmetry analysis, mappings, and grouping can likewise produce variable numbers of basis states, terms, transitions, groups, or constraints.

JAX can express these algorithms, yet the natural representation often conflicts with its compilation model. A dynamic algorithm consequently needs padding, masking, sorting, bounded buffers, static limits, or custom control-flow encoding. These techniques can be valuable for a carefully designed workload, while adding representation work and potentially changing the algorithm's semantics.

The second difficulty is compilation latency. JIT compilation can produce an extremely fast steady-state kernel, while the first call carries tracing, lowering, optimization, and executable creation. This is a good trade for long-running workloads with many repeated calls; it is less attractive for short jobs or frequently changing structures.

JAX can avoid this cost very effectively when the workflow has a stable shape. Hamiltonian coefficients, circuit angles, and other numerical inputs can live inside one parameterized compiled function, allowing broad scans to reuse the same executable. TensorCircuit-NG handles this style of work extremely well. The compilation boundary becomes important when term counts, Pauli supports, circuit control flow, sector dimensions, grouping results, or propagated-operator shapes change. Each new structure may require a new trace or a more elaborate static encoding, so separating setup, first execution, and steady execution helps identify where a native complementary path is useful.

The third difficulty is a workload dominated by bit strings and bit manipulation. Pauli words, occupation states, symmetry generators, basis indices, and transition keys can all be represented as packed integers. Their operations include XOR, parity, masks, shifts, comparisons, hash lookups, and small logical branches; the computation is controlled by the bits themselves more than by dense floating-point arithmetic.

JAX supports bitwise operations, loops, and integer arrays. A single XOR does not become faster simply because it is written in Rust. The opportunity appears in the complete workload: millions of small operations, changing output sizes, duplicate-key aggregation, branch-heavy recurrences, and data structures that do not map cleanly to a dense rectangular array. A Python fallback exposes interpreter overhead, while a tensor encoding can introduce padding, sorting, masking, recompilation, or extra preparation.

These cases reveal a specific type of gap. TensorCircuit-NG has a powerful numerical engine, while some operator workflows need a compact control-oriented engine for irregular discrete computation. That gap is where a Rust companion can create real value.

Why Rust is a useful complement

Rust's scientific-computing ecosystem is smaller than Python's, and its linear-algebra stack is less mature. That is acceptable for this design because dense matrix multiplication, eigensolvers, tensor contractions, and accelerator kernels already have mature homes in the Python and JAX ecosystems. TenCirPauli gains little by rebuilding those foundations.

Rust has a different set of advantages. It compiles ordinary loops and branches to native code, gives direct control over memory and integer representations, handles dynamic collections without Python object overhead, and makes packed-data algorithms natural to express. Hash maps, bit masks, transition tables, and variable-length work queues fit this runtime well. The core can release the Python GIL while processing a complete batch, so the Python boundary stays outside the hot loop.

The complement can be summarized as follows:

Workload characteristic	JAX / TensorCircuit-NG	Rust / TenCirPauli
Dense matrix and tensor arithmetic	Strong fit	Usually delegates to established numerical libraries
Regular batching and static array programs	Strong fit	Capable, with less ecosystem leverage
Automatic differentiation through numerical code	Strong fit	Explicit local derivative rules where needed
Dynamic term counts and variable shapes	Requires encoding for compilation	Natural control flow and dynamic storage
Hash-based aggregation and graph-like analysis	Possible, often awkward inside traced arrays	Direct and compact
Packed integers, bit strings, parity, masks	Expressible, with limited advantage from tensorization	Natural inner-loop representation
Long-running accelerator workloads	Strong fit	Usually the wrong execution target
Short or frequently changing workloads	Compilation cost can dominate	Native setup can remain small and predictable

This division of labor is the starting point for TenCirPauli. It also explains why the project is designed as a companion to TensorCircuit-NG. The two runtimes can cooperate on one scientific workflow, with each one handling the part of the program that matches its performance profile.

What this implies for Pauli computation

Pauli algebra is a particularly clear example of the boundary. A Hamiltonian may be written as

H = c₀ P₀ + c₁ P₁ + ··· + cₘ Pₘ,

and the eventual numerical task may be an expectation value or a gradient. Between those points, the program may combine equal words, track phases, compute commutation relations, construct measurement groups, discover symmetries, restrict a physical sector, map fermions, and propagate observables through circuits.

These operations are symbolic and discrete, dominated by compact keys, parity, support inspection, branching, aggregation, and variable-size results. The final state-vector or tensor-network calculation may still be dense and backend-friendly. Pauli-heavy workflows therefore benefit from native preparation and transformation followed by a regular TensorCircuit-NG or JAX numerical plan when appropriate.

That makes Pauli computation a natural Rust target. Packed X/Z data, phase bookkeeping, parity checks, aggregation, and variable-size collections all fit native integer loops and compact data structures. From this workload, the surrounding capabilities follow naturally: the same native machinery can support Pauli algebra, measurement grouping, symmetry analysis, compilation, and observable propagation.

The functionality follows from the runtime choice

The design of TenCirPauli's public API follows directly from this framework analysis. The matrix is one useful destination for a small system. Larger workflows need algebraic transformations, measurement plans, reduced bases, matrix-free actions, observable trajectories, or differentiable circuit objectives. The architecture preserves the operator across those stages.

The resulting workflow can be viewed as a sequence of transformations:

structured model → canonical operator → algebra and analysis → reduction or mapping → execution plan → measurement or gradient

Each arrow has a different computational profile: symbolic expansion, canonicalization, bit-packed keys, graph analysis, and integer indexing at the front; dense state tensors, backend autodiff, sparse linear algebra, or native CPU kernels at the end. The representation must cross this boundary without losing its meaning.

From physical models to canonical operators

Pauli operators are the central representation for qubit Hamiltonians, observables, and propagation. TenCirPauli extends the same native approach to fermionic, bosonic, qudit-Weyl, Majorana, and hybrid operators. Jordan–Wigner, parity, and Bravyi–Kitaev mappings transform structured terms into Pauli form, while optional chemistry adapters bring molecular Hamiltonians into the same pipeline. Canonical aggregation, explicit phase handling, deterministic ordering, and compact keys give every later capability one stable operator.

From operators to measurements and structural information

Measurement planning is an analysis stage. A qubit-wise commuting grouping uses Pauli supports and local bases, so its useful result contains more than a partition of term indices. It also describes the basis rotations and the reconstruction of Pauli eigenvalues from rotated computational-basis samples. The grouping result can therefore travel from symbolic preprocessing to experimental post-processing without a second interpretation layer.

Symmetry analysis follows the same pattern. Z₂ generators, tapering sectors, fixed-particle-number spaces, and general additive-charge restrictions use bit operations, constraint solving, basis indexing, and leakage checks. They can reduce the computational object before a circuit, sparse matrix, or matrix-free plan is executed. For a 60-qubit, two-particle system, the relevant sector contains choose(60, 2) = 1,770 basis states, compared with 2**60 states in the full computational space. This is a structural reduction that comes before numerical optimization.

From one operator to several execution targets

Compilation chooses the endpoint that matches the next consumer: dense, COO, CSR, SciPy linear operator, Rust-native matrix-vector product, or a pure-array TensorCircuit-NG/JAX backend plan. For large systems the useful result may be a reusable MVP plan that never materializes the full matrix; for a restricted sector it may be a compact transition plan over the physical basis. Rust prepares the fixed structure before backend tracing, and the public API keeps the target choice explicit.

From circuits to observable execution and gradients

The same boundary applies when the operator meets a circuit. A fixed-particle-number circuit can execute directly in a restricted basis. A Pauli observable can propagate backwards through a circuit using dynamic native storage, with terms expanded, merged, cancelled, and projected by weight. A stochastic Pauli-path estimator can use the same operator semantics with an explicit sampling contract. Native value-and-gradient paths use local derivative and vector-Jacobian rules for supported gates, while TensorCircuit-NG and JAX remain available when the objective belongs inside a backend-traced tensor program.

The user-facing interface remains entirely in Python. Users construct operators, pass them to grouping or compilation APIs, connect them to TensorCircuit-NG circuits and backends, and receive ordinary Python objects, NumPy arrays, or backend tensors. They do not need to write Rust, manage FFI handles, or choose native data layouts. The workflow should feel as fluent as TensorCircuit-NG itself; Rust stays behind the boundary and handles the work that scales with terms, gates, groups, transitions, or basis states through coarse-grained native calls.

What the Early Benchmarks Show

The first benchmark suite provides evidence for this division of labor. The headline result comes from a representative 60-qubit, two-particle U(1) VQE: TenCirPauli's first compiled value-and-gradient call was about 688× faster than the corresponding TensorCircuit/JAX call, and the steady native path was about 2.6× faster. In a matched stochastic Pauli-path value-and-gradient workload, the native path was about 6.5–7.6× faster at 12 qubits and about 12.4× faster at 16 qubits in the recorded steady-state comparisons.

These results show where the architecture creates leverage. The first-call improvement reflects the cost of tracing and compilation, while the steady-state improvement reflects the benefit of native handling for irregular Pauli structure. A JAX implementation can still be the best choice after a long compilation has been amortized, and a Rust implementation becomes attractive when the workload changes shape frequently, contains heavy bit manipulation, or spends most of its time in symbolic preparation. The measurements separate native setup, first execution, steady execution, memory, and numerical agreement so that these cases remain visible.

Later technical posts will open up these comparisons and individual workloads in more detail. Here the benchmarks support one framework-level conclusion: runtime choice should follow the shape of the computation.

The larger lesson

TensorCircuit-NG solved an important problem by making tensor-based circuit computation expressive, differentiable, and backend-aware. Its JAX-centered design is a major part of that success. The same design makes dynamic, branch-heavy, shape-changing, and bit-string-heavy tasks stand out as a separate class of workload.

TenCirPauli extends TensorCircuit-NG around that boundary. It gives irregular Pauli workloads a native path while preserving TensorCircuit-NG's strengths for dense numerical computation, parameterized execution, automatic differentiation, and accelerated backends. The result is a complementary architecture: JAX handles regular numerical programs, Rust handles irregular Pauli structure, and Python connects the two into one scientific workflow.

That is why I developed TenCirPauli. The project began with a framework-selection question, and the Pauli algebra, measurement planning, symmetry tools, restricted sectors, propagation engines, and backend plans followed from the answer.

From Parameter Tuning to Cross-Paradigm Exploration: Quantum Control Enters the Era of “Autopilot”

Shixin Zhang — Tue, 21 Jul 2026 06:37:46 +0000

If you have ever tried to drive a high-performance race car on ice, you may understand the frustration researchers face when controlling quantum systems today.

In the grand vision of quantum computing, Quantum Optimal Control (QOC) serves as the steering wheel that guides quantum systems toward desired states. Whether in adiabatic quantum computation, quantum annealing, or quantum simulation, the fundamental challenge remains the same: designing time-dependent control protocols that drive a quantum system from a simple initial state to a complex target state with high fidelity.

However, real-world quantum control faces two fundamental obstacles.

On the hardware side, quantum systems are extremely fragile. Short coherence times, limited control channels, hardware-specific constraints, and strict pulse boundaries severely restrict the available control space.

On the algorithmic side, many-body Hamiltonians associated with practical problems often exhibit complicated spectral structures, including small energy gaps and rugged optimization landscapes. Finding an efficient evolution path within a limited time window remains highly challenging.

For decades, designing quantum control protocols has largely remained a human-driven, handcrafted process. Experts repeatedly design, simulate, and tune protocols for specific physical systems and hardware platforms through extensive trial and error.

A recent work introduces a fundamentally different approach: QOC-Workbench, an LLM-driven, fully auditable framework for cross-paradigm quantum control design. Rather than acting as another black-box optimizer, it functions more like an autopilot system for quantum control—transforming how control protocols are discovered, validated, and improved.

Reference:
LLM-Driven Cross-Paradigm Design for Quantum Optimal Control
Yu-Qin Chen and Shi-Xin Zhang, arXiv:2607.17498

Beyond Closed Optimization Spaces: How QOC-Workbench Works

Traditional quantum optimal control methods usually operate inside a predefined design space.

Researchers first choose a control ansatz—a mathematical form for pulse schedules, interpolation functions, or auxiliary Hamiltonians. Classical optimization algorithms then search for optimal parameters within that fixed structure.

This approach is powerful, but fundamentally limited.

If the initial design space is incomplete, optimization can only find the best solution within existing assumptions. It cannot invent new functional forms, discover alternative control mechanisms, or challenge the original modeling choices.

QOC-Workbench changes this paradigm by integrating:

large language models with scientific reasoning capabilities,
structured knowledge extracted from quantum control literature,
historical simulation results,
hardware constraints,
and high-performance quantum simulation infrastructure.

The workflow forms a closed-loop scientific discovery system:

1. Human experts define the physical boundary

Researchers specify:

target Hamiltonians,
hardware limitations,
physical constraints,
evaluation objectives.

Humans provide the scientific context and ensure physical validity.

2. LLM performs cross-paradigm exploration

Instead of only optimizing parameters, the LLM can:

propose new control schedule families,
modify the structure of auxiliary Hamiltonians,
combine ideas from different control paradigms,
generate executable simulation code.

The search space itself becomes dynamic.

3. Physics solvers provide rigorous validation

Candidate protocols are evaluated through differentiable quantum many-body simulations powered by high-performance quantum software infrastructure such as TensorCircuit-NG.

The system does not rely on language-model judgment alone—the generated ideas must survive quantitative physical evaluation.

4. Memory engine turns experiments into reusable knowledge

Every successful or failed experiment is automatically recorded as structured knowledge.

Over time, the system accumulates reusable design principles, allowing previous discoveries to influence future exploration.

Through this process, AI evolves from a parameter fitting tool into a continuously improving scientific assistant.

Three Levels of Evolution: From Pulse Shaping to Neural Control Generators

To demonstrate the capability of QOC-Workbench, the authors tested it across three increasingly challenging physical scenarios.

These examples illustrate a gradual transition:

from optimizing existing protocols → modifying physical pathways → discovering new computational paradigms.

Case 1: Designing Hardware-Compatible Control Pulses

Rydberg Atom Arrays

The first challenge considers solving the Maximum Independent Set problem using Rydberg atom arrays.

Real quantum hardware imposes strict constraints on available control signals. Traditional approaches often rely on analytical counterdiabatic protocols derived from simplified models.

However, these idealized solutions may not fully capture the complexity of interacting many-body systems.

QOC-Workbench analyzed the limitations of existing approaches and explored a broader control space.

Instead of simply tuning parameters of known pulses, it discovered a new pulse structure:

the “smooth beta-bump” envelope.

The generated protocol:

satisfies realistic hardware constraints,
preserves smooth control behavior,
achieves higher ground-state fidelity than classical analytical baselines in many-body simulations.

This demonstrates that LLM-driven exploration can redesign control waveforms rather than merely optimize them.

Case 2: Redesigning Many-Body Evolution Paths

XXZ Spin Chains

The second example moves beyond pulse engineering.

For XXZ spin chains with complex spectral structures, QOC-Workbench explored the structure of the entire evolution trajectory.

The system introduced:

a target catalyst Hamiltonian that asymptotically vanishes at the endpoints,
jointly optimized approximate counterdiabatic corrections,
nonlinear time schedules combining polynomial and sinusoidal deformations.

The key insight was that optimal control is not only about adjusting individual parameters.

The geometry of the evolution path itself can be redesigned.

By jointly optimizing the Hamiltonian pathway and correction terms, the system discovered improved protocols that would be difficult to obtain through conventional parameter optimization alone.

Case 3: Breaking the Scaling Barrier with Neural Generators

2D Random-Field Ising Models

The third case reveals the most significant conceptual shift.

For disordered many-body systems, optimizing a control protocol separately for every instance quickly becomes computationally expensive.

QOC-Workbench identified this bottleneck and changed the problem formulation.

Instead of searching for an optimal protocol instance by instance, it designed and trained a graph neural network (GNN) generator.

The generator was trained only on small-scale graph instances but successfully generalized to larger unseen systems.

It could:

accurately predict control coefficients,
generate reasonable evolution paths,
bypass expensive per-instance variational optimization.

This represents a transition from:

“optimize every problem separately”

to:

“learn the underlying structure of the solution space.”

Conclusion: Let Physicists Return to Physics

QOC-Workbench is not designed to replace human scientific intuition.

Instead, it aims to amplify it.

In this emerging human-AI collaboration paradigm, researchers no longer need to spend most of their time on:

manual parameter tuning,
repetitive protocol benchmarking,
low-level implementation details.

Instead, they can focus on:

understanding fundamental physical mechanisms,
defining meaningful physical constraints,
interpreting machine-discovered protocols,
extracting new scientific principles.

Human insights then become new knowledge injected back into the system, creating a continuous feedback loop between human reasoning and machine exploration.

From manually crafting isolated interpolation curves to building a continuously evolving, auditable, and transferable knowledge system, quantum control is moving beyond fixed optimization frameworks.

The future of quantum control may not be about finding better parameters inside predefined spaces.

It may be about building intelligent systems capable of discovering entirely new control paradigms.

Quantum control is entering the era of autopilot.

Training a 1,000-Qubit, 40,000-Parameter Quantum Algorithm with Full Gradients Using TensorCircuit-NG

Shixin Zhang — Sat, 18 Jul 2026 02:47:36 +0000

Introduction

If you wanted to simulate 1,000 quantum qubits and compute exact full gradients for 40,000 parameters on a classical computer, how much compute power would you need?

For a 1,000-qubit, 10-layer circuit, calculating a single state amplitude might have a manageable computational overhead. However, when you attempt to solve the system's Variational Quantum Eigensolver (VQE) and compute all of its parameter gradients, the difficulty skyrockets. At first glance, this sounds like a job that strictly requires a supercomputing cluster.

The underlying reasons for this explosion in complexity are twofold:

The Introduction of the Hamiltonian: Computing the VQE expectation value requires evaluating $E(\boldsymbol\theta)=\langle\psi(\boldsymbol\theta)\vert H\vert\psi(\boldsymbol\theta)\rangle$. This transforms the tensor network from a single-sided state contraction into a "bra-MPO-ket" three-layer sandwich structure, immediately more than doubling the graph size.
The Memory Wall in Backpropagation: Deriving gradients for tens of thousands of parameters requires backpropagation. To compute these gradients in a contraction graph, the compiler has to keep massive amounts of intermediate results from the forward pass in VRAM. This is vastly more difficult—and puts far more pressure on memory—than a simple forward contraction or amplitude calculation.

In this technical blog, we'll demonstrate how we cut the per-step execution time of a 1,000-qubit VQE down to just 1 second on a single NVIDIA RTX 6000D GPU. We achieve this by exploring three different physics- and engineering-driven contraction strategies, all without sacrificing exact gradient precision.

Performance Comparison: Three Physical Perspectives

We use a 1D Transverse Field Ising Model (TFIM) with open boundary conditions as our benchmark. Each layer of the circuit applies diagonal entangling gates sequentially to adjacent pairs $(0,1),(1,2),\ldots,(n-2,n-1)$ along the qubit chain:

$$R_{ZZ}(\theta)=\exp(-i\theta Z\otimes Z/2)$$

Followed by single-qubit rotations. The TFIM Hamiltonian is:

$$H_{\rm TFIM}=\sum_{i=0}^{n-2}X_iX_{i+1}+\sum_{i=0}^{n-1}Z_i$$

We can also represent this Hamiltonian as an exact and compact Matrix Product Operator (MPO, with a Bond Dimension of 3).

The table below shows the benchmark results for three different contraction modes (using an NVIDIA RTX 6000D at complex64 precision):

Perspective (Algorithm Mode)	Initial Compilation	First Full Gradient	Steady-State Full Gradient	Peak VRAM	Applicability & Value
Global Contraction Tree	5 h 20 min	5.88 s	1.09 s	51.97 GB	Directly contracts the full bra-MPO-ket graph; useful for full-graph compute and cross-benchmarking.
Local Causal Sliding Window	10.79 s	148.68 s	148.36 s	8.86 GB	Relies on strict causal cones of fixed width for local terms; terms can be dispatched independently.
Local Window (8-GPU Parallel)	10.50–11.28 s / GPU	19.72–20.50 s	18.71 s	8.86 GB / GPU	Dispatches 125 local terms per GPU; yielded a measured 7.93× speedup.
Spatial Transfer Matrix (B3)	6.367 s	1.328 s	1.054 s	8.62 GB	Leverages repeating 1D spatial structures.
Spatial Transfer Matrix (B5)	7.375 s	1.320 s	1.133 s	5.44 GB	A lower-VRAM variant of the same exact STM algorithm.

These approaches complement one another:

The Global Tree delivers excellent steady-state execution time (1.09s) but suffers from a brutal 5+ hour cold compilation time and massive 52 GB peak VRAM usage.
The Local Window approach crushes compile time down to ~10 seconds, but redundantly computes the shared environments of adjacent local terms, making single-GPU execution sluggish.
The Spatial Transfer Matrix (STM) successfully decouples compilation costs from the system length by explicitly passing the repetitive 1D spatial structure to jax.lax.scan, perfectly balancing compilation and execution efficiency.

Contraction Path Metrics: FLOPs, Max Tensor, and Write

In tensor network contraction, path quality is defined by several resource metrics:

FLOPs (Floating Point Operations): The total number of scalar multiply-add operations required for the path. For example, log10 FLOPs = 12.0 means roughly $10^{12}$ scalar ops.
Max Tensor Size (Width $w$): The number of elements in the largest intermediate tensor generated during contraction. It directly dictates the instantaneous VRAM pressure during the forward pass. (If all indices have a dimension of 2, width $w$ corresponds to $2^w$ elements).
Total Write: The total number of elements written out across all intermediate tensors. During backpropagation, all of these written tensors must be retained in memory as residuals to compute gradients.

When calculating expectations and gradients simultaneously, you must keep an eye on all three metrics. Ultimately, however, empirical compile time, execution time, and peak GPU VRAM are the ground truth.

Perspective 1: Global Contraction Tree — Brute-Forcing the Entire Graph

By calling value_and_grad directly on the complete bra-MPO-ket network, we can quantify the true cost of naive global contraction.

To make this feasible, we first alter the network representation. It is critical to write each $R_{ZZ}$ gate in an exact Rank-2 decomposed form:

$$R_{ZZ}(\theta)=\cos(\theta/2)I\otimes I-i\sin(\theta/2)Z\otimes Z$$

Maintaining the original left-to-right "ladder" gate ordering is also crucial. If we reorder the commuting $R_{ZZ}$ gates into an alternating even/odd bond "brick-wall" structure, we destroy the elimination path. The tensor network width instantly spikes to 39.585. Keeping the ladder ordering keeps the width at a manageable 23.585.

Using the omeco path search on this massive graph, we found a global contraction path with log10 FLOPs = 12.0466 and log2 write = 32.5912.

On a single RTX 6000D, post-compilation gradient execution takes only 1.09s, peaking at 51 GB of VRAM. This proves that full-graph VQE gradients can technically be run on a single card, but the bottlenecks are purely the global HLO compilation time and the memory needed to store backward residuals.

omeco vs. cotengra: Two Path-Search Frameworks

Since the global graph's resource bottleneck lies heavily in contraction path search and compilation, how do top-tier tools fare? We compared two frameworks—omeco and cotengra—on this massive tensor network.

omeco (Rust-based) uses a TreeSA algorithm to perform intense simulated annealing in tree space. It is excellent for quickly finding high-quality un-sliced seed trees on large graphs.
cotengra offers richer interfaces for manipulating and fine-tuning contraction trees, such as reconfiguring subtrees based on existing paths or performing granular slice-index searches on a fixed tree.

We ran a controlled search comparison on a 100-qubit, 10-layer TFIM graph (6,460 tensors, 8,441 indices):

Search Method & Budget	Search Time	log10 FLOPs	log2 Max Tensor	log2 Total Write	Notes
`omeco` TreeSA (16 trials × 64 steps)	15.68 s	11.068	24.585	29.517	16 independent SA trials
`cotengra` CMA-ES (8 hyperparam candidates)	37.59 s	12.901	31.585	35.646	8 sets of search params
`cotengra` SA (12 steps × 12 reconfigs)	9.22 s	11.827	29.585	34.014	Low-budget SA
`cotengra` SA (24 steps × 24 reconfigs)	34.09 s	10.873	23.585	30.367	Higher-budget SA

The data shows that omeco TreeSA ran significantly more annealing steps in less time and returned lower-complexity trees, outperforming the alternatives for this un-sliced scenario. However, for scenarios requiring deep slicing, neither framework is currently ideal.

The Efficiency Limits of Slicing

When VRAM is tight, slicing the contraction tree is a necessary evil to keep memory footprints in check. But if you have enough VRAM for an un-sliced path, forcing a slice to distribute across multiple GPUs does not scale efficiency linearly.

Fundamentally, slicing a tensor network means forcibly delaying the contraction of selected indices to the very end of the path. In an optimal, un-sliced path, these indices are eliminated early on, preventing intermediate tensors from blowing up in size. Slicing disrupts this optimal elimination order. It forces every sub-task to redundantly compute intermediate results that could have been shared before the final summation.

When we force-sliced the 1,000-qubit global path into 8, 32, and 128 tasks, the log2 write per slice barely dropped—from 32.5912 to 32.5632, 32.5491, and 32.5365 respectively. Because it failed to meaningfully dismantle the primary memory structure of the backward pass, while heavily deviating from the optimal contraction order, redundant computation skyrocketed. Total log10 FLOPs jumped from 12.0466 to 12.9420, 13.5391, and 14.1355.

Takeaway: If it fits in VRAM, using an un-sliced path usually maximizes hardware utilization.

Perspective 2: Local Causal Sliding Window — Exploiting Local Physics

For a circuit depth of $L=10$, we can leverage the commutativity of 2-qubit gates to convert the ladder structure into a brick-wall equivalent. Consequently, every local TFIM term possesses an exact backward causal cone during backpropagation. Since the diagonal entangling gates commute, the width of this causal window is strictly $2L+2$, which is only 22 sites for $L=10$. The brick-wall structure, which was a liability for global tree search, becomes a massive advantage here.

By using lax.scan to iterate over the local Pauli terms of the Hamiltonian and wrapping single terms in jax.checkpoint, the compilation scale becomes solely dependent on window size and circuit depth, totally decoupled from the total number of system sites:

$$T_{\rm window}=O(n C_{\rm local}(L)),\qquad M_{\rm window}=O(M_{\rm local}(L))$$

This approach boasts rapid compile times (~10 seconds) and a lean VRAM footprint of 8.86 GB. If dispatched across 8 GPUs (125 local terms per GPU), the steady-state gradient time drops to 18.71s. However, the overlapping causal windows introduce massive computational redundancy.

Furthermore, this method heavily relies on the commutativity of diagonal gates. If we swap them for non-commuting 2-qubit gates, the causal cone under a ladder structure expands to $O(n)$, rendering this method useless.

Perspective 3: Spatial Transfer Matrix — Lossless Exact Scanning

The spatial transfer matrix strategy slices the system along the spatial qubit dimension into a left-end block, repeating middle blocks, and a right-end block. The middle block receives the complete boundary tensor from the left, contracts its internal bra-MPO-ket subnetwork, and outputs to the next block.

The recurrence relation is:

$$B_{k+1}=\mathcal{T}_k(\boldsymbol\theta_k)B_k$$

At depth $L=10$, the spatial cut crosses 10 ket bonds, 10 bra bonds, and 1 MPO bond (dimension 3). The exact boundary size is:

$$D_{\rm boundary}=3\times2^{2L}=3\times4^L = 3\times4^{10}$$

This amounts to roughly 24 MiB of memory traffic, which perfectly explains why this method can effortlessly perform linear scanning at the 1,000-qubit scale.

Using a 3-site block division, this mode requires just 6.367s for cold compilation, executes at 1.054s per step, and peaks at 8.62 GB of VRAM.

The spatial width of each scan step (the block size $b$) acts as a tunable time-space tradeoff:

Smaller blocks shrink the internal contraction graph, reducing compile pressure and the residuals saved for backprop, but increase the number of scan steps needed to pass the boundary tensor.
Larger blocks reduce scan steps but inflate maximum tensor size, total write, compile time, and peak VRAM.

In our tests, a 3-site block offered optimal throughput. A 5-site block reduced peak VRAM further to 5.44 GB, at the slight cost of increasing execution time to 1.133s.

Counterintuitive Acceleration: Trading Compute for Bandwidth

Fascinatingly, pairing the transfer matrix's middle block loop with jax.checkpoint (recomputation) dropped the peak VRAM from 42.24 GB down to 8.62 GB, while also slightly reducing steady-state execution time from 1.118s to 1.054s.

"Reducing memory traffic by recomputing intermediate residuals" actually speeding up execution highlights a hardware reality: on modern consumer GPUs, memory bandwidth is often a much harder bottleneck than raw single-precision FLOPs. Taking on a heavier compute burden to alleviate read/write strain yields net performance gains. This same logic applies when tuning the penalty ratio between time and space complexity during contraction tree searches.

Even more thought-provoking is the fact that this relatively simple spatial slicing and block-scanning strategy heavily outperformed the global tree—derived from intense simulated annealing—in execution time, compile time, and memory footprint. This implies that for truly massive tensor networks requiring backpropagation (where intermediate residuals and VRAM are paramount), existing contraction path algorithms still have significant blind spots and ample room for innovation.

Pitfalls to Avoid

Bypassing TF32 Precision Limitations

When doing complex matrix multiplications on NVIDIA GPUs, simply setting the highest precision in JAX is not enough to avoid automatic degradation to TF32. You must explicitly set this environment variable before runtime:

Bash

   export NVIDIA_TF32_OVERRIDE=0

If you don't, the state norm can slip to 0.98–0.996, causing noticeable deviations in energy calculations. This is a stark reminder of the differing precision tolerances between standard Machine Learning and Quantum Simulation.

Rayon Thread Pool Stack Overflows

When omeco searches ultra-deep trees (depth > 1000) and generates slicing code, the recursive traversal of the deep tree can trigger a Segmentation Fault in Rayon threads. You must explicitly bump up the stack size before initiating Python or the Rayon global pool:

Bash

   export RUST_MIN_STACK=67108864

Full 1,000-Qubit VQE: From Single-Step Gradients to End-to-End Optimization

To prove that this isn't just a parlor trick for a single energy/gradient calculation, we ran a complete, complex 1,000-qubit VQE optimization. Our circuit features 10 layers of nearest-neighbor $R_{ZZ}$ ladders, with each layer's single-qubit component consisting of sequential $R_X$, $R_Z$, and $R_X$ rotations:

$$\vert{}0\rangle^{\otimes 1000}\xrightarrow{H^{\otimes 1000}}\left[R_{ZZ}\text{ Ladder}\rightarrow R_X\rightarrow R_Z\rightarrow R_X\right]^{10}.$$

Before constructing the full bra-MPO-ket network, we exactly compressed each consecutive $R_X$–$R_Z$–$R_X$ sequence into a single $2\times2$ single-qubit tensor. We then utilized the exact same Spatial Transfer Matrix scheme (with zero approximation truncations) to compute the energy and the gradients for all 40,000 parameters. The entire optimization ran on a single NVIDIA RTX 6000D, completing 2,000 Adam updates.

For this 1,000-site critical open-boundary TFIM, the exact ground state energy can be derived directly from the free-fermion spectrum. After 2,000 updates, our VQE energy was $E_{\rm VQE}=-1268.4365$, resulting in a total energy error of $E_{\rm VQE}-E_0=4.440$. This equates to a relative error of about $3\times10^{-3}$.

Without any hyperparameter tuning, a 1,000-qubit VQE featuring complex gate sequences, full parameters, and exact full gradients hit a relative energy precision in the thousandths. This confirms that our tensor network representations, path searches, spatial scanning, autodiff, and GPU execution aren't isolated micro-optimizations—they form a cohesive, end-to-end technical pipeline capable of translating circuit definitions into actual, strictly-verified optimization convergence.

Conclusion

Our work on full-gradient simulation and optimization for a 1,000-qubit VQE demonstrates that by hybridizing low-rank gate decomposition, contraction path search, lossless spatial transfer matrices, JAX automatic differentiation, and compiler mechanics, we can do the impossible. We can compute the full gradient of a 1,000-qubit VQE rapidly on a single GPU, execute thousands of training steps within hours, and achieve ~0.3% relative energy error without systemic fine-tuning.

These results illustrate the immense potential of moving from single-shot simulations to massive end-to-end variational computation, leaving plenty of headroom for exploring better circuit structures, learning rate schedules, and higher precision.

Getting a 1,000-qubit VQE to run natively proves one thing: in the deep waters of quantum simulation, the mathematical elegance of algorithmic design must be deeply coupled with the underlying mechanics of compilers (XLA), automatic differentiation, and GPU hardware architectures. TensorCircuit-NG is more than just a simulator; it is a critical piece of infrastructure that bridges software and hardware, providing a complete technical pipeline from quantum algorithm definition to ultra-large-scale variational optimization.

Large-Scale TensorCircuit Contractions on GPUs: Disabling XLA GPU Autotuning

Shixin Zhang — Wed, 15 Jul 2026 03:41:23 +0000

When running large-scale tensor-network contractions with TensorCircuit-NG and the JAX GPU backend, the following runtime configuration is worth testing:

XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

Its main benefit is not speed, but lower persistent GPU memory usage from XLA GPU autotuning, which makes memory behavior during compilation and on the first visible GPU more predictable. In the TensorCircuit contraction workloads we tested, disabling autotuning also slightly improved steady-state runtime, but the memory savings were the more important result.

Key takeaway

XLA GPU autotuning evaluates alternative algorithms or workspace configurations for certain GPU kernels and custom calls, then selects an implementation. This can be valuable for convolutions, large GEMMs, and deep-learning workloads with fixed shapes. For large TensorCircuit contractions, however, the contraction path is already determined by OMECO or cotengra, leaving relatively little optimization freedom for autotuning while still potentially incurring substantial persistent memory overhead during compilation and tuning.

For TensorCircuit contractions, run this A/B test by default:

# Baseline
XLA_PYTHON_CLIENT_PREALLOCATE=false python your_script.py

# Test configuration
XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

Both environment variables must be set before the Python process starts and before JAX is imported. This recommendation primarily concerns GPUs; CPU backends do not exhibit the same GPU-kernel autotuning behavior.

Representative results

All results below use a fixed contraction path so that path-search randomness does not affect the comparison.

Workload	Autotuning	Post-compile memory	Peak memory	Steady-state runtime
100 qubits × 24 layers, amplitude	Default	8.7 GiB	8.7 GiB	0.37 s
100 qubits × 24 layers, amplitude	autotune=0	0.5 GiB	4.6 GiB	0.40 s
28 qubits × 12 layers, expectation gradient	Default	4.7 GiB	21.4 GiB	0.18 s
28 qubits × 12 layers, expectation gradient	autotune=0	0.5 GiB	17.2 GiB	0.15 s
28 qubits × 13 layers, expectation gradient	Default	10.9 GiB	43.8 GiB	0.46 s
28 qubits × 13 layers, expectation gradient	autotune=0	0.5 GiB	33.5 GiB	0.42 s
28 qubits × 14 layers, expectation gradient	Default	17.0 GiB	64.5 GiB	0.58 s
28 qubits × 14 layers, expectation gradient	autotune=0	0.5 GiB	64.5 GiB	0.58 s

The first three workload groups show the most common benefit: disabling autotuning reduces compilation-stage memory and the final peak. The 28 × 14 case appears different: post-compile memory falls from 17.0 GiB to 0.5 GiB, but the final peak is unchanged. This behavior is related to the JAX GPU allocator.

Why the final peak is unchanged for the 28 × 14 case

Even with XLA_PYTHON_CLIENT_PREALLOCATE=false, the default JAX GPU allocator tends to retain and reuse GPU memory that it has already allocated. The memory reported by nvidia-smi is therefore the amount held by the process, not the total size of tensors that are currently live.

In the 28 × 14 example, default autotuning did consume approximately 17 GiB of additional memory during compilation. During the first real backward contraction, however, the runtime buffers themselves also required a large allocation. The default allocator could reuse blocks allocated earlier, so the final peak was not simply the sum of runtime memory and autotuning memory.

Using XLA_PYTHON_CLIENT_ALLOCATOR=platform as a diagnostic exposes this difference:

Workload	Allocator	Autotuning	Post-compile memory	Peak memory
28 qubits × 14 layers, expectation gradient	Default	Default	17.0 GiB	64.5 GiB
28 qubits × 14 layers, expectation gradient	Default	autotune=0	0.5 GiB	64.5 GiB
28 qubits × 14 layers, expectation gradient	platform	Default	17.0 GiB	82.8 GiB
28 qubits × 14 layers, expectation gradient	platform	autotune=0	0.5 GiB	66.3 GiB

The platform allocator retains less reusable GPU memory, which makes it useful for diagnosing where allocations originate. Because it also reuses fewer large blocks allocated earlier, however, the runtime may request additional memory and produce a higher peak. Prefer the default allocator for normal execution; use platform mainly to confirm whether autotuning introduces extra memory usage.

Interpreting peak memory

Here, peak memory is the maximum per-process GPU memory observed by polling nvidia-smi, with snapshots recorded at stages such as after_compile and after_first_run. XLA's compiled.memory_analysis().peak_memory_in_bytes measures something different: it more closely reflects the computation graph's buffer assignment and is usually lower than the actual process memory reported by nvidia-smi.

Why the first GPU may use more memory in multi-GPU processes

In a JAX/XLA process that can see multiple GPUs, backend initialization, the default device, compilation services, autotuning caches, executable caches, or allocator state may be placed preferentially on the first GPU in the visible-device list. Consequently, the first GPU can hold an extra block of memory. Disabling xla_gpu_autotune_level often reduces this first-device memory tax.

For multiple independent single-GPU jobs, use CUDA_VISIBLE_DEVICES so that each process sees only its assigned GPU:

CUDA_VISIBLE_DEVICES=1 XLA_PYTHON_CLIENT_PREALLOCATE=false XLA_FLAGS=--xla_gpu_autotune_level=0 python your_script.py

For genuine multi-GPU parallel or distributed jobs, do not hide GPUs that must participate in the computation merely to avoid the first-device memory tax. Preserve the correct device set, then measure how disabling autotuning changes memory usage on each GPU.

Practical recommendations

For large TensorCircuit-NG contractions, use the following procedure:

Fix the contraction path instead of running a new stochastic path search for every benchmark.
Set XLA_PYTHON_CLIENT_PREALLOCATE=false to prevent JAX from reserving a large block of GPU memory at startup.
A/B test default autotuning against XLA_FLAGS=--xla_gpu_autotune_level=0.
Record compile time, first-run time, steady-state runtime, post-compile memory, and post-first-run memory separately.
Even if disabling autotuning does not improve steady-state runtime, prefer autotune=0, especially near the OOM limit or when scheduling multiple GPUs.

In short, disabling XLA GPU autotuning does not change the contraction path; it reduces an additional source of memory usage in the GPU compilation and execution layers. For large TensorCircuit contractions, this is usually a low-risk configuration well worth testing.

When Quantum Dynamics Doesn't Start from Zero: Completing the Missing Half of Entanglement Growth | PRL

Shixin Zhang — Fri, 10 Jul 2026 00:42:59 +0000

Entanglement dynamics lies at the heart of nonequilibrium quantum physics. For more than two decades, the standard approach has been remarkably consistent: start from an unentangled product state, let the system evolve unitarily, and study how the entanglement entropy grows over time.

This framework has led to many fundamental discoveries, including our understanding of quantum thermalization and many-body localization (MBL). It also shaped an implicit assumption shared across the field: whenever the half-chain entanglement entropy increases, the system must be creating new quantum entanglement.

Our recent paper, published in Physical Review Letters, argues that this picture is incomplete.

The central observation is surprisingly simple:

An increase in measured entanglement does not necessarily mean new entanglement has been created.

Instead, quantum dynamics possesses two fundamentally different capabilities that have long been mixed together.

Two ways to increase entanglement

A useful way to think about entanglement is to imagine the system as a connected network of water reservoirs.

There are two distinct mechanisms that can raise the water level observed at a particular cut.

Build: Creating new entanglement

The first mechanism genuinely generates new quantum correlations.

This is analogous to pumping fresh water into the entire reservoir system. The total amount of entanglement increases.

Move: Transporting existing entanglement

The second mechanism creates no new entanglement at all.

Instead, quantum evolution simply redistributes the entanglement that already exists inside the system. Water is flowing internally, but no new water enters the reservoirs. Although the total amount remains unchanged, the water level measured at one particular location may still rise.

Exactly the same phenomenon can happen for half-chain entanglement entropy.

This distinction turns out to be much more important than previously appreciated.

The intuitive expectation

Once these two mechanisms are separated, an intuitive principle emerges.

If a system already starts with a large amount of entanglement, there is less room left to generate additional entanglement later.

Indeed, this is exactly what happens in familiar systems such as

quantum chaotic (thermalizing) systems,
free-fermion systems,
random quantum circuits with strong scrambling.

As the initial entanglement increases, the additional entanglement generated during evolution decreases monotonically.

This is precisely what one would expect if entanglement growth were primarily driven by building new entanglement.

MBL breaks the rule

Many-body localized systems tell a completely different story.

Instead of decreasing monotonically, the entanglement growth exhibits a striking bell-shaped dependence on the initial entanglement.

Starting from nearly product states, the growth is very small.
Starting from nearly maximally entangled states, the growth is again very small.
The largest increase occurs at intermediate initial entanglement.

This behavior is difficult to explain if entanglement growth comes solely from generating new entanglement.

Something else must be happening.

A "pure transport" experiment

To isolate the missing ingredient, we designed a particularly simple reference model.

Instead of using an interacting Hamiltonian, we considered a random circuit composed only of SWAP gates.

This circuit has a remarkable property:

it cannot create any entanglement, and
it only exchanges the locations of quantum states.

In other words, it performs pure entanglement transport.

Surprisingly, the entanglement-growth curve produced by this SWAP-only circuit closely matches the behavior observed in MBL systems, both qualitatively and even quantitatively.

This comparison reveals the underlying physics.

MBL is not particularly good at generating new entanglement.

Instead, it excels at moving around the entanglement that already exists.

When the system begins with almost no entanglement, there is simply nothing to transport.

When it begins nearly saturated, there is no remaining room for rearrangement.

Only at intermediate entanglement do both ingredients coexist, allowing transport to produce the largest observable increase.

Looking beyond a single bipartition

Most previous studies monitor only one quantity: the entanglement across the middle cut of the system.

While extremely useful, this provides only a partial view of the system's entanglement structure.

In our work, we introduce a more global perspective by considering the Bipartition-Averaged Entanglement Entropy (BAEE), which averages entanglement over all possible bipartitions.

The simulations reveal an interesting phenomenon.

Even in ordinary thermalizing systems, BAEE grows much faster than the half-chain entanglement during the early stages of evolution.

The difference between these two quantities represents a hidden reservoir of entanglement that has already been generated locally but has not yet reached the particular cut being measured.

Returning to our water analogy, thermalization rapidly fills many local reservoirs throughout the system.

Later dynamics can transport this stored entanglement across different partitions.

This picture naturally explains why transport-dominated systems like MBL exhibit their largest observable entanglement growth at intermediate initial entanglement.

A new perspective on entanglement dynamics

The broader message is that entanglement dynamics is not just about creating quantum information.

It is equally about processing, redistributing, and transporting the quantum information that already exists.

The traditional "start from product states" paradigm has taught us a great deal, but it captures only one half of the story.

Distinguishing between entanglement generation and entanglement transport provides a more complete framework for understanding quantum dynamics across thermalizing systems, free fermions, many-body localization, and quantum circuits.

Beyond offering a conceptual picture, this framework makes concrete predictions that can be tested on today's quantum simulation platforms, providing new experimental probes of nonequilibrium quantum dynamics.

Reference

Entanglement growth from entangled states: A unified perspective on entanglement generation and transport

Chun-Yue Zhang, Zi-Xiang Li, and Shi-Xin Zhang

Physical Review Letters 137, 020404 (2026)

Can AI Really Write Quantum Computing Code? Introducing ORBIT-Q: A Dual-Axis Benchmark for AI Agents and Quantum Software Frameworks

Shixin Zhang — Wed, 08 Jul 2026 05:35:39 +0000

Large language models have become remarkably good at writing conventional software. Frameworks like Codex, Claude Code, and other coding agents can already solve a large fraction of real-world programming tasks.

But scientific programming—especially quantum computing—is a very different challenge.

A quantum program is not simply expected to compile and produce the correct output. It must also preserve physical correctness, maintain differentiability, respect algorithmic constraints, and often achieve high computational performance. Traditional software benchmarks rarely capture these requirements.

To evaluate how AI agents perform in this setting, we developed ORBIT-Q (Open Research Benchmark for Integrated Tasks in Quantum Computing), a benchmark specifically designed for autonomous scientific programming in quantum computing.

Why Existing Benchmarks Are Not Enough

In conventional coding benchmarks, passing unit tests is often sufficient.

In scientific computing, however, an implementation may pass numerical tests while still being fundamentally wrong.

During our experiments we frequently observed behaviors such as:

Framework bypassing. Instead of using the requested quantum framework, the agent secretly reconstructs the computation with NumPy or JAX tensor operations.
Broken differentiability. The generated code produces correct numbers but destroys the end-to-end automatic differentiation pipeline.
Violation of physical assumptions. The implementation changes the intended mathematical or physical problem while still appearing to "work."

These failures are difficult to detect using standard execution-based evaluation alone.

Scientific programming therefore requires evaluation beyond correctness—it requires semantic verification.

ORBIT-Q: A Dual-Axis Benchmark

ORBIT-Q consists of 12 challenging research-level quantum programming tasks, covering representative workloads in quantum simulation, quantum machine learning, tensor network algorithms, optimization, and automatic differentiation.

Its key idea is a dual-axis evaluation protocol.

Axis 1: Agent Evaluation

Keep the quantum framework fixed and compare different AI agents.

This measures how well various models (GPT, Claude, etc.) can solve scientific programming tasks under identical software environments.

Axis 2: Framework Evaluation

Keep the AI agent fixed and compare different quantum software frameworks.

This evaluates not only functionality and runtime performance, but also something increasingly important in the AI era:

How AI-friendly is a software framework?

A framework with discoverable APIs, composable abstractions, and consistent interfaces allows autonomous agents to generate substantially better solutions.

Preventing "Cheating"

To ensure generated solutions genuinely use the intended framework, ORBIT-Q employs a three-stage verification pipeline:

Deterministic functional testing
LLM-based source-level semantic auditing, designed to detect framework bypassing and other implementation shortcuts
Expert manual review

This combination substantially reduces false positives that commonly appear in conventional coding benchmarks.

Results: Which Frameworks Work Best?

Using the same coding agent (Codex + GPT-5.5), we evaluated several mainstream quantum software frameworks.

TensorCircuit-NG achieved the strongest overall performance, successfully solving 10 out of 12 benchmark tasks while also delivering significantly faster execution than competing frameworks.

For comparison:

TensorCircuit-NG: 10 / 12
PennyLane: 8 / 12
TorchQuantum: 4 / 12
MindQuantum: 4 / 12

Beyond success rate, TensorCircuit-NG consistently produced solutions that executed several times faster than those generated for other frameworks.

This suggests that framework design has a substantial impact on autonomous scientific programming—not only for human developers but also for AI agents.

Results: Which AI Agents Perform Best?

Under the TensorCircuit-NG environment, the leading coding agents achieved:

Codex + GPT-5.5: 10 / 12
Claude Code + Opus 4.8: 9 / 12
Claude Code + Sonnet 4.6: 7 / 12

Although these results are encouraging, a significant gap remains between AI-generated solutions and expert-written implementations.

Human experts solved all 12 tasks, while producing implementations that were typically more than twice as efficient as the strongest AI-generated solutions.

Current AI systems are becoming effective research assistants, but they are still far from replacing domain experts in scientific software development.

An Unexpected Observation: Safety False Positives

One particularly interesting finding was unrelated to quantum computing itself.

During evaluation with Claude Code + Opus 4.8, two benchmark tasks failed—not because the model lacked the necessary programming capability, but because the interaction was interrupted by Cybersecurity Refusals.

These tasks involved no networking, no external services, and no security-sensitive objectives. They consisted solely of local quantum programming and framework exploration.

This illustrates an often-overlooked issue in agent evaluation:

Product-level safety policies can significantly affect end-to-end task reliability, even when the underlying model is technically capable of solving the problem.

For autonomous scientific workflows, reliability depends not only on model intelligence but also on surrounding product behavior.

The Economics of Scientific AI

Another interesting lesson concerns inference cost.

Developers often compare models by token price alone.

Our experiments suggest this can be misleading.

Lower-cost models frequently require many more iterations because they generate incorrect implementations, encounter execution failures, or repeatedly need debugging.

Consequently, obtaining one successful scientific solution may consume substantially more time and tokens than using a stronger (but more expensive) model.

For scientific programming, a more meaningful metric may be:

Cost per successful scientific solution

rather than simply cost per token.

Looking Ahead

As AI agents become increasingly integrated into scientific research, software frameworks will need to evolve as well.

Future scientific software should not only be easy for researchers to use—it should also be easy for autonomous agents to understand, compose, and optimize.

Although ORBIT-Q focuses on quantum computing, we believe its evaluation methodology can be generalized to many areas of scientific computing where correctness, semantics, differentiability, and performance all matter.

If AI is going to become a true collaborator in scientific discovery, we need benchmarks that measure much more than whether code simply runs.

Paper

ORBIT-Q: Dual-axis Benchmarking of Autonomous Agents in Scientific Quantum Programming

Shi-Xin Zhang and Yu-Qin Chen

arXiv:2607.03105

The benchmark, evaluation framework, and source code are all open source at GitHub: https://github.com/sxzgroup/ORBIT-Q and the accompanying webpage: https://sxzgroup.github.io/ORBIT-Q/.

The "Secret of Staying Young" in Quantum Neural Networks

Shixin Zhang — Tue, 07 Jul 2026 06:57:41 +0000

How quantum geometry helps preserve learning ability in continual learning

In quantum machine learning, new models are often evaluated by how much they improve benchmark accuracy over classical baselines. These quantitative gains, however, are frequently fragile. They can depend heavily on the choice of baseline models, hyperparameters, or other experimental details.

A more fundamental question is whether quantum and classical learning systems exhibit qualitatively different learning dynamics. Such structural differences, if they exist, reveal something deeper than a few percentage points of accuracy—they provide insight into the underlying mechanisms of learning itself.

A recent breakthrough study published in PRX Quantum by Yu-Qin Chen of the Graduate School of the Chinese Academy of Sciences and Shi-Xin Zhang of the Institute of Physics, Chinese Academy of Sciences, explores this question from the perspective of continual learning. Instead of asking whether quantum neural networks achieve higher accuracy, the work asks:

Can quantum neural networks preserve their ability to learn over long periods of continual training? If so, why?

The answer turns out to reveal a surprising geometric advantage rooted in quantum mechanics itself.

AI's Midlife Crisis: Losing the Ability to Learn

Continual learning aims to build models that, much like humans, continuously accumulate knowledge while adapting to new tasks and changing environments.

Historically, research has focused on catastrophic forgetting—the tendency of neural networks to overwrite previously learned knowledge when learning new tasks.

In recent years, however, researchers have recognized another equally important challenge.

As training continues across many tasks, models gradually become less capable of learning new information. Their parameters become increasingly difficult to update, gradients become less informative, and adaptation slows dramatically.

This phenomenon is known as loss of plasticity.

Among the earliest researchers to emphasize its importance was reinforcement learning pioneer Richard Sutton, who argued that for long-running learning systems, catastrophic forgetting and loss of plasticity are two complementary problems:

Catastrophic forgetting determines how well a model retains old knowledge.
Loss of plasticity determines how well it can acquire new knowledge.

An intuitive analogy is that the model gradually "ages." Although it accumulates more experience, it becomes increasingly resistant to learning anything new.

Do Quantum Models Age More Slowly?

The natural question is whether quantum neural networks suffer from the same phenomenon.

The study first addressed a simple question:

Do quantum neural networks preserve plasticity better than classical neural networks?

The answer appears to be yes.

Across continual learning experiments involving more than 3,000 sequential tasks, a remarkably consistent pattern emerged.

Classical neural networks steadily lost their learning ability as training progressed.

Quantum neural networks, in contrast, maintained a much higher level of plasticity throughout long training sequences.

But observing the phenomenon is only the beginning.

The more interesting question is:

Why does this happen?

Geometry Matters

To understand the difference, consider where the parameters of a neural network live.

Classical neural network weights inhabit ordinary Euclidean space. In principle, parameter norms can grow without bound.

During prolonged continual training, optimization often drives these parameters toward increasingly large magnitudes.

Initially, this helps fit the data.

Eventually, however, several undesirable effects emerge:

neurons become increasingly saturated,
effective gradients shrink,
parameter updates become harder,
the trace of the Fisher Information Matrix steadily decreases.

Together, these effects gradually reduce the model's ability to adapt to new tasks.

This suggests that loss of plasticity is fundamentally connected to the geometry of the parameter space.

Why Quantum Neural Networks Behave Differently

Quantum neural networks follow an entirely different geometric trajectory.

The reason is not a specially designed continual-learning algorithm.

Instead, it originates from one of the most fundamental principles of quantum mechanics.

Quantum evolution is described by unitary transformations.

Mathematically, the trainable parameters correspond to rotations on compact Lie groups.

Unlike Euclidean space, these parameter manifolds are compact.

Parameters can continue evolving indefinitely, but they cannot drift arbitrarily far away.

This geometric constraint naturally prevents the unbounded parameter growth observed in classical networks.

As a result,

gradients remain in a healthy range,
parameter norms stay bounded,
the Fisher Information Matrix remains active,
and the network continues to retain the ability to learn new tasks.

In other words, the advantage of quantum models may not come solely from having richer computational representations.

It may also arise from the geometry imposed by the laws of quantum physics.

Rather than expanding without limit, quantum parameters evolve on a compact manifold whose structure naturally protects learning plasticity over time.

This geometric explanation is arguably more interesting than reporting another benchmark improvement.

Instead of asking whether one model wins by a few percentage points on a particular dataset, it asks whether quantum and classical learning systems obey fundamentally different learning dynamics during long-term adaptation.

From Theory to Large-Scale Validation

A theoretical explanation is only convincing if it survives large-scale empirical testing.

To validate the proposed mechanism, the authors constructed multiple continual learning benchmarks involving

more than 3,000 sequential learning tasks,
quantum circuits with depths up to 30 layers,
and over 4,000 trainable quantum parameters.

These experiments are considerably more demanding than conventional machine learning benchmarks.

Each configuration effectively requires training thousands of quantum neural networks while continuously monitoring internal quantities such as gradient statistics and the Fisher Information Matrix throughout optimization.

Such experiments would be prohibitively slow—or simply infeasible—using many conventional quantum software frameworks.

The computational foundation of this work therefore relied heavily on TensorCircuit-NG, an open-source quantum computing framework that combines tensor-network simulation, automatic differentiation, and high-performance GPU acceleration. These capabilities make long-horizon, large-scale continual learning experiments computationally practical.

A Different Perspective on Quantum Advantage

This work does not claim that quantum neural networks have solved continual learning.

Catastrophic forgetting still exists, and many questions about memory retention, stability, and continual adaptation remain open.

Instead, the paper offers a different perspective on quantum advantage.

Discussions of quantum machine learning often emphasize computational speedups or asymptotic complexity advantages.

But real intelligent systems require more than fast learning.

They must also continue learning over time.

Continual learning requires both remembering what has already been learned and remaining capable of acquiring new knowledge.

Catastrophic forgetting addresses the first challenge.

Loss of plasticity addresses the second.

Both are essential.

If quantum neural networks can naturally preserve their capacity to learn throughout long-term adaptation—not because of additional engineering tricks, but because of the geometry dictated by quantum mechanics—then this "ageless" plasticity may represent a compelling and fundamentally different form of quantum advantage.

Reference

Chen, Y.-Q., & Zhang, S.-X. (2026). Intrinsic Preservation of Plasticity in Continual Quantum Learning. PRX Quantum, 7, 033003.

The Two Paradigms of Scientific Computing Agents: Abstraction, Openness, and "The Bitter Lesson"

Shixin Zhang — Mon, 22 Jun 2026 13:05:07 +0000

In recent years, the rapid evolution of Large Language Models (LLMs) has turned "AI + Scientific Computing" into a highly active frontier. Whether in molecular dynamics, material and drug design, or quantum computing, numerous platforms are attempting to bridge natural language interfaces with rigorous scientific computation.

From a user experience perspective, this approach significantly lowers the barrier to entry, allowing non-experts to breeze through standardized experimental workflows. However, when we shift our focus from "Can it run a standard experiment quickly?" to "Does it support open-ended scientific exploration?", a stark architectural divide emerges regarding abstraction boundaries and system openness.

Currently, Scientific Computing Agent systems can be broadly categorized into two technical paradigms:

Encapsulated Systems: Running in controlled cloud sandboxes, these systems typically provide pre-configured, templated workflows accessible via a Web UI.
Open & Programmable Systems: Operating within general-purpose computing environments, these systems (like Claude Code or Codex) integrate deeply with code repositories, runtimes, and external toolchains.

While both rely on conversational interfaces, their core difference lies in their habitat: is the Agent living in a closed ecosystem of cloud templates, or an open, customizable computing space?

Abstraction Boundaries vs. The Space for Innovation

Every software system must strike a balance between ease of use and flexibility. For standardized scientific tasks, encapsulated systems shine. However, when a research question deviates from standard templates, the very abstraction that reduces complexity becomes a bottleneck.

Here is a clear comparison of the two paradigms:

Dimension	Encapsulated Systems	Open & Programmable Systems
Representative Examples	Domain-specific Web-based AI platforms	General-purpose agents like Claude Code, Codex
Execution Environment	Pre-defined, controlled cloud sandboxes; highly templated	General compute environments (native OS, containers, local/cloud)
Abstraction Boundary	High (Hides underlying engineering details)	Low (Direct access to file systems, low-level compute libraries, and dependencies)
Ideal Use Cases	Education, running standard algorithms, rapid benchmarking	Exploratory frontier research, highly customized workflows
Handling Novel Problems	Wait for platform updates, or revert to writing code manually	Break out of the framework; freely compose modules and custom logic

Take quantum computing as an example. For standard Variational Quantum Algorithms (VQAs), encapsulated Web platforms can easily handle the entire pipeline—from quantum circuit construction and parameter optimization to result visualization. By condensing complex engineering details into a few pre-built templates, users can complete experiments with minimal cognitive load.

But the moment a researcher’s needs veer off the beaten path, this abstraction hits a wall. Suppose a researcher wants to combine a novel data encoding method, a highly customized quantum gate structure, and a non-standard loss function. Because this bespoke architecture doesn't map to existing templates, the encapsulated system's API simply rejects it.

In contrast, open programmable systems support these novel combinations because they don't pre-define the shape of the problem; they merely provide computing primitives. In these environments, circuit construction, training loops, loss functions, and data pipelines are all exposed as raw code. An Agent (or researcher) can freely import new Python modules, alter the training loop, inject custom gradient estimation methods, or couple a quantum simulator with an external data pipeline. Because the system hasn't hardcoded these steps into indivisible blocks, a problem that breaks an encapsulated system is just another day of writing code for an open system.

Project Context and the Information Horizon

If architecture forms the skeleton of a system, context forms the Agent's horizon. The quality of an Agent's reasoning is inextricably tied to the scope of information it can access.

In real-world scientific computing, the "state" of a project is never just a few chat prompts or isolated data uploads. It is a massive, ongoing web of information: repository directory structures, historical scripts, local test datasets, related PDF papers, version control histories, and past error logs.

Constrained by cloud sandbox isolation, an encapsulated Agent's horizon is usually limited to the current ephemeral session; its understanding of state is fragmented. Conversely, in an open programmable system, an Agent like Claude Code operates as a first-class citizen within the compute environment. It can directly read the real-time state of the entire project directory. If a user asks to tweak an initialization parameter based on the last run, the open Agent can fetch historical logs, diff code versions, and execute reliable reasoning backed by full project context.

The difference is fundamental: is the Agent trapped in a single, isolated interaction, or is it embedded in the continuous information network of a real research project?

From Code Generation to Workflow Orchestration

Context dictates reasoning, but action drives results. Once an Agent grasps the global state, its capabilities expand from mere code generation to system-level orchestration. This is the second great divide between the two paradigms: the breadth of agency.

Scientific computing rarely stops at writing a single algorithm script. It is usually a complex workflow spanning multiple independent tools. Under the open paradigm, an Agent doesn't just write logic using native frameworks; it executes system-level operations. It can SSH into High-Performance Computing (HPC) clusters to submit jobs, set up cron jobs to monitor GPU utilization, read stack traces to auto-retry crashed experiments, clean data post-run, generate charts, and even draft the initial manuscript.

While encapsulated systems confine the Agent to a proprietary loop, open systems grant Agents cross-platform, cross-tool autonomy, turning them into genuine collaborators.

General Beats Specialized: The "Bitter Lesson" in the Agent Era

This transition from encapsulated to open, and from specialized cloud platforms to general programming environments, perfectly echoes Richard Sutton's famous essay, "The Bitter Lesson". Sutton observed that throughout AI history, specialized methods meticulously hand-crafted using human domain knowledge are ultimately surpassed by general methods that leverage massive computation.

This philosophy holds entirely true for AI in scientific computing. Today, many platforms pour immense resources into building highly specialized Agents for niche domains, designing bespoke UIs and rigid workflow templates. In the short term, these make for incredibly smooth demos.

However, as the capabilities of foundation models scale exponentially, general-purpose Agents (like Claude Code or Codex) are becoming overwhelmingly powerful. They don't need a specialized UI wrapper. Drop them into a standard, open computing environment, and their generalized reasoning allows them to read domain documentation on the fly, call low-level scientific libraries, and independently orchestrate complex analysis.

The meticulously hardcoded workflows of domain-specific Agents risk rapid obsolescence. Often, their domain capabilities struggle to keep pace with the generalized leaps made by foundation models.

Recognizing this, a new generation of scientific computing frameworks is aligning with the open paradigm. For instance, in the quantum computing space, TensorCircuit-NG is a prime example of embracing the general Agent route. It abandons traditional closed-platform UI wrappers in favor of a native AI stack, offering hyper-performance low-level primitives alongside out-of-the-box skill suites. Its core design philosophy is simple: empower general-purpose Agents to freely explore and orchestrate complex science within an open environment.

Conclusion

Encapsulated and open programmable systems represent two distinct technological philosophies. The former lowers the barrier to entry via high-level abstraction, playing a crucial role in education and standard reproducibility.

However, in uncharted, fast-moving frontier sciences, maintaining system openness and generality is paramount. Allowing increasingly capable general Agents to dive deep into real, low-level engineering environments—breaking free from rigid abstraction boundaries—is the most sustainable path for AI to truly revolutionize scientific computing.

PyTrees Are Not One Thing: JAX, PyTorch, and TensorFlow Compared

Shixin Zhang — Fri, 12 Jun 2026 06:18:20 +0000

PyTrees look deceptively simple. You flatten a nested Python object into leaves, keep a structure descriptor, and later rebuild or map over the same shape. That abstraction is powerful enough to carry optimizer states, model parameters, batched inputs, gradients, and sharding annotations. It is also just ambiguous enough that three major frameworks implement three subtly different languages under the same idea.

This note compares JAX jax.tree_util, PyTorch torch.utils._pytree, and TensorFlow tf.nest. I tested the behavior in two environments: an older stack with JAX 0.4.35, PyTorch 2.2.2, TensorFlow 2.20.0, and a newer stack with JAX 0.10.0, PyTorch 2.12.0, TensorFlow 2.21.0. Most flatten/unflatten semantics were stable across these versions. The main version-sensitive result is PyTorch: _pytree.tree_map in 2.2.2 accepts only one pytree, while 2.12.0 supports multiple pytrees and behaves much closer to JAX prefix-style mapping.

The short version: JAX treats pytrees as a transformation language, PyTorch is converging toward that model in torch.func, and TensorFlow exposes a broader nested-structure utility through tf.nest. Those differences show up exactly where backend-agnostic libraries usually hurt: None, dictionary order, custom containers, tree_map, autodiff, and vectorization.

The Shape Of The APIs

The three APIs have the same surface story but not the same contract.

from jax import tree_util as jtu
from torch.utils import _pytree as tpu
import tensorflow as tf

leaves, treedef = jtu.tree_flatten(tree)
tree = jtu.tree_unflatten(treedef, leaves)
tree = jtu.tree_map(f, *trees)

leaves, spec = tpu.tree_flatten(tree)
tree = tpu.tree_unflatten(leaves, spec)
tree = tpu.tree_map(f, tree)          # PyTorch 2.2.2
tree = tpu.tree_map(f, *trees)        # PyTorch 2.12.0

leaves = tf.nest.flatten(tree)
tree = tf.nest.pack_sequence_as(structure, leaves)
tree = tf.nest.map_structure(f, *structures)

Flattening means "which objects are leaves?" Unflattening means "what metadata is needed to reconstruct the original container?" Mapping means "what does it mean for several structures to match?" Those three questions are where the frameworks diverge.

JAX calls its structure descriptor a PyTreeDef, so treedef is the conventional variable name. PyTorch calls the analogous descriptor a TreeSpec, so examples and internals often name it spec. Conceptually they play the same role: they describe the container skeleton and the metadata needed to rebuild it from a flat leaf list. TensorFlow's tf.nest does not return a separate treedef object from flatten; instead, pack_sequence_as takes an existing nested structure as the template.

There is also a small argument-order trap. JAX unflattens as tree_unflatten(treedef, leaves), while PyTorch unflattens as tree_unflatten(leaves, spec). TensorFlow's equivalent is pack_sequence_as(structure, leaves).

A Compact Map Of The Differences

Case	JAX	PyTorch `_pytree`	TensorFlow `tf.nest`
Scalar	Leaf	Leaf	Leaf
`None`	Empty pytree, 0 leaves	Leaf	Leaf
`list`, `tuple`	Containers	Containers	Containers
namedtuple	Container, type-strict	Container, type-strict	Container, type-strict
plain `dict` order	Sorted keys	Insertion order	Sorted-key leaf order
`OrderedDict` order	Insertion order	Insertion order	Sorted-key leaf order
`defaultdict` order	Sorted keys	Insertion order	Sorted-key leaf order
`defaultdict.default_factory`	Preserved	Preserved	Preserved
custom `dict` subclass	Leaf unless registered	Leaf unless registered	Container
custom `list`/`tuple` subclass	Leaf unless registered	Leaf unless registered	Container
dataclass instance	Leaf unless registered	Leaf unless registered	Leaf by default
multi-arg `tree_map`	Supported, prefix semantics	PyTorch 2.2.2: not supported; PyTorch 2.12.0: supported with prefix semantics	Supported, strict same structure
unflatten arity mismatch	Raises `ValueError`	Raises `ValueError`	Raises `ValueError`

The rest of the note explains why these rows matter.

`None`: A Ghost Node In JAX, A Leaf Elsewhere

The cleanest way to feel the philosophical split is None. In JAX, None is not a value to map over. It is a zero-leaf structural marker.

jtu.tree_flatten(None)
# leaves: []
# treedef: PyTreeDef(None)

jtu.tree_map(lambda x: ("mapped", x), None)
# None

In PyTorch and TensorFlow, None is a leaf.

tpu.tree_flatten(None)
# [None]

tf.nest.flatten(None)
# [None]

tpu.tree_map(lambda x: ("mapped", x), None)
# ("mapped", None)

tf.nest.map_structure(lambda x: ("mapped", x), None)
# ("mapped", None)

The nested case makes the difference visible:

tree = [1, None, 3]

jtu.tree_flatten(tree)[0]
# [1, 3]

tpu.tree_flatten(tree)[0]
# [1, None, 3]

tf.nest.flatten(tree)
# [1, None, 3]

If None means "optional value absent", JAX treats it structurally. If None means "a value in my tree", PyTorch and TensorFlow are closer to that intuition.

Dictionaries: The Same Keys, Different Time Arrows

Plain dict is a container everywhere, but the traversal order differs. JAX sorts keys, PyTorch follows insertion order, and TensorFlow assigns leaves by sorted keys while preserving the original mapping order when rebuilding.

tree = {"b": 2, "a": 1}

jtu.tree_flatten(tree)[0]
# [1, 2]   # a, then b

tpu.tree_flatten(tree)[0]
# [2, 1]   # b, then a

tf.nest.flatten(tree)
# [1, 2]   # a, then b

Replacing the leaves with [10, 20] shows the reconstruction contract:

# JAX
{"a": 10, "b": 20}

# PyTorch
{"b": 10, "a": 20}

# TensorFlow
{"b": 20, "a": 10}

TensorFlow's result is the surprising one on first read. It maps values according to sorted keys, but prints in the original insertion order. The object order and the leaf assignment order are not the same concept.

Mixed incomparable key types are another consequence of sorting. JAX and TensorFlow fail on {1: "one", "2": "two"} because 1 < "2" is not defined. PyTorch does not sort and therefore flattens this case in insertion order.

jtu.tree_flatten({1: "one", "2": "two"})
# ValueError: Comparator raised exception while sorting pytree dictionary keys.

tf.nest.flatten({1: "one", "2": "two"})
# TypeError: '<' not supported between instances of 'str' and 'int'

tpu.tree_flatten({1: "one", "2": "two"})[0]
# ["one", "two"]

Ordered Containers Are Not Just Dicts With Better Manners

OrderedDict has explicit order metadata, and JAX treats that metadata as part of the tree structure. PyTorch uses insertion order too. TensorFlow again uses sorted-key leaf assignment.

from collections import OrderedDict

tree = OrderedDict([("b", 2), ("a", 1)])

jtu.tree_flatten(tree)[0]
# [2, 1]

tpu.tree_flatten(tree)[0]
# [2, 1]

tf.nest.flatten(tree)
# [1, 2]

All three preserve the OrderedDict type when rebuilding, but TensorFlow assigns replacement leaves by sorted key:

tf.nest.pack_sequence_as(OrderedDict([("b", 2), ("a", 1)]), [10, 20])
# OrderedDict([("b", 20), ("a", 10)])

Multi-argument mapping reveals another difference. JAX rejects two OrderedDicts with the same keys but different order because the custom node metadata differs.

a = OrderedDict([("b", 2), ("a", 1)])
b = OrderedDict([("a", 10), ("b", 20)])

jtu.tree_map(lambda x, y: (x, y), a, b)
# ValueError: Mismatch custom node data: ('b', 'a') != ('a', 'b')

TensorFlow accepts this and pairs by key while preserving the first structure's order. PyTorch 2.12.0 also accepts it and returns the same visible result:

OrderedDict([("b", (2, 20)), ("a", (1, 10))])

`defaultdict`: Losing The Type Changes Behavior

defaultdict is not a decorative subclass. It carries a default_factory, which changes lookup behavior.

from collections import defaultdict

counter = defaultdict(int)
counter["missing"]
# 0

plain = {}
plain["missing"]
# KeyError

All three frameworks preserve the default_factory, but they disagree about leaf order just as with dictionaries.

tree = defaultdict(int, {"b": 2, "a": 1})

jtu.tree_flatten(tree)[0]
# [1, 2]

tpu.tree_flatten(tree)[0]
# [2, 1]

tf.nest.flatten(tree)
# [1, 2]

Rebuilding with [10, 20] gives:

# JAX
defaultdict(int, {"a": 10, "b": 20})

# PyTorch
defaultdict(int, {"b": 10, "a": 20})

# TensorFlow
defaultdict(int, {"b": 20, "a": 10})

This matters for any pure Python fallback. If it flattens a defaultdict as a mapping but reconstructs a plain dict, it is wrong, not merely imprecise.

Custom Containers: Either Register Them Or Treat Them As Leaves

JAX and PyTorch are conservative about arbitrary subclasses. TensorFlow is more eager to recurse into sequence and mapping subclasses.

class MyDict(dict):
    pass

class MyList(list):
    pass

class MyTuple(tuple):
    pass

JAX and PyTorch treat these as leaves unless explicitly registered:

jtu.tree_flatten(MyDict({"b": 2, "a": 1}))[0]
# [MyDict({"b": 2, "a": 1})]

tpu.tree_flatten(MyList([1, 2]))[0]
# [MyList([1, 2])]

TensorFlow traverses them:

tf.nest.flatten(MyDict({"b": 2, "a": 1}))
# [1, 2]

tf.nest.flatten(MyList([1, 2]))
# [1, 2]

tf.nest.flatten(MyTuple((1, 2)))
# [1, 2]

Namedtuple is the standard exception. All three frameworks recognize it as a structural container and preserve its type. They are also strict about namedtuple type matching: Point(1, 2) is not the same structure as (1, 2) or RGB(1, 2).

The Real Trap: `tree_map` Does Not Always Mean Same-Structure Map

JAX tree_map uses the first argument as the reference structure. Later arguments are flattened "up to" that structure. If the first tree has a leaf, the corresponding value in a later tree may be an entire subtree.

jtu.tree_map(lambda x, y: (x, y), [1, 2], [[3], {"x": 4}])
# [(1, [3]), (2, {"x": 4})]

The first tree says: "I am a list of two leaves." Therefore the second tree only needs to be a list of two objects. Those objects are passed whole to the function.

The scalar case is even clearer:

jtu.tree_map(lambda x, y: (x, y), 1, [2, 3])
# (1, [2, 3])

jtu.tree_map(lambda x, y: (x, y), [1, 2], 3)
# ValueError: Expected list, got 3.

PyTorch 2.12.0 behaves similarly:

tpu.tree_map(lambda x, y: (x, y), [1, 2], [[3], {"x": 4}])
# [(1, [3]), (2, {"x": 4})]

tpu.tree_map(lambda x, y: (x, y), 1, [2, 3])
# (1, [2, 3])

tpu.tree_map(lambda x, y: (x, y), [1, 2], 3)
# ValueError: Node type mismatch; expected <class 'list'>, but got <class 'int'>.

PyTorch 2.2.2 did not support this multi-pytree call through _pytree.tree_map. TensorFlow supports multiple structures, but it requires strict structural equality:

tf.nest.map_structure(lambda x, y: (x, y), [1, 2], [[3], {"x": 4}])
# ValueError: structures do not have the same nested structure

Transform APIs: PyTree Support Is Not Just Flattening

Tree semantics matter most when they meet transforms. Here the frameworks differ again.

JAX transformations are natively pytree-based. grad accepts nested inputs and returns gradients with the same structure:

import jax
import jax.numpy as jnp

def f(params):
    return params["x"] ** 2 + params["y"][0] ** 3

params = {"x": jnp.array(2.0), "y": [jnp.array(3.0)]}
jax.grad(f)(params)
# {"x": Array(4., dtype=float32), "y": [Array(27., dtype=float32)]}

JAX vmap accepts nested pytree inputs too:

def g(params):
    return params["x"] + params["y"][0]

batched = {"x": jnp.arange(3.0), "y": [jnp.arange(3.0) + 10]}
jax.vmap(g)(batched)
# Array([10., 12., 14.], dtype=float32)

Because None is a zero-leaf node in JAX, it can sit inside a vmapped input without becoming a batched argument:

def h(params):
    return params["x"]

jax.vmap(h)({"x": jnp.arange(3.0), "y": [None]})
# Array([0., 1., 2.], dtype=float32)

Classic PyTorch autograd is different. torch.autograd.grad expects tensors or gradient edges as inputs, not an arbitrary nested pytree:

x = torch.tensor(2.0, requires_grad=True)
y = torch.tensor(3.0, requires_grad=True)
loss = x ** 2 + y ** 3

torch.autograd.grad(loss, (x, y))
# (tensor(4.), tensor(27.))

nested = {"x": x, "y": [y]}
torch.autograd.grad(loss, nested)
# RuntimeError: all inputs have to be Tensors or GradientEdges, but got str

The newer torch.func stack does understand nested pytree-like parameter structures:

from torch.func import grad, vmap

def f(params):
    return params["x"] ** 2 + params["y"][0] ** 3

params = {"x": torch.tensor(2.0), "y": [torch.tensor(3.0)]}
grad(f)(params)
# {"x": tensor(4.), "y": [tensor(27.)]}

def g(params):
    return params["x"] + params["y"][0]

batched = {"x": torch.arange(3.0), "y": [torch.arange(3.0) + 10]}
vmap(g)(batched)
# tensor([10., 12., 14.])

TensorFlow's transform support follows tf.nest. GradientTape.gradient accepts nested sources and returns gradients in the same structure:

x = tf.Variable(2.0)
y = tf.Variable(3.0)
nested = {"x": x, "y": [y]}

with tf.GradientTape() as tape:
    loss = nested["x"] ** 2 + nested["y"][0] ** 3

tape.gradient(loss, nested)
# {"x": tf.Tensor(4.0), "y": [tf.Tensor(27.0)]}

tf.vectorized_map also accepts nested input structures:

def g(params):
    return params["x"] + params["y"][0]

batched = {"x": tf.range(3.0), "y": [tf.range(3.0) + 10]}
tf.vectorized_map(g, batched)
# tf.Tensor([10. 12. 14.], shape=(3,), dtype=float32)

tf.function accepts nested structures as ordinary function arguments:

@tf.function
def f(params):
    return params["x"] ** 2 + params["y"][0] ** 3

f({"x": tf.constant(2.0), "y": [tf.constant(3.0)]})
# tf.Tensor(31.0, shape=(), dtype=float32)

The right summary is more specific: JAX transforms are pytree-native; PyTorch classic autograd is not, while torch.func is; TensorFlow transform APIs accept nested structures.

Closing

PyTrees are a small abstraction with a long tail. Simple examples make every framework look compatible; real optimizer states, optional values, ordered mappings, custom containers, and transform APIs expose the differences quickly.

TensorCircuit-NG vs cuQuantum on H200: JIT compilation beats the "magic GPU library" assumption

Shixin Zhang — Sun, 07 Jun 2026 02:02:29 +0000

NVIDIA cuQuantum has a strong reputation as the natural high-performance baseline for GPU quantum simulation. That reputation is understandable: cuQuantum contains serious low-level GPU libraries such as cuStateVec and cuTensorNet and it is NVIDIA who creates GPU and CUDA!

But in an end-to-end differentiable VQE workload, the result is more nuanced. On our H200 GPU benchmark, TensorCircuit-NG was substantially faster after compilation, while also offering a much higher-level and user-friendly programming model.

The short version:

cuQuantum is a powerful low-level library.
It is not automatically the fastest route for practical quantum simulation tasks.
Direct cuQuantum code is significantly more verbose and engineering-heavy.
TensorCircuit-NG pays a JAX compilation cost, but repeated value-and-gradient evaluations quickly amortize that cost.
The final running time of TensorCircuit-NG is much shorter than NVIDIA cuquantum.

Benchmark setup

We used the workload as in the script for 1D TFIM VQE task:

Hardware and software:

GPU: NVIDIA H200
TensorCircuit-NG: 1.6.0
JAX: 0.7.2
cuQuantum Python: 26.3.2
CuPy: 14.1.1
PyTorch: 2.11.0+cu128

We measured one warmup/compile call and then the mean of five later value-and-gradient calls.

Implementations compared

We tested two TensorCircuit-NG modes:

TC-JAX scan: uses scan over VQE layers to reduce JAX compilation/staging time.
TC-JAX unrolled: builds all layers directly. This produces a larger traced program, but can be faster after compilation.

We also tested two direct cuQuantum routes:

cuStateVec adjoint: applies gates with cuStateVec and computes the full gradient with adjoint differentiation. This is not parameter shift so it is a fair comparison.
cuTensorNet full-state autograd: contracts the full state with cuTensorNet, then computes the TFIM state-vector expectation on GPU with PyTorch autograd.

The cuTensorNet path is intentionally not the obviously bad version where every Pauli term gets a separate tensor-network path search. We first tried that more "TN-native" observable-contraction style, but for this workload it spent too much time in repeated graph/path overhead. The final version is closer to the state-vector expectation workflow used by the TensorCircuit-NG and MindQuantum benchmark.

Repeated value-and-gradient runtime

The table below reports the post-warmup runtime. This is the relevant metric for VQE-style optimization, where the same circuit structure is evaluated many times.

backend	14 qubits	20 qubits	24 qubits
TC-JAX scan	0.01201s	0.01616s	0.06374s
TC-JAX unrolled	0.00995s	0.01381s	0.02547s
cuStateVec adjoint	0.08036s	0.12061s	0.30142s
cuTensorNet full-state autograd	1.35677s	2.04291s	2.30414s

In repeated value-and-gradient calls, TensorCircuit-NG is faster than cuStateVec:

qubits	TC-JAX scan vs cuStateVec	TC-JAX unrolled vs cuStateVec
14	6.69x	8.08x
20	7.46x	8.73x
24	4.73x	11.83x

The gap is much larger against the cuTensorNet route for this particular state-vector expectation plus autograd workflow:

qubits	TC-JAX scan vs cuTensorNet	TC-JAX unrolled vs cuTensorNet
14	112.97x	136.36x
20	126.42x	147.93x
24	36.15x	90.46x

These numbers are the main point: cuQuantum is not a magic speed button. A library being close to CUDA, or being written by a GPU vendor, does not automatically make it the fastest end-to-end implementation for a differentiable quantum algorithm.

First-call cost and amortization

cuQuantum has much lower first-call overhead. This is expected: TensorCircuit-NG uses JAX JIT compilation, and that first call can be expensive.

So if the task is a single one-off circuit evaluation, cuQuantum's low startup cost is attractive. But VQE is usually not a one-off workload. It repeatedly evaluates the same circuit structure for many optimizer steps and often across multiple random initializations. In that regime, TensorCircuit-NG's first-call cost is easily amortized, and the much faster post-compilation runtime becomes the dominant factor.

There is also a useful TensorCircuit-NG tradeoff:

Use scan mode when compilation time matters.
Use unrolled mode when the same circuit will be evaluated many times and peak post-compilation throughput matters.

At 24 qubits, unrolled TensorCircuit-NG is about 2.50x faster than scan mode after compilation, but the first call is about 9x heavier.

Programming model

Performance is only half of the story. The programming model matters.

In TensorCircuit-NG, the benchmark is expressed as circuit code:

c = tc.Circuit(n)
c.h(range(n))
for layer in range(depth):
    for i in range(n - 1):
        c.rzz(i, i + 1, theta=params[layer, 0, i])
    for i in range(n):
        c.rx(i, theta=params[layer, 1, i])

value_and_grad = tc.backend.jit(tc.backend.value_and_grad(energy_fn))

With direct cuQuantum, the user has to manually manage much lower-level details:

gate matrices and their dtype conventions
state-vector memory
cuStateVec binding signatures
tensor-network modes
PyTorch operands for autograd
GPU synchronization
version-specific API behavior

cuQuantum is valuable, but it is closer to a low-level engine than a high-level quantum algorithm framework. For a researcher, that difference is very real.

Takeaway

This benchmark does not prove that cuQuantum is slow for every task. What this benchmark does show is narrower and more practical:

For VQE workload, direct cuQuantum was not the fastest end-to-end route. TensorCircuit-NG provided a much simpler programming interface and substantially faster repeated value-and-gradient evaluations after JAX compilation.

The common assumption that "NVIDIA controls CUDA, therefore cuQuantum must be the fastest implementation" is too simplistic. Raw GPU kernels matter, but so do JIT compilation, autodiff integration, graph-level optimization, and the abstraction level exposed to users.

TensorCircuit-NG's advantage is that it lets users write concise quantum-program code while still compiling to high-performance backend-native tensor programs. For repeated VQE-style workloads, that combination can beat direct cuQuantum both in usability and in runtime.

DEV Community: Shixin Zhang

When High-Level Abstractions Become the Bottleneck: Quantum Scientific Computing in the AI Era

A framework is a theory of scientific work

Quantum–AI scientific computing as one infrastructure

Performance reveals the architecture

The organization encoded in the stack

The default for advanced projects

References

Tensor Networks Do Not Mean Approximate Simulation: The Right Way to Understand TensorCircuit-NG

Tensor Networks Are Not an Approximation Algorithm

Circuit in TensorCircuit-NG: Exact Contraction of Complete Circuits

Compared with State-Vector Simulators, Where Does the Speedup Come From?

DMCircuit: Complete Density-Matrix Simulation Based on Tensor Networks

MPS Is One Special Form of Tensor Network

Beyond the Three Main Modes: More Native Simulators

Why I Developed TenCirPauli

Framework selection creates a performance profile

Where the JAX model becomes expensive

Why Rust is a useful complement

What this implies for Pauli computation

The functionality follows from the runtime choice

From physical models to canonical operators

From operators to measurements and structural information

From one operator to several execution targets

From circuits to observable execution and gradients

What the Early Benchmarks Show

The larger lesson

From Parameter Tuning to Cross-Paradigm Exploration: Quantum Control Enters the Era of “Autopilot”

Beyond Closed Optimization Spaces: How QOC-Workbench Works

1. Human experts define the physical boundary

2. LLM performs cross-paradigm exploration

3. Physics solvers provide rigorous validation

4. Memory engine turns experiments into reusable knowledge

Three Levels of Evolution: From Pulse Shaping to Neural Control Generators

Case 1: Designing Hardware-Compatible Control Pulses

Rydberg Atom Arrays

Case 2: Redesigning Many-Body Evolution Paths

XXZ Spin Chains

Case 3: Breaking the Scaling Barrier with Neural Generators

2D Random-Field Ising Models

Conclusion: Let Physicists Return to Physics

Training a 1,000-Qubit, 40,000-Parameter Quantum Algorithm with Full Gradients Using TensorCircuit-NG

Introduction

Performance Comparison: Three Physical Perspectives

Contraction Path Metrics: FLOPs, Max Tensor, and Write

Perspective 1: Global Contraction Tree — Brute-Forcing the Entire Graph

omeco vs. cotengra: Two Path-Search Frameworks

The Efficiency Limits of Slicing

Perspective 2: Local Causal Sliding Window — Exploiting Local Physics

Perspective 3: Spatial Transfer Matrix — Lossless Exact Scanning

Counterintuitive Acceleration: Trading Compute for Bandwidth

Pitfalls to Avoid

Full 1,000-Qubit VQE: From Single-Step Gradients to End-to-End Optimization

Conclusion

Large-Scale TensorCircuit Contractions on GPUs: Disabling XLA GPU Autotuning

Key takeaway

Representative results

Why the final peak is unchanged for the 28 × 14 case

Interpreting peak memory

Why the first GPU may use more memory in multi-GPU processes

Practical recommendations

When Quantum Dynamics Doesn't Start from Zero: Completing the Missing Half of Entanglement Growth | PRL

Two ways to increase entanglement

Build: Creating new entanglement

Move: Transporting existing entanglement

The intuitive expectation

MBL breaks the rule

A "pure transport" experiment

Looking beyond a single bipartition

A new perspective on entanglement dynamics

Reference

Can AI Really Write Quantum Computing Code? Introducing ORBIT-Q: A Dual-Axis Benchmark for AI Agents and Quantum Software Frameworks

Why Existing Benchmarks Are Not Enough

ORBIT-Q: A Dual-Axis Benchmark

Axis 1: Agent Evaluation

Axis 2: Framework Evaluation

Preventing "Cheating"

Results: Which Frameworks Work Best?

Results: Which AI Agents Perform Best?

An Unexpected Observation: Safety False Positives

`Circuit` in TensorCircuit-NG: Exact Contraction of Complete Circuits

`DMCircuit`: Complete Density-Matrix Simulation Based on Tensor Networks

`None`: A Ghost Node In JAX, A Leaf Elsewhere

`defaultdict`: Losing The Type Changes Behavior

The Real Trap: `tree_map` Does Not Always Mean Same-Structure Map