Chinchilla y las leyes de escalado: el paper que cambió cómo se entrenan los LLM

INTELIGENCIA ARTIFICIAL · LLM · ENTRENAMIENTO

Si tú también te has quedado con la duda de por qué a veces un modelo “más pequeño” sorprende, aquí tienes la explicación clara: qué dice el paper, por qué fue un punto de inflexión y cómo se conecta con decisiones actuales (desde mixture-of-experts hasta modelos pequeños y datos sintéticos).

1. El mito: “más parámetros” siempre gana

Hubo una época (no tan lejana) en la que el argumento era simple: si quieres más calidad, escala el modelo. Más parámetros = más capacidad = mejores resultados. Y ojo: parte de esto era verdad. Escalar funcionaba.

El problema es que esa intuición escondía una trampa: un modelo grande no aprende por existir. Aprende por ver datos. Si no lo expones a suficientes tokens (o no lo entrenas suficientes pasos), se queda “a medio cocer”. Como tener un Ferrari y conducirlo solo por un parking.

2. Qué cambió Chinchilla: el foco pasa de tamaño a “compute bien gastado”

El paper (técnicamente Training Compute-Optimal Large Language Models) no vino a decir “no escales modelos”. Vino a decir algo más útil: si tu presupuesto de compute es fijo, hay combinaciones de tamaño y tokens que son mucho mejores que otras.

En la práctica: en lugar de invertir casi todo en parámetros, te conviene repartir el compute para entrenar con muchos más tokens. Resultado: modelos con menos parámetros pueden superar a modelos más grandes si están entrenados con más datos y más pasos, a igualdad de compute total.

3. La intuición clave: muchos modelos estaban infraentrenados

“Infraentrenado” suena técnico, pero es una idea muy humana: no le diste tiempo (ni material) al cerebro para aprender. En LLM, eso suele ocurrir cuando el tamaño crece más rápido que los tokens disponibles o los pasos de entrenamiento que te puedes permitir.

Chinchilla popularizó una señal de alarma: si el modelo es gigantesco, pero la cantidad de texto que ha leído no crece proporcionalmente, estás pagando por capacidad que no se llega a llenar.

4. La regla práctica que todo el mundo repite (y cómo entenderla bien)

La frase resumida que se hizo famosa fue algo así: para entrenamiento compute-óptimo, necesitas del orden de ~20 tokens por parámetro (en el rango de tamaños/compute analizado). No es una ley física, pero sí una brújula: te está diciendo que los tokens importan muchísimo más de lo que la industria estaba asumiendo.

Piénsalo con un ejemplo sencillo (sin obsesionarnos con la cifra exacta):

Esto, por cierto, conecta directamente con el debate actual sobre qué pesa más: arquitectura, tamaño, o datos. Si te interesa esa capa de decisión (sin dogmas), te puede encajar esta guía para elegir un modelo open source en 2025 según tu caso.

5. Por qué esto funciona: capacidad vs experiencia

Un LLM grande tiene más capacidad para representar patrones complejos. Pero esa capacidad solo se convierte en rendimiento si el modelo ve suficientes ejemplos variados para ajustar sus pesos.

Cuando faltan tokens, pasan dos cosas típicas:

• Aprendizaje incompleto: el modelo no llega a “aprovechar” su tamaño; se queda corto en generalización.
• Desperdicio de compute: gastas mucho en mover un modelo enorme, pero no lo entrenas lo suficiente como para que compense.

Chinchilla puso orden en esa intuición con curvas de escalado y una idea muy operativa: con compute fijo, hay un punto donde “más ancho” deja de ser lo óptimo y “más largo” (más datos/steps) empieza a dominar.

6. Implicaciones hoy: por qué sigues oyendo hablar de Chinchilla en 2026

Aunque el paper salió hace un tiempo, su impacto sigue vivo porque cambió incentivos. Si la frontera se mueve con datos/steps, entonces los “superpoderes” pasan por:

6.1. Datasets mejores (no solo más grandes)

Cuando el cuello de botella es tokens, lo siguiente que descubres es que no todos los tokens valen lo mismo. Deduplicación, calidad, mezcla de dominios, multilingüe, filtrado de spam, y control de contaminación en evaluación… todo eso se volvió “core”.

6.2. Mixture-of-Experts y eficiencia real

Una consecuencia natural: si quieres escalar sin disparar el coste, necesitas arquitecturas que te den capacidad sin pagarla siempre. Ahí entran los MoE, donde activas solo parte del modelo por token. Si quieres aterrizar esa idea sin humo, aquí tienes una explicación clara de Mixture-of-Experts (MoE) y por qué cambia el coste de escalar.

6.3. Modelos pequeños que compiten por diseño

Chinchilla también legitimó una idea que antes sonaba “anti-hype”: modelos más pequeños bien entrenados y bien posicionados pueden ser mejores para muchos productos (coste, latencia, privacidad, despliegue). Esto enlaza con el auge de SLM y modelos móviles: por qué los Small Language Models están ganando terreno.

6.4. El elefante en la habitación: datos sintéticos

Si el mundo “se acaba” en datos de alta calidad, aparece la tentación: generar datos con IA para entrenar IA. Funciona… hasta que no. Hay riesgos reales de degradación (el famoso model collapse) si la dieta se vuelve demasiado autorreferencial. Este tema está creciendo rápido, y lo tienes desarrollado aquí: datos sintéticos en LLM: beneficios, riesgos y colapso.

7. Si tú entrenas (o afinas) modelos: cómo usar la lección sin entrenar un monstruo

Vale, pero tú no vas a entrenar el próximo modelo frontera. Aun así, Chinchilla te deja una brújula para decisiones diarias: cuando tengas un presupuesto limitado, casi siempre te conviene exprimir datos y entrenamiento antes que inflar parámetros.

Y si tu problema es más de aplicación que de preentrenamiento (datos propios, conocimiento actualizado, control), muchas veces la solución no es “más parámetros” sino arquitectura: recuperación, herramientas, agentes, etc. Ahí encaja especialmente bien el mapa mental de RAG vs fine-tuning vs agentes para elegir la arquitectura correcta.

8. La moraleja: la industria dejó de preguntar “¿cuántos parámetros?” y empezó a preguntar “¿cuántos tokens?”

Chinchilla no “mató” la escala. La maduró. Puso números (y vergüenza) a una idea simple: no puedes presumir de tamaño si no has pagado el entrenamiento necesario para llenar ese tamaño de conocimiento.

A partir de ahí, el debate cambia. Ya no es solo “modelo más grande” vs “modelo más pequeño”. Es:

¿Dónde pongo mi presupuesto limitado para sacar más calidad real? Y muchas veces la respuesta es menos sexy, pero más eficaz: mejor datos, más pasos, mejor mezcla y mejor evaluación.