# Paga la inteligencia por token Curso exprés sobre la economía de construir con IA — por qué cada llamada a un modelo cuesta dinero y tiempo, y cómo mantenerla asequible. 19 conceptos — Token, Frontier model, Model routing, Plan-and-execute, Prompt caching, Semantic caching, Batching, el triángulo Latencia–Coste–Calidad, Streaming y más — cada uno con su nombre en inglés, un diagrama y una ficha: qué es → ejemplo → trampa → relaciones. Una hoja de referencia de una página al final. La idea central: el coste y la velocidad son restricciones de diseño, y el modelo más barato que supera el listón suele ganar. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/model-economics-express --- ## 1. Pagas por token 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. ### 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. _Diagram: Arriba el contador, abajo seis grupos de palancas — los capítulos 2–7 las recorren._ 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. _Diagram: El texto se corta en tokens, el contador los cuenta — la factura crece con cada token._ #### Token (la unidad de facturación) - **Qué es:** Un fragmento de texto — más o menos una palabra o parte de una. La unidad de facturación. - **Ejemplo:** «La política de reembolso es de 30 días» son unos siete tokens, no una petición. - **Trampa:** Pagas por el volumen de texto, no por el número de peticiones: una petición larga cuesta más. - **Relaciones:** Los tokens se suman en **Input / Output Tokens** y en toda la **Cost Formula**. ### 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. _Diagram: A la izquierda: todo lo que envías. A la derecha: lo que escribe el modelo. Se factura ambas mitades — en cada llamada._ #### Input / Output Tokens (lo que envías, lo que recibes) - **Qué es:** Input — prompt, contexto, historial. Output — la respuesta generada. - **Ejemplo:** Un system prompt de miles de tokens + una pregunta corta + una respuesta de una línea: casi toda la factura es input. - **Trampa:** Un contexto grande cuesta dinero en cada llamada, no una sola vez. - **Relaciones:** **Context Trimming** y **Prompt Caching** recortan el input; **Concise Structured Output** recorta el output. ### 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**. _Diagram: Dos palancas son tuyas: enviar menos y llamar menos. El precio por token (tu elección de modelo) multiplica ambas._ #### Cost Formula (lo que impulsa la factura) - **Qué es:** Coste = tokens por llamada × número de llamadas (× el precio del modelo por token). - **Ejemplo:** Un agente que hace 20 llamadas con un contexto largo cuesta muchas veces más que una sola llamada con el mismo contexto. - **Trampa:** Los bucles de agentes multiplican en silencio el número de llamadas. - **Relaciones:** Cada técnica que sigue reduce uno de los multiplicadores — mira el diagrama de relaciones al final. > **La pregunta de encuadre:** «¿Qué está impulsando de verdad la factura de esta funcionalidad — un contexto grande en cada llamada, un modelo inteligente pero caro, o demasiadas llamadas — porque eso me dice de qué palanca tirar?» > 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. ## 2. El frontier no siempre es la respuesta 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. ### 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. _Diagram: El precio por token sube muchas veces de un modelo pequeño al frontier (sin escala)._ #### Frontier Model (lo más alto de la gama) - **Qué es:** El modelo más grande, inteligente y caro de la gama. - **Ejemplo:** Usarlo para clasificar tickets es como contratar a un cirujano de primera para poner una tirita. - **Trampa:** Hacerlo el modelo por defecto para toda tarea es elegir por defecto lo más caro — el derroche más común en los productos de IA. - **Relaciones:** **Right-sizing**, **Model Routing** y **Plan-and-Execute** deciden dónde le toca estar. ### 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. _Diagram: Las tareas rutinarias van al modelo pequeño; solo las realmente difíciles van al frontier._ #### Right-sizing (el modelo justo para la tarea) - **Qué es:** Para cada tarea, usa el modelo más débil que la resuelva bien. - **Ejemplo:** Extraer un campo de un correo — modelo pequeño; desenredar un caso legal complicado — uno grande. - **Trampa:** «La resuelve bien» hay que comprobarlo con evals, no a ojo. - **Relaciones:** La versión estática; la dinámica es **Model Routing**. Se comprueba con **Clear the Bar**. > **La pregunta del modelo:** «¿Esta tarea necesita de verdad el modelo más inteligente — o estoy pagando precios de frontier por un trabajo que un modelo pequeño y barato haría igual de bien?» > Los precios de los modelos varían enormemente, y la mayoría de las tareas no necesitan el frontier. Pequeño para lo rutinario, potente para lo realmente difícil — y deja de pagar de más por la fácil mayoría. ## 3. Enruta por dificultad Si la mayor parte del trabajo es fácil y una parte es difícil, no eliges un solo modelo para todo — envías cada petición al adecuado. Esa elección al vuelo es el routing, y es uno de los patrones de mayor palanca que existen. ### 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». _Diagram: La petición va al modelo pequeño; si la respuesta se queda corta, escala al frontier._ #### Model Routing (escalado) - **Qué es:** Elegir un modelo por petición, al vuelo, según su dificultad. - **Ejemplo:** Un bot de soporte: «dónde está mi pedido» va al modelo pequeño, una queja enrevesada al grande. - **Trampa:** Necesitas una forma de saber que la respuesta barata se quedó corta — si no, las respuestas malas llegan a los usuarios. - **Relaciones:** La decisión la toma un **Router**; patrón hermano — **Plan-and-Execute**. ### 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. _Diagram: El router envía la mayor parte del tráfico al modelo pequeño y la porción difícil al frontier._ #### Router (el despachador) - **Qué es:** El componente que evalúa una petición y elige su modelo. - **Cómo funciona:** Reglas, un clasificador barato o un modelo juez pequeño. - **Trampa:** Si el propio router es lento o caro, se come todo el ahorro. - **Relaciones:** El corazón de **Model Routing**; convierte la diferencia de precio entre modelos en ahorro. ### 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. _Diagram: El modelo fuerte escribe el plan una vez; los modelos baratos ejecutan los pasos._ #### Plan-and-Execute (planifica caro, ejecuta barato) - **Qué es:** Un modelo fuerte planifica; los baratos cumplen los pasos del plan. - **Ejemplo:** Un informe sobre 50 documentos: el modelo grande decide qué extraer y cómo combinarlo, el pequeño recorre cada documento. - **Trampa:** Un mal plan lo cumplen fielmente — y mal — los pasos baratos. - **Relaciones:** Una variante de **Model Routing**; usa el **Frontier Model** de forma quirúrgica. > **La pregunta del routing:** «¿Estoy enviando cada petición a un solo modelo — o enruto la fácil mayoría a uno barato y escalo solo los casos realmente difíciles al caro?» > Modelo pequeño por defecto, escala al grande solo cuando la tarea lo merezca. Un router barato y un reparto de planifica-caro, ejecuta-barato convierten la diferencia de precio entre modelos en ahorro. ## 4. Cachea: no hagas el trabajo dos veces La llamada más barata es la que nunca haces. Cuando el mismo trabajo, o uno parecido, aparece una y otra vez, recordar la respuesta en vez de recalcularla es uno de los mayores ahorros disponibles. ### 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. _Diagram: Un acierto es instantáneo y gratis; un fallo va al modelo, y el resultado se guarda._ #### Response Caching (reutilizar respuestas enteras) - **Qué es:** Guardar una respuesta terminada del modelo y servirla cuando se repite exactamente la entrada. - **Ejemplo:** El resumen del mismo artículo para mil lectores se calcula una sola vez. - **Trampa:** Solo compensa donde las entradas de verdad se repiten; las respuestas pueden quedar obsoletas. - **Relaciones:** Lo amplían **Prompt Caching** (la parte común del prompt) y **Semantic Caching** (peticiones parecidas). ### 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. _Diagram: La primera llamada paga precio completo; después el prefijo común sale de la caché y cuesta mucho menos._ #### Prompt Caching (prefijo cacheado) - **Qué es:** El proveedor reutiliza un prefijo de prompt que no cambia y cobra menos por él. - **Ejemplo:** Un bot con instrucciones largas y un documento de referencia: eso se cachea, solo la pregunta del usuario va a precio completo. - **Trampa:** Cualquier cambio pequeño al inicio del prompt (por ejemplo, una marca de tiempo) rompe la coincidencia del prefijo. - **Relaciones:** Recorta el lado input de **Input / Output Tokens**; complementa a **Context Trimming**. ### 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é. _Diagram: Dos peticiones cercanas en significado comparten una respuesta cacheada. Una petición lejana en significado va al modelo._ #### Semantic Caching (caché por significado) - **Qué es:** Una caché con clave en el significado de la petición (un embedding), no en su texto exacto. - **Ejemplo:** «Olvidé mi contraseña» recibe la respuesta guardada para «cómo restablezco mi contraseña». - **Trampa:** Ajusta el umbral de similitud con cuidado: preguntas con palabras parecidas pueden necesitar respuestas distintas. - **Relaciones:** Amplía **Response Caching**; se apoya en embeddings. > **La pregunta de la caché:** «¿Dónde está recalculando esta funcionalidad la misma respuesta, o una casi igual — y podría una caché, incluido el prefijo fijo del prompt, convertir ese coste repetido en uno de una sola vez?» > La llamada más barata es la que te saltas. Cachea las respuestas repetidas, reutiliza el prefijo del prompt que no cambia y atrapa semánticamente los duplicados reformulados — el trabajo repetido es un coste repetido que no tienes por qué pagar. ## 5. Envía menos y agrupa Cuando haces una llamada, controlas lo que cuesta controlando cuánto envías y cuánto pides. Enviar menos y agrupar el trabajo son las palancas de todos los días que mantienen bajo el coste por llamada. ### 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. _Diagram: Antes: el historial completo y todos los documentos. Después: un resumen corto, los tres mejores fragmentos y la pregunta._ #### Context Trimming (envía solo lo necesario) - **Qué es:** Dale al modelo solo lo que necesita este paso. - **Ejemplo:** En lugar de 40 turnos pasados — un resumen de un párrafo; en lugar de toda la base de conocimiento — los tres mejores fragmentos. - **Trampa:** Si recortas demasiado, el modelo pierde un dato que necesitaba y responde peor. - **Relaciones:** Reduce el primer multiplicador de la **Cost Formula**; vecino de **Prompt Caching**. ### 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. _Diagram: Un ensayo cuesta muchos output tokens; un esquema de un solo campo da la misma respuesta mucho más barata._ #### Concise Structured Output (esquema ajustado) - **Qué es:** Limitar la forma y la longitud de la respuesta: solo los campos que necesitas. - **Ejemplo:** La nota de una reseña como `{"score": 4}`, no tres párrafos de razonamiento. - **Trampa:** Un esquema demasiado rígido puede no dejar al modelo espacio para pensar en tareas difíciles. - **Relaciones:** Recorta la mitad output de **Input / Output Tokens**. ### 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. _Diagram: Una a una: ahora, al precio normal. En lote: más tarde, pero a menudo con descuento._ #### Batching (trabajos masivos) - **Qué es:** Enviar muchas peticiones no urgentes como un solo batch job. - **Ejemplo:** Etiquetar 100 000 tickets antiguos de noche en un solo lote. - **Trampa:** La respuesta no llega enseguida — no sirve para nada que una persona esté esperando. - **Relaciones:** Elige a propósito la esquina del «coste» del **Latency–Cost–Quality Triangle**. > **La pregunta de la eficiencia:** «¿Estoy enviando más contexto y pidiendo más salida de lo que necesita esta tarea — y podría el batching del trabajo no urgente abaratarlo?» > Controla el coste por llamada enviando menos: recorta el contexto, pide una salida estructurada y concisa, y agrupa el trabajo no urgente. Un prompt más ajustado es más barato además de mejor. ## 6. Latencia, coste, calidad 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 evita que optimices uno arruinando otro. ### 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. _Diagram: Un modelo grande tira hacia la calidad, uno pequeño hacia el coste y la velocidad. Los tres al máximo a la vez es raro._ #### Latency–Cost–Quality Triangle (elige dos) - **Qué es:** Tres cualidades que no puedes llevar todas al límite a la vez. - **Ejemplo:** Pasar a un modelo pequeño: más barato y rápido, pero más flojo en los casos difíciles. - **Trampa:** Recortar el coste puede bajar la calidad sin que se note — comprueba con evals. - **Relaciones:** La elección concreta de esquina es **Use-case Balance**; el truco de velocidad es **Streaming**. ### 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. _Diagram: Tres funcionalidades, tres ganadoras: latencia para el chat, coste para el trabajo por lotes, calidad para lo de alto riesgo._ #### Use-case Balance (nombra la esquina ganadora) - **Qué es:** Para cada funcionalidad, nombrar de forma explícita la esquina del triángulo que más importa. - **Ejemplo:** Autocompletado de búsqueda — latencia; etiquetado nocturno — coste; un resumen médico — calidad. - **Trampa:** Un solo ajuste para todo pierde un poco en todas partes. - **Relaciones:** Guía las elecciones en **Right-sizing**, **Batching** y **Streaming**. ### 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í. _Diagram: Sin streaming: pantalla en blanco hasta el final. Con streaming: las palabras llegan enseguida, el mismo tiempo total._ #### Streaming (salida token a token) - **Qué es:** Mostrar la respuesta a medida que se genera, token a token. - **Ejemplo:** Un asistente de chat empieza a escribir un instante después de la pregunta. - **Trampa:** No acelera el resultado completo: si necesitas la respuesta entera (por ejemplo, JSON para el código), no hay ganancia. - **Relaciones:** Ayuda a la esquina de la «latencia» del **Latency–Cost–Quality Triangle** sin cambiar el modelo. > **La pregunta del triángulo:** «Para esta funcionalidad, ¿qué esquina importa más — coste, latencia o calidad — y he elegido el modelo y el diseño para ganar esa y sacrificar la otra adecuada?» > Coste, latencia y calidad se intercambian — rara vez consigues los tres al máximo. Elige qué esquina debe ganar cada funcionalidad, sacrifica la otra adecuada y usa streaming para comprar velocidad percibida casi gratis. ## 7. Usarlo bien La economía de la IA se reduce a una postura sencilla: saber lo que cuestan las cosas y gastar a propósito lo mínimo que hace el trabajo. Las palancas son pocas, y la mayor parte del ahorro viene de negarse a pagar de más por defecto. ### 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. _Diagram: Un número mensual no dice nada; un desglose por funcionalidad muestra el punto caliente de inmediato._ #### Cost per Task (coste desglosado) - **Qué es:** Registrar tokens y dinero por funcionalidad, tipo de llamada y tarea. - **Ejemplo:** El desglose muestra que el bucle del agente se come más que el chat, la búsqueda y los resúmenes juntos. - **Trampa:** Sin desglose optimizas lo que se ve, no lo que es caro. - **Relaciones:** Te dice de qué multiplicador de la **Cost Formula** tirar primero. ### 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. _Diagram: Los evals fijan el listón. Toma el modelo más barato que lo supere; todo lo que esté por encima es pagar de más._ #### Clear the Bar (suficientemente bueno, y nada más) - **Qué es:** La configuración más pequeña (modelo, contexto, llamadas) que pasa tus evals. - **Ejemplo:** Bajas una funcionalidad de un modelo grande a uno mediano, pasas los evals — la calidad se mantiene, la factura baja. - **Trampa:** Sin evals el «listón» es una sensación, y los ahorros erosionan la calidad en silencio. - **Relaciones:** La suma de todas las palancas del curso; valida **Right-sizing** y **Model Routing**. ### 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. _Diagram: Las palancas de arriba bajan tres multiplicadores, que forman el coste total; el desglose por tarea lo mide._ #### Antes de lanzar una funcionalidad de IA a escala - **¿Conoces el cost per task** — 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 fácil mayoría a un modelo barato, escalando los casos difíciles? - **¿Estás cacheando** — respuestas repetidas, el prefijo fijo del prompt, casi duplicados? - **¿Estás enviando lo mínimo** — contexto recortado, salida estructurada concisa, en lote lo no urgente? - **¿Qué esquina del triángulo gana** — coste, latencia o calidad — y está el diseño ajustado para ella? #### Señales de que gestionas bien el coste - **Mides el cost per task** y conoces tus puntos calientes, no solo el total mensual. - **Ajustas el modelo a la dificultad** y **enrutas** en vez de usar el frontier para todo. - **Cacheas** el trabajo repetido y el prefijo fijo del prompt. - **Envías el mínimo** de contexto y pides una salida **concisa**. - **Equilibras el triángulo** por funcionalidad y usas **streaming** para que todo se sienta rápido. ## Hoja de referencia: los 19 conceptos ### El contador - **Token** (unidad de facturación): Un fragmento de texto, más o menos una palabra. La unidad en que se te factura. - **Input / Output Tokens** (entrada y salida): Pagas por lo que envías y por lo que escribe el modelo — en cada llamada. - **Cost Formula** (lo que impulsa la factura): Tokens por llamada × número de llamadas (× el precio del modelo por token). ### Elección del modelo - **Frontier Model** (lo más alto de la gama): El más inteligente y caro. La excepción, no el valor por defecto. - **Right-sizing** (el modelo justo para la tarea): Modelo pequeño para lo rutinario, el potente para lo realmente difícil. ### Routing - **Model Routing** (escalado): Modelo barato por defecto, el caro solo cuando hace falta. - **Router** (el despachador): Un juez barato y rápido que decide qué modelo recibe cada petición. - **Plan-and-Execute** (planifica caro, ejecuta barato): Un modelo fuerte planifica una vez, los baratos ejecutan los pasos. ### Caching - **Response Caching** (reutilizar respuestas enteras): Una respuesta guardada para una repetición exacta — instantánea y gratis. - **Prompt Caching** (prefijo cacheado): El prefijo del prompt que no cambia se reutiliza y cuesta mucho menos. - **Semantic Caching** (caché por significado): Las peticiones cercanas en significado comparten una respuesta guardada. ### Enviar menos - **Context Trimming** (envía solo lo necesario): Solo el contexto necesario: un resumen en vez del historial, los mejores fragmentos en vez de todo. - **Concise Structured Output** (esquema ajustado): Solo los campos que necesitas — menos output tokens, más fiable. - **Batching** (trabajos masivos): El trabajo no urgente en lote: más tarde, pero a menudo con descuento. ### Equilibrio - **Latency–Cost–Quality Triangle** (elige dos): Rápido, barato, bueno — elige dos. - **Use-case Balance** (nombra la esquina ganadora): Cada funcionalidad nombra, de forma explícita, su esquina más importante. - **Streaming** (salida token a token): Las palabras llegan enseguida: el mismo tiempo total, una espera que se siente más corta. ### Usarlo bien - **Cost per Task** (coste desglosado): Un desglose por funcionalidad y por tarea revela los puntos calientes. - **Clear the Bar** (suficientemente bueno, y nada más): La configuración más barata que pasa tus evals — y nada más. > La economía de la IA es ahorro deliberado: facturación por token, modelo ajustado a la dificultad, routing, caching, enviar lo mínimo y equilibrar el coste con la latencia y la calidad — gana lo más barato que supera el listón. Fin del curso exprés · 7 capítulos · 19 conceptos Ahora toca la práctica: toma una funcionalidad de IA y mide cuánto cuesta de verdad una tarea en tokens — luego prueba las jugadas obvias. Bájala a un modelo más pequeño y comprueba, con evals, si la calidad se mantiene; recorta el contexto; cachea las repeticiones. Normalmente verás que la factura cae mucho sin pérdida real, porque elegías por costumbre la opción más cara. La disciplina encaja en el momento en que una configuración más barata supera el listón y te das cuenta de que el frontier model nunca fue necesario. Pero quédate con una idea por encima de las demás: pagas la inteligencia por token, así que gasta lo mínimo que hace el trabajo.