Cómo ProsGrow reduce un 54% la latencia de inferencia de vídeo de MiniMax-H3

Cada trabajo necesita una clase de servicio distinta

Una vista previa creativa necesita poca espera. La transferencia de movimiento debe conservar la interpretación original durante una salida más larga. Una solicitud audiovisual de alta resolución puede ocupar varias GPU a la vez. Optimizar estos servicios exige decisiones sobre precisión, atención, residencia en memoria, paralelismo, compilación y calidad.

ProsGrow evaluó estas clases de servicio en un nodo con ocho GPU RTX PRO 6000 Blackwell. La comparación de MiniMax-H3 redujo la inferencia en servidor de 19.392 a 8.913 segundos para la misma solicitud BF16 Turbo en las mismas ocho GPU: un 54.0% menos de latencia. Los estudios independientes de Wan y Animate muestran cómo los plazos, la demanda agregada y la calidad cambian la configuración más útil.

Definimos un contrato de carga, analizamos sus cuellos de botella, comparamos puntos de operación candidatos y validamos el resultado elegido. Los estudios vinculan cada mejora medida con sus restricciones de recursos y calidad.

MiniMax-H3: latencia, memoria y calidad

MiniMax-H3 puso de manifiesto el coste de distribuir una gran carga audiovisual entre las GPU de un nodo PCIe. Cambiar la división del trabajo paralelo redujo la inferencia en servidor de 19.392 a 8.913 segundos en las mismas ocho GPU: un 54.0% menos de latencia para la misma solicitud BF16 Turbo.

El paralelismo de tensores y el de secuencias generan distintas necesidades de comunicación y memoria. Las mediciones controladas respaldaron reducir la sobrecarga de comunicación para esta carga, aunque no hubo una traza de kernels utilizable que estableciera la causa a ese nivel. El perfil de latencia elegido consumió unos 84.2 GB por GPU; las configuraciones con más margen de memoria tuvieron mayor latencia.

La pila SGLang MiniMax-H3 del proyecto original aporta los componentes de servicio del modelo y paralelismo. ProsGrow evaluó su comportamiento en este hardware y seleccionó según el objetivo del servicio.

Un experimento de aproximación independiente reutilizó cálculos intermedios y redujo la inferencia en servidor de 8.913 a 7.092 segundos, un 20.44% adicional. La finalización API pasó de 10.045 a 8.040 segundos, todavía con las ocho GPU asignadas a una sola solicitud. El tiempo de decodificación permaneció prácticamente igual.

Esa mejora adicional tiene otra condición de aceptación: el cálculo aproximado exige un control de calidad. El candidato elegido superó una comprobación limitada de coherencia numérica en una escena. Esto respalda un punto de operación candidato, no una equivalencia perceptual general ni la aprobación para cualquier carga de cliente.

Wan2.2: comparación controlada de cuatro pasos

La ruta elegida combina menor precisión, atención dispersa y residencia en GPU. Estas capacidades proceden del modelo LightWan2.2 y el runtime LightX2V originales, incluida la destilación de pasos consciente de la cuantización. ProsGrow integró y validó la ruta, estableció controles locales y midió sus contrapartidas de servicio.

Una ejecución BF16 estándar de 40 pasos tardó 357.640 segundos. Gran parte de la diferencia frente a esa referencia se debe a la destilación de pasos del proyecto original. El control BF16 de cuatro pasos mide una mejora combinada adicional de ejecución de 2.45×, independiente de la ventaja de la destilación.

Precisión, atención y residencia interactúan

La oportunidad abarcaba varias capas de la ejecución:

• Precisión y atención: una representación numérica más pequeña y la atención dispersa redujeron el trabajo de eliminación de ruido. Su ventaja combinada depende del modelo y de la ruta de ejecución admitida; cambiar solo el formato no garantiza una inferencia más rápida.
• Residencia en GPU: los pesos de expertos más pequeños podían permanecer en memoria GPU, eliminando transferencias del host al dispositivo en la ruta crítica. El ahorro de memoria cambió tanto dónde se ejecutaba el cálculo como cuánta aritmética requería.
• Equilibrio de la canalización: la decodificación se mantuvo cerca de 2.36 segundos. Al acelerar la eliminación de ruido, esta etapa casi sin cambios pasó a ocupar una mayor parte de la solicitud, limitando el beneficio de nuevas mejoras del eliminador de ruido.
• Servicio en caliente frente a frío: el proceso aislado optimizado tardó 72.12 segundos incluyendo carga del modelo, calentamiento y cierre. Por tanto, una inferencia en caliente breve depende de un servicio que gestione el arranque y la residencia.

El resultado controlado mide estos cambios en conjunto. No atribuye una aceleración causal independiente a cada capa. Por eso la optimización necesita tiempos por etapa y un límite de entrega de extremo a extremo.

