DiffusionGemma funciona no LM Studio? Status atual (junho 2026)

Não, DiffusionGemma não funciona no LM Studio agora. Não é um problema de configuração nem de arquivo. Os runtimes incluídos no LM Studio — tanto o engine llama.cpp quanto o engine MLX para Apple Silicon — não suportam a arquitetura diffusion-gemma. Dois bug reports confirmados no GitHub rastreiam isso.

O que acontece de verdade quando você tenta

No Apple Silicon (caminho MLX)

Quando você tenta carregar DiffusionGemma pelo engine MLX do LM Studio (versão 1.8.5):

Failed to load model.
Error when loading model: ValueError: Model type diffusion_gemma not supported.
Error: No module named 'mlx_vlm.speculative.drafters.diffusion_gemma'

Isso ocorre porque o LM Studio inclui mlx-vlm 0.4.5 (uma build de desenvolvimento de abril de 2026). DiffusionGemma requer mlx-vlm 0.6.3 ou mais recente. Você não pode corrigir isso atualizando os engines do LM Studio dentro do app — a versão da biblioteca incluída é o que é até o LM Studio publicar uma atualização.

Rastreado em: lmstudio-bug-tracker #2037

No Windows / Linux (caminho llama.cpp)

O engine llama.cpp do LM Studio (Metal llama.cpp v2.21.0 ou similar) falha com:

error loading model: unknown model architecture: 'diffusion-gemma'

Isso porque o suporte ao DiffusionGemma no llama.cpp está no PR #24423, que não está mesclado. O LM Studio inclui uma versão de release do llama.cpp, portanto não contém o PR.

Rastreado em: lmstudio-ai/lms #583

Quando o LM Studio vai suportar DiffusionGemma?

O suporte do LM Studio depende de duas coisas serem mescladas no upstream:

1. PR #24423 ser mesclado no llama.cpp main (para o caminho llama.cpp)
2. mlx-vlm 0.6.3+ ser incluído (para o caminho MLX da Apple)

Nenhum dos dois aconteceu ainda. O LM Studio precisaria publicar um novo release após ambos. Realisticamente isso leva semanas, não dias.

O que realmente funciona agora

Runtime	Suporte ao DiffusionGemma	Observação
Unsloth Studio	Sim	Caminho local mais fácil. Funciona em macOS/Windows/Linux. Suportado desde 12 de junho de 2026 (v0.1.463-beta).
vLLM	Sim	Melhor para serving. Suporte nativo desde 10 de junho de 2026. Requer Linux + GPU NVIDIA.
HF Transformers	Sim	Apenas Python. Pesos oficiais do Google em google/diffusiongemma-26B-A4B-it.
llama.cpp (PR #24423)	Sim	Apenas CLI. Deve ser compilado do branch do PR. Usa llama-diffusion-cli, não llama-cli.
LM Studio	Não	Tanto engine MLX quanto llama.cpp falham.
Ollama	Não	Issue #16664 aberta.

Caminho recomendado por tipo de uso

Quer uma GUI desktop: Unsloth Studio é atualmente a única GUI local funcionando. Após instalar, busque DiffusionGemma no gerenciador de modelos.

Usuário de Apple Silicon: Unsloth Studio suporta macOS. O caminho MLX no LM Studio ainda não funciona.

Confortável com linha de comando: Compilar llama.cpp do PR #24423 e usar llama-diffusion-cli diretamente. Oferece mais controle sobre o número de passos de difusão e outros parâmetros.

Desenvolvedor Python que quer experimentar rapidamente: HuggingFace Transformers com os pesos oficiais google/diffusiongemma-26B-A4B-it.

Precisa servir DiffusionGemma para múltiplos usuários: vLLM tem suporte nativo e benchmarks publicados.

Usuário do Ollama: Aguarde. Não há solução alternativa sem compilar binários customizados.

Antes de usar DiffusionGemma: o que saber

DiffusionGemma tem vantagens reais de velocidade no ambiente certo. Em NVIDIA RTX 3090/4090 e cards superiores, com baixa concorrência, a geração pode ser várias vezes mais rápida que o Gemma 4 autorregressivo padrão. Em GPUs NVIDIA de entrada (3060, 4060) e Apple Silicon, a vantagem de velocidade pode não aparecer. O modelo transfere a inferência de limitado por largura de banda de memória (onde o Apple Silicon se destaca) para limitado por capacidade de computação (onde GPUs NVIDIA dedicadas de alta gama se destacam).

Mais importante: o Google afirma explicitamente que a qualidade de saída do DiffusionGemma é inferior ao Gemma 4 padrão. Não é uma limitação temporária. O tradeoff velocidade-qualidade é uma característica fundamental da abordagem de difusão. Se você precisa de qualidade máxima, o Gemma 4 padrão é o modelo certo.

DiffusionGemma é mais adequado para:

• Code infilling (preencher o meio de código existente)
• Edição inline com contexto anterior e posterior
• Aplicações locais interativas onde latência importa e alguma redução de qualidade é aceitável

Menos adequado para:

• Tarefas que requerem máxima precisão factual
• Raciocínio complexo de múltiplas etapas onde precisão acumula
• Qualquer caso de uso onde você compararia saídas criticamente ao Gemma 4 padrão

Perguntas frequentes

Atualizar o LM Studio resolve isso?
Não, até o LM Studio publicar um release com mlx-vlm 0.6.3+ (para Apple) ou uma nova versão do llama.cpp incluindo PR #24423 (para outros). Nenhum release atual faz isso.

Posso apontar o LM Studio para um runtime customizado?
O LM Studio atualmente não suporta trocar o binário llama.cpp por um customizado. O runtime incluído é o que você obtém.

O Gemma 4 padrão ainda funciona no LM Studio?
Sim. A arquitetura gemma4 é suportada nos releases atuais do LM Studio. A limitação é específica do diffusion-gemma.

Quanto tempo vai demorar para isso ser resolvido?
Difícil prever. Depende do PR #24423 ser mesclado no llama.cpp, do LM Studio publicar uma atualização com a nova versão do llama.cpp, e da equipe MLX lançar e o LM Studio incluir um mlx-vlm mais recente. Semanas é a estimativa mais realista.

Guias relacionados:

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