fltech - Technology Blog of Fujitsu Research

A technology blog where Fujitsu researchers talk about a variety of topics

Top > Quantum > Attended ISC High Performance 2026 #1 ~Focusing on Quantum Computer x HPC related sessions

Attended ISC High Performance 2026 #1 ~Focusing on Quantum Computer x HPC related sessions

Quantum Computing

Introduction

Hello, this is Shun GOKITA from the Quantum Laboratory at Fujitsu.

From June 22 to 26, 2026, I attended ISC High Performance 2026 (hereafter, ISC 2026) held in Hamburg, Germany. In this article, I will share highlights from the conference, focusing on platform-related sessions concerning the integration of quantum computers into HPC environments.

ISC is one of the major annual international conferences in the HPC (High Performance Computing) field, held in Europe every June. Along with SC (held in the US), it is widely considered one of the world's two largest conferences in HPC. This year's event was held at the Congress Center Hamburg (CCH), with over 3,500 attendees and more than 200 exhibitors. The five-day program consisted of tutorials and workshops on the first (Monday) and last (Friday) days, and the main conference and exhibition running through the middle three days (Tuesday to Thursday). The theme of this year was "Connecting the Dots", with the integration of HPC, AI, quantum, and sustainability serving as an underlying thread throughout the conference.

Recently, integrating quantum computers into HPC has become one of the major topics at HPC-related international conferences. At ISC 2026 as well, quantum-HPC integration was discussed in a variety of session formats — from the Opening Keynote, panels, BoFs (Birds of a Feather), the HPC Solutions Forum, and Workshops. This article focuses on platform-level topics: how to integrate quantum computers into HPC systems and how to operate them.

I also gave a poster presentation myself, and I will touch on that content later in the article. Fujitsu had multiple presentations at ISC 2026 including at the Vendor Showdown, HPC Solutions Forum, Workshops, and Project Posters, as well as exhibits on the FUJITSU-MONAKA processor, FugakuNEXT, AI Computing Broker, and Fujitsu's efforts in quantum computing.

Fujitsu exhibition booth

Top500 Highlights: A CPU-Only System Takes the Top, ABCI-Q Ranks 38th

Before moving on to the technical sessions, let me briefly touch on the Top500 results announced at ISC 2026. Taking the top spot was LineShine, a system in Shenzhen, China, which recorded 2.198 EFlop/s on the HPL benchmark. It uses "LingKun," a proprietary Arm-based platform, and is a CPU-only system — the first ever to exceed 2 EFlop using only CPUs. Against a theoretical peak of 2.74 EFlop, its efficiency was about 80%, significantly outperforming the three US GPU-based systems (El Capitan, Frontier, Aurora), which achieve 50–65% efficiency.

Rank System Site HPL (EFlop/s)
1 LineShine Shenzhen, China 2.198
2 El Capitan LLNL (US) 1.809
3 Frontier ORNL (US) 1.353
4 Aurora ANL (US) 1.012
5 JUPITER Jülich (Germany) 1.000

JUPITER at 5th place is Europe's only exascale machine. Among Japanese systems, Supercomputer Fugaku ranked 9th (442 PFlop/s) and ABCI 3.0 ranked 19th (145 PFlop/s). ABCI-Q, which is related to my work, ranked 38th (74.58 PFlop/s). In the poster session mentioned later, I presented the quantum-HPC hybrid infrastructure that we are building on ABCI-Q.

In the same session, it was also announced that operation of the Top500 list will be transferred to ACM going forward.

With that, let me move on to the quantum platform-related sessions.

Opening Keynote: The Future of Heterogeneous HPC

The Opening Keynote on the first day of the main conference (June 23) was "HPC: A Heterogeneous Future" by Prof. Martin Schulz of the Technical University of Munich (TUM). This keynote set the context that ran through the subsequent quantum-related sessions.

Key points:

  • We are entering the post-Moore era, and GPU-based acceleration is starting to hit limits imposed by energy budgets
  • The next stage is heterogeneous computing: combining CPU/GPU with quantum, neuromorphic, and photonic technologies as part of a portfolio
  • Quantum computers should be positioned as accelerators, not replacements for HPC
  • The key to success is not the hardware but the software stack — a sustainable, unified, and extensible integration foundation is required
  • Hardware/software co-design, hierarchical scheduling, resource management, and cross-domain collaboration are all essential

