Cómo ProsGrow alcanzó las 45,978 preguntas sobre documentos por hora

El problema: igual número de preguntas puede implicar distinto trabajo

Un servicio documental privado debe resolver las tareas pendientes con precisión y a tiempo. Repartir el mismo número de preguntas entre todas las GPU parece razonable, hasta que un trabajador recibe más páginas de alta resolución o instrucciones multimodales más largas. Entonces, el trabajador más lento determina cuándo termina el lote.

ProsGrow identificó este desequilibrio oculto y evaluó una asignación guiada por perfiles de rendimiento en el mismo nodo. El rendimiento pasó de 44,608 a 45,978 preguntas sobre documentos por hora: un aumento del 3.07%. El resultado muestra cómo la inferencia multimodal puede dejar capacidad sin utilizar aunque los recuentos de solicitudes parezcan equilibrados.

Referencia → Optimización de ProsGrow

Ambas ejecuciones usaron Qwen3.6-27B BF16 en vLLM 0.25.1 sobre las mismas ocho GPU. Cada solicitud proporcionó una imagen de página y una pregunta para obtener una respuesta breve. La carga completa de validación contenía 5,349 preguntas sobre 1,285 imágenes de páginas.

La referencia equilibraba el número de preguntas. ProsGrow utilizó perfiles de carga para reducir las diferencias de trabajo asignado a cada réplica, manteniendo las consultas repetidas de una página en la misma réplica.

Todas las preguntas finalizaron correctamente, con un 91.92% de coincidencia exacta. Con las 4.16265 preguntas por página medidas, el rendimiento equivale a 11,045 imágenes de páginas/hora. Esta conversión depende de la densidad de preguntas.

Lo que reveló el análisis de rendimiento

El mismo número de preguntas ocultaba una diferencia del 7.59% entre las cargas de entrada más pesada y más ligera. Los perfiles hicieron visible ese desequilibrio; la asignación elegida lo redujo a menos del 0.017%. El rendimiento final en una ventana común alcanzó el 98.61% de ocho veces la tasa de una GPU aislada.

Equilibrar el trabajo también debía preservar la reutilización cuando varias preguntas se referían a la misma página. Ambas asignaciones conservaron esa localidad, y la ejecución optimizada registró un 76.06% de aciertos en la caché del procesador multimodal, incluidos los calentamientos. La mejora medida vino de distribuir el trabajo de forma más uniforme sobre esta base de inferencia.

El volumen de entrada no explica todos los retrasos: la forma de la página, los lotes y las solicitudes más lentas siguen afectando a la finalización. La señal útil fue la diferencia entre solicitudes aparentemente equilibradas y el trabajo que generaban, no una regla universal de planificación.

Las contrapartidas: margen de memoria y precisión

Las imágenes de páginas grandes convirtieron el margen de memoria en una cuestión de corrección además de una limitación de rendimiento. El perfil de inferencia seleccionado admitió todo el conjunto de validación y equilibró el aprovechamiento del prellenado con la latencia y el margen necesario para las páginas más grandes.

También probamos un checkpoint más pequeño de NVFP4 mixto con el mismo contrato documental. Ocupaba 20.43 GiB en disco frente a los 51.75 GiB de BF16, pero ofreció 44,970 preguntas/hora, un 2.19% menos que BF16. El ANLS medio bajó de 0.96531 a 0.96314 y la coincidencia exacta del 91.92% al 91.14%. Mantuvimos BF16 para esta configuración de inferencia documental ya calentada.

El preprocesamiento de imágenes, el codificador visual y el prellenado multimodal largo siguieron teniendo un coste importante en la ruta cuantizada. Los pesos más pequeños no mejoraron el margen de memoria máxima con la política de ejecución probada. NVFP4 redujo la energía de todo el servidor por pregunta un 2.33%, pero esa ventaja no compensó la pérdida de rendimiento y calidad para esta carga.

Qué significa para un servicio documental privado

El cambio de planificación añade aproximadamente 1,369 preguntas completadas por nodo-hora a la tasa medida. Para una cola con consultas repetidas sobre páginas, supone más trabajo útil con las mismas ocho GPU. Adoptarlo en producción requeriría un análisis representativo o un estimador de costes validado para las páginas entrantes; este benchmark usó costes aprendidos del mismo corpus fijo.

