Skip to content

Sporkle:把内存和设备编排放在第一位

一个不舒服的实话:我们基于 CUDA 的 AI 技术栈,是优化方程式的人搭的,不是懂硬件的人。数据科学家懂数学;系统工程师懂内存。当我给真实负载上仪器,大约 ~55% 的墙钟时间压根不在「做 AI」——它消散在可避免的数据搬运和同步停等里。AI 慢,不是因为模型大;是因为内存被人当成事后想起来的事。

Sporkle 是我第四次向这问题开火:先把它当设备管理问题,再当计算问题。用一个 API 干净地编排内存、生命周期和跨设备的搬运;让数学骑在一条清醒的流水线上面。当你把内存摆在正中间,技术栈就不再跟你打架, 性能开始在处处冒头。

为什么是 Fortran

我用一门新而漂亮的 Fortran 方言写它,因为数组语义和显式形状能让编译器生成狠得下手的代码,同时内存模型一目了然。想想 do concurrent、纯过程、显式形状数组、可预测的步长,必要时再加 ISO C 互操作。它读起来像数学,举止像系统,还顺手删掉了那锅让「快」代码又脆又不透明的指针烂汤。

实测数据

收据——连 NVIDIA 支持都还没落地:生产 CPU 路径跑到 ~90–160 GFLOPS;一个直白的 OpenGL compute 后端拿下 400+ GFLOPS;三缓冲异步流水线(围栏门控)合计 ~3,630 GFLOPS。大核心在流水线里看到约 ~6.5× 延迟砍削;小的内存受制型核心,靠数据保温和发射不乱,照样拿下 ~2.3× 吞吐。负载之下,线程安全的程序缓存甚至报出「负开销」,拜无锁读取和共享工件所赐,打到 ~124.5% 的并行效率。

🧩 今天它跑在 AMD 上,不发供应商 SDK 仙尘也能派真实的活;NVIDIA 和 Intel 在后面排队。命题是设备无关的:修好数据搬运,赢面在任何有内存和通道的家伙身上都会冒出来。

🖥️ 而且这数字重要就重要在:以上每一个,都产自我那台三年高龄的 Ryzen 7、全家 AMD 的游戏机。不是机房机柜。没有任何异国硬件。只有规规矩矩的系统工程。

⚡ 为什么要盯这件事?有用 AI 的最低占地更小。不用更大的箱子也能提速。每个 token/帧/样本省下瓦数。可复现的测试架、真实的轨迹、研究级代码。设备层修好,数学自己飞。

目前 Alpha2

👉https://github.com/LynnColeArt/sporkle