Mapa del curso: 19 conceptos en siete grupos

Un mapa de metro: primero ves todas las líneas, luego recorres estación por estación.

Primero va el contador: cómo se cuenta el coste. Después, seis grupos de palancas: qué modelo elegir, cómo repartir las peticiones entre modelos, cómo no pagar dos veces, cómo enviar menos, cómo equilibrar el coste con la velocidad y la calidad, y cómo medirlo todo.

Cada concepto de abajo tiene la misma forma: el término en inglés (la palabra que encontrarás en la documentación), una imagen cotidiana, un diagrama y una ficha con campos: qué es, ejemplo, trampa y conceptos relacionados.

Token — 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. 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.

Input / Output Tokens — pagas por lo que entra y 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. 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.

Cost Formula — tokens por llamada × 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. Casi todo ahorro de este curso tira de una de las dos palancas: envía menos o llama menos.

Frontier Model — el más inteligente y el más caro

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.

Los modelos van de pequeños y baratos a grandes y caros, y el precio por token entre el de abajo y el de arriba difiere muchas veces. El más grande e inteligente es el frontier model. Es realmente mejor en razonamiento difícil y abierto. Pero la mayor parte 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 se ocupa de esto con una calidad que no se distingue de la del gigante.

Right-sizing — ajusta el modelo a la tarea

Un buen jefe asigna el problema difícil al experto y el trabajo rutinario al junior — ajusta el talento a la tarea, no al revés.

Right-sizing significa ajustar el modelo a lo que la tarea realmente exige. El razonamiento difícil, nuevo y de varios pasos merece un modelo potente; el trabajo simple, acotado y repetitivo va a uno pequeño. No es un recorte de calidad — es ajustar la capacidad a la necesidad, para dejar de pagar de más por el trabajo rutinario y seguir llevando el modelo pesado donde de verdad hace falta. Acertar con esto, tarea por tarea, es la mayor palanca sobre la factura de un producto de IA.

Model Routing — pequeño por defecto, escala cuando haga falta

Un servicio de soporte donde el primer nivel resuelve la mayoría de las preguntas y solo pasa a un especialista las realmente enrevesadas — la mayoría de los casos nunca necesita escalar.

El patrón de model routing: envía cada petición por defecto a un modelo pequeño y barato, y escala a uno mayor y más caro solo cuando la tarea de verdad lo necesita. Como los casos fáciles son la mayoría, casi todas las peticiones se resuelven barato, y pagas el sobreprecio solo por las pocas que lo merecen. El valor por defecto pasa de «usa el mejor modelo y ahorra luego» a «usa el modelo más barato que supere el listón, y escala cuando no lo supere».

Router — quién 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 rápido y barato que dirige los recursos caros adonde hacen falta.

Para enrutar, algo tiene que juzgar la dificultad de cada petición: un router. Puede ser un conjunto de reglas simples (las tareas cortas y estructuradas van al pequeño; las largas y abiertas al grande), un clasificador barato o incluso un modelo pequeño que juzgue la dificultad. El router en sí debe ser barato y rápido, porque corre sobre todo. Un buen router envía en silencio la mayor parte del tráfico al modelo barato y reserva el frontier para la porción realmente difícil.

Plan-and-Execute — un modelo fuerte planifica, los baratos ejecutan

Un arquitecto diseña el edificio, pero el equipo de obra hace la mayor parte del trabajo — pagas al experto caro por pensar y a manos más baratas por trabajar.

Una versión potente del routing es plan-and-execute: una llamada a un modelo fuerte descompone una tarea difícil en pasos concretos, y luego un modelo más barato y pequeño ejecuta esos pasos. El razonamiento caro ocurre una vez; el grueso del trabajo corre barato. Este diseño mixto puede recortar la factura de forma drástica frente a ejecutarlo todo en el modelo grande.

Response Caching — no pagues dos veces por la misma respuesta

Un empleado que guarda las respuestas más pedidas en una ficha sobre el mostrador, en lugar de buscarlas 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 consulta — estás pagando por trabajo idéntico repetidamente. Response 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, muchas.

Prompt Caching — reutiliza la parte que no cambia

Una carta modelo donde el largo preámbulo estándar ya viene impreso y solo rellenas las pocas líneas que cambian — no reescribes todo cada vez.

A menudo, un gran trozo de tu contexto es igual en cada llamada — un system prompt largo, instrucciones fijas, un documento compartido. Prompt caching deja que el modelo reutilice ese prefijo que no cambia en lugar de reprocesarlo cada vez, cobrando mucho menos por la parte repetida. Como ese contexto fijo suele ser la mayor parte de tus input tokens, cachearlo puede recortar mucho el coste de input en funcionalidades de alto volumen. Es un ahorro casi gratis: pon primero la parte estable y mantenla idéntica.

Semantic Caching — atrapa los casi duplicados

Un servicio de ayuda que reconoce «cómo restablezco 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, semantic caching usa el significado (mediante embeddings) para reconocer cuándo una petición nueva se parece lo bastante a una anterior como para reutilizar la respuesta — «cuál es vuestra política de reembolso» y «cómo funcionan las devoluciones» no hace falta recalcularlas por separado. Atrapa el caso común en que los usuarios preguntan lo mismo con otras palabras, convirtiendo una larga cola de preguntas reformuladas en aciertos baratos de caché.

