{"slug": "core-pytorch-sessions-at-pytorch-conference-north-america-2026", "title": "Core PyTorch Sessions at PyTorch Conference North America 2026", "summary": "PyTorch Conference North America 2026, scheduled for October 20–21 in San Jose, CA, will feature Core PyTorch sessions covering compiler and runtime internals, distributed communication, device portability, release engineering, CI, observability, accelerator integration, and contributor infrastructure. Sessions include talks on out-of-tree release readiness, a tiered Cross-Repository CI Relay, and the use of AI agents for CI triage and PR review, with registration discounts available before September 4.", "body_md": "### Featured projects\n\n**TL;DR**\n\nPyTorch Conference North America 2026 features Core PyTorch sessions spanning compiler and runtime work, distributed communication, device portability, release engineering, CI, observability, accelerator integration, and contributor infrastructure.\n\n**Core PyTorch at #PyTorchCon NA:**\n\nPyTorch Conference North America 2026 comes to San Jose, CA, October 20–21, with two days of technical talks, workshops, and discussions across the open source AI stack.\n\nOur Core PyTorch program gets into the machinery of the framework: compiler and runtime internals, distributed communication, device abstractions, hardware integration, release engineering, CI, profiling, and compatibility. The sessions below cover the APIs, implementation work, performance results, and engineering approaches shaping how PyTorch is built and extended.\n\n[View the full conference schedule](https://hubs.ly/Q04tDx8f0)\n\n[Register for PyTorch Conference North America 2026 before September 4 to save on your ticket](https://hubs.ly/Q04tDw_W0)\n\n**Release Engineering, Compatibility, and Contributor Infrastructure**\n\n**Relay and Reuse: The Dual Engine Behind PyTorch Out-of-Tree Release Readiness**\n\n**Jiahao Chen, Huawei; Jiahao Tan, Huawei**\n\n**October 20, 11:10–11:35 a.m. | LL21DEF | Breakout Session**\n\nThis session explains how an out-of-tree accelerator backend uses device-agnostic test reuse and cross-repository CI to keep pace with PyTorch releases. The speakers say instantiate_device_type_tests and dynamic skipping make 580K+ community test cases reusable out of the box, while the Cross-Repo CI Relay validates PyTorch PRs against accelerator code before merge.\n\nTogether, the approach supports stable out-of-tree backend releases within 30 days of each upstream update.\n\n**Shipping PyTorch and Its Ecosystem: A Modern Release Story**\n\n**Andrey Talman, Meta**\n\n**October 20, 11:45–11:55 a.m. | LL21DEF | Lightning Talk**\n\nThis talk covers changes to PyTorch release engineering across three areas: a faster and more predictable release process; continuous validation of Triton and vLLM against PyTorch nightlies so breakage surfaces upstream early; and AI agents that triage CI, separate noise from regressions, and draft fixes.\n\nThe session also examines where agents accelerate release work and where humans still make the call.\n\n**Scaling PyTorch’s Compatibility Promise: A Tiered Cross-Repository CI Relay for Out-of-Tree Backends**\n\n**Subin George, Red Hat LLC; Jewel K M, Red Hat**\n\n**October 20, 12:00–12:10 p.m. | LL21DEF | Lightning Talk**\n\nThis talk presents the Cross-Repository CI Relay, or CRCR, which forwards PyTorch PR and push events to downstream repositories in real time for compatibility validation before merge. It covers a four-tier trust model ranging from event dispatch through blocking merge prerequisites, along with the relay, ingestion, visualization, and security architecture.\n\nThe speakers report that deployment with Ascend NPU and RISC-V backends reduces breakage detection from days to minutes.\n\n**Fighting Agents with Agents Bringing Claude to PyTorch CI, triage, and PR review**\n\n**Driss Guessous, Meta**\n\n**October 20, 12:35–12:45 p.m. | LL21DEF | Lightning Talk**\n\nPyTorch maintainers are reviewing an increasing number of PRs written by AI agents. This talk covers how Claude was added to PyTorch infrastructure through @claude on issues and PRs, automatic issue triage, reusable onboarding for pytorch and meta-pytorch repositories, PR review skills, and CI and autorevert investigation.\n\nThe session also covers Bedrock/OIDC setup, two-stage GitHub Actions, tool allowlists, and repository-specific skills, with the stated goal of supporting maintainers rather than replacing them.\n\n**Clearing the Path Towards an ABI Stable PyTorch C++ Extension Ecosystem**\n\n**Sean McGovern, Red Hat; Chris Leonard, Red Hat; Jane Xu, Meta**\n\n**October 21, 2:15–2:40 p.m. | LL21ABC | Breakout Session**\n\nPyTorch’s stable ABI provides a binary-compatible C interface that extensions can target across PyTorch versions without recompilation. This session presents tools for identifying and inventorying unstable API usage and applying source-to-source conversion, with LLM-assisted follow-up for migration work.\n\nThe speakers demonstrate the process on libraries including vLLM and SGLang.\n\n**Compiler, Runtime, Tensor, and Observability Work**\n\n**Beyond Size and Stride: Unleash Performance with Device-Aware Tensor Layouts**\n\n**Olivier Tardieu, IBM; Matthew Arnold, IBM Research**\n\n**October 20, 4:20–4:30 p.m. | LL20AB | Lightning Talk**\n\nPyTorch tensors encode size, stride, and storage offset, but the speakers argue that these fields are insufficient to capture hardware layouts required by modern accelerators. This session introduces a tensor layout extension for device-aware specialization, including tiling and NUMA-aware placement, while preserving standard PyTorch tensor semantics.\n\nThe speakers also demonstrate how torch.compile and Inductor can use these controls to adapt layouts to the target device and adjust computations.\n\n**Observability Tooling for Cudagraph Workloads**\n\n**Natalia Gimelshein, Meta; Driss Guessous, Meta**\n\n**October 20, 4:20–4:30 p.m. | LL21DEF | Lightning Talk**\n\nCudagraph workloads can make profiling, stream visualization, and memory tracking difficult. This talk covers PyTorch utilities for using information captured during graph capture to enrich runtime information collected during replay.\n\nThe goal is more information-rich performance and memory monitoring at low overhead, including nearly zero-overhead always-on monitoring.\n\n**Nested Graph Breaks: Reducing the Cost of Graph Breaks in torch.compile**\n\n**William Wen, Meta**\n\n**October 20, 4:35–4:45 p.m. | LL20AB | Lightning Talk**\n\nA nested graph break previously caused O(N) duplicate graph breaks, O(N) graphs to be traced, and O(N²) frame traces for a function call O(N) layers deep.\n\nThis session presents nested graph break support in Dynamo, reducing those costs to O(1) duplicate graph breaks, O(1) graphs traced, and O(N) frame traces. The speakers report larger captured graphs, fewer graph breaks, reduced Dynamo trace time, and improved debuggability.\n\n**Static Tensor Shape Checking for PyTorch with Pyrefly**\n\n**Steven Troxler, Meta Platforms; Avik Chaudhuri, Meta**\n\n**October 20, 5:30–5:55 p.m. | LL20AB | Breakout Session**\n\nThis session presents static tensor shape checking in the Pyrefly type checker, including inline tensor-shape hints and detection of mismatches before execution.\n\nThe speakers cover symbolic integers, Tensor and Dim types, a shape-transform DSL, evaluation across 28 models spanning LLMs, vision, recommenders, and reinforcement learning, and AI-assisted annotations using a Claude skill.\n\n**TorchInsights: Zero-GPU Memory & Runtime Estimation for Distributed Training and Agentic Research**\n\n**Sanket Jayant Purandare, Meta; Aditya Venkataraman, Meta**\n\n**October 20, 5:45–5:55 p.m. | LL21ABC | Lightning Talk**\n\nTorchInsights estimates memory use and runtime for distributed training without running workloads on GPUs. Using fake tensors and fake execution, it can break down peak memory, sweep training configurations, rank parallelism plans, and simulate multi-stream GPU execution with Perfetto traces.\n\nThe tool uses pluggable cost models and is also presented as a lower-cost evaluation loop for AI-agent auto-research before spending real GPU time.\n\n**Parametrized Dynamic Shape CUDA Graphs**\n\n**Elias Ellison, Meta; Daniel Galvez, NVIDIA**\n\n**October 21, 11:45 a.m.–12:10 p.m. | LL21ABC | Breakout Session**\n\nDynamic workloads can require padding, on-device shapes, repeated recordings, or larger model changes to use CUDA Graphs. This session combines parametrized CUDA Graphs with torch.compile’s symbolic tracing and guard infrastructure to capture and re-parametrize a single CUDA Graph across dynamic shapes.\n\nThe speakers report performance wins and reduced cold-start times for inference serving.\n\n**Native DSL Operators in PyTorch Core**\n\n**Simon Layton, Meta**\n\n**October 21, 2:50–3:15 p.m. | LL21ABC | Breakout Session**\n\nDSL-authored kernels have largely remained outside PyTorch core. This talk presents work toward adding DSL-authored operators as first-class citizens of PyTorch core, tying them into dispatch and testing.\n\nThe work is intended to support new operators, highly optimized implementations, and targeted fixes for specialized performance cliffs.\n\n**From Backed to Unbacked: Sound, Predictable, and Controllable Dynamic Shapes in PyTorch**\n\n**Laith Sakka, Meta**\n\n**October 21, 4:20–4:45 p.m. | LL21ABC | Breakout Session**\n\nBacked dynamic shapes use symbolic sizes together with example-input hints and guards, which can allow recompilation. For workflows including vLLM, export, pre-compilation, and JIT deployments where dynamic-shape recompilation is not acceptable, this talk presents unbacked shapes, which disallow implicit guards on dynamic shapes.\n\nThe session covers data-dependent errors and branching, work to close the performance gap with backed shapes across TorchBench and vLLM, and APIs for shape constraints and dispatch across compiled artifacts.\n\n**Speeding Up torch.compile: A New FakeTensor**\n\n**Angel Li, Meta**\n\n**October 21, 4:55–5:05 p.m. | LL21ABC | Lightning Talk**\n\nFakeTensor is used by Dynamo and Inductor when building FX graphs, and the abstract identifies FakeTensor propagation as a contributor to torch.compile tracing time.\n\nThe speaker reports that one FakeTensor propagation takes around 20% of total Dynamo tracing time and that aten.mm takes around 225 microseconds with a Python FakeTensor, while a C++ FakeTensor shows a 30x speedup for that operation. The talk covers the new C++ FakeTensor’s design, performance benchmarks, and integration with the torch.compile ecosystem.\n\n**Lightweight FX Tracing in PyTorch**\n\n**Richard Zou, Meta; Yidi Wu, Meta Inc.**\n\n**October 21, 5:10–5:20 p.m. | LL21ABC | Lightning Talk**\n\nDynamo traces Python bytecode and can fall back to graph breaks, but the speakers say they have received feedback that Dynamo is too heavy for use cases where users require a full graph.\n\nThis talk presents a lightweight FX tracer based on make_fx for functionally pure PyTorch code. It covers the API, its guarantees, how it differs from Dynamo, and how it interacts with other APIs.\n\n**Distributed Communication and Device Portability**\n\n**PyTorch Generalization: A Journey Toward Write Once, Run Anywhere**\n\n**Yu Guangye, Intel; Eikan Wang, Intel**\n\n**October 20, 12:20–12:30 p.m. | LL21DEF | Lightning Talk**\n\nThis talk covers ongoing work to make PyTorch APIs, runtime interfaces, and testing infrastructure less backend-specific. The speakers focus on model-level API unification across Autocast, Inductor, and graph capture and replay; torch.accelerator for device, stream, event, RNG, and memory management; and test infrastructure spanning Distributed, Dynamo, Inductor, ATen operators, and more.\n\nThe stated goal is a consistent user and developer experience across in-tree and out-of-tree backends.\n\n**Future of Distributed Communication in PyTorch: New APIs for Fault Tolerance, RDMA and Extensibility**\n\n**Tristan Rice, Meta; Kapil Sharma, Meta**\n\n**October 20, 4:20–4:45 p.m. | LL21ABC | Breakout Session**\n\nThis talk presents new APIs for fault tolerance, one-sided RDMA, collective hooks, backend extensibility, and backend interfaces. Examples include torch.distributed.reconfigure() for live process-group reconfiguration after rank failures, Window APIs for one-sided put/get, composable hooks for collectives, and pip-installable backends registered through entry_points.\n\nThe speakers say these features were incubated in TorchComms and are now being upstreamed into torch.distributed.\n\n**rocSHMEM Symmetric Memory in PyTorch for AMD GPUs**\n\n**Prachi Gupta, AMD**\n\n**October 20, 4:35–4:45 p.m. | LL21DEF | Lightning Talk**\n\nPyTorch symmetric memory issues communication from within device kernels. This talk describes extending that capability to AMD GPUs through rocSHMEM, which the abstract says is now available in upstream PyTorch.\n\nThe session covers Triton-callable rocSHMEM primitives, AMD-specific device-bitcode linking and HIP-module initialization behind a backend-agnostic layer shared with NVSHMEM, and a comparison with RCCL host-driven all-to-all on representative Mixture-of-Experts workloads.\n\n**XCCL: Scaling PyTorch Collectives to Exascale on Intel GPUs with TorchComms**\n\n**Panagiotis Kourdis, Intel; Tanima Dey, Intel Corporation**\n\n**October 20, 5:10–5:20 p.m. | LL21ABC | Lightning Talk**\n\nXCCL adds native Intel GPU support to TorchComms through an in-tree backend built on Intel’s oneCCL library.\n\nThe speakers report over 90% scaling efficiency across thousands of nodes on Argonne National Laboratory’s Aurora system while running TorchTitan and other AI workloads. The talk also covers a stream-ordered asynchronous execution model, differences between PyTorch collective semantics and oneCCL, CI, testing on Intel hardware, and comparisons with NCCL and RCCL.\n\n**Introducing NCCL Extensions: Communication Patterns for Modern AI**\n\n**Sreeram Potluri, NVIDIA; Artem Polyakov, NVIDIA**\n\n**October 21, 4:55–5:20 p.m. | 210AE | Breakout Session**\n\nNCCL domain extensions are specialized libraries built on NCCL Device APIs for emerging communication patterns. This session introduces NCCL-EP for Mixture-of-Experts dispatch and combine and NCCL-M2N for zero-copy resharding between disjoint device meshes.\n\nThe speakers cover their design rationale, APIs, and performance results, including the use of NCCL-M2N to move weight snapshots from trainers to inference replicas for reinforcement learning rollout without CPU staging.\n\n**Accelerator Integration and Hardware-Aware Tooling**\n\n**Integrating the IBM Spyre Accelerator**\n\n**David Grove, IBM; Antoni Viros i Martin, IBM Research; Avery Blanchard, IBM Research**\n\n**October 20, 4:55–5:20 p.m. | LL21DEF | Breakout Session**\n\nTorch-Spyre is an open source project that provides a PyTorch PrivateUse1 device with OpenReg, including an Inductor backend, for the IBM Spyre Accelerator.\n\nThe talk covers the state of Torch-Spyre, functional enablement and performance improvements made in 2026, and contributions made back to PyTorch. It also discusses device-specific tensor layouts and scratchpad-optimized tiling, with an emphasis on integration with upstream PyTorch.\n\n**TorchTPU: Running PyTorch Natively on Google TPUs**\n\n**Claudio Basile, Google**\n\n**October 21, 11:10–11:35 a.m. | LL21ABC | Breakout Session**\n\nThis session presents TorchTPU as a native PyTorch backend for Google TPUs. It covers an eager-first stack with ATen-to-StableHLO lowering and “DeferAndFuse” execution, an XLA stack for large-scale workloads, bounded dynamism, and integrations with vLLM and TorchTitan.\n\nThe abstract says TorchTPU has been used in production-scale engagements with private preview partners and is transitioning to an open source model, with a public GitHub repository release upcoming.\n\n**From torch.profiler to Hardware Cycles: A Practical Profiling Playbook for AWS Trainium**\n\n**Esha Lakhotia, AWS Annapurna Labs; Pinak Panigrahi, Amazon**\n\n**October 21, 12:20–12:45 p.m. | LL21ABC | Breakout Session**\n\nThis session shows how the torch.profiler API can be used on AWS Trainium without code changes or separate tooling, from CPU dispatch and runtime orchestration down to on-device hardware execution.\n\nThe speakers walk through tracing slow model components to compiled operations and Python source, using cycle-level device timelines to identify bottlenecks, and AI-assisted analysis that identifies performance bottlenecks and suggests potential fixes.\n\n**Explore the Full Program**\n\nThese sessions represent part of our Core PyTorch program across October 20 and 21. Explore the full PyTorch Conference North America program for additional sessions across training, inference, applications, kernel engineering, responsible AI, and more.", "url": "https://wpnews.pro/news/core-pytorch-sessions-at-pytorch-conference-north-america-2026", "canonical_source": "https://pytorch.org/blog/core-pytorch-sessions-at-pytorch-conference-north-america-2026/", "published_at": "2026-08-27 20:49:08+00:00", "updated_at": "2026-08-27 21:19:26.921308+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "ai-agents"], "entities": ["PyTorch Conference North America 2026", "Huawei", "Meta", "Red Hat", "Claude", "Ascend NPU", "RISC-V", "Triton"], "alternates": {"html": "https://wpnews.pro/news/core-pytorch-sessions-at-pytorch-conference-north-america-2026", "markdown": "https://wpnews.pro/news/core-pytorch-sessions-at-pytorch-conference-north-america-2026.md", "text": "https://wpnews.pro/news/core-pytorch-sessions-at-pytorch-conference-north-america-2026.txt", "jsonld": "https://wpnews.pro/news/core-pytorch-sessions-at-pytorch-conference-north-america-2026.jsonld"}}