Frankenstein Transformer: 33 arquitecturas y 23 optimizadores en un solo archivo

Resumen ejecutivo

1. El problema: un zoológico sin catálogo

Desde que los transformers se volvieron el estándar del modelado de secuencias — en lenguaje natural, visión por computadora y hasta biología computacional —, la investigación produjo una explosión de alternativas. Cada una ataca una limitación concreta de la atención clásica: el costo cuadrático cuando el texto es largo, la memoria que consume la inferencia, la necesidad de decidir dinámicamente a qué prestar atención, la eficiencia sobre el hardware disponible. En paralelo, el mundo de los optimizadores —el algoritmo que ajusta los pesos del modelo durante el entrenamiento— se diversificó mucho más allá del clásico AdamW.

Como plantea el paper, la consecuencia práctica es incómoda: comparar experimentalmente dos arquitecturas requiere un esfuerzo de ingeniería sustancial. Hay que implementar y depurar cada variante, garantizar que las tuberías de entrenamiento sean idénticas y gestionar espacios de hiperparámetros enormes. Si dos equipos reportan resultados distintos, muchas veces es imposible saber si la diferencia está en la arquitectura o en cómo cada uno montó su experimento. Esa fragmentación "dificulta la reproducibilidad, ralentiza el progreso científico y aumenta la barrera de entrada para nuevos investigadores" — una barrera que pesa especialmente en América Latina, donde pocos equipos pueden costear reimplementar el estado del arte solo para poder compararlo.

2. La propuesta: la configuración como contrato

La apuesta de Frankenstein Transformer es que el archivo de configuración sea la única fuente de verdad. En vez de escribir código distinto para cada experimento, describes el modelo completo —arquitectura, optimizador, datos, entrenamiento, despliegue— en un YAML, y la herramienta se encarga del resto.

La pieza que hace que esto no se degrade con el tiempo es una decisión de diseño pequeña y severa: el esquema está declarado con additionalProperties: false. En castellano: si escribes un campo que el esquema no reconoce, la ejecución falla — no lo ignora en silencio. Cualquiera que haya perdido un día persiguiendo un experimento que "no aplicó" un parámetro mal escrito entiende por qué esto importa. El precio es rigidez; el beneficio es que dos personas con el mismo YAML obtienen el mismo experimento.

Y rigidez no significa verbosidad: solo cinco campos de modelo son obligatorios —vocabulario, tamaño oculto, número de capas, cabezas y el patrón de capas— más la tarea de entrenamiento. Todo lo demás cae en valores por defecto razonables, y solo se declara lo que se quiere cambiar. Una configuración mínima de un modelo con atención estándar cabe en pocas líneas:

model_class: frankenstein
model:
  vocab_size: 30522
  hidden_size: 256
  num_layers: 4
  num_heads: 8
  layer_pattern: [standard_attn, standard_attn, standard_attn, standard_attn]
training:
  task: mlm
  batch_size: 8
  optimizer:
    optimizer_class: adamw

Cambiar de arquitectura es editar layer_pattern; cambiar de optimizador, una línea. Esa es toda la promesa del proyecto, resumida en un archivo.

3. Las cinco categorías de arquitecturas

El catálogo de 33 mezcladores de secuencia se organiza en cinco categorías, y entenderlas equivale a un mapa rápido del estado del arte:

Dos clases de modelo cubren los dos paradigmas del campo: frankenstein entrena en modo codificador —atención bidireccional para modelado de lenguaje enmascarado, estilo BERT— y frankensteindecoder en modo decodificador —enmascaramiento causal para predecir el siguiente token, estilo GPT—. Eso permite comparar el mismo mezclador en ambos mundos. A esto se suman mecanismos transversales como Mixture-of-Depths (enrutamiento que decide cuánta profundidad de red merece cada token), mHC (conexiones residuales restringidas por variedad), mezcla de expertos (MoE) y tres tipos de normalización.

4. Optimizadores: control fino donde importa

La segunda mitad del sistema es el enrutamiento de optimizadores, y aquí hay una idea práctica que vale por sí sola. No todos los parámetros de un modelo quieren el mismo trato: los embeddings, las capas de normalización, los bloques recurrentes y los de atención se comportan distinto durante el entrenamiento. Frankenstein permite asignar hiperparámetros por grupo mediante prefijos —por ejemplo adamw-lr_embeddings o muon-ns_steps—, es decir, una tasa de aprendizaje para los embeddings, otra para las normas y otra para la atención, sin escribir una línea de código.

5. Del entrenamiento al despliegue

Una decisión de arquitectura interesante: el proyecto trata la cuantización como una etapa del despliegue, no como una familia separada de modelos. Entrenas normal, y al desplegar aplicas empaquetado ternario de pesos —que reduce el almacenamiento a aproximadamente 1,58 bits por parámetro, el enfoque BitNet— con activaciones en INT8. El resultado es un artefacto mucho más liviano y exportable al formato de HuggingFace Transformers, es decir, utilizable con las herramientas que el ecosistema ya conoce.

La otra tubería lista para usar son los embeddings de oraciones estilo SBERT: un mismo codificador entrenado sirve para puntuar similitud entre pares de textos, para búsqueda y recuperación sobre un corpus, y para clustering o codificación offline. Es la clase de utilidad que convierte un experimento de investigación en algo aplicable a un buscador interno o a un sistema de recomendación.

