当扩散模型遇上 llama.cpp：stable-diffusion.cpp 把 30+ 图像视频模型压进一个 C 文件

你想在 MacBook 上跑 Stable Diffusion。官方方案是 Python + PyTorch + 一堆 CUDA 依赖，装完环境已经过去了两小时。你的 Mac 风扇开始狂转，内存占用 8GB 起步。你开始怀疑：生成一张图真的需要这么重吗？

leejet/stable-diffusion.cpp 给了一个干脆的答案：不需要。一个 C/C++ 文件，没有外部依赖，CPU 也能跑，CUDA、Vulkan、Metal、OpenCL、SYCL 全支持。今天它在 GitHub Trending 上又涨了 69 颗星——对一个已经存在两年的项目来说，这种持续的生命力比爆发更值得注意。

llama.cpp 的扩散模型版

如果你用过 llama.cpp，stable-diffusion.cpp 的哲学你一眼就能认出来：

• 基于 ggml（同一个底层张量库）
• 纯 C/C++ 实现，零外部依赖
• 编译出来就是一个可执行文件，不需要 Python 环境
• 支持 GGUF 量化格式
• CPU/CUDA/Vulkan/Metal/OpenCL/SYCL 全后端覆盖
• 跨平台：Linux、macOS、Windows、Android（通过 Termux）

llama.cpp 证明了这条路对 LLM 行得通。现在 stable-diffusion.cpp 证明它对扩散模型也行得通。

30+ 模型：Day-0 支持的含金量

这个项目最惊人的不是技术本身，而是模型覆盖速度。看一眼支持列表：

图像模型：SD1.x/2.x、SDXL、SD3/SD3.5、FLUX.1、FLUX.2、Qwen-Image、Qwen-Image-2.1、Z-Image、PiD、Lens、Chroma、Chroma1-Radiance、LongCat Image、MiniT2I、SenseNova U1.5、Ovis-Image、Anima、ERNIE-Image、Boogu Image、Krea2、Mage-Flow、SeFi-Image、HiDream-O1-Image、Ideogram4、LLaDA-Image

图像编辑模型：FLUX.1-Kontext、Qwen Image Edit、LongCat Image Edit、Boogu Image Edit、Mage-Flow-Edit、LLaDA-Image Edit

视频模型：Wan2.1/2.2、MiniMax-H3、LTX-2.3/2.5、HunyuanVideo 1.5、LingBot-Video

注意时间线：2026/09/20 支持 Qwen-Image-2.1，2026/08/20 支持 LTX-2.5，2026/08/04 支持 MiniMax-H3。这些是"Day-0 支持"——模型发布当天或第二天就能跑。

这意味着什么？新模型发布的第一天，你不需要等 ComfyUI 更新、不需要等 diffusers 库适配、不需要装 Python 环境——下载个二进制文件就能跑。对于想第一时间试新模型的开发者来说，这是最短的路径。

为什么 C/C++ 仍然有意义

在 Python 统治 AI 的时代，为什么纯 C/C++ 实现还有价值？

第一，部署体积。Python + PyTorch + diffusers + transformers 的最小部署也要几个 GB。stable-diffusion.cpp 编译出来是一个几十 MB 的二进制文件。对于边缘设备、嵌入式系统、移动端，这个差距是决定性的。

第二，启动速度。Python 环境的冷启动需要几秒到几十秒（加载 PyTorch、初始化 CUDA）。C/C++ 二进制的冷启动是毫秒级。对于需要快速响应的在线服务，这是用户体验的关键。

第三，后端灵活性。Python 生态的推理框架通常绑死 CUDA。stable-diffusion.cpp 支持 CPU（AVX/AVX2/AVX512）、CUDA、Vulkan、Metal、OpenCL、SYCL——同一个二进制文件，在不同硬件上自动选择最佳后端。Vulkan 支持意味着 AMD/Intel GPU 也能用，Metal 支持意味着 Mac 的 Apple Silicon 能用。

第四，跨平台可复现性。--rng cuda 和 --rng cpu 选项让你能精确控制随机数生成，跨平台得到一致的结果。这在 Python 生态里是个老大难问题——不同硬件、不同 CUDA 版本，同样的 seed 可能生成不同的图。

GGUF：模型也能量化

stable-diffusion.cpp 支持 GGUF 格式——这是 llama.cpp 生态的量化模型格式。意味着你可以把 FLUX.1 或 SDXL 量化到 Q4/Q8，在显存有限的设备上跑。

对于 8GB 显存的笔记本，想跑 FLUX.1（原始 12B 参数，FP16 需要 24GB 显存），GGUF Q4 量化后只需要约 6GB。这在 Python 生态里需要 bitsandbytes + accelerate + 一堆配置，在 stable-diffusion.cpp 里就是一个参数。

生态：绑定和 UI

围绕 stable-diffusion.cpp 已经长出了一个小生态：

语言绑定：Go（cgo 和 non-cgo 两个版本）、C#、Python、Rust、Flutter/Dart。这意味着你可以在任何语言里调用它。

UI 前端：GIMP 插件、Jellybox、Stable Diffusion GUI、Stable Diffusion CLI-GUI、Local Diffusion（Android）。这些项目把 stable-diffusion.cpp 当后端，提供图形界面。

这个生态虽然比不上 ComfyUI 或 AUTOMATIC1111 的规模，但它的定位不同——它不是给设计师用的，是给开发者嵌入到自己系统里用的。

和 llama.cpp 的命运分岔

有意思的是，llama.cpp 成了 LLM 推理的事实标准之一，被 Ollama、LM Studio 等大量产品采用。但 stable-diffusion.cpp 没有达到同样的地位。

原因可能是：LLM 推理的瓶颈在内存和速度，扩散模型推理的瓶颈在质量。

LLM 推理时，你不在乎 logits 的精度差了 0.01——输出文本质量几乎不变。所以量化到 Q4 没问题，速度优先。

但扩散模型推理时，每一步去噪的精度直接影响最终图像质量。量化到 Q4 可能出现色偏、伪影、细节丢失。用户对图像质量的敏感度远高于对文本质量的敏感度——你一眼能看出图糊了，但不太能感觉出 logits 差了 0.01。

所以 stable-diffusion.cpp 的核心用户群不是追求最快推理的人，而是追求最小部署体积 + 最大模型覆盖的人。在边缘设备、移动端、跨平台场景里，它的价值无可替代。

一个更深的观察

stable-diffusion.cpp 和 llama.cpp 代表了一种被低估的工程哲学：把复杂系统简化到极致。

Python 生态的推理框架越来越复杂——依赖链越来越长、配置项越来越多、版本冲突越来越频繁。一个 ComfyUI 的完整环境可能有上百个依赖包，任何一个包更新都可能 break 整个系统。

C/C++ 的方案反其道而行：一个二进制文件，一个模型文件，一条命令生成。没有依赖地狱，没有版本冲突，没有环境隔离。这种简单性在 AI 工程化的下一阶段——从研究到部署、从云端到边缘——会越来越有价值。

当模型规模从 7B 涨到 70B 再到 700B，当部署场景从数据中心扩展到手机和手表，"最简单的方案"往往会赢。不是因为它最强，而是因为它最可靠。

项目链接：leejet/stable-diffusion.cpp 后端：CPU / CUDA / Vulkan / Metal / OpenCL / SYCL License：MIT 安装：从 releases 页面 下载预编译二进制