Matriz de pruebas comparativas de PyTorch 2.13: qué probar antes de las actualizaciones de FlexAttention, CuTeDSL, torchcomms y FSDP2

PyTorch 2.13 es el tipo de versión que puede hacer que un equipo se sienta atrasado antes de haber ejecutado un solo trabajo. FlexAttention recibe más atención, Apple Silicon MPS es más importante para el desarrollo local, CuTeDSL apunta hacia el trabajo del kernel de nivel inferior, torchcomms y FSDP2 cambian las conversaciones de entrenamiento distribuido y el trabajo de memoria continúa en capas como nn.LinearCrossEntropyLoss.

Esa lista es útil. No es un plan de actualización.

El blog oficial de lanzamiento de PyTorch y las notas de lanzamiento de GitHub son el mapa de lo que cambió. No son prueba de que su carga de trabajo deba cambiar esta semana. Trate cada figura atractiva de actualización o memoria como un objetivo de reproducción local. Si sus propios scripts, hardware, porciones de datos, opciones de precisión y ruta de reversión no respaldan el reclamo, el reclamo es simplemente el resultado de otra persona.

La misma disciplina se aplica a los equipos que ya están pensando en realizar cambios, como en LLM que ofrece planes de migración. Aísle el cambio, mídalo y haga que la reversión sea aburrida. El hábito de la evidencia de documentar bancos de pruebas de IA también pertenece aquí: cada resultado de referencia necesita una fuente, ID de ejecución, entorno, comando y decisión.

La pregunta no es si 2.13 es más rápido

Una actualización del marco rara vez falla porque la característica del título es falsa. Falla porque el equipo prueba un camino y se embarca en otro.

Un punto de referencia de atención CUDA puede parecer bueno, mientras que la exportación falla en un tiempo de ejecución posterior. MPS puede ejecutar la demostración, mientras que un patrón realmente disperso retrocede o se queda sin memoria. Un trabajo distribuido puede mostrar un paso más rápido, mientras que resulta difícil confiar en la recuperación del punto de control. La CPU puede tratarse como una alternativa aburrida, luego CI bloquea la liberación porque cambió una pequeña ruta del operador.

Aquí está la versión contundente: un punto de referencia que no puede provocar una reversión es solo un gráfico.

PyTorch 2.13 debería probarse como un cambio de plataforma. Eso significa la misma carga de trabajo, no una carga de trabajo más bonita, en todos los backends que el equipo realmente utiliza. Las computadoras portátiles Apple Silicon, los servidores CUDA, los trabajadores ROCm, los trabajos de CPU CI y los clústeres distribuidos no fallan de la misma manera. Una matriz de prueba útil lo acepta desde el principio.

La matriz de prueba multiplataforma de PyTorch 2.13

{
  "matrix": "optijara-cross-platform-pytorch-2-13",
  "versions": ["current_baseline", "pytorch_2_13"],
  "backends": ["mps", "cuda", "rocm", "cpu", "distributed"],
  "gates": ["correctness", "latency", "throughput", "peak_memory", "determinism", "compile_export", "rollback"],
  "decisions": ["adopt", "isolate", "defer", "rollback"]
}

Comience con el control

La ejecución de control es donde muchos programas de referencia fallan silenciosamente.

Congele la versión actual de PyTorch, la confirmación del modelo, el segmento del conjunto de datos, la versión del tokenizador o de preprocesamiento, la política de semillas, el modo de precisión, la forma del lote, la longitud de la secuencia y la máscara de atención. Registre el modelo de hardware, el backend del acelerador, las versiones del controlador o del tiempo de ejecución, el iniciador distribuido, la configuración del compilador y las variables de entorno. Si la carga de trabajo tiene modos de entrenamiento e inferencia, establezca ambos como base.

Luego mantenga las partes aburridas idénticas. Los mismos guiones. Mismas entradas. Misma política de calentamiento. Misma ventana de medición. No compare una ejecución de PyTorch 2.13 cuidadosamente ajustada con una línea de base obsoleta que nadie ha tocado en meses.

