Costo, latencia y LLMOps

Economía de los tokens

Los modelos alojados se cobran por token, normalmente con precios por millón de tokens y con precios distintos para los tokens de entrada (todo lo que se envía: el prompt del sistema, las definiciones de herramientas, los documentos recuperados, el historial de la conversación y el mensaje del usuario) y los tokens de salida (todo lo que se genera). Los tokens de salida suelen costar varias veces más que los de entrada, porque la entrada se procesa en paralelo en una sola pasada (el prefill), mientras que la salida se genera token a token, y cada uno necesita su propia pasada por el modelo (el decode). Los modelos de razonamiento (sección 12.1) también facturan como salida sus tokens internos de razonamiento, aunque no se muestren, de modo que la misma pregunta puede costar cantidades muy distintas según cuánto tiempo piense el modelo.

El costo de una llamada es simplemente tokens de entrada × precio de entrada + tokens de salida × precio de salida. Las sorpresas arquitectónicas están en lo que determina el número de tokens. En un chat, normalmente se vuelve a enviar todo el historial en cada turno, así que la entrada crece con cada turno y el total de una conversación crece aproximadamente con el cuadrado de su longitud. Las definiciones de herramientas y un prompt del sistema largo se pagan en cada llamada. La recuperación añade miles de tokens por pregunta, y los agentes que recorren herramientas en bucle (sección 12.4) hacen varias llamadas por cada solicitud del usuario. En la mayoría de los asistentes en producción, los tokens de entrada dominan la factura aunque cada uno sea más barato.

Autoalojar un modelo de pesos abiertos cambia la forma del costo en lugar de eliminarlo: pagas el tiempo de GPU tanto si se usa como si no, así que el costo por token depende de la utilización y de cuántas solicitudes puede procesar el servidor a la vez. Los hábitos de FinOps de la sección 10.8 se aplican directamente: expresa el costo por unidad de valor de negocio (por conversación, por ticket resuelto, por documento procesado), compáralo con la alternativa (el costo de gestión de un agente humano) y asígnalo a funciones y equipos. Los precios de esta sección son cifras ilustrativas elegidas para facilitar la aritmética, no precios de lista actuales; los precios reales varían entre proveedores y han bajado mucho con el tiempo.

Latencia: tiempo hasta el primer token y velocidad de generación

La latencia de una respuesta del modelo tiene dos partes principales. El tiempo hasta el primer token (TTFT) abarca todo lo que ocurre antes de que llegue el primer token de salida: tu propio preprocesamiento (guardrails de entrada, recuperación, re-ranking), la red, la espera en cola en el proveedor y el prefill, que crece con el número de tokens de entrada. Después, la salida llega a la velocidad de generación del modelo, medida en tokens de salida por segundo, así que el tiempo total es aproximadamente TTFT + tokens de salida ÷ tokens por segundo. Los modelos de razonamiento añaden una fase de pensamiento antes del primer token visible, que puede durar segundos o minutos.

De ello se derivan dos consecuencias. Primero, la longitud de la salida suele ser la mayor palanca sobre la latencia: reducir a la mitad una respuesta de 400 tokens ahorra más tiempo que cualquier optimización de red. Pedir respuestas concisas, fijar una longitud máxima de salida y usar salidas estructuradas en lugar de prosa ayudan. Segundo, cada llamada a una herramienta es un viaje de ida y vuelta adicional completo, con su propio prefill y su propio decode, así que un agente que hace cuatro llamadas a herramientas antes de responder es cuatro veces más lento que una sola llamada, sea cual sea la velocidad del modelo. Especifica y monitoriza la latencia como percentiles, no como medias (sección 2.4): el TTFT p95 y el tiempo total p95 por turno, porque la espera en cola de los proveedores de modelos hace que la cola de la distribución sea mucho más larga que la mediana en los momentos de mucha carga.

Streaming