As a concrete example of such a software stack, Prof. Schulz introduced the Munich Quantum Software Stack (MQSS), developed by the Munich Quantum Valley he leads. It is positioned as an integrated foundation enabling seamless transitions across devices and users, and is closely related to QDMI (Quantum Device Management Interface) described later.

The framing of quantum computers as "accelerators" was not limited to this keynote — it was a shared premise across nearly all quantum-related sessions that followed. Compared with just a few years ago when "quantum advantage" was the central topic, this seems to suggest that the quantum community as a whole has entered a more realistic phase.

Quantum-HPC Panel: Where the Platform Stands Today

At the panel session on June 23, "HPC-Enabled Path to Using, Scaling and Operating QC," representatives from HPC centers and quantum vendors gathered to discuss the current state and challenges of Q-HPC integration.

The panelists included the moderator from ICHEC (Ireland) and representatives from BSC (Barcelona Supercomputing Center, Spain), CINECA (Italy), IQM Quantum Computers (Finland, superconducting qubits), Equal1 (Ireland, silicon spin qubits), and Riverlane (Cambridge, UK, quantum error correction).

Each institution already operates quantum computers of multiple modalities. BSC operates MareNostrum-Ona alongside MareNostrum 5 (with CPU/GPU partitions), consisting of two digital quantum computers by Qilimanjaro (Transmon qubits) and one analog quantum computer based on Fluxonium qubits (EuroQCS-Spain, with multi-generation deployment planned). CINECA, in addition to cloud access, had just started official operation on June 11 — just before ISC — of two systems at their Bologna site: IQM Radiance (superconducting) and PASQAL Orion Beta (neutral atoms, 100+ qubits). CINECA also runs emulators in parallel within the site.

Equal1 introduced Bell-1 / RacQ, a 19-inch rack-mounted quantum computer using silicon spin qubits on CMOS. They develop the Cryo-CMOS control ASICs in-house, and the system runs from a self-contained cryostat connected to a standard power outlet — a design that emphasizes ease of integration into HPC environments. It was also memorable that the actual machine was on live demo on the exhibition floor.

Riverlane is a company specializing in quantum error correction (QEC), providing a QEC stack called Deltaflow. It offers modular, real-time QEC compatible with all major qubit technologies, and a partnership with HPE was also announced. They positioned MegaQuOp (one million error-free quantum operations) as a milestone in the near future. (While their original roadmap targeted the end of 2026, the industry consensus has since shifted toward around 2028 as the pivotal year.)

The panel discussion covered several active points:

  • Multi-dimensional constraints of orchestration: differences in modality (execution times differ by orders of magnitude), placement (on-site / cloud / remote), vendor-specific queues, required fidelity — no scheduler yet exists that can satisfy all of these simultaneously
  • Compilation time explosion: quantum compilation is dominated by routing & mapping, and the current Python-based approaches will not scale to 1000–2000+ qubits
  • Position of emulators: useful as a pre-deployment validation tool up to a few hundred qubits, but comes with economic issues due to heavy HPC resource consumption
  • Latency required by QEC: conditional branching below 10 μs, measurement processing at ns–μs scales — general-purpose OSes cannot handle this; real-time OSes with tightly coupled nodes are required
  • Benchmarking: single-QPU performance is not enough; full-stack benchmarks including QEC are needed

Particularly memorable was an anecdote from the IQM speaker about a system administrator at one of Europe's largest HPC centers, who reportedly said, "There's no way I'm reconfiguring Slurm." The message was clear: quantum-HPC integration must be done non-invasively, respecting the operational practices and accumulated experience that the HPC community has built over the past 40+ years. This point was repeated throughout the subsequent BoFs and HPC Forum.

BoF: Integration Patterns for Quantum-Classical Hybrid

At the Birds of a Feather session on June 24, "Quantum Classical Hybridization: Where Quantum Fits in the Continuum," a member of the JUNIQ project at Forschungszentrum Jülich (FZJ) presented a four-way categorization of how QPUs are integrated into HPC:

Pattern Characteristics Evaluation
① Cloud Access QPUs have vendor-owned queues Not really "integration," but important as an entry point
② HPC system-global QPU as a shared resource across the HPC system High utilization (recommended)
③ HPC node-local QPU dedicated to a specific node Minimum latency, but low QPU utilization
④ Combined A mix of the above A realistic deployment compromise

