La arquitectura transformer está resuelta: el moat real de los LLM vive en el entrenamiento, no en el diagrama

Por Zendoric · 28 de junio de 2026.

Hay una frase que circula en foros técnicos cada vez que sale un modelo nuevo: 'al final, es solo un transformer'. La afirmación es técnicamente correcta y analíticamente inútil. Un ensayo publicado por Bharadwaj P. en su blog personal pone sobre la mesa, con ejemplos trabajados y diagramas, exactamente qué se esconde detrás de ese 'solo': tres fases de entrenamiento, billones de tokens, datos de preferencia humana, y una infraestructura GPU que no está al alcance de casi nadie. La arquitectura es el punto de partida, no el producto.

**El transformer vacío es una pila de números aleatorios**

El texto arranca de un hecho que conviene recordar: un modelo recién inicializado no sabe nada. Es una matriz de pesos sin sentido. Lo que lo convierte en Claude, GPT o Gemini no es el diagrama de bloques de atención —eso ya está publicado, es público y reproducible—, sino el proceso que sucede después. El autor identifica seis palancas que cierran esa brecha: tokenización, entrenamiento previo, ajuste supervisado, alineación, adaptación barata mediante LoRA, y la infraestructura de inferencia.

Antes de llegar a las fases de entrenamiento, el ensayo dedica espacio a dos elementos que suelen darse por sentados pero que tienen consecuencias concretas en el comportamiento de los modelos.

El primero son las **conexiones residuales**. El problema clásico de entrenar redes profundas es que la señal de error se degrada al propagarse hacia atrás: se encoge o explota. La solución, elegante por su sencillez, es dejar que la entrada original de cada bloque viaje también directamente a la salida, de modo que el bloque solo aprenda un ajuste incremental sobre una señal estable. Sin esa ruta paralela, entrenar modelos profundos de muchas capas sobre billones de tokens sería numéricamente inviable.

El segundo es la **tokenización**. Los modelos no ven palabras; ven fragmentos estadísticos. Un tokenizador como el de Llama 3 parte el texto en trozos cuya frecuencia de aparición justifica darles un identificador propio. 'Aardvark' se convierte en tres tokens ('a', 'ard', 'vark') porque es rara; 'I' permanece intacto porque es ubícua. Este diseño explica por qué los LLM manejan bien erratas y mezcla de idiomas —el modelo nunca vio 'palabras' como unidades— y también por qué fallan sistemáticamente al contar letras: 'strawberry' no llega como diez caracteres separados, sino como bloques opacos. El hecho de que el modelo responda 'dos' cuando la respuesta correcta es 'tres erres' no es un fallo de razonamiento abstracto; es una consecuencia directa de cómo el texto se representa en la entrada.

**Tres fases, un mismo mecanismo, datos distintos**

El núcleo del ensayo es la secuencia de entrenamiento. El mecanismo es siempre el mismo —predecir el siguiente token, comparar con la respuesta real, corregir los pesos— pero la naturaleza de los datos cambia radicalmente entre fases, y eso cambia el modelo resultante.

La **fase uno, el preentrenamiento**, es la parte de fuerza bruta: más de diez billones de tokens de texto web filtrado, código de fuente abierta, problemas matemáticos. El modelo aprende a continuar texto. Lo que emerge se denomina modelo base: un autocompletado sofisticado que, ante una pregunta, puede generar más preguntas en lugar de responderlas. Aquí reside el nombre GPT: Generative Pre-trained Transformer. El 'pre-trained' es literalmente esta fase.

La **fase dos, el ajuste supervisado** (SFT), transforma ese autocompletado en un asistente. Se reemplaza el texto web por conversaciones: instrucción, contexto del sistema, respuesta correcta. El mecanismo no cambia; cambia el ejemplo. El modelo aprende que su turno empieza cuando aparece un token especial —`<|im_start|>assistant`— y que lo que sigue debe ser una respuesta, no una continuación. Los laboratorios invierten cantidades significativas en construir estos datasets de conversación y los mantienen privados. Dos modelos que comparten arquitectura y texto web pueden comportarse de manera muy diferente si sus datos de conversación difieren.

