Executando o Google Gemma 4 localmente com o Headless CLI do LM Studio e o Claude Code

 (ai.georgeliu.com)
17 pontos por GN⁺ 23 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Gemma 4 usa uma arquitetura mixture-of-experts, ativando apenas parte dos parâmetros para oferecer inferência de alto desempenho mesmo em hardware mais modesto
  • LM Studio 0.4.0 introduz o novo Headless CLI (llmster), permitindo baixar, carregar, conversar com modelos e executar um servidor de API sem o app desktop
  • Por meio de uma API compatível com OpenAI e Anthropic, é possível servir o Gemma 4 como servidor local e usar o Claude Code como assistente de código totalmente offline
  • Ajustes finos de hardware, como comprimento de contexto, offloading para GPU e requisições paralelas, permitem equilibrar desempenho e eficiência de memória
  • A inferência local baseada em modelos MoE permite revisão rápida de código e testes de prompt sem custo de API, surgindo como tecnologia central para montar um ambiente de IA offline para desenvolvedores

Executando o Google Gemma 4 localmente — integração do novo Headless CLI do LM Studio com o Claude Code

  • Por que executar localmente

    • APIs de IA em nuvem têm limitações como custo, rate limits, privacidade e latência de rede
    • Para trabalhos iterativos rápidos, como revisão de código, rascunhos e testes de prompt, executar modelos localmente é vantajoso
    • A execução local oferece as vantagens de custo de API zero, nenhum envio de dados para fora e disponibilidade constante

    • O Gemma 4** usa uma arquitetura mixture-of-experts (MoE), na qual apenas 4B dos parâmetros de um modelo 26B são ativados**, permitindo alto desempenho mesmo em hardware mais modesto

      • Em um MacBook M4 Pro (48GB), foi registrada velocidade de 51 tokens por segundo; no Claude Code, fica um pouco mais lento

  • Família de modelos Gemma 4

    • O Google lançou o Gemma 4 em 4 famílias de modelos, otimizadas para diferentes hardwares
    • A série E (E2B, E4B) usa Per-Layer Embeddings e oferece suporte a entrada de áudio (reconhecimento de voz e tradução)
    • O modelo dense 31B alcança 85,2% no MMLU Pro e 89,2% no AIME 2026
    • O modelo 26B-A4B ativa apenas 8 de 128 especialistas (3,8B de parâmetros), operando com qualidade de nível 10B e custo de nível 4B
    • Com 82,6% no MMLU Pro, 88,3% no AIME e Elo 1441, ele se aproxima do modelo dense 31B e compete com modelos de 400B+
    • Suporte a contexto de 256K, entrada de visão, chamada de função e configuração de modo de raciocínio o torna adequado para inferência local

  • Principais mudanças no LM Studio 0.4.0

    • A introdução do mecanismo de inferência independente chamado llmster** permite execução completa via CLI sem o app desktop**

      • Com a CLI lms, é possível baixar modelos, carregá-los, conversar e executar o servidor
      • Principais recursos:
      • llmster daemon: gerencia carregamento de modelos e inferência em segundo plano
      • Processamento de requisições paralelas: lida com várias requisições simultâneas por meio de batching contínuo
      • Stateful REST API: mantém histórico de conversa pelo endpoint /v1/chat
      • Integração MCP: suporte local ao Model Context Protocol

  • Instalação e download do modelo

    • Comando de instalação: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • Executar o daemon: lms daemon up
    • Atualizar runtimes: lms runtime update llama.cpp, lms runtime update mlx
    • Baixar o modelo Gemma 4 26B: lms get google/gemma-4-26b-a4b
    • A quantização padrão é Q4_K_M (17.99GB)
    • Depois do download, carregue com lms load google/gemma-4-26b-a4b

  • Gerenciamento de modelos locais

    • Ver a lista de modelos instalados: lms ls
    • A saída de exemplo inclui Gemma 4, Qwen 3.5, GLM 4.7 Flash e vários outros modelos MoE
    • Modelos MoE permitem inferência eficiente usando apenas parte dos parâmetros ativos

  • Execução de conversa e desempenho

    • Iniciar conversa: lms chat google/gemma-4-26b-a4b --stats
    • Exemplo de saída: 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • Com 51 tok/sec e 1,5 s até a primeira resposta, a velocidade é suficiente para uso interativo

  • Verificando estado do modelo e memória

    • Ver os modelos carregados: lms ps
    • Exemplo: uso de 17.99GB de memória, contexto de 48K, 2 requisições paralelas e TTL de 1 hora
    • Principais itens visíveis na saída JSON (lms ps --json | jq):
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • Estimativa de memória conforme o comprimento de contexto

    • A opção --estimate-only permite prever o requisito de memória
    • O modelo base consome cerca de 17.6GiB, e a cada duplicação do contexto o uso cresce 3~4GiB
    • Em 48K de contexto, são necessários cerca de 21GiB; em 256K, 37.48GiB
    • Exemplo de comando: 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • A relação linear entre comprimento de contexto e memória é útil para planejar capacidade

  • Ajuste de carregamento por hardware

    • Comprimento de contexto

      • Defina dentro do limite de memória, descontando o uso do sistema operacional (4~6GB)
      • Ex.: lms load google/gemma-4-26b-a4b --context-length 128000

    • Offloading para GPU

      • Apple Silicon usa arquitetura de memória unificada, então --gpu=1.0 pode usar toda a GPU
      • Em sistemas NVIDIA, é possível dividir conforme o limite de VRAM, por exemplo com --gpu=0.5

    • Requisições paralelas

      • Várias requisições simultâneas são tratadas com batching contínuo
      • No GUI, ajuste Max Concurrent Predictions (padrão 4)
      • No caso do Gemma 4, em um sistema de 48GB, contexto de 48K e paralelismo 2 são adequados

    • Descarregamento automático por TTL

      • Com --ttl 1800, o modelo é descarregado automaticamente após 30 minutos de inatividade
      • O padrão é 1 hora, e 0 ou -1 desativam o recurso

    • Salvar valores padrão por modelo

      • No app desktop, em My Models → ícone de configurações, é possível salvar padrões de GPU, contexto e Flash Attention

    • Speculative Decoding

      • Em modelos MoE, é ineficiente; no Gemma 4, recomenda-se deixar desativado
      • Em testes com Mixtral, houve melhora de 39% em tarefas de código, mas queda de 54% em tarefas matemáticas

    • Flash Attention

      • Reduz o uso de memória do cache KV, permitindo contextos longos
      • Em Apple Silicon, ao ativar, há economia de memória

  • App desktop do LM Studio

    • No GUI, é possível visualizar status do servidor, carregamento de modelos, endpoints de API e stream de logs
    • Inclui protocolo compatível com Anthropic (POST /v1/messages)
    • O recurso de visão permite analisar imagens
    • Exemplo: ao analisar uma imagem do Timezone Scheduler, foram gerados 504 tokens a 54.51 tok/sec
    • Resultado do monitoramento do sistema:
      • Uso de memória: 46.69GB/48GB, swap 27.49GB
      • GPU em 90%, CPU a 91°C, GPU a 92°C
      • Consumo de energia de 23.56W (CPU 11.06W, GPU 13.32W)
    • A arquitetura de memória unificada elimina a necessidade de copiar dados entre CPU e GPU

  • Servindo o modelo como servidor de API

    • Iniciar servidor: lms server start
    • API compatível com OpenAI: http://localhost:1234/v1
    • Endpoint compatível com Anthropic: POST /v1/messages
    • Mudar a porta: --port 8080
    • O carregamento JIT do modelo faz carregamento automático na requisição e descarregamento automático após o TTL
    • Stream de logs em tempo real: lms log stream --source model --stats
    • Também é possível acessar a partir de outros dispositivos na rede, com suporte a autenticação por token de API

  • Integração com o Claude Code

    • Por meio do endpoint compatível com Anthropic, é possível executar o Claude Code com um modelo local
    • Adicione a função claude-lm ao ~/.zshrc: 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • Todas as chamadas de modelo do Claude Code (Opus, Sonnet, Haiku) são roteadas para o Gemma 4
    • Configuração de contexto de 48K, limite de saída de 8K tokens e ambiente somente local
    • Ao executar claude-lm, é possível usar um assistente de código totalmente offline
    • A velocidade é menor que na nuvem, mas é adequado para revisão de código, pequenas alterações e tarefas exploratórias

  • Principais aprendizados

    • Modelos MoE são centrais para a inferência local: o Gemma 4 26B-A4B entrega qualidade de nível 10B com custo de nível 4B
    • O daemon headless permite um workflow totalmente baseado em CLI
    • O comprimento de contexto é a principal variável de uso de memória
    • --estimate-only ajuda a evitar OOM
    • O endpoint compatível com Anthropic permite executar o Claude Code totalmente offline em ambiente local

  • Limitações

    • O lms chat não mostra diretamente o nome do modelo
    • O contexto padrão de 48K é conservador; se houver memória sobrando, recomenda-se expandir
    • A execução local do Claude Code não substitui completamente a API da Anthropic; há restrições para trabalhos maiores
    • Em sistemas de 48GB, há pressão de memória e uso de swap; recomenda-se 64GB ou mais

  • Próximos passos

    • Estão planejados testes comparativos com Qwen 3.5 35B, GLM 4.7 Flash e Nemotron 3 Nano
    • Resumo do procedimento: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get google/gemma-4-26b-a4b
