De los 512 KB a la Luna
¿Optimizar o escalar hasta el infinito?
Hace unas décadas, en una tienda de computadoras, un vendedor intentó convencerme de comprar una Kaypro con 512 KB de RAM. Su argumento era impecable:
“Con el tiempo, los programas serán más eficientes y necesitarán menos memoria”.
En esa época, 640 KB era la norma. Más que suficiente, según el imaginario popular que luego se atribuyó a Bill Gates.
Hoy me escucho a mí mismo diciendo algo parecido, pero en otro contexto. Hablamos de modelos de IA cada vez más grandes, de GPUs que consumen cientos de watts, de data centers que parecen ciudades industriales. Y mi argumento suena razonable:
“No necesitamos frenar el progreso. Necesitamos modelos más potentes, pero más eficientes”.
Y entonces me pregunto:
¿Estoy repitiendo la misma fe tecnológica del vendedor?
¿O esta vez es diferente?
La historia no es lineal
La computación ha seguido dos fuerzas en tensión permanente:
- Escalar hardware
- Optimizar software
Durante décadas, la abundancia energética y la caída de precios del hardware favorecieron la primera. Si el programa era lento, le “echábamos” más RAM. Si el servidor se saturaba, se añadía otro. La ley de Moore funcionó como anestesia colectiva: el problema del rendimiento se resolvería solo.
Pero esa comodidad tenía un costo invisible. Cada capa adicional de abstracción, cada framework, cada runtime, aumentaba el consumo de recursos. Y mientras la energía era barata, nadie preguntaba demasiado.
La era de los modelos gigantes
Con la inteligencia artificial, la escala volvió a dominar la conversación. Modelos más grandes producen mejores resultados. Más parámetros, más datos, más GPUs.
Figuras como Eric Schmidt, ex CEO de Google, han planteado que el crecimiento energético de la IA podría empujarnos a soluciones fuera de lo convencional, incluso infraestructura energética más allá de la Tierra. La idea de aprovechar energía solar fuera de la atmósfera ya no suena tan descabellada.
La pregunta no es si es técnicamente posible.
La pregunta es si es sostenible.
¿Optimización por escasez?
Históricamente, la optimización no surge por virtud, sino por restricción.
Los primeros programadores optimizaban porque no había memoria.
Los ingenieros embebidos optimizaban porque cada byte costaba.
Los desarrolladores de videojuegos optimizaban porque cada frame importaba.
La abundancia relaja la disciplina.
La escasez la reintroduce.
Si la memoria sube de precio.
Si la energía se vuelve un cuello de botella real.
Si las regulaciones ambientales se endurecen.
Entonces la optimización deja de ser elegancia técnica y se convierte en supervivencia económica.
¿Es imposible revertir la tendencia?
No necesariamente.
Ya estamos viendo señales de un giro:
- Modelos destilados que mantienen rendimiento con menos parámetros
- Cuantización agresiva
- Inferencia eficiente en dispositivos locales
- Arquitecturas especializadas como chips diseñados para cargas específicas
La historia no dice que siempre necesitaremos más recursos.
Dice: que siempre usaremos los recursos disponibles.
Si la energía es abundante, la consumiremos.
Si es escasa, optimizaremos.
El verdadero dilema
Mi temor no es que la optimización sea imposible.
Mi temor es que culturalmente nos hayamos acostumbrado a escalar antes que a comprender.
Comprar más memoria es más fácil que reescribir un algoritmo.
Entrenar un modelo más grande es más fácil que investigar una arquitectura más elegante.
Pero las revoluciones técnicas profundas suelen venir de la segunda opción.
La Luna o la eficiencia
Podemos imaginar data centers en la Luna alimentados por energía solar perpetua.
O podemos imaginar una nueva generación de ingenieros obsesionados con hacer más con menos.
Probablemente ocurran ambas cosas.
La historia de la computación nunca ha sido elegir entre escalar u optimizar. Ha sido una danza entre ambas.
La pregunta no es si caeremos en el mismo error del vendedor del Keypro.
La pregunta es si sabremos reconocer cuándo la abundancia es una ilusión y cuándo la escasez es una oportunidad.
Y quizás, esta vez, tengamos la madurez para no depender únicamente de que el hardware nos salve.
Compartir:
¿Te gustó este artículo? Apoya este blog y ayuda a que siga creciendo.
Invítame un café