Cómo un Mac Mini M4 de USD $599 ejecuta un modelo de IA 35B con 16 GB y cero swap

Un desarrollador aseguró haber convertido un Mac Mini M4 base de USD $599 en un servidor de automatización de IA capaz de correr un modelo de 35.000 millones de parámetros con 16 GB de memoria, cero swap y hasta 17,3 tokens por segundo, combinando Gemma 4, Qwen 35B y un esquema de inferencia local pensado para reducir costos, acelerar tareas rutinarias y mantener operativo un agente incluso cuando los servicios en la nube fallan.
***

• El sistema usa tres niveles de modelos locales y la nube para clasificar mensajes, resumir contexto, consolidar memoria y cubrir fallas de Claude.
• El truco técnico clave fue ejecutar Qwen 3.5 35B-A3B con llama.cpp y la bandera --mmap, aprovechando el SSD como extensión práctica de memoria.
• Tras probar Gemma 4, el autor reportó una mejora de 4,4x en clasificación y de 1,8x en resumización frente a su configuración previa con Qwen.

La idea de que un modelo de lenguaje grande exige hardware costoso volvió a ponerse en discusión tras el caso compartido por @leopardracer, quien explicó cómo trasladó su sistema de automatización a un Mac Mini M4 sin monitor, en su versión base de USD $599 y con 16 GB de memoria unificada. Según su relato, el equipo no solo ejecuta modelos ligeros para clasificación rápida, sino también un modelo de 35.000 millones de parámetros con cero swap y una velocidad de 17,3 tokens por segundo.

El proyecto no está pensado como una demostración aislada, sino como infraestructura de trabajo permanente. El Mac Mini funciona como servidor de automatización de IA las 24 horas para procesar iMessages, correos electrónicos, tareas del turno nocturno y más de 35 habilidades especializadas. En ese ecosistema, Claude Code sigue siendo el “cerebro” principal, pero el objetivo fue descargar trabajo rutinario hacia modelos locales para ahorrar dinero, evitar límites de uso y mejorar la respuesta en tareas repetitivas.

De acuerdo con la explicación, el resultado ha sido una reducción aproximada de entre 30% y 40% en las sesiones consumidas de Claude, en comparación con enviar todo por API. Además del ahorro, la ejecución local reduce latencia al eliminar viajes de red en procesos simples como clasificar mensajes o comprimir texto antes de enviarlo a un modelo más potente en la nube.

Este enfoque mezcla una tendencia creciente en IA aplicada: usar modelos locales para tareas frecuentes y baratas, y reservar los modelos remotos para razonamiento complejo. En la práctica, eso crea sistemas híbridos más resilientes y previsibles en costo, algo relevante para cualquier flujo de agentes que dependa de automatización continua.

Tres niveles locales para repartir el trabajo

El esquema descrito por leopardracer no usa un solo modelo para todo. En su lugar, divide las tareas en tres niveles locales, más una capa en la nube. La lógica es simple: no todas las cargas requieren la misma capacidad. Un modelo pequeño puede decidir si un mensaje es un saludo o una pregunta, pero no necesariamente puede resumir de forma útil un bloque grande de información operacional.

El nivel rápido corre sobre cada mensaje entrante. Su función es clasificar el tipo de mensaje, como pregunta, solicitud, idea, saludo o FYI, y evaluar urgencia. Según el autor, este proceso tarda menos de 2 segundos por mensaje. Si el sistema detecta que el contenido es un simple saludo o un aviso sin acción requerida, omite por completo una llamada a Claude.

El nivel primario se reserva para tareas que exigen mejor comprensión del lenguaje. Ahí entra la compresión de contexto, donde un mensaje de unas 500 palabras puede reducirse a unas 30 antes de que Claude lo vea. También se usa para generar notas de respaldo y resúmenes de informes matutinos. En su experiencia, un modelo de 4,5B efectivos resultó suficiente para ese equilibrio entre calidad y costo computacional.

El nivel pesado es el más llamativo. Allí corre Qwen 3.5 35B-A3B para preprocesamiento complejo y como respaldo operativo cuando Claude falla o queda limitado por tasa. Su tarea más importante es comprimir un día completo de señales de automatización en un briefing denso para la planificación nocturna con Opus, con un ahorro estimado de 15x en tokens. También se activa para chequeos de salud, monitoreo y escaneo de errores durante la madrugada, etiquetando la salida como [Local Fallback].

