Las mejores GPUs en la nube para el servicio y despliegue de LLM

Lo que realmente exige el servicio de un LLM de una GPU alquilada

Servir un modelo de lenguaje grande es una carga de trabajo fundamentalmente diferente a entrenarlo. El entrenamiento está limitado por el rendimiento y es tolerante a la latencia; el servicio es sensible a la latencia, está limitado por la memoria y es intermitente. Cuando alquilas una GPU para desplegar un LLM detrás de una API, el cuello de botella rara vez son los FLOPS en bruto. Es cuánto del modelo y su caché KV puedes mantener en la VRAM, qué tan rápido se transmite esa memoria y cuántas solicitudes concurrentes puedes agrupar antes de que los tokens por segundo por usuario colapsen.

La caché KV es la parte que la mayoría subestima. Cada solicitud activa almacena las claves y valores de atención para su contexto, y esa huella crece con la longitud de la secuencia y el número de usuarios concurrentes. Un modelo que cabe cómodamente en reposo puede quedarse sin memoria en el momento en que se empuja tráfico real con prompts largos. Por eso, los despliegues de servicio a menudo necesitan más margen de VRAM que lo que sugieren solo los pesos del modelo.

Cómo dimensionar la GPU según el modelo

La primera pregunta práctica es si el modelo cabe en una sola GPU o tiene que dividirse entre varias. Al leer la comparación anterior con respecto a tu modelo, considera estos factores:

• La capacidad de VRAM determina qué modelos caben. Un modelo cuantizado de 7B–13B en FP8 o INT8 puede servirse desde un acelerador de gama media, mientras que un modelo de 70B en BF16 generalmente necesita una tarjeta de alta memoria o un nodo con múltiples GPUs. Los modelos muy grandes de clase frontera requieren efectivamente múltiples GPUs de gama alta conectadas entre sí.
• El ancho de banda de memoria establece la velocidad de generación de tokens. La decodificación autorregresiva lee el conjunto completo de pesos para cada token producido, por lo que la memoria clase HBM (como la que se encuentra en tarjetas de centros de datos) genera tokens mucho más rápido que las tarjetas de consumidor basadas en GDDR con el mismo tamaño de modelo. Para chat interactivo, el ancho de banda suele importar más que el cómputo.
• Las precisiones soportadas determinan qué tan agresivamente puedes reducir el tamaño del modelo. Las tarjetas con soporte para tensores FP8 e INT8 te permiten servir modelos más grandes con menos VRAM y a mayor rendimiento, siempre que tu pila de servicio y el esquema de cuantización del modelo sean compatibles.
• El interconector importa una vez que un modelo abarca múltiples GPUs. El servicio paralelo tensorial intercambia activaciones entre GPUs en cada capa, por lo que los enlaces clase NVLink dentro de un nodo ofrecen una latencia materialmente mejor que las configuraciones solo PCIe. Para despliegues con una sola GPU, el interconector es irrelevante.

Servicio con una sola GPU versus múltiples GPUs

Si tu modelo y su pico de caché KV caben en una GPU, mantenlo ahí. El servicio con una sola GPU evita por completo la sobrecarga de comunicación entre dispositivos y es más sencillo de operar. Solo pasa a paralelismo tensorial o servicio multinodo cuando el modelo realmente no cabe, porque cada GPU que añades introduce costo de sincronización y complica el escalado automático. Cuando necesites múltiples GPUs, prefiere instancias en la lista anterior que combinen tarjetas de alta memoria con un interconector rápido dentro del nodo en lugar de unir tarjetas poco acopladas.

Características del proveedor que importan para el servicio, no para el entrenamiento

Más allá del silicio, el modelo operativo del proveedor decide si un despliegue es viable. Al revisar la comparación anterior para una carga de trabajo de servicio en lugar de un entrenamiento, prioriza diferente:

