Cómo medir el costo operativo de un gateway de IA

La empresa cierra el contrato del gateway de IA mirando el precio del token y la lista de modelos. Tres meses después, el costo que duele en el P&L no es el token. Es la latencia que el gateway se comió, la memoria que el clúster no había presupuestado y el tiempo de operación que nadie puso en la planilla de compra. El costo operativo de un gateway de IA se mide como delta: misma carga, mismo modelo, misma región, con y sin el gateway en el camino. Sin ese harness, la compra es fe.

¿Qué es el costo operativo de un gateway de IA?

El costo operativo de un gateway de IA es el overhead que el gateway añade en producción: latencia extra en p50, p95 y p99, memoria y CPU del proceso, costo de infraestructura amortizado por millón de requests y, cuando es material, tiempo de operación dedicado a la capa.

No es precio de token. No es calidad del modelo. Es el precio de poner el gateway entre el cliente y el proveedor.

Ese overhead existe en cualquier arquitectura. Proxy dedicado, sidecar en el clúster, gateway gestionado. La forma cambia. La cuenta, no. Quien compra el gateway sin medir el delta acepta un impuesto invisible sobre cada llamada de producción.

La confusión empieza en el vocabulario. El equipo de producto dice "costo de IA" y señala la factura del proveedor. El equipo de plataforma dice "costo de IA" y señala el nodo que se llenó de memoria. Finanzas dice "costo de IA" y señala el tipo de cambio y la nota. Son tres cuentas distintas. Mezclarlas es el defecto que este método existe para impedir.

Requisitos previos antes de medir

Antes del paso 1, el comprador necesita un entorno controlado, métricas comparables en ambos caminos y un dueño claro de la medición, con un criterio de aceptación escrito antes del primer run. Sin eso, el harness se vuelve teatro de dashboard y el gráfico de latencia se vuelve argumento de venta, no evidencia de compra.

Tres insumos abren la puerta. Acceso a un endpoint directo del proveedor (baseline) y al endpoint del gateway bajo evaluación, en la misma región y con el mismo modelo. Herramienta de carga HTTP que exporte percentiles (p50, p95, p99), no solo el promedio: k6, vegeta, Locust o un equivalente interno. Payload representativo de producción: tamaño de prompt, streaming o no, tool calls si existen, temperatura y max tokens fijos.

Sin payload de producción, la prueba mide el laboratorio. El resto del kit cierra la cuenta en dinero y en proceso.

• Métricas de proceso en el host del gateway: RSS/memoria residente, CPU por request o por segundo, réplicas activas.
• Precio unitario de la infra donde corre el gateway (vCPU-hora, GB-hora, request de load balancer) o unit economics del clúster.
• Ventana de prueba con carga lo bastante estable para la cola: miles de requests por escenario, no decenas.

Falta todavía el dueño. Un nombre de plataforma o de SRE y un criterio de aceptación escrito antes del primer run, no después de ver el gráfico. Sin precio de infra, la prueba se detiene en milisegundos y nunca se vuelve dinero. Los dos errores son comunes y caros.

Paso a paso: el método en seis movimientos

El método completo tiene seis pasos ejecutables en orden fijo: definir qué cuenta como overhead del gateway de IA, montar el baseline, medir latencia añadida, medir memoria y CPU, convertir todo en costo por millón de requests y solo entonces fijar criterios de aceptación antes de escalar.

El orden importa. Criterio sin número es opinión. Número sin criterio es decoración.

Los tres primeros movimientos abren el harness:

1. Aislar el overhead del gateway de IA de los otros dos costos de IA.
2. Montar el harness baseline cliente → proveedor.
3. Medir latencia añadida en p50, p95 y p99.

Los tres siguientes cierran la cuenta y la decisión de escala:

1. Medir memoria, CPU y réplicas bajo la misma carga.
2. Convertir recursos en costo operativo por millón de requests.
3. Fijar criterios de aceptación de la carga y decidir la escala.

Cada paso debajo lleva su propio bloque de respuesta, el procedimiento y el criterio de salida. Saltar el orden es el camino más corto hacia un informe bonito e inútil.