lms chat google/gemma-4-26b-a4b --stats
    • Integração com Claude Code: adicione a função claude-lm e depois execute claude-lm
    • Pode ser usado para montar um workflow local de IA e integrá-lo a webapps e ambientes de desenvolvimento

Leituras relacionadas

1 comentários

 
GN⁺ 23 일 전
Comentários do Hacker News

  • É possível rodar um LLM localmente usando diretamente o llama.cpp server e aproveitá-lo no Claude Code ou em outros agentes de CLI
    Foi organizado um guia completo de configuração testando LLMs open-weight recentes, como o Gemma4, em um MacBook M1 Max 64GB
    O modelo 26BA4B foi o mais interessante nesse hardware e mostrou uma velocidade de geração de tokens (40 tok/s) quase duas vezes maior que a do Qwen3.5 35BA3B
    Mas os resultados no benchmark tau2 ficaram abaixo das variantes do Qwen (68% vs 81%), então é provável que não seja adequado para tarefas complexas centradas em ferramentas

    • Fico curioso se não houve problema de conflito de especificação entre Anthropic e OpenAI no Claude Code
      Estou usando mlx_vlm e vMLX, mas no Claude Code recebo erro 400 Bad Request
      Queria saber se no llama-server esse problema não aconteceu

  • Tenho a sensação de que os modelos locais já passaram do estágio de apenas “ser possível” e entraram numa fase de uso realmente confortável
    Especialmente o fluxo com LM Studio headless é impressionante. Ele permite usar inferência local em ferramentas reais
    Estou desenvolvendo um agente open source de programação via CLI chamado cloclo, que oferece suporte a vários backends, como LM Studio, Ollama, vLLM, Jan e llama.cpp
    Os modelos locais estão se aproximando de uma combinação ideal: uso diário pessoal e barato, enquanto os modelos em nuvem ficam para tarefas de alto desempenho

    • Fico curioso em que o cloclo difere do pi-mono

  • O ponto central aqui não é tanto o próprio Gemma 4, mas o fato de que o harness e o modelo ficaram totalmente separados
    Claude Code, OpenCode, Pi e Codex funcionam com qualquer backend
    Ou seja, os agentes de programação estão cada vez mais virando uma camada generalizada, e o foco da competição está migrando para qualidade e custo do modelo
    Isso é bom para os usuários e uma ameaça para empresas que dependiam do harness

    • Na verdade, penso o contrário. Os modelos é que estão sendo generalizados, e o harness e o tooling estão se tornando o principal fator de ganho real de desempenho
      Por exemplo, no texto “Improving 15 LLMs at Coding in One Afternoon”, foi dito que só trocar o harness já trouxe grande melhora
    • Na verdade, já era possível conectar o Claude Code ou o OpenCode diretamente a um endpoint HTTP local

  • Dá para executar de forma simples com o comando ollama launch claude --model gemma4:26b

    • Se você não aumentar o tamanho da context window, a função de chamada de ferramentas não funciona
    • Surpreende como isso funciona de forma tão simples se você tiver apenas ollama e claude instalados
    • Mas no meu caso não funcionou. O claude entra em loop infinito e não responde
      Nemotron, glm e qwen 3.5 funcionam bem, mas só o gemma deu problema

  • Essa abordagem também parece útil para automação de testes de software web
    Selenium e Puppeteer costumam quebrar facilmente quando o design da web muda um pouco
    Já esses modelos parecem conseguir se adaptar às mudanças, o que permitiria testes mais flexíveis
    Especialmente porque parece viável usá-los até com modelos pequenos

  • MoE na prática não economiza (V)RAM
    Todos os pesos precisam permanecer na memória, e apenas parte deles é usada em uma inferência
    Então o tok/s melhora, mas o uso de VRAM continua o mesmo

    • Eu também me confundi no começo. Os especialistas inativos pulam a computação, mas ainda ficam carregados na memória
      Esta visualização ajudou a entender
    • Em alguns motores de inferência, é possível descarregar parte dos especialistas para a RAM da CPU
      Por exemplo, dá para rodar um MoE de 35B parâmetros com uma combinação de GPU com 12GB de VRAM + 16GB de RAM
    • Não é necessário manter todos os pesos na memória ao mesmo tempo
      É possível fazer carregamento sob demanda por troca a partir de RAM, disco, rede etc.
      O MoE reduz a quantidade de dados que precisa ser trocada na próxima etapa de inferência

  • Estou usando o Claude Code como interface principal para iteração em pipelines de dados
    Em especial, para padronizar disclosures regulatórios governamentais (XBRL) e expô-los por REST e MCP
    O MCP é a parte mais interessante: em vez de chamar o cliente diretamente, você define ferramentas de forma declarativa e o modelo decide quando chamá-las
    Por exemplo, uma consulta como “compare a tendência de alavancagem desta empresa ao longo de 10 anos com a média do setor” é automaticamente decomposta na sequência adequada de chamadas de ferramenta
    Porém, no uso interativo com MCP, a latência é muito mais sensível
    Uma resposta em 2 segundos é aceitável em um script, mas quebra o fluxo da conversa
    Então passei a manter em cache as tabelas mais usadas na memória e consegui respostas abaixo de 100ms
    Fico curioso se outras pessoas também passaram por esse tipo de limiar de latência

    • Eu também acho o MCP útil, mas o consumo de tokens pode crescer bastante
      Em implementações simples, ele consome dezenas de milhares de tokens a mais para a mesma funcionalidade
      Existe um texto explicativo da Anthropic, mas o material já está um pouco desatualizado
    • Na minha experiência, 300~500ms por chamada de ferramenta é o limite superior natural
      Acima disso, cadeias de múltiplas etapas ficam lentas, e o modelo começa a adicionar raciocínio desnecessário, inflando o contexto
      Além do cache, também funcionou bem uma estratégia para reduzir o número de chamadas de ida e volta, retornando vários dados de uma vez

  • Foi compartilhado como configurar o Gemma 4 26B no macOS como inferência local para o Claude Code

    • Acho que foi uma ótima organização do conteúdo

  • Talvez no futuro os principais laboratórios de IA passem a operar LLMs locais em paralelo para reduzir a carga da nuvem, deixando apenas os cálculos pesados para a nuvem

    • Mas fico em dúvida se isso não entraria em conflito com o modelo de negócio deles

  • Fico curioso sobre quão bem o modelo Gemma 4 funciona em tarefas de programação orientadas a agentes e qual é a impressão prática de uso