la ecuación de esta slide
C = pin · tin  +  pout · tout (Ec. 1)
El coste de una llamada. tin son los tokens que mandáis (instrucciones + historial + pregunta) y tout los que el modelo genera. pin y pout son los precios por token, que vienen de dividir entre un millón la cifra que publica el proveedor. Generar cuesta unas cinco veces más que leer, así que la segunda mitad de la fórmula pesa mucho más de lo que su tamaño sugiere.
Cmes = C · N (Ec. 2)
El presupuesto mensual multiplica por N, vuestra previsión de consultas al mes. Es el único de los cuatro números que no sale de una tabla de precios: sale de vuestro plan de negocio.
guion paso a paso
  1. Deja 4.000 de entrada y 400 de salida, y cambia el modelo de Haiku a Opus. La factura se multiplica por cinco sin que cambie una sola línea de vuestro código: elegir modelo es una decisión de presupuesto.
  2. Vuelve a Sonnet y sube la salida de 400 a 2.000. La barra dorada (salida) adelanta a la gris (entrada) aunque sigáis mandando diez veces más tokens de los que recibís.
  3. Sube la entrada a 40.000, como en una sesión agéntica larga. Ahora manda la entrada. Es el caso del Tema A: el contexto acumulado es lo que os arruina, no la respuesta.
  4. Pon N en 500.000 consultas y mira el coste anual. Cifras de cinco o seis dígitos al año a partir de una consulta que parecía costar céntimos.
Comprueba que entiendes: ¿por qué la salida es más cara que la entrada?
Porque leer la entrada se paraleliza: el modelo procesa todos los tokens del prompt a la vez. Generar es secuencial: cada token de salida exige una pasada completa por el modelo, y hay que esperar al anterior para producir el siguiente. Pagáis el coste de cómputo real, y por eso la proporción es aproximadamente de uno a cinco en toda la gama.

Setup. Panel de arriba: las dos partidas de una consulta, a escala. Panel de abajo: el coste mensual de los cuatro modelos con los mismos tokens, para que la comparación sea justa.

Juega. Pon los números de vuestra startup. Si vuestro producto resume documentos, la entrada es grande y la salida pequeña; si redacta informes, al revés.

Lee así. La barra más larga del panel de arriba os dice dónde está vuestra palanca. Si manda la entrada, atacad el contexto y la caché. Si manda la salida, atacad la longitud de la respuesta.

Mensaje. Cuatro números bastan para el presupuesto base: dos precios de tabla, dos estimaciones vuestras.

Términos. token: trozo de texto, unas 0,75 palabras en castellano. tin/tout: tokens de entrada y salida. pin/pout: precio por token. N: consultas al mes. MTok: millón de tokens, la unidad en que se publican los precios.

las ecuaciones de esta slide
tn = t0 + (n − 1) · Δ (Ec. 3)
Los tokens de entrada del turno n. t0 es el contexto inicial (instrucciones + objetivo) y Δ lo que añade cada vuelta: lo que el modelo dijo más lo que devolvió la herramienta. Crece en progresión aritmética porque la API no tiene memoria y el harness reenvía todo el historial en cada llamada.
Csesión = Σn=1T  [ pin tn + pout s ] = pin · T(2t0 + (T−1)Δ)2 + pout · T · s (Ec. 4)
El coste de la sesión entera es la suma de los T turnos, no el coste del último. La suma de una progresión aritmética crece con T²: doblar la longitud de la sesión cuadruplica aproximadamente la parte de entrada. s son los tokens que el modelo genera por turno.
guion paso a paso
  1. Con T = 8, compara el coste total con el coste del último turno solo. El total es varias veces el del último turno. Esa diferencia es el error de estimación que casi todos los equipos cometen al presupuestar.
  2. Dobla T de 8 a 16 y mira el coste total. No se dobla: se multiplica por algo más de tres. La parte de entrada crece con el cuadrado del número de turnos.
  3. Sube Δ de 2.500 a 6.000, como si cada herramienta devolviera un fichero entero. La curva acumulada se dispara: lo que devuelven las herramientas pesa más que lo que dice el modelo.
  4. Activa la poda. La recta de tokens se aplana y el coste total baja mucho. Es el precio a pagar: el agente olvida lo que vio al principio.
Comprueba que entiendes: si una sesión de 10 turnos cuesta 1 euro, ¿cuánto cuesta una de 20?
Alrededor de 3,6 euros, no 2. La parte de salida sí se dobla (son T respuestas), pero la de entrada va como T², y en una sesión agéntica la entrada domina. Por eso la primera barandilla que se le pone a un agente es un tope de turnos, y la segunda es podar o compactar el contexto.