Paso 1: Aislar tres costos que la planilla suele mezclar

El primer paso separa, por escrito, tres líneas de costo que la mayoría de las empresas trata como una sola: latencia y calidad del proveedor, precio de token y overhead del gateway de IA. Esta medición cubre solo la tercera línea. Cualquier métrica que mezcle las otras dos con el overhead del gateway invalida el harness en el origen.

La línea (a) responde si el modelo elegido cumple el SLA de calidad y de tiempo de respuesta del proveedor. Eso se mide con evaluación de salida y con latencia de punta a punta en el camino directo, tema cubierto en cómo medir el rendimiento de proveedores de LLM. La línea (b) responde cuánto cuesta cada mil tokens después de tipo de cambio, impuesto y enrutamiento de modelo, tema de colapso del precio del token y costo de IA y de economía de modelo en general. La línea (c) responde lo que la empresa paga, en tiempo y en infra, por poner el gateway en el camino.

El error clásico es reportar la latencia de punta a punta con gateway y llamar a eso "overhead del gateway". No lo es. Es la suma del proveedor, de la red y del gateway. Overhead es diferencia. Sin la resta, el gateway hereda la culpa (o el mérito) del modelo.

Otro error clásico: usar el ahorro de token como prueba de que el gateway "se paga solo". El ahorro de token es línea (b). Puede ser real y aun así el gateway estar demasiado caro en latencia p99 o en memoria. Las dos cuentas necesitan cerrar juntas, en planillas separadas.

Escriba las tres líneas en el documento de aceptación antes de correr carga. Si alguien las mezcla de nuevo en la reunión de resultados, el documento existe para rechazar el gráfico.

Paso 2: Montar el harness baseline y el harness con gateway

El segundo paso monta dos caminos idénticos en todo, excepto en la presencia del gateway de IA. Baseline: cliente de carga → proveedor. Bajo prueba: cliente de carga → gateway → proveedor. Mismo modelo, misma región, mismo payload, misma concurrencia y misma duración definen el laboratorio; el overhead es la diferencia entre los dos caminos, agregada en percentiles.

Controle lo que el laboratorio suele dejar suelto. Warm-up de DNS y TLS en ambos caminos, misma versión de cliente HTTP y mismo keep-alive. Misma política de retry (de preferencia cero retry en el harness de overhead, para no enmascarar falla como latencia). Misma ventana horaria, porque la congestión de red y de proveedor varía a lo largo del día.

La carga necesita ser la de producción, no la del demo. Si el 40% de las llamadas en producción usan streaming, el harness usa streaming. Si el prompt mediano tiene 2.400 tokens de entrada, el harness no corre con "Hello". Si hay tool calls, entran en el escenario o se convierten en un escenario separado. Un único escenario "feliz" subestima la cola.

Registre el harness como artefacto versionado: script de carga, archivo de payload, variables de endpoint, commit hash del gateway bajo prueba, fecha y hora UTC del run. Overhead sin reproducibilidad se vuelve slide. Con reproducibilidad, se vuelve criterio de compra y de release.

Paso 3: Medir latencia añadida en p50, p95 y p99

El tercer paso calcula la latencia que el gateway de IA añade, en percentiles, nunca solo en promedio. Para cada percentil pXX, overhead_pXX = latencia_pXX(con gateway) − latencia_pXX(baseline), en la misma carga. Reporte p50, p95 y p99. El promedio solo esconde la cola y no sostiene un criterio de producción.

La razón es aritmética, no estética. En tráfico alto, p99 es el percentil que el usuario "estacional" siente y en el que el SLO se rompe. Un gateway con +8 ms de promedio y +120 ms de p99 no es un gateway de +8 ms. Es un gateway que falla 1 de cada 100 llamadas respecto del presupuesto de latencia. La literatura de ingeniería de performance trata los percentiles como el estándar de lectura de cola precisamente porque el promedio miente bajo una distribución asimétrica (guía de percentiles p50/p95/p99).

