Optimisation de la transpilation avec SABRE
Estimation du temps d'exécution : 1 minute sur un processeur Heron r2 (REMARQUE : il s'agit uniquement d'une estimation. (La durée d'exécution peut varier.)
Acquis d'apprentissage
À l'issue de ce tutoriel, vous devriez avoir compris :
- Comment configurer les paramètres SABRE (
layout_trials,swap_trials,max_iterations) pour améliorer la qualité de la transpilation - Les compromis entre le temps d'exécution de la transpilation et la qualité du circuit (profondeur et nombre de portes)
- Comment personnaliser l'heuristique de routage SABRE (
basic,decay,lookahead) et comparer ses performances sur du matériel
Prérequis
Nous vous recommandons de vous familiariser avec les sujets suivants avant de commencer ce tutoriel :
- Transpilation de circuits : aperçu de la transpilation dans Qiskit
- Étapes du transpileur : étapes de disposition et de routage
- Configurer les gestionnaires de passes prédéfinis : personnalisation des niveaux d'optimisation
Arrière-plan
La transpilation permet de convertir des circuits quantiques en formats compatibles avec un matériel quantique spécifique. Deux étapes clés consistent à choisir une configuration des qubits (mise en correspondance des qubits logiques avec les qubits physiques) et à définir le routage des portes (insertion de portes SWAP afin que les portes multi-qubits respectent la connectivité du dispositif).
SABRE ( algorithme de recherche heuristique bidirectionnelle basé sur la méthode SWAP ) optimise à la fois la disposition et le routage. Cette méthode s'avère particulièrement efficace pour les circuits à grande échelle (plus de 100 qubits) sur des dispositifs présentant des cartes de couplage complexes, comme les processeurs Heron d' IBM®. SABRE minimise le nombre de portes SWAP et réduit la profondeur du circuit, ce qui améliore la fidélité d'exécution. Les récentes améliorations apportées à l'algorithme « LightSABRE » permettent de réduire encore davantage les temps d'exécution et le nombre de portes logiques.
Dans ce tutoriel, vous allez tout d'abord configurer SabreLayout le circuit GHZ à l'aide de différents paramètres afin de l'optimiser, puis observer l'impact de ces réglages sur la fidélité d'exécution. Vous comparerez ensuite les algorithmes de calcul d'itinéraires de SABRE à grande échelle sur du matériel réel.
Exigences
Avant de commencer ce tutoriel, assurez-vous que les éléments suivants sont installés :
- Qiskit SDK v2.0 ou version ultérieure, avec prise en charge de la visualisation
- Qiskit Runtime v0.22 ou version ultérieure (
pip install qiskit-ibm-runtime) - Qiskit Aer (
pip install qiskit-aer)
Configuration
from qiskit import QuantumCircuit
from qiskit.quantum_info import SparsePauliOp
from qiskit_ibm_runtime import QiskitRuntimeService
from qiskit_ibm_runtime import EstimatorOptions
from qiskit_ibm_runtime import EstimatorV2 as Estimator
from qiskit_aer.primitives import EstimatorV2 as AerEstimator
from qiskit.transpiler.passes import (
SabreLayout,
SabreSwap,
BarrierBeforeFinalMeasurements,
StarPreRouting,
)
from qiskit.transpiler.passes.layout.vf2_layout import VF2LayoutStopReason
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit.passmanager.flow_controllers import ConditionalController
import matplotlib.pyplot as plt
import numpy as np
import time
seed = 42
service = QiskitRuntimeService(
channel="ibm_cloud",
token="<YOUR_API_TOKEN>", # Replace with your actual API token
instance="<YOUR_INSTANCE_NAME>", # Replace with your instance name if needed
)
backend = service.least_busy(operational=True, simulator=False)
print(f"Using backend: {backend.name}")Output:
Using backend: ibm_kingston
Exemple de simulateur à petite échelle
Dans cette section, un simulateur avec bruit, basé sur le modèle de bruit du backend réel, est utilisé pour montrer comment différentes SabreLayout configurations influencent à la fois la qualité de la transpilation et la fidélité d'exécution. L'utilisation de qiskit_aer avec un modèle de bruit dérivé de données réelles d'étalonnage matériel vous permet de tester la transpilation sans consommer de crédits matériels.
Étape 1 : Mettre en correspondance les entrées classiques avec un problème quantique
Nous construisons un circuit GHZ à topologie en étoile comportant 15 qubits. Le premier qubit sert de nœud central, et des portes CNOT le relient directement à tous les autres qubits. Cette topologie pose un problème complexe d'agencement, car elle ne se traduit pas de manière évidente par la carte de couplage du dispositif.
Nous définissons ZZ également des opérateurs permettant de mesurer les corrélations d'intrication entre des paires de qubits.
SABRE est un algorithme polyvalent qui ne repose sur aucune hypothèse concernant la structure du circuit. Pour ce circuit GHZ à topologie en étoile, on connaît en effet un acheminement optimal : le StarPreRouting « pass » détecte les sous-circuits en étoile et les réorganise en une chaîne linéaire qui s'adapte directement à n'importe quel backend disposant d'un chemin linéaire suffisamment long. Ce tutoriel se concentre sur SABRE car cet outil fonctionne pour des circuits quelconques, mais si vous savez que StarPreRouting votre circuit présente une structure particulière bien définie, l'application d'une étape spécialisée avant le routage peut donner de meilleurs résultats que n'importe quelle recherche heuristique.
num_qubits_sim = 15
# Create star-topology GHZ circuit
qc_sim = QuantumCircuit(num_qubits_sim)
qc_sim.h(0)
for i in range(1, num_qubits_sim):
qc_sim.cx(0, i)
qc_sim.measure_all()
# ZZ operators: Z on qubit 0 and qubit i, identity elsewhere
operator_strings_sim = [
"Z" + "I" * i + "Z" + "I" * (num_qubits_sim - 2 - i)
for i in range(num_qubits_sim - 1)
]
operators_sim = [SparsePauliOp(op) for op in operator_strings_sim]Étape 2 : Optimiser le problème pour l'exécution sur du matériel quantique
SabreLayoutLe gestionnaire de passes prédéfini par défaut optimization_level=3 utilise déjà cette fonctionnalité, mais avec des paramètres par défaut prudents. Afin d'étudier l'impact d'un paramétrage plus strict, ce passage est remplacé par une configuration personnalisée SabreLayout permettant une recherche plus approfondie, tandis que tous les autres passages de la phase de mise en page restent inchangés. À titre de comparaison, un quatrième gestionnaire de passes conserve la valeur par défaut SabreLayout mais ajoute StarPreRouting à la phase d'initialisation. StarPreRouting Il s'agit d'une étape tenant compte de la structure qui détecte les sous-circuits en étoile et les réécrit sous forme de chaîne linéaire avant le routage.
Le déroulement des opérations est le suivant :
- Examinez le gestionnaire de passes par défaut pour voir où
SabreLayoutil se situe au sein de lalayoutphase. - Remplacez ce passage par une instance personnalisée
SabreLayoutà l'aide dePassManager.replace(index, passes=...), puis générez lapm_starvariante avecpm.init += StarPreRouting(). - Lancez les quatre gestionnaires de passes et comparez les indicateurs.
Les quatre configurations sont les suivantes :
Config | Description |
|---|---|
pm_1 (par défaut) | Préréglage par défaut « level-3 » (SabreLayout avec max_iterations=4, layout_trials=20, swap_trials=20) |
pm_2 | Personnalisé SabreLayout (max_iterations=4, layout_trials=200, swap_trials=200) |
pm_3 | Personnalisé SabreLayout (max_iterations=8, layout_trials=200, swap_trials=200) |
pm_star | Préréglage par défaut avec StarPreRouting ajouté à la phase d'initialisation |
Paramètres clés de SABRE :
layout_trials/swap_trials: Permet de contrôler le nombre de mises en page et de solutions de routage que SABRE examine. En augmentant le nombre d'essais, SABRE explore un espace de recherche plus vaste, ce qui augmente les chances de trouver une meilleure solution.max_iterations: Détermine le nombre de cycles d'affinement de routage avant-arrière que SABRE effectue sur chaque candidat. SABRE améliore la disposition de manière itérative en tirant les leçons des retours d'expérience sur le routage; ainsi, plus il y a d'itérations, plus les améliorations sont importantes.
Ces deux approches entraînent un temps de transpilation plus long, mais les circuits obtenus sont plus courts et utilisent moins de portes, ce qui réduit directement la décohérence et les erreurs de porte sur le matériel réel.
Étape n° 2a: z le gestionnaire de mots de passe par défaut. A StagedPassManager est constitué d'étapes (init, layout, routing, translation, optimization, scheduling), chacune étant elle-même un PassManager. L'appel .draw() d'une fonction sur une scène représente ses passes sous forme de graphe, ce qui nous permet de voir où SabreLayout se trouve.
# Build the default pass manager (no modifications yet)
pm_1 = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=seed
)
# Visualize the layout stage to see where SabreLayout sits
pm_1.layout.draw()Output:
Dans le schéma ci-dessus, le SabreLayout « pass » que nous souhaitons personnaliser se trouve à la ConditionalController position [2] de l'étape de mise en page. Ce contrôleur remplit deux fonctions :
- Il fonctionne
SabreLayoutselon un mécanisme de déclenchement, de sorte qu’il ne s’exécute que lorsqueVF2Layoutla recherche d’une correspondance parfaite [a] échoué (sinon, la disposition parfaite de « VF2 » est conservée). - Elle est
SabreLayoutprécédée d’uneBarrierBeforeFinalMeasurementsétape qui empêche les mesures d’être réorganisées lors du routage interne d’ SabreLayout's.
Si nous nous contentons de replace(index=2, passes=sl_2), ces deux comportements sont abandonnés. Pour les conserver, nous réemballons nos produits sur mesure SabreLayout dans le même ConditionalController emballage (dans les mêmes conditions et avec la même protection) avant de les remplacer.
Étape n° 2b: : Créez des passes personnalisées SabreLayout et remplacez celles par défaut.
cmap = backend.coupling_map
# Custom SabreLayout passes with more aggressive search
sl_2 = SabreLayout(
coupling_map=cmap,
seed=seed,
max_iterations=4,
layout_trials=200,
swap_trials=200,
)
sl_3 = SabreLayout(
coupling_map=cmap,
seed=seed,
max_iterations=8,
layout_trials=200,
swap_trials=200,
)
# Same condition the preset uses: only run SabreLayout when VF2Layout did not
# find a perfect mapping. This preserves any perfect layout VF2 produced at [1].
def _vf2_match_not_found(property_set):
if property_set["layout"] is None:
return True
return (
property_set["VF2Layout_stop_reason"] is not None
and property_set["VF2Layout_stop_reason"]
is not VF2LayoutStopReason.SOLUTION_FOUND
)
def wrap_sabre(sabre_pass):
"""Re-wrap a SabreLayout in the original ConditionalController + barrier."""
return ConditionalController(
[
BarrierBeforeFinalMeasurements(
"qiskit.transpiler.internal.routing.protection.barrier"
),
sabre_pass,
],
condition=_vf2_match_not_found,
)
# Build two fresh pass managers and swap in the wrapped custom SabreLayout at index 2
pm_2 = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=seed
)
pm_3 = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=seed
)
pm_2.layout.replace(index=2, passes=wrap_sabre(sl_2))
pm_3.layout.replace(index=2, passes=wrap_sabre(sl_3))
# Build pm_star: default preset with StarPreRouting added to the init stage
pm_star = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=seed
)
pm_star.init += StarPreRouting()
# Visualize pm_3 after replacement (pm_2 has the same structure, only max_iterations differs)
pm_3.layout.draw()Output:
La position [2] est à nouveau un ConditionalController — de forme identique à celle par défaut, mais le intérieur SabreLayout est celui que nous avons défini (avec layout_trials=200, swap_trials=200, et max_iterations=8 pour pm_3; pm_2 est identique à l'exception de max_iterations=4). La barrière de protection et le _vf2_match_not_found système de commande sont conservés; la seule différence entre pm_2/pm_3 et pm_1 réside donc dans la configuration SABRE elle-même. pm_star conserve la valeur par défaut SabreLayout et ajoute StarPreRouting simplement à la fin de la phase d'initialisation.
Étape n° 2c: : Lancez chaque gestionnaire de passes et comparez les résultats.
results_sim = {}
for name, pm in [
("pm_1 (4,20,20)", pm_1),
("pm_2 (4,200,200)", pm_2),
("pm_3 (8,200,200)", pm_3),
("pm_star (default + StarPreRouting)", pm_star),
]:
t0 = time.time()
tqc = pm.run(qc_sim)
elapsed = time.time() - t0
depth = tqc.depth(lambda x: x.operation.num_qubits == 2)
size = tqc.size()
ops_mapped = [op.apply_layout(tqc.layout) for op in operators_sim]
results_sim[name] = {
"tqc": tqc,
"ops": ops_mapped,
"depth": depth,
"size": size,
"time": elapsed,
}
print(f"{name}: 2Q Depth {depth}, Size {size}, Time {elapsed:.2f}s")
# Print improvement relative to default (pm_1)
baseline = results_sim["pm_1 (4,20,20)"]
print("\nImprovement vs. default (pm_1):")
for name in [
"pm_2 (4,200,200)",
"pm_3 (8,200,200)",
"pm_star (default + StarPreRouting)",
]:
r = results_sim[name]
depth_pct = (baseline["depth"] - r["depth"]) / baseline["depth"] * 100
size_pct = (baseline["size"] - r["size"]) / baseline["size"] * 100
print(f" {name}: 2Q depth {depth_pct:+.1f}%, size {size_pct:+.1f}%")Output:
pm_1 (4,20,20): 2Q Depth 38, Size 183, Time 0.01s
pm_2 (4,200,200): 2Q Depth 36, Size 183, Time 0.15s
pm_3 (8,200,200): 2Q Depth 30, Size 158, Time 0.16s
pm_star (default + StarPreRouting): 2Q Depth 26, Size 160, Time 0.01s
Improvement vs. default (pm_1):
pm_2 (4,200,200): 2Q depth +5.3%, size +0.0%
pm_3 (8,200,200): 2Q depth +21.1%, size +13.7%
pm_star (default + StarPreRouting): 2Q depth +31.6%, size +12.6%
Les trois gestionnaires de passes modifiés ont tous généré des circuits présentant une profondeur d' 2Q s inférieure à celle du gestionnaire par défaut. Les configurations SABRE agressives (pm_2 et pm_3) sacrifient un temps de transpilation plus long au profit d'une recherche plus large, tandis que pm_star tire parti de la structure en étoile du circuit et produit un résultat encore moins profond sans entraîner de coût de transpilation supplémentaire. Les gains exacts varient d'une exécution à l'autre, mais la tendance générale reste la même : un plus grand nombre d'essais et d'itérations SABRE permet à l'algorithme heuristique d'explorer un espace plus vaste, tandis que les passes tenant compte de la structure, comme StarPreRouting , peuvent contourner entièrement cette recherche lorsque la forme du circuit correspond.
Même à cette petite échelle (15 qubits), la marge d'amélioration est suffisante pour que les trois approches surpassent l'approche par défaut. Avec des circuits plus grands (plus de 100 qubits), l'espace de recherche s'étend considérablement et les avantages liés à la fois à l'augmentation du nombre d'essais et aux passages tenant compte de la structure deviennent beaucoup plus marqués, comme le montrera la section consacrée aux circuits à grande échelle.
pm_names = list(results_sim.keys())
depths = [results_sim[n]["depth"] for n in pm_names]
sizes = [results_sim[n]["size"] for n in pm_names]
times = [results_sim[n]["time"] for n in pm_names]
colors = ["#404080", "#2a9d8f", "#a8d05e", "#e29bdd"]
x = np.arange(len(pm_names))
fig, axs = plt.subplots(1, 3, figsize=(14, 5))
# 2Q Depth
bars = axs[0].bar(x, depths, color=colors)
axs[0].set_ylabel("2Q Depth", fontsize=11)
axs[0].set_title("Two-Qubit Gate Depth", fontsize=13)
axs[0].set_ylim(0, max(depths) * 1.2)
for bar, val in zip(bars, depths):
axs[0].text(
bar.get_x() + bar.get_width() / 2,
bar.get_height() + max(depths) * 0.02,
str(val),
ha="center",
va="bottom",
fontsize=11,
fontweight="bold",
)
for i in range(1, len(depths)):
pct = (depths[0] - depths[i]) / depths[0] * 100
if pct != 0:
axs[0].text(
bars[i].get_x() + bars[i].get_width() / 2,
bars[i].get_height() / 2,
f"{pct:+.0f}%",
ha="center",
va="center",
fontsize=10,
color="white",
fontweight="bold",
)
# Size
bars = axs[1].bar(x, sizes, color=colors)
axs[1].set_ylabel("Gate Count", fontsize=11)
axs[1].set_title("Circuit Size", fontsize=13)
axs[1].set_ylim(0, max(sizes) * 1.2)
for bar, val in zip(bars, sizes):
axs[1].text(
bar.get_x() + bar.get_width() / 2,
bar.get_height() + max(sizes) * 0.02,
str(val),
ha="center",
va="bottom",
fontsize=11,
fontweight="bold",
)
for i in range(1, len(sizes)):
pct = (sizes[0] - sizes[i]) / sizes[0] * 100
if abs(pct) > 0.1:
axs[1].text(
bars[i].get_x() + bars[i].get_width() / 2,
bars[i].get_height() / 2,
f"{pct:+.0f}%",
ha="center",
va="center",
fontsize=10,
color="white",
fontweight="bold",
)
# Time
bars = axs[2].bar(x, times, color=colors)
axs[2].set_ylabel("Time (s)", fontsize=11)
axs[2].set_title("Transpilation Time", fontsize=13)
axs[2].set_ylim(0, max(times) * 1.3)
for bar, val in zip(bars, times):
axs[2].text(
bar.get_x() + bar.get_width() / 2,
bar.get_height() + max(times) * 0.03,
f"{val:.2f}s",
ha="center",
va="bottom",
fontsize=11,
fontweight="bold",
)
for ax in axs:
ax.set_xticks(x)
ax.set_xticklabels(pm_names, fontsize=8, rotation=15)
ax.grid(axis="y", linestyle="--", alpha=0.5)
plt.suptitle(
"Transpilation quality vs. configuration",
fontsize=14,
fontweight="bold",
y=1.02,
)
plt.tight_layout()
plt.show()Output:
Étape 3 : Exécutez à l'aide d' Qiskit primitives
Nous exécutons chaque circuit transpilé 10 fois à l'aide d'Aer EstimatorV2 , avec un modèle de bruit dérivé du backend réel. Étant donné que les résultats de simulation, sujets à des variations aléatoires, diffèrent d'une exécution à l'autre, le calcul de la moyenne sur plusieurs exécutions permet d'obtenir des estimations de fidélité plus fiables et de quantifier l'incertitude statistique à l'aide de barres d'erreur.
# Create a noisy estimator from the real backend's noise model
noisy_estimator = AerEstimator.from_backend(backend)
num_runs = 10
# sim_all_runs[name] = list of arrays, one per run
sim_all_runs = {name: [] for name in results_sim}
for run in range(num_runs):
for name, r in results_sim.items():
job = noisy_estimator.run([(r["tqc"], r["ops"])])
evs = list(job.result()[0].data.evs)
sim_all_runs[name].append(evs)
print(f"Run {run + 1}/{num_runs} done")
# Compute mean and std across runs for each config
sim_stats = {}
for name in results_sim:
all_evs = np.array(sim_all_runs[name]) # shape (num_runs, num_operators)
sim_stats[name] = {
"mean": np.mean(all_evs, axis=0),
"std": np.std(all_evs, axis=0),
"overall_mean": np.mean(all_evs),
"overall_std": np.std(
np.mean(all_evs, axis=1)
), # std of per-run averages
}
print(
f"{name}: mean fidelity = {sim_stats[name]['overall_mean']:.4f} +/- {sim_stats[name]['overall_std']:.4f}"
)Output:
Run 1/10 done
Run 2/10 done
Run 3/10 done
Run 4/10 done
Run 5/10 done
Run 6/10 done
Run 7/10 done
Run 8/10 done
Run 9/10 done
Run 10/10 done
pm_1 (4,20,20): mean fidelity = 0.9510 +/- 0.0094
pm_2 (4,200,200): mean fidelity = 0.9513 +/- 0.0043
pm_3 (8,200,200): mean fidelity = 0.9540 +/- 0.0065
pm_star (default + StarPreRouting): mean fidelity = 0.9547 +/- 0.0072
Comme il s'agit d'un petit circuit, les valeurs de fidélité sont relativement proches dans les quatre configurations. Les circuits sont suffisamment courts pour que le bruit matériel n'ait pas d'impact significatif, même sur la version la moins optimisée. La fidélité moyenne suit globalement la profondeur d’ 2Q : pm_3 et pm_star, les deux circuits les moins profonds, atteignent les fidélités les plus élevées et se situent pratiquement à égalité, compte tenu de leurs marges d’erreur. pm_2 constitue un contre-exemple intéressant : bien que sa profondeur d' 2Q e soit inférieure à pm_1celle de, sa fidélité moyenne s'avère également légèrement inférieure, ce qui nous rappelle que le lien entre profondeur et fidélité est de nature statistique plutôt que déterministe. Le choix des qubits spécifiques dans une configuration et leur étalonnage au moment de l'exécution ont également leur importance.
Étape 4 : Post-traitement et restitution du résultat dans le format classique souhaité
Tracez ensuite les corrélations d'intrication en fonction de la distance entre les qubits, ainsi que la corrélation moyenne en tant qu'indicateur unique de fidélité. Dans un cas idéal (sans bruit), toutes les corrélations seraient égales à 1. Compte tenu des bruits réels, chaque porte supplémentaire introduit une erreur et chaque pas de temps supplémentaire favorise la décohérence; ainsi, un circuit transpilé présentant une profondeur moindre et un nombre réduit de portes (en particulier de portes à deux qubits) devrait mieux préserver l'intrication.
data_sim = list(range(1, len(operators_sim) + 1))
markers = ["o", "s", "^", "*"]
colors_line = ["#404080", "#2a9d8f", "#a8d05e", "#e29bdd"]
fig, (ax1, ax2) = plt.subplots(
1, 2, figsize=(14, 5), gridspec_kw={"width_ratios": [2.5, 1]}
)
# Left: correlations vs distance with error bars (mean +/- 1 std)
for (name, stats), marker, color in zip(
sim_stats.items(), markers, colors_line
):
ax1.errorbar(
data_sim,
stats["mean"],
yerr=stats["std"],
marker=marker,
label=name,
color=color,
linewidth=2,
capsize=3,
capthick=1,
elinewidth=1,
)
ax1.set_xlabel("Distance between qubits $i$", fontsize=11)
ax1.set_ylabel(r"$\langle Z_0 Z_i \rangle$", fontsize=11)
ax1.set_title(
"Entanglement correlations vs. qubit distance (avg. of 10 runs)",
fontsize=12,
)
ax1.legend(fontsize=9)
ax1.grid(alpha=0.3)
# Right: mean correlation bar chart with error bars
names = list(sim_stats.keys())
means = [sim_stats[n]["overall_mean"] for n in names]
stds = [sim_stats[n]["overall_std"] for n in names]
x_bar = np.arange(len(names))
bars = ax2.bar(
x_bar, means, yerr=stds, color=colors_line, capsize=5, ecolor="gray"
)
ax2.set_ylabel(r"Mean $\langle Z_0 Z_i \rangle$", fontsize=11)
ax2.set_title("Average fidelity", fontsize=13, pad=12)
y_range = max(means) - min(means) if max(means) != min(means) else 0.01
# Top of ylim accounts for the bar height + std error bar + headroom for the value label
y_top = max(m + s for m, s in zip(means, stds)) + y_range * 1.5
ax2.set_ylim(min(means) - y_range * 0.8, y_top)
for bar, val, std in zip(bars, means, stds):
ax2.text(
bar.get_x() + bar.get_width() / 2,
bar.get_height() + std + y_range * 0.15,
f"{val:.4f}",
ha="center",
va="bottom",
fontsize=10,
fontweight="bold",
)
# Annotate % change vs pm_1
baseline_mean = means[0]
for i in range(1, len(means)):
pct = (means[i] - baseline_mean) / baseline_mean * 100
if abs(pct) > 0.01:
mid_y = (means[i] + ax2.get_ylim()[0]) / 2
ax2.text(
bars[i].get_x() + bars[i].get_width() / 2,
mid_y,
f"{pct:+.1f}%",
ha="center",
va="center",
fontsize=10,
color="white",
fontweight="bold",
)
ax2.set_xticks(x_bar)
ax2.set_xticklabels(names, fontsize=8, rotation=15)
ax2.grid(axis="y", linestyle="--", alpha=0.5)
fig.tight_layout()
plt.show()Output:
Les résultats montrent un lien évident entre la qualité de la transpilation et la fidélité de l'exécution, avec quelques précisions utiles :
pm_1(par défaut) : Référence. Avec seulement 20 essais et quatre itérations, SABRE dispose d'une marge d'optimisation limitée, ce qui se traduit par le circuit le plus profond parmi ceux générés uniquement par SABRE.pm_2(autres essais) : L'exploration d'un nombre de candidats dix fois plus important permet d'obtenir une structure légèrement moins profonde, mais la fidélité moyenne reste globalement stable (et peut même descendre en dessous de la valeur de référence en raison du bruit), car le gain en profondeur est faible à cette échelle.pm_3(plus d'essais + plus d'itérations) : En doublantmax_iterationsce nombre pour le porter à 8, SABRE bénéficie de cycles de raffinement supplémentaires, ce qui permet d'obtenir le circuit le moins profond réalisé uniquement avec SABRE et la fidélité moyenne la plus élevée de la comparaison.pm_star(par défaut + StarPreRouting ) : AjouteStarPreRoutingà la phase d'initialisation d'un préréglage qui, sans cela, serait celui par défaut. La réécriture tenant compte de la structure réduit la structure en étoile à une chaîne linéaire que le reste du transpileur mappe sur le chemin linéaire du dispositif, produisant ainsi le circuit globalement le moins profond (légèrement meilleur quepm_3) et offrantpm_3une fidélité équivalente à celle de dans les limites des marges d'erreur. Cela ne modifie pas le temps de transpilation par rapport à la valeur par défaut, car la réécriture ne nécessite pratiquement aucun temps d'exécution par rapport à la recherche stochastique de SABRE.
Il convient de noter que l'augmentation de max_iterations n'a pas toujours un impact positif. Dans ce cas précis, cela a été très utile, mais pour d’autres circuits ou backends, les itérations supplémentaires pourraient ne pas apporter d’amélioration supplémentaire, voire nuire légèrement aux performances en raison d’une optimisation excessive d’un minimum local. En règle générale, vous devriez augmenter layout_trials et swap_trials autant que votre budget-temps le permet, car multiplier les essais augmente toujours les chances de trouver une meilleure disposition. Il vaut la peine de tester cette augmentation max_iterations , mais elle doit être validée en fonction de votre cas d'utilisation spécifique. Les passes spécialisées telles que StarPreRouting sont similaires dans leur principe, mais dépendent davantage du circuit : elles ne sont utiles que lorsque le circuit contient effectivement la structure qu'elles ciblent. Le gain est important lorsque cela s'applique, et nul dans le cas contraire, mais cela ne coûte pratiquement rien d'essayer.
Exemple de matériel à grande échelle
Outre l'ajustement du nombre d'essais, SABRE permet de personnaliser l 'algorithme de routage. SABRE propose trois méthodes heuristiques :
basic: Une approche gloutonne simple qui sélectionne l'échange minimisant la distance immédiate jusqu'à la porte suivante.decay(par défaut) : attribue dynamiquement des poids aux qubits en fonction de leur activité récente, ce qui décourage les échanges répétés sur les mêmes qubits.lookahead: Évalue les coûts de routage futurs en anticipant les prochaines portes, ce qui permet éventuellement de trouver de meilleures séquences d'échange.
Pour utiliser une heuristique personnalisée, créez un SabreSwap « pass » et associez-le à SabreLayout via le routing_pass paramètre.
SabreLayoutUn quatrième gestionnaire de passes est ajouté à la comparaison : pm_star_hw, qui conserve les paramètres parSabreSwap défaut mais ajoute StarPreRouting à la phase d'initialisation. À cette échelle (100 qubits), la recherche SABRE s'avère plus complexe, et la conversion d'une structure en étoile en une chaîne linéaire s'avère clairement avantageuse, car un processeur Heron dispose de chemins linéaires suffisamment longs pour accueillir le circuit obtenu.
Nous comparons ici les trois heuristiques SABRE, ainsi StarPreRouting que leur application à grande échelle sur un circuit GHZ de 100 qubits. Nous effectuons plusieurs essais de disposition avec différentes graines pour les configurations SABRE, sélectionnons le meilleur circuit transpilé de chacun d'entre eux, puis les soumettons tous à un test sur du matériel réel, ainsi que StarPreRouting le résultat.
Étapes 1 à 4 regroupées en un seul bloc de code
C'est ici que l'ensemble du processus est mis en œuvre à plus grande échelle. Lorsque l'on utilise SabreSwap comme pour routing_pass SabreLayout, un seul essai de disposition est effectué par appel; c'est pourquoi la cellule de code suivante effectue une boucle sur les graines afin d'explorer l'espace de disposition.
Nous utilisons la même wrap_sabre fonction auxiliaire que celle définie dans l’étape 2 à petite échelle (ci-dessus), et ajoutons une fonction auxiliaire analogue wrap_routing , car l’étape routing à l’indice [1] est également un ConditionalController([BarrierBeforeFinalMeasurements, routing_pass], ...) —; la remplacer telle quelle supprimerait de la même manière la barrière protectrice et la _swap_condition synchronisation.
# -------------------------Step 1-------------------------
num_qubits = 100
# Create star-topology GHZ circuit
qc = QuantumCircuit(num_qubits)
qc.h(0)
for i in range(1, num_qubits):
qc.cx(0, i)
qc.measure_all()
# ZZ operators
operator_strings = [
"Z" + "I" * i + "Z" + "I" * (num_qubits - 2 - i)
for i in range(num_qubits - 1)
]
operators = [SparsePauliOp(op) for op in operator_strings]# -------------------------Step 2-------------------------
num_seeds = 10
seed_list = [seed + i for i in range(num_seeds)]
swap_trials = 200
# The default routing[1] is a ConditionalController([barrier, routing_pass],
# condition=_swap_condition); we re-wrap so the new routing pass keeps the
# protective barrier and is skipped when routing isn't needed (matches the preset).
def _swap_condition(property_set):
return not property_set["routing_not_needed"]
def wrap_routing(routing_pass):
return ConditionalController(
[
BarrierBeforeFinalMeasurements(
"qiskit.transpiler.internal.routing.protection.barrier"
),
routing_pass,
],
condition=_swap_condition,
)
heuristic_results = {}
# Three SABRE heuristics, swept over seeds
for heuristic in ["basic", "decay", "lookahead"]:
trials = []
for s in seed_list:
sr = SabreSwap(
coupling_map=cmap, heuristic=heuristic, trials=swap_trials, seed=s
)
sl = SabreLayout(coupling_map=cmap, routing_pass=sr, seed=s)
pm = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=s
)
# Re-wrap each custom pass in its original ConditionalController + barrier
# (wrap_sabre is defined in the small-scale Step 2 cell above).
pm.layout.replace(index=2, passes=wrap_sabre(sl))
pm.routing.replace(index=1, passes=wrap_routing(sr))
t0 = time.time()
tqc = pm.run(qc)
elapsed = time.time() - t0
depth = tqc.depth(lambda x: x.operation.num_qubits == 2)
size = tqc.size()
trials.append(
{
"tqc": tqc,
"depth": depth,
"size": size,
"time": elapsed,
"seed": s,
}
)
heuristic_results[heuristic] = trials
# Default preset + StarPreRouting in init, also swept over seeds for a fair comparison
star_trials = []
for s in seed_list:
pm_star_hw = generate_preset_pass_manager(
optimization_level=3, backend=backend, seed_transpiler=s
)
pm_star_hw.init += StarPreRouting()
t0 = time.time()
tqc = pm_star_hw.run(qc)
elapsed = time.time() - t0
depth = tqc.depth(lambda x: x.operation.num_qubits == 2)
size = tqc.size()
star_trials.append(
{
"tqc": tqc,
"depth": depth,
"size": size,
"time": elapsed,
"seed": s,
}
)
heuristic_results["StarPreRouting"] = star_trials
# Print summary for each entry
for label in ["basic", "decay", "lookahead", "StarPreRouting"]:
trials = heuristic_results[label]
depths = [t["depth"] for t in trials]
sizes = [t["size"] for t in trials]
best = min(trials, key=lambda t: t["depth"])
print(f"{label}:")
print(
f" 2Q depth: min: {min(depths)}, mean: {np.mean(depths):.1f}, std: {np.std(depths):.1f}"
)
print(
f" size : min: {min(sizes)}, mean: {np.mean(sizes):.1f}, std: {np.std(sizes):.1f}"
)
print(
f" best seed: {best['seed']} (2Q depth={best['depth']}, size={best['size']})"
)Output:
basic:
2Q depth: min: 524, mean: 570.5, std: 39.9
size : min: 3819, mean: 4227.1, std: 360.6
best seed: 51 (2Q depth=524, size=3852)
decay:
2Q depth: min: 387, mean: 436.4, std: 41.7
size : min: 2687, mean: 3183.1, std: 459.3
best seed: 45 (2Q depth=387, size=2786)
lookahead:
2Q depth: min: 364, mean: 424.6, std: 36.5
size : min: 2335, mean: 3014.6, std: 388.1
best seed: 51 (2Q depth=364, size=2485)
StarPreRouting:
2Q depth: min: 196, mean: 196.0, std: 0.0
size : min: 1151, mean: 1151.0, std: 0.0
best seed: 42 (2Q depth=196, size=1151)
hw_colors = {
"basic": "#ff7f0e",
"decay": "#d62728",
"lookahead": "#1f77b4",
"StarPreRouting": "#2a9d8f",
}
fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(13, 5))
for label in ["basic", "decay", "lookahead", "StarPreRouting"]:
trials = heuristic_results[label]
depths = [t["depth"] for t in trials]
sizes = [t["size"] for t in trials]
seeds = [t["seed"] for t in trials]
color = hw_colors[label]
ax1.scatter(
seeds,
depths,
label=label,
color=color,
alpha=0.8,
edgecolor="k",
s=60,
)
ax1.axhline(np.mean(depths), color=color, linestyle="--", alpha=0.5)
ax2.scatter(
seeds,
sizes,
label=label,
color=color,
alpha=0.8,
edgecolor="k",
s=60,
)
ax2.axhline(np.mean(sizes), color=color, linestyle="--", alpha=0.5)
ax1.set_xlabel("Seed", fontsize=11)
ax1.set_ylabel("2Q Depth", fontsize=11)
ax1.set_title("Two-Qubit Gate Depth per Seed", fontsize=13)
ax1.legend(fontsize=10)
ax1.grid(alpha=0.3)
ax2.set_xlabel("Seed", fontsize=11)
ax2.set_ylabel("Gate Count", fontsize=11)
ax2.set_title("Circuit Size per Seed", fontsize=13)
ax2.legend(fontsize=10)
ax2.grid(alpha=0.3)
plt.suptitle(
"Transpilation variability across seeds: SABRE heuristics vs. StarPreRouting",
fontsize=14,
fontweight="bold",
y=1.02,
)
plt.tight_layout()
plt.show()
# Summary comparison
for label in ["basic", "decay", "lookahead", "StarPreRouting"]:
best = min(heuristic_results[label], key=lambda t: t["depth"])
print(
f"{label}: best 2Q depth={best['depth']}, size={best['size']} (seed={best['seed']})"
)Output:
basic: best 2Q depth=524, size=3852 (seed=51)
decay: best 2Q depth=387, size=2786 (seed=45)
lookahead: best 2Q depth=364, size=2485 (seed=51)
StarPreRouting: best 2Q depth=196, size=1151 (seed=42)
# -------------------------Step 3: Execute on hardware-------------------------
best_circuits = {}
for label in ["basic", "decay", "lookahead", "StarPreRouting"]:
best_circuits[label] = min(
heuristic_results[label], key=lambda t: t["depth"]
)
b = best_circuits[label]
print(f"Best {label}: 2Q depth={b['depth']}, size={b['size']}")
options = EstimatorOptions()
options.resilience_level = 2
options.dynamical_decoupling.enable = True
options.dynamical_decoupling.sequence_type = "XY4"
estimator = Estimator(backend, options=options)
hw_jobs = {}
hw_ops = {}
for label, best in best_circuits.items():
hw_ops[label] = [op.apply_layout(best["tqc"].layout) for op in operators]
hw_jobs[label] = estimator.run([(best["tqc"], hw_ops[label])])
print(f"{label} job: {hw_jobs[label].job_id()}")
estimator.options.environment.job_tags = ["TUT_TOWS"]
hw_results = {}
for label, job in hw_jobs.items():
hw_results[label] = job.result()[0]
print(f"{label} job done")Output:
Best basic: 2Q depth=524, size=3852
Best decay: 2Q depth=387, size=2786
Best lookahead: 2Q depth=364, size=2485
Best StarPreRouting: 2Q depth=196, size=1151
basic job: d81q5tnoha1c73bknprg
decay job: d81q5tugbeec73aktopg
lookahead job: d81q5to0bvlc73d1epe0
StarPreRouting job: d81q5u7tjchs73bn82hg
basic job done
decay job done
lookahead job done
StarPreRouting job done
# -------------------------Step 4: Post-process-------------------------
data = list(range(1, len(operators) + 1))
hw_markers = {
"basic": "D",
"decay": "o",
"lookahead": "s",
"StarPreRouting": "*",
}
hw_labels = ["basic", "decay", "lookahead", "StarPreRouting"]
fig, (ax1, ax2) = plt.subplots(
1, 2, figsize=(14, 5), gridspec_kw={"width_ratios": [2.5, 1]}
)
# Left: correlations vs distance
for label in hw_labels:
evs = list(hw_results[label].data.evs)
b = best_circuits[label]
ax1.plot(
data,
evs,
marker=hw_markers[label],
color=hw_colors[label],
linewidth=2,
label=f"{label} (2Q depth={b['depth']}, size={b['size']})",
markersize=5 if label == "StarPreRouting" else 4,
)
ax1.set_xlabel("Distance between qubits $i$", fontsize=11)
ax1.set_ylabel(r"$\langle Z_0 Z_i \rangle$", fontsize=11)
ax1.set_title(
"Entanglement correlations vs. qubit distance (hardware)", fontsize=12
)
ax1.legend(fontsize=9)
ax1.grid(alpha=0.3)
# Right: mean fidelity bar chart
hw_means = [np.mean(list(hw_results[label].data.evs)) for label in hw_labels]
hw_bar_colors = [hw_colors[label] for label in hw_labels]
x_bar = np.arange(len(hw_labels))
bars = ax2.bar(x_bar, hw_means, color=hw_bar_colors)
ax2.set_ylabel(r"Mean $\langle Z_0 Z_i \rangle$", fontsize=11)
ax2.set_title("Average fidelity", fontsize=13)
y_range = (
max(hw_means) - min(hw_means) if max(hw_means) != min(hw_means) else 0.01
)
ax2.set_ylim(min(hw_means) - y_range * 0.2, max(hw_means) + y_range * 0.15)
for bar, val in zip(bars, hw_means):
ax2.text(
bar.get_x() + bar.get_width() / 2,
bar.get_height() + y_range * 0.05,
f"{val:.4f}",
ha="center",
va="bottom",
fontsize=11,
fontweight="bold",
)
ax2.set_xticks(x_bar)
ax2.set_xticklabels(hw_labels, fontsize=9, rotation=15)
ax2.grid(axis="y", linestyle="--", alpha=0.5)
fig.tight_layout()
plt.show()
print("\nMean fidelity:")
for label, m in zip(hw_labels, hw_means):
print(f" {label}: {m:.4f}")Output:
Mean fidelity:
basic: 0.0344
decay: 0.1298
lookahead: 0.1857
StarPreRouting: 0.3295
Analyse
Les nuages de points montrent une variabilité importante entre les différentes graines pour les trois heuristiques SABRE, ce qui souligne l'importance de réaliser plusieurs essais de disposition plutôt que de se fier à une seule transpilation. La StarPreRouting courbe reste pratiquement plate pour toutes les graines, car la transformation d'une structure en étoile en une chaîne linéaire est déterministe compte tenu de la structure; le routage SABRE en aval ne dispose alors que d'une très faible marge de manœuvre sur une chaîne linéaire, de sorte que la graine n'a pratiquement aucun effet sur la profondeur ou la taille finales.
D'après les résultats de la transpilation, les decay heuristiques et lookahead surpassent basic systématiquement avec une large marge. Cette basic heuristique, bien que rapide, utilise une stratégie gloutonne simple qui conduit souvent à des circuits nettement plus profonds. Pour ce circuit GHZ à topologie en étoile, lookahead tend à produire la profondeur d’ 2Q et le nombre de portes les plus faibles parmi les heuristiques SABRE, car sa fonction de coût prospective est bien adaptée aux circuits présentant des schémas de connectivité à longue portée. StarPreRouting, Cependant, cette méthode surpasse largement les trois autres : en réécrivant l'étoile sous la forme d'une chaîne linéaire avant le routage, elle contourne complètement le problème de recherche et fournit un circuit que le reste du transpileur peut mapper sur un chemin linéaire avec un nombre minimal d'opérations SWAP supplémentaires.
Cet avantage se répercute directement sur la fidélité matérielle. Une profondeur d’ 2Q s et un nombre de portes plus faibles ne se traduisent pas toujours directement par une fidélité plus élevée (les qubits physiques spécifiques utilisés par une configuration et leur étalonnage lors de l’exécution ont également leur importance), mais lorsque l’écart de profondeur est aussi important que celui qui sépare SABRE et StarPreRouting [ici], l’approche tenant compte de la structure l’emporte haut la main, car le circuit accumule bien moins de décohérence et bien moins d’événements d’erreur à deux qubits. Le diagramme à barres de fidélité montre StarPreRouting que devance largement même la meilleure heuristique SABRE, tandis que basic se situe bien en dessous des autres, car ses circuits, beaucoup plus complexes, sont à l'origine de la plupart des erreurs.
Principaux intérêts :
- Parmi les algorithmes heuristiques SABRE,
decayetlookaheadsont nettement plus performants quebasicpour les circuits non triviaux. Pour les charges de travail de production, privilégiez l'une des deux options. - Le meilleur algorithme heuristique SABRE dépend de votre circuit et de votre matériel. Tester plusieurs heuristiques avec plusieurs graines constitue la stratégie la plus fiable.
- Si vous souhaitez explorer encore davantage de configurations, augmentez
swap_trials(etlayout_trialslorsque vous n'effectuez pas de passage de routage personnalisé) plutôt que de répartir la charge de travail vers des nœuds distants. Les passes SABRE parallélisent déjà les essais entre les threads locaux, et la charge de travail par essai est suffisamment faible pour que la surcharge liée à la distribution l'emporte généralement sur tout gain de vitesse. - Lorsque le circuit présente une structure particulière connue, l'application d'une passe tenant compte de la structure, comme celle
StarPreRoutingeffectuée avant SABRE, peut permettre d'obtenir une amélioration d'un ordre de grandeur qu'aucun réglage de SABRE ne pourra égaler. Cela ne remplace pas SABRE :StarPreRoutingcela n'est utile que lorsque le circuit comporte effectivement des sous-circuits en étoile et que le backend dispose d'un chemin linéaire suffisamment long. Lorsque vous connaissez la forme de votre circuit, il est utile de vérifier s'il existe des correspondances dans la bibliothèque de passes.
Etapes suivantes
Si ce travail vous a paru intéressant, les documents suivants pourraient vous intéresser :
SabreLayoutRéférence API : documentation complète sur les paramètres- Article sur SABRE : l'algorithme SABRE original pour la disposition et le routage
- LightSABRE article : les améliorations algorithmiques qui sous-tendent l'implémentation actuelle de SABRE par Qiskit
- Écrivez une étape de transpilation personnalisée : créez votre propre logique de transpilation
- Plug-ins de transpilation : étendre le pipeline de transpilation de Qiskit avec des passes tierces
- Représentation DAG : comprendre le graphe acyclique orienté utilisé en interne par le transpileur
Enquête tutorielle
Veuillez répondre à cette courte enquête pour nous faire part de vos commentaires sur ce didacticiel. Vos commentaires nous aideront à améliorer nos offres de contenu et l'expérience des utilisateurs.