IBM 通过发布 SDK v2.6，进一步推动 Qiskit 超越 Python

随着 IBM 推进可选 Python 的工作流，Qiskit SDK v2.6 新增了 C API 的 pass manager、原生 QPY 序列化以及自定义操作。

本页由英文翻译而来。公司和产品名称及来源链接保持不变。阅读英文原文

IBM 已发布 Qiskit SDK v2.6。这次软件更新的重点是该项目的底层 C 接口，而非更广为人知的 Python 层。根据 IBM 10 月 22 日发布摘要，此次更新为 C API 增加了 pass manager 框架，将 QPY 电路序列化引入编译型语言工作流，并允许开发者直接通过 C 定义自定义量子操作。综合来看，这些变化延续了 IBM 让 Qiskit 更多功能在无需 Python 运行时的情况下可用的努力。

发布了什么

v2.6 版本扩展了 Qiskit 的 C API。IBM 将其描述为一个面向编译型语言的底层接口，用于访问 Qiskit 基于 Rust 的核心数据模型。IBM 表示，这一接口既可在脱离 Python 的情况下独立使用，也可用于构建与 Qiskit Rust 对象直接交互、性能更高的 Python 扩展。

在 Qiskit v2.6 中，IBM 为该 C API 增加了一个通用的 pass manager 框架。新组件包括 QkPassManager、QkPassVtable 和 QkIrHandle，它们共同使开发者能够创建编译器 pass，并将其串联为可跨多个中间表示进行类型检查的流水线。

此次发布还在 C API 中开放了 QPY 序列化函数，使得以 C、C++ 和 Julia 等语言编写的程序无需通过 Python 中转，就能读写 Qiskit 的二进制电路格式。此外，据 IBM 称，开发者现在还可以通过 C vtable 接口定义自定义操作，包括硬件原生操作。

技术细节

IBM 表示，新的 pass manager 框架可在执行前验证编译流水线，方法是检查每个 pass 所声明的输入和输出表示。内置表示包括 QkCircuit 和 QkDag，而用户定义的 IR 也可以通过 QkIrHandle 进行描述。

这很重要，因为 Qiskit 的编译器工作正日益围绕通过多种表示逐步降低程序层级来组织。这种模式既适用于当前的转译流程，也与未来的容错工具链相关。

在序列化方面，Qiskit 2.6 将 QPY 格式 v18 设为默认值。IBM 表示，该版本通过对量子寄存器和经典寄存器采用更紧凑的编码，减少了序列化电路的体积。据该公司称，通过 C API 生成的电路仍与 Python 的 qiskit.qpy 模块兼容。

此次发布将最低支持的 Python 运行时维持在 3.10，而从源码构建现在则要求 Rust 1.89。IBM 的路线图页面还指出，Qiskit 2.6.0 已于 2026 年 10 月 16 日发布，错误修复将通过补丁版本或下一个次要版本交付。

这为什么重要

对大多数 Qiskit 用户而言，Python 仍是主要入口。但 IBM 显然也在构建另一种部署模式：以编译型语言访问同一套核心编译器和执行栈。

这一转变与高性能计算环境相关，因为 Python 可能在打包、运行时或集成方面构成限制。IBM 的文档称，C API 旨在为内部 Rust 数据模型提供一个明确定义的 ABI，而该公司的博客则将 v2.6 定位为又一步，让 Qiskit 能用于未安装 Python 的环境。

这也表明了更广泛的架构转型。Qiskit 路线图显示，IBM 正朝着在 v2.7 中为 C 接口实现正式的 ABI 和 API 稳定性迈进，同时引入一个面向容错编译的新中端 IR。至于 v2.8，路线图指向 BackendV3，并将其描述为一个面向 Rust 原生的后端接口，向 Python 和 C 暴露。

值得关注什么

眼下最直接的问题是稳定性。IBM 当前的 C API 文档称，该接口仍应被视为实验性功能，并且可能会在次要版本之间发生变化。对于考虑深度集成的软件团队来说，这一点非常重要。

因此，下一个里程碑是 Qiskit 2.7。根据 GitHub 路线图，该版本预计将为 C API 定义稳定性保证，并进一步扩展编译器功能。如果 IBM 做到这一点，Qiskit 的非 Python 路径看起来就不再像一个内部底层工程项目，而更像是面向编译型量子软件栈的生产级接口。