JUNIQ currently operates a range of modalities in parallel, including D-Wave annealers, PASQAL's neutral atom systems, and IQM's superconducting machines. Practical guidance was offered: "If you only have a single QPU, Cloud Access makes sense; if you have multiple identical QPUs, node-local becomes an option."

The most active discussion in this BoF was during the Q&A on resource estimation. Several panelists pointed out that the telemetry data taken for granted in HPC is simply not available from quantum vendors. The discussion converged on: "Vendors are reluctant to share, citing IP and commercial concerns, but the HPC community should keep pressing for it." BSC mentioned that they are co-developing a quantum extension of the HPC monitoring tool LIKWID together with its developers.

BoF: Quantum-Computing-as-a-Service (QCaaS)

Also on June 24, the BoF "Quantum-Computing-as-a-Service: What Do Users Want Today and How Can One Provide It?" brought discussions from both provider and user perspectives.

The provider-side panelists included representatives from GWDG (Göttingen), LRZ (Munich), Fraunhofer, Qoro Quantum, and Forschungszentrum Jülich. The speaker from LRZ mentioned that Euro-Q-Exa (IQM Radiance, in operation since February 2026) will be upgraded to a 100+ qubit system within the year, and that the four quantum computers currently at LRZ will be expanded to six by year-end. LRZ's concept of "treating the QPU like a math library" — providing a layer where users can invoke QPUs without worrying about backend implementation — was interesting.

From JUNIQ, a joint research example with Lufthansa Group on the Tail Assignment problem was introduced. When the aircraft assignment problem was reduced to a mid-scale quantum device, QAOA showed the success probability decreasing exponentially with qubit count, while an annealing version offered only limited improvement. In the end, Guided Quantum Walk achieved stable behavior with success probability close to 1. What was striking was the framing: "The goal is not to demonstrate quantum advantage, but to serve as a benchmark case for evaluating algorithmic suitability." A comment from the floor — "similar research elsewhere also failed to show classical-side advantage" — reinforced the practical, expectation-managed tone.

On the user side, a neuroscience/BCI (Brain-Computer Interface) researcher from the University of Freiburg School of Medicine gave a talk. As a researcher applying deep learning to BCI for both healthy individuals and paralyzed patients, they listed the following requirements for QCaaS:

  1. Conceptual accessibility: having someone to discuss with — more important than technical access
  2. Low-friction experimentation: access from familiar Python-based environments (scikit-learn, etc.)
  3. Performance assessment: clear comparison metrics against classical
  4. Hybrid workflows: connection to HPC and AI infrastructure

Placing "someone to discuss with" above "technical access" concisely captured the distance between the quantum community and application domains such as medical AI.

In the final vote of the panel, "clear use-case guidance and realistic expectation management" received the most votes as the most important element for advancing QCaaS. A closing comment resonated with the tone I felt throughout ISC this year: "HPC users should look for small pieces of their workflow that could be carved out for quantum, and come to us for consultation."

HPC Solutions Forum: QDMI

At the HPC Solutions Forum on June 24, Aqarios (a Munich-based startup) presented an implementation of QDMI (Quantum Device Management Interface).

QDMI is the hardware-software interface specification of the Munich Quantum Software Stack (MQSS) mentioned earlier. It is developed primarily by TUM (CDA and CAPS) and LRZ, with contributions from the open community. Its features are open-source and hardware-agnostic, with the goal of avoiding vendor lock-in.

The design philosophy was described as: bringing HPC's maturity (non-blocking resource usage, fair-share, observability, accountability) into the quantum side; abstracting hardware backends through an intermediate QDMI Device Plugin layer; caching calibration data to minimize latency. A typical deployment pattern was shown with QDMI placed between the Slurm controller and compute nodes — signaling that integration with existing HPC operations is being consciously considered.

As use cases, QSCI (Quantum Selected Configuration Interaction) in quantum chemistry and AFQMC (Auxiliary Field Quantum Monte Carlo) were introduced. Regarding AFQMC, a paper describing a polynomial-order reduction in classical cost had just been released on arXiv on the day of the presentation.

At the same forum, C12 Quantum Electronics (a Paris-based startup developing carbon-nanotube-based qubits) also gave a talk. Their "three requirements for making quantum computers deployable in HPC" were nicely laid out:

  1. Speed — not the single-gate performance, but the speed of the full execution cycle
  2. Scalability — manufacturability for QEC. "It's an architectural problem, not a software problem"
  3. Deployability — fit with the HPC environment (cooling, footprint, operational complexity, cost)

