Qué impulsa realmente la tasa de retorno por unidad de cómputo

En la parte 1 recorrimos el argumento de Sara Hooker de que la era del «más grande es mejor» se está acabando. La pregunta natural que la sigue —y a la que Hooker dedica la mayor parte de su ensayo— es esta: si el cómputo ya no es la palanca dominante, ¿cuál lo es?

Su respuesta: lo que importa ahora es la tasa de retorno por unidad de cómputo, y esa tasa la impulsan cuatro cosas, de las cuales solo una es «más parámetros». Vamos por ellas en orden, porque cada una tiene implicaciones para cómo un equipo de ingeniería debería elegir modelos, diseñar pipelines de entrenamiento y presupuestar infraestructura en 2026.

1. Parámetros: rendimientos decrecientes y, después, rareza

En 2016, Inception tenía 23M de parámetros. En 2025, Qwen3-235B-A22B tiene 235.000 millones. Ese salto de cuatro órdenes de magnitud compró ganancias reales durante un tiempo. También ha dejado al descubierto un hecho profundamente incómodo: no entendemos por qué necesitamos la mayoría de esos pesos.

Hooker cita un cuerpo de trabajo que lo hace concreto:

• Puedes eliminar la mayoría de los pesos entrenados después del entrenamiento con pérdida mínima de rendimiento (Gale et al. 2019; Han et al. 2015; Evci et al. 2019; Hooker et al. 2020). Es el conocido resultado de sparsity / pruning.
• Pero —y aquí está el rompecabezas— no puedes alcanzar el mismo rendimiento si empiezas con la red pequeña desde el principio. Los pesos extra están haciendo algo durante el entrenamiento que ya no hacen en inferencia.
• Denil et al. (2014) demostraron que un pequeño conjunto de pesos puede usarse para predecir el 95 % de los pesos de una red. El espacio es enormemente redundante.

La explicación más simple es incómoda: las redes profundas son aprendices increíblemente ineficientes de la cola larga. Los patrones frecuentes se aprenden temprano y barato. Los raros —exactamente los que hacen que un modelo parezca «listo» en casos límite— requieren una cuota desproporcionada del cómputo y una cuota desproporcionada de los pesos, en buena parte porque entrenamos minimizando pérdida media y con exposición igual entre ejemplos. La señal de los atributos raros se diluye en las actualizaciones por lote.

Hooker llama a esto «construir una escalera hasta la luna»: progresas técnicamente, pero con una estructura de costes que no puede seguir pagando. Si aceptas ese diagnóstico, las siguientes tres palancas no son optimizaciones opcionales. Son la frontera real.

2. Calidad de datos: la palanca en la que todo el mundo invierte de menos

La calidad de los datos compensa el cómputo. Hooker reúne un cuerpo amplio de evidencia —deduplicación, poda de datos, priorización de datos— que muestra que un corpus de entrenamiento mejor curado reduce el número de parámetros necesario para alcanzar una capacidad dada. Según Marion et al. (2023), Penedo et al. (2023), Singh et al. (2024b) y otros, datasets más pequeños bien curados pueden igualar o superar a otros mayores usados de cualquier manera. El tiempo de entrenamiento cae directamente, y el ahorro de cómputo es estructural, no incremental.

¿Por qué la industria invierte de menos aquí de forma crónica? Por tres razones que cualquiera que haya gestionado un equipo de ML reconocerá:

1. El trabajo de curación no encaja en una planificación trimestral. «Limpiar datos» es un verbo que no cabe en un slide de roadmap. «Entrenar un modelo 10× mayor», sí.
2. El cómputo se compra; los datos curados se construyen. Puedes mandarle dinero a NVIDIA y tener GPUs el trimestre que viene. No puedes mandar dinero y tener un corpus limpio, deduplicado, equilibrado y con licencias claras el trimestre que viene.
3. Las métricas de éxito se manipulan. Las mejoras en benchmarks por calidad de datos pintan idénticas en una gráfica a las mejoras por escala, así que el crédito va a quien gritó más fuerte sobre escalar, no al equipo de datos que hizo la deduplicación en silencio.

El cambio que describe Hooker —de los datos como snapshot congelado (MNIST, ImageNet, SQuAD) a los datos como objeto maleable y optimizable— es uno de los giros de paradigma más importantes del ensayo. Es también donde existen los retornos más asimétricos para equipos que no tienen presupuesto de hyperscaler pero sí tienen expertise de dominio. Volveremos a esto en la parte 3 bajo «el espacio maleable de los datos».

3. Técnicas algorítmicas: la composición silenciosa

La tercera palanca es la más infravalorada, sobre todo porque no llega como un gran avance único sino como un goteo continuo de técnicas que individualmente parecen optimizaciones menores. Hooker enumera una lista parcial de lo que ha compensado al cómputo bruto en los últimos años:

