DEV Community: Shixin Zhang

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.

Why JAX Is a Much Better Backend for Quantum Circuit Simulation Than PyTorch

Shixin Zhang — Sat, 06 Jun 2026 05:01:36 +0000

Modern quantum circuit simulation is not just “machine learning with complex tensors.” It involves irregular tensor contractions, sparse operators, statevector transformations, and automatic differentiation through all of them. This makes backend choice unusually important. A backend that is excellent for standard neural-network layers may still be a poor fit for general quantum simulation workloads.

We benchmarked this with a simple VQE workload for the 1D transverse-field Ising
model as in the script,

H = -sum_i Z_i Z_{i+1} - sum_i X_i,

using 20 qubits, 10 ansatz layers, complex64 precision, and one NVIDIA RTX 5090 GPU.

Results

Backend	Compile / Warmup	Value+Grad Runtime
TensorCircuit-NG, JAX backend	53.53 s	0.0265 s
TensorCircuit-NG, PyTorch backend	0.48 s	0.3299 s
TorchQuantum, optimized implementation than default	0.81 s	0.4172 s

The JAX backend is about 12.4x faster than TensorCircuit-NG’s PyTorch backend and about 15.7x faster than TorchQuantum for the post-compilation value-and-gradient step.

The compile time tells the other half of the story: JAX pays a much larger upfront XLA compilation cost. But after compilation, XLA produces a far more effective execution plan for this quantum simulation workload. This is exactly the tradeoff we want in VQE, QAOA, time evolution, and many other iterative algorithms: pay once, run many times.

Why This Happens

Quantum circuit simulation stresses a backend differently from ordinary deep learning. The workload mixes tensor-network contraction, sparse Hamiltonian application, and reverse-mode differentiation. JAX/XLA is designed to see the whole computation and optimize it aggressively as a compiled program on the target device.

PyTorch, in contrast, is strongest where the workload resembles standard neural network layers. For more general tensor programs, especially tensor-network-like simulation code, the compiler stack is less aggressive and less predictable.
In this benchmark, the same TensorCircuit-NG algorithm is more than an order of magnitude faster on JAX than on PyTorch after compilation.

A Note on TorchQuantum

We also compared against TorchQuantum as a representative PyTorch-native quantum circuit package. To make the comparison generous, we did not use its generic Pauli-string expectation path. That built-in route tends to materialize dense Pauli operators and is slow and not scalable. Instead, we implemented a TFIM-specific expectation directly extracted from state:

ZZ terms are evaluated from probabilities and precomputed sign tensors.
X terms are evaluated by flipping the state axis and taking an inner product.

This is already a substantial low-level optimization Even with that help, TorchQuantum remains slower than TensorCircuit-NG on the JAX backend by about 15.7x. And even if you prefer PyTorch backend, PyTorch backend from TensorCircuit-NG is still a better choice in terms of both warm-up and run times.

Takeaway

The lesson is not merely that one package is faster than another. The deeper point is that backend architecture matters. Quantum simulation benefits from a compiler that can optimize a whole differentiable tensor program, not just a collection of familiar machine-learning layers.

For TensorCircuit-NG, the JAX backend gives exactly that: a high-level quantum programming interface backed by XLA’s aggressive compilation. The result is a backend that is not only elegant for research code, but also dramatically faster for real differentiable quantum simulation workloads.

TensorCircuit-NG: How to Tell Whether a Quantum x AI x HPC Platform Is Truly Mature When Everyone Tells the Same Story

Shixin Zhang — Thu, 04 Jun 2026 08:28:33 +0000

In recent years, the convergence of quantum computing, artificial intelligence (AI), and high-performance computing (HPC) has become a central theme in the evolution of scientific computing infrastructure. From AI4Science and quantum machine learning to supercomputing centers and heterogeneous computing platforms, phrases such as "Quantum x AI x HPC", "integrated quantum-supercomputing-intelligence infrastructure", and "next-generation research infrastructure" now appear frequently in academic conferences, industry forums, and corporate presentations.

