DiffusionGemma funciona com llama.cpp? O status atual

A resposta curta: o llama.cpp padrão não consegue executar DiffusionGemma. O suporte existe no pull request #24423, que ainda não foi mesclado no momento em que este artigo foi escrito. Esse PR adiciona um novo binário dedicado chamado llama-diffusion-cli — executar o llama-cli padrão contra um GGUF do DiffusionGemma vai falhar com error loading model: unknown model architecture: 'diffusion-gemma'.

Por que DiffusionGemma precisa de um binário próprio

DiffusionGemma não é simplesmente um checkpoint Gemma 4 renomeado. Ele usa difusão de texto discreta: em vez de gerar token por token da esquerda para a direita, começa com um canvas de 256 tokens totalmente mascarado e refina o bloco inteiro através de denoising paralelo. Isso requer atenção bidirecional durante a geração, comportamento de sampling customizado em cada passo de denoising e um model runner fundamentalmente diferente — nada disso existe no caminho autorregressivo padrão do llama.cpp.

O PR #24423 implementa isso como um binário separado (llama-diffusion-cli) em vez de modificar o llama-cli existente. Até que esse PR seja mesclado no main, nenhum release oficial do llama.cpp vai incluí-lo.

O que é o PR #24423 e como usá-lo

O PR #24423 foi escrito por danielhanchen (o fundador do Unsloth) e adiciona a arquitetura diffusion-gemma ao código do llama.cpp. O PR está ativo desde o lançamento do DiffusionGemma em 10 de junho de 2026, e membros da comunidade publicaram binários pré-compilados não-oficiais para Linux/WSL2 CUDA e Windows CPU enquanto o PR aguarda.

Para compilar a partir do branch do PR:

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

# Buscar e fazer checkout do branch do PR
git fetch origin pull/24423/head:diffusion-gemma-pr
git checkout diffusion-gemma-pr

# Compilar (exemplo com CUDA)
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# O novo binário estará em:
./build/bin/llama-diffusion-cli

Para builds apenas com CPU, omitir o flag -DGGML_CUDA=ON.

Executando um modelo

Baixar um GGUF confiável do DiffusionGemma (o Unsloth publica os mais usados em unsloth/diffusiongemma-26B-A4B-it-GGUF no Hugging Face), então:

./build/bin/llama-diffusion-cli \
  -m ./diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
  -p "Explique a diferença entre geração de texto por difusão e autorregressiva." \
  --diffusion-steps 128

O parâmetro --diffusion-steps controla quantos passos de denoising o modelo executa. Mais passos = maior qualidade, geração mais lenta. Comece com 128 e ajuste.

Requisitos de memória

O modelo é baseado na arquitetura Gemma 4 26B A4B MoE, então os requisitos de memória são os mesmos:

• Q4_K_M: aproximadamente 14,4–18 GB (medição prática do Unsloth: 18 GB)
• Q8: aproximadamente 28 GB
• BF16: aproximadamente 52–58 GB

O modelo ativa apenas ~3,8B parâmetros por forward pass, apesar de ter 26B de parâmetros totais carregados na memória.

Velocidade: o que os números realmente significam

O Google afirma até 4x de velocidade de geração em comparação ao Gemma 4 padrão e mais de 1.000 tokens por segundo em uma única H100. Esses números são reais no hardware descrito. O que não dizem:

A vantagem de velocidade é condicional. A geração paralela do DiffusionGemma muda o perfil computacional de limitado por largura de banda de memória (característica de modelos autorregressivos) para limitado por capacidade de computação (característica de modelos de difusão). Em GPUs NVIDIA high-end com computação abundante — RTX 3090, 4090, A100, H100 — isso favorece o DiffusionGemma. Em GPUs de entrada (RTX 3060, 4060) e Apple Silicon, a diferença de computação se inverte e a vantagem de velocidade pode desaparecer completamente. Verifique benchmarks no seu hardware antes de esperar os números do headline.

A qualidade é menor. O Google afirma explicitamente que a qualidade geral da saída do DiffusionGemma é inferior ao Gemma 4 padrão. Isso não é uma limitação temporária — é o tradeoff fundamental entre velocidade e qualidade da abordagem de difusão.

Tabela comparativa de runtimes

Runtime	Status DiffusionGemma (junho 2026)
llama.cpp (main)	Não suportado. unknown model architecture: 'diffusion-gemma'
llama.cpp (PR #24423)	Suportado via llama-diffusion-cli. Deve ser compilado do branch do PR.
Unsloth Studio	Suportado desde v0.1.463-beta / 2026.6.6. Caminho local mais fácil.
Ollama	Não suportado. Issue #16664 aberta.
LM Studio	Não suportado. Runtime incluído não contém PR #24423.
vLLM	Totalmente suportado desde 10 de junho de 2026. Melhor para serving.
HF Transformers	Suportado via release oficial do Google.

Qual caminho usar

Se quer uma GUI local com configuração mínima: Use o Unsloth Studio. Suporta DiffusionGemma nativamente desde o release de 12 de junho e trata os parâmetros de inferência automaticamente.

Se está confortável com linha de comando: Compile o PR #24423 e use llama-diffusion-cli diretamente. Isso dá mais controle sobre os parâmetros de difusão.

Se usa ambiente Python: Use HuggingFace Transformers com os pesos oficiais google/diffusiongemma-26B-A4B-it.

Se precisa servir múltiplos usuários: O vLLM tem suporte nativo como o primeiro motor de inferência a integrar completamente o DiffusionGemma.

Se usa Ollama ou LM Studio padrão: Aguarde. Ambos dependem do mesmo PR subjacente e não há solução alternativa sem compilar binários personalizados.

Perguntas frequentes

Posso só atualizar o llama.cpp para a versão mais recente e obter suporte ao DiffusionGemma?
Não. PR #24423 não está mesclado no main. Atualizar pelo repositório oficial não adiciona suporte à arquitetura diffusion-gemma.

Há um binário llama-diffusion-cli pré-compilado para baixar?
Existem builds informais da comunidade para Linux/WSL2 CUDA (sm_86, RTX série 30) e Windows CPU. Pesquise "llama-diffusion-cli-prebuilt" no GitHub. Esses não são releases oficiais da Anthropic ou ggml-org.

DiffusionGemma produz saídas melhores que o Gemma 4 normal?
Não. O Google afirma explicitamente que a qualidade da saída é inferior ao Gemma 4 padrão. A vantagem é velocidade, especialmente para workflows de code infilling e edição inline onde o tradeoff de qualidade é aceitável.

Por que o Ollama falha mesmo sendo baseado no llama.cpp?
O Ollama inclui sua própria versão do llama.cpp que fica atrás do upstream. Mesmo atualizando o Ollama, o runtime incluído não contém PR #24423.

Guias relacionados:

• DiffusionGemma funciona no LM Studio?
• Corrigir unknown model architecture gemma4 no llama.cpp
• Gemma 4 A4B vs E4B: qual modelo usar