Capítulo 11: Economía de la inferencia en GPU y del despliegue

Visión general#

Una instancia de GPU puede parecer barata si divides su precio por hora entre el rendimiento (throughput) teórico en tokens. Ese cálculo supone que el hardware funciona a pleno rendimiento con trabajo útil todas las horas, algo que el tráfico real rara vez permite.

Un modelo puede caber en la memoria de la GPU y aun así tener problemas con peticiones concurrentes de contexto largo. El tráfico puede llegar en picos, y unos requisitos de latencia estrictos pueden obligarte a mantener capacidad sin usar disponible. Autoalojar también te hace responsable de operar el servicio.

Poner un anuncio de alquiler de GPU al lado de una página de precios de una API te dice poco. Compara opciones que den los mismos resultados con el mismo nivel de servicio.

Práctica#

Describe la carga de trabajo antes de elegir la infraestructura: longitud de entrada, longitud de salida, concurrencia, objetivos de latencia, picos de tráfico y requisitos de disponibilidad. Sigue el tiempo hasta el primer token, la tasa de tokens generados, el tiempo en cola, la latencia de cola y las tareas aceptadas completadas.

En un modelo denso de 32.000 millones de parámetros, el almacenamiento bruto de los pesos ronda los 64 GB con precisión de 16 bits, 32 GB con 8 bits y 16 GB con 4 bits, antes de los metadatos de cuantización, los buffers de ejecución, la KV cache y otras sobrecargas. En un modelo mixture-of-experts, planifica la memoria para el total de los pesos, no solo para los que se activan por token.

Compara tres opciones:

Supón que un despliegue cuesta 6.000 $ al mes y una API de pago por uso cuesta 0,035 $ por tarea aceptada. Si autoalojar añade 0,003 $ de coste variable por tarea, el volumen de equilibrio simplificado es:

Esto solo se cumple mientras el despliegue pueda asumir ese volumen sin añadir capacidad y ambas opciones den una calidad y un servicio equivalentes. Los costes reales de GPU suelen subir a escalones a medida que añades réplicas.

Ledgerline. Ledgerline calculó el precio de una réplica dedicada para la extracción y lo dejó enseguida. Con 40.000 facturas al mes, toda la línea de extracción cuesta 567 $, mientras que una sola réplica en el ejemplo del capítulo cuesta 6.000 $ antes de cualquier tráfico. A unos 0,014 $ por factura, una réplica necesitaría más de 500.000 facturas al mes para amortizarse, muy por encima de las 190.000 que puede servir, así que se queda la API de pago por uso. La hoja de cálculo facilita repetir las cuentas si cambia la combinación.

En profundidad#

Durante el prefill, el modelo procesa la secuencia de entrada. Durante el decode, genera los tokens de salida. La planificación y la presión sobre la memoria son distintas en las dos fases. El batching continuo puede mejorar el rendimiento útil coordinando peticiones de distinta longitud; la gestión paginada de la KV cache reduce la memoria asignada que se desperdicia; el prefix caching puede reutilizar la KV cache de un prefijo compartido entre peticiones y evitar repetir su prefill (consulta Tokens, contexto y caché de prompts).

La cuantización puede reducir el almacenamiento de los pesos y, a veces, mejorar el rendimiento en hardware compatible, pero puede cambiar el comportamiento del modelo y no hace que la generación salga gratis. Una huella de pesos menor solo ayuda si lo que limita el despliegue es la memoria de los pesos.

Con el despliegue de 6.000 $ al mes del ejemplo de la sección Práctica, 100.000 tareas aceptadas asignan 0,06 $ por tarea. Gestionar 160.000 con el mismo hardware asigna 0,0375 $. La factura no cambia, pero cada tarea cuesta menos. Si se fuerza demasiado, una mayor utilización empeora las colas y la latencia P95, así que un servicio fiable puede necesitar algo de capacidad de reserva.

