DeepSeek y Gemma: Cómo un Experimento de LLM Híbrido en Kaggle Rompió la Biblioteca Transformers

Entusiastas armaron un LLM híbrido casi contra las reglas: tomaron cuatro capas del modelo Gemma de 31B e las incrustaron en una arquitectura MoE vacía de DeepSeek-V4 sin entrenamiento adicional. Esto no produjo un competidor funcional de ChatGPT, pero el proceso en sí mostró cuán profundamente puede romper PyTorch y Transformers persiguiendo probar una idea extrema.

Por qué se necesita un híbrido

La idea nació de restricciones extremadamente rigurosas: dos T4 gratuitos en Kaggle, aproximadamente 30 GB de RAM y ningún presupuesto para fine-tuning a gran escala. En lugar de entrenar, los autores decidieron probar un escenario más tosco: injerto estructural de modelos. Gemma-4-31B sirvió como donante, comprimido al formato NF4 de 4 bits, mientras que un DeepSeek-V4 vacío con su enrutador Mixture-of-Experts sirvió como el "esqueleto". La tarea sonaba casi como un meme: trasplantar pesos de una arquitectura a otra y ver si la quimera podía cobrar vida.

Desde una perspectiva de ingeniería, el proyecto era interesante no por la calidad de las respuestas, sino por el mero hecho de la compatibilidad. Gemma y DeepSeek tienen diferentes dimensionalidades, su propia lógica de normalización, diferentes bloques de atención y sus propias reglas para enrutamiento de tokens entre expertos. En los libros de texto, tales transferencias generalmente se clasifican como imposibles sin proyecciones intermedias y entrenamiento adicional. Los autores conscientemente fueron contra esta regla e idearon un experimento para probar la resiliencia de la biblioteca: ¿qué se rompería primero — el modelo, la memoria de Kaggle o la pila del Hugging Face en sí?

Dónde se rompió todo

El primer fallo comenzó en la etapa de carga. Transformers se negó a reconocer adecuadamente el tipo personalizado `gemma4`, luego se estrelló con un error `dict.to_dict()` porque uno de los módulos internos serializó la configuración en un diccionario ordinario e inmediatamente intentó acceder a él como un objeto. Para continuar, los autores registraron manualmente el tipo en `CONFIG_MAPPING` y agregaron un monkey patch para `GenerationConfig`, que envuelve el diccionario en un objeto proxy sobre la marcha. De lo contrario, toda la operación habría terminado antes de que se creara la quimera.

Luego, la biblioteca intentó inicializar secciones vacías de DeepSeek con ruido aleatorio llamando a `normal_`. En ese punto, PyTorch arrojó `NotImplementedError`: los pesos donantes fueron cargados a través de bitsandbytes en formato de 4 bits y almacenados como `uint8`, mientras que el generador de distribución normal funciona con tensores float. El problema se resolvió de la forma más directa: interceptaron `TORCH_INIT_FUNCTIONS["normal_"]` e impidieron que la función tocara tensores de bytes. No es un parche bonito, sino un desvío quirúrgico, y sin él el trasplante ni siquiera habría comenzado.

La parte más desagradable resultó ser los expertos de DeepSeek y la memoria. Los bloques MoE estaban ocultos no en un `ModuleList` ordinario, sino dentro de una clase personalizada que no se podía iterar simplemente. Además, descomprimir la capa de 31B de Gemma en la RAM de Kaggle casi instantáneamente conducía a OOM. Para solucionar esto, los autores escribieron un "sonar" recursivo que busca las subcapas requeridas por los atributos `gate_proj`, `up_proj` y `down_proj`, y transfirieron pesos en micro-lotes a través de la CPU, distribuyendo los modelos entre dos GPUs y llamando constantemente al recolector de basura.

"En el aprendizaje automático, no hay muros arquitectónicos impenetrables."

Cómo cosieron el modelo

El script final redujo toda la operación a una secuencia de parches duros y copia de pesos. Para cada una de las cuatro capas, seleccionaba matrices para ajustarse al tamaño de la capa objetivo, rellenándolas con ceros cuando era necesario, trasplantaba por separado las proyecciones de atención y por separado los componentes MLP para cada experto encontrado. La memoria se limpiaba inmediatamente después de cada operación de copia importante. Incluso después del trasplante, los autores tuvieron que reescribir el enrutador MoE para que durante la inferencia el modelo no se bloqueara en conflictos de dimensión y pudiera generar al menos algo de texto.

Los pasos técnicos clave fueron los siguientes:

• Registro de configuración personalizada de Gemma en el registro global de Transformers
• Monkey patch para `GenerationConfig` que sobrevive al error `dict.to_dict()`
• Bloqueo de `normal_` para pesos `uint8` de 4 bits
• Búsqueda recursiva de expertos y transferencia de matrices en micro-lotes a través de la CPU

Probar la quimera resultante mostró el resultado esperado: el modelo realmente se inició, pero generó texto incoherente, una mezcla de tokens aleatorios y fragmentos de frases. Para los autores, esto seguía siendo un éxito porque el objetivo no era la calidad de las respuestas, sino la demostración del principio. No alinearon vocabularios, no entrenaron proyecciones de transición y no realizaron fine-tuning después del trasplante, por lo que el flujo caótico de tokens en la salida era casi inevitable. Sin embargo, el experimento demostró que las restricciones arquitectónicas a menudo resultan ser no un muro, sino una larga lista de problemas de bajo nivel que pueden eludirse con código.

Qué significa esto

Tales experimentos no crean un producto terminado, pero hacen un buen trabajo mostrando los límites de los LLMs de código abierto modernos. Si los pesos, la cuantización, el enrutamiento y los hidden states pueden alinearse al menos parcialmente sin entrenamiento adicional, entonces se abre el espacio para híbridos más prácticos — ya con proyecciones normales, adaptación de vocabulario y ajuste posterior. Para los desarrolladores, esta es una señal: la pila alrededor de los modelos sigue siendo frágil, lo que significa que el espacio para ensamblajes no estándar solo está creciendo.