La latencia mediana de las solicitudes optimizadas fue de 4.521 segundos y el p95 de 9.411 segundos. Las preguntas de texto libre obtuvieron 0.93498 ANLS, por debajo de la media global. Un piloto necesita objetivos de calidad para las páginas del cliente y una política de revisión acorde con el coste de una respuesta incorrecta.

De las preguntas medidas al coste modelado

El modelo de costes divide el coste horario de infraestructura entre la porción vendida de la capacidad medida de 11,045 páginas equivalentes/hora. Es independiente de la comparación local de rendimiento del 3.07%.

El modelo supone amortización a tres años, mantenimiento anual del 5%, 720 horas/mes, electricidad a $0.10/kWh, un multiplicador de consumo de 1.30 para refrigeración e instalaciones, 7.476590 kW de potencia activa y 1.016 kW en reposo. Con un 10% de demanda pagada, el volumen vendido es el 10% de la capacidad del benchmark y el nodo sigue incurriendo en amortización, mantenimiento y electricidad en reposo. Se excluyen personal, operación de aplicaciones, redes, almacenamiento y reservas de servicio.

Como referencia de precios, el ejemplo 5 de precios de Queries de AWS Textract indica $15 por 1,000 páginas en EE. UU. Oeste (Oregón), comprobado el 15 de septiembre de 2026. El precio ilustrativo del informe, $10 por 1,000 páginas, está un 33.33% por debajo de esa referencia. Es un escenario de precios: nuestra carga medida contiene unas 4.16 preguntas por página y no se probó equivalencia de calidad de extracción, cobertura de funciones ni servicio entregado.

Metodología y limitaciones

• Modelo y entorno de ejecución: Qwen/Qwen3.6-27B, revisión 6a9e13bd6fc8f0983b9b99948120bc37f49c13e9, BF16; vLLM 0.25.1 con FlashAttention 2. Ocho réplicas independientes en GPU RTX PRO 6000 Blackwell Server Edition de 96 GB nominales cada una. Los ajustes de inferencia se mantuvieron constantes; se desactivaron el razonamiento y la caché de prefijos, y se activó la caché del procesador multimodal.
• Datos y evaluación: partición completa de validación de lmms-lab-encoder/DocVQA en la revisión 539088ef8a8ada01ac8e2e6d4e372586748a265e: 5,349 preguntas y 1,285 imágenes únicas. Las solicitudes pedían respuestas breves con muestreo determinista. Calidad y capacidad proceden de la misma ejecución optimizada sobre toda la partición.
• Definición de métricas: la similitud de Levenshtein normalizada media (ANLS) mide el parecido con respuestas de referencia; la coincidencia exacta normaliza mayúsculas y espacios. Estas métricas de DocVQA no miden directamente errores de negocio a nivel de campo.
• Límites temporales: desde solicitudes API calentadas de preguntas documentales hasta respuestas completas, usando una ventana común sincronizada del nodo. Las tasas horarias se convierten a partir de una ejecución de unos siete minutos. Quedan fuera la ingestión de PDF, los conectores empresariales, la validación de esquemas, la revisión humana, el arranque en frío y la ingeniería de disponibilidad.
• Límites de la comparación: cambiar las formas de lote alteró 35 predicciones normalizadas pese a usar temperatura cero. El pequeño aumento de ANLS es variación numérica observada, no prueba de que la planificación mejore la precisión del modelo. La comparación emparejada de planificación es un benchmark local, no una prueba repetida en producción ni un resultado certificado por el fabricante. La conversión a páginas solo se aplica a esta densidad de preguntas.

Preguntas y respuestas privadas sobre documentos e inferencia multimodal

Para las preguntas y respuestas privadas sobre documentos, este benchmark ayuda a relacionar la capacidad de inferencia multimodal con los documentos pendientes y el plazo de procesamiento. Su unidad es una pregunta respondida, no un PDF incorporado ni un campo de negocio verificado. Un despliegue de cliente debe evaluar imágenes de páginas representativas, calidad de respuestas y proceso de revisión junto al rendimiento del servicio GPU.