xquad

XQuad：量子优化问题的"LLVM"

当你的量子退火机"水土不服"时

想象一下：你费尽千辛万苦为 D-Wave Advantage 量子计算机写好了一个组合优化问题，准备在量子世界里寻找最优解——结果项目突然换了硬件路线，或者你需要同时对比 classical 模拟器的效果。传统做法意味着：重写、重写、再重写。代码在各个后端之间疲于奔命，科学家的时间被大量浪费在适配工作而非核心问题上。

XQuad 正是为了解决这个痛点而生的。它提出了一个大胆的思路：与其让问题去迁就硬件，不如让硬件来适配同一个标准"中间语言"。XQuad 的核心是一个基于栈的虚拟机（XQVM），你用它的汇编语言 .xqasm 编写一次 quadratic 优化问题，就能自由切换到任何已支持的后端——D-Wave 量子退火机、NVIDIA CUDA GPU、Apple Metal GPU，或者纯 Python 模拟器。这和 LLVM 在传统编译器领域的思路如出一辙：用统一 IR 解耦上层问题与下层硬件。XQuad 的作者也毫不讳言这一点，直接在 README 中写道："Think of it as LLVM for quadratic models"。

这个项目来自 Quip Network 旗下的 Postquant Labs，背后的技术积累颇为深厚。GitHub 页面显示，XQuad 已被超过 5,500 颗 stars 关注，18 次 fork，2026 年 8 月仍有活跃更新。维护者在文档中明确写道"Early public release"，指令集、二进制格式和公共 API 在 v1.0 之前可能还会变化——但这恰恰说明项目正处于快速迭代期，值得持续跟踪。

架构：三个 Rust crate + 五个 Python 包

XQuad 的技术栈设计非常有意思。它本质上是一个 Rust-first 的多语言混合仓库，顶层是一个 Cargo workspace，包含 6 个子 crate：

这套设计的精妙之处在于"双重实现互验"：每个 opcode 的行为在 xqvm（Rust）和 xqvm_py（Python）中各有一份实现，CI 中会强制对比两者输出——任何不一致都会导致构建失败。这种 cross-implementation parity 机制在虚拟机类项目中极为罕见，极大提升了规范（SPEC.md）的可信度。

在硬件抽象层面，XQuad 支持的后端层次非常丰富。基础的 CPU 模拟退火（Simulated Annealing）随 pip 安装即可使用，无需额外依赖。如果有 NVIDIA GPU，装上 xquad[cuda] 即可启用 CUDA 加速的 QUBO 求解；macOS Apple Silicon 用户则可以用 xquad[metal] 启用 Metal GPU。对于拥有 D-Wave Leap 账号的用户，xquad[dwave] 将量子退火硬件直接接入流水线。各种 extra 之间可以自由组合（pip install xquad[cuda,dwave]）。

使用体验：两种交互模式

对于普通用户，XQuad 提供了两套入口。Python API 是官方推荐的方式——xquad.program 中的 Program + Session + RunResult 三件套设计非常直观：写一次程序，创建 session，传入不同的 calldata 执行，最后用 RunResult 提取输出。这套 API 对 Jupyter/REPL 环境做了友好优化，可以反复注入不同参数观察结果。

from xquad.program import Program

program = Program.from_source("""
PUSH 0
INPUT r0
PUSH 1
INPUT r1
LOAD r0
LOAD r1
ADD
STOW r2
PUSH 0
OUTPUT r2
HALT
""")

session = program.session(output_slots=1)
session.set_calldata([40, 2])
result = session.run()
assert dict(result.outputs) == {0: 42}

CLI 工具则适合做快速验证或脚本化场景：

xquad asm add.xqasm -o add.xqb && xquad run add.xqb

examples 目录中包含了大量实际应用：TSP 旅行商问题、MaxCut 图划分、背包问题、最大独立集、图着色、二次规划……覆盖了组合优化的主流场景，质量相当扎实。

技术细节：栈机 + 类型化寄存器文件

XQVM 是一个基于栈的字节码虚拟机，但它不仅仅有操作数栈——还有一个 256 槽的类型化寄存器文件。寄存器可以存整数、整数向量、QUBO/Ising 模型（XqmxModel）和候选解（XqmxSample）。这种混合设计让 XQVM 既能处理经典计算（整数运算、循环跳转），又能原生表达量子优化问题。

字节码格式极为精简：没有文件头，没有常量池，只有 opcode 字节 + 大端序操作数。这使得 .xqb 字节码文件可以非常紧凑，也方便嵌入其他系统（如 Substrate 区块链的 pallet，或者 WASM runtime）。

opcode 表用 Rust x-macro 声明在 xqvm/src/bytecode/types/table.rs 中，同时维护一份 YAML 规范（conformance/opcodes.yaml），Python 实现也在 xqvm_py.opcodes 中对应维护。三方一致性由脚本 scripts/check-opcode-parity.py 强制校验，构建时和 CI 中都会执行。

局限与风险

必须指出几个现实问题：

第一，v1.0 之前 API 不稳定。作者明确警告不要用于生产环境。如果你需要的是稳定的依赖项，现阶段 XQuad 不是好选择。

第二，Python 预编译轮子仅限 CPython >= 3.13。这对很多企业级 Python 环境是个挑战（很多生产环境仍在用 3.10-3.11）。Linux/macOS/Windows 用户如果 Python 版本不满足条件，需要本地编译 Rust 扩展，门槛不低。

第三，硬件支持门槛较高。D-Wave QPU 需要 Leap 账号和 API token，NVIDIA GPU 需要 CUDA 12.x 驱动——不是开箱即用的体验。真正的价值在于你在已有这些硬件资源的情况下，XQuad 能让你在它们之间自由切换对比。

第四，AGPL-3.0 许可。如果你的商业产品需要链接这个库，AGPL 的传染性需要认真评估（相比 MIT/Apache 更严格）。

行业意义

XQuad 代表了一个值得关注的方向：量子-经典异构求解器的抽象层。目前量子计算领域最大的问题之一是硬件碎片化——每家 QPU 厂商都有自己的 SDK 和问题格式，切换成本极高。XQuad 尝试用统一 IR + 多后端的方式解决这个问题。如果量子计算真正走向商业化，这类中间层工具的价值会快速放大。

截至 2026 年 8 月，XQuad 的活跃度数据值得关注：5589 stars，18 forks，2026-08-03 仍有更新，Rust crates.io 和 PyPI 双轨发布策略——这是一个有持续投入的活跃项目，而非昙花一现的实验性代码。

如果你在处理 QUBO / Ising / 离散优化问题，无论是做量子算法研究还是对比 classical 求解器的效果，XQuad 都值得放进工具箱。唯一需要记住的是：它还处于发育期，生产环境使用前请务必锁定具体版本。