DeepSeek et Gemma: Comment une Expérience LLM Hybride sur Kaggle a Cassé la Bibliothèque Transformers

Des enthousiastes ont assemblé un LLM hybride presque contre les règles : ils ont pris quatre couches du modèle Gemma 31B et les ont intégrées dans une architecture MoE vide de DeepSeek-V4 sans entraînement supplémentaire. Cela n'a pas produit un concurrent fonctionnel de ChatGPT, mais le processus lui-même a montré à quel point on peut profondément casser PyTorch et Transformers en poursuivant le test d'une idée extrême.

Pourquoi un hybride est-il nécessaire

L'idée est née de contraintes extrêmement strictes : deux T4 gratuits sur Kaggle, environ 30 GB de RAM et aucun budget pour un fine-tuning à grande échelle. Au lieu de s'entraîner, les auteurs ont décidé de tester un scénario plus brut — la greffe structurelle de modèles. Gemma-4-31B a servi de donneur, compressé au format NF4 4-bit, tandis qu'un DeepSeek-V4 vide avec son routeur Mixture-of-Experts a servi de "squelette". La tâche ressemblait presque à un mème : transférer les poids d'une architecture à une autre et voir si la chimère pouvait prendre vie.

D'un point de vue ingénierie, le projet était intéressant non pas par la qualité des réponses, mais par le simple fait de la compatibilité. Gemma et DeepSeek ont des dimensionnalités différentes, leur propre logique de normalisation, des blocs d'attention différents et leurs propres règles pour l'acheminement des tokens entre les experts. Dans les manuels, ces transferts sont généralement classés comme impossibles sans projections intermédiaires et entraînement supplémentaire. Les auteurs ont consciemment enfreint cette règle et ont mis en place une expérience pour tester la résilience de la bibliothèque : qu'est-ce qui se casserait en premier — le modèle, la mémoire de Kaggle ou la pile Hugging Face elle-même ?

Où tout s'est cassé

La première défaillance a commencé au stade du chargement. Transformers a refusé de reconnaître correctement le type personnalisé `gemma4`, puis s'est écrasé avec une erreur `dict.to_dict()` parce que l'un des modules internes a sérialisé la configuration dans un dictionnaire ordinaire et a immédiatement essayé d'y accéder comme un objet. Pour continuer, les auteurs ont enregistré manuellement le type dans `CONFIG_MAPPING` et ont ajouté un monkey patch pour `GenerationConfig`, qui enveloppe le dictionnaire dans un objet proxy à la volée. Sinon, toute l'opération aurait pris fin avant même que la chimère ne soit créée.

Ensuite, la bibliothèque a tenté d'initialiser les sections vides de DeepSeek avec du bruit aléatoire en appelant `normal_`. À ce moment, PyTorch a levé `NotImplementedError` : les poids donateurs ont été chargés via bitsandbytes au format 4-bit et stockés sous la forme `uint8`, tandis que le générateur de distribution normale fonctionne avec des tenseurs float. Le problème a été résolu de la manière la plus directe — ils ont intercepté `TORCH_INIT_FUNCTIONS["normal_"]` et ont empêché la fonction de toucher aux tenseurs d'octets. Ce n'est pas un correctif élégant, mais un contournement chirurgical, et sans lui la transplantation n'aurait même pas commencé.

La partie la plus désagréable s'est avérée être les experts de DeepSeek et la mémoire. Les blocs MoE ont été cachés non pas dans un `ModuleList` ordinaire, mais à l'intérieur d'une classe personnalisée qu'on ne pouvait pas simplement parcourir en boucle. De plus, décompresser la couche 31B de Gemma dans la RAM de Kaggle conduisait presque instantanément à OOM. Pour contourner cela, les auteurs ont écrit un "sonar" récursif qui recherche les sous-couches requises par les attributs `gate_proj`, `up_proj` et `down_proj`, et ont transféré les poids par microlots via le CPU, en répartissant les modèles sur deux GPU et en appelant constamment le collecteur de déchets.

"En apprentissage automatique, il n'y a pas de murs architecturaux

impénétrables."

Comment ils ont cousu le modèle

Le script final a réduit toute l'opération à une séquence de correctifs durs et de copie de poids. Pour chacune des quatre couches, il sélectionnait des matrices pour s'adapter à la taille de la couche cible, les complétant par des zéros si nécessaire, transférait séparément les projections d'attention et séparément les composants MLP pour chaque expert trouvé. La mémoire était nettoyée immédiatement après chaque opération de copie importante. Même après la transplantation, les auteurs ont dû réécrire le routeur MoE pour que lors de l'inférence le modèle ne se bloque pas sur les conflits de dimensionnalité et puisse générer au moins un texte.

Les principales étapes techniques étaient les suivantes :

• Enregistrement de la configuration personnalisée de Gemma dans le registre global de Transformers
• Monkey patch pour `GenerationConfig` qui survit à l'erreur `dict.to_dict()`
• Blocage de `normal_` pour les poids `uint8` 4-bit
• Recherche récursive d'experts et transfert de matrices par microlots via le CPU

Tester la chimère résultante a montré le résultat attendu : le modèle a effectivement démarré, mais a généré du texte incohérent, un mélange de tokens aléatoires et de fragments de phrases. Pour les auteurs, c'était toujours considéré comme un succès car l'objectif n'était pas la qualité des réponses, mais la démonstration du principe. Ils n'ont pas aligné les vocabulaires, n'ont pas entraîné les projections de transition et n'ont pas fait de fine-tuning après la transplantation, donc le flux chaotique de tokens en sortie était presque inévitable. Cependant, l'expérience a prouvé que les contraintes architecturales s'avèrent souvent être non pas un mur, mais une longue liste de problèmes de bas niveau qui peuvent être contournés par du code.

Ce que cela signifie

De telles expériences ne créent pas un produit fini, mais elles montrent bien les limites des LLMs open-source modernes. Si les poids, la quantification, l'acheminement et les hidden states peuvent être au moins partiellement alignés sans entraînement supplémentaire, alors l'espace s'ouvre pour des hybrides plus pratiques — déjà avec des projections normales, une adaptation du vocabulaire et un ajustement ultérieur. Pour les développeurs, c'est un signal : la pile autour des modèles est toujours fragile, ce qui signifie que l'espace pour les assemblages non standard ne fait que croître.