La **fase tres, la alineación**, es donde entra el aprendizaje por refuerzo. La variante más conocida es RLHF: se presentan dos respuestas a evaluadores humanos, se registra cuál prefieren, se entrena un modelo predictor de preferencias y se usa ese predictor para empujar al modelo de chat hacia respuestas mejor valoradas. DPO (Direct Preference Optimization) logra un efecto similar con menos infraestructura, aprendiendo directamente desde pares de preferencia sin el predictor intermedio. Es también en esta fase donde, según el análisis externo disponible, emergen los modelos de razonamiento: el transformer es idéntico, pero el entrenamiento enseña al modelo a emitir tokens de razonamiento intermedio antes de la respuesta final. La caja gris de 'pensando' que muestran algunos interfaces no es magia arquitectónica; es conducta aprendida.

**LoRA: la vía de acceso para el resto**

Ajustar los pesos completos de un modelo de decenas de miles de millones de parámetros está fuera del presupuesto de casi cualquier equipo que no sea un laboratorio de frontera. LoRA (Low-Rank Adaptation) resuelve ese problema dejando los pesos originales congelados y añadiendo, en paralelo, dos matrices pequeñas cuyo producto aproxima el ajuste que haría el entrenamiento completo. La dimensión intermedia de esas matrices —el 'rango bajo' que da nombre a la técnica— se elige para que el número de parámetros entrenables caiga por debajo del uno por ciento del total. En una matriz de pesos real, en lugar de actualizar miles de millones de valores, se entrenan millones. La pérdida de expresividad existe, pero el coste cae en órdenes de magnitud. Para casos de uso especializados —un modelo experto en código legal, en terminología médica, en un idioma con pocos recursos— LoRA es la diferencia entre posible e imposible.

**La carrera no es por la arquitectura**

El ensayo menciona el patrón de emergencia documentado alrededor de 2022: en muchas tareas, la precisión de un modelo permanece plana cerca del azar y luego salta bruscamente cuando el cómputo de entrenamiento supera un umbral. Ese patrón convirtió la acumulación de datos y cómputo en una lógica de inversión difícil de resistir para cualquier laboratorio que observe la curva. Como contexto del sector, ese es el motor detrás de los acuerdos de licencia de datos a gran escala, de la construcción de centros de datos y de la pugna por la capacidad de GPU que define la industria desde entonces.

En cuanto a la inferencia, el artículo recuerda algo que los no especialistas suelen ignorar: servir un modelo a escala es un problema de ingeniería propio, separado del entrenamiento. Las GPUs dominan porque multiplicar matrices en paralelo es exactamente lo que hacen bien. Los esfuerzos para reducir el coste de inferencia —cuantización, modelos más pequeños para tareas de clasificación— y la arquitectura Mixture of Experts (MoE), que mantiene capacidad total pero solo activa una fracción de parámetros por token, son respuestas directas a esa presión económica.

**La lectura que importa**

El valor de este tipo de síntesis técnica está en proporcionar un marco analítico para leer el mercado. Cuando un laboratorio anuncia un nuevo modelo y el debate gira en torno a si usa tal o cual mecanismo de atención, número de capas o tamaño del vocabulario, está discutiendo la parte que ya está resuelta y es pública. La diferencia competitiva está en los datos de conversación, en la calidad y escala del proceso de alineación, en la capacidad de cómputo sostenida durante meses, y en el conjunto de decisiones de entrenamiento que los laboratorios guardan con celo.

Dicho de otra forma: la arquitectura transformer es el papel en blanco. El texto que se escribe encima —quién lo recopiló, cómo se filtró, qué señales de preferencia se usaron, cuánto se gastó— es lo que hace que un modelo valga lo que vale.