At the same time, a clear pattern has emerged:

The messaging is becoming increasingly similar, while the actual technical depth of different products varies dramatically.

Whether the subject is a quantum software platform, an AI4Science infrastructure stack, or a heterogeneous computing framework, many projects now describe themselves in similar terms:

integrating quantum computing with AI;
supporting heterogeneous computing resources;
serving as future research infrastructure;
enabling applications in materials science, chemistry, biomedicine, and other industries;
building an open ecosystem and developer community.

These directions are meaningful. In fact, they are becoming part of the field's shared consensus.

The real question is different:

When everyone is telling a similar story, how can we tell whether a platform has actually delivered technical substance, rather than remaining at the level of conceptual packaging and slideware?

For scientific infrastructure, it is more useful to ask five verifiable questions than to focus on slogans:

Is it open source?
Does it provide public benchmarks?
Is it used continuously by high-quality research communities?
Has it supported real industry-oriented application cases?
Does it continue to evolve through sustained version updates?

Any platform that claims to be "next-generation research infrastructure" should be able to answer these questions in a concrete way.

The development of TensorCircuit-NG offers a useful case study. Its value does not lie only in proposing a vision for "Quantum x AI x HPC"; it lies in a body of work that can be inspected, reproduced, cited, extended, and tested over time: open code, reproducible performance evaluations, a visible record of academic adoption, evidence of industry spillover, and six years of engineering iteration.

1. Is It Open Source?

For scientific software, open source means more than publishing code.

It means that:

the technology can be independently verified;
performance claims can be reproduced;
algorithms can be inspected;
users can deploy the software without relying on a closed service;
third-party researchers can repeat experiments under their own conditions.

Research communities do not lack polished presentations. What is much rarer is a technical system that can survive independent inspection.

TensorCircuit was not released as a one-off code dump. Its development forms a traceable engineering trajectory: from the original personal open-source version, to the version developed during the Tencent Quantum Lab period, and then to the currently maintained TensorCircuit-NG project. Across these stages, the core code, documentation, tests, and examples have remained open. The GitHub history preserves the development record, with more than 500 combined stars and forks, over 2,700 commits, more than 30 released versions, and contributions from over 30 developers around the world.

In terms of engineering scale, TensorCircuit-NG is no longer a short-term proof-of-concept project. It is a platform-level scientific computing system, with roughly 70,000 lines of code, type annotations, unit tests, continuous integration, documentation, and tutorials. The repository currently contains close to one thousand test functions. These tests are not merely a coverage metric; they are part of the engineering foundation that keeps APIs stable, backend behavior consistent, and long-term maintenance manageable.

The surrounding ecosystem matters as well. TensorCircuit-NG provides documentation, more than 30 tutorial examples, over 170 application examples, more than 10 benchmark suites, and a companion quantum computing tutorial. Together, these resources form a developer ecosystem that is learnable, reusable, and extensible. The platform also embraces AI-native workflows by providing AI skill packages for paper reproduction, code translation, and performance optimization. This means TensorCircuit-NG is not only designed for human developers; it is also adapting to a new mode of scientific software development in which AI agents participate directly in research workflows.

Another measurable signal of open-source adoption is installation and use. TensorCircuit-related packages include tensorcircuit, tensorcircuit-ng, and the nightly package tensorcircuit-nightly on PyPI, with cumulative pip install downloads exceeding one million. Download counts alone do not prove scientific value, but they do show that the platform exists in real development environments, not only in papers or promotional pages.

For research infrastructure, credibility comes from the ability of third-party users to run the code, inspect the implementation, reproduce experiments, and build their own workflows. Code is always more honest than marketing material.

2. Are There Public Benchmarks?

Every computing platform eventually has to answer a simple question:

Does it actually improve computational efficiency?

