La PyTorch Foundation lanzó PyTorch 2.12 el miércoles — 2.926 commits de 457 contribuyentes desde 2.11. El titular de rendimiento es un cambio de backend en una operación de nicho que resulta importar mucho: `linalg.eigh` por lotes en CUDA es hasta 100× más rápido después de la deprecación del backend MAGMA legacy en favor de cuSolver, con las heurísticas de dispatch actualizadas para usar `syevj_batched` incondicionalmente. Workloads que antes corrían en minutos — comunes en computación científica y en cualquier paso de entrenamiento ML que necesita descomposiciones propias de matrices por lotes — ahora corren en segundos, finalmente cerrando una brecha de larga data con CuPy. Aparte, Adagrad se une a Adam, AdamW y SGD con `fused=True`, ejecutando el paso del optimizador en un solo kernel CUDA en lugar de múltiples lanzamientos separados. El lowering `addcdiv` basado en FMA en XPU trae paridad numérica bit-a-bit entre `torch.compile` y el modo eager en GPUs Intel — pequeño en aislamiento pero cargante si has estado persiguiendo comportamientos de optimizador compilado irreproducibles.
La historia estratégica es el pivote cross-backend. PyTorch 2.12 introduce `torch.accelerator.Graph`, una API device-agnóstica para captura y replay de gráficos que unifica la abstracción sobre implementaciones específicas del backend como `torch.xpu.XPUGraph`. Cada backend se registra vía una interfaz ligera `GraphImplInterface`; `c10::Stream` y `torch.Stream` ahora exponen `is_capturing()` como el reemplazo backend-agnóstico del `is_current_stream_capturing` específico del dispositivo. El soporte inicial cubre CUDA y XPU (Intel), con extensibilidad a backends fuera del árbol vía `PrivateUse1`. Esta es la contraparte a nivel de framework de la dinámica del foso CUDA que cubrimos antes esta semana: PyTorch está haciendo explícitamente más fácil para los aceleradores no-CUDA participar en el modelo de programación de captura de gráfico, que es la capa donde vive Inductor y la mayor parte del trabajo de rendimiento. Los usuarios ROCm ganan segmentos de memoria expandibles, colectivos de memoria simétrica rocSHMEM, y pipelining FlexAttention en la misma release — el camino AMD recibió un bump notable.
Dos cambios más para flaggear a builders. Primero, `torch.export.save` y `torch.export.load` ahora serializan correctamente el dtype `float8_e8m0fnu` usado como exponente de bloque compartido en los formatos de cuantización Microscaling (MX) — MXFP4, MXFP6, MXFP8. Hasta ahora, los modelos usando estas técnicas de cuantización agresivas no podían exportarse vía el camino de despliegue PyTorch estándar; los equipos enviando LLMs a entornos restringidos en costo o edge tenían que inventar serialización custom. Esa brecha se cerró. Segundo, el control flow `torch.cond` ahora se puede capturar y replay dentro de CUDA Graphs vía los nodos IF condicionales de CUDA 12.4 — previamente, el branching dependiente de datos forzaba un fallback a CUDA graph trees porque la evaluación de la rama ocurría en CPU. Con 2.12, la evaluación de rama queda en GPU dentro de una sola captura de gráfico (backends eager y cudagraphs; soporte Inductor planeado). Para workloads estilo agente o RL con control flow dependiente de datos, esto saca un acantilado de rendimiento real.
Para builders: esta es una release de baja fricción si ya estás en el track 2.x — la mayoría de las ganancias son transparentes (dispatch eigh, Adagrad fusionado, FMA addcdiv) y no requieren cambios de código. El fix de export Microscaling es el que hay que levantar de inmediato si entregas modelos cuantizados; clona el ejemplo en la documentación y re-prueba tu pipeline de export. La API torch.accelerator.Graph es mayormente relevante si apuntas a Intel XPU o construyes un acelerador custom — la significancia de largo plazo es que PyTorch ahora está abstrayendo explícitamente la captura de gráfico a través de backends, lo cual es la fundación sobre la que cualquier retador serio de CUDA tiene que construir. Los equipos de entrenamiento distribuido deberían mirar las adiciones ncclx + gloo de FlightRecorder y el nuevo `seq_num` NCCL para correlación de colectivos a través de ranks — ambos son mejoras concretas de calidad-de-vida para debugging. Las notas de la release valen leerse end-to-end si mantienes un pipeline de entrenamiento; los items titulares arriba son una muestra, no la lista completa.