As a 10-year outlook to 2036, they shared: "The center that extracts the most value will not be the one with the biggest quantum system, but the one that integrates it best," and "The bottleneck will shift from 'compute' to 'coordination'." This felt like it captured the heart of the platform-level discussion.

HPC Solutions Forum: GENCI and the Alice & Bob Procurement

On June 25, GENCI (France) gave a presentation on the Alice & Bob cat-qubit system procurement, which had just been signed at VivaTech on June 17 — the week just before ISC.

The main points were:

  • 18 cat-qubits on the "Helium" platform
  • The first early Fault-Tolerant Quantum Computer (eFTQC) installed at a European computing center
  • Installed at CEA's TGCC facility, integrated with GENCI's Joliot-Curie supercomputer
  • User access starting in 2027
  • Joins the existing Ruby (Pasqal) and Lucy (Quandela) systems

GENCI as a whole is pursuing a unified HPC + AI + quantum platform vision, with plans for eventual integration with Alice Recoque, Europe's future exascale machine.

What is interesting is that Riverlane's Deltaflow (mentioned earlier) and Alice & Bob's cat-qubits represent two contrasting approaches to QEC. Riverlane takes the approach of "providing a modality-agnostic QEC layer in software," while Alice & Bob takes the approach of "suppressing bit-flip errors at the hardware level to reduce the QEC burden." If we add NVIDIA Ising (described later, using AI to accelerate decoding), we see three distinct directions running in parallel as QEC strategies.

Poster Presentation: Quantum-HPC Hybrid Infrastructure on ABCI-Q

Poster presentation
I gave a poster presentation on June 24, so let me touch briefly on the content.

The title was "A Quantum-HPC Hybrid Computing Infrastructure based on Open-source Quantum Computer Operations Software," a joint work between Fujitsu, the National Institute of Advanced Industrial Science and Technology (AIST), and the Center for Quantum Information and Quantum Biology at Osaka University. On top of the ABCI-Q platform mentioned earlier, we are building OQTOPUS (Open-source full-stack quantum computer operations software) — an initiative to develop a practical infrastructure that seamlessly connects HPC, quantum, and classical resources.

ABCI-Q is a platform operated by AIST that integrates a GPU-based supercomputer (System H: 2020 GPUs, 48,480 CPU cores) with three types of quantum computers:

  • System F: Fujitsu's 64-qubit superconducting quantum computer
  • System Q: QuEra's 260-qubit neutral atom quantum computer
  • System O: OptQC's 100-qumode photonic quantum computer

This configuration — integrating three quantum computers of different modalities into a single HPC infrastructure — is one of very few examples of its kind worldwide. OQTOPUS is a full-stack software layer integrating the necessary components: job management, transpilation, calibration, device gateway, and more.

During the poster session, I received many questions about HPC and quantum collaboration, and they were remarkably close to the topics being debated throughout the conference. Specifically:

  • Current and future plans for integration with HPC schedulers
  • Compatibility with QRMI / QDMI
  • Comparison with MQSS
  • Possibilities for cooperation with openQSE

The session reaffirmed our position as running in parallel with the standardization discussions covered in the workshops described later.

The ABCI-Q platform itself was also presented the following day (June 26) at the QRUCH workshop by Ryousei Takano from AIST, under the title "ABCI-Q: A Next-Generation Hybrid Computing Infrastructure Integrating AI, HPC, and Quantum Computing."

Workshop: QRUCH (Friday June 26, morning)

On Friday morning, the QRUCH 2nd Edition: Quantum Resources for Unified Computing Hub workshop featured an Opening Keynote by Travis Humble from Oak Ridge National Laboratory (ORNL), followed by a series of lightning talks from European and Japanese centers, and a panel discussion.

This workshop has a lineage: the BoF "Towards Hardware Agnostic Standards in Hybrid HPC/Quantum Computing" at ISC'24 → the first QRUCH at ISC'25 → and this second edition. What distinguishes it is its clear focus on the middleware needed to integrate quantum computers into HPC centers.

Given the structure of the workshop, let me highlight a few points that stood out.

ORNL Keynote — Travis Humble (Quantum Science Center Director)

ORNL was involved in the classical verification (using Summit) of Google's Sycamore quantum supremacy experiment in 2019, and the evolution of the Quantum Supremacy benchmark since then was described in detail. According to a 2025 paper, running the equivalent problem on Frontier would be estimated to take 6 billion years — older than the Earth.