Setup. Arriba, los tokens de entrada que paga cada turno. Abajo, el coste acumulado turno a turno, con la línea de lo que pagaríais si sólo contarais la última llamada.

Juega. Un agente que lee código tiene Δ grande (ficheros enteros); uno que consulta una base de datos lo tiene pequeño.

Lee así. El área bajo las barras es vuestra factura. La línea de puntos es lo que creíais que ibais a pagar.

Mensaje. Un agente no cuesta T llamadas: cuesta la suma de T contextos que crecen.

Términos. T: turnos del bucle. t0: contexto inicial. Δ: tokens que añade cada vuelta. podar: borrar resultados de herramientas antiguos. compactar: resumirlos.

las ecuaciones de esta slide
Ccaché = pin[ (1−f) tin + 0,1 · f · tin ] + pout tout (Ec. 5)
f es la fracción del prompt que se sirve desde caché. Esa parte se factura al 10 % del precio de entrada; el resto, al 100 %. La caché casa por prefijo exacto: lo estable tiene que ir delante y lo que cambia, detrás.
C1ª = pin[ (1−f) tin + 1,25 · f · tin ] + pout tout (Ec. 6)
La primera llamada paga un 25 % de más por escribir en caché (con TTL de 5 minutos; el doble si pedís una hora). A partir de la segunda se lee al 10 %. De ahí que haya un número mínimo de llamadas por debajo del cual la caché sale cara.
m* = 0,25 · f 0,9 · f + 1  ≈  1,28 (Ec. 7)
El punto de equilibrio en número de llamadas: el sobrecoste de escribir (0,25·f) dividido entre el ahorro por llamada (0,9·f), más la propia llamada que escribió. Sale por debajo de dos e independiente de f: con dos llamadas sobre el mismo prefijo, la caché ya compensa.
guion paso a paso
  1. Pon las llamadas en 1 y mira el panel de abajo. Con una sola llamada la caché pierde: habéis pagado por escribir algo que nadie va a leer.
  2. Sube a 2 llamadas. La línea dorada ya cruza por debajo de la gris. El umbral está en 1,28 llamadas: con dos, compensa siempre.
  3. Mueve f de 70 % a 20 %. El ahorro final cae mucho, pero el umbral no se mueve: f cambia cuánto ganáis, no a partir de cuándo ganáis.
  4. Activa el TTL de una hora con pocas llamadas. Escribir cuesta el doble y hacen falta más llamadas para amortizarlo. El TTL largo es para tráfico con huecos, no para ahorrar.
Comprueba que entiendes: ¿por qué meter la fecha de hoy en el system prompt destruye la caché?
Porque la caché casa por prefijo exacto, byte a byte. Si la primera línea del prompt cambia cada día (o cada petición, si lleva la hora), todo lo que viene detrás deja de casar y se factura al 100 %. El síntoma es que el contador de tokens leídos de caché sale cero llamada tras llamada. La regla es simple: lo estable delante, lo volátil detrás.

Setup. Arriba, el reparto del prompt entre lo cacheado y lo fresco. Abajo, el coste acumulado con y sin caché según el número de llamadas.

Juega. Un asistente con un manual de 20.000 tokens fijos tiene f alto; un clasificador que recibe textos distintos cada vez lo tiene bajo.

Lee así. El cruce de las dos líneas es el momento a partir del cual la caché os está devolviendo dinero.

Mensaje. La caché es la palanca con mejor relación entre lo que ahorra y lo que cuesta implementarla: reordenar el prompt.

Términos. f: fracción cacheable. prefijo: el principio del prompt, que tiene que ser idéntico. TTL: cuánto vive la entrada en caché. m*: llamadas a partir de las cuales compensa.

