From the NVIDIA edition of October 19, 2026
CTOL analysis: NVIDIA's JUPITER run used about 35% of the machine, reports no logical error rate, and its 90% saving traces to a 2024 Google estimate in a different unit
CTOL Digital Solutions (user-submitted news analysis) · Independent technical commentary · Germany / Europe
- Publisher
- CTOL Digital Solutions
- Original publication
- 2026-10-19
- Source retrieved
- 2026-10-20
- Event date
- 2026-10-19
What happened
CTOL argues the JUPITER result is a memory-management achievement, not a measurement of quantum error rates. Using NVIDIA's CUDA-Q technical blog, it notes the 104-qubit protocol was stored as a 45-bit encoded register (about 35.2 trillion amplitudes, 512 TiB, 64 GiB per GPU in double precision) on 8,192 of JUPITER's 23,536 Booster GPUs, about 35% of the machine; by its arithmetic one more bit would need 16,384 GPUs and two more would exceed the machine. It says the blog reports no logical error rate or fidelity, so the run cannot show whether coherent errors and leakage erode the saving. The 90% figure traces to a 2024 Google paper (Gidney, Shutty, Jones) measured in qubit rounds (space-time volume) under simpler uniform depolarizing noise, not physical-qubit counts. It credits the run as a useful reference simulator and notes cross-simulator agreement validated the software.
Why it matters
Useful to research institutions and public funders as a model of how to read vendor HPC and quantum claims: check the unit, the missing metric and the share of the machine consumed. The arithmetic is checkable against public figures, but the article is user-submitted, so treat it as informed commentary.
Evidence and measured results
Independent commentary built on NVIDIA's CUDA-Q blog and Jülich's published node counts; GPU projections for 46 and 47 bits are the author's arithmetic assuming double precision and ignoring communication overhead. Published under the site's news-submission rules; no author is named on the page.
Limitations and uncertainty
User-submitted article, author unnamed; projections are calculated, not measured. It disputes NVIDIA's framing but does not claim the run is wrong.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-20; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Funders and research leaders must judge vendor HPC and quantum claims before committing resources.
- Stakeholders
- Research office
- HPC allocation committee
- Grant officers
- Discovery questions
- What metric would show the scientific result, not just scale?
- What share of the machine does the claim require?
- Is there a peer-reviewed paper?
- Value hypothesis
- Interpretation: disciplined claim review avoids over-commitment to unproven approaches.
- Potential engagement
- Claims-review checklist for research-computing allocation and funding decisions.
- Unsupported claims
- That the NVIDIA run is invalid
- That the 90% saving is disproven
Pre-sales engineering
Role takeaway
- Fit
- Technical due-diligence reference for quantum-simulation claims.
- Architecture and integration
- Distributed state-vector simulation bounded by GPU memory; tensor networks for approximation.
- Prerequisites
- Access to methods and metrics
- Constraints
- User-submitted source
- Calculated projections
- Security
- Not applicable to this source.
- Proof of value
- Request the logical error rate for the simulated state
- Check precision and memory assumptions
Delivery
Role takeaway
- Work
- Embed metric and resource-share questions in allocation review.
- Dependencies
- Allocation policy
- Ownership
- HPC allocation committee.
- Skills and adoption
- Reviewers need basic quantum-error-correction literacy.
- Governance checkpoints
- Metric stated in proposal
- Post-run results report
- Acceptance criteria
- Proposed: every large-allocation proposal states its outcome metric
- Proposed: share of machine reported
- Risks
- Reviewer capacity limits
- Vendor resistance to disclosure
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
State-vector simulation memory doubles per encoded bit, so scale is bounded by machine memory; approximate methods such as tensor networks are the route beyond it.
Governance
Who approves, reviews and stays accountable for outcomes?
Supports requiring error metrics and peer-reviewed methods before public bodies cite vendor quantum results in funding or policy decisions.
Security and privacy
What data, permissions and controls need testing?
Not applicable to this source.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Not addressed by the source.
Procurement
What should contracts, pricing and exit terms secure?
Large-allocation justifications should state the share of a public machine consumed and the scientific metric delivered.
Operating model
Which teams own the service once it runs?
Allocation committees can ask for the outcome metric (here, logical error rate) as a condition of large runs.
Publication history
- 2026-10-19NVIDIA · Issue 448 resources
Stable resource ID: ctol-jupiter-simulation-no-logical-error-rate-90-percent-claim-20261019