El sistema incluye reglas de seguridad para evitar malos desvíos. Todo mensaje que mencione dinero, despliegues, publicaciones o cualquier asunto laboral omite el triaje local y va directo a Claude. Lo mismo ocurre con mensajes muy cortos, de menos de 20 caracteres, tras un error previo donde “yes” fue clasificado como simple acuse de recibo y terminó saltándose una respuesta que sí debía generarse.

El truco técnico detrás del modelo 35B

La parte más técnica del montaje gira alrededor de llama.cpp y la bandera --mmap. Leopardracer explicó que su primer intento para correr Qwen 3.5 35B-A3B mediante Ollama cargó 26 GB en una máquina de 16 GB. El resultado fue un bloqueo total del sistema, 4,3 millones de swaps y un timeout de 10 minutos sin producir ni un token.

Con llama.cpp y --mmap, el comportamiento cambió por completo. El mismo modelo, en el mismo hardware, pasó a generar 17,3 tokens por segundo, con 81% de memoria libre y cero swap. La explicación es que el sistema operativo trata el archivo del modelo como un espacio de direcciones virtual respaldado por SSD, en vez de intentar cargarlo entero en RAM.

Ese comportamiento se beneficia de la arquitectura Mixture of Experts, o MoE, del modelo usado. Qwen 3.5 35B-A3B tiene 35.000 millones de parámetros en total, pero solo unos 3.000 millones están activos por token. En otras palabras, no todo el modelo trabaja a la vez. Las capas compartidas se mantienen residentes en memoria, con un consumo aproximado de 4 GB a 6 GB, mientras que los pesos de expertos se cargan desde el SSD solo cuando se necesitan.

Según el autor, cerca de 90% del modelo permanece en la unidad NVMe la mayor parte del tiempo, y la caché de páginas de macOS guarda de forma natural los expertos usados recientemente. Esto hace que los patrones repetidos se aceleren. También mencionó el trabajo de investigación “LLM in a Flash”, publicado por Apple en diciembre de 2023, como antecedente directo de este enfoque de usar almacenamiento rápido como extensión práctica de memoria para inferencia.

Una sorpresa adicional fue el rendimiento frente a un modelo previo de 9B. Aunque el 35B tiene muchas más variables totales, el presupuesto efectivo de cómputo por token se mantiene controlado gracias al esquema MoE. En su medición, el modelo pesado alcanzó 17,3 tok/s, por encima de los 12,6 tok/s de su anterior 9B. Para ello usó una cuantización agresiva UD-IQ3_XXS de Unsloth, con un tamaño cercano a 13 GB en disco.

Del stack Qwen a Gemma 4 en tareas rápidas

Durante cerca de una semana, el sistema completo operó con Qwen 3.5 en todos los niveles. El autor dijo que la clasificación tardaba unos 8,5 segundos en el modelo 4B y la resumización alrededor de 50 segundos en el 9B. Aunque era estable, el desempeño seguía siendo más adecuado para segundo plano que para triaje constante sobre cada mensaje entrante.

La situación cambió con el lanzamiento de Gemma 4 bajo licencia Apache 2.0. Ese detalle fue decisivo para su uso en infraestructura 24/7, porque elimina restricciones de uso y límites mensuales de usuarios activos asociados a versiones previas. Además, el autor destacó los benchmarks públicos de la nueva familia, incluyendo puntuaciones de 88% a 89% en matemáticas AIME 2026, frente al 20,8% que había registrado Gemma 3.

Más allá de los números de marketing, lo que más llamó su atención fue la multimodalidad en modelos pequeños. Gemma 4 E2B, con 2,3B efectivos, y E4B, con 4,5B efectivos, pueden procesar imágenes y audio de forma nativa. En su configuración anterior con Qwen, los mensajes de voz enviados por iMessage debían omitirse por completo, y las capturas de pantalla no eran visibles para la capa de triaje.

Antes de migrar, el autor preparó sus propias pruebas. Ejecutó 10 prompts de clasificación y 3 tareas de resumización bajo condiciones idénticas. El resultado fue una mejora de 4,4x en clasificación y de 1,8x en resumización. En números concretos, la clasificación pasó de 8,5 segundos a 1,9 segundos. Esa reducción fue la razón principal del cambio, porque para un sistema de triaje continuo la diferencia entre casi 2 segundos y casi 9 segundos es material.

La precisión no mejoró en la misma proporción. Según relató, la brecha observada fue de 70% frente a 80%, con varios casos en zonas grises. Tanto Gemma como Qwen clasificaron “What’s the status of the nightshift?” como status_check en lugar de question. El fallo más claro fue que Gemma respondió observation para un mensaje donde la etiqueta correcta debía ser fyi, inventando una categoría no permitida. El autor cree que eso puede corregirse con mejor prompting.

