In Part 1 of the series, we showed how quantum computing can be applied to protein folding by mapping molecular conformations to quantum optimization problems. Using Divi, Maestro, and Composer, we demonstrated how large-scale protein models can be simulated efficiently through Qoro Cloud—where simulation clusters are automatically deployed, scaled, and tuned for performance. We then ran a 17-qubit optimization on IBM hardware using automated, hardware-level parallelization.
While 17-qubit problems are still small enough for exact statevector simulation, real protein models grow far beyond that scale. As problems become larger, simulation becomes more difficult, and quantum hardware becomes more valuable. This brings us to the focus of Part 2: how to reduce the number of quantum hardware evaluations needed to reach a high-quality solution on problems that can’t be perfectly simulated.
Here, we explore a strategy known as pretraining. Rather than starting variational algorithms from random parameters, we use large-scale classical or hybrid simulations to identify promising regions of the energy landscape before touching the QPU. This dramatically cuts down the number of hardware iterations required—reducing cost, runtime, and noise accumulation.
In this post, we build off a recent paper from Zapata Computing, which showed how Matrix Product State (MPS) simulations can pretrain variational circuits for better performance on real hardware. While their approach used MPS tensors to reconstruct an Ansatz, we take a more direct path: simulate quantum circuits at large scale, extract good parameters, and continue the optimization on quantum hardware.
Using Qoro’s software stack, this entire hybrid workflow—from distributed MPS simulation to QPU execution—runs automatically. As a demonstration, we applied pretraining to several protein-folding instances, including a 61-qubit model with 4,690 Hamiltonian terms. In fewer than 50 lines of code, we completed the whole workflow: large-scale pretraining, parameter selection, circuit packing, error mitigation, and QPU execution.
The results show clear reductions in runtime, cost, and convergence steps. Pretraining emerges as a practical and powerful pattern for future HPC + QC systems: use simulation at scale to explore cheaply, and reserve the quantum computer for the steps where it provides unique advantage.
What Is Pretraining?
Pretraining is the idea of giving a variational quantum algorithm a head start. Instead of beginning an optimization from random parameters—which can require hundreds or thousands of QPU evaluations to stumble into a good region of the landscape—pretraining identifies a promising neighborhood before the quantum hardware ever runs.
In quantum optimization, this matters enormously: most of the time and cost in variational algorithms comes from evaluating poorly performing parameter sets on the QPU. If we can prune that exploration and begin near a low-energy region, the hardware needs far fewer iterations to converge.
In the context of protein folding, pretraining means using classical or hybrid simulation methods to approximate a good configuration of variational parameters. These pretrained parameters encode a rough but meaningful understanding of the target energy landscape. When the quantum computer begins its optimization, it does so from a point already shaped by large-scale simulation, rather than from a random guess.
This approach can drastically reduce total QPU usage, shorten optimization runtime, and improve stability—especially for noisy devices. Pretraining is rapidly emerging as one of the most practical techniques for hybrid quantum-classical workflows: use classical compute to explore cheaply at scale, then use quantum hardware only where it provides unique value.
How Divi, Composer, and Maestro Automate Pretraining
Once we choose to pretrain an optimization, Qoro’s software stack handles the entire workflow automatically—from large-scale simulation to quantum hardware execution.
Divi is the user-facing Python interface where the optimization problem is defined. When pretraining is configured, Divi orchestrates the full sequence of steps: generating candidate parameter sets, performing sampling-based searches (e.g., Monte Carlo), selecting the best-performing parameters, and handing them off to the quantum execution stage.
Maestro carries out the simulation work that makes pretraining possible. For these experiments, it used its MPS backend to evaluate expectation values for dozens of qubits efficiently. MPS allows simulations far beyond the reach of traditional statevector methods, enabling us to explore the landscape of the protein-folding Hamiltonian at significant scale.
Composer provides the system-level intelligence—allocating simulators, routing jobs, scaling compute resources, and later switching seamlessly from simulation to QPU execution. Composer ensures that the right hardware or simulator is used at each stage and that the system remains elastic, responsive, and cost-efficient.
All of this runs on Qoro Cloud, which serves as the glue. It connects Divi’s optimization logic with Composer’s orchestration engine, coordinating distributed simulations, parallel sampling, and hardware execution without any manual intervention.
During the pretraining stage, Qoro Cloud provisioned a temporary cluster of Maestro simulators and executed 10 Monte Carlo iterations, each evaluating 100 sampled parameter sets. Maestro’s distributed MPS engine processed 1,000 independent 61-qubit circuits—encompassing 4,690 Hamiltonian terms—in roughly five minutes. The result was a high-quality set of pretrained parameters ready for QPU execution.
With this automated workflow, the transition from large-scale simulation to quantum hardware becomes a single, unified pipeline. The user writes fewer than 50 lines of code; Qoro’s software stack handles the rest.
The Implementation
The Divi code used to implement the workflow is similar to the previous post. Here we show how pretraining is configured. First we configure to run on the Maestro backend. The backend automatically detects that this is an expectation value job and does not use sampling methods. Shots can be provided to the simulator, but this is only used if the states should be extracted.
To run the pretraining step:
Then we can switch the optimization technique and to switch to the IBM quantum computer. We add a bit of noise to the best parameters to continue to minimize.
And that’s all. With less than 50 lines of code, we can pretrain a 61-qubit VQE problem, change the optimization strategy, and gain all of the parallelization and hardware optimization method already built into the Qoro stack.
The Performance
We ran the experiment with both a 39-qubit problem and a 61-qubit problem. First, we time the pretraining strategy using a varying number of ansatz layers. The total end-to-end training time to run a population based optimization technique is recorded. Composer allocated 8 cloud nodes (scaling up with time to minimize cost) running Maestro with 8 GB of RAM and 4 vCPUs on Spot Instances, roughly costing 50 cents / hour. The Maestro simulator automatically determined that MPS is the most effective way to simulate these circuits using a bond dimension of 16.
Pretraining
In the largest experiment, it takes roughly 15 minutes to run 1,000 61-qubit circuits on very modest hardware. A computational cost of at most $1.00 to pretain the problem in the worst case.
39-qubits
The figure compares three stages of the hybrid workflow:
- MPS Simulation Pre-optimization (blue)
- QPU execution with pretrained parameters (orange)
- QPU execution without pretraining (green)
The simulation phase (Iterations 0–9) shows the MPS optimizer steadily reducing the energy from ~3200 down to ~300, demonstrating that the simulation finds a good region of the variational landscape before any QPU call is made. This trained parameter set is then passed directly to the hardware.
Pretrained QPU Execution: Faster Convergence, Lower Cost
When the QPU starts running (Iteration 9 onward), the pretrained execution begins around 7800 energy, immediately near the region of good solutions. Across the following iterations, the pretrained run remains stable and steadily decreases toward ~6100.
Because the optimizer starts close to an optimum, it requires fewer QPU iterations, which directly maps to lower hardware cost. In this experiment, the pretrained run corresponds to approximately:
$1440 total QPU cost (based on the number of circuit evaluations and packing).
Non-pretrained QPU Execution: High Variance, Slower Convergence
In contrast, the run that begins without pretraining arrives on hardware with no prior information. It starts at a similar initial energy (~7200), but the optimizer struggles to find good directions. It wanders into a significantly higher-energy region (~11,800 at Iteration 12), demonstrating high variance and inefficient exploration. Moreover, to minimize the noise, we used no circuit-packing, which increases runtime.
This unstable trajectory forces the optimizer to evaluate more parameter sets, increasing both runtime and QPU usage. The non-pretrained run costs:
$5760 total QPU cost, four times more than the pretrained case.
Pretraining dramatically improves the hardware efficiency:
Key Insight
- 4× reduction in QPU cost
- More stable convergence
- No wasted iterations exploring poor regions of the landscape
Even with a shallow p=2 hardware-efficient ansatz, pretraining provides a clear advantage. It allows the QPU to operate only where it matters—fine-tuning parameters—rather than performing broad, expensive searches across the parameter space.
61-qubits
This experiment examines a 61-qubit protein-folding Hamiltonian using a shallow hardware-efficient ansatz (p=1). The plot compares:
- QPU-only optimization (blue) — starting from random parameters
- Simulation-based pretraining (red) — using MPS to find good parameters
- QPU continuation after pretraining (green) — running those pretrained parameters on the real device
QPU-Only Execution: Slow and Unstable Convergence
The blue curve shows the trajectory when the optimizer runs entirely on hardware with no prior knowledge. It begins at a very high energy (~17,800) and gradually decreases, but the convergence is slow and inconsistent:
- Iteration 1: ~17,800
- Iteration 2: ~12,900
- Iteration 3: ~5,300
- Iteration 4: ~1,200 (temporary dip)
- Iteration 5–6: energy rises again to ~4,000
The optimizer oscillates and struggles to maintain progress, a common issue for shallow ansätze on noisy devices. Without pretraining, many circuit evaluations are wasted exploring poor regions of the parameter landscape. Further, we used 122 qubits of the device to run these experiments in parallel, vastly improving runtime and cost.
Simulation Pretraining: Rapid and Stable Energy Reduction
The red points show the MPS-based simulation run that produces pretrained parameters. With only a few iterations of classical simulation:
The energy drops from ~10,600 → ~3,100 → ~700 → ~500 → ~450 → ~430
Within just a handful of simulation steps, the system finds a region extremely close to the optimum—without spending any QPU time.
When these parameters are transferred to the QPU (green curve), the hardware optimization begins already near the low-energy basin, starting around ~2,300 and then steadily improving:
- Iteration 10 (start): ~2,300
- Iteration 11–12: ~2,000–2,200
- Iteration 13: ~1,500
- Iteration 14: ~900
Key Insight
For this 61-qubit problem with p=1:
- Pretraining finds good parameters 4–6× faster than hardware alone.
- Hardware-only execution wastes early iterations in bad regions.
- Warm-starting the QPU reduces both noise sensitivity and cost.
Observable Grouping and Massive QPU Job Reduction
A major contributor to the efficiency of these experiments comes from Divi’s automatic observable grouping, which minimizes the number of circuits sent to the quantum hardware. Protein-folding Hamiltonians consist of thousands of Pauli terms, each of which normally requires its own circuit execution when moving from simulation (expectation-value computation) to hardware sampling.
For the 39-qubit protein with 13 amino acids, the Hamiltonian contains 1,913 individual Pauli terms. Naively, each optimizer iteration would require executing all 1,913 circuits for every sampled parameter set—a prohibitively expensive process on today’s QPUs. Instead, Divi groups all compatible observables into a single measurement circuit, reducing the hardware load from 1,913 circuits per iteration to just one. That is a 1,913× reduction in QPU job count without altering the algorithm logic.
This advantage becomes even more dramatic at larger scales. The 61-qubit model for the 16-amino-acid sequence LVRGGEDPMAARARLY contains 4,690 Hamiltonian terms. Divi’s grouping again consolidates these into a single circuit, achieving a 4,690× reduction in required QPU jobs. These optimizations—handled transparently by Divi—are essential for making large-scale quantum optimization viable on current hardware and for enabling hybrid simulation-to-QPU workflows at this scale.
Conclusion
Across both the 39-qubit and 61-qubit protein-folding experiments, the results demonstrate that pretraining is one of the most effective tools for reducing quantum hardware cost while maintaining strong convergence behavior. Running variational optimization directly on a quantum device leads to unstable trajectories, noisy gradients, and many wasted iterations. In contrast, pretraining with large-scale simulation produces parameter sets already near the low-energy region of the landscape. When these warm-started parameters are transferred to the QPU, the optimizer converges faster, more smoothly, and with far fewer hardware evaluations.
The impact is substantial: pretraining cuts QPU usage by factors of 3×–4× in our tests, and when combined with circuit packing, users can further control the trade-off between runtime, cost, and solution quality. Packing also ensures that batched circuits execute efficiently on hardware, giving users a practical mechanism to tune experiment cost.
These gains are amplified by Divi’s observable grouping, which collapses thousands of Hamiltonian terms into a single circuit. For the 13-amino-acid (39-qubit) instance, Divi reduces 1,913 circuits to just one; for the 16-amino-acid (61-qubit) model, 4,690 terms collapse to one. This grouping alone makes large-scale quantum optimization feasible on today’s devices.
Why It Matters
This set of experiments highlights how classical simulation and quantum hardware can cooperate efficiently when unified under a single automated workflow. Pre-optimization on simulators eliminates the need for expensive hardware iterations early in the optimization process, while Qoro Cloud ensures that the full pipeline—sampling thousands of 61-qubit circuits, running Monte Carlo searches, grouping observables, packing circuits, and executing on IBM hardware—operates as a seamless, continuous workflow.
Each component of the Qoro stack plays a distinct role:
- Divi simplifies algorithm development, automates observable grouping, and handles transitions between simulators and QPUs.
- Maestro provides scalable, high-performance simulation using MPS-based expectation-value computation for many-qubit systems.
- Composer orchestrates compute resources, manages packing and scaling policies, and coordinates distributed execution.
- Qoro Cloud integrates all layers—simulation, orchestration, optimization, and hardware execution—into a unified environment.
By combining the precision of classical simulation with the power of real quantum hardware, Qoro’s platform reduces both the time and cost of quantum experiments. This hybrid approach is a strong step toward practical quantum computing for applications such as protein folding, molecular design, and materials optimization.
