¿Qué causa los fallos de serving de LLM y cómo se solucionan?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Los fallos de serving de LLM suelen deberse a memoria insuficiente, más trabajo simultáneo del que puede gestionar el servicio o reintentos que repiten solicitudes costosas. Identifica qué recurso o etapa falla antes de cambiar el runtime. Que un modelo se cargue correctamente no demuestra que pueda gestionar el tráfico previsto.
Relaciona el síntoma con las pruebas
| Síntoma | Primeros datos que debes revisar | Cambio que debes probar |
|---|---|---|
| Error por falta de memoria en GPU | Pesos, asignación de KV, activaciones, longitudes de las solicitudes | Lote activo más pequeño, límites más cortos o cuantización compatible |
| La latencia aumenta sin errores | Uso de KV, interrupciones, solicitudes en espera | Menos solicitudes admitidas simultáneamente o más capacidad verificada mediante mediciones |
| Primer token lento | Cola, tokenización, prefill, tiempos de red | Corregir la etapa lenta; probar prefill por bloques si las fases interfieren entre sí |
| La carga aumenta tras los tiempos de espera agotados | Número de reintentos y trabajo que sigue ejecutándose | Reintentos limitados y cancelación del trabajo abandonado |
El almacenamiento de pesos y el de KV son independientes. Un modelo de 70B en FP16 necesita unos 140 GB solo para los valores de los pesos. Con una distribución de caché convencional de atención completa, una secuencia de Llama 3.1 70B con 128K tokens añade 40 GiB de datos KV en FP16, sin contar la sobrecarga del runtime. Ninguna de las dos cifras por sí sola representa el requisito total de memoria.
Comprueba las interrupciones antes de ampliar la cola
Cuando no hay suficiente espacio para KV, un motor de serving puede interrumpir solicitudes. vLLM V1 normalmente vuelve a calcular el trabajo interrumpido, lo que añade latencia aunque la API acabe respondiendo correctamente. Relaciona el número de interrupciones con las longitudes de los prompts, las secuencias activas y el uso de KV.
Reduce el trabajo admitido o modifica la asignación de memoria que estás probando. Aumentar la utilización de memoria de la GPU exige confirmar que las demás asignaciones siguen cabiendo. Trasladar datos KV reutilizables a la CPU o al disco también añade transferencias; no garantiza que una solicitud activa demasiado grande quepa en memoria.
Limita los reintentos
Reintenta los fallos transitorios dentro de un plazo y un presupuesto de reintentos. Usa esperas progresivas con variación aleatoria y asigna los reintentos a una sola capa para que los de la pasarela y los del cliente no se multipliquen. La guía SRE de Google explica cómo los reintentos pueden agravar la sobrecarga.
Propaga la cancelación cuando el solicitante abandone, comprueba que la generación se detiene y prueba este comportamiento bajo carga. Una cola de mayor capacidad retrasa el rechazo, pero no crea capacidad de procesamiento.
Lee la sección modos de fallo de serving de LLM de la guía para conocer los conceptos de memoria y planificación relacionados.