Capítulo 15 — APIs serverless frente a infraestructura dedicada

Decimoquinta entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que pone sobre la mesa la aritmética del punto de equilibrio y luego nombra el renglón de ingeniería de plataforma que decide la respuesta para la mayoría de los equipos.

Por qué existe este capítulo

El Capítulo 14 dejó al equipo con una imagen limpia de qué compone la factura de API, y una sospecha silenciosa de que podría ser más barata. La siguiente pregunta natural es si el equipo debería estar pagando por token en absoluto. La alternativa es traer la inferencia a casa, correr un modelo de pesos abiertos sobre el stack que los capítulos anteriores describieron, y pagar por hora-GPU en su lugar. El intercambio tiene un punto de equilibrio limpio. Lo que es menos limpio, y lo que la mayoría de los equipos subestima, es todo lo que hay en el lado dedicado del libro que no está en la factura de la GPU — la ingeniería de plataforma, los parches de seguridad, la coreografía de actualización de modelo, el aviso de las 3 de la mañana cuando un nodo se cae de la flota. El Capítulo 15 toma en serio ambos lados y deriva cuándo el autohost es la respuesta correcta.

15.1 La fórmula del punto de equilibrio es limpia y, en su mayor parte, un señuelo

La GPU produce throughput × utilización × 3.600 tokens de salida por hora. Su coste por millón de tokens es (gpu_por_hora / tokens_por_hora) × 1.000.000. El punto de equilibrio frente a la API es donde ese número iguala el precio por millón de la API. Un modelo de 70B en FP8 sobre un H100 a 3 $/hora, corriendo 800 tokens por segundo agregados al 60 por ciento de utilización, sale a aproximadamente 1 $ por millón de tokens de salida. La API frontera cobra 15 $. El ahorro aparente es 14× — un argumento a favor del autohost que le encanta a finanzas y al que se le está escapando el segundo renglón, mayor. El punto de equilibrio también depende de la utilización; por debajo del 20–30 por ciento de utilización el coste por millón autohosteado sube por encima de la tasa de API y la GPU se vuelve más cara que la alternativa que se suponía que desplazaba. La utilización, a su vez, es función de la forma del tráfico, de la calidad del autoscaling, y de si el equipo puede empaquetar más de una carga sobre la misma flota.

15.2 La ingeniería de plataforma es el renglón que decide el trato

La factura de la GPU es la mitad pequeña. La mitad grande es el equipo que mantiene la flota corriendo: motores, drivers, orquestación, autoscaling, observabilidad, seguridad. El equipo de API paga este coste implícitamente a través del precio por token; el equipo autohost lo paga en headcount. Una regla de andar por casa útil: una única flota de serving de GPU — uno o dos variantes de modelo, autoscaling, observabilidad, on-call, upgrades trimestrales — requiere aproximadamente un ingeniero de plataforma a tiempo completo más una fracción de SRE. Una flota más diversa — varios motores, varios modelos, scheduling multi-tenant — requiere entre dos y cuatro. A 300k $ totalmente cargados por ingeniero, la factura anual de plataforma es de 300k $ a 1,2M $. El tráfico mensual del punto de equilibrio donde el autohost paga sale entre 200 millones y 1.000 millones de tokens de salida por mes. Por debajo de eso, el overhead de ingeniería supera el ahorro en tokens y el equipo debería quedarse en una API. Por encima, el ahorro domina. La ingeniería de plataforma también viene en funciones escalón, no en curvas suaves: el primer hire pone la flota en marcha, el segundo ocurre porque el primero no puede cubrir el on-call de fin de semana, el tercero cuando la flota crece a multi-región.

15.3 La postura realista es híbrida, y el router es la pieza que sostiene la carga

La decisión más limpia — todo por API o todo dedicado — rara vez es correcta para un equipo con más de un año en producción. Las cargas de estado estable predecibles (batch nocturno, informes programados, colas de clasificación) empaquetan bien sobre capacidad dedicada planificada. Las cargas ráfaga (picos virales, inundaciones de tickets, lanzamientos de nueva cohorte) necesitan elasticidad de API. Las cargas de latencia estricta (autocompletado interactivo, voz) se benefician de un despliegue dedicado colocado. Las cargas sin latencia (enriquecimiento nocturno, re-indexado) se benefician de APIs de batch a mitad de precio. La arquitectura que soporta lo híbrido es un router en la frontera de la aplicación que clasifica cada petición por presupuesto de latencia, complejidad y utilización actual de backend y despacha al backend más barato que cumpla su SLA. Un router más refinado también hace routing dentro-de-la-API por modelo (modelo barato para consultas simples, frontera para complejas, tier de razonamiento para las que lo necesitan). El beneficio de segundo orden es opcionalidad: las cargas pueden migrar entre lados de la frontera cambiando la política del router, no el código de aplicación. Y el caso dedicado a menudo solo compensa porque una segunda carga — una que si no habría ido a la API — se cuela sobre la GPU ya pagada. Un equipo que evalúa lo dedicado sobre una única carga normalmente nunca se mueve; un equipo que piensa en portafolios de cargas sí lo hace, y ahorra.

Lo que prepara el Capítulo 15

El Capítulo 15 nombró una clase de cargas que los agentes han introducido y que no encaja ni en "llamada a API" ni en "serving de modelo": el entorno de ejecución para código generado por LLM, que vive sobre funciones serverless, microVMs (Firecracker, gVisor) o sandboxes WASM según el aislamiento y la flexibilidad de paquetes que el agente necesite. El Capítulo 16 cierra el volumen con el catálogo de jugadas de reducción de coste que aplican a ambos lados de la frontera de postura: routing inteligente de modelo, compactación de contexto a nivel de aplicación, APIs de batch, caché semántica — las jugadas que se acumulan en un tercio o la mitad de la factura del mes pasado.

Próximamente — Capítulo 16: Estrategias de reducción de coste en producción. Las jugadas que se acumulan y convierten la factura del mes pasado en el ahorro del próximo.