Incluye en el coste total la conmutación por error, la red, la monitorización, las actualizaciones, la seguridad y el tiempo de ingeniería asignado. Si la migración cuesta 24.000 $ y ahorra 2.000 $ al mes en régimen estable, el periodo de recuperación simple es de 12 meses, antes de otros riesgos y cambios.

Comparar opciones de compra de GPU#

La capacidad de GPU en la nube se vende normalmente de tres formas. La capacidad bajo demanda es la más cara por hora y se puede liberar en cualquier momento, aunque puede que el tipo de GPU que quieres no esté disponible cuando lo pidas. La capacidad reservada o comprometida cuesta menos por hora a cambio de un plazo, y la pagas llegue tráfico o no. La capacidad spot o interrumpible es aún más barata, pero el proveedor puede recuperarla con poco aviso.

Ese riesgo de interrupción decide dónde encaja spot. Los trabajos por lotes, la evaluación offline y otro trabajo reintentable pueden absorber un nodo recuperado reanudando desde un checkpoint o volviendo a encolar. El serving crítico en latencia normalmente no puede, salvo que la capacidad bajo demanda o reservada cubra por sí sola el pico.

Pon precio a nodos completos. Una cifra por hora de GPU deja fuera la CPU y la memoria del sistema, el almacenamiento de los pesos del modelo, la red y la transferencia de datos. Después convierte el precio del nodo en coste por tarea aceptada con el rendimiento que hayas medido para tu carga de trabajo. Dos GPU pueden intercambiar su posición en la clasificación cuando se incluyen el rendimiento y el batching. Los precios y las estructuras de descuento cambian a menudo, así que revisa las páginas de precios vigentes de cada proveedor, como la de precios de AWS EC2 enlazada abajo, antes de hacer la comparación.

El punto de equilibrio de capacidad como un rango#

Reúne la forma de la demanda y los supuestos financieros en una sola hoja de cálculo:

Con 180.000 tareas, la alternativa de pago por uso es 180.000 × 0,035 $ = 6.300 $/mes. La dedicada es 6.000 $ + 180.000 × 0,003 $ = 6.540 $/mes: más cara, incluso antes de la migración. Con 190.000 tareas, el pago por uso sale a 6.650 $ y la dedicada a 6.570 $. Pero con 220.000 tareas el despliegue fijo de este ejemplo se queda sin capacidad, así que no puedes extrapolar el ahorro aparente sin añadir otra réplica o cambiar el requisito de servicio.

En conjunto, la capacidad dedicada de este ejemplo solo gana en una franja estrecha, de 187.500 a 190.000 tareas al mes, antes de que haga falta una segunda réplica. Por debajo de la franja, la API de pago por uso es más barata, y por encima la segunda réplica añade otros 6.000 $ de coste fijo.

El tráfico medio mensual no basta por sí solo para fijar la capacidad. Dimensiona para la tasa de llegada pico, la distribución de longitudes de entrada y de salida, el contexto por petición, la concurrencia y la latencia P95. Una oferta de capacidad dedicada o de un plan de tarifa plana debería detallar el rendimiento y el comportamiento de la cola, además de los cupos mensuales de tokens.

Al comparar una migración, separa el ahorro neto recurrente del coste puntual; El manual de optimización cubre el periodo de recuperación. Trata cualquier punto de equilibrio como el límite de un escenario.

Antes de comprometerte con capacidad dedicada, vuelve a ejecutar la hoja de cálculo con tus propios volúmenes, carga pico y objetivos de latencia. La calculadora de abajo parte de las cifras de la tabla; lleva el volumen más allá de la capacidad de una réplica para ver el escalón.

El mismo cálculo, con una tabla de volúmenes, está en la hoja de cálculo descargable.

Referencias: vLLM, In-flight batching y KV cache paginada en TensorRT-LLM, Artículo de PagedAttention, Precios de AWS EC2, Avisos de interrupción de EC2 Spot.