la restricción de esta slide
tsys + tskills + trag + thist  ≤  B (Ec. 8)
Las cuatro capas comparten una única ventana de contexto B. tsys es fijo; tskills lo controláis con la carga progresiva; trag depende de cuántos fragmentos inyectéis; thist es la única que crece sola mientras el agente trabaja. Y todas se pagan en cada turno.
tskills = síndice · K + smanual · a (Ec. 9)
Con carga progresiva pagáis un índice corto por cada una de las K skills disponibles, más el manual completo de las a que se activan. Sin carga progresiva pagaríais smanual·K siempre, aunque no se use ninguna.
guion paso a paso
  1. Con 20 skills, apaga la carga progresiva. La franja de skills pasa de una línea fina a un bloque enorme: 18.000 tokens por llamada que estáis pagando para no usarlos.
  2. Vuelve a encenderla y sube las skills activadas de 1 a 5. Crece, pero mucho menos: pagáis los manuales que de verdad abrís.
  3. Mueve el turno de 1 a 60 dejando todo lo demás fijo. Las tres primeras capas no se mueven; la cuarta se come la ventana ella sola. Es la única que crece sin que vosotros hagáis nada.
  4. Sube los fragmentos RAG a 20 con el turno alto. La barra choca con la línea de la ventana de 200k y el aviso se pone en rojo: a partir de ahí el sistema empieza a perder información.
Comprueba que entiendes: de las cuatro capas, ¿cuál atacaríais primero si la factura se dispara?
El historial, porque es la única que crece sola y la que acaba dominando en sesiones largas. Las otras tres son decisiones de diseño que tomáis una vez; el historial es una consecuencia del bucle. Se ataca podando (borrar resultados de herramientas antiguos) o compactando (resumir lo anterior). Las dos pierden información: hay que elegir cuál duele menos en vuestro caso.

Setup. Arriba, las cuatro capas apiladas contra las ventanas de 200k y 1M. Abajo, lo que cuesta ese contexto al mes a 50.000 consultas.

Juega. Un asistente de soporte tiene mucho RAG y poco historial; un agente de programación, al revés.

Lee así. El color que más ocupa es donde está vuestro problema. Si es gris claro (historial), el arreglo es de gestión de sesión; si es dorado (RAG), es de recuperación.

Mensaje. El contexto es un presupuesto, y se paga entero en cada uno de los turnos.

Términos. B: ventana de contexto del modelo. carga progresiva: el agente ve sólo el índice de cada skill y abre el manual cuando hace falta. podar: borrar. compactar: resumir.

la ecuación de esta slide
VRAM ≈ P · b · (1 + ρ)  +  k · L · c (Ec. 10)
Primer término, los pesos: P parámetros (en miles de millones) por b bytes cada uno — 2 en FP16, 1 en FP8, 0,6 en INT4 — con un ρ ≈ 15 % de overhead del runtime. Segundo término, la caché KV: k ≈ 320 MB por cada mil tokens, por la longitud de contexto L y por las peticiones simultáneas c. El primero es fijo; el segundo crece con vuestro uso real.
G = ⌈ VRAM / VGPU ⌉ (Ec. 11)
Las GPUs necesarias, redondeando hacia arriba: no se puede comprar media tarjeta. Por eso el coste del servidor sube a saltos, no de forma continua: un token más de contexto puede costaros una tarjeta entera.
guion paso a paso
  1. 70B en INT4, contexto 8k, 4 simultáneas. Unos 58 GB: entra en una sola A100 de 80 GB. Con este dimensionado el proyecto parece barato.
  2. Sube el contexto a 128k dejando todo lo demás igual. La barra dorada (caché KV) adelanta a la gris (pesos) y hacen falta varias tarjetas. El modelo no ha cambiado de tamaño.
  3. Vuelve a 8k y sube las simultáneas de 4 a 32. Mismo efecto: la caché KV es proporcional al producto L·c, así que da igual por dónde crezca.
  4. Pon FP16 con 70B. 140 GB sólo de pesos: dos tarjetas antes de servir a nadie. Por eso todo el mundo cuantiza.
Comprueba que entiendes: ¿por qué el gráfico de coste sube a escalones y no en rampa?
Porque las GPUs se compran enteras. Mientras la VRAM necesaria quepa en las tarjetas que ya tenéis, el coste no se mueve; en cuanto se pasa un byte, hay que añadir otra tarjeta completa y el coste salta. Esto tiene una consecuencia práctica: justo antes de un escalón, recortar un poco el contexto o la concurrencia os ahorra una tarjeta entera al mes.

Setup. Arriba, las tres partidas de VRAM apiladas con las líneas de 1, 2 y 3 tarjetas de 80 GB. Abajo, el coste mensual del servidor resultante, a precio mediano de mercado.

Juega. Dimensionad con el contexto y la concurrencia que vais a tener de verdad en hora punta, no los del día de la demo.

Lee así. Si la barra dorada es mayor que la gris, vuestro cuello de botella es el uso, no el modelo: un modelo más pequeño no os va a salvar.

Mensaje. Contar sólo los pesos es el error de dimensionado más caro y más frecuente.