Todo se opera con ocho subcomandos de una sola CLI —train, deploy, quantize, infer, sbert-train, sbert-infer, transformers-export y web-server—, cada uno con selección automática de dispositivo (CPU, CUDA o Apple Silicon). Y para bajar la barrera de entrada, ese último subcomando levanta un constructor visual de configuraciones en Streamlit: formularios generados desde el propio esquema, con descripciones y ayuda de cada parámetro, validación en tiempo real, vista previa del YAML y generación automática del comando final. Hay incluso una versión publicada en la web para armar la configuración sin instalar nada.

6. Lo que el propio autor reconoce que falta

Uno de los méritos del proyecto es su honestidad: la sección de discusión y limitaciones del paper es tan detallada como la de contribuciones, y el propio README marca con una advertencia las piezas que no están listas. Vale la pena listarlo, porque es un mapa bastante claro de por dónde puede aportar quien quiera colaborar:

• Dos métodos de atención dispersa que no requieren entrenamiento (SpargeAttn y FASA) son solo de evaluación: intentar entrenar con ellos lanza un error en tiempo de ejecución, porque necesitan checkpoints preentrenados o un ajuste fino específico que aún no está automatizado.
• mHC está validado solo al nivel de los experimentos publicados de 3B–27B parámetros; falta reproducción independiente a escalas menores.
• La cuantización es uniforme para todos los parámetros; la literatura sugiere que estrategias por capa o por canal darían mejores compromisos entre calidad y eficiencia. La compresión agresiva puede degradar el rendimiento, sobre todo en modelos pequeños.
• El patrón de despacho interno "corre el riesgo de convertirse en un cajón de sastre" a medida que se agregan variantes: hace falta una arquitectura de plugins con registro declarativo.
• No hay todavía una evaluación comparativa exhaustiva entre mezcladores y optimizadores sobre tareas estandarizadas — justamente lo que la herramienta hace posible, y que sería su aporte más valioso al campo.
• Los espacios de hiperparámetros se exploran a mano; falta integración con optimización bayesiana u otros métodos automáticos.

7. Por qué esto importa para Latinoamérica

Frankenstein Transformer no promete un modelo mejor: promete que comparar sea barato. Y esa diferencia es política, no solo técnica. Cuando reproducir un experimento cuesta semanas de ingeniería, la investigación queda reservada a quien puede pagar esas semanas. Cuando cuesta editar un archivo de configuración, un estudiante de magíster en Valparaíso, un equipo de tres personas en Bogotá o un laboratorio universitario en Quito pueden entrar a la conversación con evidencia propia.

Hay un detalle que conviene subrayar: el paper lleva la nota "Este trabajo no está afiliado". Es investigación independiente, publicada en español y en inglés, con el código abierto bajo licencia permisiva, documentación hosteada y pruebas automatizadas en varias versiones de Python — hecha por un ingeniero chileno que trabaja en el sector público. Es exactamente el tipo de aporte que la región necesita multiplicar, y el tipo de trabajo que esta comunidad existe para amplificar.

8. Conclusiones

Tres ideas para llevarse. Primero, el cuello de botella de la investigación en IA ya no es solo el cómputo: es la fricción de ingeniería que separa una idea de su comparación justa contra el estado del arte. Segundo, la reproducibilidad se diseña: un esquema estricto que falla ante un campo desconocido hace más por la ciencia que cualquier declaración de buenas intenciones en un README. Tercero, consolidar es contribuir: reunir 33 arquitecturas y 23 optimizadores bajo un mismo techo no genera titulares como un modelo nuevo, pero reduce la barrera de entrada para todos los que vienen detrás.

Referencias

• Merino M., E. F. (2026). Frankenstein Transformer: Biblioteca Unificada de Codificador-Decodificador, CLI y Notas de Diseño Basadas en Investigación. Paper en español (PDF).
• Repositorio y documentación del proyecto: github.com/erickfmm/frankenstein-transformer · frankenstein-transformer.readthedocs.io.
• Constructor de configuraciones en línea: interfaz web del esquema YAML.
• Vaswani, A. et al. (2017). Attention Is All You Need — base de la arquitectura transformer, citada en el paper. arxiv.org/abs/1706.03762.
• Charla del autor en el I Congreso IA-LATAM: Del método científico de Newton a los LLM y la simulación de la inteligencia. Día 2 del congreso.

Sobre el autor

Erick Francisco Merino Menares es ingeniero del Centro de Innovación del Ministerio de Educación de Chile e investigador independiente en arquitecturas de aprendizaje profundo. Participó en el I Congreso IA-LATAM con la charla «Del método científico de Newton a los LLM y la simulación de la inteligencia». LinkedIn · GitHub

Artículo divulgativo elaborado por la Comunidad IA LATAM a partir del paper original en español y de la documentación pública del repositorio. Los términos técnicos se explican en lenguaje llano; las cifras y limitaciones corresponden a lo declarado por el autor. El proyecto está en desarrollo activo, por lo que las cantidades de arquitecturas y optimizadores pueden variar respecto de esta publicación. Este trabajo es investigación independiente y no está afiliado a ninguna institución.