As a concrete research example, the concept of Quantum Twin was introduced. A 50-site 1D XYZ Heisenberg model of Potassium Copper Fluoride (KCuF₃) was implemented on IBM's Heron processor "IBM Boston," and compared with the experimental spectrum obtained from ORNL's Spallation Neutron Source. An Entanglement Witness (derived from Quantum Fisher Information) was used to quantify the entanglement of the ground state.

What was noteworthy was the honest disclosure that "the quantum computer result appears to match the experiment better than a noiseless Tensor Network calculation — but this is misleading, because they happen to look similar due to noise of different origins." This kind of unexaggerated presentation is a model for research communication.

On the US-side activities, the openQSE (Open QHPC Software Ecosystem) initiative was also introduced. It is a Working Group led by Amir Shehata (ORNL, described later), with cross-cutting participation from HPC centers, quantum vendors, system integrators, and users. Additionally, it was mentioned that ORNL has installed Quoll — a quantum computer cluster based on diamond NV qubits from Quantum Brilliance (an Australia-based company) — in the Advanced Computing Ecosystem testbed at OLCF. The 3 QDK × 2 qubit = 6 qubit configuration operates at room temperature, so unlike superconducting systems, it does not require large-scale cooling infrastructure.

BSC: Circuit Cutting and Quantum Circuit Cache

BSC presented on circuit cutting and Quantum Circuit Cache implementation using the Qdislib library. They support multiple circuit cutting methods across Qiskit / Cuda Quantum and other frameworks, and use ZX-calculus to determine semantic equivalence between "syntactically different but semantically equivalent" circuits generated by cutting, so that cached previous results can be reused. Since QPU execution is inherently serial, removing avoidable executions from the critical path yields substantial speedups.

In the Q&A, when asked "What is the biggest blocker?", the answer was the lack of use cases. The observation that "without concrete hybrid workflows in hand, the design of orchestration and scheduling becomes hypothetical" likely resonates with many HPC centers.

PSNC (Poland): Four Integration Scenarios

PSNC (Poznan Supercomputing and Networking Center) presented the deployment of PIAST-Q (a trapped-ion quantum computer under EuroHPC), along with four integration scenarios:

  1. Tight integration: 1 QPU + many CPUs/GPUs. QDMI support via a Slurm SPANK plugin
  2. Multi-QPU + Multi-GPU: multiple photonics + multiple GPUs in collaboration with NVIDIA
  3. Coexistence of Cloud + Tight integration: lightweight cloud frontend for training use
  4. Distributed Quantum Computing: entanglement connection to a site in Warsaw

Building on the largest inter-HPC-center network in Europe operated by PSNC, they are looking ahead to a Quantum Internet (integrating quantum devices including sensors) as a longer-term vision.

CINECA: Smart Job Scheduling Experiment

CINECA presented a comparison of three scheduling strategies.

Strategy Behavior
Baseline Reserve all HPC + quantum resources at job start
Workflow Alternate classical jobs and quantum jobs sequentially
Malleability Always run with minimal CPU resources, adding more resources as they become available