• Instruction fine-tuning. Enseñar a los modelos a seguir instrucciones sobre el preentrenamiento.
• Distilación desde modelos profesores más grandes. Un «estudiante» pequeño y capaz, entrenado con datos sintéticos de un «profesor» mayor, puede aproximarse al profesor con una fracción del coste de inferencia.
• Chain-of-thought reasoning. Un patrón de prompting y entrenamiento que mejora el rendimiento multipaso sin cambio de cómputo en entrenamiento.
• Aumento del contexto. Cambios arquitectónicos y de atención que dejan al mismo modelo condicionar sobre mucha más información en inferencia.
• Retrieval-augmented generation. Externaliza la cola larga de hechos a una capa de recuperación. Reduce alucinaciones, reduce la necesidad de memorizar, reduce la presión sobre los parámetros.
• RLHF y preference training. Constitutional AI, DPO, RLOO y otras variantes cambian el comportamiento de forma sustancial sin requerir proporcionalmente más parámetros.

Davidson et al. (2023) estiman que las técnicas puramente de cómputo en inferencia pueden ofrecer mejoras de 5× a 20× sobre el rendimiento base post-entrenamiento. Esa cifra merece que te sientes con ella un momento. Una mejora de capacidad de 10× que requiere cero reentrenamiento es justo el tipo de cosa que rompe las hojas de ruta de «el año que viene, modelo más grande».

Para los equipos de ingeniería, la lección práctica es: la mayor parte de tu hoja de ruta de IA debería ser algorítmica, no de capacidad. Vas a sacar más palanca de añadir una capa de retrieval bien implementada, una pasada de verificación, un modelo destilado específico de tarea o una estructura de prompt en chain-of-thought que de esperar al próximo escalón de tamaño de modelo.

4. Arquitectura: el techo

La arquitectura es la palanca que todo el mundo subestima porque se mueve pocas veces. Pero cuando se mueve, resetea todas las leyes de escalado que vinieron antes. Hooker es directa:

Un nuevo diseño arquitectónico puede cambiar fundamentalmente la relación entre cómputo y rendimiento, y dejar irrelevante cualquier ley de escalado existente.

Tenemos los recibos históricos. Las CNN cambiaron la relación para visión (Ciresan et al. 2011; Krizhevsky et al. 2012; Szegedy et al. 2014). Los transformers cambiaron la relación para lenguaje (Vaswani et al. 2017). Cada uno fue un cambio de paradigma que dejó obsoletas las curvas previas de cómputo-rendimiento y desbloqueó una década entera de trabajo posterior.

Es casi seguro que toca otro. El ensayo es contundente: la arquitectura actual «muestra todos los signos de un meseta en los retornos por cómputo adicional» y «el siguiente paso significativo requerirá una arquitectura completamente distinta». Las redes profundas son particularmente malas en:

• Aprendizaje continuo —sufren olvido catastrófico cuando los datos nuevos interfieren con comportamientos viejos.
• Especialización del conocimiento —las actualizaciones de gradiente globales no tallan regiones de competencia como sí hacen los sistemas biológicos.
• Eficiencia de muestras —necesitan muchísimos más ejemplos que un niño humano para tareas comparables.

Una nueva arquitectura que arreglase aunque fuese una sola de estas cosas barajaría todo el paisaje de nuevo. Por eso concentrar todo el capex en escalar la arquitectura actual es, en el marco de Hooker, infrainvertir en la fuente más probable del próximo salto.

Qué cambia esto para los líderes de ingeniería

Juntando las cuatro palancas, esto es lo que me llevaría a una conversación de planificación en el Q3 de 2026:

• Deja de rankear modelos por número de parámetros. Rankéalos por capacidad-por-token-por-dólar sobre tu mix real de tareas. La correlación entre número de parámetros y ese ratio es ya débil.
• Sube la ingeniería de datos en el organigrama. Si no tienes a una persona sénior dueña de la curación, la deduplicación, el cumplimiento de licencias y la priorización de datos, estás dejando la mayor palanca gratuita tirada en el suelo.
• Trata las mejoras algorítmicas como el primer movimiento por defecto. Antes de encargar un fine-tune o un despliegue de modelo más grande, agota: retrieval, estructura del prompt, pasadas de verificación, distilación, uso de herramientas, chain-of-thought. La mayoría de equipos tira la toalla en esta capa demasiado pronto.
• Sigue los cambios de arquitectura en serio. Cuando aterrice la próxima arquitectura post-transformer (y aterrizará), los equipos que hayan sobreinvertido en infraestructura con forma de transformer —pipelines, ops, compromisos con proveedores— serán los más lentos en adaptarse. La diversidad arquitectónica en tu stack es una cobertura.
• No confundas «estrategia de IA» con «selección de modelo». El modelo es una decisión entre muchas. Los datos, el retrieval, la verificación, el diseño con human-in-the-loop —ahí es donde ocurre el trabajo diferenciado.

El marco de Hooker —tasa de retorno por unidad de cómputo— es el que hay que internalizar. Saca la conversación de «cómo de grande» y la lleva a «cuánta capacidad por unidad de coste y qué palancas la mueven». Esa es una conversación que los equipos de ingeniería pueden ganar de verdad, y una que los CFO pueden valorar de verdad.

---

Siguiente en esta serie: Más allá del escalado: los nuevos espacios de optimización para el progreso de la IA. Métodos sin gradiente, el cómputo en inferencia como palanca de primera clase, el espacio maleable de los datos, los sistemas agénticos y lo que la muerte del escalado significa (y lo que no) para el impacto ambiental.