Separe el calentamiento de compilación de la medición de estado estable. Capture la latencia p50 y p95 donde la latencia importa, tokens o muestras por segundo donde importa el rendimiento, memoria máxima, deriva numérica, tiempo de compilación, interrupciones de gráficos, costo de reinicio y modo de falla. La misma regla de congelación de la carga de trabajo aparece en pruebas de IA multimodal en tiempo real: si la prueba cambia durante la evaluación, el resultado se vuelve difícil de confiar.

FlexAttention en MPS y CUDAFlexAttention merece pruebas construidas a partir de los patrones de atención reales del equipo. Una atención densa no es suficiente si la migración está motivada por un comportamiento escaso o de contexto prolongado. Incluya máscaras causales, patrones de ventanas deslizantes, patrones de bloques dispersos, secuencias largas, precisión mixta y pases hacia atrás. Los documentos oficiales de FlexAttention definen la superficie API. La guía de creación de perfiles de Hugging Face ayuda a los equipos a leer los rastros de atención en lugar de confiar en un número de rendimiento agregado.

En Apple Silicon, las pruebas de MPS deberían ir más allá del éxito de la importación. Ejecute el mismo patrón disperso, máscara, forma de lote y longitud de secuencia planificados para el trabajo real. Compare con la línea base de MPS anterior y, cuando sea posible, con una referencia de CUDA o CPU para verificar que sea correcta. Esté atento a operadores no admitidos, retrocesos silenciosos, picos de memoria y desviaciones de precisión mixta.

En CUDA, agregue comprobaciones retrospectivas deterministas. Repita las carreras sembradas. Compare los gradientes con las tolerancias acordadas. Mantenga la antigua SDPA o la ruta de atención personalizada junto a FlexAttention hasta que la nueva ruta ocupe su lugar. Si el comportamiento determinista es parte del requisito de liberación, la puerta no tiene velocidad promedio. La puerta es una corrección repetible bajo las mismas configuraciones de semilla, precisión y backend.

Puertas de kernel, memoria y compilador

CuTeDSL debería ubicarse en un carril de prototipos a menos que el equipo ya posea un mantenimiento de kernel personalizado. La prueba no es sólo la velocidad. Es propiedad. ¿Quién depura el código? ¿Qué hardware se requiere? ¿Cómo lo comparará el equipo con el comportamiento estándar de PyTorch? ¿Con qué rapidez se puede desactivar cuando cambia un controlador, forma o modo de precisión?

nn.LinearCrossEntropyLoss pertenece a un carril de memoria y corrección. Compare la memoria máxima, el tiempo de paso, el comportamiento de los logits, el comportamiento de precisión mixta, las señales de convergencia y la compatibilidad con la pila de entrenamiento. Una ganancia de memoria es valiosa sólo si la ruta de pérdida todavía entrena el modelo previsto y no crea un nuevo trabajo de integración.

Para torch.compile y exporte, utilice puertas en lugar de optimismo. Cuente los saltos del gráfico. Registro de sobrecarga de compilación. Pruebe formas dinámicas reales, no solo una demostración limpia de formas fijas. Verifique la exportación cuando el modelo abandone Python para otro tiempo de ejecución. La publicación sobre fusión de normalización del 10 de julio es un contexto arquitectónico útil porque la fusión puede cambiar el tráfico de memoria y la estructura del núcleo. Todavía no elimina la necesidad de pruebas específicas de la carga de trabajo. Para obtener una perspectiva de portabilidad más amplia, compare esto con pruebas de portabilidad informática de IA, donde la elección del backend debe probarse bajo limitaciones prácticas.

Pruebas distribuidas y de respaldo

La superposición de torchcomms y FSDP2 necesita pruebas de sistemas distribuidos, no pruebas de casillas de verificación. Para torchcomms, mida el comportamiento colectivo, la latencia, el ancho de banda, el manejo de fallas, la disponibilidad del backend y la compatibilidad con las herramientas de lanzamiento existentes. Confirme que el monitoreo aún explica lo que sucede cuando un trabajo se desacelera.