El streaming envía los tokens al cliente a medida que se generan, normalmente como server-sent events sobre HTTP. No hace que la respuesta termine antes, pero los usuarios juzgan la capacidad de respuesta sobre todo por el momento en que algo empieza a ocurrir, así que una respuesta de 4 segundos que empieza tras 1 segundo parece mucho más rápida que una que aparece de golpe. El streaming tiene costos arquitectónicos. Cada proxy, gateway y balanceador de carga del camino debe dejar pasar el flujo sin almacenarlo en búfer y mantener abiertas conexiones de larga duración. Los guardrails de salida (sección 12.6) ya no pueden inspeccionar la respuesta completa antes de que el usuario la vea, así que o bien comprueban los fragmentos a medida que pasan (y puede que tengan que retirar texto ya mostrado), o bien retienen el flujo una frase aproximadamente. Las salidas estructuradas que desencadenan acciones no pueden ejecutarse hasta que estén completas y validadas, así que envía la prosa al usuario en streaming y deja las acciones para el final. La facturación, el logging y el trazado deben poder gestionar flujos que el cliente abandona a medias.

Caché de prompts y caché semántica

La caché de prompts (prompt caching, también llamada prefix caching o context caching) reutiliza el estado interno calculado por el proveedor para un prefijo de prompt idéntico que se procesó recientemente. Los tokens de entrada en caché se facturan con un fuerte descuento (algunos proveedores cobran alrededor de una décima parte del precio normal de entrada, otros aplican un descuento menor, y algunos cobran un recargo por escribir en la caché) y se omite el prefill de esa parte, lo que también reduce el TTFT. Es la optimización de costos más eficaz para asistentes con instrucciones largas y estables. Solo funciona si el prefijo es idéntico byte a byte, así que la disposición del prompt se convierte en una inquietud arquitectónica: pon primero el contenido estático (prompt del sistema, definiciones de herramientas, políticas, ejemplos few-shot), después el contenido que cambia lentamente (el historial de la conversación) y al final el contenido de cada solicitud (los documentos recuperados, el mensaje nuevo). Una marca de tiempo o el nombre del usuario al principio del prompt del sistema anula la caché sin que nadie lo note. Los servidores de inferencia autoalojados, como vLLM, ofrecen la misma técnica, conocida como automatic prefix caching (caché automática de prefijos).

La caché semántica es diferente: almacena respuestas completas indexadas por el significado de la pregunta, mediante embeddings, y devuelve una respuesta almacenada cuando una pregunta nueva es lo bastante similar, sin llegar a llamar al modelo. Puede ahorrar mucho en preguntas repetitivas y no personales (¿cuál es su horario de reparto?), pero es más arriesgada de lo que parece. Preguntas similares pueden necesitar respuestas distintas (¿puedo cancelar mi pedido? y cancela mi pedido), el umbral de similitud equilibra la tasa de aciertos frente a las respuestas erróneas, y las reglas de la sección 7.6 siguen aplicándose: la clave debe incluir todo lo que cambia la respuesta, las respuestas en caché quedan obsoletas cuando cambian las políticas y nada personal debe servirse nunca desde una caché compartida. Mide la tasa de falsos aciertos en una muestra etiquetada antes de confiar en ella. Una simple caché de coincidencia exacta para llamadas deterministas, como la clasificación a temperatura 0, es más sencilla y segura.

Procesamiento por lotes

No todas las llamadas a modelos necesitan una respuesta en segundos. El resumen nocturno, el etiquetado de una acumulación de tickets pendientes, la generación de embeddings para una reindexación y la ejecución de baterías de evaluación pueden esperar. La mayoría de los grandes proveedores ofrecen interfaces por lotes (batch) que aceptan un archivo de solicitudes y devuelven los resultados de forma asíncrona dentro de un plazo indicado (normalmente de hasta 24 horas) con un descuento considerable, a menudo de alrededor de la mitad del precio normal, y con límites de tasa separados y más amplios. Desde el punto de vista arquitectónico, se trata del procesamiento asíncrono basado en colas de la sección 9.3: diseña el trabajo para que sea idempotente, haz el seguimiento del estado de cada solicitud y gestiona los fallos parciales.