El Google SRE Book fija la misma disciplina del otro lado del contrato: los SLI de latencia se expresan en distribución, y las alertas basadas solo en promedio llegan demasiado tarde (Service Level Objectives, Google SRE). El harness de gateway hereda esa regla. Quien acepta el promedio acepta la sorpresa.

Mida también la tasa de error y de timeout en ambos caminos. Un gateway que añade 3 ms en p50 y duplica el timeout bajo la misma carga no pasó. Overhead de latencia y overhead de confiabilidad van juntos en el informe.

No invente un umbral universal de p99 "bueno". El presupuesto de latencia es de la carga. Un asistente interno asíncrono tolera decenas de milisegundos de más; un autocomplete síncrono en el checkout no tolera. El paso 6 transforma ese presupuesto en criterio de aceptación. Aquí el trabajo es solo medir el delta con honestidad estadística: muestra grande, carga estable, warm-up descartado, cold start aislado si el runtime tiene cold start.

Paso 4: Medir memoria, CPU y réplicas bajo la misma carga

El cuarto paso captura el costo de recurso del proceso del gateway de IA mientras corre la carga del paso 3. Memoria residente (RSS) por réplica, CPU media y de pico por réplica, número de réplicas necesarias para sostener la concurrencia objetivo sin romper el p99 de latencia. Sin esos tres números, el overhead parece solo latencia.

Un gateway es software que procesa cada request: parse, auth, regla de enrutamiento, log, eventual cache, eventual política de fallback. Eso consume CPU y memoria de forma proporcional al tráfico y, en muchos diseños, al tamaño del payload. Una prueba de latencia con una réplica ociosa subestima lo que la producción va a pedir cuando despierte el autoscaler.

Mida en meseta, no en pico transitorio de subida de carga. Suba la concurrencia en escalones. En cada escalón, espere estabilizar, recolecte percentiles de latencia y RSS/CPU, solo entonces suba de nuevo. El gráfico que importa es latencia p99 y memoria versus requests por segundo, con y sin el gateway en el camino. En el baseline, la memoria del gateway es cero por definición; lo que sobra es la memoria del cliente de carga, que se cancela en la comparación de infra del gateway.

Separe memoria steady-state de fuga. Un run de 10 minutos no revela leak. Si la decisión de compra es material, corra al menos una ventana larga (horas) con carga constante y mire la pendiente del RSS. Pendiente positiva continua es costo operativo futuro, no detalle de telemetría.

Anote la configuración: límites de CPU y memoria del contenedor o de la VM, política de GC si hay, tamaño de buffer de log, sampling de trace. Cambiar el sampling de 100% a 1% en medio de la prueba invalida la serie. El harness mide un binario y una config, no una idea.

Paso 5: Convertir recursos en costo operativo por millón de requests

El quinto paso transforma milisegundos y megabytes en dinero por millón de requests del gateway de IA. Sume infraestructura amortizada del gateway (compute, memoria, load balancer, observabilidad dedicada) y, cuando sea material, tiempo de operación (guardia, tuning, incidentes atribuibles a la capa). Divida por el volumen. Ese es el costo operativo unitario del gateway. Todavía no es precio de token.

Fórmula mínima, por período estable:

Costo_infra_gateway = (vCPU-hora × precio_vCPU) + (GB-hora × precio_GB) + (LB y egress atribuibles) + (backend de log/trace si es exclusivo del gateway).

Costo_ops_gateway = horas de ingeniería en el período × costo interno de la hora, solo lo que el gateway exige más allá del camino directo.

Costo_operativo_por_1M = (Costo_infra_gateway + Costo_ops_gateway) / (requests en el período) × 1.000.000.

El precio de token sigue afuera. Entra en el business case total de la IA, en otra pestaña, junto con el ahorro de enrutamiento de modelo descrito en model router middleware a escala. Aquí la pregunta es otra: cuánto paga la empresa por tener el gateway encendido, con independencia de qué modelo atendió el request.

