¿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é funciones permiten establecer un límite de confianza de IA doméstica alrededor de archivos confidenciales?
Un límite de confianza para la IA doméstica combina cifrado en reposo, permisos de mínimo privilegio, aislamiento del entorno de ejecución y recuperación con...
¿Qué hace que los resultados de búsqueda privados favorezcan los archivos editados con frecuencia?
Los archivos editados con frecuencia obtienen ventajas de posicionamiento cuando cada actualización añade señales de frescura, fragmentos, versiones o interacción sin normalizarlas por fuente.
¿Qué hace que los modelos de presencia del hogar inteligente confundan a los invitados con los residentes?
Los invitados pueden parecer residentes cuando el sistema observa patrones de actividad del hogar, pero carece de una señal de identidad estable de la...
