Hay una frase que repito tanto en el trabajo que mi equipo ya debe estar cansado de escucharla: no siempre necesitamos el modelo más grande. La digo cuando alguien propone, casi por reflejo, usar el modelo más potente disponible para una tarea que un modelo más chico resolvería igual de bien, más rápido y por una fracción del costo. La digo porque vi demasiadas veces esa tentación de ir directo a lo más caro y poderoso, como si la potencia fuera siempre una virtud y nunca un desperdicio. Y la vuelvo a pensar ahora, leyendo los informes que empezaron a circular este año sobre cuánta energía y cuánta agua consume todo este entusiasmo por la IA, porque me confirman algo que ya intuía desde el lado del presupuesto y la arquitectura: cada vez que elegimos más potencia de la que la tarea necesita, alguien paga la diferencia. A veces es nuestra factura. A veces es la red eléctrica de una región. A veces es una cuenca de agua que ya estaba bajo estrés. La eficiencia, que durante años tratamos como una optimización opcional para cuando sobra tiempo, se está volviendo una forma de responsabilidad. De eso quiero hablar.
La tentación de ir siempre a lo más grande#
Hay un reflejo muy extendido en el mundo de la tecnología, y con la IA se volvió casi automático: ante cualquier tarea, elegir lo más potente disponible. Si hay un modelo más grande, más nuevo, con mejores números en los benchmarks, lo usamos, sin preguntarnos demasiado si la tarea lo justifica. Es una decisión que se siente segura —nadie te critica por usar lo mejor— y que además es cómoda, porque evita el trabajo de pensar qué necesita realmente cada caso.
Pero esa comodidad tiene un costo, y no es chico. Usar un modelo enorme para clasificar un texto simple, para extraer un dato de un formulario o para responder una pregunta trivial es como contratar una excavadora para plantar una maceta. Funciona, claro que funciona. Pero pagamos de más, esperamos de más, y consumimos muchísimo más de lo que la tarea pedía. La diferencia entre la excavadora y la pala no se nota cuando hay una sola maceta. Se nota cuando son millones de macetas por día, que es exactamente la escala a la que opera la IA cuando la metemos en producción. Lo que en una prueba aislada parece un detalle insignificante, multiplicado por el volumen real de uso, se transforma en una cuenta que alguien tiene que pagar.
Lo que los informes de este año nos están mostrando#
Vale la pena detenerse un momento en por qué este tema dejó de ser una preocupación abstracta. Este año empezaron a publicarse análisis más serios sobre el consumo energético de la inteligencia artificial, y los números, aunque haya que tomarlos con cuidado, son lo bastante grandes como para que no podamos seguir ignorándolos. La Agencia Internacional de la Energía, en su informe sobre energía e IA de este año, estima que el consumo eléctrico de los centros de datos —una porción creciente de ellos dedicada a IA— podría más que duplicarse hacia el final de la década. Y aparece un dato que para mí es el más revelador, porque desarma una idea muy instalada: lo que más pesa en el consumo no es entrenar los modelos, sino usarlos.
Solemos imaginar que el gran costo ambiental de la IA está en ese momento dramático del entrenamiento, esos meses de cómputo intensivo para crear un modelo. Y es cierto que entrenar consume muchísimo. Pero el entrenamiento se hace una vez; el uso, en cambio, ocurre millones de veces por día, todos los días, para siempre. Cada consulta, cada respuesta, cada tarea que le delegamos a un agente, suma. Y esa suma, sostenida en el tiempo y multiplicada por una cantidad de usuarios que no para de crecer, termina pesando más que el entrenamiento que tanto nos impresiona. A esto se le agrega el costo del agua: los centros de datos necesitan enfriarse, y ese enfriamiento consume agua dulce, a veces en regiones que ya la tienen escasa. Es un costo todavía más invisible que el de la electricidad, porque ni siquiera aparece en la factura que miramos.
No traigo estos números para sumarme al coro alarmista, que de eso ya hay bastante y no aporta mucho. Los traigo porque le ponen evidencia a algo que, desde el lado de la ingeniería, ya sabíamos sin necesidad de informes: cada decisión técnica tiene un costo, y cuando ese costo se multiplica por la escala, deja de ser despreciable. La novedad no es que la IA consuma. La novedad es que ahora tenemos dimensión de cuánto, y que ese cuánto depende, en buena parte, de decisiones que tomamos nosotros.
El costo que no aparece en el dashboard#
Acá está el centro de lo que me interesa. Cuando elegimos un modelo, miramos cosas que son fáciles de ver: si funciona, qué tan bien responde, cuánto sale por consulta. Lo que casi nunca miramos es la cadena de costos que se dispara detrás de esa elección y que no figura en ningún tablero. El costo energético de cada inferencia. El agua del enfriamiento. La carga sobre una red eléctrica. La huella que, sumada a la de todos los demás que tomaron la misma decisión cómoda, se vuelve un problema colectivo.
Es la misma lógica de las dependencias invisibles de las que escribí hace un par de meses, solo que aplicada al consumo: lo que no medimos, no lo gestionamos, y lo que no vemos, lo damos por gratis. Un equipo mira su dashboard, ve que la latencia está bien y que el costo por consulta es bajo, y concluye que todo está en orden. Pero el dashboard no muestra que ese mismo resultado se podía conseguir con un modelo tres o cinco veces más eficiente, que habría consumido una fracción de la energía. No muestra el costo de la sobrepotencia, porque la sobrepotencia no rompe nada: simplemente desperdicia, silenciosamente, a una escala que solo se vuelve visible cuando alguien se sienta a sumar. Y casi nadie se sienta a sumar, porque mientras funcione, parece que no hay problema.
Elegir el modelo correcto es una decisión de diseño#
Quiero ser claro en algo, porque es la idea que más me importa transmitirle a mi equipo: elegir qué modelo usar no es un detalle de configuración, es una decisión de arquitectura. Tan importante como elegir una base de datos, un patrón de diseño o una estrategia de caché. Y como toda decisión de arquitectura, merece criterio, no reflejo.
La pregunta correcta nunca es “¿cuál es el modelo más potente?”, sino “¿qué necesita realmente esta tarea?”. Hay tareas que requieren razonamiento profundo, varios pasos, manejo de ambigüedad, y ahí un modelo potente se justifica plenamente. Pero hay muchísimas otras —clasificar, extraer, resumir algo corto, responder preguntas acotadas, transformar un formato en otro— que un modelo más chico resuelve con la misma calidad, más rápido y con una fracción del consumo. Tratar a todas las tareas como si necesitaran lo máximo es, en el fondo, no haber pensado el problema. Es delegar en la fuerza bruta lo que debería resolver el criterio. Y la fuerza bruta, ya lo escribí cuando hablé de aquel modelo que sacudió a la industria a principios de año, tiende a adormecer el ingenio: cuando tenemos potencia de sobra, dejamos de preguntarnos si la estamos usando bien.
La buena noticia es que pensar esto no solo ahorra recursos; casi siempre mejora el sistema. Un modelo más chico y adecuado suele responder más rápido, lo que mejora la experiencia. Cuesta menos, lo que libera presupuesto para otras cosas. Consume menos, lo que reduce la huella. Rara vez elegir bien el modelo es un sacrificio; lo más común es que sea, simplemente, una mejor decisión en todas las dimensiones a la vez. La sobrepotencia no nos estaba dando nada a cambio de lo que costaba.
No es un modelo, son varios según la tarea#
Hay una consecuencia práctica de todo esto que conviene hacer explícita, porque cambia cómo diseñamos un sistema. La pregunta “¿qué modelo usamos?” suele plantearse como si hubiera que elegir uno solo para todo el producto, y esa es justamente la trampa. Un sistema real rara vez hace una sola cosa: clasifica, extrae, resume, razona, conversa, decide. Y cada una de esas cosas tiene exigencias distintas. Pretender que un único modelo, el más grande, atienda todo por igual es cómodo de configurar, pero es casi siempre la peor opción, porque significa pagar el precio del caso más exigente para resolver también los más triviales.
Lo que tiene sentido, y es lo que trato de empujar cuando diseñamos, es pensar en términos de varios modelos conviviendo en el mismo sistema, cada uno en la tarea donde rinde mejor. Un modelo chico y veloz para la clasificación inicial o la extracción simple, que resuelve el grueso del volumen. Un modelo más potente reservado para los casos que de verdad lo necesitan, esos que llegan después de un primer filtro y que justifican el gasto. A veces incluso una cascada: empezar barato, y escalar a algo más caro solo cuando el caso lo amerita. No es una idea exótica ni nueva; es el mismo principio de siempre, el de poner cada recurso donde aporta más, aplicado a una caja de herramientas que ahora incluye modelos de distinto tamaño.
Esto exige un poco más de trabajo de diseño que elegir un modelo único y olvidarse, no lo voy a negar. Hay que entender el flujo, separar las tareas, decidir los umbrales. Pero ese trabajo se paga solo, y rápido: en costo, en velocidad, en consumo. Y tiene un beneficio extra que me parece el más valioso a largo plazo: obliga al equipo a entender el sistema por partes, a saber qué hace cada pieza y por qué, en lugar de tirarle el modelo más grande encima a un problema que nunca terminamos de mirar de cerca. La pereza de usar uno solo para todo no solo cuesta más; también nos deja entendiendo menos lo que construimos.
No usemos un cañón para matar una mosca#
Hay un dicho viejo que viene perfecto acá: no hace falta un cañón para matar una mosca. Y sin embargo, en el mundo de la IA, lo vemos todo el tiempo. Alguien tiene que resolver una tarea mínima —clasificar un texto, sacar un dato de un formulario, responder algo acotado— y apunta directo con el modelo más potente, el cañón, contra una mosca que se mataba con la mano. El resultado es el mismo, sí: la mosca muere. Pero gastamos en pólvora, en estruendo y en humo muchísimo más de lo que el problema pedía, y encima nos quedamos con la sensación de haber hecho un buen trabajo porque, total, la mosca está muerta.
Saber cuándo hace falta el cañón y cuándo alcanza con la mano no es un detalle menor: es, para mí, una de las habilidades que definen a un buen profesional de la IA. Y subrayo lo de habilidad, porque no es algo que venga incluido con la herramienta ni que se aprenda leyendo la documentación. Es criterio, y el criterio se construye con experiencia. Elegir bien la potencia que usamos para cada tarea es exactamente el tipo de decisión donde se nota el oficio de quien la toma. El que recién empieza tiende a ir a lo más grande, por las dudas, porque todavía no tiene la intuición de cuánto necesita cada problema. El que lleva años entiende, casi sin pensarlo, que la mayoría de las tareas no necesitan el tope, y reserva la artillería pesada para cuando de verdad hace falta.
La potencia adecuada también es cuestión de experiencia#
Esto conecta con algo que ya escribí cuando hablé de quienes recién empiezan a programar con IA, y que vale la pena retomar acá desde otro ángulo. Dije entonces que la IA acelera muchísimo a alguien que ya tiene criterio, pero que a alguien que todavía no lo tiene puede darle una falsa autonomía. Con la elección del modelo pasa algo parecido. No es lo mismo un junior que una persona que hace quince años escribe software. No porque el junior sea menos inteligente —muchas veces es más rápido y más audaz—, sino porque la elección de la herramienta justa se apoya en algo que solo da el tiempo: haber visto muchos problemas, haberse equivocado eligiendo de más y de menos, haber pagado las dos cuentas y haber aprendido a anticiparlas.
Quien tiene experiencia le saca más provecho a la IA, justamente, porque sabe pedirle lo correcto y elegirle el tamaño correcto. Reconoce de un vistazo cuándo una tarea es trivial y cuándo esconde una complejidad que va a requerir más. Sabe que pagar por una capacidad que la tarea nunca va a usar no es prudencia sino desperdicio, y sabe distinguir los pocos casos donde esa capacidad de más sí se justifica. El junior, en cambio, todavía está construyendo esa intuición, y mientras la construye va a tender a sobredimensionar, porque lo más grande se siente más seguro. Eso no es un defecto a castigar; es una etapa del aprendizaje. Pero sí es algo que, como líderes de equipo, tenemos que acompañar: enseñar a elegir bien la potencia es parte de formar a alguien, igual que enseñarle a elegir bien una estructura de datos o a no resolver con tres servicios lo que se resuelve con uno.
Por qué esto importa más allá del bolsillo#
Ahora bien, alguien podría decirme: si el modelo grande funciona y me lo puedo pagar, ¿cuál es el problema de usar el cañón? Y acá quiero ser cuidadoso, porque no me interesa dar lecciones de moral ni sumarme al discurso de que vamos a destruir el planeta por usar desodorante. Ese tipo de culpa difusa y exagerada me parece tan inútil como contraproducente. No se trata de cargar a cada desarrollador con el peso del cambio climático cada vez que hace una llamada a un modelo; eso sería absurdo y paralizante.
Lo que sí creo es que elegir bien la potencia tiene varias consecuencias buenas que se acumulan, y conviene tenerlas todas en la cabeza, no solo una. Está la económica, la más obvia: gastar lo justo libera presupuesto para otras cosas. Está la operativa: un modelo más chico y adecuado suele responder más rápido, lo que mejora la experiencia de quien usa el producto. Y está, sí, la ambiental, pero en su justa medida: a la escala a la que opera la IA, elegir consistentemente más potencia de la necesaria sí tiene un costo energético e hídrico real, y desperdiciarlo por comodidad cuando podríamos no hacerlo es, simplemente, una mala práctica. No lo planteo como una cruzada, sino como lo que es: una de las varias razones por las que vale la pena elegir con criterio, no la única ni la principal. La principal, para mí, sigue siendo profesional: usar la herramienta justa es, antes que nada, hacer bien nuestro trabajo.
Durante mucho tiempo, en software, el consumo de recursos fue invisible para quien programaba: alguien más pagaba la factura del servidor, alguien más se ocupaba de la infraestructura, y uno podía darse el lujo de no pensar en eso. La IA, por su escala, nos vuelve a poner esa cuenta delante de los ojos, y nos da la oportunidad de recuperar un hábito que nunca debió perderse: el de elegir con conciencia de lo que cada decisión cuesta. No por culpa, sino por oficio. El buen ingeniero nunca fue el que tira más recursos al problema; fue el que entiende tan bien el problema que la solución resulta justa.
Lo que le digo al equipo#
Cuando trabajo este tema con mi equipo, trato de que no quede en un principio abstracto, porque los principios abstractos no cambian decisiones. Lo bajo a preguntas concretas que conviene hacerse antes de elegir un modelo para algo que va a producción. ¿Esta tarea necesita de verdad razonamiento complejo, o es algo acotado y repetitivo? ¿Probamos si un modelo más chico la resuelve con calidad suficiente, o fuimos directo al más grande por las dudas? ¿Sabemos cuánto cuesta esta elección multiplicada por el volumen real que vamos a tener, no por la única consulta de la prueba? ¿Estamos pagando por una capacidad que esta tarea nunca va a usar?
Esa última pregunta es la que más me gusta, porque desarma de raíz la falsa sensación de seguridad de “usemos lo mejor por las dudas”. Esa coartada del “por las dudas” es, casi siempre, una forma elegante de no haber pensado el problema. Cuando un equipo se acostumbra a hacerse estas preguntas antes de elegir, pasa algo más profundo que ahorrar recursos: empieza a entender mejor lo que construye, porque para responderlas hay que mirar cada tarea de cerca en lugar de taparla con potencia. Y un equipo que entiende lo que construye toma mejores decisiones en todo lo demás, no solo en la elección del modelo.
La eficiencia no es lo contrario de la ambición#
Me importa aclarar algo para no ser malinterpretado, porque este discurso puede sonar a “usemos menos IA” y no es eso. No estoy en contra de la potencia ni de los modelos grandes; son maravillosos y resuelven problemas que antes eran impensables. Estoy en contra de usarlos por defecto, sin criterio, para todo. La eficiencia bien entendida no es renunciar a la ambición: es ser ambicioso con cabeza. Es querer resolver problemas grandes usando exactamente lo que hace falta, ni más ni menos. Y elegir ese “exactamente” es, otra vez, una cuestión de oficio: cuanto más sabe quien decide, más fina es la puntería.
Y hay algo lindo en esto, que me reconcilia con el tema más allá de la preocupación por el consumo: pensar en eficiencia nos obliga a entender mejor lo que hacemos. Para elegir el modelo justo hay que entender de verdad la tarea, sus requisitos, sus límites. Esa comprensión, ese trabajo de pensar antes de elegir, es lo que separa a un equipo que opera con criterio de uno que va apilando potencia sobre potencia esperando que la fuerza compense la falta de claridad. La eficiencia, al final, es un subproducto de pensar bien. Y pensar bien nunca pasó de moda.
Me quedo con una pregunta para dejarles, porque este tema recién empieza a ocupar el lugar que merece en las conversaciones técnicas. La próxima vez que vayamos a elegir, casi por reflejo, el modelo más potente para una tarea nueva, ¿nos vamos a tomar el minuto incómodo de preguntarnos si de verdad lo necesita, o vamos a seguir tratando la potencia como si fuera gratis solo porque su costo no aparece en el dashboard que miramos? Porque el costo está ahí igual, lo veamos o no. Y una parte de madurar como técnicos, creo, es aprender a hacernos cargo justamente de lo que no se ve.
Fuentes consultadas#
- Agencia Internacional de la Energía (IEA), “Energy and AI”, abril de 2025.
- Pengfei Li, Jianyi Yang, Mohammad A. Islam, Shaolei Ren, “Making AI Less ‘Thirsty’: Uncovering and Addressing the Secret Water Footprint of AI Models”, University of California, Riverside, 2023.