Para la superposición de FSDP2, mida el tiempo de paso, la espera de comunicación, la memoria máxima, el guardado y la carga del punto de control, el manejo del estado del optimizador y el escalado en recuentos de nodos controlados. No apruebe la superposición de un paso rápido. Un mejor camino es aquel que entrena, controla, recupera y deja suficiente evidencia para que los operadores depuren la siguiente falla.Las comprobaciones de ROCm y CPU mantienen honestas las rutas alternativas. Es posible que un equipo no entrene su modelo más grande en CPU, pero los trabajos de CPU a menudo protegen la CI, el desarrollo local y las pruebas de humo. ROCm puede formar parte de una flota mixta. Un éxito exclusivo de CUDA no debería aprobar una flota que también depende de las computadoras portátiles Apple Silicon, los trabajadores de ROCm o el respaldo de CPU.

Errores y advertencias comunes

El error más común es cambiar la carga de trabajo mientras se cambia el marco y luego darle crédito al marco por el resultado. Mantenga la carga de trabajo fija. Otro error es probar CUDA de camino feliz mientras se ignoran las computadoras portátiles MPS, los trabajadores de ROCm, los trabajos de exportación y la CPU CI. Un tercero está tratando la deriva numérica como una ocurrencia tardía porque el rendimiento mejoró.

Otras trampas son menos glamorosas. Los equipos cuentan el calentamiento compilado como velocidad de estado estable. Informan un rendimiento promedio pero pierden el pico de memoria. Prueban longitudes de secuencia más cortas que las utilizadas en producción. Repiten las afirmaciones de las notas de lanzamiento como si fueran garantías. Se saltan la reversión porque el punto de referencia parecía limpio.

Las advertencias deben escribirse antes de que comience la ejecución. El costo de implementación puede superar una pequeña ganancia de referencia. El hardware, el controlador, la precisión y la forma de la carga de trabajo pueden cambiar la respuesta. Los datos de referencia pueden necesitar controles de privacidad si las indicaciones, etiquetas o muestras son confidenciales. El comportamiento de la caché puede hacer que las ejecuciones repetidas parezcan mejores que la primera ejecución. La calidad de la evaluación determina si la desviación de la precisión es visible. Las API prototipo y las rutas de kernel personalizadas pueden agregar trabajo de mantenimiento que el número de velocidad no muestra.

Aplazar la adopción de PyTorch 2.13 cuando los patrones dispersos críticos no se hayan probado, las comprobaciones retrospectivas deterministas fallen, las rutas de exportación no sean compatibles, la recuperación distribuida sea frágil, se excedan los presupuestos de memoria o la reversión dependa de actos heroicos manuales. El aislamiento no es fracaso. A menudo es la respuesta de los adultos.

Lista de verificación de implementación y plan de medición

Utilice un período de referencia de dos semanas si el cambio afecta a la capacitación en producción, el desarrollo de modelos o el servicio de dependencias. La primera semana debería cubrir la revisión del código fuente, la captura de la línea base, la congelación del entorno y las pruebas de un solo nodo. La segunda semana debería cubrir pruebas distribuidas, compiladores y puertas de exportación, ensayos de reversión y una decisión canaria.

El plan de medición debe registrar la latencia, el rendimiento, la memoria máxima, el tiempo de compilación, las interrupciones del gráfico, la deriva numérica, la repetibilidad determinista, el comportamiento del punto de control y la duración de la reversión de p50 y p95. Almacene ID de ejecución, detalles de hardware, versiones de software, comandos, identificadores de sectores de conjuntos de datos, URL de origen, puertas de aprobación o falla y notas de reproducción.Establezca umbrales antes de ejecutar las pruebas. Un cuaderno de investigación, una capacitación nocturna, un servicio de inferencia de cara al cliente y un trabajo de ajuste distribuido no deberían compartir un mismo umbral. Decida qué justificaría la adopción antes de que existan los gráficos. De lo contrario, el punto de referencia se convierte en una negociación a posteriori.

Si un equipo necesita ayuda para convertir las notas de la versión en pruebas de infraestructura de IA reproducibles, Optijara puede ayudar a diseñar la matriz, automatizar la captura de evidencia y convertir las actualizaciones del marco en planes de adopción medidos. PyTorch 2.13 debería lograr la adopción carga de trabajo por carga de trabajo, backend por backend.