Curso exprés · No. 31
Cada llamada a un modelo cuesta dinero y tiempo, medidos por token — y la factura escala con cuánto envías y con lo inteligente que sea el modelo que usas. Tratar el coste y la velocidad como restricciones de diseño, no como algo de última hora, es lo que separa una demo que funciona una vez de un producto que corre de forma asequible a escala. Aprende las palabras y las palancas, y «hazlo más barato» se vuelve rutina en lugar de crisis.
Solo lo esencial · Una imagen por idea · El coste es una restricción de diseño
Para controlar el coste de una funcionalidad de IA, primero tienes que entender el contador. Los modelos se facturan por token, y casi toda decisión económica se desprende de lo que eso significa.
El token es la unidad de coste
Un taxímetro que cobra por kilómetro — el precio del viaje no es una tarifa plana, es la distancia recorrida, que va subiendo todo el camino.
Un token es un fragmento de texto — aproximadamente una palabra o un trozo de una — y es la unidad en la que se te factura. Cada llamada a un modelo cuesta una cantidad basada en el número de tokens implicados, igual que un taxi cobra por distancia. Este es el hecho fundacional de la economía de la IA: no pagas por petición a tarifa plana, pagas por el volumen de texto que el modelo lee y escribe. Una vez que ves el token como el contador, el coste de todo se vuelve legible.
Pagas tanto por lo que entra como por lo que sale
Una llamada telefónica en la que se te factura tanto lo que dices como lo que oyes — cuenta toda la conversación, no solo tu mitad.
Se te cobra por los input tokens (todo lo que envías — el prompt, el contexto, el historial) y por los output tokens (todo lo que el modelo genera). Cuentan ambas mitades, y un contexto largo que envías en cada llamada cuesta cada vez, aunque la respuesta sea corta. Por eso una funcionalidad que mete un contexto enorme en cada petición es cara sin importar el tamaño de la salida — pagas toda la conversación, en ambas direcciones, en cada una de las llamadas.
El coste escala con el contexto y el número de llamadas
Un servicio de mensajería que factura por paquete y por kilómetro — tu total es cuántos viajes por la distancia de cada uno. Recorta cualquiera de los dos y la factura baja.
Tu coste total tiene dos multiplicadores: cuántos tokens por llamada (impulsado sobre todo por cuánto contexto envías) y cuántas llamadas haces (impulsado por lo parlanchín que sea tu diseño — una sola llamada, una cadena fija, o un agente que da muchas vueltas). Un contexto largo multiplicado a lo largo de muchas llamadas es cómo explotan las facturas de IA. Ambas palancas están en tu control, y casi toda técnica de ahorro de coste en este curso consiste en realidad en tirar de una de ellas: envía menos por llamada, o haz menos llamadas.
Los modelos facturan por token, tanto por input como por output. Tu coste es tokens-por-llamada por número-de-llamadas — así que todo ahorro se reduce a enviar menos o llamar menos.
El instinto es usar el modelo más inteligente para todo. Ese instinto es caro, porque la brecha de precio entre modelos es enorme y la mayoría de las tareas no necesitan lo más alto de la gama.
Los modelos varían enormemente en precio y potencia
Una flota de vehículos desde una bicicleta hasta un camión de carga — costes por viaje muy distintos, y usar el camión para entregar una sola carta es mucho dinero para el trabajo.
Hay un amplio espectro de modelos, desde pequeños y baratos hasta grandes y caros, y la diferencia de precio entre el de arriba y el de abajo suele ser enorme — muchas veces mayor por token. El frontier model más grande e inteligente es drásticamente más costoso que uno pequeño. Así que la elección del modelo es una de las mayores decisiones de coste que tomas, y recurrir por defecto al más potente para cada tarea es recurrir por defecto al más caro.
La mayoría de las tareas no necesitan el modelo más inteligente
No contratas a un cirujano de primera para poner una tirita — la tarea rutinaria la hace igual de bien alguien mucho más barato, y el especialista se desperdicia en ella.
El frontier model es genuinamente mejor en razonamiento difícil y abierto — pero la mayoría de lo que hacen los productos reales no es eso. Clasificar un mensaje, extraer un campo, resumir un párrafo, enrutar una petición: un modelo pequeño y barato resuelve esto con una calidad que no puedes distinguir de la del gigante. Pagar precios de frontier por trabajo rutinario es el desperdicio más común en los productos de IA. El modelo más inteligente es la excepción a la que recurres, no el valor por defecto del que partes.
Ajusta el modelo a la dificultad de la tarea
Un buen jefe asigna el problema difícil al experto y el trabajo rutinario al júnior — emparejando el talento con la tarea, no al revés.
El principio es ajustar el modelo a lo que la tarea realmente exige. El razonamiento difícil, novedoso y de varios pasos se gana un modelo potente; el trabajo simple, bien acotado y repetitivo va a uno pequeño. Esto no es un compromiso de calidad — es emparejar capacidad con necesidad, para que dejes de sobrepagar por trabajo rutinario sin dejar de traer el modelo pesado donde de verdad hace falta. Acertar con este emparejamiento, tarea por tarea, es la mayor palanca individual sobre la factura de un producto de IA.
Los precios de los modelos varían enormemente, y la mayoría de las tareas no necesitan el frontier. Ajusta el modelo a la dificultad de la tarea — pequeño para lo rutinario, potente para lo genuinamente difícil — y deja de sobrepagar por la mayoría fácil.
Si la mayor parte del trabajo es fácil y una parte es difícil, no eliges un modelo para todo — envías cada petición al correcto. Esa elección dinámica es el routing, y es uno de los patrones de mayor apalancamiento que existen.
Usa el modelo pequeño por defecto, escala cuando haga falta
Un mostrador de soporte donde el personal de primera línea resuelve la mayoría de las preguntas y solo pasa las realmente complicadas a un especialista — la mayoría de los casos nunca necesitan escalar.
El patrón central es enrutar por dificultad: envía cada petición a un modelo pequeño y barato por defecto, y escala a uno más grande y caro solo cuando la tarea realmente lo necesita. Como los casos fáciles son la mayoría, la mayor parte de las peticiones se resuelven de forma barata, y pagas el sobreprecio solo por las pocas que lo merecen. Esto invierte el valor por defecto de «usa el mejor modelo y economiza después» a «usa el modelo más barato que supere el listón, y escala cuando no lo haga».
Un router decide qué modelo recibe cada petición
Una enfermera de triaje que evalúa rápido a cada paciente y lo envía al nivel de atención adecuado — un juicio veloz y barato que dirige los recursos caros adonde se necesitan.
Para enrutar, algo tiene que decidir la dificultad de cada petición — un router. Pueden ser reglas simples (las tareas cortas y estructuradas van a lo pequeño; las largas y abiertas van a lo grande), un clasificador barato, o incluso un modelo pequeño juzgando la dificultad. El router en sí debe ser barato y rápido, ya que corre sobre todo. Un buen router envía discretamente el grueso del tráfico al modelo barato y reserva el frontier para la franja genuinamente difícil — convirtiendo la diferencia de precio entre modelos en ahorro.
Deja que un modelo fuerte planifique y los baratos ejecuten
Un arquitecto diseña el edificio, pero la cuadrilla de obra hace el grueso del trabajo — pagas al experto caro por pensar y manos más baratas por la labor.
Una versión potente del routing es plan-and-execute: usa una llamada a un modelo fuerte para descomponer una tarea difícil en pasos concretos, y luego ejecuta esos pasos con un modelo más barato y pequeño. El razonamiento caro ocurre una vez; el grueso del trabajo corre barato. Esto captura la capacidad de planificación del frontier model donde importa mientras mantiene bajo el coste por paso — un diseño heterogéneo que puede recortar la factura drásticamente frente a correrlo todo en el modelo grande.
Enruta por dificultad: modelo pequeño por defecto, escala al grande solo cuando la tarea lo merezca. Un router barato y una división planifica-caro-ejecuta-barato convierten la diferencia de precio entre modelos en ahorro.
La llamada a un modelo más barata es la que nunca haces. Cuando el mismo trabajo, o uno similar, surge una y otra vez, recordar la respuesta en lugar de recalcularla es uno de los mayores ahorros disponibles.
No pagues dos veces por la misma respuesta
Un empleado que mantiene en una ficha sobre el mostrador las respuestas más preguntadas, en lugar de buscar cada una desde cero cada vez que alguien pregunta.
Si tu app produce la misma salida del modelo una y otra vez — la misma pregunta, el mismo documento resumido, la misma búsqueda — estás pagando por un trabajo idéntico repetidamente. El caching guarda el resultado la primera vez y lo sirve al instante y gratis en las repeticiones (el curso de caching cubre la mecánica). La llamada cara ocurre una vez; las lecturas baratas ocurren muchas. Dondequiera que el mismo input se repita, una cache convierte el coste repetido en uno solo.
El prompt caching reutiliza la parte que no cambia
Una carta tipo donde el largo preámbulo estándar va preimpreso, y solo rellenas las pocas líneas que cambian — no reescribes todo cada vez.
A menudo un buen trozo de tu contexto es el mismo en cada llamada — un system prompt largo, instrucciones fijas, un documento compartido. El prompt caching permite que el modelo reutilice ese prefijo invariable en lugar de reprocesarlo cada vez, cobrando mucho menos por la parte repetida. Como ese contexto fijo suele ser el grueso de tus input tokens, cachearlo puede recortar el coste de input sustancialmente en funcionalidades de alto volumen. Es un ahorro casi gratis que obtienes solo por estructurar la parte estable de tu prompt para que pueda cachearse.
El semantic caching captura los casi-duplicados
Una mesa de ayuda que reconoce «cómo reinicio mi contraseña» y «olvidé mi contraseña» como la misma pregunta — y da la misma respuesta preparada a ambas.
Más allá de las coincidencias exactas, el semantic caching usa el significado (vía embeddings) para reconocer cuándo una nueva petición es lo bastante cercana a una anterior como para reutilizar la respuesta — «cuál es vuestra política de reembolsos» y «cómo funcionan las devoluciones» no hace falta recalcularlas por separado. Esto captura el caso común en que los usuarios preguntan lo mismo con palabras distintas, extendiendo el alcance de la cache mucho más allá de inputs idénticos. Usado con cuidado, convierte una larga cola de preguntas reformuladas-pero-equivalentes en aciertos de cache baratos.
La llamada más barata es la que te saltas. Cachea las respuestas repetidas, reutiliza el prefijo de prompt invariable y captura los duplicados reformulados de forma semántica — el trabajo repetido es coste repetido que no tienes por qué pagar.
Cuando sí haces una llamada, controlas cuánto cuesta controlando cuánto envías. Enviar menos y agrupar el trabajo son las palancas cotidianas que mantienen bajo el coste por llamada.
Envía menos contexto
Empacar solo lo que de verdad vas a usar en el viaje en lugar de todo tu armario — cada objeto extra cuesta cargarlo, y la mayoría nunca lo tocarías.
Como pagas por input token, el ahorro más directo es enviar menos contexto. Recorta el historial de la conversación, resume los turnos viejos en lugar de cargarlos literalmente, recupera solo los pocos fragmentos más relevantes en vez de todo. Esta es la disciplina del context engineering rindiendo el doble: un contexto más ajustado no solo es mejor para la calidad, es más barato en cada llamada. La mayoría de las facturas de IA infladas tienen prompts inflados debajo — recorta el relleno y el coste cae con él.
Pide menos salida, estructurada
Hacer una pregunta que quiere un sí o un no te da una respuesta rápida; hacer una que invita a un ensayo te da un ensayo que tienes que pagar y luego recortar.
También pagas por output tokens, así que no hagas que el modelo genere más de lo que necesitas. Pide una salida concisa y estructurada — los campos específicos, una respuesta corta, sin preámbulo divagante — en lugar de un ensayo largo del que solo extraerás un número. La salida estructurada (el curso de structured output) cumple doble función aquí: es más fiable y es más barata, porque un esquema ajustado produce menos tokens que la prosa libre. Restringe lo que vuelve, y restringes la mitad de salida de la factura.
Agrupa el trabajo donde puedas
Poner una lavadora llena en vez de una camisa a la vez — agrupar el trabajo reparte el coste fijo y rinde más por cada ciclo.
Cuando tienes muchas peticiones similares que no necesitan cada una una respuesta instantánea, agruparlas mediante batching — procesando muchas juntas — suele ser más barato que dispararlas una a una, y los proveedores a menudo ofrecen un descuento por trabajos en batch que pueden correr cuando convenga. Esto intercambia latencia (cada elemento espera al lote) por menor coste, lo que es el trato correcto para el trabajo de fondo o en bloque — procesar una cola atrasada, enriquecer un dataset — donde la velocidad por elemento no importa. Donde no lo necesitas ahora, el batching lo abarata.
Controla el coste por llamada enviando menos: recorta el contexto, pide salida concisa y estructurada, y agrupa el trabajo no urgente. Un prompt más ajustado es más barato además de mejor.
El coste nunca vive solo — se intercambia con la velocidad y la calidad. Ver los tres como un triángulo que equilibras por caso de uso te impide optimizar uno hasta arruinar otro.
Los tres tiran unos contra otros
El viejo cartel del taller — «rápido, barato, bueno: elige dos» — porque apretar fuerte en uno suele costarte otro.
El coste, la latency (velocidad) y la calidad forman un triángulo, y se compensan entre sí. El modelo más grande e inteligente da la mejor calidad pero cuesta más y suele ser el más lento; un modelo pequeño es barato y rápido pero más débil en tareas difíciles; un contexto pesado mejora la calidad pero sube tanto el coste como la latencia. Rara vez consigues los tres al máximo a la vez. Así que no optimizas el coste de forma aislada — decides, para cada caso de uso, qué esquina importa más y qué estás dispuesto a intercambiar por ella.
Elige el equilibrio por caso de uso
Eliges un coche deportivo para la carrera y una furgoneta de carga para la mudanza — la misma pregunta, respuestas opuestas, porque el trabajo decide qué importa.
El equilibrio correcto depende por completo de la funcionalidad. Un chat de cara al usuario vive o muere por la latency y necesita un modelo rápido y capaz. Un trabajo en batch nocturno solo se preocupa por el coste y puede usar la opción más barata y lenta. Una respuesta legal o médica de alto riesgo prioriza la calidad por encima de ambas. No hay un único punto correcto en el triángulo — nombrar qué esquina debe ganar esta funcionalidad en concreto, y cuál puede sacrificar, es la decisión que impulsa cada elección de modelo y diseño a su alrededor.
El streaming compra velocidad percibida barata
Una cocina que saca cada plato según está listo en vez de hacerte esperar a la comida entera — el tiempo total es el mismo, pero la espera se siente mucho más corta.
Un truco esquiva el triángulo: hacer streaming de la salida del modelo token a token según se genera, para que el usuario vea aparecer las palabras de inmediato en lugar de mirar una pantalla en blanco hasta que la respuesta entera esté lista. El tiempo total no cambia, pero la latencia percibida cae drásticamente, porque algo está ocurriendo ya mismo. Esta es una forma barata de hacer que una funcionalidad se sienta rápida sin un modelo más rápido — gestionando la experiencia de la latencia en lugar de la latencia misma.
El coste, la latencia y la calidad se compensan — rara vez maximizas los tres. Elige qué esquina debe ganar cada funcionalidad, sacrifica la otra correcta, y usa streaming para comprar velocidad percibida gratis.
La economía de la IA se reduce a una postura sencilla: saber lo que cuestan las cosas, y gastar deliberadamente lo mínimo que hace el trabajo. Las palancas son pocas, y la mayor parte del ahorro viene de negarse a sobrepagar por defecto.
Mide el coste por tarea, no solo la factura total
Una factura detallada que muestra cuánto costó cada plato, en lugar de un solo número grande — solo el desglose te dice dónde recortar.
No puedes controlar un coste que no mides. Lleva la cuenta de lo que cada funcionalidad, cada tipo de llamada, cada tarea cuesta de verdad en tokens, no solo la factura mensual a granel, para que puedas ver adónde va el dinero y qué parte optimizar. El coste es algo que instrumentas y vigilas, como el rendimiento — la mayoría de las funcionalidades de IA caras tienen uno o dos puntos calientes de coste que un desglose revela al instante y un total oculta por completo. Mide por tarea, y el lugar donde ahorrar se anuncia solo.
Usa lo más barato que supere el listón
Compras la herramienta que es suficientemente buena para el trabajo, no la más cara del estante — capacidad más allá de lo que necesitas es solo dinero gastado.
El principio rector es usar el modelo más barato, el contexto más pequeño y las menos llamadas que aún cumplan tu listón de calidad — y nada más. Esto no es tacañería por sí misma; es negarse a pagar por capacidad que la tarea no usa. Fija el listón de calidad con evals, luego encuentra la configuración más ligera que lo supere. La mayoría de los ahorros de coste no son trucos ingeniosos — son simplemente declinar recurrir por defecto a la opción más potente, más cargada de contexto y más parlanchina cuando una más esbelta supera el listón.
- ¿Conoces el coste por tarea — medido en tokens, no solo la factura total? - ¿Está el modelo ajustado a la dificultad — pequeño para lo rutinario, frontier solo donde haga falta? - ¿Estás enrutando — la mayoría fácil a un modelo barato, escalando los casos difíciles? - ¿Estás cacheando — respuestas repetidas, el prefijo de prompt fijo, casi-duplicados? - ¿Estás enviando el mínimo — contexto recortado, salida concisa y estructurada, en batch donde no es urgente? - ¿Qué esquina del triángulo gana — coste, latencia o calidad — y está el diseño afinado para ella?
- token / input / output — la unidad de facturación, cobrada por lo que envías y lo que vuelve. - frontier model — la opción más grande, más inteligente y más cara. - routing / router — enviar cada petición al modelo correcto según la dificultad. - plan-and-execute — un modelo fuerte planifica, los modelos baratos hacen el grueso. - caching / prompt caching / semantic caching — reutilizar respuestas, prefijos fijos y casi-duplicados. - batching — agrupar trabajo no urgente para bajar el coste, intercambiando latencia. - latency / cost / quality — el triángulo que equilibras por caso de uso; streaming para velocidad percibida.
- Mides el coste por tarea y conoces tus puntos calientes, no solo el total mensual. - Ajustas el modelo a la dificultad y enrutas en lugar de usar el frontier para todo. - Cacheas el trabajo repetido y el prefijo de prompt fijo. - Envías el mínimo de contexto y pides salida concisa. - Equilibras el triángulo por funcionalidad y usas streaming para que las cosas se sientan rápidas.
La economía de la IA es ahorro deliberado: factura por token, ajusta el modelo a la dificultad, enruta, cachea, envía el mínimo, y equilibra el coste frente a la latencia y la calidad — gana lo más barato que supere el listón.