# introduccion-a-la-computacion-cuantica-con-qiskit
Introducción a la computación cuántica con Qiskit
Volver a la portada del cursoEjecución en Hardware Real
Sección 5 · Simulación y Ejecución en Qiskit
Ejecución en hardware real
Ejecutar un circuito en un procesador cuántico real es el paso que convierte la teoría en experimento. IBM Quantum Platform ofrece acceso gratuito a procesadores de más de cien qubits mediante su plan abierto (Open Plan). En esta lección conoces el flujo completo y lo practicas en el notebook con un backend falso, para que funcione aunque todavía no tengas cuenta.
El flujo en cuatro pasos
- Conectarse: crear el servicio con
QiskitRuntimeService, usando la cuenta guardada. - Elegir un procesador: por ejemplo, el menos ocupado con
least_busy. - Transpilar al procesador: convertir el circuito a las puertas nativas y a la conectividad del equipo. El resultado se llama circuito ISA (Instruction Set Architecture).
- Ejecutar con una primitiva: enviar el circuito con
Samplery esperar el resultado del trabajo (job).
En código, con una cuenta configurada, el flujo se ve así:
from qiskit import QuantumCircuit
from qiskit.transpiler import generate_preset_pass_manager
from qiskit_ibm_runtime import QiskitRuntimeService
from qiskit_ibm_runtime.executor_sampler import Sampler
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()
# service = QiskitRuntimeService()
# backend = service.least_busy(operational=True, simulator=False)
# isa = generate_preset_pass_manager(optimization_level=1, backend=backend).run(qc)
# job = Sampler(mode=backend).run([isa], shots=1000)
# print(job.job_id())
# print(job.result()[0].data.meas.get_counts())
El trabajo entra en una cola. Puede tardar segundos o varios minutos según la demanda. Guarda el identificador del trabajo: con él puedes recuperar el resultado más tarde con service.job(id).
Practicar sin cuenta: backends falsos
Los backends falsos (FakeManilaV2, FakeBrisbane y otros) guardan la conectividad, las puertas nativas y las tasas de error de procesadores reales. Si pasas un backend falso como mode, el Sampler ejecuta localmente con ese ruido. El mismo código sirve después para el procesador real cambiando una sola línea:
from qiskit import QuantumCircuit
from qiskit.transpiler import generate_preset_pass_manager
from qiskit_ibm_runtime.fake_provider import FakeManilaV2
from qiskit_ibm_runtime.executor_sampler import Sampler
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()
backend = FakeManilaV2()
isa = generate_preset_pass_manager(optimization_level=1, backend=backend, seed_transpiler=1).run(qc)
print("Puertas tras transpilar:", dict(isa.count_ops()))
print(Sampler(mode=backend).run([isa], shots=1000).result()[0].data.meas.get_counts())
El circuito transpilado usa puertas como rz, sx y cx, que son las que el procesador sabe ejecutar. En los conteos aparecen unos pocos 01 y 10: son errores, no parte del estado de Bell.
Qué cambia respecto al simulador
- Puertas nativas: la Hadamard no existe como tal; se construye con rotaciones.
- Conectividad: no todos los qubits están conectados. Si el circuito pide una
cxentre qubits lejanos, el transpilador agrega intercambios (swap), que suman error. - Ruido: cada puerta y cada medición fallan con cierta probabilidad, y los qubits pierden coherencia con el tiempo.
- Tiempo de cómputo: el plan abierto limita el tiempo mensual de procesador, así que conviene probar todo antes en simulador.
Qué verás en el notebook
- El flujo completo con un backend falso: transpilar, ejecutar y leer resultados.
- Cómo cambian profundidad y número de puertas con cada nivel de optimización.
- Una comparación ideal contra ruidoso y la fidelidad del estado de Bell.
- Las líneas exactas que cambian para usar un procesador real.
Trampas comunes
- Enviar circuitos sin transpilar. Los procesadores de IBM rechazan circuitos que no sean ISA.
- Gastar tiempo real en depuración. Los errores de lógica se encuentran en simulador, no en hardware.
- Circuitos demasiado profundos. Más de unas decenas de capas de puertas de dos qubits suelen dar resultados dominados por el ruido.
- Esperar resultados perfectos. Un estado de Bell en hardware real suele mostrar algunos puntos porcentuales de resultados incorrectos.
Cierre
El hardware real es un recurso limitado: úsalo para confirmar lo que ya funcionó en simulación. Ejecuta el notebook con el backend falso y, cuando tengas tu cuenta, cambia el backend por service.least_busy(...) y compara tus conteos reales con los simulados.