This is why public benchmarking is essential for judging platform maturity. In a high-performance setting such as "Quantum x AI x HPC", claims about acceleration, heterogeneous execution, or scalability are difficult to evaluate without reproducible benchmarks.

One of the earliest reasons TensorCircuit attracted attention was its benchmark system for differentiable quantum computing and tensor-network simulation. The first TensorCircuit white paper was published in Quantum: TensorCircuit: a Quantum Software Framework for the NISQ Era. The paper introduced the platform architecture, core functionality, and performance advantages, and compared TensorCircuit against several mainstream quantum software frameworks on variational quantum algorithms, gradient computation, and quantum circuit simulation.

The work made clear why unified tensor programming, automatic differentiation, and just-in-time compilation matter for quantum computing workflows. In several variational quantum algorithm and gradient computation tasks, TensorCircuit demonstrated significant performance advantages over representative frameworks such as IBM's Qiskit and PennyLane, with speedups reaching multiple orders of magnitude in some cases. More importantly, these results were not confined to figures in a paper: the code, experimental setup, and evaluation procedures were made reproducible. That is the difference between a verifiable technical path and an unverifiable performance claim.

With the release of TensorCircuit-NG, the benchmark scope has expanded toward problems closer to future research infrastructure:

GPU-accelerated computing;
optimized tensor-network contraction;
distributed HPC environments;
unified computation graphs spanning quantum circuits, neural networks, and tensor networks.

The NG white paper further summarizes TensorCircuit's upgrade toward the integration of quantum computing, supercomputing, and intelligent computing; see the preprint. The focus has shifted from "how to simulate quantum circuits faster on a single machine" to "how to organize quantum, AI, and numerical computing workflows in realistic heterogeneous research environments."

External evaluation provides another layer of evidence. NVIDIA used TensorCircuit as a third-party quantum software case in its cuQuantum 23.10 benchmarking context. This shows that TensorCircuit has entered the evaluation landscape of hardware and high-performance computing vendors. For scientific infrastructure, such external benchmarks complement open papers and are more persuasive than slide-based claims.

3. Is It Used by the Research Community?

For scientific infrastructure, the hardest signal to fake is not performance.

It is sustained use by serious research communities.

A platform can gain short-term attention through marketing, but it cannot gain long-term citations through marketing alone. Research adoption is a form of long-horizon voting. If a platform continues to support high-quality work across institutions, research areas, and teams, then it has demonstrated real utility.

More than 170 academic works have cited TensorCircuit, and in the first five months of 2026 alone, more than 40 works have already cited it. More importantly, these works are not concentrated in a single niche. They span quantum simulation, quantum machine learning, quantum chemistry, quantum sensing, quantum architecture search, and AI4Science.

Quantum Simulation and Many-Body Systems

In many-body quantum physics, condensed matter systems, and complex quantum dynamics, researchers often need large-scale quantum circuit simulation, tensor-network contraction, and differentiable optimization. These tasks place high demands on performance, numerical stability, and automatic differentiation.

Representative works include Zero and Finite Temperature Quantum Simulations Powered by Quantum Magic from teams including NVIDIA, Google, MIT, and Harvard; Exploring nontrivial topology at quantum criticality in a superconducting processor from Haohua Wang's group at Zhejiang University; and Variational LOCC-assisted quantum circuits for long-range entangled states from Xiongfeng Ma's group at Tsinghua University. These papers show that TensorCircuit is not limited to abstract algorithm demonstrations; it is being used in concrete problems in many-body physics and experimental quantum information.

Quantum Machine Learning

Quantum machine learning is one of the most active application areas for TensorCircuit. Representative papers include Understanding quantum machine learning also requires rethinking generalization from Jens Eisert's group at the Free University of Berlin, Dynamical transition in controllable quantum neural networks with large depth from teams including Liang Jiang and Junyu Liu, Generative Quantum Machine Learning via Denoising Diffusion Probabilistic Models from Quntao Zhuang's group at the University of Southern California, and IBM Quantum's Dynamic parameterized quantum circuits: expressive and barren-plateau free.