En los modelos autoalojados, el procesamiento por lotes ocurre dentro del servidor de inferencia: el batching continuo (continuous batching) intercala los pasos de decode de muchas solicitudes concurrentes en una sola GPU, lo que multiplica el rendimiento (throughput). El compromiso es el conocido entre throughput y latencia: lotes más grandes significan tokens más baratos pero respuestas individuales más lentas, así que el tráfico interactivo y el offline suelen servirse desde grupos (pools) separados con configuraciones distintas.

Selección de modelos y cascadas para reducir costos

La mayor decisión de costos es qué modelo gestiona cada tarea, y la respuesta suele ser el más pequeño que supera la batería de evaluación de esa tarea (sección 12.5). Los precios de los modelos pequeños y grandes suelen diferir en un factor de diez o más, mientras que muchas tareas (clasificar la intención, extraer un número de pedido, responder una pregunta sobre el estado a partir de datos estructurados) no necesitan un modelo grande. El enrutamiento envía cada solicitud a un modelo adecuado según una clasificación barata; una cascada de modelos prueba primero con un modelo pequeño y escala a uno más grande cuando la salida no supera la validación o el modelo pequeño indica poca confianza (sección 12.2). FrugalGPT (Chen, Zaharia y Zou, 2023) mostró cascadas que igualaban la calidad del modelo más potente por una fracción del costo en sus benchmarks.

El costo esperado de una cascada de dos pasos es el costo del modelo pequeño más la tasa de escalado multiplicada por el costo del modelo grande. Por tanto, las cascadas solo compensan cuando la mayoría de las solicitudes se quedan en el modelo pequeño, y tienen una trampa de latencia: las solicitudes escaladas pagan ambos intentos, así que la cola se vuelve más lenta aunque la media mejore. El enrutamiento previo evita el doble intento, pero depende de la precisión del enrutador. Otras reducciones de tokens suelen ser aún más baratas: recorta el prompt del sistema, recupera menos fragmentos pero mejores, resume los turnos más antiguos de la conversación, limita la longitud de la salida, reduce el esfuerzo de razonamiento de los modelos de razonamiento en las tareas fáciles y, para una única tarea de muy alto volumen, considera hacer fine-tuning o destilar un modelo pequeño.

Cuotas, límites de tasa y escaleras de alternativas

Los proveedores de modelos imponen límites de tasa: solicitudes por minuto, tokens de entrada y de salida por minuto, solicitudes concurrentes y, a veces, topes diarios, señalados mediante respuestas HTTP 429, normalmente con una cabecera Retry-After. Tu propio gateway también debe imponer cuotas, por usuario, por inquilino (tenant) y por función, tanto para repartir la capacidad de forma justa como para defenderse del riesgo de consumo ilimitado de la sección 12.6. Los patrones de resiliencia de la sección 9.4 siguen siendo válidos: timeouts en cada llamada, reintentos con backoff exponencial y jitter solo para los errores reintentables, circuit breakers, bulkheads que impiden que una función ruidosa agote la cuota compartida, y degradación elegante (una respuesta predefinida y un enlace al soporte humano son mejores que un indicador de carga girando sin fin).

Una escalera de alternativas (fallback ladder) enumera modelos y proveedores alternativos que se prueban en orden cuando la primera opción falla, alcanza su límite de tasa o devuelve un resultado no válido. Las buenas escaleras tienen un presupuesto de tiempo total para que el usuario no tenga que esperar a que se recorran todos los peldaños, dejan enfriar un peldaño durante el tiempo que pida el proveedor tras un 429 en lugar de bombardearlo, tratan una respuesta imposible de analizar o que no cumple el esquema como un fallo que pasa al siguiente peldaño, y mantienen los prompts portables entre modelos. Cada peldaño debe superar la batería de evaluación: un modelo alternativo sin probar es una caída silenciosa de la calidad justo cuando el sistema está bajo presión. Las propias funciones de IA de este curso funcionan así. ArchitectBot y el corrector de las pruebas recorren una escalera de modelos de pesos abiertos alojados, con un timeout por modelo y un presupuesto de tiempo global, pausan un modelo tras una respuesta de límite de tasa durante el tiempo que pida el proveedor y, como último recurso, recurren a un segundo proveedor; las búsquedas web tienen topes diarios y mensuales, y los visitantes tienen límites de tasa.

