DeepSeek-V4-Pro Compressé 50x, Maintenant Exécuté sur un T4 Gratuit de Kaggle

L'expérience avec DeepSeek-V4-Pro démontre que même un modèle de la classe de 1,6 billion de paramètres peut être amené à un état de fonctionnement sans cluster H100, si vous abandonnez l'idée de l'exécuter dans sa forme originale. Au lieu d'une inférence complète, l'auteur du projet a assemblé une approximation extrêmement agressive : compression des poids via décomposition de faible rang, traitement des fragments gigantesques par flux continu et adaptation manuelle de l'architecture aux outils existants. Le résultat est loin d'être production-ready, mais le simple fait de fonctionner sur une T4 NVIDIA gratuite dans Kaggle semble une forte démonstration de l'importance des mathématiques et de l'ingéniosité en ingénierie aujourd'hui.

La description originale discute de DeepSeek-V4-Pro, que l'auteur appelle un modèle MoE de 1,6 billion de paramètres avec des poids dépassant 800 GB. Pour cette classe de systèmes, typiquement une infrastructure complètement différente est nécessaire : plusieurs H100s, de grandes quantités de mémoire vidéo, des canaux rapides entre nœuds et un espace disque local adéquat. Face à cela, le choix d'une instance Kaggle gratuite avec une T4 avec 16 GB VRAM et environ 50 GB de disque semble non pas comme une tentative de répliquer un déploiement standard, mais comme une expérience aux limites du possible.

L'énoncé du problème lui-même est également important : non pas préserver le modèle dans sa forme originale, mais vérifier combien de structure utile peut être conservée après une compression radicale. Le mouvement clé du projet est d'abandonner la quantification standard de 4 bits en faveur de la transmutation SVD, c'est-à-dire la décomposition de faible rang des matrices de poids. Selon la description de l'auteur, un rang de 64 a fourni environ 50 fois de compression.

Ce schéma préserve les dépendances principales entre les paramètres, mais rejette beaucoup de détails et avec eux une partie de la qualité. Pour un modèle géant, c'est un échange difficile : la précision baisse, mais il y a une chance de faire tenir le système dans le matériel disponible. En essence, ce n'est plus le modèle original au sens plein, mais son squelette mathématique, qui est encore capable de préserver une partie du contexte et des connexions associatives.

Le deuxième élément important est le travail avec les poids en mode MLOps presque d'urgence. Au lieu de stocker l'ensemble complet des paramètres localement, l'auteur a traité les fragments séquentiellement via safe_open : téléchargé un fichier, extrait le tenseur nécessaire, compressé en RAM, envoyé le résultat au référentiel et complètement effacé le cache avant l'étape suivante. Cela a permis de contourner la limitation de disque un ensemble de poids qui dans un scénario normal ne tiendrait simplement pas sur une machine gratuite.

Il est séparément souligné que la consommation de RAM n'a jamais dépassé 4 GB. C'est un détail important, car dans ces tâches vous vous heurtez non seulement à des limitations de VRAM mais aussi à la logistique des fichiers, quand le modèle ne peut physiquement pas être décompressé sans astuces intermédiaires. La troisième couche de la construction est un vol d'identité architectural.

La bibliothèque transformers, selon l'auteur, ne supportait pas encore DeepSeek-V4, donc la configuration a dû être masquée en tant que DeepSeek-V2 et le routage MoE a dû être corrigé séparément par monkey patching. Du point de vue de l'ingénierie, c'est une technique fragile : elle dépend de la version des bibliothèques, du format de la configuration et de la conception du routeur d'experts. Mais c'est précisément cette étape qui montre que certaines des limitations autour des grands modèles ne sont liées non seulement au matériel, mais aussi à la compatibilité des outils.

Si le stack ne connaît pas encore la nouvelle architecture, les chercheurs doivent souvent d'abord adapter le framework au modèle, puis s'occuper de la qualité de la sortie. Le résultat était une version du modèle qui, selon l'auteur, tient en mémoire d'une seule T4 et peut maintenir le contexte, mais se dégrade notablement en qualité. Parmi les effets secondaires figurent les hallucinations et le mélange du russe, de l'anglais et du chinois en une seule réponse.

Cela rend le système un mauvais candidat pour les scénarios de production fiables où la précision, la stabilité et la prévisibilité importent. Mais en tant que preuve de concept, le projet fonctionne : il démontre que même les modèles gigantesques open-weight peuvent non seulement être discutés en termes de data-centers, mais aussi être décomposés en configurations plus accessibles, bien que fortement réduites. La principale conclusion ici n'est pas que la T4 est soudainement devenue un remplacement pour les clusters GPU modernes.

Plutôt l'inverse : l'expérience montre clairement le coût de tels compromis et la limite au-delà de laquelle l'exécution d'un modèle signifie non pas une inférence complète, mais une reconstruction au niveau de la recherche. Mais ce sont précisément de tels projets qui font avancer la pratique de la compression, de l'inférence approximative et du MLOps accessible. Plus ces solutions de contournement apparaissent, plus bas sera le obstacle à l'entrée pour ceux qui veulent expérimenter avec de grands modèles sans budget corporatif.