¿Qué es el procesamiento por lotes continuo y cuándo es importante para un servidor de IA doméstico?
El batching continuo programa las secuencias activas en cada iteración de decodificación, lo que permite que nuevas solicitudes se incorporen y que las completadas salgan sin esperar a un lote fijo.
Una familia puede enviar una solicitud de voz, una pregunta sobre un documento y una instrucción de programación a un único modelo local en cuestión de segundos. Sus instrucciones y longitudes de salida difieren, por lo que un lote fijo desperdicia espacios mientras las respuestas más cortas esperan a la más larga. El batching continuo sigue reconstruyendo trabajo útil alrededor del modelo, pero solo importa cuando las solicitudes se superponen y el servidor tiene suficiente memoria y margen de programación.
La programación a nivel de iteración es la idea fundamental
La decodificación autorregresiva hace avanzar cada secuencia activa aproximadamente un token por iteración del modelo. Un programador continuo selecciona las secuencias ejecutables para la siguiente iteración, admite nuevas solicitudes cuando se libera capacidad y elimina las secuencias inmediatamente después de completarse.
El artículo de Orca introdujo la programación a nivel de iteración con la granularidad de las iteraciones del modelo, en lugar de solicitudes completas. El batching selectivo agrupa las operaciones compatibles y mantiene separado el trabajo específico de cada solicitud. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
Esto no es lo mismo que transmitir tokens a un usuario. La transmisión cambia cuándo se entrega la salida; el batching continuo cambia cómo varias solicitudes comparten internamente la ejecución del modelo. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización actúe.
Se diferencia del batching estático y del batching por ventana de llegada
El batching estático mantiene unido a un grupo fijo y a menudo rellena las secuencias más cortas hasta que termina la más larga. El batching por ventana de llegada o dinámico espera brevemente para recopilar solicitudes, pero todavía puede ejecutar el grupo resultante como una sola unidad. El batching continuo revisa la composición en cada iteración.
El artículo de vLLM combina la programación a nivel de iteración con la gestión paginada de la caché KV, de modo que los conjuntos cambiantes de secuencias no requieren reservas contiguas rígidas. La programación y la gestión de memoria son funciones complementarias, no intercambiables. Ese límite debe medirse por separado en condiciones operativas realistas.
Un mayor número de secuencias activas amortiza las lecturas de pesos y puede mejorar el rendimiento, pero cada solicitud compite por la memoria KV y la capacidad de cómputo. Un lote activo más grande no es automáticamente mejor para la latencia o la equidad. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.
La concurrencia, no solo el tamaño del modelo, genera el beneficio
Un único usuario interactivo puede notar poca mejora porque no hay una segunda solicitud disponible para llenar la capacidad sin utilizar. Los beneficios aparecen con usuarios domésticos simultáneos, ramas de agentes, resúmenes en segundo plano o varias aplicaciones que comparten un modelo residente.
Sarathi-Serve analiza cómo la interferencia del prefill puede alterar la latencia de decodificación y utiliza prefills segmentados para hacer más predecible la programación mixta. El resultado muestra que la política de admisión importa tanto como la etiqueta de batching continuo. Esta dependencia debe mantenerse explícita en la interfaz final.
El límite de fallo es la presión sobre la memoria o una admisión agresiva que aumenta el tiempo por token de salida y la latencia de cola. Cuando la caché KV se llena, la expulsión, el intercambio o la recomputación pueden eliminar las mejoras de rendimiento y volver inestable el servicio interactivo.
Determina si la demanda simultánea lo justifica
Reproduce una, dos, cuatro y ocho solicitudes superpuestas con longitudes realistas de instrucciones y salidas. Registra el rendimiento, el tiempo hasta el primer token, el tiempo por token de salida, el tiempo de finalización p95, la utilización de la KV, las expulsiones y la equidad por clase de solicitud.
Compara el comportamiento con las brechas del batching continuo. Repite la prueba con el batching continuo desactivado o con una línea base de lote fijo, manteniendo constantes el modelo, la cuantización, los límites de contexto y el hardware. Por tanto, el resultado debe comprobarse frente a la evidencia original.
Utiliza el batching continuo cuando la superposición produzca mejoras materiales de rendimiento o capacidad sin infringir la latencia de cola interactiva. Si las solicitudes rara vez se superponen, prioriza la residencia del modelo y la latencia de inicio antes de añadir complejidad al programador. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué es la deriva de las incrustaciones y cuándo es necesario reconstruir un índice de búsqueda privado?
Decodifica el desplazamiento del modelo, el preprocesamiento, el corpus y las consultas; distingue entre la monitorización y la incompatibilidad; y decide cuándo es necesario...
¿Qué es la compatibilidad del tokenizador y por qué puede hacer que el cambio de modelo falle?
Descifra la identidad del vocabulario, la semántica de los tokens especiales, las plantillas de chat, los tokens en caché, los adaptadores y las comprobaciones...
¿Qué es la permanencia del modelo y cuándo debe un servicio de IA local mantener las ponderaciones cargadas?
Descubre la permanencia de los pesos, los niveles de caché, los arranques en frío, la expulsión, la multiplexación, la presión de memoria y cuándo...
