<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Quantum Computing on JAX-TPU, Cryptography and Reverse engineering]]></title><description><![CDATA[Quantum Computing on JAX-TPU, Cryptography and Reverse engineering]]></description><link>https://ashitesh.me</link><generator>RSS for Node</generator><lastBuildDate>Sun, 11 Oct 2026 12:22:45 GMT</lastBuildDate><atom:link href="https://ashitesh.me/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Responsible Disclosure: How a Single Mobile Flaw Exposed  Million+ Student, Parent & Teacher Records Across India]]></title><description><![CDATA[Author: Ashitesh Kumar Singh (Class 12th Student & Independent Quantum Computing & Cryptography Researcher • GitHub)Category: Mobile Security / Reverse Engineering / Cloud Infrastructure / Responsible]]></description><link>https://ashitesh.me/responsible-disclosure-how-a-single-mobile-flaw-exposed-million-student-parent-teacher-records-across-india</link><guid isPermaLink="true">https://ashitesh.me/responsible-disclosure-how-a-single-mobile-flaw-exposed-million-student-parent-teacher-records-across-india</guid><category><![CDATA[cybersecurity]]></category><category><![CDATA[bugbounty]]></category><category><![CDATA[#infosec]]></category><category><![CDATA[Responsible Disclosure]]></category><category><![CDATA[CERTIn]]></category><category><![CDATA[DPDPA, Digital Personal Data Protection Act ]]></category><category><![CDATA[reverse engineering]]></category><dc:creator><![CDATA[Ashitesh]]></dc:creator><pubDate>Wed, 30 Sep 2026 10:05:56 GMT</pubDate><content:encoded><![CDATA[<blockquote>
<p><strong>Author:</strong> Ashitesh Kumar Singh (Class 12th Student &amp; Independent Quantum Computing &amp; Cryptography Researcher • <a href="https://github.com/AshiteshSingh">GitHub</a>)<br /><strong>Category:</strong> Mobile Security / Reverse Engineering / Cloud Infrastructure / Responsible Disclosure<br /><strong>Status:</strong> Remediated &amp; Officially Acknowledged by CERT-In</p>
</blockquote>
<hr />
<h2>📌 Executive Summary</h2>
<p>In July 2026, while in <strong>Class 12th</strong>, I was reverse engineering and analyzing the client-side architecture of a widely adopted Indian school enterprise resource planning (ERP) platform used by my own school. During this research, I uncovered an escalating vulnerability chain.</p>
<p>What began as an inspection of local caching on my personal student account quickly escalated into direct access to central cloud infrastructure, production databases, and master administrative accounts. The vulnerability exposed an estimated <strong>5 million+ citizen entities</strong> (a conservative baseline calculation factoring in all enrolled students, parents, and faculty across thousands of schools nationwide, with the actual real-world total likely being even higher), spanning over <strong>12 TB+ of sensitive records</strong>—including:</p>
<ul>
<li><p>Detailed personally identifiable information (PII) of minor students</p>
</li>
<li><p>Parent contact data &amp; financial records</p>
</li>
<li><p>Faculty dossiers &amp; master administrative credentials</p>
</li>
<li><p>Enterprise employee payroll and salary registers</p>
</li>
<li><p>Defense-affiliated school registries</p>
</li>
</ul>
<p>If an adversary had exploited this architecture, the private data of millions of students, parents, and teachers would have leaked across the country. Furthermore, the elevated access technically granted full write and update privileges—meaning I had the capability to <strong>manipulate exam marks, alter academic records, falsify attendance, and modify fee payment ledgers</strong>.</p>
<p>Rather than tampering with any records or exploiting this access, I immediately halted all database operations, prepared a reproducible Proof of Concept (PoC) for validation, and coordinated with <strong>CERT-In (Indian Computer Emergency Response Team)</strong>. Following formal verification and vendor remediation, CERT-In issued an official acknowledgment recognizing the responsible disclosure.</p>
<hr />
<h2>🔍 The Reality Check: An 8 GB Slice of My Own School</h2>
<p>To verify the scope of the vulnerability safely without intruding into unauthorized organizations, I restricted testing strictly to the tenant slice of my own enrolled school.</p>
<p>As a <strong>Class 12th student</strong> analyzing an application I used every day, this was no longer an abstract dataset or synthetic test entries—these were real-world production records belonging to my own classmates, friends, and teachers:</p>
<ul>
<li><p><strong>Complete Academic Profiles:</strong> Unrestricted access to classmates' full academic histories, raw exam marksheets, internal performance remarks, attendance logs, and disciplinary notes.</p>
</li>
<li><p><strong>Arbitrary Record Manipulation (Untouched):</strong> Elevated access carried write privileges that made it technically possible to arbitrarily alter exam scores, modify report cards, clear pending tuition fee dues, and tamper with student profiles. Adhering to strict ethical principles, <strong>not a single record was ever modified, falsified, or tampered with.</strong></p>
</li>
<li><p><strong>Intimate Identity Records:</strong> Direct visibility into student profile photos, residential home addresses, and linked national identity documents (including student and parent Aadhaar records and PAN details).</p>
</li>
<li><p><strong>Financial &amp; Banking Records:</strong> Parent bank account numbers, fee payment transactions, tuition billing histories, and saved card transaction tokens.</p>
</li>
<li><p><strong>Device Telemetry &amp; Expired Token Replay:</strong> Hardware identifiers, device models, OS versions, and push notification tokens. Critically, backend verification failed to enforce proper invalidation—allowing state queries and data retrieval through expired tokens and orphaned device sessions.</p>
</li>
</ul>
<blockquote>
<p>⚠️ <strong>Scope &amp; Scale:</strong> Querying the partition for just my own school accounted for approximately <strong>8 GB</strong> of sensitive data. Extrapolating this verified footprint across the <strong>thousands of educational institutions</strong> served by the platform nationwide—including several schools catering to families of Indian defense personnel—established an aggregate central data footprint exceeding <strong>12 TB+</strong> and upwards of <strong>5 million+ citizen records</strong> (calculated as a conservative lower bound across students, parents, and teachers, with the actual total likely to be even higher). If breached by a malicious threat actor, the personal and financial data of millions of students, parents, and educators would have been catastrophically leaked.</p>
</blockquote>
<hr />
<h2>🌐 The Full Scale of Exposure</h2>
<p>Beyond student and institutional records, deeper infrastructure routes revealed unrestricted access to central administrative systems:</p>
<pre><code class="language-text">[Student Mobile App]
        │
        ▼ (Static APK Analysis / JADX)
[Insecure SQLite Persistence (CWE-312)]
        │
        ▼ (Plaintext Operational AWS Keys Extracted)
[Internal 12-Hour Rotating Service APIs]
        │
        ▼ (Unrestricted IAM Escalation)
[Central Production Clusters (12 TB+ / 5M+ Records)]
   ├── Student &amp; Parent PII (Aadhaar, Marks, Bank Data)
   ├── Defense School Registries
   ├── Cleartext Master Admin Credentials
   └── Corporate HR, Payroll &amp; Employee Salaries
</code></pre>
<ul>
<li><p><strong>Master Admin Portals:</strong> Cleartext administrative passwords that allowed direct logins into multi-tenant master consoles across <strong>thousands of schools</strong>.</p>
</li>
<li><p><strong>Corporate &amp; Employee Data:</strong> Internal company payroll databases, staff salaries, HR files, and vendor configuration secrets.</p>
</li>
<li><p><strong>Defense School Assets:</strong> Confidential student and parent rosters for educational institutions operating under defense family welfare boards.</p>
</li>
</ul>
<hr />
<h2>⚙️ Technical Breakdown</h2>
<h3>1. Static Reverse Engineering &amp; APK Logic Inspection</h3>
<p>Applying static reverse engineering to the vendor's production Android APK (using <strong>JADX-GUI</strong> and <strong>APKTool</strong>) revealed that permanent root AWS keys were not hardcoded in the string pool. However, decompiling and reversing the client session management logic exposed a critical architectural flaw: upon successful authentication, operational credentials were written directly into local app cache files.</p>
<hr />
<h3>2. Dynamic Execution &amp; Insecure Local Persistence (CWE-312)</h3>
<p>Accessing an Android application's sandboxed internal database directory (<code>/data/data/</code>) normally requires root permissions on a device. Instead of rooting a physical smartphone, I utilized <strong>LDPlayer</strong> (with root mode enabled) as a controlled testing environment.</p>
<p>Authenticating through my legitimate personal student account inside the emulator, I inspected the app's internal database directory via ADB:</p>
<pre><code class="language-bash">adb shell
su
cd /data/data/&lt;package_name&gt;/databases/
sqlite3 local_cache.db
</code></pre>
<p>Querying the SQLite database confirmed the critical failure: <strong>The app stored active operational AWS Access Key IDs and Secret Access Keys in plaintext on client-side storage.</strong></p>
<hr />
<h3>3. Traversing the 12-Hour Rotating API</h3>
<p>The recovered credentials carried overly permissive IAM policies across the vendor's cloud environment:</p>
<ol>
<li><p>The keys granted direct interaction with an internal service routing gateway.</p>
</li>
<li><p>Within this subsystem, a secondary service API rotated access tokens every 12 hours.</p>
</li>
<li><p>Inspecting routing tables and endpoint responses exposed direct connection paths leading straight into the vendor's central production database clusters.</p>
</li>
</ol>
<hr />
<h3>4. Verification and Ethical Cessation</h3>
<p>Once the 8 GB institutional slice and the existence of multi-terabyte production tables were confirmed, all probing was terminated immediately:</p>
<ul>
<li><p>🚫 <strong>No data dumping:</strong> No tables were dumped, mirrored, or exfiltrated.</p>
</li>
<li><p>🚫 <strong>Zero data tampering:</strong> Marks, fees, attendance, and student profiles were never modified or altered.</p>
</li>
<li><p>🚫 <strong>Zero retention:</strong> No personal records of classmates, parents, or staff were retained.</p>
</li>
<li><p>🧹 <strong>Complete sanitization:</strong> All temporary debugging databases, tokens, and test logs were permanently wiped from the testing machine.</p>
</li>
</ul>
<hr />
<h2>⏱️ Disclosure Timeline</h2>
<table>
<thead>
<tr>
<th>Date</th>
<th>Milestone / Action</th>
</tr>
</thead>
<tbody><tr>
<td><strong>July 07, 2026</strong></td>
<td>Insecure client-side key storage discovered; personal school dataset and master cloud endpoints mapped.</td>
</tr>
<tr>
<td><strong>July 08, 2026</strong></td>
<td>Database scope (8 GB school slice / 12 TB+ total infrastructure across thousands of schools) verified; all probing halted immediately.</td>
</tr>
<tr>
<td><strong>July 09, 2026</strong></td>
<td>Initial report submitted; CERT-In replied requesting step-by-step video/screenshot PoC with active timestamp.</td>
</tr>
<tr>
<td><strong>July 10, 2026</strong></td>
<td>Non-destructive PoC submitted. CERT-In registered formal incident under official <strong>Ref: CERT-In [Redacted]</strong>.</td>
</tr>
<tr>
<td><strong>July – August 2026</strong></td>
<td>CERT-In coordinated remediation with the ERP vendor; cloud IAM policies tightened, client persistence removed, and DPDP consent framework planned.</td>
</tr>
<tr>
<td><strong>September 24, 2026</strong></td>
<td>CERT-In confirmed full remediation and issued an official Letter of Acknowledgment to <strong>Ashitesh Kumar Singh</strong>.</td>
</tr>
</tbody></table>
<hr />
<h2>🛡️ Verification Proofs &amp; CERT-In Correspondence</h2>
<h3>1. PoC Request with Active Timestamp (July 09, 2026)</h3>
<p>Following initial reporting, CERT-In's Incident Response team verified receipt and requested an active-timestamp validation proof:</p>
<img src="https://cdn.hashnode.com/uploads/covers/6a1ba7e37c924da4619da9bf/261fb0f5-d7ce-4a77-9f74-b16a26fb4102.png" alt="Screenshot 2026-09-30 145814" style="display:block;margin:0 auto" />

<hr />
<h3>2. Official Incident Registration (July 10, 2026)</h3>
<p>Upon receiving the step-by-step PoC, CERT-In formally registered the incident and assigned a case reference ID:</p>
<img src="https://cdn.hashnode.com/uploads/covers/6a1ba7e37c924da4619da9bf/19f40245-c390-42e4-bc20-7461bfd2b5e8.png" alt="Screenshot 2026-09-30 150119" style="display:block;margin:0 auto" />

<hr />
<h3>3. Formal Acknowledgment of Responsible Disclosure (September 24, 2026)</h3>
<p>Following vendor remediation and verification, CERT-In issued an official acknowledgment letter:</p>
<img src="https://cdn.hashnode.com/uploads/covers/6a1ba7e37c924da4619da9bf/44e86e93-1f85-4012-b0ca-eeb157978e97.png" alt="Screenshot 2026-09-26 115607" style="display:block;margin:0 auto" />

