IBM treibt Qiskit mit SDK-Release v2.6 weiter über Python hinaus
Qiskit SDK v2.6 von IBM ergänzt einen Pass-Manager für die C-API, native QPY-Serialisierung und benutzerdefinierte Operationen, während IBM Arbeitsabläufe vorantreibt, die Python optional machen.
Diese Seite wurde aus dem Englischen übersetzt. Unternehmens- und Produktnamen sowie Quellenlinks bleiben unverändert. Original auf Englisch lesen
IBM hat Qiskit SDK v2.6 veröffentlicht, ein Software-Update, das sich auf die Low-Level-C-Schnittstelle des Projekts konzentriert statt auf die bekanntere Python-Ebene. Laut IBMs Release-Zusammenfassung vom 22. Oktober ergänzt das Update die C-API um ein Pass-Manager-Framework, bringt die QPY-Schaltkreisserialisierung in Workflows mit kompilierten Sprachen und ermöglicht es Entwicklern, benutzerdefinierte Quantenoperationen direkt aus C zu definieren. Insgesamt setzen die Änderungen IBMs Bemühungen fort, mehr von Qiskit ohne Python-Laufzeit nutzbar zu machen.
Was angekündigt wurde
Mit dem Release v2.6 erweitert Qiskit seine C-API, die IBM als Low-Level-Schnittstelle zum Rust-basierten Kern-Datenmodell von Qiskit für den Einsatz aus kompilierten Sprachen beschreibt. Laut IBM ist die Schnittstelle sowohl für die eigenständige Nutzung ohne Python gedacht als auch für den Bau leistungsfähigerer Python-Erweiterungen, die direkt mit den Rust-Objekten von Qiskit interagieren.
In Qiskit v2.6 hat IBM dieser C-API ein generisches Pass-Manager-Framework hinzugefügt. Zu den neuen Komponenten gehören QkPassManager, QkPassVtable und QkIrHandle, die es Entwicklern zusammen ermöglichen, Compiler-Passes zu erstellen und sie zu typgeprüften Pipelines über mehrere Zwischendarstellungen hinweg zu verketten.
Das Release stellt außerdem QPY-Serialisierungsfunktionen in der C-API bereit, sodass Programme in Sprachen wie C, C++ und Julia das binäre Schaltkreisformat von Qiskit schreiben und lesen können, ohne den Umweg über Python zu gehen. Darüber hinaus können Entwickler nun laut IBM über eine C-vtable-Schnittstelle benutzerdefinierte Operationen definieren, darunter auch hardware-native Operationen.
Die technischen Details
IBM zufolge kann das neue Pass-Manager-Framework eine Kompilierungspipeline vor der Ausführung validieren, indem es die deklarierten Ein- und Ausgabedarstellungen für jeden Pass prüft. Zu den eingebauten Darstellungen gehören QkCircuit und QkDag; benutzerdefinierte IRs lassen sich ebenfalls über QkIrHandle beschreiben.
Das ist wichtig, weil die Compiler-Arbeit in Qiskit zunehmend darum organisiert wird, Programme über mehrere Darstellungen hinweg abzusenken, ein Muster, das sowohl für heutige Transpilierungsabläufe als auch für künftige fehlertolerante Toolchains relevant ist.
Bei der Serialisierung macht Qiskit 2.6 das QPY-Format v18 zum Standard. Laut IBM verringert diese Version die Größe serialisierter Schaltkreise durch eine kompaktere Kodierung für Quanten- und klassische Register. Über die C-API erzeugte Schaltkreise bleiben laut Unternehmen mit dem Python-Modul qiskit.qpy kompatibel.
Das Release belässt die minimal unterstützte Python-Laufzeit bei 3.10, während Builds aus dem Quellcode nun Rust 1.89 erfordern. Auf IBMs Roadmap-Seite heißt es außerdem, dass Qiskit 2.6.0 am 16. Oktober 2026 veröffentlicht wurde und Fehlerbehebungen über Patch-Releases oder das nächste Minor-Release ausgeliefert werden.
Warum das wichtig ist
Für die meisten Qiskit-Nutzer bleibt Python der wichtigste Einstiegspunkt. Doch IBM arbeitet klar erkennbar auch auf ein anderes Bereitstellungsmodell hin: Zugriff aus kompilierten Sprachen auf denselben Kern-Compiler- und Ausführungs-Stack.
Dieser Wandel ist für High-Performance-Computing-Umgebungen relevant, in denen Python bei Paketierung, Laufzeit oder Integration eine Einschränkung sein kann. Laut IBMs Dokumentation ist die C-API darauf ausgelegt, eine definierte ABI zum internen Rust-Datenmodell bereitzustellen, und im Blog des Unternehmens wird v2.6 als weiterer Schritt zur Nutzung von Qiskit in Umgebungen beschrieben, in denen Python nicht installiert ist.
Zugleich signalisiert das eine breitere architektonische Transition. Die Qiskit-Roadmap zeigt, dass IBM auf formale ABI- und API-Stabilität für die C-Schnittstelle in v2.7 hinarbeitet, zusammen mit einer neuen Middle-End-IR für fehlertolerante Kompilierung. Für v2.8 verweist die Roadmap auf BackendV3, dort beschrieben als eine Rust-native Backend-Schnittstelle, die für Python und C bereitgestellt wird.
Worauf zu achten ist
Die unmittelbare Frage ist die Stabilität. In der aktuellen Dokumentation zur C-API von IBM heißt es, die Schnittstelle sei weiterhin als experimentell zu betrachten und könne sich zwischen Minor-Releases ändern. Dieser Vorbehalt ist für Software-Teams wichtig, die eine tiefe Integration erwägen.
Der nächste Meilenstein ist damit Qiskit 2.7. Laut der Roadmap auf GitHub soll diese Version Stabilitätsgarantien für die C-API definieren und die Compiler-Funktionalität weiter ausbauen. Sollte IBM das liefern, wird der Nicht-Python-Pfad von Qiskit weniger wie ein internes Infrastrukturprojekt wirken und mehr wie eine produktionsreife Schnittstelle für kompilierte Quantensoftware-Stacks.
Quellen
Die Informationen auf dieser Seite stammen aus den unten aufgeführten Quellen und wurden von DesignQuantum abgerufen.
- Qiskit SDK v2.6 release summary | IBM Quantum Computing Blog ibm.com
- Qiskit SDK C API documentation (latest version) | IBM Quantum Documentation quantum.cloud.ibm.com
- Roadmap github.com
- IBM Releases Qiskit SDK v2.6 with C API Pass-Manager Framework, Native QPY Serialization, and Custom Operations - Quantum Computing Report quantumcomputingreport.com