En empresas brasileñas que pagan al proveedor en dólares y la infra local en reales, mantenga las monedas explícitas. Infra de clúster en BRL. Token en USD. Sumar sin FX es el mismo error que mezclar la línea (b) con la línea (c). La página pública de Nexforce Router sostiene cobro en moneda local y el encuadre de crédito fiscal en el camino de adquisición; tipo de cambio, retenciones, CIDE y demás cargos sobre el token quedan en la pestaña de token (línea b), no como atajo para "probar" el gateway sin medir el overhead del propio gateway.

No invente un porcentaje universal de overhead de infra. Clústeres spot, on-demand, serverless y bare metal cambian la cuenta por un factor grande. El método exige el precio de su cuenta cloud o el unit economics de su clúster. Sin ese input, el paso 5 se detiene y el informe queda en recursos físicos, lo que ya es mejor que el promedio de latencia solo, pero todavía no es P&L.

Paso 6: Fijar criterios de aceptación de la carga y solo entonces escalar

El sexto paso cierra el ciclo con criterios de aceptación escritos sobre la carga real, no sobre un benchmark genérico de vendor. Antes de promover el gateway de IA al 100% del tráfico, la empresa declara el presupuesto de overhead que el workload tolera y verifica si el harness pasó en los tres ejes.

Tres ejes bastan en la mayoría de los casos:

Los valores de X, Y, Z y W salen del producto y del SRE, no de este artículo y no del marketing del proveedor. Un autocomplete puede fijar p99 añadido en pocos milisegundos. Un pipeline batch nocturno puede fijar el techo en costo por 1M y casi ignorar p50. El método es el mismo. El presupuesto cambia.

Escale en rebanadas. 5% del tráfico con el harness continuo pegado al deploy. Compare percentiles de la rebanada con el baseline sintético y con el histórico del camino directo. Solo aumente la rebanada si los tres ejes de aceptación siguen en verde. El rollback es parte del criterio, no improvisación de madrugada.

Reevalúe cuando cambie lo que el harness controló: versión major del gateway, regla de enrutamiento que añade fan-out, sampling de trace, modelo dominante, tamaño mediano de prompt. Overhead medido el trimestre pasado en otro payload es arqueología.

Cómo verificar si la medición es correcta

La verificación confirma que el harness mide overhead de verdad, y no un artefacto de laboratorio creado por muestra corta, carga inestable o caminos que difieren en modelo, región o payload. Corra el baseline dos veces seguidas; la diferencia entre las dos corridas baseline debe ser mucho menor que el overhead reportado del gateway.

Si el ruido del baseline se traga el delta, la muestra es pequeña o la carga es inestable.

Los primeros tres ítems matan el harness si fallan:

1. Modelo, región, payload y concurrencia idénticos en ambos caminos.
2. Warm-up descartado; cold start aislado o eliminado.
3. p50, p95 y p99 reportados; el promedio, si aparece, es anexo, no titular.

Los tres siguientes cierran la aritmética y la telemetría:

1. Overhead_pXX calculado por resta de percentiles del mismo escenario, no por feeling de dashboard.
2. RSS/CPU recolectados en la meseta, con config de observabilidad fija.
3. Costo por 1M usa precio real de la cuenta, con moneda explícita.

Faltan proceso y artefacto. Criterios de aceptación fechados y firmados antes del run de go/no-go. Artefactos versionados: script, payload, hash, timestamp UTC. Si el ítem 1 falla, el resto es ficción. Si el criterio llega después del gráfico, el equipo negocia el techo después de ver el número que no le gustó. Los dos son fallas de proceso, no de herramienta.

Errores comunes al medir overhead de gateway

Los errores de abajo aparecen con regularidad en bakes de compra y en postmortems de "el gateway quedó caro", casi siempre porque el equipo midió la suma equivocada, mezcló pestañas del business case o aceptó el gráfico del proveedor en lugar del harness interno. Cada uno tiene corrección directa.

Medir solo la latencia de punta a punta con gateway y llamarla overhead. Corrección: siempre restar el baseline en el mismo escenario.

Reportar el promedio y esconder p99. Corrección: p50, p95 y p99 obligatorios en el informe de aceptación; promedio opcional.

Usar payload de demo. Corrección: capturar la distribución real de tamaño de prompt y de streaming de producción; correr al menos el percentil 50 y el 95 de esa distribución.