<hr />
<h2>🏆 The Outcome: Safeguarding Millions &amp; Enforcing DPDP Compliance</h2>
<ul>
<li><p><strong>Zero Records Breached, Everything Fixed:</strong> Because this disclosure was conducted in strict good faith, <strong>not a single record was leaked, breached, or sold</strong>. All vulnerable endpoints, credential persistence flaws, and permissive IAM roles were thoroughly remediated and patched.</p>
</li>
<li><p><strong>Protecting 5 Million+ Students, Parents &amp; Teachers:</strong> As a Class 12th student, I am glad and proud to have helped secure the sensitive personal data of approximately <strong>5 million+ students, parents, and teachers</strong> (calculated as a conservative baseline across thousands of schools, though the true figure is likely even higher) before any malicious actors could discover and weaponize this flaw.</p>
</li>
<li><p><strong>Mandated DPDP Act (Digital Personal Data Protection) Consent:</strong> Because this massive dataset involved the PII of minor students, the vulnerability exposed significant compliance vulnerabilities. Following this disclosure and CERT-In's intervention, the vendor was required to enforce <strong>explicit DPDP Act consent workflows and parental consent verification</strong> directly into the platform's login and onboarding architecture.</p>
</li>
</ul>
<hr />
<h2>💡 Key Takeaways for EdTech &amp; Mobile Security</h2>
<ol>
<li><p><strong>Zero Trust on Client Storage</strong><br />Mobile devices must never store cloud infrastructure keys or IAM credentials. All database interactions must terminate at an authenticated backend API implementing strict role-based access control (RBAC).</p>
</li>
<li><p><strong>Proper Token Lifecycle Management</strong><br />Session tokens and authentication artifacts must be validated server-side on every request, with strict expiration enforcement to prevent token replay and orphaned sessions.</p>
</li>
<li><p><strong>Strict Cloud IAM Scoping (Principle of Least Privilege)</strong><br />Cloud identities must adhere to the Principle of Least Privilege (PoLP). A client-facing configuration must never have network paths or IAM permissions to query master production clusters, corporate HR payroll, or cross-tenant datasets.</p>
</li>
<li><p><strong>Compliance by Design (DPDP Act &amp; Minor PII)</strong><br />Platforms managing students' and minors' records must treat data protection as a legal baseline. Integrating transparent consent, parental verification, and automated audit logs is essential for compliance under modern regulations like India's DPDP Act.</p>
</li>
</ol>
<hr />
<blockquote>
<p><strong>Responsible Disclosure Notice:</strong><br />This vulnerability was researched and disclosed entirely in good faith in compliance with responsible security disclosure standards. All vendor names, sensitive endpoints, school identifiers, and exploit scripts have been omitted or redacted.</p>
</blockquote>
]]></content:encoded></item><item><title><![CDATA[ Scaling Quantum State-Vector Simulation to 36 Qubits on Google Cloud TPU
]]></title><description><![CDATA[The Problem
Simulating quantum circuits on a classical computer is exponentially hard. An n-qubit state vector holds 2ⁿ complex amplitudes — at 30 qubits that's 8 GB, at 33 qubits 64 GB, at 36 qubits ]]></description><link>https://ashitesh.me/scaling-quantum-state-vector-simulation-to-36-qubits-on-google-cloud-tpu</link><guid isPermaLink="true">https://ashitesh.me/scaling-quantum-state-vector-simulation-to-36-qubits-on-google-cloud-tpu</guid><category><![CDATA[quantum computing]]></category><category><![CDATA[tpu]]></category><category><![CDATA[jax]]></category><category><![CDATA[google cloud]]></category><category><![CDATA[memory-management]]></category><dc:creator><![CDATA[Ashitesh]]></dc:creator><pubDate>Thu, 11 Jun 2026 15:01:31 GMT</pubDate><content:encoded><![CDATA[<h2>The Problem</h2>
<p>Simulating quantum circuits on a classical computer is exponentially hard. An <em>n</em>-qubit state vector holds 2ⁿ complex amplitudes — at 30 qubits that's <strong>8 GB</strong>, at 33 qubits <strong>64 GB</strong>, at 36 qubits <strong>549 GB</strong>. No single GPU or TPU chip can hold that.</p>
<p>Most frameworks (Qiskit, PennyLane) give up around 29–30 qubits for two reasons:</p>
<ol>
<li><strong>Memory wall</strong> — the full state vector doesn't fit on one device</li>
<li><strong>XLA graph explosion</strong> — deep circuits compiled with Python <code>for</code>-loops unroll into millions of XLA graph nodes, crashing the compiler host before a single gate runs</li>
</ol>
<p>I built a simulator in <strong>100% pure JAX</strong> that solves both — scaling to <strong>36 qubits (549 GB)</strong> across a 64-chip Google Cloud TPU v6e cluster, with full reverse-mode autodiff and sub-millisecond gate latency.</p>
<hr />
<h2>Solution 1: Distributed State Vector with <code>PositionalSharding</code></h2>
<p>Instead of storing all 2ⁿ amplitudes on one chip, I split the state vector across the entire TPU mesh using JAX's native sharding API:</p>
<pre><code class="language-python">mesh          = Mesh(mesh_utils.create_device_mesh((16,)), axis_names=("chips",))
state_sharding = NamedSharding(mesh, P("chips", None))

# 33-qubit state: shape [16, 2^29] — each chip holds 2^29 amplitudes
state = jax.jit(init_ground_state, out_shardings=state_sharding)()
</code></pre>
<p>Each chip holds exactly its slice of the state vector in its own HBM pool. JAX's Inter-Chip Interconnects (ICI) handle cross-chip gate operations automatically. The host CPU never holds the full array.</p>
<table>
<thead>
<tr>
<th>Cluster</th>
<th>Qubits</th>
<th>State Vector Size</th>
<th>Per-Chip</th>
</tr>
</thead>
<tbody><tr>
<td>Single GPU</td>
<td>29</td>
<td>4.29 GB</td>
<td>—</td>
</tr>
<tr>
<td>TPU v5e-16</td>
<td><strong>33</strong></td>
<td>64 GB</td>
<td>4 GB</td>
</tr>
<tr>
<td>TPU v6e-64</td>
<td><strong>36</strong></td>
<td>549.76 GB</td>
<td>8.59 GB</td>
</tr>
</tbody></table>
<hr />
<h2>Solution 2: <code>lax.fori_loop</code> for O(1) Compiler Graph Size</h2>
<p>A Python <code>for</code>-loop inside <code>@jax.jit</code> statically unrolls every iteration into a separate XLA graph node. At 100 circuit layers × 30 qubits, the HLO graph has millions of nodes — the XLA compiler host OOMs during compilation, before execution even starts.</p>
<p><code>jax.lax.fori_loop</code> compiles the loop body <strong>once</strong> as a single <code>While</code> HLO node:</p>
<pre><code class="language-python"># ✅ O(1) XLA graph — compiles once, runs D times at hardware speed
state = lax.fori_loop(0, D, circuit_body, state)

# ❌ O(D) XLA graph — explodes at 100+ layers
for i in range(D):
    state = apply_gate(state, ...)
</code></pre>
<p>Graph size stays constant regardless of circuit depth. No compiler OOM.</p>
<hr />
<h2>The Full Compilation Stack</h2>
<pre><code>Python (JAX / jnp)
      ↓  @jax.jit traces once
XLA High-Level Operations (HLO)
      ↓  XLA compiler: fusion, tiling, layout
TPU HBM3 machine instructions
      ↓  ICI for cross-chip ops
Result: 36-qubit state vector across 64 HBM3 pools
</code></pre>
<p>The entire simulation — state init, gate application, observables, and gradient accumulation — runs inside <strong>one monolithic XLA kernel</strong>. No Python re-entry between gates. No CPU↔device copies mid-circuit.</p>
<hr />
<h2>Key Results</h2>
<ul>
<li><strong>Gate latency (after JIT warm-up):</strong> ~0.01ms</li>
<li><strong>Gradient of 100-parameter circuit:</strong> ~8ms (one <code>jax.grad</code> backward pass vs ~10s with PennyLane parameter-shift)</li>
<li><strong>VQE H₂ ground state:</strong> converged to −1.13627 Hartree — within 1.6×10⁻³ Hartree of the FCI reference (quantum chemical accuracy)</li>
<li><strong>Grover's at 36 qubits:</strong> marked state probability peaks at ~0.998 after 205,887 iterations</li>
<li><strong>Barren plateau:</strong> gradient variance confirmed to decay as 2⁻ⁿ up to 24 qubits (consistent with McClean et al. 2018)</li>
</ul>
<hr />
<h2>Try It for Free</h2>
<p>The repo includes a Colab notebook that runs on a <strong>free Colab TPU v5e-1</strong> — no Google Cloud account needed.</p>
<p><a href="https://colab.research.google.com/github/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/blob/main/tpu/colab_tpu_v5e_1chip.ipynb"><img src="https://img.shields.io/badge/Open_In-Google_Colab-F9AB00?style=for-the-badge&amp;logo=googlecolab&amp;logoColor=white" alt="Open In Colab" /></a></p>
<p>Six self-contained experiments: GHZ state prep, VQC XOR classifier, VQE H₂, QAOA MaxCut, Monte Carlo noise simulation, and noisy NISQ fidelity decay.</p>
<hr />
<h2>Why Pure JAX — Not PennyLane, Qiskit, or PyTorch?</h2>
<table>
<thead>
<tr>
<th>Framework</th>
<th>Why it fails at this scale</th>
</tr>
</thead>
<tbody><tr>
<td>PennyLane</td>
<td>Python-level gate dispatch; no monolithic XLA kernel; parameter-shift needs 2× evals per gradient</td>
</tr>
<tr>
<td>Qiskit-Aer</td>
<td>C++/CUDA, single device only; zero TPU support</td>
</tr>
<tr>
<td>TensorFlow Quantum</td>
<td>Cirq simulation runs on CPU — only classical ops hit TPU</td>
</tr>
<tr>
<td>PyTorch + <code>torch_xla</code></td>
<td>Bridge adds per-op latency at every Python→XLA boundary</td>
</tr>
</tbody></table>
<p>JAX <strong>is</strong> XLA. There is no bridge. Python code is the source language for a JIT compiler that targets TPU silicon directly.</p>
<hr />
<h2>References</h2>
<ol>
<li>Bradbury et al. (2018). JAX: composable transformations of Python+NumPy programs.</li>
<li>McClean et al. (2018). Barren plateaus in quantum neural network training landscapes. <em>Nature Communications</em>.</li>
<li>Peruzzo et al. (2014). A variational eigenvalue solver on a photonic quantum processor. <em>Nature Communications</em>.</li>
<li>Farhi et al. (2014). A quantum approximate optimization algorithm. <em>arXiv:1411.7308</em>.</li>
<li>Vidal (2003). Efficient classical simulation of slightly entangled quantum computations. <em>PRL</em>.</li>
</ol>
<hr />
<p><em>Supported by the Google TPU Research Cloud (TRC) program.</em><br /><em>Apache 2.0 License · <a href="https://github.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX">github.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX</a></em></p>
]]></content:encoded></item><item><title><![CDATA[Simulating Quantum Computers at Scale: JAX, GPUs, and Cloud TPUs]]></title><description><![CDATA[Note: The detailed research paper and full experimental results for this project have already been published. This post provides a high-level summary of the core system design, key benchmarks, and eng]]></description><link>https://ashitesh.me/simulating-quantum-computers-at-scale-jax-gpus-and-cloud-tpus</link><guid isPermaLink="true">https://ashitesh.me/simulating-quantum-computers-at-scale-jax-gpus-and-cloud-tpus</guid><category><![CDATA[quantum computing]]></category><category><![CDATA[Python]]></category><category><![CDATA[jax]]></category><category><![CDATA[Machine Learning]]></category><dc:creator><![CDATA[Ashitesh]]></dc:creator><pubDate>Tue, 02 Jun 2026 14:39:23 GMT</pubDate><content:encoded><![CDATA[<p><em>Note: The detailed research paper and full experimental results for this project have already been published. This post provides a high-level summary of the core system design, key benchmarks, and engineering insights.</em></p>
<p>Classical simulation of quantum systems is the bedrock of modern quantum algorithm research. However, simulating variational quantum algorithms (VQAs) has historically run into a massive wall: <strong>gradient computation scaling</strong>. </p>
<p>In this post, I’ll introduce the <strong>JAX Quantum Research Suite</strong>—a hardware-accelerated, fully differentiable quantum simulator designed to run seamlessly on consumer GPUs and scale up to Google Cloud TPU clusters. </p>
<p>We’ll explore how it overcomes traditional limitations, achieves up to a <strong>48.7× speedup in gradient calculations</strong>, and scales simulations up to <strong>36 qubits on TPU v6e</strong> and <strong>1,024 qubits using Matrix Product States (MPS)</strong>.</p>
<p><em>This research and scaling development was supported by the Google TPU Research Cloud (TRC) program.</em></p>
<hr />
<h2>The Core Challenge: Differentiating Quantum Circuits</h2>
<p>For variational algorithms like VQE (Variational Quantum Eigensolver) or QAOA (Quantum Approximate Optimization Algorithm), we need to optimize parameterized quantum circuits. </p>
<p>In standard frameworks, computing gradients is done using the <strong>Parameter-Shift Rule (PSR)</strong>. For a circuit with \(P\) parameters, PSR requires \(2P\) full circuit evaluations. When you scale up to hundreds of parameters, this linear \(O(P)\) overhead becomes a major bottleneck.</p>
<p>By using <strong>JAX</strong>, our simulator implements <strong>reverse-mode automatic differentiation (backpropagation)</strong>. This allows us to compute all \(P\) gradients in a single backward pass—an \(O(1)\) scaling cost relative to the parameter count.</p>
<hr />
<h2>🚀 Key Highlights &amp; Benchmarks</h2>
<h3>1. 48.7× Faster Gradients (Reverse-Mode AD vs. Parameter-Shift)</h3>
<p>On a 15-qubit Hardware-Efficient Ansatz circuit with <strong>120 parameters</strong>, we benchmarked gradient calculation times:</p>
<ul>
<li><strong>Parameter-Shift Rule (PSR)</strong>: <code>1,826 ms</code></li>
<li><strong>JAX Reverse-Mode Autodiff (<code>jax.grad</code>)</strong>: <strong><code>37.5 ms</code></strong></li>
<li><strong>Performance Leap</strong>: A <strong>48.7× speedup</strong>, which grows even larger as the number of parameters increases.</li>
<li><strong>Vs. PennyLane JAX Backend</strong>: Our custom statevector simulator ran ~4× faster (2ms vs 8ms for 50 params on GPU) due to monolithic XLA kernel fusion.</li>
</ul>
<h3>2. Grover's Algorithm at 36 Qubits (549 GB Statevector)</h3>
<p>Full statevector simulation scales exponentially in memory. A 36-qubit simulation requires <strong>549.76 GB</strong> of memory to store the amplitudes. Using a 64-chip <strong>Google Cloud TPU v6e</strong> mesh, we successfully ran Grover's algorithm at 36 qubits, distributing the massive statevector across TPU HBM3.</p>
<h3>3. Shor's Algorithm at 33 Qubits on TPU v5e-16</h3>
<p>We demonstrated a distributed QFT (Quantum Fourier Transform) pipeline for Shor's order-finding at a 33-qubit scale (64 GB statevector) on a 16-chip Cloud TPU v5e mesh, using network-optimized collective communication (<code>ppermute</code>) to reduce inter-chip transfer spikes from 8 GB to 128 MB.</p>
<h3>4. 1,024-Qubit MPS VQE &amp; Numerical Stability Breakthroughs</h3>
<p>To simulate beyond statevector limits (36+ qubits), we built a differentiable Matrix Product State (MPS) simulator in pure JAX. When differentiating through Singular Value Decomposition (SVD), JAX frequently crashes due to Wirtinger gradient singularities. 
We introduced three key stabilization techniques:</p>
<ol>
<li><strong>SVD Epsilon Floor</strong> (<code>1e-7</code>) to prevent division-by-zero.</li>
<li><strong>Site-level Normalization</strong> to stop amplitude drift.</li>
<li><strong>SVD Jitter &amp; Momentum SGD</strong> to low-pass filter and damp "V-bounce" oscillations caused by bond-dimension entanglement ceilings.</li>
</ol>
<hr />
<h2>🛠️ Three Engineering Tricks for Cloud TPU Scaling</h2>
<p>Tracing deep quantum circuits into XLA bytecode can crash compile hosts or run out of memory. We solved these issues with three specific JAX primitives:</p>
<h3>A. Multi-Device <code>PositionalSharding</code></h3>
<p>We partition the statevector's leading dimension across physical TPU chips:</p>
<pre><code class="language-python">sharding = PositionalSharding(jax.devices()).reshape(NUM_DEV, 1)
state = jax.device_put(state, sharding)
</code></pre>
<p>XLA handles local gate execution automatically, routing cross-shard gates via TPU Inter-Chip Interconnects (ICI).</p>
<h3>B. <code>lax.fori_loop</code> for O(1) Compiler Graph Size</h3>
<p>Unrolled Python loops create millions of HLO nodes, causing compile-time memory leaks. We wrap our circuit execution using JAX's loop control:</p>
<pre><code class="language-python">state_new = jax.lax.fori_loop(0, depth, body_fn, state_init)
</code></pre>
<p>This forces XLA to compile the gate block once, keeping the compiler graph size constant (\(O(1)\)) regardless of circuit depth.</p>
<h3>C. <code>jax.checkpoint</code> for O(1) Backpropagation Memory</h3>
<p>Reverse-mode AD normally stores all intermediate states in memory. For deep circuits, this causes HBM OOM errors. We apply gradient checkpointing to recompute intermediate states on-the-fly during the backward pass:</p>
<pre><code class="language-python">@jax.checkpoint
def circuit_layer(state, params):
    return apply_gates(state, params)
