Booth：一个把 CUDA、HIP 和 Triton 编译到 CPU 的编译器，值得你多看两眼
针对多个 GPU 和 CPU 架构的开源 CUDA、Triton 和 HIP 编译器。
秒懂
- 它是什么？
- Booth 是一个开源的 CUDA、HIP 和 Triton 编译器，能把 GPU 内核编译到 AMD、NVIDIA、Tenstorrent 甚至纯 x86-64 CPU。本文介绍它的工作机制、上手方式、局限性和适用人群。
- 适合谁用？
- Booth 适合那些想在无 GPU 环境里跑通 Triton 或 CUDA 内核、做原型验证或教学的人，也适合对编译器实现感兴趣的开发者。它不适合追求生产级 GPU 性能优化、需要完整 CUDA 特性支持或依赖成熟生态的企业团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 C（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个把 GPU 内核编译到 CPU 的编译器，解决什么问题
Booth 是一个开源编译器，输入是 CUDA C、HIP 或 Triton 源码，输出可以是 AMD RDNA 2/3/4 二进制、NVIDIA PTX、Tenstorrent Metalium C++、RV32IM，或者纯 x86-64 可执行文件。最后一种输出意味着你可以在没有 GPU 的笔记本上运行 Triton 内核，包括 matmul。README 里作者说没见到别人这样做，这确实是个罕见的定位。它主要面向两类人：一类是需要在无 GPU 环境里验证或运行 GPU 内核的开发者，另一类是研究编译器实现的人，尤其是对 SSA、寄存器分配和发散分析感兴趣的人。
从 CUDA 到 x86-64：一条不经过 LLVM 的路径
Booth 的核心机制是直接从前端语言生成目标代码，不依赖 LLVM。对 CUDA 和 HIP，它直接解析源码；对 Triton，它读取 Triton 的 JIT 中间表示；对 Fortran do concurrent，它通过 LFortran 先把 Fortran 转成 CUDA 源码，再交给 Booth 编译。OCaml 内核则走另一条路：用 ocamlc 做类型检查，Booth 读取 .cmt 文件。这种设计让 Booth 能绕过 LLVM 的庞大依赖，但也意味着它必须自己实现大量的编译器后端工作，包括 SSA 寄存器分配和发散分析。README 提到这些技术来自学术论文，比如 Braun 和 Hack 的 SSA spill，以及 Sampaio 等人的发散分析。
获取和构建：一条命令，零依赖
如果你想快速尝试，直接从 GitHub Releases 下载预编译的 Linux、macOS 或 Windows 二进制包，解压后运行 ./kath --version 即可。kath 是二进制名，因为 Linux HA 栈里已经有一个叫 booth 的程序，避免冲突。如果你要自己构建，只需要一个 C99 编译器，执行 make 就行，没有其他依赖。编译一个 CUDA 内核到 AMD GPU 二进制，命令是 ./kath --amdgpu-bin kernel.cu -o kernel.hsaco。Fortran 和 OCaml 前端需要额外的编译器，但构建 Booth 本身不需要它们。
OCaml 和 Fortran：类型检查前置的另类设计
Booth 支持用 OCaml 写 GPU 内核，这是一个不寻常的设计。OCaml 内核是普通函数，由 ocamlc 做类型检查，所以如果你把 int 写到需要 32 位设备整数的地方，或者把 block-shared 数组当全局数组读，会在 Booth 看到之前就报错。README 里提到一个用 OCaml 写的 Asian option pricer 在 RTX 4060 Ti 上运行，结果和闭式参考一致。Fortran 内核则通过 LFortran 生成 CUDA 源码，再走 Booth 的编译管线，CI 里用 SLATEC 标准值做验证。这种前置类型检查的思路，对减少内核错误有帮助，但它也意味着你需要额外安装 OCaml 5.x 和 dune，或者 LFortran，才能用这些前端。
主框架式的运行纪律：崩溃转储和结构化输出
Booth 借鉴了大型机世界的运行纪律，提供真实的崩溃转储（ABEND dumps）、按类别路由的结构化输出（SYSPRINT）和入口参数快照（SNAP）。这些功能对调试 GPU 内核很有用，因为 GPU 内核出错时往往难以定位。文档 docs/mainframe.md 专门介绍这些特性。这种设计在编译器项目中不常见，它反映了作者对可观测性的重视。但需要注意的是，这些功能可能增加运行时开销，而且文档没有说明具体如何启用或配置，实际使用时可能需要参考文档细节。
已知限制和适用边界
Booth 目前不是完整的 CUDA 或 HIP 实现。docs/features.md 明确列出了哪些能编译、哪些不能，但 README 没有详细列举。这意味着你可能会遇到不支持的库调用、内置函数或架构特性。另一个限制是性能：Booth 的目标是尽可能接近原生，但直接生成机器码而不经过 LLVM 的优化，可能在某些场景下性能不如 nvcc 或 ROCm 的产物。此外，RV32IM 输出暗示它支持 RISC-V 32 位，但文档没有说明具体支持哪些扩展或性能预期。如果你需要生产级的 GPU 性能优化，Booth 可能不是首选。
替代方案：nvcc、ROCm 和 Triton JIT 的差异
直接的替代方案是使用 NVIDIA 的 nvcc 编译 CUDA 到 PTX 或 SASS，或者使用 ROCm 的 hipcc 编译 HIP 到 AMD GPU。这些工具链成熟，优化充分，但都依赖特定 GPU 厂商的驱动和运行时。Triton 本身有 JIT 编译器，但它的目标是生成 GPU 代码，不能直接输出 CPU 可执行文件。Booth 的不同在于它提供了一个统一的编译入口，能把多种前端语言编译到多种后端，尤其是 CPU。如果你只需要在 GPU 上跑，传统工具链更可靠；如果你需要跨架构或 CPU 回退，Booth 提供了独特的价值。
维护与许可：Apache-2.0 下的个人项目
Booth 采用 Apache-2.0 许可证，允许自由使用和修改。项目最近有活跃的发布记录，v0.5.2 在 2026 年 8 月发布，v5.01 在 7 月，v0.5.0 在 5 月，说明维护是持续的。但项目本质上是个人项目，作者在 README 里自称是 hobbyist，依赖社区反馈和贡献。升级成本方面，由于没有依赖，构建和部署相对简单，但你需要关注 CHANGELOG.md 来了解每次版本的变化。另外，如果你打算在生产环境使用，作者在 README 里说会很高兴听到，但这也暗示项目可能没有企业级支持。
编辑结论
Booth 适合那些想在无 GPU 环境里跑通 Triton 或 CUDA 内核、做原型验证或教学的人，也适合对编译器实现感兴趣的开发者。它不适合追求生产级 GPU 性能优化、需要完整 CUDA 特性支持或依赖成熟生态的企业团队。在采用前，先检查 docs/features.md 确认你需要的语言特性和目标架构是否在支持列表里，再用你自己的内核跑一遍测试，特别是涉及共享内存、原子操作或复杂控制流的部分。
社区笔记