Términos. VRAM: memoria de la GPU. caché KV: lo que el modelo guarda de los tokens ya procesados. cuantizar: bajar la precisión de los pesos. INT4: 4 bits por parámetro.

la ecuación de esta slide
N* = Cfijo cconsulta (Ec. 12)
El punto de equilibrio: el número de consultas al mes que iguala las dos vías. Cfijo es el servidor (GPUs por horas más personal) y cconsulta el coste variable de la API. Por debajo de N* gana la API; por encima, el servidor. Las dos rectas siempre se cortan porque una sale del origen con pendiente positiva y la otra es horizontal.
Cfijo = PGPU · G · h  +  Cpersonal (Ec. 13)
h son las horas al mes que el servidor está encendido: 730 si es 24/7, unas 260 si sólo en horario de oficina. Es la palanca más barata que tenéis sobre la horizontal. Cpersonal no depende de las horas y es, casi siempre, la partida mayor.
guion paso a paso
  1. Con los valores de partida, mira dónde cae vuestro volumen. A 50.000 consultas estáis muy a la izquierda del cruce: la API gana con holgura. Es el caso de casi cualquier arranque.
  2. Apaga el servidor fuera de horario (h = 260). La horizontal baja mucho y el umbral se desploma. Apagar por la noche es la optimización más barata que existe.
  3. Quita el personal. El umbral vuelve a bajar. Por eso un presupuesto que sólo cuenta GPUs hace parecer rentable un servidor que no lo es.
  4. Sube el coste por consulta (modelo más caro o contexto más largo). La recta se inclina y el cruce se mueve a la izquierda: cuanto más cara es vuestra llamada, antes compensa el servidor.
Comprueba que entiendes: ¿qué razón no económica puede inclinar la decisión hacia el servidor propio aunque el número diga lo contrario?
Tres habituales. Primera, residencia del dato: si vuestros datos no pueden salir de la empresa, el cálculo no manda. Segunda, pesos propios: si habéis ajustado un modelo con LoRA sobre datos vuestros, necesitáis poder servirlo. Tercera, dependencia de proveedor: una subida de precios o un cambio de condiciones os deja sin producto. Las tres son argumentos legítimos; lo que no vale es presentarlas como si fueran ahorro.

Setup. Arriba, las dos curvas y el cruce. Abajo, de qué se compone el coste fijo del servidor.

Juega. Poned el coste por consulta que os salió en la primera slide y vuestro volumen esperado.

Lee así. Si vuestro punto está a la izquierda del cruce, la respuesta es API y el debate se acabó. Si está cerca, mirad el crecimiento previsto a doce meses antes de decidir.

Mensaje. El servidor propio se justifica por volumen sostenido, residencia del dato o pesos propios; casi nunca por precio a volúmenes de arranque.

Términos. coste fijo: el que pagáis aunque nadie pregunte. coste variable: el que crece con el uso. N*: punto de equilibrio. h: horas encendido al mes (730 = 24/7).

las tres palancas, compuestas
Cfinal = Cbase · rtier · rcaché · rbatch (Ec. 14)
Las tres palancas son multiplicativas e independientes: cada una reduce un factor distinto de la factura y se pueden aplicar a la vez. rtier es el cociente de precios entre modelos; rcaché vale 1 − 0,9f sobre la parte de entrada; y rbatch es 0,5 si la respuesta puede esperar.
ahorro = 1 − rtier rcaché rbatch (Ec. 15)
Como se multiplican, el ahorro conjunto es mayor que la suma de los ahorros por separado, y ninguna de las tres cambia lo que el usuario ve — salvo el batch, que introduce latencia.
guion paso a paso
  1. De Opus a Sonnet, sin caché ni batch. Un 40 % menos con un cambio de una línea. Mirad si vuestra tarea de verdad necesitaba el tier alto.
  2. Añade f = 75 %. La barra vuelve a caer. Las dos palancas se componen: no elegís entre una y otra.
  3. Activa el batch. La mitad otra vez. Pero ojo: esta sí cambia el producto, porque la respuesta deja de ser inmediata.
  4. Prueba la combinación extrema: Opus a Haiku, f = 95 %, con batch. Más del 95 % de ahorro. La pregunta ya no es si podéis permitíroslo, sino si Haiku resuelve la tarea.
Comprueba que entiendes: ¿cuál de las tres palancas NO podéis usar en un chat con el usuario delante?
El batch. Las otras dos son invisibles para quien usa el producto: cambiar de modelo altera la calidad pero no la experiencia, y la caché sólo cambia cómo se factura un prompt idéntico. El batch, en cambio, convierte una respuesta inmediata en una que llega en menos de una hora: sirve para clasificar tickets de noche o para generar informes, pero no para conversar.

