(2/3) 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 toca decisiones que yo afronto de verdad como CTO: qué modelos elegir, cómo diseñar los pipelines de entrenamiento y qué infraestructura presupuestar para 2026.

1. Parámetros: rendimientos decrecientes y, después, terreno extraño

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 rindió mejoras 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 aterriza:

• 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.

El contraargumento justo: escalar sigue funcionando. Todos los modelos frontera del último año se entrenaron a una escala enorme, y los laboratorios que firman los cheques más grandes saben leer una curva de pérdida. Concedido. Pero «sigue funcionando» no es la misma afirmación que «mejor retorno de la siguiente unidad de cómputo» — y la segunda es a la que responde de verdad tu presupuesto.

Hooker llama a esto «construir una escalera hasta la luna»: progresas técnicamente, pero con una estructura de costes que no puede seguir compensando. 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 infrainvierte

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 sin criterio. El tiempo de entrenamiento cae directamente, y el ahorro de cómputo es estructural, no incremental.

¿Por qué la industria infrainvierte 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 una diapositiva 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: el interés compuesto silencioso

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.
• Destilació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. Merece la pena detenerse en esa cifra. 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 ganar más añadiendo 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 esperando al próximo escalón de tamaño de modelo.

4. Arquitectura: la que fija el techo

La arquitectura es la palanca que todo el mundo subestima porque se mueve pocas veces. Pero cuando se mueve, pone a cero 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.

La historia lo avala. 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 una 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 reordenaría el tablero por completo. 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 clasificar modelos por número de parámetros. Clasifícalos 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 desaprovechando la mayor palanca gratuita que existe.
• 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, destilación, uso de herramientas, chain-of-thought. La mayoría de equipos tira la toalla en esta capa demasiado pronto.
• Tómate en serio los cambios de arquitectura. 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 un seguro.
• 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 a la que los CFO pueden ponerle precio.

---

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.