Llevo algo más de un año compartiendo con todos mis amigos en corto uno de los problemas que hoy en día comienza a ser un dolor de cabeza en muchas empresas, que es lo que yo llamo la "Predictibilidad de los costes de la IA". Una fuerza de empleados humanos te da una predictibilidad de costes con la que puedes hacer un presupuesto más o menos claro, pero con el uso indiscriminado de la IA y los límites en consumo de tokens, es difícil tener esa predictibilidad, y aprender a gestionar eso es una nueva disciplina en las organizaciones.
Figura 1: Cómo optimizar el gasto en IA con arquitecturas clasificadas, orquestadas y/o destilación. El problema de la Predictibilidad de los Costes de la IA.
Imagen: Nano Banana.
Es verdad que algo no es caro o barato simplemente por su coste, ya que puede ser que por el mismo coste tu fuerza laboral con IA esté entregando mucha más productividad en mucho menos tiempo, o puede pasar justo lo contrario, que estemos gastando el mismo budged en IA en la mitad de tiempo, pero estemos entregando dashboards y tools que son "nice-to-have" pero que no tengan un impacto real en el negocio. Las dos posibilidades existen, y será un éxito o no para la compañía, si esta es capaz de racionalizar, ya no tanto el consumo, sino el qué se quiere hacer con IA.
Pero no estoy hoy para hablar de eso, que seguro que os hablaré en algún artículo ulterior, que también tengo mis reflexiones sobre cómo se está usando la IA en muchas empresas, sino sobre las soluciones tecnológicas de arquitectura que yo he estado discutiendo con clientes, y compañeros, para proponer soluciones de optimización de costes en el uso de la IA.
El planteamiento de partida es que tenemos una empresa que está haciendo un consumo útil de tokens de IA pero quiere optimizar el coste, pues bien, existen diferentes soluciones arquitecturas, que los ingenieros de software de tu empresa - incluso haciendo uso de IA - te pueden ayudar a construir, basadas en estas ideas. A ver qué os parecen.
Clasificiación Funcional: IA, ML o Algorítmica clásica
Esta es una decisión fundamental y muy clara desde el principio. Su base es tan sencilla como dado un servicio digital que hace uso de la IA, decidir cómo se debe construir cada funcionalidad y solución algorítima debe estar detrás es fundamental.
Responder a un "Hola" o realizar una operación sencilla como "suma 2+2" no requiere que te gastes tokens en modelos de frontera, al igual que elegir qué anuncio poner. Para ello, se deben analizar bien de qué manera se debe construir cada función de un servicio digital, y esto debes clasificarlo en varios niveles:
- Tareas complejas de razonamiento: Aquellas que debes enviar a los modelos de Inteligencia Artificial y que van a marcar la diferencia en tu servicio.
- Tareas complejas de conocimiento: Para estas funciones, los algoritmos de Machine Learning son una opción perfecta. Si tienes los datos, en lugar de enviarlos vía contexto usando un RAG o un Graph RAG, la alternativa puede ser entrenar tu ML y generar el conocimiento como parte de tu sistema. El coste es infinitamente menor si haces tu ML y, además, controlas tus datos.
- Tareas de razonamiento sencillas: Aquellas que, aun requiriendo del uso de modelos de IA, pueden ser atendidas por SLMs, modelos LLM OpenSource, o simplemente más económicos.
- Tareas Algorítmicas: Aquellas que puedes realizar co un algoritmo clásico determinista. Hemos estudiado muchos años los algoritmos de divide y vencerás, rectas de barrido, grafos, recursivos, la factorización de código, los patrones de diseño y las técnicas de optimización, como para pensar que ahora todo tiene que ser un LLM de frontera.
Estos algoritmos resuelven una gran mayoría de las soluciones, y por tanto deben ser siendo el grosso de tu sistema informático. Si no es así, entonces es que estás IA-diotizado y piensas que todo debe ser IA.
Estas arquitecturas son claves para una arquitectura optimizada. Usar IA no debe ser una moda, sino la aplicación de una tecnología nueva a solucionar un problema que no se puede solucionar mejor de otra forma. Y cuando decimos "mejor" hay que incluir los parámetros importantes para la compañía, como son el resultado, los costes, el tiempo, etcétera.
Orquestación y Enrutamiento de Modelos
Centrándonos en las tareas de razonamiento, dependiendo de la complejidad, estas podrán ser resueltas por uno o varios modelos diferentes. Llevándolo al absurdo, responder a un
Prompt de "
Hola" o a uno de "
cuánto es dos más dos", o "
cuantos días han pasado del 1 de Enero de 1990 al 23 de Marzo de 2026", por ejemplo, pueden hacerlo todos, o muchos modelos.
Normalmente, una arquitectura no optimizada elige el modelo pensando en la tarea de razonamiento más compleja, que puede ser respondida sólo por uno, o por pocos Modelos Frontera, con lo que tenemos un sistema que, por culpa de la tarea más compleja, genera unos sobre-costes en las tareas más sencillas a realizar, que probablemente sean más. Para eso, antes de conectar un servicio digital a un solo modelo y que tire, utiliza algún sistema que permita cambiar el modelo en cada petición, y que te permita clasificar a qué modelo vas a enviarlo.
Esto no es nuevo, y
lo hace hasta el propio OpenAI en su arquitectura de GPT, y todos los servicios digitales que han visto crecer sus
tokens masivamente llegan aquí tarde o temprano. Así que, si vas a hacer un servicio digital, clasifica las tareas previamente, o hazlo con un
Módulo de Enrutamiento que clasifique los
Prompts en función de las peticiones en tu propio
AI Gateway, para que puedas optimizar dónde enviar cada
Prompt.
Prompt Shadowing
Para saber si puedes cambiar un modelo por otro más económico, una de las técnicas que debes utilizar es la de Prompt Shadowing. En este caso, cuando tu sistema digital envía a un Prompt con su contexto a un Modelo de Frontera, debes enviar esa misma tarea en paralelo al modelo más económico para poder compararlas y saber si lo está haciendo bien, suficiente bien, o mal.
Esta información te permitirá, adecuar las peticiones para que el modelo más económico las haga bien, probar diferentes modelos, detectar tareas que se pueden enviar al modelo más eficiente en costes, o pensar en una estrategia de Fine-Tuning o destilación para que el modelo más eficiente en costes tenga la calidad de las respuestas que necesitas.
Destilación de Conocimiento
Los modelos han aprendido, y aprenden, de los datos que se les dan. Tu sistema digital está proporcionando datos al
Modelo de Frontera, pero éste también te proporciona datos, en forma de respuestas. Este conocimiento
no debes perderlo nunca porque es tuyo y te puede servir para entrenar a un modelo más efectivo en costes que puedas correr en tu entorno con el conocimiento que has generado. A este proceso de
Fine-Tuning con conocimiento generado a partir de las respuestas a
Prompts de otro modelo se llama
Destilación.
Para ello, si tienes todos los datos de Prompt + Contexto y la Respuesta más si es posible los Metadatos (Razonamiento, Memoria e Historial) puedes hacer un entrenamiento de un modelo OpenSource con este conocimiento. Esto lo puedes hacer con Prompt Shadowing a través de tu API Gateway, AI Gateway o el CASB, y Destilar en el modelo objetivo periódicamente el conocimiento obtenido del Modelo Frontera con Prompt Shadowing.
Cuando el modelo objetivo más eficiente en costes haya aprendido a hacer las tareas igual de bien que el modelo frontera, entonces podrás cambiarlo. Por supuesto, este proceso no es fácil para un modelo completo generalista donde quieres destilar todo lo que sabe el Modelo Frontera de todas las áreas de conocimiento, pero cuando se trata de tu sistema, estas tareas suelen referirse a un único ámbito de conocimiento y con un número no-infinito de variaciones.
Sería como tener a un Senior de un Departamento enseñándole al Junior de ese Departamento cómo se hacen las tareas que tienen que ver con sus funciones. No le va a destilar conocimiento de Quantum-Mechanics, pero le va a enseñar a trabajar y razonar con los datos que maneja ese departamento y lo aprenderá perfectamente.
SaaS, Cloud u On-Prem
Pues todos, según tus costes. Los Modelos Frontera más potentes los vas a poder consumir normalmente solo en SaaS, pero si tienes un CASB, vas a poder hacer Prompt Shadowing para luego hacer un proceso de Fine-Tunning y Destilar el conocimiento en un modelo OpenSource que corras en tu propio IAS, o que corras en tu propia infraestructura.
Este tipo de soluciones, necesitan que desacoples tu servicio digital de tus modelos, y que tener flexibilidad para poder mover las
APIs y los
Prompts de uno a otro. Con esta filosofía se desarrolla la arquitectura de
Cloudflare para AI Gateway. Tú puedes conocer tu
API Gateway a los Guardarraíles, y estos al
backend del servidor, que puede estar en
Cloud u
On-Prem en tu
datacenter.
Luego, tu backend se conecta al
Modelo Frontera vía
CASB, o al modelo que quieras usando
AI Gateway que te permite elegir el que quieras en cada
Prompt. Esto te permite tener
observabilidad de los
Prompts y conectar todas la peticiones a múltiples modelos, con lo que podrías hacer
Prompt Shadowing para
Destilar y/o hace
Fine-Tunning de un modelo que corras directamente en
Cloudflare, o en tu propio servidor
On-Prem conectado por un túnel a
Cloudflare.
Con esta arquitectura, tu sistema te dará flexibilidad, no estarás "hand-cuffed" a las variaciones de precios que puedan surgir los paquetes empresariales de las compañías de IA que ofrecen Modelos Frontera y te asegurarás de tener siempre el conocimiento guardado en tus sistemas.
Orquestación de Agentes
Otra de las arquitecturas que puedes utilizar para reducir los costes, es decidir qué cosas vas a externalizar a agentes de terceros. En lugar de construirte toda la arquitectura, existe ya un mercado de Agentes AI que realizan tares con Prompts complejos.
Es el equivalente del uso de las APIs para acceder a funciones, pero delegando funciones de razonamiento complejas, y esto lo puedes hacer vía orquestación en el API Gateway o incluso en el MCP Server. Como es un tema chulo, le dedicaré otro artículo más adelante, porque este parece el futuro de la fuerza laboral de muchas empresas, y creo que merece la pena hablar de él en detalle.
Prompt Engineering
La última de las recomendaciones, lógicamente, tiene que ver con el Prompt Engineering. Hacer correctamente los Prompts, dirigir el razonamiento al camino más corto y eficiente de la respuesta. Dar el contexto adecuado y no más ni menos. Exigir las respuestas de manera clara y concisa, y un largo número de pequeños detalles, ayudan a reducir el número de tokens empleados en la respuesta y, por tanto, los costes.
Figura 11: Técnicas de optimización de Prompting 1
Esto es el equivalente al uso de índices correctamente, diseño de bases de datos siguiente las formas normales de Boyce-Codd, configuración de límites y memoria, uso de vistas o Cubos OLAP en el mundo de las bases de datos, pero llevado al mundo del Prompting y la los modelos LLM. Mucho por hacer aquí aún.
Figura 12: Técnicas de optimización de Prompting 2
Como podéis ver, basta con preguntarle a un modelo LLM por estas técnicas, y están bien documentadas hoy en día. Os he dejado las diez más importantes nada más, pero hay mucho juego por hacer aquí, porque no es lo mismo Prompting genérico, que Prompting para Desarrollo de Software, que para un sistema digital concreto.
Figura 13: Técnicas de optimización de Prompting 3
Por supuesto, esta es una disciplina muy novedosa, y las empresas están empezando a preocuparse por estos costes ahora, así que ir formándose en esta disciplina será igual de valioso a como lo fue el mundo del Tuning de Bases de Datos en mi época.
¡Saludos Malignos!
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
