XStack基准：ML代码跨框架迁移的试金石

机器学习代码应该运行在研究者选择的地方，而不是它最初被编写的地方。如今，ML代码主要栖息于两个生态系统：PyTorch配NVIDIA GPU，以及JAX配Google TPU。将代码库在这两个生态之间迁移，意味着要跨框架和硬件进行构建与测试。这种迁移既是实际需求——它能为研究者解锁不同的硬件——也是一个天然的基准：它涉及不同的框架和硬件，覆盖整个代码库，且具有长时程和挑战性。为此，我们推出XStack，一个评估智能体在两大生态间迁移ML代码库的基准。每个智能体收到一个PyTorch代码库和一台干净的TPU机器，必须交付一个JAX代码库。其输出需满足我们基于源仓库已发表结果的评分标准（经我们认证和校准）才算通过。目前，智能体迁移仍不可靠：Claude Opus 5通过率为75%，GPT-5.6-sol为45%，其他所有智能体至多40%。XStack是迈向将ML代码从其生态束缚中解放的一步。我们发布XStack，旨在让跨框架和硬件的可靠迁移变得可衡量，并推动其进展。

为什么需要XStack基准？

ML代码的生态锁定是一个现实问题。研究者选择PyTorch或JAX，往往受限于硬件可用性而非个人偏好。迁移代码库不仅需要理解两种框架的API差异，还要处理硬件特性、性能调优和整个仓库的依赖关系。这种复杂性使得迁移成为评估智能体能力的理想测试场：它要求长时程规划、跨领域知识整合，以及对整个代码库的全局把握。XStack将这一挑战形式化，为智能体提供了一个标准化的竞技场。

JAX与PyTorch的核心差异：PyTorch采用即时执行（eager execution）模式，操作在调用时立即计算，调试直观；JAX则基于函数式编程范式，默认使用即时编译（JIT）将纯函数编译为XLA计算图，要求代码无副作用且形状静态。此外，JAX的自动微分通过grad变换实现，而非PyTorch的.backward()方法；参数更新需借助optax等库显式完成，而非优化器的.step()。这些范式差异意味着迁移并非简单的API替换，而是需要重构代码的执行模型与状态管理方式。

TPU与XLA编译器：TPU是Google专为张量计算设计的专用集成电路（ASIC），其执行依赖XLA（Accelerated Linear Algebra）编译器将计算图编译为TPU指令。与GPU上常用的CUDA内核不同，XLA会进行算子融合、内存规划等全局优化，但要求计算图静态且形状已知。这导致在TPU上运行时，动态控制流和可变形状操作需特殊处理（如jax.lax.cond、jax.lax.scan），也是PyTorch代码迁移至JAX+TPU时的主要性能与兼容性挑战之一。

XStack如何工作？

XStack的核心设计简洁而严格。每个智能体获得一个PyTorch仓库和一台干净的TPU机器，任务是产出一个JAX仓库。评分不依赖主观判断，而是基于源仓库的已发表结果——这些结果经过认证和校准，确保迁移后的代码在功能上等价且性能达标。这种基于真实结果的评分机制，使得基准既贴近实际又具有可重复性。智能体需要独立完成整个迁移流程：从代码解析、框架转换到硬件适配和测试验证。

智能体表现：差距明显

初步评估揭示了智能体在迁移任务上的不均衡表现。Claude Opus 5以75%的通过率领先，GPT-5.6-sol达到45%，而其他所有智能体均不超过40%。这一分布表明，尽管顶尖模型展现出一定潜力，但迁移的可靠性远未达到生产级要求。高通过率背后的原因可能包括更强的代码理解能力和长上下文处理能力，但即使是领先者也有四分之一的失败案例，说明任务仍存在显著挑战。

基准中的智能体与通过率：文中提及的Claude Opus 5、GPT-5.6-sol等为参与评估的AI智能体（基于大语言模型的代码智能体）。通过率指智能体在XStack任务中成功交付满足评分标准的JAX代码库的比例。75%的通过率意味着在多数任务上功能与性能达标，但仍有四分之一的失败案例；而其他智能体至多40%的通过率则反映出当前模型在长时程、跨框架迁移任务上的普遍局限。

迁移难点与未来方向

迁移的难点是多维的。框架间的语义差异（如自动微分机制、张量操作习惯）、硬件特有的优化（如TPU的XLA编译与GPU的CUDA内核），以及仓库级别的依赖管理，都构成了障碍。XStack的发布为社区提供了一个可衡量的目标：通过量化智能体的迁移能力，推动跨框架工具和方法的进步。未来，随着基准的迭代和智能体能力的提升，我们有望看到更可靠的迁移方案，最终让ML代码自由流动于不同生态之间。