Mezclar ahorro de token con costo del gateway es el atajo retórico más común en reunión de compra. Corrección: pestañas separadas en el business case; el gate de compra exige las dos en verde, no una compensando a la otra en el discurso.

Ignorar memoria y réplicas. Corrección: paso 4 obligatorio antes de declarar costo operativo; la latencia sola no cierra el P&L.

Aceptar benchmark de proveedor como aceptación interna. Corrección: el harness es de la empresa, en la cuenta de la empresa, en el payload de la empresa. Un número de marketing es hipótesis, no criterio.

Cambiar config de trace o de log entre baseline y prueba. Corrección: congelar sampling y nivel de log; medir el binario que va a producción.

Declarar el techo de p99 después del gráfico. Corrección: criterio escrito en los requisitos previos y en el paso 6, con fecha anterior al run final.

Tabla de métricas del harness

La tabla resume qué recolectar en el harness del gateway de IA, dónde recolectar cada serie y para qué sirve en la aceptación de compra o de release. Úsela como portada del informe de medición y como checklist de completitud antes de presentar número alguno a la dirección.

Ningún porcentaje mágico de "overhead aceptable" entra en la tabla. El número que importa es el que la carga firmó en el paso 6. El techo es de la carga.

FAQ

¿Cuál es la diferencia entre costo operativo del gateway y costo de token?

Costo operativo del gateway es el overhead del gateway de IA: latencia añadida, compute, memoria, operación. Costo de token es lo que el proveedor cobra por la inferencia, más FX y cargos cuando aplican. Son pestañas distintas del business case. Uno puede mejorar mientras el otro empeora.

¿Se puede medir overhead sin tener el gateway en producción?

Sí. El harness corre en homologación o en una rebanada sombra, siempre que el camino baseline y el camino con gateway usen el mismo modelo, región y payload. Producción valida lo que el laboratorio midió; no sustituye el método.

¿Por qué p99 importa más que el promedio en la latencia de gateway LLM?

Porque la distribución de latencia de llamadas a modelo es asimétrica y la cola es donde se rompe el SLO. El promedio diluye timeouts y spikes. En volumen alto, el 1% de las llamadas es mucha llamada. Los criterios de producción se escriben en p95 y p99; el promedio es comentario.

¿El Nexforce Router elimina la necesidad de este harness?

No. Ningún gateway de IA serio pide fe en lugar de medición. El Nexforce Router concentra observabilidad, reglas, límites de spend y fallback en una API. El harness sigue siendo del comprador: es él quien define el presupuesto de latencia y de infra de su propia carga y verifica el delta antes de escalar.

¿Con qué frecuencia repetir la medición?

En cada cambio que altere el camino crítico: nueva major del gateway, regla de enrutamiento con fan-out, cambio de sampling de trace, cambio del modelo dominante, salto grande en el tamaño de prompt. Como mínimo, en cada ciclo de capacidad en el que el volumen o el mix de escenarios cambie de escalón.

Referencias y lectura complementaria

• Service Level Objectives, Google SRE Book
• Performance Percentiles: p50, p95, p99
• Cómo medir el rendimiento de los proveedores de LLM
• Model Router middleware a escala
• Colapso del precio del token y costo de IA
• Nexforce Router

El siguiente paso después del harness

Con el overhead aislado, el comprador deja de discutir gateway de IA en abstracto y pasa a discutir un número que cabe en criterio de aceptación, en rebanada de tráfico y en renovación de contrato: latencia añadida en p99, costo por millón de requests del gateway, tasa de error contra el baseline.

La capa correcta de gateway se justifica dos veces. Una en la pestaña de token y de modelo, donde reglas, límites y fallback protegen margen y continuidad. Otra en la pestaña de costo operativo, donde el harness prueba que el gateway cabe en el presupuesto de latencia y de infra de la carga. El Nexforce Router existe para la primera conversación con gobernanza centralizada. La segunda conversación nadie la terceriza: mide, resta, acepta o rechaza.

Quien escala sin delta compra narrativa. Quien escala con delta compra infraestructura.