In experiments on Leonardo (CINECA's Top500 #12 HPC system) with emulated QPUs, the Malleability approach achieved a 50–64% reduction in HPC resource usage. For modalities like neutral atoms where the quantum job itself takes hours, dynamic scheduling techniques of this kind can be especially effective. It's a valuable insight for future operational design.

ABCI-Q (Japan, AIST): AI Scientist Perspective

From Japan, Ryousei Takano of AIST presented an overview of the ABCI-Q platform and its future vision. As mentioned earlier, ABCI-Q — installed at AIST's Kashiwa campus — is a world-class configuration integrating a GPU-based AI supercomputer with three types of quantum computers (superconducting, neutral atom, and photonic).

Particularly noteworthy was the discussion of an AI Scientist-oriented agentic workflow as part of the long-term vision. Building on the premise that "by the 2030s, AI scientists will autonomously design and run experiments," AIST is developing benchmarks on ABCI-Q to evaluate AI models' capabilities in the quantum domain. The message that "in the AI scientist era, HPC will need to be redesigned to be agentic-centric across APIs, preserved security, governance, billing, and more" contrasted interestingly with the more system-integration-focused discussion coming out of Europe.

JUNIQ: Integration Mode and the Captiva Appliance

In a lightning talk near the end of the workshop, JUNIQ (which had also spoken at the June 24 BoF) presented a more detailed integration model. At the core is an appliance-based solution called Captiva, integrated with identity servers (NetIQ) and Slurm to operate multiple QPU modalities in HPC system-global mode.

Their Continuous Benchmarking work was also interesting: they extended the HPC monitoring tool LIKWID for quantum use, and run a simple benchmark job on the QPUs once per hour to continuously monitor things like calibration drift. The comment that "you can't get this data if you're only using the cloud" concisely conveyed the value of on-premise operation.

Workshop: Standardization of Quantum-Classical Integration (Friday June 26, afternoon)

On the afternoon of June 26, the 5th Workshop on Quantum and Hybrid Quantum/Classical Computing Approaches was held. Like the QRUCH workshop in the morning, the theme was quantum-HPC integration, but this session focused especially on standardization of the software stack.

NVIDIA: CUDA-Q / NVQLink / Ising Full Stack

The first talk was from NVIDIA, positioning their quantum strategy as applying the accelerated-computing stack experience of the past 20–25 years to quantum computing — the next "accelerator." The product stack:

  • CUDA-Q: A quantum version of CUDA — an open developer platform
  • cuQuantum: GPU acceleration for quantum simulation
  • CUDA-QX: Domain-specific built-in kernels
  • NVQLink: A high-speed interface between the Quantum System Controller and GPUs

What deserves special attention is NVIDIA Ising, released in April 2026 — an open-source AI model family for quantum computing. Ising Calibration (a Vision Language Model) automates the calibration of quantum processors, reducing the time from days to hours. Ising Decoding (based on 3D CNNs) performs real-time QEC decoding, achieving 2.5× faster and 3× more accurate results than the current industry-standard pyMatching. Early adoption is progressing across a range of quantum companies and research institutions such as IQM, IonQ, and Atom Computing.

NVIDIA CEO Jensen Huang was quoted as saying, "AI is the control plane — the operating system of quantum machines." The talk made NVIDIA's strategy of embedding itself deeply into the quantum computing industry — without building quantum hardware itself — very clear.

Dell Technologies: NVQLink × PowerEdge Validation

Next, Dell Technologies presented validation results for quantum-classical connection via NVQLink using Dell PowerEdge servers. By directly connecting an FPGA-emulated quantum system controller to a Dell server via RoCEv2, they achieved sub-microsecond round-trip latency. It was also shown that performance improves further with GPU generation (Blackwell) and firmware release level. The fact that they presented real measured numbers gave the talk strong credibility.

STFC Hartree Centre: QRMI

The UK's STFC Hartree Centre introduced QRMI (Quantum Resource Management Interface) — another abstraction layer alongside QDMI mentioned earlier.

The distinguishing feature of QRMI is that it is not an SDK but purely an infrastructure abstraction layer. Existing SDKs (Qiskit, Cirq, etc.) can be used as-is, and HPC resource managers (Slurm, etc.) can treat quantum computers as schedulable resources just like GPUs. It's a lightweight design consisting of only about 10 methods, with the same vendor-agnostic, open-source approach as QDMI.

On the difference from QDMI, the speaker explained: "QDMI is a compiler-oriented design that provides detailed information about the quantum backend. QRMI focuses on making quantum resources usable from the scheduler with minimal information, from the HPC user's perspective." Their stance was that "which one remains is unclear — we are in the phase of deploying both and seeing what sticks." A detailed paper is planned for SC25.

openQSE: Open Quantum-HPC Ecosystem

Amir Shehata (ORNL) reported on the activities of the openQSE community. In response to the current situation where numerous software stacks have been developed independently at different institutions, they started weekly meetings for consolidation and are now in the process of joining the Joint Development Foundation / Linux Foundation. Multiple Working Groups (Software Architecture, System Architecture, Quantum Resource Management Interface, Compiler Infrastructure) are advancing the discussion. Particularly in the QRMI WG, they are prototyping a shim layer combining QDMI and QRMI, aiming to eventually converge on a single unified interface.

The message "The current situation is a mess. We want to converge this into an open compute ecosystem" was echoed by Lukas Burgholzer (CTO of Munich Quantum Software Company), who spoke next. Lukas walked through the concrete steps of implementing QDMI on IBM systems using detailed sequence diagrams.

Pasqal: CINECA "Sol" Integration and Second-Level Scheduler

Pasqal presented the integration approach for CINECA's "Sol" system (scheduled for commissioning in September).

What was distinctive was that, on top of a Slurm SPANK plugin + QRMI, they introduce a lightweight Pasqal-specific middleware layer (second-level scheduler). It includes functions for authentication (leveraging Munge), queueing, and accounting, and is designed to handle cloud and HPC on a single platform. The pragmatic design philosophy — "beyond central standards, we also need a thin layer to absorb vendor-specific concerns" — came through clearly.

IBM Quantum: Practical Quantum Advantage and Hierarchical QEC

Antonio Corcoles from IBM Quantum gave an overall picture of IBM's quantum-HPC integration, focusing particularly on the criteria for Quantum Advantage and the architecture of QEC. IBM's roadmap targets realizing fault tolerance in 2028–2029 as a publicly stated goal.

What stood out in the Quantum Advantage discussion was the distinction from "Quantum Utility" — a concept IBM proposed two years ago. While Quantum Utility indicates a state that "exceeds brute-force classical simulation," Quantum Advantage is more strictly evaluated by three criteria: (1) mathematically rigorous accuracy with confidence bounds, (2) improvement of the upper bound on variational problems, and (3) judgment based on distribution bias in large-scale circuits. To avoid the pattern of "claim X gets made, then later gets overturned by classical" repeating itself, IBM is asking the community for transparent and reproducible evaluation.

The QSCI hybrid workflow implementation was also introduced concretely. In the older version, quantum circuits were run for about an hour at the NY data center, and then classical subspace diagonalization was done afterward — sequentially. In the improved version, they introduce a pipelined design that runs post-processing of the previous circuit on the classical side while the next circuit runs on the quantum side, improving both efficiency and scientific yield.

For QEC, IBM described adopting a three-layer hierarchical architecture. Near the chip, a Local layer (fast FPGAs for immediate syndrome processing); above it, a Logical layer (codeblock-level operations, throughput-focused); and finally, on the HPC cluster, a Cluster layer (higher-level decoding algorithms). This design reflects the recognition that a large amount of syndrome data generated per microsecond must be decoded in real time — and that no single location can handle it all. Together with NVIDIA Ising's hierarchical approach, Riverlane Deltaflow, and Alice & Bob cat-qubits, this reaffirms how diverse the approaches to QEC have become.

Peter Coveney (UCL): Real Applications Using Quantum Computers

The workshop closed with a talk by Prof. Peter Coveney of University College London on scientific applications. His opening remarks — "I do real science, I'm not here to play with quantum technology" and "My problems demand exascale" — set the tone for a very grounded talk.

Two applications stood out.

The first is a simulation of the active-site reaction of GPCR (G protein-coupled receptor, the third most important protein in drug discovery). A multi-scale QM/MM approach was used: the full molecule in classical MM, the intermediate region in DFT, and only the wave function of the active site on the quantum computer — using IBM's 127-qubit machine. The wave function returned from the quantum side then requires a 1 billion × 1 billion matrix diagonalization on the classical side, which would take 3 weeks on the 64 GPUs available under normal allocation, but was reduced to 1 hour on 1,200 GPUs in collaboration with NVIDIA. This is a striking example of how the arrival of quantum computers demands massive classical computing resources not only on the quantum side but also on the classical side. As for algorithms, QSCI — not VQE — is what is practical these days.

The second is long-time prediction of turbulence, a case of "Quantum for AI" — the reverse of "AI for quantum." Using a quantum computer as a prior for classical machine learning, and implementing it with 12 qubits on the IBM Garnet chip, they showed that while major ML approaches such as neural operators and Gaussian processes break down at long times, quantum-informed ML remains stable over long time horizons. Moreover, this is achieved with far fewer parameters and less data than conventional AI models. The next target is reportedly "tomorrow's weather forecast."

Overall Thoughts: Where Is the "Quantum-HPC Integration" Discussion Heading?

Reflecting on the five-day conference, several points stood out to me.

First, European quantum-HPC integration is clearly moving from the "implementation" phase to the "standardization" phase. BSC, CINECA, LRZ, JSC/Jülich, GENCI, CESGA, and PSNC are all operating multiple quantum modalities in parallel. The EuroHPC integration project (EuroQHPC-Integration) was shared at the GENCI presentation during QRUCH on June 26, with a grand scale of "30 partners, 17 European countries, 6 quantum computers × 6 supercomputers" in motion.

Second, the center of gravity of the discussion has fully moved from hardware to software and integration. Five years ago, qubit counts and fidelity would have been the main topics. Now, the discussion is centered on platform-layer topics such as QDMI / QRMI, MQSS, SLURM integration, resource estimation, and observability.

Third, a cautious stance on quantum advantage is broadly shared across the community. As illustrated by the Lufthansa case, the framing of "not aiming to beat classical with quantum, but valuing this as a benchmark case for evaluating algorithmic suitability" — this careful attitude, and wariness of overhype, was repeatedly mentioned across multiple sessions.

Fourth, QEC has begun to enter the platform-level discussion as well. Various approaches such as Riverlane Deltaflow, Alice & Bob cat-qubits, and NVIDIA Ising are running in parallel, and MegaQuOp (one million error-free quantum operations) was shared as a milestone in the near future.

On the other hand, listening to the quantum-HPC integration discussion, I felt that while the "ideal-picture" infrastructure discussion is very active, the connection to concrete applications is harder to see. Looking closer, "quantum-HPC integration" — as a phrase — actually mixes three technically very different layers with vastly different timescales:

Layer Timescale Representative Technologies
① Tight coupling (QEC layer) Microseconds – milliseconds NVQLink, Riverlane Deltaflow, NVIDIA Ising Decoding
② Variational loop Seconds – minutes Quantum variational algorithms like VQE/QAOA; quantum resource abstraction via QDMI/QRMI; HPC-side job scheduling
③ Workflow orchestration Hours – days Quantum sampling with heavy classical post-processing, like QSCI or AFQMC

Of the infrastructure standardization efforts discussed at ISC 2026, NVQLink is mainly aimed at ①, while QDMI/QRMI/openQSE are mainly aimed at ②. Yet the actual results from the user side are emerging in ③. There is a subtle misalignment here.

Layer ① does require tight coupling, but it is also an area where vendors like IBM, IQM, NVIDIA, and Quantinuum have already built their own stacks. The eventual value of open standardization here is uncertain.

Layer ② is likely to lose its central role once FTQC is realized. The main algorithms in this area — variational algorithms like VQE — are NISQ-era algorithms. Once fault-tolerant quantum computing becomes available, algorithms that don't require quantum-classical iteration (such as Quantum Phase Estimation) are likely to become mainstream. The Lufthansa Tail Assignment case, in fact, ended up being positioned as "valuable for confirming that QAOA is fundamentally unsuited to this problem."

Layer ③ is a use-case pattern currently considered useful for quantum-HPC integration, and may survive into the FTQC era — but the quantum-HPC relationship in this layer is not "tight coupling." The QSCI example is symbolic: after obtaining a wave function on the quantum computer, a huge matrix is diagonalized on the classical side over hours. It's a workflow of "heavy classical pre-processing → quantum sampling → even heavier classical post-processing" — one where you might even argue the classical side is the protagonist.

In other words, the layer being standardized on the infrastructure side, and the layer where users are actually producing results, are not necessarily aligned.

The reasons for this subtle misalignment likely include: an "insurance policy" aspect for the NISQ-to-FTQC transition; a procurement-strategy aspect for preventing vendor lock-in; and a narrative-construction aspect for ensuring that the HPC community's operational know-how continues to be valuable in the quantum era — each contributing a little.

Given this situation, what those of us on the platform side should focus on, I believe, is not over-optimizing for a specific use case too early, but maintaining the flexibility to respond regardless of which application pattern becomes mainstream.

That said, while "maintaining flexibility" sounds simple, in practice it means dealing with: different APIs from every vendor, multiple standardization proposals (like QDMI vs QRMI), differences among HPC schedulers, and the diversity of application patterns — the cost of covering all of these easily exceeds what a single institution can bear.

This is not just a concern for our team — it is a structural challenge shared across all institutions working on quantum-HPC integration. That openQSE and similar efforts are being pursued through open communities is, I believe, exactly a reflection of this recognition.

With this in mind, I felt that for the development of OQTOPUS as well, working in collaboration with the open community — building the shared components together — is the sustainable path for ensuring flexibility. Such efforts are particularly meaningful precisely in this time of high uncertainty in quantum-HPC integration.

ISC 2027 will also be held in Hamburg. I'm looking forward to seeing how much this field advances in one year — particularly, what choices the application layer and the platform layer each make during the transition from NISQ toward FTQC.

References

This article is a summary intended for external publication. Some content from institutions and companies has been simplified. For details, please refer to the official announcements from each organization.