Una ronda sincronizada del nodo mostró latencia en caliente similar entre GPU. Su finalización más lenta se proyecta a unos 3,138 clips/hora para este contrato de vista previa. Es una conversión de capacidad de una ronda medida, no una prueba API sostenida de una hora. La calidad también limita el resultado: las composiciones difirieron y no se estableció equivalencia perceptual.

Animate-2: rendimiento para un servicio asíncrono

Animate-2 produce un vídeo de transferencia de movimiento de 11.21 segundos a partir de una imagen de referencia y un vídeo original. Sus trabajos más largos encajan en una cola asíncrona, donde las salidas completadas y la energía por trabajo importan más que el plazo de una vista previa interactiva.

ProsGrow combinó una ruta FP8 validada con una caché de compilación persistente. Reutilizar código compilado redujo el trabajo repetido de arranque, mientras que la precisión cambió el coste de ejecución estable. Ambos se midieron dentro del límite completo de lanzamiento utilizado por este servicio.

La potencia casi constante del servidor y el mayor rendimiento redujeron la energía por salida alrededor de un 15.1%. La configuración elegida dejó solo unos 4 GiB de margen de memoria GPU, por lo que la geometría de salida y el trabajo concurrente son restricciones importantes del despliegue.

La caché de compilación también es un artefacto operativo: debe versionarse o reconstruirse si cambian hardware, runtime, forma del modelo o ajustes de compilación. El resultado útil incluye esa decisión de ciclo de vida junto con el rendimiento y la comprobación de regresión visual.

Elija el punto de operación para el cliente

Usar todo el nodo puede acortar una solicitud. Dividir la capacidad en réplicas menores puede completar más trabajos independientes en conjunto. Otro estudio de MiniMax con poda del modelo y el adaptador Turbo del proyecto original produjo una tasa de 478.14 clips/hora a partir de una ronda sincronizada, con solicitudes de unos 30.1 segundos cada una. El cambio de modelo y de estructura de servicio exige una evaluación de calidad propia.

No hay un único ajuste ganador para todos estos objetivos. Lo útil es un conjunto de opciones medidas entre latencia, rendimiento, memoria, energía y calidad. Estos estudios aportan evidencia para elegir una clase de servicio; después, un piloto del cliente debe validar las salidas aceptadas, las colas y los plazos con medios representativos.

Metodología y limitaciones

• Hardware y repetición: un nodo con ocho GPU RTX PRO 6000 Blackwell, 96 GB nominales por GPU. Wan registra una generación medida en caliente por trabajador. La tasa elegida de Animate es la menor de dos ejecuciones del nodo. Cada candidato de latencia H3 tiene un calentamiento y una solicitud medida; las tasas de réplicas proceden de una ronda simultánea. Estos estudios breves no establecen SLA de carga sostenida ni percentiles de latencia.
• Calidad de Wan: la revisión de hojas de contacto encontró clips coherentes, pero la referencia estándar de 40 pasos siguió más fielmente el prompt literal en la única escena probada. La destilación, la dispersión y los cambios de precisión no establecen equivalencia perceptual.
• Calidad de Animate: se compararon los 269 fotogramas con BF16, obteniendo SSIM 0.9534 y PSNR 31.74 dB. Son comprobaciones de regresión visual sobre una sola entrada.
• Calidad de H3: la aproximación elegida obtuvo SSIM 0.8128 frente a la referencia, apenas por encima del mínimo 0.8102 observado en configuraciones locales de paralelismo. Esa comprobación numérica no sustituye una revisión con múltiples prompts de movimiento, fidelidad al prompt, sincronía audiovisual o preferencia humana. El estudio independiente de rendimiento del modelo podado obtuvo SSIM 0.8815 frente a su modelo original.
• Atribución y tiempos: los modelos y runtimes originales aportan los componentes de optimización. Los cambios combinados no aíslan el efecto de cada componente. La inferencia H3 en servidor excluye sondeo y descarga del cliente; sus 8.913 segundos de servidor y 10.045 segundos de API deben mantenerse separados en las comparaciones.

Las mediciones de Wan se recogieron del 12 al 18 de agosto y los seguimientos de MiniMax del 1 al 2 de septiembre de 2026. Los resultados se aplican a los medios y contratos de salida indicados.

Generación privada de vídeo con MiniMax-H3 y Wan

Para la generación privada de vídeo con MiniMax-H3 o Wan2.2, la primera decisión de despliegue es si el servicio prioriza una vista previa rápida o los trabajos completados a lo largo del tiempo. La latencia de inferencia del servidor, la finalización completa de la API y el rendimiento de generación describen límites distintos. La evaluación del cliente debe asociar cada resultado con la geometría de salida, el material de origen y los cambios visuales aceptables.