Show HN 上的 Enki：让 GPU kernel 用纯 stable Rust 写，作者说这是为了治「GPU 编程地狱」

今天在 Hacker News 上看到个 Show HN，点进去叫 Enki。一句话：用纯 stable Rust 写 GPU compute kernel，然后直接编译跑在 GPU 上。项目挂在 github.com/enkiruntime/enki，目前 7 个 points、1 条评论，热度不高，但作者在里面写了一大段来龙去脉，反而比很多几百赞的帖子更有信息量。

作者说这项目是为了治他所谓的「GPU 编程地狱」。他最早从 OpenGL 起步，后来碰 Vulkan，被吓到的主要是那堆样板代码——只为了跑一个三角形或者一个基础 matmul，就得写多少东西。他是从 CPU 语言（C#，后来 Rust）过来的，本来以为体验差不多，结果发现完全不是这么回事。于是自己憋了一年多用 Vulkan 写游戏引擎，期间做了个叫「utu」的内部库，专门帮他抽象 Vulkan 的样板代码，做着做着冒出个念头：与其一直忍，不如自己把这个主问题修了。然后他把代码全扔了，只盯一个目标——「写 CPU 代码，让它跑在 GPU 上」。

技术路径是他最痛苦那段：把用户 kernel 函数（叫 nam）对应的 Rust bitcode（也就是 .bc 的 LLVM IR）编译到 SPIR-V，这部分他专门写了个编译器，起名「parsu」。这步做完，他声称 crates.io、迭代器、enum、泛型都能直接写进 kernel 里跑在 GPU 上。因为就是原生 stable Rust 的语法，想回 CPU 跑也顺理成章，代码一行都不用动。

方向挺对口。现在 GPU 编程的主流路数基本是 CUDA、Vulkan 手搓、或者各种领域特定语言，Rust 生态里像 wgpu 也有自己的着色器路线，但「纯 stable Rust、同一份代码 CPU/GPU 都能跑」这个卖点，真能落地的还不多。也正因为这样，我反而更想泼点冷水：作者现在是自述为主，没看到任何 benchmark，没有 matmul 性能对比、没有和 hand-written kernel 的差距数据。LLVM IR 到 SPIR-V 的转换，能不能保住 vectorization、能不能保留关键的优化，这才是 GPU 代码真正要命的地方——「能跑」和「跑得快」隔着一整个优化深渊。目前看到的说法是「能用」，我猜真正拿去做渲染或矩阵计算的人，心里还得再掂量掂量。

不过这种项目最大的价值，其实在于它戳了个点：GPU 编程这么多年的痛苦，很多不在于算法难，而在于样板代码和语言割裂。有人愿意站出来把这层皮扒掉一点，总归是好事。仓库只有一个初始提交级别的热度，但这类工具通常就是慢慢被真实工作量喂大的——有人真拿它跑起来、报出 bug、贴出性能曲线，它才有下一步可能。

现在也挂着一个时间线：YC Winter 2027 批次的申请开到 11 月 2 日。作者是第一回发帖，估计也在琢磨这条路怎么走。我的看法是，先别急着看它能不能进孵化器，先看它能不能在一个真实项目里撑住一次像样的 matmul 再说。暂未看到任何性能数据之前，权当一个「写法很顺口、跑起来待验证」的新尝试来关注。

相关链接
- Enki 项目仓库
- Hacker News 原始讨论