El sistema anterior tomaba una sola decisión, una vez: cargar los 46 modelos en una GPU fija y dejarlos ahí. Todo lo demás —cuánto cuesta, cuánto escala, qué pasa si un modelo no cabe— era consecuencia de esa decisión. La plataforma nueva decide en tiempo de ejecución: qué modelo vive dónde, cuándo se descarga, cuánta capacidad encender y cuándo apagarla toda. Este informe contrasta ambas infraestructuras contra la factura real de Google Cloud y contra lo medido en producción.
Construir un sistema dinámico significó escribir un servicio de control que
decide placement, ruteo, carga, descarga y capacidad —
triton-controller —, un catálogo declarativo de modelos
por entorno, un gate de CI que mide recursos reales antes de dejar entrar un
modelo, y la infraestructura que todo eso necesita. El cambio de GPU es
uno de los resultados: recién cuando el sistema dejó de necesitar que
todos los modelos vivieran juntos en una GPU grande, una GPU chica pasó a ser
viable.
Antes, atender un pico significaba encender otra A100 con los 46 modelos. Ahora el controller coloca el modelo pedido y sus dependencias donde ya hay VRAM libre.
El legacy declaraba minReplicas: 1: la GPU nunca se apagaba. Los tres pools nuevos declaran min_nodes = 0 y levantan capacidad por request.
Migrando la carga real de agosto (1.037 horas de GPU) sin cambiar nada más: $4.153 → $879. A eso se suma el entorno de pruebas, que deja de costar cuando está ocioso.
El pico de julio — el mes más caro del año — fue en buena parte un entorno de pruebas encendido, no crecimiento de producción. Es el costo que el diseño nuevo elimina por construcción.
El costo por hora de GPU de ambos sistemas está medido en la factura:
$4,04/h en lucro-recognition-system durante ocho meses,
$0,85/h en hub-gpu-prod desde el corte a L4 del 5 de septiembre.
El ahorro mensual es una proyección: hoy la plataforma nueva todavía no absorbe la producción. La proyección asume que una hora de L4 hace el mismo trabajo que una hora de A100 — supuesto que se sostiene en la medición de latencia de la sección 6, donde L4 resultó más rápida, no más lenta.
La separación entre producción y pruebas es un prorrateo: la factura no trae dimensión de namespace, así que las horas de cada entorno se tomaron de Cloud Monitoring y esa proporción se aplicó al costo. Los totales son de factura; el corte entre ambos entornos, no.
Los dos sistemas sirven los mismos modelos con el mismo motor — NVIDIA Triton Inference Server. La diferencia está en quién decide qué modelo vive en qué GPU. En el legacy nadie lo decide: todos viven juntos, siempre. En el nuevo lo decide un servicio, request por request.
lucro-recognition-system · GKE Autopilot
hub-gpu-prod · GKE Standard + triton-controller
Los pods GPU de Autopilot no facturan lo que el pod pide: facturan el nodo físico
completo que hizo falta para alojarlo. El sistema legacy pedía
2 vCPU y 16 GB, y pagaba un
a2-highgpu-1g entero — 12 vCPU y 85 GB — más el recargo de
Autopilot por acelerador. La GPU es sólo 73% de esa factura.
| Componente | USD | Cantidad | $/hora GPU |
|---|---|---|---|
| Nvidia Tesla A100 Nvidia Tesla A100 GPU running in Americas | 19.036 | 6.488 h | 2,934 |
| vCPU del nodo A2 Instance Core running in Americas | 2.461 | 77.859 h | 0,379 |
| RAM del nodo A2 Instance Ram running in Americas | 2.337 | 551.502 GiB·h | 0,360 |
| Recargo Autopilot Autopilot A100 40GB / Accelerator CPU / Memory Premium | 2.122 | — | 0,327 |
| A100 sobre Autopilot | 25.956 | 6.488 h | 4,00 |
| Componente | USD | Cantidad | $/hora GPU |
|---|---|---|---|
| Nvidia L4 Nvidia L4 GPU running in Americas | 58,5 | 105 h | 0,557 |
| vCPU del nodo G2 Instance Core running in Americas | 20,9 | 837 h | 0,199 |
| RAM del nodo G2 Instance Ram running in Americas | 9,7 | 3.317 GiB·h | 0,092 |
| L4 dedicada | 89,1 | 105 h | 0,85 |
La ADR-035 (5 de septiembre) eligió L4 usando precios de lista de terceros y anotó
explícitamente que hacía falta «confirmar contra la consola de Cloud Billing antes
de comprometer el análisis a una decisión final». Su estimación para
g2-standard-8 fue $0,8536/hora.
La factura de septiembre dice $0,85. La estimación con la que
se decidió era correcta.
Aislar la capa de inferencia importa: de los $92.389 que
lucro-recognition-system gastó en el periodo, la inferencia
son $26.207. El resto es BigQuery, AlloyDB, red y las demás
piezas del producto. Sobre esa porción, el costo por hora se mantuvo plano en ~$4
durante los nueve meses — lo que subió fueron las horas.
hub-gpu-prod pagó A100 para la VM de
medición de recursos y para el experimento de consolidación con MIG, que se midió y
se descartó. Recién desde el 5 de septiembre la infraestructura tiene su forma
de producción.
| Mes | Legacy USD | Legacy GPU·h | $/h | hub-gpu-prod USD |
|---|---|---|---|---|
| Enero | 1.829 | 448 | 4,09 | — |
| Febrero | 2.067 | 504 | 4,10 | — |
| Marzo | 2.294 | 553 | 4,15 | — |
| Abril | 2.275 | 557 | 4,09 | 7 |
| Mayo | 2.498 | 610 | 4,10 | 320 |
| Junio | 3.483 | 861 | 4,05 | 715 |
| Julio | 6.070 | 1.535 | 3,95 | 637 |
| Agosto | 4.153 | 1.037 | 4,01 | 408 |
| Septiembre (1–17) | 1.538 | 385 | 4,00 | 460 |
| Periodo completo | 26.207 | 6.488 | 4,04 | 2.545 |
La factura no distingue entornos — no trae namespace. Cloud Monitoring sí: dentro
del proyecto legacy hay dos namespaces con contenedores GPU,
recognition-prod y recognition-dev.
Puestos lado a lado, el mes más caro del año deja de ser una historia de crecimiento.
gpu-test-l4 baja a cero nodos y el controller lo vuelve a
levantar cuando llega un request.
Mové las horas de GPU al mes y compará. Los dos precios por hora son los medidos en la factura: $4,04 para A100 sobre Autopilot y $0,85 para L4 dedicada. La sustitución es hora por hora, que es un supuesto conservador — en la medición de latencia la L4 resultó más rápida.
El costo por hora es la mitad del argumento. La otra mitad es que el sistema nuevo necesita menos horas para la misma carga, porque puede apagar lo que no se usa y mover lo que sí.
Un modelo recibe un pico de tráfico. En el legacy, la única palanca es replicar el Deployment: se enciende otra A100 y se cargan los 46 modelos otra vez, aunque 45 estén ociosos.
En el nuevo, el controller coloca réplicas adicionales de ese modelo — con sus dependencias, en orden topológico — en pods que ya tienen VRAM libre.
El legacy declara minReplicas: 1. La A100 queda encendida las 24 horas, haya o no tráfico, porque apagarla significaría perder los 46 modelos cargados y pagar el cold-start completo al volver. Eso vale para producción y también para el entorno de pruebas: 702 horas de GPU en el periodo, 645 de ellas en julio.
Los tres pools nuevos declaran min_nodes = 0. El controller levanta capacidad desde cero cuando llega un request sin placement, y el reaper de inactivos devuelve VRAM sin esperar a que haya presión. Un entorno de pruebas que nadie usa no cuesta nada.
En el legacy, prod y las pruebas compartían la misma forma de despliegue y, en el experimento de consolidación, el mismo nodo físico. Una falla o un mantenimiento afectaba a todo a la vez.
Ahora cada entorno tiene su propia GPU física y su propio catálogo de modelos.
gpu-prod-l4 no comparte hardware con
gpu-elastic-l4 ni con gpu-test-l4.
En el legacy, que un modelo entrara en memoria junto a los otros 45 se descubría en producción. No había control automático previo.
Ahora ningún modelo llega a staging sin pasar un gate que
lo carga en hardware real, corre una inferencia real con una imagen real y mide
CPU, RAM y VRAM. Desde la ADR-0026, ese gate mide sobre L4 — la misma GPU que
sirve en producción — y no sobre A100.
Una GPU más barata suele significar un peor servicio. Acá no. La ADR-034 midió, con
una comparación de control, que el ~2× de latencia que se había observado venía del
particionado MIG de la A100, no de la arquitectura del chip. Sobre L4 dedicada, el
pipeline real de alpina_afiches contra el endpoint de
producción dio p50 de 224 ms, frente a 323 ms
en A100. El cold-start desde nodo apagado quedó igual:
391 s contra ~360 s.
Datos de costo. Exportaciones CSV de la tabla de costos de Cloud Billing (cuenta 01DB70-652EAE-B4124D), un archivo por mes de facturación, enero a septiembre de 2026 — el histórico completo disponible en la cuenta. Cada fila trae proyecto, servicio, SKU, fecha, cantidad y costo sin redondear.
Atribución a la capa de inferencia. Del proyecto legacy se tomaron sólo los SKUs del nodo GPU: Nvidia Tesla A100 GPU running in Americas, A2 Instance Core y Ram running in Americas, y los recargos Autopilot A100 40GB / Accelerator CPU / Memory Premium. La aritmética se verifica sola: 6.488 horas de GPU × 12 vCPU del a2-highgpu-1g = 77.856, y la factura registra 77.859 horas de A2 Instance Core. Del proyecto nuevo, los SKUs equivalentes de L4 y G2.
Separación entre producción y pruebas. La exportación de facturación no trae namespace, así que el corte por entorno viene de Cloud Monitoring: la métrica kubernetes.io/container/accelerator/duty_cycle agregada por hora y agrupada por namespace_name, sobre el cluster autopilot-cluster. Da 6.765 horas de contenedor GPU en recognition-prod y 702 en recognition-dev. Esa proporción se aplicó al costo facturado; es un prorrateo, no una cifra de factura.
Verificación. Los totales por proyecto de cada mes se contrastaron contra lo que muestra la consola de facturación. Agosto: $11.347,08 para lucro-recognition-system y $407,56 para hub-gpu-prod, idénticos en ambas fuentes.
Datos de arquitectura y latencia. Manifiestos de Kubernetes y Terraform de ambos repositorios, configuración viva de los clusters en GCP, y las ADR-021, 026, 034, 035, 039, 040 y 042 de inference-platform y recognition-system-inference.