Context Trimming — envía menos contexto

Meter en la maleta solo lo que de verdad usarás en el viaje en vez de todo el armario — cada cosa de más cuesta cargarla, y la mayoría no la tocarías.

Como pagas por input token, el ahorro más directo es el context trimming. Recorta el historial de la conversación, resume los turnos antiguos en lugar de arrastrarlos textuales, recupera solo los pocos fragmentos más relevantes en vez de todo. Es la context engineering dando fruto dos veces: un contexto más ajustado no solo es mejor para la calidad, es más barato en cada llamada. Debajo de la mayoría de las facturas de IA infladas hay prompts inflados.

Concise Structured Output — pide menos salida

Una pregunta que pide un sí o un no recibe una respuesta rápida; una que invita a un ensayo recibe un ensayo que tienes que pagar y luego recortar.

También pagas por los output tokens, así que no hagas que el modelo genere más de lo que necesitas. Pide una salida estructurada y concisa — los campos concretos, una respuesta corta, sin preámbulos largos — en vez de un ensayo del que solo vas a sacar un número. La salida estructurada hace doble trabajo aquí: es más fiable y más barata, porque un esquema ajustado produce menos tokens que la prosa libre.

Batching — agrupa el trabajo donde puedas

Poner una lavadora llena en vez de una camisa cada vez — agrupar el trabajo reparte el coste fijo y hace más por pasada.

Cuando tienes muchas peticiones parecidas que no necesitan cada una una respuesta inmediata, hacer batching — procesar muchas juntas — suele ser más barato que lanzarlas de una en una, y los proveedores suelen ofrecer descuento por los batch jobs que pueden correr cuando convenga. Cambias latencia (cada elemento espera al lote) por menor coste — el trato adecuado para trabajo en segundo plano o masivo: procesar un atraso, enriquecer un conjunto de datos.

Latency–Cost–Quality Triangle — los tres tiran en direcciones opuestas

El viejo cartel de taller — «rápido, barato, bueno: elige dos» — porque empujar fuerte en uno suele costarte otro.

El coste, la latencia (velocidad) y la calidad forman un triángulo, y se intercambian. 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 flojo en tareas difíciles; mucho contexto mejora la calidad pero sube el coste y la latencia. Rara vez consigues los tres al máximo a la vez. Así que no optimizas el coste aislado — para cada caso de uso decides qué esquina importa más y qué cedes a cambio.

Use-case Balance — elige el equilibrio por funcionalidad

Eliges un deportivo para la carrera y una furgoneta 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 latencia y necesita un modelo rápido y capaz. Un trabajo por lotes 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 pone la calidad por encima de ambas. No hay un único punto correcto en el triángulo — nombrar qué esquina debe ganar esta funcionalidad, y cuál puede sacrificar, es la decisión que guía todas las demás.

Streaming — velocidad percibida, barata

Una cocina que saca cada plato cuando está listo en vez de hacerte esperar a toda la comida — el tiempo total es el mismo, pero la espera se siente mucho más corta.

Un truco esquiva el triángulo: el streaming de la salida del modelo token a token mientras se genera, para que el usuario vea aparecer palabras de inmediato en vez de mirar una pantalla en blanco hasta que esté toda la respuesta. El tiempo total no cambia, pero la latencia percibida baja de forma drástica. Es una manera barata de hacer que una funcionalidad se sienta rápida sin un modelo más rápido — gestionas la experiencia de la espera, no la espera en sí.

Cost per Task — mide por tarea, no solo la factura total

Una cuenta detallada que muestra cuánto costó cada plato, en vez de un solo número grande — solo el desglose te dice dónde recortar.

No puedes controlar un coste que no mides. Registra lo que cuesta de verdad en tokens cada funcionalidad, cada tipo de llamada, cada tarea — el cost per task — no solo la factura mensual a bulto. El coste es algo que se instrumenta y se vigila, 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.

Clear the Bar — lo más barato que supera el listón

Compras la herramienta que basta para el trabajo, no la más cara del estante — la capacidad que te sobra es solo dinero gastado.

El principio rector: usa el modelo más barato, el contexto más pequeño y el menor número de llamadas que aún cumplan tu listón de calidad — y nada más. No es tacañería por sí misma; es negarse a pagar por una capacidad que la tarea no usa. Fija el listón con evals y luego busca la configuración más ligera que lo supere. La mayoría de los ahorros no son trucos ingeniosos — son negarse a elegir por costumbre la opción más potente, con más contexto y más parlanchina.

Cómo encaja todo

Un panel de control con tres mandos: precio por token, tokens por llamada, número de llamadas. Cada técnica del curso gira uno de ellos.

Cada técnica del curso golpea uno de los tres multiplicadores de la factura. Right-sizing, Model Routing y Plan-and-Execute bajan el precio por token. Context Trimming, Concise Output y Prompt Caching bajan los tokens por llamada. Response y Semantic Caching bajan el número de llamadas. Batching compra un descuento a cambio de esperar, Cost per Task muestra dónde mirar, y el triángulo te recuerda que toda palanca se intercambia con la latencia y la calidad.