• El tiempo de arranque en frío y configuración se convierten en preocupaciones de primera clase. Un endpoint de servicio que escala a cero entre picos de tráfico paga el costo de arranque en frío en cada escala hacia arriba, por lo que el aprovisionamiento rápido y el almacenamiento en caché de imágenes afectan directamente la latencia final.
• La granularidad de facturación cambia la economía del tráfico intermitente. La facturación por segundo o por minuto es adecuada para endpoints con escalado automático que inician y detienen instancias; la facturación gruesa por hora castiga ese patrón.
• La confiabilidad bajo demanda sobre spot suele ser la opción correcta. Las instancias interrumpibles o spot son excelentes para entrenamiento y trabajos por lotes, pero riesgosas para un endpoint orientado al usuario, donde una recuperación a mitad de solicitud interrumpe el tráfico en vivo. Spot aún puede servir bien para inferencia por lotes no interactiva.
• Almacenamiento persistente y carga rápida del modelo reducen el dolor de reinicio. Pesos de varios gigabytes que se recargan desde almacenamiento en frío en cada reinicio añaden minutos de inactividad; volúmenes en caché o adjuntos acortan eso.
• Red y egreso afectan el costo a escala. La inferencia de alto rendimiento puede mover muchos datos hacia afuera; verifica los términos de egreso antes de comprometerte con un despliegue de alto tráfico.

Lote versus tiempo real, y dónde cae el costo

Decide temprano para qué modo estás optimizando. El servicio interactivo en tiempo real valora un tiempo bajo hasta el primer token y tasas constantes de tokens por usuario, lo que favorece memoria de alto ancho de banda y tamaños de lote modestos. La inferencia por lotes o fuera de línea valora el rendimiento total y puede agrupar grandes lotes en hardware más barato o interrumpible, intercambiando latencia por solicitud por un costo mucho mejor por token. Muchos equipos usan ambos: un nivel receptivo bajo demanda para usuarios en vivo y un nivel por lotes respaldado por spot para generación masiva.

En cuanto al costo de alquiler, el servicio abarca todo el espectro. Un modelo pequeño cuantizado en una tarjeta de gama media es económico y ampliamente disponible; los modelos frontera en nodos multi-GPU de alta memoria son escasos, más caros y a veces limitados en capacidad durante picos de demanda. Debido a que las tarifas cambian constantemente y varían según la región y el compromiso, toma la comparación en vivo anterior como la fuente de verdad en lugar de cualquier cifra fija, y compara instancias según VRAM, clase de ancho de banda, interconector y modelo de facturación juntos en lugar de solo el precio principal.

Preguntas frecuentes

¿Cuánta VRAM necesito para servir un LLM?

Presupuesta para los pesos del modelo en la precisión elegida más un margen sustancial para la caché KV, que crece con la longitud del contexto y los usuarios concurrentes. Como guía aproximada, los modelos pequeños y medianos cuantizados se sirven desde una sola tarjeta de gama media, mientras que los modelos grandes en mayor precisión necesitan una tarjeta de alta memoria o varias GPUs. Siempre dimensiona para la concurrencia máxima, no para el reposo.

¿Son adecuadas las GPUs spot o interrumpibles para servir LLMs?

Para endpoints en tiempo real orientados al usuario, generalmente no, porque una recuperación puede interrumpir solicitudes en vivo y forzar reinicios en frío. Las instancias spot son adecuadas para inferencia fuera de línea o por lotes, donde las interrupciones solo retrasan el rendimiento en lugar de romper una sesión interactiva. Muchos equipos mantienen capacidad bajo demanda para tráfico en vivo y usan spot para trabajos masivos.

¿Por qué el ancho de banda de memoria importa más que el cómputo para el servicio?

La decodificación token por token lee los pesos del modelo desde la memoria para cada token que genera, por lo que la velocidad de generación está limitada por qué tan rápido la GPU transmite la memoria y no por sus FLOPS máximos. Por eso las tarjetas equipadas con HBM de centros de datos producen tokens más rápido que las tarjetas de consumidor que alojan el mismo modelo, y por qué el ancho de banda es una columna clave para comparar arriba.

¿Debo servir en una sola GPU o dividirlo entre varias?

Usa una sola GPU siempre que el modelo y su pico de caché KV quepan, ya que eso evita la comunicación entre dispositivos y simplifica el escalado. Pasa a paralelismo tensorial multi-GPU solo cuando el modelo realmente no quepa, y cuando lo hagas, elige instancias que combinen tarjetas de alta memoria con un interconector rápido dentro del nodo.