Setup. Arriba, la factura mensual cayendo palanca a palanca. Abajo, el factor de reducción de cada una por separado y el compuesto.

Juega. Buscad la combinación que os deja dentro de presupuesto y preguntaos qué habéis sacrificado en cada paso.

Lee así. El número grande es el ahorro compuesto. Debajo, cuánto aporta cada palanca: la que más aporte es por donde empezar.

Mensaje. Tres decisiones de arquitectura, ninguna de ellas de investigación, recortan la factura más que cualquier optimización de prompt.

Términos. tier: gama del modelo. batch: API asíncrona con 50 % de descuento. multiplicativo: los factores se componen en vez de sumarse.

tokenTrozo de texto que el modelo procesa como unidad. En castellano, unas 0,75 palabras. La unidad en que se factura todo.
tin, tout Tokens de entrada (lo que mandáis) y de salida (lo que genera). Se facturan a precios distintos.
pin, pout Precio por token. Se publica por millón (MTok); dividid entre 106 antes de usarlo en la fórmula.
NConsultas al mes. El único número del presupuesto que no sale de una tabla: sale de vuestro plan de negocio.
harnessTodo lo que rodea al modelo: system prompt, bucle, herramientas, permisos, contexto y memoria.
TTurnos del bucle del agente. El coste de entrada crece con T².
ΔTokens que cada vuelta añade al contexto: lo que dijo el modelo más lo que devolvió la herramienta.
fFracción del prompt servida desde caché. Se factura al 10 % del precio de entrada.
prefijoEl principio del prompt. La caché casa por prefijo exacto: un byte distinto la invalida entera.
TTLCuánto vive una entrada en caché: 5 minutos (escribir cuesta 1,25×) o 1 hora (2×).
batchAPI asíncrona con 50 % de descuento. Entrega en menos de una hora casi siempre, 24 como máximo.
BVentana de contexto: el máximo de tokens que el modelo puede leer de una vez.
skillManual de procedimiento que el agente abre sólo cuando la tarea encaja. Con carga progresiva paga el índice, no el manual.
podar / compactarBorrar resultados antiguos, o resumirlos. Las dos pierden información; elegid cuál duele menos.
P, b, ρParámetros del modelo (en miles de millones), bytes por parámetro y overhead del runtime.
caché KVLo que la GPU guarda de los tokens ya procesados. Crece con el contexto y con la concurrencia.
cuantizarBajar la precisión de los pesos. INT4 ocupa un tercio que FP16 y pierde poca calidad.
N*Punto de equilibrio: consultas al mes a partir de las cuales el servidor propio sale más barato que la API.
coste fijoLo que pagáis aunque nadie pregunte: GPUs encendidas y personal.
workflowSecuencia de pasos que vosotros fijáis. Si conocéis los pasos, sale más barato y más auditable que un agente.
1 · Del modelo al agente
«Un agente es el mismo modelo metido en un bucle con herramientas y permisos.»
Quitadle el bucle, las herramientas, el criterio de parada o los permisos y vuelve a ser un chatbot. El harness decide su calidad más que el modelo.
↓
2 · El bucle cuesta T²
«La API no tiene memoria, así que cada vuelta reenvía todo lo anterior.»
Csesión = Σ pintn + pouts. Doblar los turnos multiplica la entrada por más de tres. Por eso la primera barandilla es un tope de turnos.
↓
3 · El contexto es un presupuesto
«Cuatro capas comparten la ventana, y sólo una crece sola.»
tsys + tskills + trag + thist ≤ B. Las tres primeras las diseñáis; el historial es consecuencia del bucle y se ataca podando o compactando.
↓
4 · Tres palancas multiplicativas
«Tier, caché y batch recortan la factura sin tocar la funcionalidad.»
C·rtierrcachérbatch. Son independientes y se componen. Sólo el batch cambia lo que el usuario experimenta.
↓
5 · La decisión final es de volumen
«N* = Cfijo / cconsulta, y vuestro volumen cae a un lado o a otro.»
Dimensionad con pesos y caché KV. Contad las GPUs hacia arriba y el personal dentro. El servidor propio se justifica por volumen sostenido, residencia del dato o pesos propios.
Garrido-Merchán — ecgarrido@comillas.edu — Deep Learning para Business Analytics — Tema A · Del modelo al agente