为什么一个模型能跑出四倍速，错误也翻了六倍，还能在Reddit的本地大模型板块引发273票的热议？DiffusionGemma无疑是2026年最受关注的图像生成模型，但你是不是也发现，一旦离开HuggingFace的示例笔记本，想在自己的环境里把它真正用起来，故事就完全不一样了。

现在是2026年7月，各大平台的真实状态到底如何？我们花了一天时间，把所有方案从头到尾跑了一遍，结论很直接：有一条代码合并请求卡住了所有的路。

这条请求就是llama.cpp项目中的#24423号合并请求。毫不夸张地说，Ollama、LM Studio、原生的GGUF支持，全都系在它身上。这个请求从6月10日开启，最初是开发者danielhanchen的概念验证，现在冲突已经解决，技术上已经可以合并。但卡住它的不是代码，而是设计方向——一位核心维护者希望做一个通用的扩散模型服务器，而不是专门针对某个模型去实现。于是，什么时候能合入主分支，到现在还没有明确的时间表。

在这种情况下，今天到底有哪些方案是真正能用的？首选是vLLM。来自vLLM团队的第一天支持就让单卡跑通变得十分简单，一行安装命令，一行服务启动，单GPU直接出图。多GPU支持曾经是痛点，直到6月26日第#46177号请求合入，张量并行功能进入主分支，才彻底解决。只需在启动命令里加上张量并行参数，比如设置成2，就可以利用两张卡来分摊模型。安装和启动过程极其直白：pip安装最新版vLLM，然后用vllm serve指向RedHatAI/diffusiongemma-26B-A4B模型，再加—tensor-parallel-size 2，一切搞定。

如果你熟悉llama.cpp，也可以选择从合并请求的分支自己编译。主分支目前还没有这些代码，需要手动拉取#24423请求对应的分支，并在编译时启用CUDA支持。步骤略繁琐：先克隆llama.cpp仓库，再抓取编号为24423的请求代码，切到那个分支，用cmake构建并加上-DGGML_CUDA=ON参数，然后编译。HuggingFace上已经可以找到Q4_K_M量化的GGUF文件，功能是跑得通的。但请记住，从编译到调试，任何坑都只能自己踩——在它成功并入主分支之前，没有任何人能保证稳定性。

至于Ollama，也许是大家最关心的问题。目前还没有原生的ollama pull diffusiongemma命令。可行的桥接方式是：用前面编译好的llama.cpp分支生成GGUF文件，再编写一个自定义的Modelfile指向这个文件，通过Ollama的导入机制把它挂上去。整个过程能跑，但非常绕，每一步都写在了diffrun.dev/ollama上。

哪些路在今天还走不通？LM Studio直接受阻于#24423未合并，因为引擎整合必须等llama.cpp主分支到位。vLLM那边，GGUF格式的支持也有问题；第#46454号请求虽然已经可以合并，修复了DiffusionGemma在GGUF中绑定词表加载的问题，但至今还没合入，所以目前最好还是老老实实用BF16的权重。还有一个nvfp4量化的话题：vLLM的nvfp4混合专家内核直接拒绝了DiffusionGemma的专家中间层尺寸，因为那个尺寸不是128的整数倍。这是一个独立的问题，有专门的跟踪记录，暂时无解。

现在的局面对所有关注者来说，信号非常清晰：只要#24423请求一合入，多米诺骨牌就会立刻倒下。Ollama在几天内就会发布引擎更新，LM Studio紧随其后，原生GGUF转换也会出现在llama.cpp主分支之中。“diffusiongemma ollama”和“diffusiongemma lm studio”的搜索量会在一夜之间飙升。所有这些合并请求的进展，我们每天都会在diffrun.dev/status上追踪，每个平台的详细踩坑手册则整理在diffrun.dev，随时可查。