Phase 17 - Lesson 27

FinOps para LLMs — Economía Unitaria y Atribución Multi-Tenant

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

FinOps tradicional no funciona con el gasto de LLMs. Los costos son transacciones de tokens, no tiempo de actividad de recursos. Las etiquetas no se mapean: una llamada de API es una transacción, no un activo. Las decisiones de ingeniería (diseño de prompts, ventana de contexto, longitud de salida) son decisiones financieras. El manual de 2026 tiene tres dimensiones de atribución para instrumentar desde el primer día: por usuario (user_id) para fijación de precios por asiento y expansión, por tarea (task_id + route) para costo de superficie del producto y priorización, por inquilino (tenant_id) para economía unitaria y renovación. Cuatro capas de tokens: prompt, herramienta, memoria, respuesta; un solo contenedor oculta el gasto. Escala de aplicación para productos multi-tenant: límites de tasa por inquilino (2-3x el pico esperado, 429 claro + retry-after); tope de gasto diario (1.5-3x el límite contratado; activa restricción de tasa + alerta); interruptores de apagado (kill switches) con z-score de gasto > 4 (pausa automática + notificación de guardia). Patrones de atribución: etiquetar y agregar, unión de telemetría (trace-ID → facturación; máxima precisión), muestreo y extrapolación, alocación basada en modelos, event-sourced, streaming en tiempo real. Métrica unitaria: costo por consulta resuelta, costo por artefacto generado; no $/M tokens. El etiquetado retroactivo siempre falla; instrumente al crear la solicitud.

Tipo: Learn Lenguajes: Python (stdlib, simulador simple de atribución de costos con interruptor de apagado) Prerrequisitos: Fase 17 · 13 (Observabilidad), Fase 17 · 14 (Caching) Tiempo: ~60 minutos

Objetivos de Aprendizaje

• Explicar por qué FinOps tradicional (etiquetas + niveles) no funciona con el gasto en LLMs y nombrar las tres nuevas dimensiones de atribución.
• Enumerar las cuatro capas de tokens (prompt, herramienta, memoria, respuesta) y por qué la facturación en un solo contenedor oculta el costo.
• Diseñar una escala de aplicación (límite de tasa → tope de gasto → interruptor de apagado) para un producto multi-tenant.
• Elegir una métrica unitaria (costo por consulta resuelta / artefacto) en lugar de $/M tokens.

El Problema

Tu factura indica $40,000. No sabes:

• Qué inquilino lo gastó.
• Qué función del producto lo impulsó.
• Si algún usuario individual fue abusivo.
• Si el culpable fue la saturación del prompt, las llamadas a herramientas o la amplificación de memoria.

Etiquetar y agregar en el lado del proveedor funciona para recursos de nube (EC2, S3) donde las etiquetas se propagan a los elementos de línea. Las llamadas a la API de LLM no se etiquetan automáticamente; tienes que registrar el usuario/tarea/inquilino en el sitio de la llamada y mantenerlo. La atribución retroactiva siempre pierde casos límite.

El Concepto

Tres dimensiones de atribución

Por usuario (user_id): quién cuesta qué. Impulsa los precios por asiento, las conversaciones de expansión e identifica a los usuarios avanzados.

Por tarea (task_id + route): qué superficie de producto cuesta qué. Impulsa la priorización de funciones y las decisiones de eliminar funciones costosas.

Por inquilino (tenant_id): qué cliente es rentable. Impulsa la economía unitaria, los precios de renovación y los umbrales de nivel.

Instrumenta los tres en el sitio de la llamada desde el primer día. Lo retroactivo siempre es peor.

Cuatro capas de tokens

Agrupar los cuatro hace que la optimización sea ciega. Sepáralos en tu esquema de atribución.

Escala de aplicación

1. Límite de tasa (Rate limit) por inquilino. 2-3x el pico esperado. Devuelve 429 con Retry-After. El inquilino experimenta fricción; sin sorpresas en la factura.

2. Tope de gasto diario (Daily spend cap) por inquilino. 1.5-3x el límite contratado. Gatillo: restringir el límite de tasa + alertar a customer success.