LLMOps: versionado, trazado y monitorización de costos

LLMOps es el conjunto de prácticas para construir, lanzar y operar aplicaciones basadas en modelos de lenguaje grandes, que adapta MLOps y DevOps a componentes cuyo comportamiento lo definen los prompts, los modelos y los datos tanto como el código. Su primera regla es que todo lo que da forma al comportamiento es un artefacto versionado: las plantillas de prompts (guardadas en el repositorio o en un registro de prompts con identificadores de versión inmutables), los identificadores de modelo fijados a versiones con fecha en lugar de alias flotantes, los esquemas de las herramientas, la configuración de recuperación, el modelo de embeddings y la versión del índice (cambiar el modelo de embeddings significa volver a calcular los embeddings de todo el corpus), las reglas de los guardrails y los conjuntos de datos de evaluación. Una versión es una combinación concreta de todo esto, desplegada mediante el mismo pipeline, las mismas feature flags y los mismos canarios que el código (sección 10.5), con sus resultados de evaluación adjuntos.

La segunda regla es que se traza cada llamada al modelo. Cada llamada se convierte en un span de la traza distribuida de la solicitud del usuario (sección 9.6) que registra el modelo, la versión del prompt, el número de tokens de entrada y de salida, la latencia, el TTFT, el costo y el resultado, con spans hijos para la recuperación y las llamadas a herramientas, de modo que una respuesta lenta o errónea pueda seguirse paso a paso. Las convenciones semánticas de OpenTelemetry para IA generativa estandarizan los nombres, como gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model y gen_ai.usage.input_tokens, junto con métricas de la duración de las operaciones y del uso de tokens. A octubre de 2026, estas convenciones siguen en estado Development y se han trasladado recientemente a su propio repositorio; los nombres han cambiado entre versiones (gen_ai.system pasó a ser gen_ai.provider.name, por ejemplo, y las métricas de tokens se están reorganizando), así que fija la versión que emite tu instrumentación. Registrar el texto de los prompts y de las respuestas generadas (completions) es opcional (opt-in) en las convenciones, y con razón: captura datos personales, así que necesita los controles de conservación y de acceso de la sección 12.8.

La tercera regla es que el costo se monitoriza como la latencia. Atribuye el gasto en tokens por función, inquilino, modelo y versión del prompt; fija presupuestos con alertas tanto sobre el gasto absoluto como sobre el costo unitario (costo por conversación); y vigila las señales de problemas: un cambio de prompt que duplicó los tokens de entrada, un agente atascado en un bucle de herramientas, una tasa de aciertos de caché que se desplomó tras un despliegue o una cuenta que genera una décima parte de todo el tráfico. Por último, la evaluación se ejecuta en el pipeline (sección 12.5), de modo que el costo, la latencia y la calidad se juzguen juntos en cada lanzamiento.

from opentelemetry import trace

tracer = trace.get_tracer("support-assistant")

def ask_model(client, messages, model="medium-2026-05", prompt_version="refund-v14"):
    with tracer.start_as_current_span(f"chat {model}") as span:
        span.set_attribute("gen_ai.operation.name", "chat")
        span.set_attribute("gen_ai.provider.name", "example-provider")
        span.set_attribute("gen_ai.request.model", model)
        span.set_attribute("app.prompt.version", prompt_version)  # our own attribute
        reply = client.chat(model=model, messages=messages, max_tokens=300)
        span.set_attribute("gen_ai.usage.input_tokens", reply.usage.input_tokens)
        span.set_attribute("gen_ai.usage.output_tokens", reply.usage.output_tokens)
        return reply