Google Gemma 4 31B a été réduit à 18,3 Go et exécuté sur Kaggle gratuit

Le Gemma 4 de 31 milliards de paramètres de Google a été comprimé avec succès de 62 GB à 18,3 GB et exécuté via Kaggle gratuit, bien que la limite disque soit inférieure à la taille originale du modèle. Pour y parvenir, l'auteur a assemblé un pipeline plutôt rigoureux, mais fonctionnel : quantification à la volée, suppression du cache pendant l'exécution et téléchargement direct du modèle vers Hugging Face Hub.

Atteindre les Limites

Le Gemma 4 31B original en format float16 occupe environ 62 GB, et le disque disponible sur Kaggle gratuit est limité à 57,6 GB. Le problème n'est pas seulement de télécharger le modèle. Il faut encore le requantifier à 4 bits, obtenir un nouvel ensemble de poids d'environ 18 GB, puis le charger.

Si nous faisons les calculs simplement, à une étape vous devez maintenir à la fois l'original et le résultat, ce qui représente déjà environ 80 GB. En d'autres termes, le scénario standard échoue même avant le premier chargement réussi. C'est le point de ce cas : il ne s'agit pas d'un bel MLOps sur du matériel coûteux, mais de la tentative d'exécuter un modèle lourd en open source dans des conditions où chaque gigaoctet doit être gagné.

Au lieu d'A100, deux T4 gratuits ont été utilisés, donc la tâche s'est résumée à deux limitations à la fois — disque et mémoire vidéo. En conséquence, tout le pipeline a dû être construit non autour de la commodité, mais autour de la survie : quoi stocker, quand supprimer et à quel moment envoyer l'artefact dehors.

Comment le Pipeline a Été Construit

La première technique clé est la quantification non pas après la préparation complète, mais juste pendant le processus de chargement. Pour cela, bitsandbytes et le format NF4 ont été utilisés, et le paramètre device_map="auto" a permis la distribution automatique du modèle sur deux T4 avec 15 GB de mémoire chacun. L'idée est de ne pas attendre que tous les poids s'installent confortablement sur disque puis seulement ensuite commencer le traitement. Plus la compression commence tôt, moins il y a de risque que les fichiers temporaires et les états intermédiaires consomment complètement l'espace disponible.

• Le modèle se charge et se quantifie presque simultanément, sans une longue pause entre les étapes
• Le paramètre device_map="auto" distribue les poids fragmentés entre deux T4
• Après le chargement en VRAM, le cache de Hugging Face est supprimé pour libérer de l'espace pour le nouvel artefact
• Au lieu de sauvegarder sur disque, le modèle est envoyé directement à Hugging Face Hub

L'étape la plus radicale a été de supprimer le dossier de cache de Hugging Face après que le modèle ait déjà été chargé en mémoire vidéo. Techniquement, l'astuce s'appuie sur le comportement de Linux : même si un fichier est supprimé du système de fichiers, le processus peut continuer à le conserver ouvert, et l'espace devient disponible pour les nouvelles écritures. Grâce à cela, les 62 GB originaux cessent d'interférer avec la création de fragments quantifiés. L'étape finale a également évité les copies inutiles : au lieu de sauvegarder normalement et de charger séparément, le résultat a été envoyé directement à Hugging Face Hub via push_to_hub.

"Nous n'avons pas attendu la fin du téléchargement, nous avons

commencé à compresser les poids immédiatement."

Ce Qui En Est Ressorti

Le résultat a été un artefact de 18,3 GB — non plus un monstre attaché au matériel serveur, mais un modèle avec lequel vous pouvez travailler sur des configurations beaucoup plus ordinaires. L'auteur souligne spécifiquement qu'il s'agit du Gemma 4 de 31 milliards de paramètres, orienté notamment vers des tâches impliquant du code complexe. Le résultat lui-même a été posté sur Hugging Face, donc ce n'est pas seulement une recette théorique, mais une expérience reproductible avec un résultat concret et une construction prête.

Il est important de noter que ce n'est pas une instruction universelle pour la production et pas un exemple d'infrastructure bien organisée. D'après la description de la méthode, il est clair que l'approche est fragile : elle est liée au comportement de Linux, au moment exact de la suppression du cache, et à l'espoir qu'aucune erreur ne se produise pendant l'exécution qui vous obligerait à recommencer presque à zéro. Mais c'est exactement ce qui rend ce cas intéressant. Il montre que l'accessibilité des grands modèles est déterminée non seulement par le budget, mais par l'ingéniosité de l'ingénierie — surtout là où l'infrastructure est limitée et où vous voulez essayer un nouveau modèle maintenant.

Ce Que Cela Signifie

Les grands modèles open source comme Google Gemma 4 peuvent être adaptés même à des infrastructures très modestes, si vous reconstruisez l'ensemble du processus autour des limitations plutôt qu'autour d'un pipeline pratique. Pour les développeurs, c'est un bon signal : la barrière à l'entrée pour les expériences avec les grands LLM est abaissée, mais le prix de cette accessibilité est des scénarios MLOps plus fragiles et manuels.