3. Interruptor de apagado (Kill switch) con z-score de gasto > 4 en relación con la línea base del inquilino. Pausa automática del inquilino; notificación al encargado de guardia; escalada a operaciones + CS.

Patrones de atribución

• Etiquetar y agregar: coloca encabezados de metadados; agrega más tarde. Simple; aproximado.
• Unión de telemetría (Telemetry joiner): une trazas con facturación a través de IDs de traza. Máxima precisión. Lo que hacen los equipos maduros.
• Muestreo + extrapolación: toma muestras del 5-10%, multiplica. Rentable para gastos aproximados; pierde los comportamientos de cola.
• Alocación basada en modelos: regresión para inferir los factores de costo. Para datos heredados sin etiquetas.
• Basado en eventos (Event-sourced): costo como eventos en un flujo (Kafka / Kinesis). En tiempo real.
• Streaming en tiempo real: actualizaciones del tablero en menos de un segundo.

Costo por X es la métrica unitaria

$/M tokens es jargón de proveedor. Métricas de producto:

• Costo por ticket de soporte resuelto.
• Costo por artículo generado.
• Costo por tarea de agente exitosa.
• Costo por minuto de sesión de usuario.

Vincula el costo con un resultado del producto. De lo contrario, la optimización carece de anclaje.

Formato de traza de atribución de costos

trace_id: abc123
  user_id: u_42
  tenant_id: t_7
  task_id: task_classify_doc
  route: model_haiku
  layers:
    prompt_tokens: 1800
    tool_tokens: 600
    memory_tokens: 400
    response_tokens: 150
  cost_usd: 0.0135
  cached_input: true
  batch: false

Emita en cada llamada. Almacene en un data lake. Agregue por dimensión. La pila de observabilidad de la Fase 17 · 13 es donde reside esto.

La pila de ahorro compuesto

Pila: caché + lote (batch) + ruta + gateway. Con los cuatro:

• Caché L2 (Fase 17 · 14): entrada ~10x más barata.
• Lote / Batch (Fase 17 · 15): 50% de descuento.
• Rota a modelo barato (Fase 17 · 16): reducción de costo del 60%.
• Eficiencia del gateway (Fase 17 · 19): redundância + reintentos.

Mejor caso combinado: ~5-10% de la línea base simple. La mayoría de los equipos tienen 2 o 3 palancas activas; pocos combinan las cuatro.

Números que debes recordar

• Dimensiones de atribución: por usuario, por tarea, por inquilino.
• Cuatro capas de tokens: prompt, herramienta, memoria, respuesta.
• Interruptor de apagado: z-score de gasto > 4.
• Métrica unitaria: costo por consulta resuelta, no $/M tokens.
• Optimizaciones combinadas: ~5-10% de la línea base posible.

Use It

El archivo code/main.py simula un servicio de LLM multi-tenant con la escala de aplicación de tres niveles. Inyecta un inquilino abusivo y demuestra la activación del interruptor de apagado.

Ship It

Esta lección produce outputs/skill-finops-plan.md. Dados el producto y la escala, diseña el esquema de atribución y la escala de aplicación.

Ejercicios

1. Ejecuta code/main.py. ¿Con qué z-score se activa el interruptor de apagado? ¿Cómo eliges el umbral?
2. Diseña un tablero de costos por inquilino y por tarea. ¿Cuáles son las primeras 5 vistas que construirías?
3. Tu inquilino más grande tiene una economía unitaria negativa. Propón tres intervenciones ordenadas por el impacto en el cliente.
4. Calcula el costo por ticket resuelto para un producto de soporte: 3M tokens/ticket, ~800 tickets/día, tarifa con caché de GPT-5.
5. Discute si el etiquetado retroactivo puede funcionar alguna vez. ¿Cuándo es aceptable?

Términos Clave

Lecturas Recomendadas

• FinOps Foundation — FinOps for AI Overview
• FinOps School — Cost per Unit 2026 Guide
• Digital Applied — LLM Agent Cost Attribution 2026
• PointFive — Managed LLMs in Azure OpenAI