技术背景:本地 LLM 推理的"内卷"拐点
本地跑 LLM 这几年,llama.cpp 几乎成了"标准答案"。开发者社区里,默认动作就是去 GitHub 克隆 ggml-org 仓库,拿 GGUF 权重,塞进 llama-bench 看 decode 速度。但 llama.cpp 的速度来源,基本是工程师手写 kernel 的极限优化——每加一个新融合、一个新模型架构,就要写一个新 kernel。当模型迭代速度赶上不上手写速度,这就是天花板。
2026 年 10 月,HardenedLinux 社区推出了 SonicBoom v0.0.3——一个把 MLIR 编译器与传统量化 kernel 放在一起的 AI 运行时框架。它只有 22k 行 C++/CUDA 核心,稳定 C ABI 暴露能力,GPLv3 协议开源。GitHub 仓库 hardenedlinux/SonicBoom 在 README 里就一句话:"A native tensor runtime. No Python. One .so."
它的思路非常清晰:不要再去手写 kernel 了,直接让编译器生成。
核心内容:把编译器搬进运行时
SonicBoom 的架构是四层分层,Layer 0 是 CPU/CUDA 硬件,Layer 1 是 native-torch 实现,Layer 2 是稳定运行时接口,Layer 3 是 C ABI 与多语言绑定(Layer 依赖严格向下)。整个 libsonicboom.so 是对外发布的库,MLIR 是静态链接进去的,不是运行时依赖。
它的核心不是单点创新,而是组合拳:
- MLIR 编译器层:模型图先被 lowering 到 Boom IR,然后经过 MLIR 的 rewrite passes,最终通过
linalg → gpu → nvvm生成 GPU kernel。这些 kernel 是 JIT 编译的,按 shape signature 缓存。 - 图规划器层:在模型真正运行之前,整个模型会被重写一遍——量化-一次到位、norm→quantize 融合、激活→量化融合、死计算消除、layout 选择、整段 decode 步骤的 CUDA Graph capture。
- 手写 kernel 层:只在编译器还没追上的地方兜底——比如从 ggml 移植过来的 MMQ/MMVQ 量化矩阵乘和 tiled prefill attention。
也就是说,SonicBoom 不再是一个"kernel 集合",而是一个"编译器栈"。
关键性能:同一 kernel,不同框架
v0.0.3 验证了两个模型家族:Gemma 4 E4B-it Q3_K_M 和 Qwen2.5-0.5B-Instruct Q4_K_M,均在 RTX 3050 8GB 上对照 llama.cpp commit 43fe9c64281 跑出来的数据。
Gemma 4 E4B-it Q3_K_M:
- Decode 64-step steady state:53.0 tok/s vs 44.8 tok/s,1.18×
- Decode at KV depth 512:52.1 tok/s vs 44.2 tok/s,1.18×
- Prefill 512-token prompt:1990 tok/s vs 1992 tok/s,1.00×(持平)
Qwen2.5-0.5B-Instruct Q4_K_M:
- Decode 64-step steady state:344.7 tok/s vs 307.6 tok/s,1.12×
- Prefill 512-token prompt:15346 tok/s vs 14044 tok/s,1.09×
关键的事实是:decode 用的就是 llama.cpp 的量化 GEMV kernel,优化没有改。那 12–18% 的领先完全来自 runtime 层——图规划器和 MLIR 编译器层的优化。这印证了 README 里那句"says: fast because of the runtime, not only the kernels"。
另一个工程亮点是 prefix-cache reuse:同一个 session 后续 prompt 如果以相同 token 开头,只有新增的后缀会被 prefill。一个 512-token prefix + 64 new 的延迟:Gemma 65.2 ms,Qwen2 13.7 ms。llama-bench 量不出这个,所以 README 直接以"first-token latency in milliseconds"报。
编译器层细节:从 S-Expr 到 NVVM
SonicBoom 用 GNU Guile 作为 first-class 语言,这一选择让应用层可以享受 PyTorch 一样的灵活性——delimited continuation 实现"死计算消除",只有真正有效的计算才进入运行时。研究侧的模型可以直接用 Scheme 写,然后 trace 到一张图里,送进 planner。
native-torch 的 operator 库在编译时由 SonicCross 生成——这是一个用 Guile 写的 torchgen 替代品。它把 PyTorch 的 native_functions.yaml 转成 native-torch 的 C++ declaration、registration、dispatch sources,每轮生成超过 7,000 个 per-operator 头文件。SonicCross 只在 build time 运行,不链接进 libsonicboom.so。
LLVM/MLIR 锁版本是 23,被静态链接进库。如果用户已有 LLVM 安装,可以通过 -DMLIR_DIR=/opt/llvm/lib/cmake/mlir 等 CMake 变量指向,跳过 submodule 同步。
与 PyTorch 的对照:一个不装 Python 的版本
README 里直接点破:SonicBoom 想做的是 "a better PyTorch, with no Python in it"。
- 同样的 eager 风格,但不需要 Python 解释器、不需要 pip、不需要 wheel tree。
- 同样的模型定义方式,但生产路径用的是 C++ core,研究路径用的是 Scheme。
- 同样的灵活性,但底层不再是 Python bytecode 解释器,而是 Guile 的
syntax-rules和 delimited continuation——TorchDynamo 需要 CPython 字节码解释器才能解决"data-dependent control flow without graph breaks",SonicBoom 用宏直接做。
这套路线对生产部署非常友好。README 给了一个三百多 MB 的 .so 文件,部署成本压到极限,没有几十 G 的 Python 全家桶。
现状与路线图
v0.0.3 不是 llama.cpp 的 drop-in 替代。明确边界:
- 两个验证模型家族:Gemma 4 E4B-it Q3_K_M 与 Qwen2.5-0.5B-Instruct Q4_K_M。其他模型能用,但需要社区跑出复现数据。
- 量化格式:Q3_K、Q4_K、Q5_K、Q6_K、Q5_0、Q8_0,
f16和q4_0在 load 时转 Q5_K。 - 采样:仅 greedy,
temperature、top_p、top_k都返回SB_ERR_UNSUPPORTED。 - GPU:CUDA sm_86(RTX 30 系),社区已有 RTX 4060 Ti Ada 上的复现数据。
路线图上比较值得关注的:
- prefill 还有 attention 是瓶颈,下一个 lever 是 generated tensor-core FA-2。
- Vulkan 后端已经在 tree 里(
-DSONICBOOM_USE_VULKAN=ON),面向 non-NVIDIA 与纯自由软件用户。 - 路线图上还有 "Beyond LLMs"——diffusion 模型,准备做一个 ComfyUI workflow 转换器。
行业意义:不是又一个 llama.cpp
SonicBoom 的关键判断不是"比 llama.cpp 更快",而是"kernel 不该是 limit"。llama.cpp 的设计哲学是 hand-tuned kernels,每加一个 fusion 就写一个新 kernel。SonicBoom 的设计哲学是"一次写 pass,所有架构都受益",由 planner 与编译器承担跨模型的优化。
这跟大模型训练框架从手写 CUDA kernel 切到编译器栈(Triton、TVM、MLIR 派系)的路径高度相似。推理栈这次终于跟上了。
社区目前 10 stars、271 commits,但合作方 HardenedVault(HardenedLinux 社区的公司化主体)提供企业咨询,业务覆盖 private/air-gapped LLM inference、性能调优、hardened 推理栈——也就是把它当作一个可商业支持的 runtime 来做。
如果你的卡是 RTX 30 系或更新的 NVIDIA,手里有 GGUF 模型,值得花一个晚上把它跑起来。GitHub 仓库就在 hardenedlinux/SonicBoom。