These works all require stable workflows connecting parameterized quantum circuits, gradient computation, model training, and numerical simulation. TensorCircuit's value is visible precisely at this workflow level: it connects quantum circuit simulation, automatic differentiation, and machine learning training into a unified programmable system.

Quantum Architecture Search and Algorithm Design

TensorCircuit has also been used in algorithmic and learning-theoretic research. Examples include Learning Quantum States and Unitaries of Bounded Gate Complexity from Caltech and Google, Quantum Machine Learning Architecture Search via Deep Reinforcement Learning from Brookhaven National Laboratory, and Distributed quantum architecture search from Luzhou Li's group at Sun Yat-sen University.

This class of work highlights the platform's infrastructure role. Researchers are not merely calling a fixed algorithm; they are building new search strategies, learning processes, and experimental protocols on top of TensorCircuit.

Quantum Chemistry and Fermionic Simulation

The quantum chemistry ecosystem around TenCirChem further extends TensorCircuit's application boundary. Quantum chemistry and fermionic simulation typically require complex Hamiltonian construction, differentiable optimization, tensor-network representations, and high-performance simulation. They therefore provide a demanding test case for any scientific computing platform.

Representative works include Efficient quantum simulation of electron-phonon systems by variational basis state encoder from teams at Tsinghua University and The Chinese University of Hong Kong, Shenzhen, as well as Fast Emulation of Fermionic Circuits with Matrix Product States from Garnet Chan's group at Caltech. These studies show that the TensorCircuit ecosystem has moved from general quantum circuit simulation into more specialized domains such as quantum chemistry.

Quantum Sensing and Imaging

TensorCircuit has also been used in quantum sensing, imaging, and experiment-facing tasks. Examples include End-to-end variational quantum sensing from Roger Melko's group at the Perimeter Institute, and Practical advantage of quantum machine learning in ghost imaging from Guihua Zeng's group at Shanghai Jiao Tong University. These works illustrate the platform's potential in quantum sensing and measurement-related applications.

The value of a research platform is not captured by a single paper. It is reflected in its ability to support many research directions over time. More than 170 citing works, users across high-level institutions, and multiple examples in leading journals and conferences form an evidence chain that is stronger than any single promotional claim.

4. Has It Supported Industry-Oriented Applications?

Academic citations show whether a platform can support research. Industry-oriented application cases show whether it can move toward real-world problems.

It is important to be precise here. Quantum computing is still exploratory in many industrial contexts, so the right question is not whether it has already replaced classical solutions at scale. The better question is whether researchers and engineering teams in different fields have used the platform to build prototypes, workflows, and validation pipelines for real problem domains. From this perspective, TensorCircuit's application spillover already reaches multiple sectors.

In agricultural diagnostics, researchers have used a quantum vision transformer for tomato leaf disease detection; see Enhancing Agricultural Diagnostics: Tomato Leaf Disease Detection Using Quantum Vision Transformer. In neuroscience and medical imaging, related works include Predicting Brain Age and Gender from Brain Volume Data Using Variational Quantum Circuits and Expanding the Horizon: Enabling Hybrid Quantum Transfer Learning for Long-Tailed Chest X-Ray Classification. In drug discovery, A hybrid quantum computing pipeline for real world drug discovery explores a hybrid quantum computing workflow for real drug discovery problems.

TensorCircuit-NG has also appeared in security, communications, optimization, and computing systems. In software security, researchers have proposed lightweight quantum convolutional neural networks for malicious code detection. In drone and radar applications, hybrid quantum neural networks have been explored for radar return signal processing. In edge computing, quantum reinforcement learning has been used for joint resource allocation and task offloading. In finance, improved QAOA methods based on conditional value-at-risk have been studied for portfolio optimization. The significance of these cases is that they move quantum software frameworks from "quantum algorithm papers" into concrete domains such as agriculture, medicine, security, communications, finance, and drug discovery.