</code></pre>
<hr />
<h2>🎯 Summary of Experiments</h2>
<ul>
<li><strong>GHZ State Prep</strong>: Learned to prepare a 3-qubit GHZ state with \(\mathcal{F} &gt; 0.9999\) in 200 epochs.</li>
<li><strong>XOR VQC Classifier</strong>: Batched classification using <code>jax.vmap</code> achieving 97%+ accuracy.</li>
<li><strong>VQE (H₂ Molecule)</strong>: Solved ground state energy to within 0.1 mHa of the FCI reference (chemical accuracy).</li>
<li><strong>QAOA MaxCut</strong>: Achieved a 99.7% approximation ratio at depth \(p=5\) on a 6-node weighted graph.</li>
<li><strong>Monte Carlo Noise Trajectories</strong>: Simulated noisy NISQ channels (amplitude/phase damping) showing exact statistical convergence matching analytical curves.</li>
<li><strong>Barren Plateaus</strong>: Confirmed McClean's exponential gradient variance decay (\(\mathcal{O}(2^{-n})\)) up to 24 qubits on TPU.</li>
</ul>
<hr />
<h2>🙏 Acknowledgements</h2>
<p>This research was made possible through the <strong>Google TPU Research Cloud (TRC)</strong> program, which provided the TPU v5e and v6e compute resources necessary to scale our simulations to 33 and 36 qubits.</p>
<ul>
<li><strong>Codebase &amp; Experiments</strong>: <a href="https://github.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX">GitHub Repository</a></li>
<li><strong>Author</strong>: Ashitesh Singh</li>
</ul>
]]></content:encoded></item><item><title><![CDATA[JAX Quantum Research Suite: A Unified, Hardware-Accelerated, Differentiable Simulator for NISQ-Era Algorithm Research Across GPU and Cloud TPU Clusters

]]></title><description><![CDATA[We present the JAX Quantum Research Suite, a high-performance, differentiable quantum circuit simulator spanning two co-existing hardware acceleration layers: a GPU division targeting NVIDIA RTX-class]]></description><link>https://ashitesh.me/jax-quantum-research-suite-a-unified-hardware-accelerated-differentiable-simulator-for-nisq-era-algorithm-research-across-gpu-and-cloud-tpu-clusters</link><guid isPermaLink="true">https://ashitesh.me/jax-quantum-research-suite-a-unified-hardware-accelerated-differentiable-simulator-for-nisq-era-algorithm-research-across-gpu-and-cloud-tpu-clusters</guid><category><![CDATA[quantum computing]]></category><category><![CDATA[Machine Learning]]></category><category><![CDATA[quantum physics]]></category><category><![CDATA[google cloud]]></category><category><![CDATA[hardware]]></category><category><![CDATA[Quantum Machine Learning]]></category><category><![CDATA[jax]]></category><category><![CDATA[Python]]></category><category><![CDATA[research]]></category><dc:creator><![CDATA[Ashitesh]]></dc:creator><pubDate>Sun, 31 May 2026 05:59:09 GMT</pubDate><content:encoded><![CDATA[<p>We present the <strong>JAX Quantum Research Suite</strong>, a high-performance, differentiable quantum circuit simulator spanning two co-existing hardware acceleration layers: a <strong>GPU division</strong> targeting NVIDIA RTX-class consumer GPUs via CUDA and a <strong>Cloud TPU division</strong> distributed across Google Cloud TPU v5e-16 and v6e-64 VM clusters. The suite is implemented in pure JAX (<code>jax.numpy</code>, <code>jax.lax</code>) for all statevector primitives, enabling seamless composition with <code>jax.grad</code>, <code>jax.vmap</code>, and <code>jax.sharding.PositionalSharding</code>.</p>
<p>For the 37-qubit random circuit sampling (RCS) benchmark, we leverage TensorCircuit with a JAX backend — the only experiment in the suite using an external quantum framework — enabling tensor-network-based amplitude sampling at extreme scale on TPU v6e-64. All other experiments use our custom pure-JAX statevector engine with zero external quantum framework dependencies.</p>
<p>On a consumer NVIDIA GeForce RTX 2050 (4 GB VRAM) — selected specifically to test the framework's baseline performance on an entry-level consumer-grade GPU — our JAX statevector simulator establishes a baseline for single-GPU execution. Gradient computation scales favorably: on a <strong>120-parameter CPU circuit</strong> (N=10 rigorous runs, 9 stable runs post-JIT warm-up), <code>jax.grad</code> computes all gradients in a single reverse-mode backward pass at <strong>37.5ms vs. 1,826ms</strong> for PennyLane's parameter-shift rule — a <strong>48.7× improvement</strong> (Section 5.3a). On a smaller 50-parameter GPU circuit (N=3 preliminary), the ratio is ~75×, consistent with PSR overhead scaling linearly with parameter count. Against PennyLane's own JAX reverse-mode backend, the advantage is ~4× (2ms vs ~8ms). On the Cloud TPU v5e-16 mesh (256 GB aggregate HBM2e), full state-vector simulation scales to <strong>33 qubits</strong> (64 GB), and on the TPU v6e-64 cluster, Grover's algorithm is evaluated at <strong>36 qubits</strong> (549 GB). The 37-qubit RCS result (Section 5.7) uses tensor-network amplitude sampling via TensorCircuit and yields <strong>F_XEB ≈ 0</strong> (preliminary, N=5 runs) — indicating the sampled distribution is near-uniform, a null result expected for deep chaotic circuits evaluated under finite bond-dimension approximation.</p>
<p>We demonstrate the suite through <strong>nine experiment subsections</strong> (Sections 4.1–4.9): GHZ state preparation, Variational Quantum Classification (XOR), Variational Quantum Eigensolver (H₂), QAOA MaxCut, Monte Carlo quantum noise trajectories, noisy NISQ fidelity decay, barren plateau gradient variance scaling, Shor's 33-qubit order-finding demonstration, and Grover's 36-qubit full statevector simulation — plus MPS VQE at 512–1024 qubits with novel SVD numerical stability analysis.</p>
<p><strong>Keywords:</strong> Quantum simulation, JAX, XLA, automatic differentiation, TPU, variational quantum eigensolver, QAOA, Shor's algorithm, Grover's algorithm, matrix product states, barren plateaus, NISQ</p>
<hr />
<h2>1. Introduction</h2>
<p>Classical simulation of quantum systems remains the primary tool for algorithm development and hardware validation in the Noisy Intermediate-Scale Quantum (NISQ) era [1]. While the broader machine learning community heavily utilizes GPUs, Tensor Processing Units (TPUs) are fundamentally massive matrix-multiplication engines connected by ultra-high-speed Inter-Chip Interconnects (ICI). This architecture makes TPUs exceptionally well-suited for quantum simulation: statevector updates and tensor-network contractions are overwhelmingly dominated by large-scale matrix multiplications. TPUs provide seamless out-of-the-box distributed memory scaling via JAX, generally offering faster and more stable execution for these specific distributed workloads without the need for researchers to write complex C++ or CUDA code. While dedicated C++/CUDA simulators — qsim, Qiskit-Aer with cuQuantum — achieve high raw gate-application throughput, they are architecturally incompatible with the core requirement of modern variational quantum algorithm research: <strong>end-to-end, hardware-accelerated automatic differentiation</strong>.</p>
<p>The standard hardware-compatible gradient method in tools like PennyLane is the <strong>Parameter-Shift Rule (PSR)</strong> [2]. For a circuit with \(P\) parameters, PSR requires \(2P\) circuit evaluations to obtain all gradients, creating an \(O(P)\) bottleneck prohibitive for large variational circuits. Reverse-mode automatic differentiation (backpropagation) computes all \(P\) gradients in a single backward pass — O(1) evaluations — but requires a simulator that is transparently differentiable at the mathematical level.</p>
<p>The JAX ecosystem [3] uniquely resolves this tension. Because JAX traces Python code directly into XLA High-Level Operations (HLO) bytecode, a quantum circuit expressed as <code>jnp.tensordot</code> and <code>jnp.transpose</code> calls can be:</p>
<ol>
<li><p><strong>JIT-compiled</strong> (<code>@jax.jit</code>) into a monolithic XLA kernel — zero Python overhead after first compilation</p>
</li>
<li><p><strong>Automatically differentiated</strong> (<code>jax.grad</code>) in a single reverse-mode backward pass — O(1) evaluations for all parameters</p>
</li>
<li><p><strong>Vectorized</strong> (<code>jax.vmap</code>) over batches of parameters or states without code changes</p>
</li>
<li><p><strong>Distributed</strong> (<code>jax.sharding.PositionalSharding</code>) across multi-chip TPU meshes via the same API</p>
</li>
</ol>
<p>No other framework achieves this seamless compilation path to TPU hardware without additional tooling: PennyLane stops at Python-level device dispatch; Qiskit-Aer is a CUDA C++ library incompatible with TPU HBM; TensorFlow Quantum's Cirq backend runs circuit simulation on CPU (only classical post-processing hits TPU cores); PyTorch's <code>torch_xla</code> adds a Python-to-XLA bridge at every tensor boundary. JAX traces Python code <em>directly</em> into XLA HLO — quantum gate operations are first-class XLA nodes with no additional bridging layer. Note: Google's own <strong>qsim</strong> simulator (C++/CUDA) achieves higher raw gate throughput than our JAX engine at small qubit counts, but is not differentiable and has no TPU backend; <strong>cuQuantum</strong> (NVIDIA) offers gate fusion and multi-GPU state-vector simulation but is similarly non-differentiable and GPU-only.</p>
<h3>1.1 Contributions</h3>
<p>This paper makes the following contributions:</p>
<ol>
<li><p>A complete, modular pure-JAX statevector simulator (<code>jax_qsim</code>) with 20+ gate types, density matrix mode, and Kraus noise channels — all composable with <code>jax.grad</code></p>
</li>
<li><p><strong>O(1) XLA graph size</strong> for deep circuits via <code>jax.lax.fori_loop</code> — enabling 33-qubit Shor's algorithm on TPU without compiler OOM</p>
</li>
<li><p><strong>O(1) backpropagation memory</strong> via <code>jax.checkpoint</code> rematerialization for multi-layer variational training at large scale</p>
</li>
<li><p><strong>Novel MPS numerical analysis</strong>: documentation and resolution of SVD Wirtinger gradient singularities, \(\log_2(\chi)\) entanglement ceiling effects, and V-bounce oscillation in the bond-dimension-limited regime</p>
</li>
<li><p>Comprehensive cross-hardware benchmarks with raw data from consumer GPU through TPU cluster</p>
</li>
</ol>
<h3>1.2 Related Work</h3>
<p><strong>qujax</strong> (Duffield et al., JOSS 2023) [4] independently derived the same <code>(2,)*N</code> statetensor functional design. However, the primary novelty and central claim of our work lies in the native multi-chip Cloud TPU distribution layer (scaling to 64 chips seamlessly via JAX's <code>PositionalSharding</code>) enabling extreme-scale memory scaling, which qujax lacks. Furthermore, researchers can use our distributed code to simulate massive systems immediately without having to write any complex C++/CUDA code, as the distributed systems architecture on TPU is already solved for them. Our work also extends the ecosystem with a full circuit-builder abstraction and density matrix mode.</p>
<p><strong>TensorCircuit</strong> (Zhang et al., <em>Quantum</em> 2023) [5] uses <code>jnp.einsum</code> tensor contractions as its core primitive and supports JAX, TF, and PyTorch backends. We use TensorCircuit specifically for the 37-qubit RCS benchmark where tensor-network contraction is more efficient than full statevector for random circuit amplitude sampling.</p>
<p><strong>qsim</strong> (Google, 2020) is a high-performance C++/CUDA statevector simulator using gate fusion and AVX/GPU parallelism. It achieves higher raw gate throughput than our JAX engine at small qubit counts (particularly on NVIDIA GPUs with cuQuantum integration). Unlike our work, qsim is not differentiable and has no TPU backend — it cannot compute <code>jax.grad</code> through a circuit.</p>
<p><strong>cuQuantum</strong> (NVIDIA, 2022) [15] provides CUDA-accelerated statevector and tensor-network simulation with multi-GPU state-vector support and a gate-fusion pass. It outperforms our simulator in raw single-gate throughput but is GPU-only, non-differentiable, and cannot run on TPU hardware.</p>
<p><strong>PennyLane Catalyst</strong> (Xanaду, JOSS 2024) [6] uses MLIR/LLVM compilation (not XLA) to produce native binaries. Unlike Catalyst, our approach does not require a separate compilation toolchain beyond JAX.</p>
<p><strong>Quimb</strong> [7] is a widely-used Python library for tensor network simulation (MPS, DMRG) that could serve as an alternative backend for large-qubit simulations. Our MPS engine differs by being fully JAX-differentiable, enabling <code>jax.grad</code> through SVD operations.</p>
<p><strong>PennyLane</strong> (Bergholm et al., 2018) [8] is the primary framework we compare against for gradient benchmarks. Unlike PennyLane's default parameter-shift rule, our simulator uses JAX reverse-mode autodiff for O(1) gradient computation.</p>
<hr />
<h2>2. Architecture</h2>
<h3>2.1 Dual Hardware Division Design</h3>
<pre><code class="language-plaintext">JAX Quantum Research Suite
├── GPU Division  (gpu/)
│   ├── jax_qsim/
│   │   ├── core.py         ← Tensor contraction gate engine (tensordot + transpose)
│   │   ├── circuit.py      ← High-level Circuit builder with run() + compile()
│   │   ├── ops.py          ← Gate library (20+ gate types, parameterized)
│   │   ├── observables.py  ← PauliString, Hamiltonian expectations (used in VQE/QAOA)
│   │   └── noise.py        ← Kraus channel density matrix simulator (used in Noise trajectories)
│   └── quantum_research/   ← 8 GPU research scripts (VQE, QAOA, barren plateau...)
│
├── tpu/
│   └── tpu_quantum_scale.py  ← Self-contained 5-experiment suite (GHZ, VQC, VQE, QAOA, Noise)
│
├── shors/
│   └── shors_algorithm_33q.py  ← 33-qubit distributed Shor's on TPU v5e-16
│
└── grover_simulation/       ← 20/30/36-qubit Grover statevector on TPU v6e-64
    ├── 20qubits.py
    ├── 30qubits.py
    └── 36qubits.py
</code></pre>
<h3>2.2 GPU Division: Statevector Gate Engine</h3>
<p>An \(n\)-qubit state is represented as a tensor of shape \((2,)^n\) and all gate applications compile to pure XLA tensor operations.</p>
<p><strong>Single-qubit gate application — 3D transpose method:</strong></p>
<p>For gate \(U \in \mathbb{C}^{2\times 2}\) acting on qubit \(q\) of a flat \(2^n\)-amplitude state vector:</p>
<p>$$|\psi'\rangle = \text{reshape}\bigl(\mathbf{U} \cdot \text{reshape}(\text{transpose}(\text{reshape}(|\psi\rangle, [2^q, 2, 2^{n-q-1}]), [1,0,2]), [2,-1]), [2, 2^q, 2^{n-q-1}]\bigr)$$</p>
<p>This access pattern maps to a single XLA <code>Dot</code> instruction with contiguous strides, producing better memory coalescing than index-arithmetic approaches on GPU HBM.</p>
<p><strong>Two-qubit gate application — 5D transpose method:</strong></p>
<p>For gate \(U \in \mathbb{C}^{4\times 4}\) on qubits \((q_1, q_2)\), \(q_1 &lt; q_2\):</p>
<p>$$\text{state} \xrightarrow{\text{reshape}} (2^{q_1}, 2, 2^{q_2-q_1-1}, 2, 2^{n-q_2-1}) \xrightarrow{\text{transpose}(1,3,0,2,4)} \xrightarrow{\text{apply } U} \xrightarrow{\text{transpose back}} |\psi'\rangle$$</p>
<p>Zhang et al. (2023) show this approach generates better GPU memory coalescing than <code>tensordot</code> for 2-qubit gates because the contracted dimensions (size 2) are contiguous after the initial transpose.</p>
<p><strong>JIT-compiled circuit execution via static circuit structure:</strong></p>
<pre><code class="language-python">@functools.partial(jax.jit, static_argnums=(2, 3, 4))
def _run_circuit_functional(params, initial_state, num_qubits, ops, state_type):
    for op_name, qubits, p_val in ops:    # fully unrolled at trace time
        ...
    return state
</code></pre>
<p>Marking <code>ops</code> as static causes JAX to fully unroll and fuse the gate sequence into a flat XLA graph. Compilation happens once; subsequent calls execute the cached XLA binary with ~0ms overhead.</p>
<h3>2.3 TPU Division: Three Engineering Contributions</h3>
<p><strong>Contribution A — Multi-Device PositionalSharding:</strong></p>
<p>A 33-qubit state-vector (\(2^{33}\) complex64 amplitudes = 64.00 GB) exceeds any single device. Across a 16-chip TPU v5e mesh:</p>
<pre><code class="language-python">sharding = PositionalSharding(jax.devices()).reshape(NUM_DEV, 1)
state = jax.device_put(state, sharding)
</code></pre>
<p>JAX partitions the leading state-vector dimension across physical chips. Intra-chip gate operations execute without communication; cross-shard gates use XLA collective ops over TPU Inter-Chip Interconnects (ICI).</p>
<p><strong>Contribution B —</strong> <code>lax.fori_loop</code> <strong>for O(1) Compiler Graph Size:</strong></p>
<p>Python <code>for</code> loops inside <code>@jax.jit</code> unroll fully, making the XLA DAG size \(O(\text{depth})\). A 100-layer circuit produces millions of HLO nodes, causing the compiler host CPU to OOM before any computation begins. We use:</p>
<p>$$\text{state}_\text{new} = \texttt{jax.lax.fori_loop}(0, d, \texttt{body_fn}, \text{state}_0)$$</p>
<p>The XLA compiler compiles <code>body_fn</code> once, representing the loop as a single hardware instruction block. Graph size is \(O(1)\) for any circuit depth \(d\).</p>
<p><strong>Contribution C —</strong> <code>jax.checkpoint</code> <strong>for O(1) Backpropagation Memory:</strong></p>
<p>Reverse-mode differentiation through a \(d\)-layer circuit naively stores all \(d\) intermediate states in HBM. We wrap layers with <code>jax.checkpoint</code>:</p>
<pre><code class="language-python">@jax.checkpoint
def circuit_layer(state, params):
    return apply_gates(state, params)
</code></pre>
<p>Intermediate states are discarded during the forward pass and recomputed on-the-fly during the backward pass, reducing memory from \(O(d)\) to \(O(1)\) at the cost of one additional forward pass.</p>
<h3>2.4 37-Qubit RCS: TensorCircuit + JAX pmap</h3>
<p>The 37-qubit random circuit sampling experiment uses <strong>TensorCircuit</strong> (with <code>tc.set_backend("jax")</code>) for amplitude computation rather than full statevector simulation. TensorCircuit's tensor-network contractor evaluates individual circuit amplitudes via <code>circuit.amplitude(bitstring)</code>, which is then vmapped over batches of bitstrings and pmap'd across TPU chips:</p>
<pre><code class="language-python">tc.set_backend("jax")
tc.set_contractor("auto")

single_chip_batcher = jax.vmap(get_amplitude_probability, in_axes=(None, 0))
parallel_tpu_driver = jax.pmap(single_chip_batcher, in_axes=(None, 0))
</code></pre>
<p>This is the only experiment in the suite using an external quantum framework. For all statevector experiments (Shor's, Grover's, VQE, QAOA, GHZ, noise), we use exclusively our pure-JAX engine.</p>
<h3>2.5 MPS Tensor Network Engine</h3>
<p>For systems exceeding statevector memory limits, the suite implements a differentiable MPS simulator in pure JAX (no Quimb, no <code>tensornetwork</code> library). Each \(n\)-qubit state:</p>
<p>$$|\psi_\text{MPS}\rangle = \sum_{i_1,\dots,i_n} A^{i_1}{[1]} A^{i_2}{[2]} \cdots A^{i_n}{[n]} |i_1 \cdots i_n\rangle, \quad A^{i_k}{[k]} \in \mathbb{C}^{\chi \times \chi}$$</p>
<p>Two-qubit gates are applied via local contraction and SVD truncation:</p>
<pre><code class="language-python">fused = jnp.einsum("ijk,klm-&gt;ijlm", site1, site2)
transformed = jnp.einsum("abcd,ibcj-&gt;iadj", gate_u, fused)
mat = mat + 1e-9 * noise   # SVD jitter (see Section 4.9)
u, s, vh = jnp.linalg.svd(mat, full_matrices=False)
s_trunc = s[:CHI] / (jnp.linalg.norm(s[:CHI]) + EPS)
</code></pre>
<hr />
<h2>3. Experimental Setup</h2>
<h3>3.1 Hardware Platforms</h3>
<table>
<thead>
<tr>
<th>Platform</th>
<th>Specification</th>
<th>Memory</th>
</tr>
</thead>
<tbody><tr>
<td>Consumer GPU</td>
<td>NVIDIA GeForce RTX 2050, CUDA 12, WSL2</td>
<td>4 GB GDDR6 VRAM</td>
</tr>
<tr>
<td>Cloud TPU v5e-16</td>
<td>16-chip v5litepod mesh (us-central1-a)</td>
<td>256 GB HBM2e</td>
</tr>
<tr>
<td>Cloud TPU v6e-64</td>
<td>64-chip mesh (TRC program)</td>
<td>~2.0 TB HBM3</td>
</tr>
</tbody></table>
<h3>3.2 Software Stack</h3>
<ul>
<li><p>JAX 0.4.x with CUDA 12 backend (GPU) / libtpu (TPU)</p>
</li>
<li><p>Python 3.10+, NumPy, Matplotlib</p>
</li>
<li><p>TensorCircuit: used <strong>exclusively</strong> in the 37-qubit RCS experiment</p>
</li>
<li><p>PennyLane <code>default.qubit</code> (JAX interface) and Cirq <code>Simulator</code>: used in GPU benchmarks for comparison</p>
</li>
</ul>
<h3>3.3 Statistical Methodology</h3>
<blockquote>
<p><strong>⚠ Important for reproducibility:</strong> Benchmarks involving GPU/TPU execution measure wall-clock time after explicit <code>.block_until_ready()</code> synchronization. All tables report <strong>mean ± standard deviation</strong> over the stated number of timed runs, <strong>excluding the first compilation/warmup call</strong>. For time-critical results (gate speed, gradient step), we recommend reproducers run ≥10 timed iterations. Current benchmark files record 3 timed execution runs; tables note this where applicable. We flag data points where N &lt; 10 as preliminary.</p>
</blockquote>
<h3>3.4 Standard Benchmark Circuit</h3>
<p>Unless otherwise specified, benchmarks use a <strong>Hardware-Efficient Ansatz (HEA)</strong>:</p>
<ul>
<li><p>\(L = 3\) layers of \([RY, RZ]\) on each qubit + nearest-neighbor CNOT chain</p>
</li>
<li><p>Final \([RY, RZ]\) layer</p>
</li>
<li><p>Total parameters: \(n \times 2 \times (L+1)\) for \(n\) qubits</p>
</li>
</ul>
<hr />
<h2>4. Experiments and Results</h2>
<h3>4.1 GHZ State Preparation (Entanglement Learning)</h3>
<p><strong>Objective:</strong> Optimize a 9-parameter, 3-layer ansatz \(U(\vec{\theta})\) to prepare the 3-qubit GHZ state:</p>
<p>$$|\text{GHZ}\rangle = \frac{|000\rangle + |111\rangle}{\sqrt{2}}$$</p>
<p><strong>Loss function:</strong> $$\mathcal{L}(\vec{\theta}) = 1 - \left|\langle\text{GHZ}|U(\vec{\theta})|000\rangle\right|^2$$</p>
<p><strong>Optimizer:</strong> Adam (\(\text{lr} = 0.05\), \(\beta_1 = 0.9\), \(\beta_2 = 0.999\)), 200 epochs.</p>
<p><strong>Results:</strong> Both GPU and TPU divisions converge to fidelity \(\mathcal{F} &gt; 0.9999\) within 200 epochs with smooth monotonic convergence. Wall-clock time per gradient step: <strong>~0.4ms</strong> (GPU, post-JIT warmup).</p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/01_state_prep_20260524_111303.png" alt="Figure 1: GHZ State Preparation — Fidelity and loss convergence over 200 Adam epochs." style="display:block;margin:0 auto" />

<p><em>Figure 1: GHZ State Preparation — Fidelity and loss convergence over 200 Adam epochs on GPU (RTX 2050). Orange: infidelity (loss, 1 − F); Green: state fidelity F. Both GPU and TPU executions achieve identical final fidelity.</em></p>
<hr />
<h3>4.2 Variational Quantum Classifier (XOR Boundary Learning)</h3>
<p><strong>Objective:</strong> Resolve the XOR classification boundary using a 2-qubit, 8-parameter VQC with angle-encoded inputs:</p>
<p>$$P(y_i = 1|\vec{x}_i) = \frac{1 + \langle\psi(\vec{x}_i)|V^\dagger(\vec{\theta}) Z_0 V(\vec{\theta})|\psi(\vec{x}_i)\rangle}{2}$$</p>
<p><strong>Key implementation feature:</strong> Batch evaluation over 200 training points uses <code>jax.vmap(predict, in_axes=(None, 0))</code>, compiling a single batched XLA kernel. This is theoretically expected to achieve ~200× throughput over PennyLane's sequential per-sample circuit calls (one XLA kernel vs. 200 Python dispatches); a direct wall-clock comparison was not measured in this work.</p>
<p><strong>Results:</strong> Achieves <strong>97%+ classification accuracy</strong> within 150 Adam epochs.</p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/02_vqc_20260524_111303.png" alt="Figure 2: VQC XOR Classifier — Left: decision boundary. Right: MSE training loss." style="display:block;margin:0 auto" />

<p><em>Figure 2: Variational Quantum Classifier. Left: learned decision boundary correctly separates XOR classes. Right: MSE loss convergence curve. Results shown from GPU execution; TPU produces identical final decision boundary.</em></p>
<hr />
<h3>4.3 Variational Quantum Eigensolver: H₂ Ground State</h3>
<p><strong>Objective:</strong> Find the ground-state energy of molecular hydrogen (H₂) in the STO-3G basis, mapped to a 4-qubit Hamiltonian via Jordan-Wigner transformation:</p>
<p>$$H = g_0 I + g_1 Z_0 + g_2 Z_1 + g_3 Z_2 + g_4 Z_3 + g_5 Z_0 Z_1 + \cdots + g_{14}(Y_0 Y_1 X_2 X_3)$$</p>
<p>with coefficients \((g_0 = -0.81054, g_1 = 0.17120, \dots)\) at equilibrium bond length \(R = 0.735\) Å.</p>
<p><strong>Ansatz:</strong> 3-layer HEA initialized near the Hartree-Fock reference \(|0011\rangle\) (40 parameters). <strong>Gradient:</strong> Reverse-mode <code>jax.grad</code> — all 40 parameter gradients in one backward pass.</p>
<p><strong>Results:</strong></p>
<table>
<thead>
<tr>
<th>Metric</th>
<th>GPU (RTX 2050)</th>
<th>TPU v5e-16</th>
</tr>
</thead>
<tbody><tr>
<td>Final VQE energy</td>
<td>−1.13718 Ha</td>
<td>−1.13721 Ha</td>
</tr>
<tr>
<td>FCI reference</td>
<td>−1.1372 Ha</td>
<td>−1.1372 Ha</td>
</tr>
<tr>
<td>Error</td>
<td>0.2 mHa</td>
<td>0.1 mHa</td>
</tr>
<tr>
<td>Chemical accuracy (&lt; 1.6 mHa)</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Epochs to convergence</td>
<td>~300</td>
<td>~280</td>
</tr>
</tbody></table>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/vqe_20260524_111303.png" alt="Figure 3: VQE H₂ Ground State — four-panel convergence plot." style="display:block;margin:0 auto" />

<p><em>Figure 3: VQE H₂ molecular simulation. Top-left: energy convergence toward FCI reference (dashed red). Green shaded band marks chemical accuracy (±1.6 mHa). Top-right: gradient norm decay. Bottom-right: H₂ potential energy surface with FCI curve (green) and VQE result (star marker).</em></p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/vqe_20260524_111303.png" alt="VQE H2 convergence" style="display:block;margin:0 auto" />

<p><em>Figure 4: VQE convergence on TPU v5e-16. Energy (blue) converges to the FCI value of −1.1372 Ha within ~280 epochs. Gradient norm (purple) decays monotonically.</em></p>
<hr />
<h3>4.4 QAOA MaxCut (Combinatorial Optimization)</h3>
<p><strong>Circuit:</strong> QAOA at depths \(p \in {1,2,3,4,5}\) on a 6-node weighted graph (\(|E|=9\)):</p>
<p>$$|\vec{\gamma},\vec{\beta}\rangle = \prod_{k=1}^p e^{-i\beta_k H_M} e^{-i\gamma_k H_C}|+\rangle^{\otimes 6}$$</p>
<p><strong>Results:</strong></p>
<table>
<thead>
<tr>
<th>Depth \(p\)</th>
<th>Best \(E[\text{cut}]\)</th>
<th>Approximation Ratio</th>
</tr>
</thead>
<tbody><tr>
<td>1</td>
<td>7.82</td>
<td>0.869</td>
</tr>
<tr>
<td>2</td>
<td>8.41</td>
<td>0.934</td>
</tr>
<tr>
<td>3</td>
<td>8.74</td>
<td>0.971</td>
</tr>
<tr>
<td>4</td>
<td>8.89</td>
<td>0.988</td>
</tr>
<tr>
<td>5</td>
<td>8.97</td>
<td>0.997</td>
</tr>
</tbody></table>
<p>Classical MaxCut optimum: 9.0. QAOA at \(p=5\) achieves <strong>99.7%</strong> of the classical optimum.</p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/qaoa_20260524_111303.png" alt="Figure 5: QAOA MaxCut — four-panel results." style="display:block;margin:0 auto" />

<p><em>Figure 5: QAOA MaxCut on a 6-node weighted graph. Top-left: cut-value convergence for QAOA depths p=1…5; color corresponds to depth. Top-right: approximation ratio approaches 1.0 (classical optimum, dashed) as p increases. Bottom-right: graph topology with edge weights.</em></p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/qaoa_20260524_111303.png" alt="Figure 6: QAOA results on TPU v5e-16." style="display:block;margin:0 auto" />

<p><em>Figure 6: QAOA MaxCut on TPU v5e-16. Convergence curves per depth p confirm identical results to GPU execution, validating hardware-portability of the JAX implementation.</em></p>
<hr />
<h3>4.5 Quantum Noise Simulation (Monte Carlo Trajectories)</h3>
<p>We implement stochastic quantum trajectory simulation for three standard noise channels:</p>
<p><strong>Amplitude Damping</strong> (T1 relaxation, initial state \(|1\rangle\)): $$K_0 = \begin{pmatrix}1&amp;0\0&amp;\sqrt{1-\gamma}\end{pmatrix}, \quad K_1 = \begin{pmatrix}0&amp;\sqrt{\gamma}\0&amp;0\end{pmatrix}$$</p>
<p><strong>Phase Damping</strong> (T2 dephasing, initial state \(|+\rangle\)): $$K_0 = \begin{pmatrix}1&amp;0\0&amp;\sqrt{1-\gamma}\end{pmatrix}, \quad K_1 = \begin{pmatrix}0&amp;0\0&amp;\sqrt{\gamma}\end{pmatrix}$$</p>
<p><strong>Depolarizing Channel</strong> (initial state \(|+\rangle\)): $$\mathcal{E}(\rho) = (1-p)\rho + \frac{p}{3}(X\rho X + Y\rho Y + Z\rho Z)$$</p>
<p>Batch evaluation uses <code>jax.vmap(simulate_trajectory, in_axes=(0, None))</code> over trajectory random keys — all trajectories execute as a single GPU kernel.</p>
<p><strong>Results:</strong> Monte Carlo averages at \(N_\text{traj} \in {10, 100, 500}\) converge to exact analytical solutions with expected \(1/\sqrt{N_\text{traj}}\) statistical convergence rates. The <code>jax.vmap</code> parallelism is theoretically expected to yield ~\(N_\text{traj}\times\) throughput relative to sequential trajectory simulation (single fused XLA kernel vs. \(N_\text{traj}\) sequential dispatches); this ratio was not directly benchmarked against a sequential baseline.</p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/05_noise_sim_20260524_111303.png" alt="Figure 7: Monte Carlo quantum noise trajectories vs exact analytical solutions." style="display:block;margin:0 auto" />

<p><em>Figure 7: Monte Carlo quantum noise simulation. Left: amplitude damping |1⟩ relaxation vs damping rate γ. Center: phase damping ⟨X⟩ decay of |+⟩. Right: depolarizing channel ⟨X⟩ decay. Yellow curve: exact analytical solution. Colored markers: 10/100/500-trajectory Monte Carlo averages converging to exact solutions.</em></p>
<hr />
<h3>4.6 Barren Plateau Gradient Variance Scaling</h3>
<p>For a depth-\(d\), \(n\)-qubit Haar-random circuit with observable \(H\), the McClean et al. (2018) prediction [9]:</p>
<p>$$\text{Var}{\vec{\theta}}\left[\partial{\theta_k}\langle H\rangle\right] \in \mathcal{O}(2^{-n})$$</p>
<p><strong>GPU findings:</strong> Gradient variance scaling benchmarks up to 15 qubits confirm the exponential decay predicted by theory. The gradient signal vanishes to XLA compiler precision noise (~\(10^{-7}\)) around 12 qubits for depth-4 random circuits.</p>
<p><strong>TPU scaling advantage:</strong> The v5e-16 mesh enables gradient variance evaluation up to 24 qubits, extending the observable scaling region by an additional decade and confirming the McClean bound into the memory-limited regime for consumer GPU hardware.</p>
<img src="https://raw.githubusercontent.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX/main/tpu/plots/07_barren_plateau_20260524_111303.png" alt="Figure 8: Barren plateau gradient variance scaling — log-scale decay vs qubit count." style="display:block;margin:0 auto" />

<p><em>Figure 8: Barren plateau study. Gradient variance ⟨(∂E/∂θ)²⟩ (y-axis, log scale) vs qubit count (x-axis). The exponential fit (dashed) confirms the O(2^{-n}) theoretical prediction from McClean et al. (2018). Gradient signal approaches compiler precision (~10⁻⁷) near 12 qubits.</em></p>
<hr />
<h3>4.7 Shor's Algorithm: 33-Qubit Distributed State-Vector Demonstration</h3>
<blockquote>
<p>[!IMPORTANT] <strong>Scope clarification:</strong> The factoring instances (N=15, 21, 35) are trivially solvable classically. The 33-qubit scale is an engineering demonstration of the distributed <code>shard_map + ppermute</code> QFT scheme at 64 GB state-vector scale — not a contribution to factoring capability.</p>
</blockquote>
<p><strong>Circuit pipeline (22 counting + 11 work qubits = 33 total):</strong></p>
<ol>
<li><p>Initialize: \(|0\rangle^{\otimes 22} \otimes |1\rangle_w\)</p>
</li>
<li><p>Hadamard superposition on counting register</p>
</li>
<li><p>Controlled modular exponentiation via <code>shard_map</code> (network spikes reduced from 8 GB to 128 MB via chunked <code>ppermute</code>)</p>
</li>
<li><p>Inverse QFT on counting register</p>
</li>
<li><p>Period extraction via continued fractions on measurement peaks \(s/2^{22} \approx j/r\)</p>
</li>
</ol>
<p><strong>Result:</strong> The 33-qubit simulation correctly extracts periods \(r \in {4, 6, 12}\) for \(N \in {15, 21, 35}\) respectively, and phase peaks at \(s \cdot 2^{22}/r\) match theoretical positions — validating the distributed QFT implementation at 64 GB state-vector scale.</p>
<hr />
<h3>4.8 Grover's Algorithm at 36 Qubits (TPU v6e-64)</h3>
<p><strong>Search space:</strong> \(N = 2^{36} \approx 6.87 \times 10^{10}\) states; state-vector requires 549.76 GB, distributed across 64 TPU v6e chips (~8.59 GB per chip).</p>
<p><strong>Optimal iteration count:</strong> $$k_\text{opt} = \left\lfloor\frac{\pi}{4}\sqrt{2^{36}}\right\rfloor = 205{,}887$$</p>
<p><strong>MPS entanglement analysis:</strong> Grover's diffusion operator \(R_s = 2|s\rangle\langle s| - I\) is globally non-local. Bipartite entanglement entropy \(S(A:B)\) grows rapidly with each oracle call. For MPS with \(\chi = 64\): \(S_\text{max} = \log_2 64 = 6\) bits — saturated within ~50 Grover iterations (&lt; 0.025% of the required \(k_\text{opt}\)). Full statevector simulation is therefore necessary; MPS is not viable for Grover's algorithm above ~15 qubits.</p>
<hr />
<h3>4.9 MPS VQE at 512–1024 Qubits: Numerical Stability Analysis</h3>
<p>While Sections 4.1–4.8 focused exclusively on full state-vector simulation (which is strictly memory-bound to ~36 qubits), this section transitions to Matrix Product States (MPS) to push into the 512–1024 qubit regime. This represents a distinct computational approach designed to handle scale by capping entanglement. Here, we investigate the numerical stability of deep MPS optimization.</p>
<p><strong>512-qubit stability breakthrough:</strong> Differentiating through SVD in JAX causes gradient explosions due to Wirtinger calculus singularities at degenerate singular values. We document three fixes achieving stable convergence:</p>
<ol>
<li><p><strong>SVD epsilon floor</strong> (<code>EPS = 1e-7</code>): Prevents \(s_i \rightarrow 0\) division-by-zero in normalization</p>
</li>
<li><p><strong>Site-level normalization</strong>: Prevents exponential amplitude drift across deep contractions</p>
</li>
<li><p><strong>Wirtinger gradient clipping</strong>: Clips real components to \([-1.0, 1.0]\), bypassing JAX complex gradient instabilities</p>
</li>
</ol>
<p>Result: Energy converges monotonically from 0.4718 to 0.4311 per site (vs. NaN crash without fixes).</p>
<p><strong>1000-qubit bond dimension bottleneck:</strong> Reducing bond dimension to \(\chi = 64\) (TPU v5e-16 memory constraint) imposes \(S_\text{max} = 6.0\) bits entanglement ceiling. As training generates correlation beyond this ceiling, SVD truncation discards significant singular values, causing:</p>
<ul>
<li><p><strong>V-bounce</strong>: Energy descends to ~0.464 at epoch 2, then rebounds to ~0.481 at epoch 4</p>
</li>
<li><p><strong>Singularity source</strong>: Passive site degeneracy (\(s_i \approx s_j \approx 0\)) causes \(\frac{1}{s_i^2 - s_j^2}\) → ∞ in JAX's SVD backward pass</p>
</li>
</ul>
<p><strong>Complete resolution (</strong><code>vqe_1024q_v5e16.py</code><strong>):</strong></p>
<ol>
<li><p><strong>SVD jitter</strong>: \(10^{-9}\) complex noise before SVD breaks \(s_i = s_j\) degeneracy</p>
</li>
<li><p><strong>Full Hamiltonian optimization</strong>: All qubits contribute to loss (no passive sites)</p>
</li>
<li><p><strong>Momentum SGD</strong> (\(\mu = 0.9\)): Low-pass filters the V-bounce oscillation, enabling stable convergence to 10,000 epochs</p>
</li>
</ol>
<p><em>Figure 9: Unstable MPS-VQE run (512 qubits, no stabilization). The energy curve shows a catastrophic spike followed by NaN divergence — caused by SVD derivative singularities when singular values approach zero degeneracy.</em></p>
<p><em>Figure 10: 1000-qubit MPS-VQE energy oscillation (V-bounce). The V-shaped rebound pattern appears when bond dimension χ=64 saturates the S_max=6 bit entanglement ceiling. Momentum SGD (μ=0.9) damps these oscillations, enabling monotonic convergence over 10,000 epochs.</em></p>
<hr />
<h2>5. Cross-Hardware Performance Benchmarks</h2>
<h3>5.1 Benchmark Methodology</h3>
<blockquote>
<p><strong>Statistical rigor note:</strong> All benchmark data in Sections 5.3–5.7 were collected on 2026-05-30 using N=10 post-warmup timed runs (2 warmup runs discarded), with raw JSON logs archived in <code>benchmarks/results/n10_benchmark_20260530_214024.json</code>. We report mean ± σ computed from all 10 individual run measurements. GPU execution data at 25q/27q (Sections 5.4–5.5) retain †N=3 from original RTX 2050 hardware runs; the scaling sweep and gradient benchmarks (Sections 5.3, 5.6–5.8) are the new N=10 rigorous measurements. Independent reproducers may re-run <code>benchmarks/n10_rigorous_benchmark.py</code> (JAX 0.10.1+, CPU baseline) or <code>benchmarks/cuda_vs_cpu_benchmark.py</code> (GPU required).</p>
</blockquote>
<h3>5.2 Gate Application Speed (10-Qubit, Single CNOT)</h3>
<table>
<thead>
<tr>
<th>Framework</th>
<th>First call</th>
<th>Subsequent calls</th>
</tr>
</thead>
<tbody><tr>
<td><strong>JAX JIT (this work, GPU)</strong></td>
<td>~150ms (XLA compile)</td>
<td><strong>~0.008ms</strong></td>
</tr>
<tr>
<td>PennyLane <code>default.qubit</code> (JAX)</td>
<td>~2ms</td>
<td>~1.5ms</td>
</tr>
<tr>
<td>PennyLane <code>lightning.gpu</code></td>
<td>~5ms</td>
<td>~0.05ms</td>
</tr>
<tr>
<td>Qiskit-Aer (CPU)</td>
<td>~0.5ms</td>
<td>~0.3ms</td>
</tr>
<tr>
<td>Cirq</td>
<td>~0.8ms</td>
<td>~0.8ms</td>
</tr>
</tbody></table>
<p><em>Note: The JAX JIT first-call overhead is a one-time compilation cost amortized over all subsequent executions. The meaningful comparison for repeated inference or training is the "Subsequent calls" column.</em></p>
<h3>5.3 Full Gradient Step — Measured vs. Reference Data</h3>
<p>We measure gradient computation on a 15-qubit Hardware-Efficient Ansatz circuit with 3 entangling layers (120 trainable parameters). Results are from <code>bench_D_gradient</code> in <code>n10_benchmark_20260530_214024.json</code> (JAX 0.10.1, CPU backend, N=10 post-warmup runs).</p>
<h4>5.3a Rigorous N=10 Measurements (15-Qubit HEA, 120 Params, CPU Backend)</h4>
<p>Two independent N=10 benchmark runs were completed on the same CPU-only hardware. For <code>jax.grad</code>, the <strong>first timed run</strong> in both cases contains a residual JIT retracing event (106 ms in V5; 413 ms in V7) despite 2 declared warmup runs — this occurs because <code>jax.value_and_grad</code> retraces on the first differentiated call after warmup when gradient tape construction is deferred. We therefore report two statistics: the <strong>10-run total mean</strong> (conservative, includes outlier) and the <strong>9-run stable mean</strong> (runs 2–10, the physically meaningful post-JIT figure):</p>
<table>
<thead>
<tr>
<th>Run</th>
<th>Framework</th>
<th>Gradient Method</th>
<th>Params</th>
<th>10-run mean ± σ</th>
<th>9-run stable mean ± σ</th>
<th>Speedup (stable)</th>
</tr>
</thead>
<tbody><tr>
<td><strong>V5</strong></td>
<td><strong>JAX +</strong> <code>jax.grad</code> <strong>(this work)</strong></td>
<td>Reverse-mode AD</td>
<td>120</td>
<td>44.1 ms ± 20.7 ms</td>
<td><strong>37.5 ms ± 1.8 ms</strong></td>
<td>—</td>
</tr>
<tr>
<td><strong>V5</strong></td>
<td><strong>PSR emulation (this work)</strong></td>
<td>Param-Shift, 2×120 evals</td>
<td>120</td>
<td>1,826 ms ± 79.7 ms</td>
<td><strong>1,826 ms ± 79.7 ms</strong></td>
<td><strong>48.7×</strong></td>
</tr>
<tr>
<td>V7</td>
<td>JAX + <code>jax.grad</code> (this work)</td>
<td>Reverse-mode AD</td>
<td>120</td>
<td>174.8 ms ± 97.0 ms</td>
<td>107.0 ms ± 53.0 ms</td>
<td>—</td>
</tr>
<tr>
<td>V7</td>
<td>PSR emulation (this work)</td>
<td>Param-Shift, 2×120 evals</td>
<td>120</td>
<td>6,254 ms ± 2,016 ms</td>
<td>6,254 ms ± 2,016 ms</td>
<td>58.4×</td>
</tr>
</tbody></table>
<p><em>PSR 9-run mean = 10-run mean because PSR has no JIT retracing (it calls a pre-compiled function repeatedly).</em></p>
<p>V5 is the primary reference: the 9-run stable jax.grad mean (<strong>37.5 ms ± 1.8 ms</strong>) has negligible variance, confirming fully compiled steady-state execution. V7 was run under measurably higher OS load: the jax.grad 9-run stable mean of 107 ms ± 53 ms (49% CV) vs. V5's 37.5 ms ± 1.8 ms (5% CV) indicates a ~3× slowdown with high run-to-run jitter consistent with concurrent background processes competing for CPU time and L3 cache during the <code>jax.value_and_grad</code> backward pass¹. V7 PSR times (6,254 ms ± 2,016 ms, 32% CV) show the same OS-load signature. Both runs confirm jax.grad is <strong>&gt;35× faster</strong> than PSR at 120 parameters; V5 is the primary reference for the clean steady-state figure.</p>
<p><em>¹ V7 was run on the same physical machine as V5 but at a different time of day with additional background tasks running. No system-level profiling was performed to isolate the exact source of the 3× slowdown.</em></p>
<p><strong>V5 raw runs — jax.grad (ms):</strong> 106.11*, 35.87, 36.12, 35.67, 35.15, 36.43, 37.26, 40.34, 38.21, 39.77<br /><strong>V5 raw runs — PSR (ms):</strong> 1,759.98, 1,997.50, 1,775.52, 1,892.40, 1,805.04, 1,800.24, 1,692.28, 1,807.51, 1,881.80, 1,845.88<br /><em>* Run 1 flagged as JIT retracing event; excluded from 9-run stable mean.</em><br /><em>(Source:</em> <code>n10_benchmark_20260530_212827.json</code><em>)</em></p>
<p><strong>Primary speedup (V5, 9 stable runs, 120 params):</strong> jax.grad is <strong>48.7× faster</strong> than PSR (37.5 ms vs 1,826 ms). Conservative 10-run figure: <strong>41.4×</strong> (44.1 ms vs 1,826 ms).</p>
<h4>5.3b Reference Data — Prior Literature / Preliminary Runs (50 Params, GPU, N=3)</h4>
<blockquote>
<p>[!NOTE] The rows below used <strong>50 parameters on GPU hardware</strong> (RTX 2050, N=3 preliminary runs) and are <strong>not directly comparable</strong> to the 120-parameter CPU measurements above. They are included for orientation against published baselines. The PSR overhead scales linearly with parameter count: 50 params gives ~75× speedup; 120 params gives <strong>48.7×</strong> (V5 primary, 9 stable runs) — both ratios are consistent with \(\text{speedup} \propto P\) where \(P\) is parameter count.</p>
</blockquote>
<table>
<thead>
<tr>
<th>Framework</th>
<th>Gradient Method</th>
<th>Params</th>
<th>Time/step (est., N=3†, GPU)</th>
</tr>
</thead>
<tbody><tr>
<td><strong>JAX JIT +</strong> <code>jax.grad</code> <strong>(GPU baseline)</strong></td>
<td>Reverse-mode AD, 1 backward pass</td>
<td>50</td>
<td><strong>~2 ms ± 0.3 ms</strong></td>
</tr>
<tr>
<td>PennyLane (parameter-shift)</td>
<td>100 circuit evaluations</td>
<td>50</td>
<td>~150 ms ± 12 ms</td>
</tr>
<tr>
<td>PennyLane + JAX backend (reverse-mode)</td>
<td>Reverse-mode (partial)</td>
<td>50</td>
<td>~8 ms ± 1.1 ms</td>
</tr>
<tr>
<td>TensorFlow Quantum</td>
<td>TF GradTape + Cirq</td>
<td>50</td>
<td>~45 ms ± 5 ms</td>
</tr>
<tr>
<td>PyTorch <code>torch.func.grad</code></td>
<td>Reverse-mode</td>
<td>50</td>
<td>~12 ms ± 2 ms</td>
</tr>
</tbody></table>
<p><em>† Preliminary data; reproduced from the original GPU benchmark runs on RTX 2050. For cross-framework comparisons at matched parameter counts and hardware, re-run</em> <code>benchmarks/cuda_vs_cpu_benchmark.py</code> <em>with GPU access.</em></p>
<p><strong>Key insight:</strong> The jax.grad advantage over PSR is algorithmic — it scales linearly with parameter count (\(P\)): at \(P=50\) (GPU, preliminary) we observe ~75×; at \(P=120\) (CPU, N=10 rigorous, 9 stable runs) we observe <strong>48.7×</strong> (V5 primary) and 58.4× (V7). Both are consistent with \(\text{speedup} \approx P / C_{\text{rev}}\) where \(C_{\text{rev}}\) is the constant reverse-mode backward-pass cost. Furthermore, the <strong>4× speedup over PennyLane's own JAX reverse-mode backend</strong> is the most direct apples-to-apples comparison (same autodiff paradigm, same hardware class). This 4× gap is driven by our simulator's monolithic XLA kernel fusion: our <code>jax.lax.fori_loop</code> compiles the entire circuit into a single optimized XLA graph, whereas PennyLane incurs Python-level dispatch overheads for tape construction and multi-kernel execution.</p>
<p><em>Figure A: Gradient benchmark (N=10, 15-qubit HEA, 120 parameters, CPU backend). Left: scatter of individual run times per method. Right: mean ± 1σ bar chart. jax.grad computes all 120 gradients in a single reverse-mode backward pass; PSR requires 240 forward evaluations (2 per parameter).</em></p>
<h3>5.4 Qubit Scaling Sweep — N=10 Rigorous Measurements</h3>
<p>We executed a scaling sweep from 4 to 20 qubits using a Hardware-Efficient Ansatz (HEA) with real RY/RZ rotations and nearest-neighbor CNOT entanglement. Circuits with \(n \leq 18\) used <strong>3 entangling layers</strong> (L=3); circuits with \(n \geq 19\) used <strong>2 layers</strong> (L=2) to stay within available RAM on the test machine†. All measurements are <strong>N=10 post-warmup timed runs</strong> from <code>bench_C_scaling</code> in <code>n10_benchmark_20260530_214024.json</code>. Circuit objects are constructed outside <code>jax.jit</code> to isolate pure execution time from compilation overhead.</p>
<p><em>† The benchmark script (</em><code>n10_rigorous_benchmark.py</code> <em>V7, line 55) automatically reduces to L=2 for n≥19. Parameter count formula: \(P = n \times 2 \times (L+1)\), giving 152 for 19q/L=3 and 160 for 20q/L=3; the measured values 114 and 120 correctly reflect L=2 as used.</em></p>
<table>
<thead>
<tr>
<th>Qubits</th>
<th>Params</th>
<th>XLA Compile (s)</th>
<th>Mean exec (ms)</th>
<th>Std (ms)</th>
<th>N runs</th>
</tr>
</thead>
<tbody><tr>
<td>4</td>
<td>32</td>
<td>2.64</td>
<td>0.237</td>
<td>0.128</td>
<td>10</td>
</tr>
<tr>
<td>6</td>
<td>48</td>
<td>2.44</td>
<td>0.124</td>
<td>0.043</td>
<td>10</td>
</tr>
<tr>
<td>8</td>
<td>64</td>
<td>3.76</td>
<td>0.497</td>
<td>0.171</td>
<td>10</td>
</tr>
<tr>
<td>10</td>
<td>80</td>
<td>4.20</td>
<td>0.359</td>
<td>0.086</td>
<td>10</td>
</tr>
<tr>
<td>12</td>
<td>96</td>
<td>6.66</td>
<td>1.770</td>
<td>0.683</td>
<td>10</td>
</tr>
<tr>
<td>13</td>
<td>104</td>
<td>6.24</td>
<td>3.177</td>
<td>0.702</td>
<td>10</td>
</tr>
<tr>
<td>14</td>
<td>112</td>
<td>7.31</td>
<td>17.43</td>
<td>9.56</td>
<td>10</td>
</tr>
<tr>
<td>15</td>
<td>120</td>
<td>6.17</td>
<td>19.68</td>
<td>1.46</td>
<td>10</td>
</tr>
<tr>
<td>16</td>
<td>128</td>
<td>7.34</td>
<td>54.53</td>
<td>30.78</td>
<td>10</td>
</tr>
<tr>
<td>17</td>
<td>136</td>
<td>8.63</td>
<td>485.4</td>
<td>107.2</td>
<td>10</td>
</tr>
<tr>
<td>18</td>
<td>144</td>
<td>10.60</td>
<td>858.4</td>
<td>169.6</td>
<td>10</td>
</tr>
<tr>
<td>19</td>
<td>114 ‡</td>
<td>8.94</td>
<td>751.6</td>
<td>120.6</td>
<td>10</td>
</tr>
<tr>
<td>20</td>
<td>120 ‡</td>
<td>9.56</td>
<td>1678.0</td>
<td>137.6</td>
<td>10</td>
</tr>
</tbody></table>
<p><em>‡ n≥19 used L=2 layers (not L=3) to fit within available RAM. \(P = n \times 2 \times (L+1)\): at L=2, P=114 (19q) and P=120 (20q). At L=3 these would be 152 and 160 respectively.</em></p>
<p>The exponential scaling (\(O(2^n)\)) is clearly visible: from 10 qubits (0.36 ms) to 20 qubits (1,678 ms), execution time increases by approximately <strong>4,670×</strong> — consistent with the theoretically expected \(2^{10} = 1,024×\) growth in state-vector size modulated by memory-bandwidth effects from cache eviction above ~16 qubits.</p>
<p><em>Figure B: Statevector simulation scaling (N=10 timed runs per data point). Log-scale y-axis. Blue line: measured jax_qsim execution times. Blue band: ±1σ across 10 runs. Orange dashed: theoretical O(2^n) reference. The inflection at 16–17 qubits corresponds to the state-vector (2 MB → 512 MB) exceeding L3 CPU cache, triggering a 10× slowdown attributable to DRAM bandwidth saturation rather than compute throughput.</em></p>
<p><em>Figure C: Individual run-by-run timing for three representative qubit counts. The 10-qubit circuit is cache-resident and shows sub-millisecond variance. The 20-qubit circuit exhibits 400 ms run-to-run variance driven by OS memory scheduling.</em></p>
<p><em>Figure D: Complete N=10 benchmark data summary. Source:</em> <code>n10_benchmark_20260530_214024.json</code><em>. Green cells: measured execution times. Orange cells: gradient benchmark results.</em></p>
<h3>5.5 JIT Compilation Overhead (Amortization Analysis — N=10 Measured)</h3>
<p>XLA compilation times (measured, 2026-05-30 benchmark):</p>
<table>
<thead>
<tr>
<th>Qubit count</th>
<th>XLA compile (measured)</th>
<th>Post-JIT exec (mean, N=10)</th>
<th>Break-even calls</th>
</tr>
</thead>
<tbody><tr>
<td>4</td>
<td>2.64 s</td>
<td>0.237 ms</td>
<td>~11,140</td>
</tr>
<tr>
<td>8</td>
<td>3.76 s</td>
<td>0.497 ms</td>
<td>~7,580</td>
</tr>
<tr>
<td>10</td>
<td>4.20 s</td>
<td>0.359 ms</td>
<td>~11,700</td>
</tr>
<tr>
<td>12</td>
<td>6.66 s</td>
<td>1.770 ms</td>
<td>~3,760</td>
</tr>
<tr>
<td>15</td>
<td>6.17 s</td>
<td>19.68 ms</td>
<td>~314</td>
</tr>
<tr>
<td>18</td>
<td>10.60 s</td>
<td>858 ms</td>
<td>~12</td>
</tr>
<tr>
<td>20</td>
<td>9.56 s</td>
<td>1,678 ms</td>
<td><strong>6</strong></td>
</tr>
<tr>
<td>25</td>
<td>~18.2s †</td>
<td>~15,600 ms †</td>
<td>2</td>
</tr>
</tbody></table>
<p><em>† 25-qubit data from original RTX 2050 hardware (requires 256 MB VRAM); 20-qubit is the largest tractable measurement on CPU-only JAX.</em></p>
<p>For training workflows with hundreds of gradient steps, the XLA compilation overhead is fully amortized after fewer than 20 calls at all tested qubit counts. The break-even point improves as circuit complexity grows — larger circuits have proportionally longer execution times relative to their (sub-linear) compile overhead.</p>
<p><em>Figure 14: GPU scaling benchmark (6-panel). Clockwise from top-left: execution time scaling, peak memory usage, gate throughput, VRAM utilization, compilation time, and speedup factor — all as functions of qubit count from 4 to 22 qubits on RTX 2050.</em></p>
<h3>5.6 Maximum Qubit Threshold by Hardware</h3>
<table>
<thead>
<tr>
<th>Hardware</th>
<th>Max Qubits</th>
<th>State-vector Size</th>
</tr>
</thead>
<tbody><tr>
<td>RTX 2050 (4 GB VRAM)</td>
<td><strong>29 qubits</strong></td>
<td>4.29 GB (VRAM limit)</td>
</tr>
<tr>
<td>Consumer CPU (64 GB RAM)</td>
<td>~32 qubits</td>
<td>32 GB</td>
</tr>
<tr>
<td>TPU v5e-16 (256 GB HBM2e)</td>
<td><strong>33 qubits</strong></td>
<td>64 GB (sharded)</td>
</tr>
<tr>
<td>TPU v6e-64 (2 TB HBM3)</td>
<td><strong>36 qubits (full statevector, Grover's)</strong></td>
<td>549.76 GB (sharded across 64 chips)</td>
</tr>
</tbody></table>
<h3>5.7 Negative Result / Scope Boundary: 37-Qubit RCS F_XEB Benchmark</h3>
<p>The 37-qubit random circuit sampling uses TensorCircuit's tensor-network amplitude sampling (not full statevector). The underlying chaotic circuit operates on a 40-qubit 1D chain topology (20-layer RX/RZ + alternating CZ pattern) evaluated on TPU v6e-64, with TensorCircuit's contraction-path optimizer sampling individual output amplitudes:</p>
<table>
<thead>
<tr>
<th>Metric</th>
<th>Value</th>
</tr>
</thead>
<tbody><tr>
<td>Circuit topology</td>
<td>40-qubit linear chain, 20 layers (chaotic RCS)</td>
</tr>
<tr>
<td>Sampling method</td>
<td>Tensor-network amplitude per bitstring (TensorCircuit)</td>
</tr>
<tr>
<td>Bitstrings sampled per run</td>
<td>32 per chip × 64 chips = 2,048</td>
</tr>
<tr>
<td>Mean sample probability \(\overline{p}\)</td>
<td>~\(9.1 \times 10^{-13}\) (near uniform \(1/2^{40}\))</td>
</tr>
<tr>
<td>F_XEB \(= 2^{40} \cdot \overline{p} - 1\)</td>
<td>~0.001 ± 0.003 (preliminary, N=5 runs)</td>
</tr>
<tr>
<td>Mean execution time (post-JIT)</td>
<td>0.52s ± 0.08s per batch</td>
</tr>
</tbody></table>
<p><em>Note: The F_XEB ≈ 0 result is physically expected and serves as a scope boundary for tensor-network methods. It indicates the sampled output distribution is approximately uniform — a null result expected for a deep chaotic circuit evaluated via tensor-network contraction with finite bond dimension. To achieve F_XEB ≈ 1.0 (indicating high fidelity), the simulator would need to retain exact full-statevector precision, which requires a prohibitive 8.79 TB of memory at 40 qubits, or exact tensor-network contraction with exponential bond dimension. This F_XEB value therefore characterizes the expected failure of the finite bond-dimension tensor-network approximation on deep chaotic circuits, not the underlying physical circuit quality.</em></p>
<hr />
<h2>6. Discussion</h2>
<h3>6.1 What This Work Demonstrates</h3>
<p><strong>Confirmed strengths:</strong></p>
<ol>
<li><p><strong>Competitive GPU performance</strong>: Preliminary observations (see Appendix C) suggest our JAX simulator matches or outperforms PennyLane Lightning GPU and Qiskit-Aer GPU on the same hardware (RTX 2050) at 27 qubits.</p>
</li>
<li><p><strong>Gradient computation advantage</strong>: The gradient advantage over PSR is architecturally principled and confirmed at <strong>48.7× (N=10 rigorous, 120-param CPU circuit)</strong>; the ~75× figure (2ms vs 150ms, 50-param GPU) is preliminary (N=3) and consistent with the linear \(\text{speedup} \propto P\) relationship. The <strong>4× advantage over PennyLane's own JAX reverse-mode backend</strong> is also real and architecture-based.</p>
</li>
<li><p><strong>TPU scalability</strong>: <code>lax.fori_loop</code> + <code>PositionalSharding</code> + <code>jax.checkpoint</code> together enable 33-qubit simulation on TPU v5e-16 that would be impossible with Python-loop-based approaches</p>
</li>
<li><p><strong>Novel MPS numerical analysis</strong>: The SVD gradient singularity characterization and V-bounce identification are engineering contributions not documented in prior JAX-based MPS literature</p>
</li>
</ol>
<h3>6.2 Honest Limitations</h3>
<p><strong>Memory bandwidth is the binding constraint:</strong><br />Preliminary tests at 25 qubits (256 MB state-vector) indicate the RTX 2050 (192 GB/s) is bandwidth-limited, not compute-limited. PennyLane Lightning CPU (using multi-core CPU DRAM at ~50–80 GB/s per-thread but higher effective bandwidth) wins at this scale on this specific hardware. However, a single run on a higher-bandwidth GPU (like an RTX 4090 or A100) would substantially flip this result in favor of the GPU.</p>
<p><strong>Compilation overhead is real:</strong><br />The first <code>jax.jit</code> call takes 1–18 seconds depending on qubit count. This is unsuitable for interactive circuit exploration but negligible for training workflows.</p>
<p><strong>MPS accuracy is bond-dimension-limited:</strong><br />At \(\chi = 64\), MPS can represent at most 6 bits of bipartite entanglement. Volume-law entanglement circuits (Grover, Shor, deep random circuits) exceed this ceiling rapidly. The 1024-qubit VQE result is physically meaningful only for near-product initial states with low entanglement.</p>
<p><strong>No gate fusion pass:</strong><br />Unlike cuQuantum, our simulator applies each gate as a separate memory operation. DAG-based gate fusion would theoretically reduce memory bandwidth requirements by 2–5×, which is identified as the primary optimization opportunity. Without gate fusion, our baseline simulator sits slightly below the absolute performance frontier of highly optimized C++ frameworks for raw gate application. However, we sacrifice this single-gate speed specifically to retain the end-to-end <code>jax.grad</code> differentiability that C++ simulators lack.</p>
<p><strong>Statistical rigor — resolved:</strong><br />Sections 5.3 (gradient timing) and 5.4 (scaling sweep 4–20 qubits) now report <strong>N=10 timed runs</strong> with mean ± σ from raw JSON logs (<code>n10_benchmark_20260530_214024.json</code>, timestamp 2026-05-30 21:40:24). The 25q/27q GPU data have been moved to Appendix C as preliminary observations since they retain †N=3 from the original RTX 2050 hardware sessions, and re-running 25q/27q XLA compilation on CPU-only hardware to achieve N=10 is impractical (requires 256 MB–1 GB VRAM).</p>
<hr />
<h2>7. Conclusion</h2>
<p>We presented the JAX Quantum Research Suite, a differentiable quantum simulator built in pure JAX for statevector experiments and extending to TensorCircuit (JAX backend) for extreme-scale random circuit sampling. Key results:</p>
<ul>
<li><p><strong>29 qubits</strong> on consumer RTX 2050 GPU with full <code>jax.grad</code> differentiability</p>
</li>
<li><p><strong>33 qubits</strong> via distributed sharding on Cloud TPU v5e-16 (Shor's algorithm demonstration)</p>
</li>
<li><p><strong>36 qubits</strong> Grover's algorithm on TPU v6e-64 via 2 TB state-vector sharding</p>
</li>
<li><p><strong>37-qubit</strong> RCS via TensorCircuit tensor-network amplitude sampling on TPU v6e-64</p>
</li>
<li><p><strong>48.7× faster gradient computation</strong> vs PennyLane parameter-shift (N=10 rigorous, 120-param circuit); <strong>~75×</strong> at 50 params (N=3 preliminary GPU); <strong>4× vs PennyLane JAX reverse-mode</strong></p>
</li>
<li><p><strong>Novel MPS numerical analysis</strong> (SVD jitter, V-bounce, Wirtinger clipping) enabling stable 1024-qubit VQE</p>
</li>
<li><p>O(1) XLA graph size via <code>lax.fori_loop</code> enabling deep circuit simulation on TPU</p>
</li>
</ul>
<p>The pure-JAX design makes any circuit composable with <code>jax.grad</code>, <code>jax.vmap</code>, and <code>jax.pmap</code> without code modification, providing a productive research tool for the NISQ algorithm development cycle. Because of this research and framework, researchers everywhere can now use our code to perform massive distributed quantum simulations directly on TPUs without having to write any complex C++ or CUDA distributed systems code.</p>
<p><strong>Code:</strong> <a href="https://github.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX">https://github.com/AshiteshSingh/Tpu-Accelerated-Quantum-JAX</a> (MIT License)<br /><strong>Supported by:</strong> Google TPU Research Cloud (TRC) Program</p>
<hr />
<h2>Acknowledgements</h2>
<p>The authors are deeply grateful to the <strong>Google TPU Research Cloud (TRC) program</strong> and the TRC team for providing access to Cloud TPU v6e-64chip and TPU v5e-16 hardware resources. This support enabled the large-scale distributed simulations (33-qubit Shor's, 36-qubit Grover's, 1024-qubit MPS-VQE) presented in this work.</p>
<hr />
<h2>References</h2>
<p>[1] Preskill, J. (2018). Quantum Computing in the NISQ Era and Beyond. <em>Quantum</em>, 2, 79.</p>
<p>[2] Mitarai, K., Negoro, M., Kitagawa, M., Fujii, K. (2018). Quantum circuit learning. <em>Physical Review A</em>, 98(3), 032309.</p>
<p>[3] Bradbury, J., Frostig, R., et al. (2018). JAX: composable transformations of Python+NumPy programs. <a href="http://github.com/google/jax">http://github.com/google/jax</a></p>
<p>[4] Duffield, S., Matos, G., Johannsen, M. (2023). qujax: Simulating quantum circuits with JAX. <em>Journal of Open Source Software</em>, 8(89), 5504. <a href="https://doi.org/10.21105/joss.05504">https://doi.org/10.21105/joss.05504</a></p>
<p>[5] Zhang, S.-X. et al. (2023). TensorCircuit: a Quantum Software Framework for the NISQ Era. <em>Quantum</em>, 7, 912. arXiv:2205.10091.</p>
<p>[6] Ittah, D., Asadi, A., Sanner, S., et al. (2024). Catalyst: A Python JIT compiler for auto-differentiable hybrid quantum programs. <em>Journal of Open Source Software</em>, 9(96), 6720. <a href="https://doi.org/10.21105/joss.06720">https://doi.org/10.21105/joss.06720</a></p>
<p>[7] Gray, J. (2018). quimb: A python library for quantum information and many-body calculations. <em>Journal of Open Source Software</em>, 3(29), 819. <a href="https://doi.org/10.21105/joss.00819">https://doi.org/10.21105/joss.00819</a></p>
<p>[8] Bergholm, V., Izaac, J., Schuld, M., et al. (2022). PennyLane: Automatic differentiation of hybrid quantum-classical computations. arXiv:1811.04968v4.</p>
<p>[9] McClean, J.R., Boixo, S., Smelyanskiy, V.N., Babbush, R., Neven, H. (2018). Barren plateaus in quantum neural network training landscapes. <em>Nature Communications</em>, 9, 4812.</p>
<p>[10] Jamadagni, A. et al. (2024). Benchmarking Quantum Computer Simulation Software Packages: State Vector Simulators. <em>SciPost Physics Core</em>.</p>
<p>[11] Shor, P.W. (1994). Algorithms for Quantum Computation: Discrete Logarithms and Factoring. <em>Proceedings of FOCS 1994</em>.</p>
<p>[12] Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. <em>Proceedings of STOC 1996</em>.</p>
<p>[13] Farhi, E., Goldstone, J., Gutmann, S. (2014). A Quantum Approximate Optimization Algorithm. arXiv:1411.4028.</p>
<p>[14] Peruzzo, A. et al. (2014). A variational eigenvalue solver on a photonic quantum processor. <em>Nature Communications</em>, 5, 4213.</p>
<p>[15] NVIDIA Corporation (2023). cuQuantum SDK: cuStateVec State-Vector Library. <a href="https://developer.nvidia.com/cuquantum-sdk">https://developer.nvidia.com/cuquantum-sdk</a></p>
<p>[16] Vidal, G. (2003). Efficient Classical Simulation of Slightly Entangled Quantum Computations. <em>Physical Review Letters</em>, 91(14), 147902.</p>
<hr />
<h2>Appendix A: Circuit API Reference</h2>
<pre><code class="language-python">from jax_qsim.circuit import Circuit
import jax, jax.numpy as jnp

c = Circuit(num_qubits=4)
c.h(0).cnot(0, 1).ry(2, param_index=0).rz(3, param_index=1)
c.noise_depolarizing(0, p=0.01)   # density_matrix mode only

params = jnp.array([0.5, 1.2])
state = c.run(params, state_type='statevector')   # JIT-compiled

# Gradient computation: all parameters in one backward pass
grad_fn = jax.jit(jax.grad(lambda p: compute_expectation(c.run(p, 'statevector'))))
grads = grad_fn(params)

# vmap over a batch of 64 parameter vectors simultaneously
batch_params = jnp.ones((64, 2))
batch_fn = jax.vmap(lambda p: c.run(p, 'statevector'))
batch_states = batch_fn(batch_params)   # all 64 circuits in one GPU kernel
</code></pre>
<h2>Appendix B: TPU Cluster Deployment</h2>
<pre><code class="language-bash"># Provision TPU v5e-16 cluster
gcloud compute tpus tpu-vm create tpu-16chip-worker \
  --zone=us-central1-a \
  --accelerator-type=v5litepod-16 \
  --version=v2-alpha-tpuv5-lite

# Interactive control script
./tpu/run_tpu.sh
# Option 1: TERMINATE — kill zombie libtpu.so processes
# Option 2: SYNC &amp; RUN — git sync all workers and run full suite  
# Option 3: DOWNLOAD — archive results and plots for download
# Option 4: CLEANUP — clear output directories
</code></pre>
<h2>Appendix C: Preliminary Observations (25 &amp; 27 Qubit GPU Benchmarks)</h2>
<blockquote>
<p>[!NOTE] The data in this appendix is derived from preliminary hardware sessions on an NVIDIA RTX 2050 (†N=3 runs) and is included as preliminary observations rather than rigorous N=10 benchmark claims.</p>
</blockquote>
<h3>C.1 25-Qubit State-Vector Benchmark (N=10 timed runs)</h3>
<p>Full N=10 CPU baseline measurements completed (timestamp 20260530_212827):</p>
<table>
<thead>
<tr>
<th>Framework</th>
<th>Compilation</th>
<th>Execution mean ± σ (N=10)</th>
<th>Hardware</th>
<th>Notes</th>
</tr>
</thead>
<tbody><tr>
<td><strong>jax_qsim CPU (this work)</strong></td>
<td>20.56 s</td>
<td><strong>20.76 s ± 2.02 s</strong></td>
<td>CPU-only JAX</td>
<td>N=10 rigorous</td>
</tr>
<tr>
<td><strong>jax_qsim GPU (this work)</strong></td>
<td>18.2 s</td>
<td><strong>15.6 s †</strong></td>
<td>RTX 2050 CUDA</td>
<td>†N=3 preliminary</td>
</tr>
<tr>
<td>PennyLane Lightning CPU</td>
<td>9.1 s</td>
<td>9.9 s †</td>
<td>C++ engine</td>
<td>†N=3 preliminary</td>
</tr>
</tbody></table>
<p><strong>V5 raw runs — 25q jax_qsim CPU (s):</strong> 19.23, 20.17, 22.01, 21.01, 25.41, 22.99, 19.02, 19.00, 19.12, 19.66<br /><em>(Source:</em> <code>n10_benchmark_20260530_212827.json</code><em>)</em></p>
<p><em>At 25 qubits, the CPU-only JAX baseline (20.76 s) is slower than both the GPU version (15.6 s) and PennyLane Lightning CPU (9.9 s). The CPU JAX slowness is expected: XLA statevector operates serially on a single cpu:0 device whereas PennyLane Lightning uses optimised multi-threaded C++ kernels. The GPU version achieves 15.6 s by parallelising across CUDA cores, approaching PennyLane Lightning throughput. On a GPU with 1+ TB/s bandwidth (e.g., RTX 4090, A100) the JAX simulator would outperform Lightning at 25 qubits.</em></p>
<p><em>Figure C.1: 25-qubit statevector benchmark (RTX 2050). At 25 qubits, PennyLane Lightning CPU (multi-threaded C++) achieves the fastest wall-clock time. The JAX GPU (RTX 2050 CUDA) is faster than JAX CPU but slower than Lightning at this state-vector size due to the 192 GB/s HBM bandwidth ceiling.</em></p>
<h3>C.2 27-Qubit Cross-Framework Comparison (N=10 CPU Baseline + †N=3 GPU)</h3>
<p>Full N=10 CPU baseline measurements for 27-qubit HEA (1 layer, 108 params):</p>
<table>
<thead>
<tr>
<th>Framework</th>
<th>Compilation</th>
<th>Execution mean ± σ (N=10)</th>
<th>Hardware</th>
</tr>
</thead>
<tbody><tr>
<td><strong>jax_qsim CPU (this work)</strong></td>
<td>100.10 s</td>
<td><strong>99.74 s ± 21.60 s</strong></td>
<td>CPU-only JAX</td>
</tr>
<tr>
<td><strong>jax_qsim GPU (this work)</strong></td>
<td>—</td>
<td><strong>4.61 s †</strong></td>
<td>RTX 2050 CUDA</td>
</tr>
<tr>
<td>PennyLane Lightning GPU</td>
<td>—</td>
<td>6.12 s †</td>
<td>RTX 2050</td>
</tr>
<tr>
<td>Qiskit-Aer GPU</td>
<td>—</td>
<td>6.85 s †</td>
<td>RTX 2050</td>
</tr>
<tr>
<td>TensorFlow Quantum GPU</td>
<td>—</td>
<td>7.50 s †</td>
<td>RTX 2050</td>
</tr>
</tbody></table>
<p><strong>V5 raw runs — 27q jax_qsim CPU (s):</strong> 160.45, 99.23, 109.34, 83.92, 92.57, 83.70, 92.90, 83.94, 96.37, 94.99<br /><em>(Source:</em> <code>n10_benchmark_20260530_212827.json</code><em>)</em></p>
<p>The CPU execution time (99.74 s) confirms the <strong>GPU is essential at 27 qubits</strong>: the RTX 2050 achieves 4.61 s — a <strong>21.6× speedup over CPU JAX</strong> and a <strong>1.3× speedup</strong> over PennyLane Lightning GPU. The first 27q CPU run (160.45 s) is an outlier likely caused by OS memory paging when the 1 GB state-vector first exceeds L3 cache; the 9 subsequent runs converge to 84–109 s.</p>
<p>At 27 qubits, the JAX JIT GPU achieves <strong>1.3× speedup</strong> over PennyLane Lightning GPU and <strong>1.5× over Qiskit-Aer GPU</strong> on identical hardware.</p>
<p><em>Figure C.2: 27-qubit GPU comparison. jax_qsim achieves the fastest execution across GPU frameworks at 27 qubits (1 GB state-vector). GPU is 21.6× faster than CPU-only JAX at this scale. All GPU measurements on NVIDIA RTX 2050.</em></p>
]]></content:encoded></item></channel></rss>