¿Cómo afecta el procesamiento por lotes continuo a la equidad en un servidor de IA doméstico?
El batching continuo mejora la utilización al reponer los lotes activos, pero la equidad depende de cómo reciben los usuarios admisión, servicio de tokens y memoria a lo largo del tiempo.
Un servidor de IA doméstico puede combinar varias conversaciones sin esperar a que todas las secuencias terminen juntas. Las solicitudes completadas salen, entran solicitudes nuevas y los usuarios activos comparten iteraciones de inferencia repetidas. Esto aumenta el rendimiento, pero las solicitudes no son iguales: un usuario puede enviar un comando corto, otro un documento extenso y otro un agente que genere cientos de tokens. Un planificador equitativo debe decidir qué unidad de trabajo cuenta, cómo entran las solicitudes nuevas y cómo interactúan las prioridades con longitudes de salida impredecibles.
El batching continuo cambia la unidad de planificación: de un lote fijo a iteraciones
El batching estático mantiene unido un grupo hasta que este termina, desperdiciando capacidad cuando las solicitudes cortas finalizan antes. El batching continuo puede reponer los espacios disponibles entre iteraciones de generación.
Orca introdujo la planificación a nivel de iteración, de modo que las solicitudes puedan entrar y salir a medida que cambia el estado de su secuencia.
Esto mejora la utilización, pero también significa que los usuarios compiten repetidamente por un lugar en la siguiente iteración, en lugar de recibir un único espacio de solicitud indivisible.
El orden de admisión determina quién empieza a acumular servicio
Una solicitud que está fuera del lote activo no recibe progreso del modelo. El planificador puede admitirla según el orden de llegada, la longitud estimada, la prioridad, los bloques KV disponibles o un contador de equidad.
vLLM combina la admisión continua con la gestión paginada de la caché KV, de modo que la memoria pueda asignarse a medida que crecen las secuencias.
El orden de llegada es sencillo, pero una cola de solicitudes largas puede retrasar los comandos domésticos cortos posteriores, incluso cuando estos terminarían rápidamente.
Contar las solicitudes por igual puede proporcionar un servicio desigual del acelerador
Una respuesta de cinco tokens y otra de quinientos tokens son una sola solicitud cada una, pero ocupan cantidades muy diferentes de iteraciones de decodificación. Las longitudes de los prompts también generan cantidades distintas de trabajo de prellenado.
Virtual Token Counter define la equidad basada en tokens, porque el número de solicitudes por sí solo no representa el servicio consumido por cargas de trabajo de LLM heterogéneas.
Una política doméstica debería decidir si la equidad significa igual trabajo en tokens, igual tiempo de espera, igual oportunidad de finalización o prioridad para las tareas sensibles a la latencia.
Ninguna métrica única satisface todas las cargas de trabajo. Un comando de voz y un resumen en segundo plano no necesariamente deberían recibir el mismo trato.
La longitud de salida desconocida dificulta predecir el servicio futuro
El planificador conoce el tamaño del prompt al admitir la solicitud, pero normalmente no sabe exactamente cuántos tokens de salida generará el modelo. Una solicitud puede permanecer activa mucho más tiempo de lo esperado.
La investigación sobre equidad destaca las longitudes de solicitud impredecibles como un desafío distintivo para servir LLM.
Cobrar el servicio a medida que se procesan realmente los tokens evita depender por completo de una estimación deficiente de la longitud, pero aun así puede permitir que una solicitud larga ocupe memoria durante muchas iteraciones.
Los prellenados grandes pueden interrumpir a los usuarios que ya reciben tokens
Un nuevo prompt de documento puede entrar mientras varios usuarios están decodificando. Su prellenado, que requiere mucho cómputo, puede alargar la iteración que las conversaciones activas deben esperar.
Sarathi-Serve utiliza la planificación sin bloqueos para dividir los prellenados grandes y reducir su efecto sobre la latencia de decodificación en curso.
Un planificador que solo cuenta los tokens de decodificación aún puede ser injusto si un usuario introduce repetidamente prellenados grandes que retrasan la salida transmitida de todos.
Por lo tanto, la contabilidad equitativa debería incluir tanto el procesamiento de entrada como los tokens generados.
La presión de memoria puede crear problemas de equidad antes de que se sature el cómputo
Cada conversación activa necesita caché KV y los contextos más largos consumen más bloques. Un usuario con un contexto grande puede reducir el número de solicitudes adicionales que caben en el lote activo.
El análisis multiusuario de ZimaSpace relaciona la concurrencia doméstica con la memoria compartida del modelo y las decisiones del planificador.
Interrumpir o intercambiar una solicitud puede recuperar capacidad, pero el usuario interrumpido podría pagar después el coste de recalcular, recargar la caché o esperar más para completar la solicitud.
Por lo tanto, la admisión basada en memoria y la planificación del cómputo deben seguir la misma política de equidad, en lugar de funcionar como límites independientes.
Las prioridades necesitan envejecimiento, cuotas y métricas visibles para el usuario
El control por voz, las herramientas de accesibilidad y el chat interactivo corto pueden merecer mayor prioridad que los embeddings o los resúmenes nocturnos. Sin embargo, una planificación basada exclusivamente en prioridades puede dejar sin servicio las tareas de baja prioridad.
Llumnix utiliza la planificación dinámica para adaptar la ubicación de las solicitudes y las decisiones sobre recursos a medida que cambian las condiciones de servicio.
Añade envejecimiento, cuotas por usuario, límites máximos de contexto o salida y una cuota reservada para tareas en segundo plano, de modo que el trabajo preferente responda rápidamente sin bloquear indefinidamente todo lo demás.
Mide el tiempo en cola, el tiempo hasta el primer token, el intervalo entre tokens, el tiempo de finalización, los tokens servidos y las interrupciones por usuario o clase de carga de trabajo. El batching continuo solo es equitativo cuando la distribución observada coincide con la política doméstica, no simplemente cuando la cantidad total de tokens por segundo es alta.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué hace que un planificador de agentes de IA repita pasos que ya completó?
Rastrea los pasos repetidos del planificador mediante la persistencia del estado, la evidencia de finalización, el análisis de los resultados de las herramientas, la...
¿Qué causa errores de permisos solo dentro de los subprocesos de agentes de IA?
Compare la identidad del proceso principal y del proceso secundario, la vista del sistema de archivos, el entorno, las capacidades, la política de seguridad...
¿Qué causa la saturación de la CPU cuando se ejecutan simultáneamente la transcodificación por hardware y la IA de vídeo?
Rastrea la saturación de la CPU en la descarga de códecs, la conversión de píxeles, las copias de fotogramas, el preprocesamiento de IA, el...
