¿Cómo se planifican la capacidad de GPU y el autoescalado para LLMs?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Dimensiona el conjunto de réplicas a partir del rendimiento medido a la latencia requerida y comprueba después que cada réplica puede alojar las secuencias activas previstas. Usa distribuciones reales de longitud de los prompts y las salidas. Redondea al alza a réplicas completas de serving, incluidas todas las GPUs necesarias para el paralelismo de tensores o de pipeline.
Comprueba la memoria antes que el rendimiento
Con una disposición convencional de caché de atención completa, Llama 3.1 70B necesita 1.25 GiB de datos KV en FP16 para una secuencia de 4,096 tokens. Por tanto, un presupuesto hipotético de 40 GiB para KV permite alojar como máximo 32 secuencias de ese tipo, sin contar la sobrecarga del asignador y del runtime. Con 131,072 tokens, una sola secuencia utiliza los 40 GiB completos.
Cuenta juntos los tokens de entrada y los generados. La fórmula cambia para arquitecturas como MLA y la atención de ventana deslizante, y la asignación por dispositivo depende de la partición. Esto es un límite de memoria, no una predicción del tamaño de lote que cumple los objetivos de latencia. El cálculo de KV cache de la guía muestra los supuestos y un cálculo ejecutable.
Calcula réplicas completas
Supongamos que se ha medido que una réplica de dos GPUs mantiene 1,200 tokens de salida por segundo con la TTFT y el TPOT requeridos para una carga de trabajo fija. La demanda máxima prevista es de 4,000 tokens de salida por segundo. Un factor de seguridad hipotético de 1.3 da:
Cinco réplicas de dos GPUs requieren diez GPUs. Estas cifras ilustran el cálculo; no son resultados de benchmarks de hardware. Repite las mediciones cuando cambien el modelo, la distribución de contextos, la topología o el SLO. Un factor de 1.3 significa un rendimiento un 30% superior a la demanda antes de redondear, no un 30% de capacidad sin utilizar.
Escala antes de incumplir los plazos
Combina la longitud de la cola y el tiempo de espera con el uso de KV, los desalojos de secuencias y el goodput que cumple el SLO. La utilización de GPU puede seguir siendo alta cuando el servicio ya está sobrecargado. vLLM documenta estas métricas de serving; deriva los umbrales de las pruebas de carga.
Mide la descarga de imágenes, la carga de pesos, la inicialización del modelo y el calentamiento antes de elegir los umbrales de autoescalado. Los controles de escalado de despliegues de KEDA permiten reducir las cargas de trabajo hasta cero, pero no eliminan la latencia de arranque del modelo. Mantén capacidad lista cuando las solicitudes no puedan esperar al arranque.
Consulta la planificación de capacidad y el autoescalado en la guía para conocer las decisiones relacionadas con el hardware y la admisión de solicitudes.