Cómo ejecutar Google Gemma 4 localmente con LM Studio Headless CLI y Claude Code

 (ai.georgeliu.com)
17 puntos por GN⁺ 23 일 전 | 1 comentarios | Compartir por WhatsApp
  • Gemma 4 usa una arquitectura de mixture-of-experts que activa solo parte de sus parámetros, lo que permite inferencia de alto rendimiento incluso en hardware modesto
  • LM Studio 0.4.0 introduce el nuevo Headless CLI (llmster), con el que es posible descargar, cargar modelos, chatear y ejecutar un servidor API sin la app de escritorio
  • Mediante una API compatible con OpenAI y Anthropic, se puede ofrecer Gemma 4 como servidor local y usar Claude Code como asistente de código completamente offline
  • Con ajustes finos de hardware como longitud de contexto, offloading a GPU y solicitudes en paralelo, se puede optimizar el rendimiento y la eficiencia de memoria
  • La inferencia local basada en modelos MoE permite revisiones de código rápidas y pruebas de prompts sin costo de API, y está emergiendo como una tecnología clave para construir entornos de IA offline para desarrolladores

Ejecutar Google Gemma 4 localmente — integración del nuevo Headless CLI de LM Studio con Claude Code

  • Por qué ejecutar en local

    • Las API de IA en la nube tienen limitaciones de costo, límites de velocidad, privacidad y latencia de red
    • Para tareas iterativas rápidas como revisión de código, redacción de borradores y pruebas de prompts, ejecutar modelos localmente es más conveniente
    • La ejecución local ofrece ventajas como costo de API cero, sin transferencia de datos al exterior y disponibilidad permanente

    • Gemma 4** usa una arquitectura mixture-of-experts (MoE) en la que, dentro de un modelo de 26B, solo se activan 4B parámetros**, lo que permite alto rendimiento incluso en hardware modesto

      • En una MacBook M4 Pro (48GB) registró una velocidad de 51 tokens por segundo, aunque dentro de Claude Code se vuelve algo más lento

  • Familia de modelos Gemma 4

    • Google publicó 4 familias de modelos de Gemma 4, optimizadas para distintos tipos de hardware
    • La serie E (E2B, E4B) usa Per-Layer Embeddings y soporta entrada de audio (reconocimiento de voz y traducción)
    • El modelo dense de 31B alcanza 85.2% en MMLU Pro y 89.2% en AIME 2026
    • El modelo 26B-A4B activa solo 8 de 128 expertos (3.8B parámetros), por lo que opera con calidad de nivel 10B a costo de nivel 4B
    • Con 82.6% en MMLU Pro, 88.3% en AIME y Elo 1441, se acerca al modelo dense de 31B y compite con modelos de más de 400B
    • Soporta contexto de 256K, entrada visual, llamadas a funciones y configuración del modo de razonamiento, por lo que resulta adecuado para inferencia local

  • Cambios principales en LM Studio 0.4.0

    • Con la introducción de llmster como motor de inferencia independiente, ahora puede ejecutarse completamente desde CLI sin la app de escritorio

      • Con la CLI lms se puede descargar modelos, cargarlos, chatear y levantar el servidor
      • Funciones principales:
      • llmster daemon: carga modelos y gestiona la inferencia en segundo plano
      • Procesamiento de solicitudes en paralelo: maneja múltiples solicitudes simultáneamente con continuous batching
      • Stateful REST API: mantiene el historial de conversación mediante el endpoint /v1/chat
      • Integración MCP: soporte local para Model Context Protocol

  • Instalación y descarga del modelo

    • Comando de instalación: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • Iniciar el daemon: lms daemon up
    • Actualizar runtime: lms runtime update llama.cpp, lms runtime update mlx
    • Descargar el modelo Gemma 4 26B: lms get google/gemma-4-26b-a4b
    • La cuantización predeterminada es Q4_K_M (17.99GB)
    • Después de la descarga, cargarlo con lms load google/gemma-4-26b-a4b

  • Gestión de modelos locales

    • Ver la lista de modelos instalados: lms ls
    • La salida de ejemplo incluye Gemma 4, Qwen 3.5, GLM 4.7 Flash y varios modelos MoE
    • Los modelos MoE permiten inferencia eficiente porque usan solo una parte de los parámetros activos

  • Ejecución del chat y rendimiento

    • Iniciar conversación: lms chat google/gemma-4-26b-a4b --stats
    • Ejemplo de salida: 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • Con 51 tok/sec y 1.5 s de respuesta inicial, la velocidad es suficiente para uso interactivo

  • Estado del modelo y memoria

    • Ver modelos cargados: lms ps
    • Ejemplo: uso de 17.99GB de memoria, contexto de 48K, 2 solicitudes en paralelo y TTL de 1 hora
    • Elementos principales visibles en la salida JSON (lms ps --json | jq):
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • Estimación de memoria según la longitud de contexto

    • La opción --estimate-only permite predecir los requisitos de memoria
    • El modelo base requiere alrededor de 17.6GiB, y cada vez que el contexto se duplica aumenta entre 3 y 4GiB
    • Con un contexto de 48K se necesitan unos 21GiB, y con 256K unos 37.48GiB
    • Ejemplo de comando: 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • La relación lineal entre longitud de contexto y memoria es útil para planificar capacidad

  • Ajuste de carga según el hardware

    • Longitud de contexto

      • Debe configurarse dentro del límite de memoria disponible, descontando el uso del sistema operativo (4~6GB)
      • Ejemplo: lms load google/gemma-4-26b-a4b --context-length 128000

    • Offloading a GPU

      • Apple Silicon usa arquitectura de memoria unificada, por lo que puede aprovechar toda la GPU con --gpu=1.0
      • En sistemas NVIDIA, puede dividirse según el límite de VRAM con valores como --gpu=0.5

    • Solicitudes en paralelo

      • Permite manejar varias solicitudes al mismo tiempo con continuous batching
      • En la GUI se configura con Max Concurrent Predictions (predeterminado: 4)
      • En el caso de Gemma 4, en un sistema de 48GB son adecuados 48K de contexto y 2 solicitudes en paralelo

    • Descarga automática por TTL

      • Con --ttl 1800 se libera automáticamente tras 30 minutos de inactividad
      • El valor predeterminado es 1 hora, y puede desactivarse con 0 o -1

    • Guardar valores predeterminados por modelo

      • En la app de escritorio, desde My Models → icono de configuración, se pueden guardar por defecto GPU, contexto y Flash Attention

    • Decodificación especulativa (Speculative Decoding)

      • En modelos MoE es ineficiente, por lo que se recomienda desactivarla en Gemma 4
      • En pruebas con Mixtral, mejoró 39% en tareas de código, pero empeoró 54% en tareas matemáticas

    • Flash Attention

      • Ayuda a soportar contextos largos al reducir la memoria del caché KV
      • Al activarlo en Apple Silicon, aporta ahorro de memoria

  • App de escritorio de LM Studio

    • La GUI permite visualizar estado del servidor, carga de modelos, endpoints API y flujo de logs
    • Incluye el protocolo Anthropic (POST /v1/messages)
    • La función de visión permite analizar imágenes
    • Ejemplo: al analizar una imagen de Timezone Scheduler, generó 504 tokens a 54.51 tok/sec
    • Resultados del monitoreo del sistema:
      • Uso de memoria 46.69GB/48GB, swap 27.49GB
      • GPU al 90%, CPU a 91°C, GPU a 92°C
      • Consumo de energía 23.56W (CPU 11.06W, GPU 13.32W)
    • La arquitectura de memoria unificada evita la copia de datos entre CPU y GPU

  • Ofrecer el modelo como servidor API

    • Iniciar el servidor: lms server start
    • API compatible con OpenAI: http://localhost:1234/v1
    • Endpoint compatible con Anthropic: POST /v1/messages
    • Cambiar puerto: --port 8080
    • Con carga JIT del modelo, se carga automáticamente al recibir solicitudes y se descarga al vencer el TTL
    • Flujo de logs en tiempo real: lms log stream --source model --stats
    • También se puede acceder desde otros dispositivos de la red y soporta autenticación con token API

  • Integración con Claude Code

    • Mediante el endpoint compatible con Anthropic, Claude Code puede ejecutarse con un modelo local
    • Agregar la función claude-lm a ~/.zshrc: 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • Todas las llamadas de modelos de Claude Code (Opus, Sonnet, Haiku) se redirigen a Gemma 4
    • Se configura un entorno solo local con 48K de contexto y límite de salida de 8K tokens
    • Al ejecutar claude-lm, se puede usar un asistente de código totalmente offline
    • Aunque es más lento que la nube, resulta adecuado para revisión de código, cambios pequeños y trabajo exploratorio

  • Lecciones principales

    • Los modelos MoE son clave para la inferencia local: Gemma 4 26B-A4B ofrece calidad de nivel 10B a costo de nivel 4B
    • El daemon headless permite un flujo de trabajo completamente basado en CLI
    • La longitud de contexto es la principal variable del uso de memoria
    • --estimate-only ayuda a evitar OOM
    • El endpoint compatible con Anthropic permite ejecutar Claude Code localmente y completamente offline

  • Limitaciones

    • lms chat no muestra directamente el nombre del modelo
    • El contexto predeterminado de 48K es conservador, y conviene ampliarlo si hay margen de memoria
    • La ejecución local de Claude Code no reemplaza por completo la API de Anthropic, y tiene limitaciones para trabajos grandes
    • En sistemas de 48GB puede haber presión de memoria y uso de swap; se recomiendan 64GB o más

  • Siguientes pasos

    • Se planean pruebas comparativas con Qwen 3.5 35B, GLM 4.7 Flash y Nemotron 3 Nano
    • Resumen del procedimiento: 
      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
    • Para integrar Claude Code: agregar la función claude-lm y luego ejecutar claude-lm
    • Puede usarse para construir flujos de trabajo locales de IA e integrarlos en webapps y entornos para desarrolladores

Lecturas relacionadas

1 comentarios

 
GN⁺ 23 일 전
Comentarios de Hacker News

  • Se puede usar directamente llama.cpp server para ejecutar un LLM localmente y aprovecharlo desde Claude Code u otros agentes CLI
    Se resumió una guía completa de configuración en la que se probaron LLM abiertos recientes como Gemma4 en una MacBook M1 Max 64GB
    El modelo 26BA4B fue el más interesante en ese hardware y mostró una velocidad de generación de tokens (40 tok/s) casi el doble de rápida que Qwen3.5 35BA3B
    Sin embargo, el resultado en el benchmark tau2 fue menor que el de las variantes de Qwen (68% vs 81%), así que se espera que no sea adecuado para tareas complejas centradas en herramientas

    • Me pregunto si no hubo problemas de conflicto de especificaciones entre Anthropic y OpenAI en Claude Code
      Yo uso mlx_vlm y vMLX, pero en Claude Code me aparece un error 400 Bad Request
      Quisiera saber si en llama-server no hubo ese problema

  • Siento que los modelos locales ya pasaron de ser simplemente “posibles” a entrar en una etapa en la que se pueden usar cómodamente
    En especial, el flujo de LM Studio sin interfaz me pareció impresionante. Permite usar inferencia local en herramientas reales
    Estoy desarrollando un agente de programación CLI de código abierto llamado cloclo, que soporta varios backends como LM Studio, Ollama, vLLM, Jan y llama.cpp
    Los modelos locales se están acercando a una combinación ideal: uso diario personal y barato, y modelos en la nube para tareas de alto rendimiento

    • Me pregunto en qué se diferencia cloclo de pi-mono

  • El punto clave aquí no es tanto Gemma 4 en sí, sino que el harness y el modelo quedaron completamente separados
    Claude Code, OpenCode, Pi y Codex funcionan con cualquier backend
    Es decir, los agentes de programación se están volviendo una capa generalizada, y el foco de la competencia se está moviendo hacia la calidad y el costo del modelo
    Eso es bueno para los usuarios y una amenaza para las empresas que dependían del harness

    • Más bien creo lo contrario. Lo que se está generalizando son los modelos, y el verdadero motor de mejora del rendimiento está en el harness y el tooling
      Por ejemplo, en el artículo “Improving 15 LLMs at Coding in One Afternoon” también se decía que con solo cambiar el harness hubo una gran mejora
    • En realidad, ya se podía conectar Claude Code u OpenCode directamente a un endpoint HTTP local

  • Se puede ejecutar fácilmente con el comando ollama launch claude --model gemma4:26b

    • Si no se aumenta el tamaño de la context window, la función de llamada de herramientas no funciona
    • Sorprende lo simple que funciona esto con solo tener instalados ollama y claude
    • Pero en mi caso no funcionó. claude entra en un bucle infinito y no responde
      Nemotron, glm y qwen 3.5 funcionan bien, pero solo gemma daba problemas

  • Parece que este enfoque también podría ser útil para la automatización de pruebas de software web
    Selenium o Puppeteer tienden a romperse fácilmente cuando cambia un poco el diseño web
    En cambio, modelos como estos podrían adaptarse a los cambios y permitir pruebas más flexibles
    En especial, parece que incluso los modelos pequeños serían suficientes

  • MoE en realidad no ahorra (V)RAM
    Todos los pesos deben residir en memoria, y solo se usa una parte en cada inferencia
    Por eso mejora el tok/s, pero el uso de VRAM sigue igual

    • Yo también me confundí al principio. Los expertos inactivos se saltan en el cómputo, pero siguen cargados en memoria
      Esta visualización me ayudó a entenderlo
    • En algunos motores de inferencia, parte de los expertos puede descargarse a la RAM del CPU
      Por ejemplo, se puede ejecutar un MoE de 35B parámetros con una combinación de GPU de 12GB VRAM + 16GB RAM
    • No hace falta tener todos los pesos en memoria al mismo tiempo
      Se pueden cargar e intercambiar solo las partes necesarias desde RAM, disco o red
      MoE reduce la cantidad de datos que hay que intercambiar en la siguiente etapa de inferencia

  • Estoy usando Claude Code como la interfaz principal para tareas repetitivas de un pipeline de datos
    En particular, para estandarizar divulgaciones regulatorias del gobierno (XBRL) y exponerlas por REST y MCP
    MCP es la parte interesante: en vez de invocar directamente al cliente, se definen herramientas de forma declarativa y el modelo decide cuándo llamarlas
    Por ejemplo, una consulta como “comparar la tendencia de apalancamiento de esta empresa durante 10 años con el promedio del sector” se descompone automáticamente en la secuencia adecuada de llamadas a herramientas
    Sin embargo, en el uso conversacional de MCP, la latencia se vuelve mucho más sensible
    Una respuesta en 2 segundos está bien en un script, pero rompe el flujo de conversación
    Así que almacené en caché las tablas más usadas en memoria y logré respuestas por debajo de 100 ms
    Me pregunto si otras personas también han experimentado este tipo de umbral de latencia

    • Yo también uso MCP y me resulta útil, pero el consumo de tokens puede aumentar mucho
      En implementaciones simples, puede gastar decenas de miles de tokens más para la misma funcionalidad
      Está el texto explicativo de Anthropic, aunque es un material algo viejo
    • En mi experiencia, entre 300 y 500 ms por llamada a herramienta es el límite superior natural
      Más allá de eso, las cadenas de varios pasos se vuelven lentas y el modelo agrega razonamiento innecesario, inflando el contexto
      Además del caché, también me resultó efectiva la estrategia de reducir la cantidad de idas y vueltas haciendo que se devuelvan varios datos a la vez

  • Comparten cómo configurar Gemma 4 26B en macOS como inferencia local para Claude Code

    • Me parece un excelente resumen

  • En adelante, quizá los principales laboratorios de IA operen LLM locales en paralelo para reducir la carga de la nube y procesar en la nube solo los cálculos pesados

    • Pero me pregunto si eso no entraría en conflicto con su modelo de negocio

  • Me da curiosidad qué tan bien funciona el modelo Gemma 4 en tareas de programación con agentes y cuál fue la impresión real al usarlo