Google Gemma 4 31B se redujo a 18,3 GB y corrió en Kaggle gratuito

El Gemma 4 de 31 mil millones de parámetros de Google fue comprimido exitosamente de 62 GB a 18,3 GB y ejecutado a través de Kaggle gratuito, a pesar de que el límite de disco sea menor que el tamaño original del modelo. Para lograrlo, el autor armó un pipeline bastante riguroso, pero funcional: cuantificación sobre la marcha, eliminación de caché durante la ejecución y carga directa del modelo en Hugging Face Hub.

Alcanzando los Límites

El Gemma 4 31B original en formato float16 ocupa alrededor de 62 GB, y el disco disponible en Kaggle gratuito está limitado a 57,6 GB. El problema no es solo descargar el modelo. Aún necesitas recuantificarlo a 4 bits, obtener un nuevo conjunto de pesos de alrededor de 18 GB y luego subirlo.

Si hacemos las cuentas simplemente, en una etapa necesitas mantener tanto el original como el resultado, lo que ya son alrededor de 80 GB. En otras palabras, el escenario estándar se rompe incluso antes de la primera carga exitosa. Ese es el punto de este caso: no se trata de MLOps bonito en hardware caro, sino de intentar ejecutar un modelo pesado de código abierto bajo condiciones donde cada gigabyte tiene que ser ganado.

En lugar de A100, se utilizaron dos T4 gratuitos, por lo que la tarea se redujo a dos limitaciones a la vez — disco y memoria de video. Como resultado, todo el pipeline tuvo que construirse no alrededor de la comodidad, sino alrededor de la supervivencia: qué almacenar, cuándo eliminar y en qué momento enviar el artefacto afuera.

Cómo Se Construyó el Pipeline

La primera técnica clave es la cuantificación no después de la preparación completa, sino justo durante el proceso de carga. Para esto, se utilizaron bitsandbytes y formato NF4, y el parámetro device_map="auto" permitió la distribución automática del modelo entre dos T4 con 15 GB de memoria cada uno. La idea es no esperar a que todos los pesos se acomoden cómodamente en el disco y solo entonces comenzar el procesamiento. Cuanto antes comience la compresión, menor será la probabilidad de que archivos temporarios y estados intermedios consuman completamente el espacio disponible.

• El modelo se carga y cuantifica casi simultáneamente, sin una larga pausa entre etapas
• El parámetro device_map="auto" distribuye pesos fragmentados entre dos T4
• Después de cargar en VRAM, el caché de Hugging Face se elimina para liberar espacio para el nuevo artefacto
• En lugar de guardar en disco, el modelo se envía directamente a Hugging Face Hub

El paso más radical fue eliminar la carpeta de caché de Hugging Face después de que el modelo ya estuviera cargado en memoria de video. Técnicamente, el truco se basa en el comportamiento de Linux: incluso si un archivo se elimina del sistema de archivos, el proceso puede continuar manteniéndolo abierto, y el espacio se vuelve disponible para nuevas escrituras. Por esto, los 62 GB originales dejan de interferir con la creación de fragmentos cuantificados. La etapa final también evitó copias innecesarias: en lugar de guardar normalmente y cargar por separado, el resultado se envió directamente a Hugging Face Hub a través de push_to_hub.

"No esperamos a que terminara la carga, comenzamos a comprimir los

pesos inmediatamente."

Lo Que Salió

El resultado fue un artefacto de 18,3 GB — ya no un monstruo atado al hardware del servidor, sino un modelo con el que puedes trabajar en configuraciones mucho más ordinarias. El autor enfatiza específicamente que se trata del Gemma 4 de 31 mil millones de parámetros, orientado entre otras cosas hacia tareas que involucran código complejo. El resultado en sí fue publicado en Hugging Face, por lo que esto no es solo una receta teórica, sino un experimento reproducible con un resultado concreto y construcción lista.

Es importante notar que esto no es una instrucción universal para producción y no es un ejemplo de infraestructura ordenada. Por la descripción del método, queda claro que el enfoque es frágil: está vinculado al comportamiento de Linux, al momento exacto de la eliminación del caché, y a la esperanza de que no ocurra ningún error durante la ejecución que te obligaría a comenzar casi desde cero. Pero es exactamente eso lo que hace interesante este caso. Muestra que la accesibilidad de modelos grandes está determinada no solo por el presupuesto, sino por la ingeniosidad ingeniería — especialmente donde la infraestructura es limitada y quieres probar un nuevo modelo ahora mismo.

Lo Que Significa

Los grandes modelos de código abierto como Google Gemma 4 pueden adaptarse incluso a infraestruturas muy modestas, si reconstruyes todo el proceso alrededor de las limitaciones en lugar de alrededor de un pipeline conveniente. Para los desarrolladores, esta es una buena señal: la barrera de entrada para experimentos con LLM grandes se reduce, pero el precio de esta accesibilidad son escenarios MLOps más frágiles y manuales.