La migración fue relativamente simple porque la arquitectura centralizaba los nombres de modelos. Solo tuvo que cambiar dos constantes y editar tres archivos con cadenas hardcodeadas. El nivel pesado se mantuvo en Qwen 35B bajo llama.cpp, mientras que los niveles rápido y primario pasaron a Gemma 4 mediante Ollama, actualizado de 0.19 a 0.20 para contar con soporte desde el primer día.

Rendimiento, contexto y el costo oculto del modo thinking

Otro aprendizaje importante fue evitar el modo “thinking” en tareas rápidas. Tanto Qwen como Gemma pueden generar cadenas extensas de razonamiento antes de responder, algo útil en análisis complejos pero muy ineficiente para clasificación simple. Leopardracer explicó que con esa función activada, preguntas como “¿este mensaje es una pregunta o una solicitud?” tardaban más de 30 segundos.

La solución fue desactivar ese comportamiento con el parámetro think: false en la llamada a la API de Ollama. Con ello, la clasificación cayó a menos de 1 segundo sin pérdida relevante de precisión. El autor describió esta optimización como la mejora individual más grande de toda la configuración, con una ganancia de velocidad de hasta 30x.

En cuanto a ventanas de contexto, el sistema trabaja con distintos límites según tarea. La clasificación usa 4K, la resumización en el nivel primario llega a 32K, el análisis documental en el nivel rápido puede subir a 64K y el 35B pesado opera con 16K. El punto clave es que --mmap ayuda con los pesos del modelo, pero la caché KV sigue viviendo en RAM. Aun así, el autor afirma que ese reparto cabe dentro de los 16 GB disponibles para sus flujos reales.

También detalló varios ajustes operativos. Uno de los más relevantes es OLLAMA_MAX_LOADED_MODELS=1, indispensable en una máquina de 16 GB para evitar que Ollama intente mantener en memoria al mismo tiempo el modelo rápido y el primario. En paralelo, llama.cpp corre en otro puerto, el 8081, mientras Ollama se mantiene en el 11434. Así conviven dos servidores de inferencia distintos en un solo Mac Mini.

Resiliencia local cuando la nube falla

Además del ahorro, el proyecto se diseñó con una lógica de continuidad operativa. La cadena de resiliencia del agente funciona como una cascada: si falla un modelo de mayor nivel, la solicitud baja al siguiente. Si Claude Sonnet no responde, el sistema intenta con Haiku. Si ambos niveles remotos fallan, entran los modelos locales. Solo cuando lo local no está disponible recurre a una API externa, y si incluso eso falla, la tarea se encola para más tarde.

El sistema rastrea además tiempos de enfriamiento para cada modelo. Si un proveedor alcanza un rate limit, registra cuánto debe esperar y evita insistir con reintentos condenados al fracaso. En un caso citado, un token OAuth expiró a las 2 a. m. y el sistema detectó que todos los niveles de Claude fallarían por la misma razón, por lo que saltó directamente al fallback local.

Para trabajos nocturnos, esa capacidad resulta especialmente útil. Mientras el autor duerme, el agente sigue ejecutando monitoreos de salud, revisión de logs y mantenimiento básico. Si Claude queda limitado por tasa a las 4 a. m., el 35B local toma el relevo. La calidad no equivale a la de un modelo premium de razonamiento, pero el resultado es preferible a un silencio total o a una cadena de errores no atendidos.

El balance final que plantea leopardracer es que los modelos locales no necesitan reemplazar a Claude para ser valiosos. Su papel es distinto: clasificar, comprimir, resumir y mantener operaciones básicas sin costo marginal por llamada. Bajo esa lógica, el patrón “local para lo frecuente y barato, nube para lo complejo y caro” aparece como una arquitectura práctica para agentes de IA, incluso sobre hardware de consumo.

De cara al futuro, el siguiente paso de prueba sería Gemma 4 26B MoE como posible reemplazo del Qwen 35B en el nivel pesado. Pero el autor dejó claro que no piensa cambiar dos variables a la vez en producción. Por ahora, su pila mantiene a Gemma 4 para tareas rápidas y primarias, y a Qwen 35B con mmap para la capa pesada. En un mercado donde la conversación suele centrarse en GPUs de miles de dólares, el experimento sugiere que una parte creciente de la infraestructura de IA puede resolverse con equipos mucho más modestos.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín