PyTorch Conference北美站：Ray分布式训练与工程实践指南

TL;DR

In only a few weeks, PyTorch Conference North America 2026 will begin in San Jose, bringing together the open source AI community to share ideas and collaborate. If you’ve heard of Ray but never had a reason to dig in, this is the year as more teams seek to scale AI on top of their own secure and governed AI infrastructure.

Ray is a distributed compute framework that helps teams scale any AI framework, library or model. It provides a consistent surface for developers to go from curating petabytes of multimodal data, to training a model across multiple nodes and then deploying it in production whether it’s on VMs or a Kubernetes-managed cluster. That coverage across the full AI lifecycle is also why Ray has become the standard substrate for post training and reinforcement learning (RL) at labs like Cursor, Microsoft AI and NVIDIA. Whether you’re new to distributed PyTorch or already running Ray in production, here’s your guide to the sessions worth blocking off on your schedule.

The open source AI compute stack

Keynote: Evolving Ray and Kubernetes Together for the AI Era

Ion Stoica, Anyscale / Databricks / UC Berkeley · Tue 9:35 AM · Grand Ballroom

Ray co-creator Ion Stoica will deliver a keynote on where Ray and Kubernetes are headed together in the AI era.

Crossing the Divide: Co-Evolving Kubernetes and Ray for the AI Era

Jago Macleod, Google, Ion Stoica, Anyscale / Databricks / UC Berkeley · Tue 2:50 PM · Room 210BF

The AI workload orchestration landscape is currently split across two massive, parallel universes: the CNCF (the bedrock of cloud native and modern infrastructure) and the PyTorch Foundation (the epicenter of AI/ML innovation). While these foundations operate independently, the end user does not have the luxury of choosing just one. PyTorch Foundation contains PyTorch, vLLM, Ray, and more, while CNCF owns Kubernetes, Envoy, OpenTelemetry, llm-d, containerd and more. To build, deploy, and scale modern AI applications, users require a seamless integration of projects from both ecosystems. This session will explore the critical bridge connecting these communities: the co-evolution of Kubernetes and Ray into a unified OSS AI Stack. We will discuss how Google and Anyscale, together with the broader community, are actively collaborating to build an open, vertically integrated stack that prevents ecosystem fragmentation.

Production-scale data curation and model training

Ray All the Way Down: A Heterogeneous, Elastic PyTorch Training Stack at LinkedIn

Tommy Li, Tao Huang, LinkedIn · Tue 3:25 PM · Room 210AE

If you want a concrete blueprint for scaling PyTorch past a single machine, this is the session to attend. LinkedIn’s team walks through a three-layer Ray-based training stack: a Ray-actor-based data loading library that streams Avro, Parquet, and Iceberg; a Ray Train framework layered with FSDP, HSDP, elastic scaling, and async checkpointing; and an on-demand cluster provisioning platform. The core lesson? Keep data loading off the GPUs by routing it through dedicated CPU nodes over a zero-copy bridge. This led to a 50–70% cut in dataloader memory and a scenario where they had to work around Ray to reclaim 24% of their step time. This use case is practical, specific, and reusable well beyond LinkedIn’s stack.

PyTorch-Native Feature Transformation and Training Framework for Uber Eats Recommendation

Peng Zhang, Ke Chen, Xandra Zhu, Uber · Oct 21 · 4:55–5:20 PM · Room LL20CD

Uber’s talk on migrating the Eats recommendation stack from TensorFlow/Horovod to PyTorch leans on Ray Data as a core piece of the redesign, replacing legacy Spark-based preprocessing with distributed feature-stat computation and zero-copy batch transformations. The results are striking: a 5x speedup and 90% lower memory usage for data transformation, plus a 20x improvement in training throughput.

Scaling the LLM Serving Layer with Ray

Ray isn’t just powering dedicated training sessions this year, it’s also showing up as critical infrastructure inside talks with a different primary focus:

Keeping GPUs Busy: High-Speed Storage for PyTorch via fsspec

Ankita Luthra, Trinadh Kotturu, Google · Tue 3:40 PM · Room LL21DEF

A bottleneck has shifted from compute to storage: GPUs sitting idle while waiting on legacy REST-based data access. The proposed fix, Rapid Storage, brings a high-throughput gRPC-based protocol to PyTorch via fsspec. According to the team, the payoff extends across the fsspec ecosystem – including Ray, alongside Dask, HF Datasets, and vLLM. If your Ray Data pipelines are storage-bound, this session is worth a visit.

From PyTorch to Production: Serving a Physics-Constrained Generative Model with ONNX, Ray, and vLLM

Arun Sharma, University of Minnesota · Tue 2:50–3:15 PM · Room 210AE

A deep engineering narrative following a physics-constrained generative model – PC-RF, a conditional rectified-flow model for climate downscaling – from training through to a served, production stack. The talk covers exporting to ONNX two different ways, running the flow-matching sampler outside the graph, and enforcing physics constraints at inference time. Ray shows up as part of the training recipe used to scale the model, with the serving path fanning out into ONNX Runtime, Temporal, and a vLLM agent.

Post-training and RL with Ray

Building a Post-Training Platform for Teams That Don’t Own the Training Loop

Gaurav Arora, Shunyao Li, Eric Wang, Pinterest · Weds 3:25–3:50 PM · Room LL20CD

As post-training expanded across teams at Pinterest (SFT, DPO, GRPO on vision-language models), each built its own stack: different frameworks, data formats, and distributed strategies. Teams spent weeks integrating OSS frameworks with internal infra before training a single step. Our traditional ML platform (MLEnv) owned the PyTorch training loop and reached 95% adoption. Post-training broke that: the loop now lives inside fast-moving OSS frameworks releasing monthly with new techniques. We built PTEnv – a lifecycle harness for PyTorch-based post-training, owning everything around the loop (data, orchestration, scaling, eval, export) while delegating the inner loop to OSS frameworks. The same interface supports subprocess execution with Ray for RL and in-process with MS-Swift using PyTorch FSDP/DDP for SFT – framework choice is a config line, not a rewrite. This talk covers the harness architecture, production gotchas training VLMs at scale (weight sync bottlenecks, MoE workarounds), post training optimization on real workloads, and framework-agnostic eval with LLM-as-judge. A practical talk for platform teams supporting multiple post-training workloads.

SkyRL: Democratizing Scalable RL Training

Sumanth Hedge, Eric Tang, Anyscale · Oct 20 4:55 PM-5:20 PM · LL20A (Lower Level)

Agents have taken center stage in 2026, with ever-growing interest from companies in training custom agents with reinforcement learning. As agents shift to longer horizon, multi-turn interactions, the systems challenges and requirements on underlying training infrastructure have also evolved. SkyRL is a modular, performant RL library built to meet this growing demand for customization and scalability. This talk traces where SkyRL started – a set of modular APIs decoupling training, inference, and environments orchestrated with Ray – and where it is today. The session will cover:

• How SkyRL provides scalable fully async RL training on 350 billion+ parameter MoE models with Megatron and vLLM
• SkyRL’s multi-tenant Tinker Engine, which allows researchers to efficiently use their own hardware for RL training while using Tinker’s flexible training APIs to iterate on recipes
• SkyRL’s redesign towards HTTP-based APIs for scalable inference, and our contributions of native RL APIs to vLLM
• Community recipes built on top of SkyRL including large MoE training on long-horizon tasks, custom recursive language models, and more.

Demo Theater