DiffusionGemma 能用 llama.cpp 运行吗？实际状态说明

简短答案：标准 llama.cpp 无法运行 DiffusionGemma。支持存在于 PR #24423 中，截至本文写作时该 PR 尚未合并。该 PR 引入了一个全新的专用二进制文件 llama-diffusion-cli——用标准的 llama-cli 加载 DiffusionGemma GGUF 会报错：error loading model: unknown model architecture: 'diffusion-gemma'。

为什么 DiffusionGemma 需要自己的二进制文件

DiffusionGemma 不只是重命名的 Gemma 4 检查点。它使用离散文本扩散：不是从左到右逐个 token 预测，而是从完全 mask 的 256-token 画布开始，通过并行去噪迭代整个块。这需要生成过程中的双向注意力机制、每个去噪步骤的自定义采样行为，以及与标准 llama.cpp 自回归路径根本不同的模型运行器——这些在标准 llama.cpp 中均不存在。

PR #24423 以独立二进制文件（llama-diffusion-cli）的形式实现了这些功能，而不是修改现有的 llama-cli。在该 PR 合并到主干之前，任何官方 llama.cpp 版本都不会包含它。

PR #24423 是什么，如何使用

PR #24423 由 danielhanchen（Unsloth 创始人）编写，为 llama.cpp 代码库添加了 diffusion-gemma 架构。该 PR 自 DiffusionGemma 于 2026 年 6 月 10 日发布以来一直活跃，社区成员已在 PR 待合并期间发布了 Linux/WSL2 CUDA 和 Windows CPU 的非官方预构建二进制文件。

从 PR 分支自行构建：

# 克隆 llama.cpp
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# 拉取并切换到 PR 分支
git fetch origin pull/24423/head:diffusion-gemma-pr
git checkout diffusion-gemma-pr

# 构建（CUDA 示例）
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# 新的二进制文件路径：
./build/bin/llama-diffusion-cli

仅 CPU 构建时，去掉 -DGGML_CUDA=ON 标志。

运行模型

从可信来源下载 DiffusionGemma GGUF（Unsloth 在 Hugging Face 上的 unsloth/diffusiongemma-26B-A4B-it-GGUF 是使用最广泛的），然后：

./build/bin/llama-diffusion-cli \
  -m ./diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
  -p "解释扩散式文本生成和自回归文本生成的区别。" \
  --diffusion-steps 128

--diffusion-steps 参数控制模型运行的去噪轮次。步数越多 = 质量越高，速度越慢。从 128 开始，按需调整。

内存需求

该模型基于 Gemma 4 26B A4B MoE 架构，内存需求相同：

• Q4_K_M：约 14.4–18 GB（Unsloth 实测约 18 GB）
• Q8：约 28 GB
• BF16：约 52–58 GB

尽管加载了全部 26B 参数，每次前向推理只激活约 3.8B。

速度：那些数字真正意味着什么

Google 声称比标准 Gemma 4 快最高 4 倍，在单张 H100 上每秒超过 1000 个 token。这些数字在其描述的硬件上是真实的。但它们没有告诉你的是：

速度优势是有条件的。 DiffusionGemma 的并行生成将计算特性从内存带宽受限（自回归模型的特点）转变为计算受限（扩散模型的特点）。在计算资源充裕的高端 NVIDIA GPU（RTX 3090、4090、A100、H100）上，这对 DiffusionGemma 有利。在低端 GPU（RTX 3060、4060）和 Apple Silicon 上，计算差距反转，速度优势可能完全消失。在期待那些标题数字之前，先在你的硬件上查找实际基准测试。

质量更低。 Google 明确声明 DiffusionGemma 的整体输出质量低于标准 Gemma 4。这不是临时限制——这是扩散方法速度-质量权衡的基本特征。

运行时对比

运行时	DiffusionGemma 状态（2026 年 6 月）
llama.cpp（主线）	不支持。报 unknown model architecture: 'diffusion-gemma'
llama.cpp（PR #24423）	通过 llama-diffusion-cli 支持。必须从 PR 分支构建。
Unsloth Studio	自 v0.1.463-beta / 2026.6.6 起支持。最简单的本地方案。
Ollama	不支持。Issue #16664 待解决。
LM Studio	不支持。捆绑的运行时不包含 PR #24423。
vLLM	自 2026 年 6 月 10 日起完全支持。最佳部署方案。
HF Transformers	通过官方 Google 版本支持。

推荐使用哪种方案

想要本地 GUI 且不想折腾： 使用 Unsloth Studio。它自 6 月 12 日发布起原生支持 DiffusionGemma，并自动处理推理参数。

习惯命令行： 从 PR #24423 构建，直接使用 llama-diffusion-cli。可以最灵活地控制扩散参数。

Python 环境用户： 使用 Hugging Face Transformers，配合官方 google/diffusiongemma-26B-A4B-it 权重。

需要多用户服务： vLLM 作为第一个完整支持 DiffusionGemma 的推理引擎，是最佳选择。

Ollama 或标准 LM Studio 用户： 等待。两者都受制于同一底层 PR，没有不构建自定义二进制文件的变通方案。

常见问题

直接更新最新版 llama.cpp 能获得 DiffusionGemma 支持吗？
不能。PR #24423 尚未合并到主线。从官方仓库更新不会添加 diffusion-gemma 架构支持。

有预构建的 llama-diffusion-cli 可以直接下载吗？
社区有 Linux/WSL2 CUDA（sm_86，RTX 30 系列）和 Windows CPU 的非官方预构建版本。在 GitHub 搜索 "llama-diffusion-cli-prebuilt"。这些不是 Anthropic 或 ggml-org 的官方版本。

DiffusionGemma 的输出比普通 Gemma 4 更好吗？
不。Google 明确表示输出质量低于标准 Gemma 4。优势是速度，尤其是对于能接受质量权衡的代码填充和内联编辑工作流。

为什么 Ollama 失败，即使它封装了 llama.cpp？
Ollama 捆绑了自己的 llama.cpp 版本，落后于上游。即使更新 Ollama，捆绑的运行时也不包含 PR #24423。

相关指南：

• DiffusionGemma 能在 LM Studio 中运行吗？
• 修复 llama.cpp 中的 unknown model architecture gemma4 错误
• Gemma 4 A4B 与 E4B：选择哪个模型运行