External recognition provides additional context for the ecosystem. TensorCircuit has appeared in PhotonBox's 2022 list of influential quantum industry events in China, was listed as a recommended quantum software project in Google Summer of Code 2023, was used by NVIDIA in cuQuantum evaluation materials, was invited to participate in UnitaryHack 2024, and participated in Open Source Promotion Plan 2025. These forms of recognition do not replace technical validation, but they do show that TensorCircuit is not an isolated lab project. It has entered the public view of the open-source quantum software and high-performance computing ecosystems.

Industrial maturity does not happen overnight. It typically moves from research prototypes, to open tools, to cross-domain collaboration, to engineering validation, and eventually to deployment. TensorCircuit-NG's current value lies in providing a reusable low-level toolchain for that process.

5. Does It Continue to Evolve?

One defining feature of scientific infrastructure is that it is never finished.

New hardware appears. New algorithms appear. New scientific demands appear. This makes sustained iteration more important than a single innovation.

TensorCircuit's history is a good example. The project was first released in April 2020. From 2020 to 2021, TensorCircuit completed its core architecture, automatic differentiation mechanism, and early quantum algorithm modules, establishing the academic foundation for a unified tensor-computing framework. From 2021 to 2024, under the Apache License 2.0, the project continued to evolve in engineering: performance optimization, interface standardization, multi-backend support, and community ecosystem development gradually turned it into an open-source platform for global research users and developers.

Since the launch of TensorCircuit-NG, or "Next Generation", in 2024, the project has moved beyond a quantum computing software framework toward a broader next-generation research infrastructure. It explores deeper integration among quantum computing, supercomputing, and intelligent computing, while continuing to expand its ecosystem in AI4Science and related areas.

Sustained iteration is also visible in upstream and downstream ecosystem contributions. Upstream, core developers have contributed to standard machine learning frameworks such as TensorFlow, including work related to the automatic differentiation formula for complex-valued singular value decomposition and fixes to vectorized matrix multiplication. In the tensor-network ecosystem, TensorNetwork-NG continues to maintain the original Google TensorNetwork framework and keep it usable. Downstream, TenCirChem extends TensorCircuit capabilities into quantum computational chemistry workflows.

These upstream and downstream contributions show that TensorCircuit-NG does not confine itself to a single framework. Instead, it builds connections among machine learning, tensor networks, quantum chemistry, and high-performance computing. This matters for Quantum x AI x HPC integration, because future research infrastructure cannot serve only one model family, one hardware type, or one class of algorithms.

In the TC-NG architecture:

quantum circuits;
neural networks;
tensor networks;

are brought into a unified computation-graph system.

At the same time:

CPUs;
GPUs;
HPC clusters;
QPUs;

are becoming part of a unified resource pool.

This marks a shift in platform positioning: from a quantum software framework to infrastructure for future scientific computing. Compared with projects that remain at the stage of concept demonstrations, short-term packaging, or slide-based roadmaps, more than six years of open-source development, continuous iteration, and repeated research-community validation say much more about a platform's real engineering capacity and long-term value.

Conclusion: What Builds Trust in Scientific Infrastructure?

In the rapid development of Quantum x AI x HPC, industry narratives are converging.

More and more platforms now talk about:

AI4Science;
hybrid quantum-classical computing;
scientific research infrastructure.

These directions are worth pursuing. But for users, researchers, and industry partners, the core criteria have not changed:

Is the platform fully open source?

Does it provide public benchmarks?

Is it broadly and continuously used by high-quality research communities?

Has it supported cross-industry application cases?

Does it continue to evolve through sustained version updates?

Once these questions are answered one by one, the value of a platform does not need to depend on slogans or conceptual messaging. For scientific infrastructure, long-term trust is built on verifiable code, reproducible experiments, growing academic adoption, application spillover into real problems, and engineering iteration that stands the test of time. In an era where technical narratives increasingly sound alike, these qualities are especially valuable.

TensorCircuit-NG: Quantum Software On AI, For AI, With AI

Shixin Zhang — Wed, 27 May 2026 11:02:16 +0000

Quantum computing and artificial intelligence are often discussed as two separate frontiers. One is about exploiting quantum mechanics for computation; the other is about building increasingly capable learning systems and agents. The core argument behind TensorCircuit-NG is that this separation is becoming less and less meaningful. If modern AI infrastructure has already solved core problems around automatic differentiation, compilation, accelerator execution, batching, and distributed training, then quantum software should stop reinventing those layers badly and start standing on top of them directly.

This is the central idea behind TensorCircuit-NG. The project is a quantum software stack built in the age of AI, aimed at AI-facing workloads, and increasingly shaped for collaboration with AI agents. Its vision is simple: quantum software on AI, for AI, with AI.

On AI: quantum software should inherit the AI stack

Quantum software has long been held back by two familiar problems. Too much of the workload remains trapped in Python-level control flow or in classical state-vector simulation patterns that scale poorly. At the same time, many quantum libraries sit outside the deep learning ecosystems where most of the tooling innovation has happened. JAX, PyTorch, and TensorFlow already have mature answers to questions like compilation, vectorization, accelerator placement, and distributed execution, yet quantum software has often kept those capabilities at the edge of the stack.

TensorCircuit-NG takes a different route. The framework treats quantum circuits as specialized tensor operations. That design choice opens up a large part of the AI toolchain almost “for free.” Automatic differentiation maps naturally onto variational quantum algorithms. Just-in-time compilation matters for repeated circuit evaluation. Vectorized mapping matters for batching over parameters, measurements, trajectories, or datasets. Accelerator support, mixed precision, and distributed execution are part of the design from the beginning.

That philosophy shows up in the architecture. TensorCircuit-NG is built around a tensor-first worldview: every object is either a tensor or a network of tensors. Once that is the primitive, different computational models become easier to compose inside one workflow. Gate-based circuits, tensor networks, neural models, noisy simulators, analog evolution, approximate methods, and symbolic representations can live inside one coherent environment.

The performance story follows directly from this design. TensorCircuit-NG supports both data parallelism and model parallelism across multiple devices and multiple hosts. In practice that means distribution over inputs, measurements, or noisy trajectories when the workload is embarrassingly parallel, and distribution over tensor-network slices when the contraction itself needs to be split across hardware. Benchmarks on both single-GPU and multi-GPU systems show that high-level Python APIs can still deliver high performance when the compilation and tensor-network substrate are done well.In representative workloads, that performance has reached speedups of several orders of magnitude over mainstream stacks such as IBM's Qiskit and Google's TensorFlow Quantum.

TensorCircuit-NG acts as a bridge among quantum computing, high-performance computing, and intelligent computing. It also serves as an interface layer where quantum models can coexist with the rest of modern computational science. Researchers who want to embed quantum layers inside larger machine learning systems should be able to do so inside the same workflow, without crossing ecosystem boundaries every time the problem gets interesting.

For AI: a platform for fast quantum machine learning

This is where the infrastructure becomes immediately useful. Quantum machine learning sits right at the intersection of circuit design, optimization, data pipelines, and repeated simulation. It is a workload that punishes slow software. If researchers want to try new ansatzes, change encodings, run ablations, train over many seeds, or sweep hyperparameters, then fast prototyping and efficient simulation matter more than slogans about QML.

TensorCircuit-NG provides a strong platform for exactly this kind of work. Differentiable circuits, JIT compilation, batching, accelerator support, and distributed execution all live inside one environment. That makes it much easier to move from an idea for a QML model to a runnable prototype, and from a prototype to a meaningful simulation campaign.

The scientific motivation for QML also becomes clearer in this setting. Attention shifts away from isolated benchmark wins and toward how quantum models behave on problems that already hurt classical AI. In our own work, this has already led to two systematic studies: one on bad data, and one on changing data.

The first studies robustness. When labels are noisy, data is poisoned, or part of the training set later needs to be removed, quantum models may show a more favorable degradation profile and may be easier to unlearn. The second studies plasticity. In continual-learning settings, quantum models may preserve the ability to absorb new tasks for longer instead of becoming rigid.

These are still open research questions. For a software project, though, the main point is straightforward: if people want to explore QML seriously, they need a platform that makes rapid iteration cheap. TensorCircuit-NG is meant to be that platform. It gives researchers a practical environment for fast QML prototyping, efficient simulation, and large-scale testing of ideas about robustness, unlearning, and adaptation.

With AI: a platform for agent-driven research

The same logic carries over to AI agents. Once a scientific software stack is fast, structured, and composable, it becomes a natural substrate for agent-driven development. Agents are useful only when they can read real code, run real tools, inspect results, and keep iterating inside a live repository. That makes software design itself part of the agent story.

TensorCircuit-NG is built with that use case in mind. The APIs are relatively concise, the examples and tests provide dense reference material, and the repository includes explicit rules and task-specific workflows for AI assistants. This lowers the cost of turning natural-language intent into runnable code, benchmarks, figures, and documentation.

The project also ships built-in skills that push this further:

arxiv-reproduce, which turns a paper identifier into a reproduction workflow;
performance-optimize, which injects optimization patterns such as scan, jit, vmap, and contraction tuning;
tc-rosetta, which translates code from other quantum frameworks with attention to intent rather than syntax alone;
tutorial-crafter, which converts programs into polished narrative tutorials.
and many more.

Taken together, these tools make the framework a software platform where researchers can move from idea to prototype, from prototype to benchmark, and from benchmark to documentation with much less friction. That is the practical meaning of “with AI” here: TensorCircuit-NG is designed to work well with agents as a real development interface, not just as a chatbot wrapped around the codebase.

The deeper claim

Taken together, these ideas add up to a stack-level thesis about the future of computational research.

First, quantum software should no longer be architected as an isolated niche. It should inherit the best ideas from the AI and HPC worlds and expose them through abstractions that remain mathematically faithful to quantum workloads.

Second, that same software stack should provide a strong platform for fast QML prototyping and efficient simulation, so ideas about robustness, unlearning, and continual adaptation can be tested quickly at scale.

Third, the arrival of capable software agents changes the design target for scientific frameworks. A good framework now has to work well for skilled humans and also be understandable, navigable, and productively extensible for agents operating over the entire repository and toolchain.

This is how TensorCircuit-NG understands itself: quantum software on AI, for AI, and with AI. It is built on the modern AI execution model, aimed at AI-relevant scientific questions, and increasingly shaped to participate in agent-mediated research workflows.

Getting started

pip install tensorcircuit-ng

An agent-first workflow also works well: ask your coding agent to install tensorcircuit-ng and start building a small quantum application from natural-language instructions.

DEV Community: Shixin Zhang

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

The Economics of Scientific AI

Looking Ahead

The "Secret of Staying Young" in Quantum Neural Networks

AI's Midlife Crisis: Losing the Ability to Learn

Do Quantum Models Age More Slowly?

Geometry Matters

Why Quantum Neural Networks Behave Differently

From Theory to Large-Scale Validation

A Different Perspective on Quantum Advantage

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

Abstraction Boundaries vs. The Space for Innovation

Project Context and the Information Horizon

From Code Generation to Workflow Orchestration

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

Conclusion

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

The Shape Of The APIs

A Compact Map Of The Differences

None: A Ghost Node In JAX, A Leaf Elsewhere

Dictionaries: The Same Keys, Different Time Arrows

Ordered Containers Are Not Just Dicts With Better Manners

defaultdict: Losing The Type Changes Behavior

Custom Containers: Either Register Them Or Treat Them As Leaves

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

Transform APIs: PyTree Support Is Not Just Flattening

Closing

`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