SonicBoom：在笔记本电脑的 RTX 3050 上，解码速度达到 52 tok/s（llama.cpp：45），使用相同的量化内核，区别在于图编译器。不使用 Python。

我一直在开发 SonicBoom，这是一个用 C++/CUDA 编写、提供 C ABI 的原生张量运行时，整个技术栈完全没有 Python。我刚刚打了 v0.0.1 标签，首个目标是在消费级 GPU 上进行本地 LLM 推理。性能数据（在配备 RTX 3050 8 GB 的笔记本上运行 Gemma 4 E4B-it Q3_K_M，两个运行时在同一台机器上使用同一个 GGUF 文件，llama.cpp 的提交为 43fe9c64281）：SonicBoom llama.cpp 解码（tg64）51.65 token/秒 45.20 token/秒 上下文深度为 2048 时的解码 47.13 token/秒 45.21 token/秒 4100 个 token 的预填充 1051 token/秒 ~1944 token/秒 首 token 延迟（TTFT），4000 个 token 的前缀 + 100 个新 token：503 毫秒（前缀复用）为什么这很重要：量化矩阵乘法内核（MMVQ/MMQ）移植自 ggml，因此与 llama.cpp 使用的是同一套内核。解码速度领先 14%，完全来自内核之上的那一层。图规划器会在模型运行前对其进行改写：激活值只量化一次并复用，归一化和激活运算与量化融合，无用计算被移除，每个解码步骤都被捕获并作为单个 CUDA Graph 重放。源自 ggml 的代码约占核心代码的 8%。其余都是运行时。前缀复用是精确的：续写结果与完整预填充后的结果逐 token 完全一致，这使得多轮聊天和编程助手工作负载的开销很低。目前还做不到的事情：预填充速度约为 llama.cpp 的一半。它采用了真正的批处理路径（int8 张量核心加 cuBLAS），但仍有差距需要缩小。已验证的模型只有一个：Gemma 4 E4B。量化格式仅支持 Q3_K、Q4_K 和 Q5_K，因此 Hugging Face 上的大多数 Q4_K_M 文件目前还无法加载，因为它们混用了 Q6_K 和 Q8_0。接下来会支持这些格式以及 Qwen。它只在 sm_86（RTX 30 系列）上经过测试，采样也仅支持贪心模式。目前它还不能直接替代 llama.cpp。v0.0.1 的意义在于证明这套架构可行：当图编译器建立在同一套内核之上后，后续的性能提升就来自编译器，而不是更多手写内核。路线图中的下一步是 MLIR GPU 代码生成、推测解码，以及更多格式。采用 GPL-3.0 许可证。基准测试条件、复现命令和模型的 sha256 都在 README 中：https://github.com/hardenedlinux/SonicBoom