Melatih model AI besar pada banyak GPU punya satu cara gagal yang mahal. Satu GPU yang macet menghentikan seluruh proses. Mencari penyebabnya selama ini berarti mengulang kegagalan itu secara manual. PyTorch 2.15 menyerang langsung cara gagal tersebut. PyTorch Foundation merilis PyTorch 2.15 pada 28 Oktober 2026. Rilis itu terdiri atas 3.117 commit dari 583 kontributor sejak PyTorch 2.14 (blog rilis PyTorch 2.15, diakses 29 Oktober 2026). Perubahan utamanya menjadikan backend komunikasi NCCL yang ditulis ulang sebagai bawaan. Backend itu berlaku untuk setiap pekerjaan GPU NVIDIA. Backend itu dipasangkan dengan perekam penerbangan. Perekam itu menulis laporan pascakegagalan ke dalam disk saat operasi kolektif macet. Bagi tim yang melatih atau menjalankan model dalam skala besar, ini pertama-tama adalah rilis keandalan, dan baru kemudian rilis kecepatan.
Poin Penting
PyTorch 2.15 dirilis pada 28 Oktober 2026, dengan 3.117 commit dari 583 kontributor sejak PyTorch 2.14.
Backend NCCL yang ditulis ulang kini menjadi bawaan untuk setiap grup proses nccl, disertai perekam penerbangan yang membuang hasil diagnosis saat operasi kolektif macet.
Transpor satu arah hadir dengan NIXL sebagai backend pertama, dan FSDP2 mendapat kendali yang lebih halus atas presisi, akumulasi gradien, dan tumpang tindih komunikasi.
Proses dekode menjadi lebih cepat di kedua ujung rentang perangkat keras: dekode NVFP4 pada GPU NVIDIA Blackwell serta FP8 dan kernel matriks berkelompok pada Apple Silicon.
Peningkatan versi punya batas yang perlu diperiksa: dukungan Python 3.10 dan macOS 14 berakhir, titik pemeriksaan terdistribusi dari 2.15 tidak dapat dimuat oleh rilis yang lebih lama, dan jalan kembali nccl-legacy dihapus pada rilis berikutnya.
Rilis ini melanjutkan arah yang digambarkan tim PyTorch sepanjang seri 2.x. Arah itu adalah perubahan dari kerangka kerja yang mengutamakan riset menjadi platform terpadu. Platform itu tidak bergantung pada satu perangkat keras. Platform itu melayani pelatihan dan inferensi produksi dalam skala besar (blog rilis PyTorch 2.15). PyTorch 2.13 membawa FlexAttention ke Apple Silicon dan memperkenalkan torchcomms untuk pelatihan pada klaster besar. PyTorch 2.14 mematangkan pekerjaan itu menjadi NVGEMM dan menampilkan backend NCCL yang ditulis ulang sebagai pilihan yang dapat diaktifkan. PyTorch 2.15 menyelesaikan serah terima itu. Pratinjau menjadi bawaan. Perkakas di sekitarnya untuk penelusuran kesalahan, presisi, dan dukungan perangkat keras ikut mengejar ketinggalan.
Apa Itu PyTorch?
PyTorch adalah kerangka kerja pembelajaran mesin sumber terbuka untuk membangun, melatih, dan menjalankan jaringan saraf. Tim memakainya untuk menulis model dalam Python. Tim menjalankannya pada CPU dan akselerator. Kode yang sama dapat ditingkatkan skalanya dari percobaan di laptop menjadi klaster pelatihan multi-GPU. Siklus rilisnya dijalankan oleh PyTorch Foundation, dan setiap rilis minor menghimpun ribuan kontribusi dari seluruh komunitas. Versi 2.15 paling tepat dipahami sebagai pekerjaan infrastruktur. Sebagian besar perubahannya berada di bawah kode model. Perubahan itu menyangkut cara GPU saling berbicara. Perubahan itu juga menyangkut cara memori dikelola dan cara pekerjaan dijadwalkan pada cip yang berbeda.
Aspek | PyTorch 2.15 |
|---|---|
Dirilis | 28 Oktober 2026 |
Ukuran rilis | 3.117 commit dari 583 kontributor sejak 2.14 |
Perubahan utama | Backend NCCL yang ditulis ulang menjadi bawaan, dengan perekam penerbangan untuk kemacetan |
Pelatihan terdistribusi | Transpor satu arah NIXL, kendali FSDP2 dan pipeline yang lebih halus |
Dekode | NVFP4 pada NVIDIA Blackwell, FP8 dan grouped_mm pada Apple Silicon |
Cakupan perangkat keras | NVIDIA, Apple Silicon, AMD gfx950 dan gfx1250, GPU Intel |
Dukungan Python | Python 3.11 sampai 3.15, termasuk torch.compile pada Python 3.15 |
Jalan kembali | TORCH_DIST_USE_NCCL2=0 atau nccl-legacy, dihapus pada rilis berikutnya |
Pelatihan Terdistribusi Mendapat Bawaan Baru
NCCL adalah pustaka NVIDIA untuk komunikasi kolektif antargpu: operasi seperti all-reduce dan all-gather, ketika setiap GPU dalam satu pekerjaan saling bertukar data. Saat model dilatih pada banyak GPU, GPU-GPU itu terus-menerus bertukar gradien dan aktivasi lewat backend ini. Pertukaran yang lambat atau macet memperlambat seluruh pekerjaan. PyTorch 2.14 menampilkan backend NCCL yang ditulis ulang, yang diporting dari torchcomms, sebagai backend nccl2 yang dapat diaktifkan. Pada PyTorch 2.15, setiap pekerjaan yang memakai nccl berjalan pada backend yang ditulis ulang itu. Backend itu menjadi bawaan (blog rilis PyTorch 2.15).
Tambahan yang paling praktis adalah perekam penerbangan. Perekam penerbangan adalah alat diagnosis yang tidak bergantung pada satu backend. Alat itu merekam apa yang sedang dilakukan setiap rank pada saat kemacetan. Alat itu lalu menulis laporan pascakegagalan ke dalam disk. Rank adalah satu proses dalam pekerjaan terdistribusi. Status kesehatan pengawas diterbitkan ke server penelusuran kesalahan. Batas waktu pada rank mana pun lalu memicu pembuangan perekam penerbangan dari semua rank sekaligus. Pada skala klaster, hal itu mengubah kemacetan dari misteri yang harus diulang menjadi bukti yang dapat dibaca. Rekonfigurasi juga dapat memilih jalur cepat menyusut atau membesar pada NCCL 2.29 atau yang lebih baru. Rank yang bertahan lalu melewati bootstrap penuh saat pekerjaan berubah bentuk. Rekonfigurasi untuk toleransi kesalahan diaktifkan pada ROCm dengan RCCL 2.30.7. For example, contoh ilustratif berikut menjelaskan cara kerjanya. Satu rank menunggu operasi yang tidak pernah tiba. Pekerjaan pun berhenti. Perekam penerbangan menunjukkan rank mana yang berhenti dan operasi apa yang ditunggunya.
Jalan keluarnya bersifat sementara, dan catatan rilis menyatakannya secara eksplisit. Anda dapat memulihkan perilaku lama pada 2.15 dengan menyetel TORCH_DIST_USE_NCCL2=0 atau memilih backend nccl-legacy. Namun, kedua jalur itu akan dihapus pada rilis berikutnya (catatan rilis PyTorch 2.15.0). Perlakukan backend lama sebagai jembatan penelusuran kesalahan, bukan sebagai rencana migrasi. Tim yang masih bergantung padanya sebaiknya menjadwalkan perpindahan sekarang, selagi jalan kembali itu masih ada untuk membandingkan perilaku.
Transpor Satu Arah dan Kendali FSDP2 yang Lebih Halus
PyTorch 2.15 juga menambah cara kedua bagi proses untuk memindahkan data. Komunikasi satu arah adalah perpindahan data satu pihak. Satu rank membaca dari atau menulis ke penyangga jarak jauh. Rank jarak jauh itu tidak mengeluarkan panggilan yang berpasangan pada saat yang sama. API transpor Python baru dalam torch.distributed mendukung model itu, dengan NIXL sebagai backend pertamanya. Sebuah transpor terhubung ke rekan lewat sebuah toko data. Transpor itu tidak memerlukan grup proses atau operasi kolektif. Transport.read_stream serta Transport.write_stream mengantrekan transfer pada aliran CUDA sehingga dapat ditangkap dengan torch.cuda.graph (blog rilis PyTorch 2.15). Bentuk itu cocok untuk inferensi yang dipisah-pisah. Bentuk itu juga cocok untuk migrasi cache KV dan server parameter. Bentuk itu cocok pula untuk sistem pembelajaran penguatan yang produsen dan konsumennya berjalan pada jadwal yang berbeda.
FSDP2 adalah strategi paralel data yang dipecah penuh dari PyTorch. Strategi ini memecah parameter model, gradien, dan status pengoptimal pada banyak GPU. Dengan cara itu, model yang lebih besar daripada memori satu GPU tetap dapat dilatih. Versi 2.15 memberinya kendali yang lebih halus atas presisi dan penangkapan. Parameter yang peka terhadap presisi dapat tetap berada dalam fp32. Contohnya gerbang perute pada model campuran pakar dan bobot normalisasi. Sisa model dilatih dalam bf16. Caranya tetap memakai satu all-gather per unit fully_shard, lewat MixedPrecisionPolicy dengan param_dtype_override_fn. Seluruh langkah akumulasi gradien kini dapat ditangkap dalam satu graf CUDA. Presisi gradien dapat disetel per parameter. Reduksi gradien dapat bertumpang tindih dengan komputasi. Satu bawaan berubah dan layak diperhatikan. Bila reduce_dtype tidak disetel, gradien kini diakumulasi dan direduksi dalam grad_dtype tiap parameter, bukan dalam param_dtype (catatan rilis PyTorch 2.15.0). Bila pelatihan Anda bergantung pada bawaan lama, setel reduce_dtype secara eksplisit.
Paralelisme pipeline mendapat perlakuan yang sama. Penyangga penerima kini dialokasikan tepat sebelum setiap penerimaan. Penyangga itu tidak dialokasikan untuk setiap microbatch di muka. Keluaran forward dilepas begitu pengirimannya selesai. Jadwal menerima anggaran max_outstanding_sends. Unshard FSDP dijadwalkan berselang pada gelembung awal tiap rank. Unshard itu tidak semuanya dikeluarkan pada awal langkah. Setiap sisi unik antarrank pipeline kini mendapat komunikator peer-to-peer khusus. Bersama-sama, catatan rilis menggambarkan hasilnya sebagai pipeline yang dapat ditangkap dalam graf CUDA. Pipeline itu bersifat deterministik, dengan profil memori yang dioptimalkan.
Dekode Lebih Cepat pada Blackwell dan Apple Silicon
NVFP4 adalah format floating-point 4-bit bawaan NVIDIA Blackwell untuk inferensi. Mendekode model bahasa satu token pada satu waktu sering kali dibatasi oleh beban peluncuran kernel. Beban itu lebih membatasi daripada aritmetika mentah. Karena itu, menghapus peluncuran lebih penting daripada menambah throughput puncak. NVGEMM, backend GEMM CuTeDSL yang ditambahkan pada 2.14, kini melipat faktor dekuantisasi skalar dari lapisan linear NVFP4 ModelOpt ke dalam GEMM itu sendiri. Hal itu menghapus satu peluncuran pointwise per lapisan selama dekode. Kernelnya dapat memakai peluncuran dependen terprogram agar konsumen Triton bertumpang tindih dengan ekor GEMM produsen (blog rilis PyTorch 2.15). Dampak praktisnya adalah peluncuran kernel yang lebih sedikit dan lebih bertumpang tindih pada dekode Blackwell.
Apple Silicon mendapat kisah presisi rendah yang sepadan. FP8 adalah format floating-point 8-bit. Format itu menyimpan tiap nilai dalam separuh memori bf16. Hal itu penting pada mesin yang memorinya dipakai bersama oleh CPU dan GPU. PyTorch 2.15 menambah dukungan float8_e4m3fn pada MPS, bersama _scaled_mm dengan penskalaan tensorwise atau rowwise. Grouped_mm baru punya jalur cepat dekode. Jalur itu menghasilkan 1,32 sampai 1,34x token per detik pada dekode campuran pakar pada M3 Ultra. API torch.mps.Stream publik yang meniru aliran CUDA melengkapi paket itu (blog rilis PyTorch 2.15). Pekerjaan kernel di sekitarnya sama konkretnya. F.linear kini memakai kernel gemv yang ada untuk percepatan rata-rata geometris 1,23x dan sampai 5x pada proyeksi kecil. Softmax satu baris pada kosakata 128.256 entri turun 8x. Backward upsample sampai 21,7x lebih cepat. Reduksi penuh norm lebih dari 100x lebih cepat. Faktorisasi QR matriks 512 kali 512 turun dari sekitar 7 detik menjadi 1,5 milidetik. Angka-angka itu adalah pengukuran proyek sendiri pada perangkat kerasnya. Ulangi pengukuran itu pada model Anda sendiri sebelum mengutipnya sebagai keuntungan Anda.
Cakupan Perangkat Keras Melebar ke Segala Arah
Rilis ini memperluas peta perangkat keras PyTorch pada keempat lini utama. Pada AMD, FlyDSL bergabung dengan CuTeDSL, Triton, dan Helion sebagai bahasa kernel yang dapat dipakai PyTorch. Inductor menyetel otomatis templat FlyDSL untuk GEMM, grouped_mm yang tidak beraturan, dan scaled_mm MXFP4 serta MXFP8 pada gfx950. Gfx1250, generasi MI450, mendapat dukungan Tensor Data Mover. Dukungan itu mencakup perkalian matriks padat, pointwise, dan pembuatan kode reduksi, plus FlexAttention forward dan dekode. Roda ROCm 10.0 dikirim berdampingan dengan roda ROCm 7.14 dari 2.14, semuanya dibangun pada paket TheRock dari AMD. Pada GPU Intel, dukungan kernel fungsi bebas SYCL menggantikan implementasi berbasis functor yang panjang untuk sebagian besar kernel yang ada. XPU mendapat berbagi kejadian antarproses dan kebijakan alokasi MemPool. Pemrofilan menambah visibilitas tingkat kernel ke dalam pemutaran ulang Graf XPU. Roda bawaan berpindah ke CUDA 13.2, dengan roda CUDA 13.4 berdampingan, termasuk dukungan eksperimental untuk GPU NVIDIA Rubin. Klaster besar seperti ini biasanya berjalan pada infrastruktur yang diorkestrasi. Penjelasan Kubernetes kami membahas apa yang dilakukan lapisan itu dan mengapa lapisan itu menjalankan komputasi awan. Dukungan Python mencakup 3.11 sampai 3.15. Cakupannya termasuk build utas bebas 3.14t dan 3.15t, dengan dukungan torch.compile untuk Python 3.15 (blog rilis PyTorch 2.15).
Sebelum Anda Meningkatkan Versi
PyTorch 2.15 adalah rilis minor dengan beberapa batas yang keras. Periksa setiap hal berikut sebelum Anda meluncurkannya:
Python 3.10 tidak lagi didukung. Versi 2.15 memerlukan Python 3.11 atau yang lebih baru, roda 3.10 tidak lagi dibuat, dan 3.10 tidak lagi diuji dalam CI.
macOS 14 tidak lagi didukung untuk akselerasi MPS. Versi 2.15 memerlukan macOS 15 atau yang lebih baru untuk pekerjaan GPU Apple Silicon.
Titik pemeriksaan terdistribusi yang disimpan dengan PyTorch 2.15 tidak dapat dimuat oleh PyTorch 2.14 atau yang lebih lama, karena metadata titik pemeriksaan kini merekam langkah tensor. Simpan titik pemeriksaan yang kompatibel dengan jalan kembali sampai peningkatan versi diterima.
Perilaku gradien FSDP2 berubah bila reduce_dtype tidak disetel, seperti dijelaskan di atas. Setel secara eksplisit bila Anda memerlukan perilaku 2.14.
Peringatan C++ dari torch.ops dan operasi kustom kini diteruskan ke Python, dan import torch tidak lagi dapat dieksekusi ulang dalam proses yang sama.
Backend nccl-legacy dan TORCH_DIST_USE_NCCL2=0 hanya ada pada rilis ini. Rencanakan migrasi sebelum rilis berikutnya menghapusnya.
Tim PyTorch juga akan mengadakan webinar tanya jawab pada Kamis, 5 November 2026, pukul 11 pagi Waktu Pasifik. Tristan Rice, Natalia Gimelshein, Huy Do, dan Jane Xu akan memaparkan rilis ini dan menjawab pertanyaan (blog rilis PyTorch 2.15). Bila tim Anda menjalankan pelatihan multi-GPU dalam produksi, dua topik layak diangkat di sana. Topik itu adalah perekam penerbangan dan linimasa backend lama.
Apa Kata Liputan Independen
Liputan Futurum Group menyebut 2.15 sebagai rilis ketika ambisi produksi PyTorch menjadi komitmen rekayasa yang konkret. Alasannya adalah backend komunikasi bawaan yang diperkeras, diagnosis kemacetan yang sistematis, dan cakupan perangkat keras yang luas. Semua itu menunjukkan kerangka kerja yang direkayasa untuk kenyataan operasional tim AI perusahaan, bukan hanya untuk laboratorium riset. Liputan itu mengutip survei Futurum. Survei itu menemukan bahwa 55,4% pengambil keputusan AI menyebut keandalan dan pengelolaan halusinasi sebagai tantangan produksi utama (Futurum Group, 29 Oktober 2026). Bingkai itu wajar sejauh yang dikatakannya. Namun, itu adalah bacaan analis, bukan hasil yang terukur. Rilis itu sendiri membuktikan perkakasnya ada. Rilis itu tidak membuktikan bahwa pekerjaan tim tertentu menjadi lebih cepat atau lebih andal.
Uraian AlphaSignal sampai pada pusat gravitasi yang sama dari sisi rekayasa. Liputan itu menitikberatkan pada pelatihan terdistribusi, dekode presisi rendah, dan dukungan akselerator. Liputan itu menandai tiga perubahan kompatibilitas yang sama bagi tim produksi. Dukungan Python 3.10 telah berakhir. C++20 kini diperlukan untuk kode bawaan. Titik pemeriksaan terdistribusi dari 2.15 tidak dapat dimuat oleh rilis yang lebih lama (AlphaSignal, 28 Oktober 2026). Saran praktisnya adalah saran yang tepat. Tim multi-node sebaiknya menguji kinerja kolektif NCCL terlebih dahulu. Tim itu juga sebaiknya menguji diagnosis kemacetan dan pemulihan kegagalan. Pekerjaan yang memakai jalan kembali lama memerlukan rencana migrasi sebelum rilis berikutnya menghapus jalur itu.
Pertanyaan yang Sering Diajukan
Apakah PyTorch 2.15 gratis? Ya. PyTorch adalah perangkat lunak sumber terbuka, dan meningkatkan versi ke 2.15 tidak memungut biaya untuk kerangka kerjanya sendiri. Biaya Anda adalah perangkat keras, komputasi awan, dan waktu rekayasa yang sudah Anda keluarkan untuk menjalankan pekerjaan pelatihan atau inferensi.
Apakah saya harus mengubah kode untuk memakai backend NCCL baru? Tidak. Setiap grup proses yang dibuat dengan backend nccl kini memakai implementasi yang ditulis ulang itu sebagai bawaan, tanpa perubahan kode. Bila Anda memerlukan perilaku lama untuk sementara, setel TORCH_DIST_USE_NCCL2=0 atau pilih backend nccl-legacy. Rencanakan migrasi sebelum rilis berikutnya menghapus jalur itu.
Apa yang dilakukan perekam penerbangan saat pekerjaan pelatihan macet? Perekam itu menulis laporan pascakegagalan ke dalam disk. Laporan itu merekam apa yang sedang dilakukan setiap rank pada saat kemacetan. Batas waktu pada rank mana pun memicu pembuangan dari semua rank lewat server penelusuran kesalahan. Hal itu memberi Anda bukti tentang rank dan operasi yang macet, bukan mengharuskan Anda mengulang kegagalan itu secara manual.
Dapatkah saya memuat titik pemeriksaan terdistribusi PyTorch 2.15 pada PyTorch 2.14? Tidak. Metadata titik pemeriksaan pada 2.15 merekam langkah tensor. Titik pemeriksaan yang disimpan dengan 2.15 tidak dapat dimuat oleh 2.14 atau yang lebih lama. Simpan titik pemeriksaan lama bila Anda mungkin perlu kembali.
Versi Python apa yang didukung PyTorch 2.15? Python 3.11 sampai 3.15, termasuk build utas bebas 3.14t dan 3.15t, dengan dukungan torch.compile untuk Python 3.15. Python 3.10 tidak lagi didukung, dan macOS 15 atau yang lebih baru diperlukan untuk akselerasi MPS pada Apple Silicon.
Kesimpulan
PyTorch 2.15 tidak akan mengubah apa yang dapat dilakukan model Anda. Rilis ini mengubah seberapa andal Anda dapat melatih dan menjalankannya dalam skala besar. Rilis ini juga mengubah pada berapa banyak jenis perangkat keras Anda dapat melakukannya. Backend NCCL yang ditulis ulang dan perekam penerbangannya menangani satu cara gagal. Cara gagal itu membuang sumber daya paling mahal dalam pekerjaan AI. Sumber daya itu adalah waktu GPU yang dihabiskan untuk pekerjaan yang macet. Transpor NIXL, kendali FSDP2, dan kernel dekode memberi tim infrastruktur perkakas yang lebih halus untuk pekerjaan yang sama. Batas peningkatan versinya luar biasa jelas untuk rilis minor. Itu adalah kebaikan. Periksa Python, macOS, titik pemeriksaan, dan linimasa backend lama sebelum Anda meningkatkan versi. Jangan memeriksanya sesudahnya. Mulailah dari blog rilis PyTorch 2.15 dan catatan rilis lengkap di GitHub. Bila inferensi terdistribusi dalam skala besar adalah masalah Anda, artikel llm-d 1.0 kami membahas tumpukan inferensi produksi yang dibangun untuk dunia yang sama, atau bacalah versi bahasa Inggris artikel ini.
For example, contoh ilustratif berikut adalah langkah pemeriksaan yang umum. Tim menguji pekerjaan kecil pada klaster uji. Tim memeriksa catatan perekam penerbangan. Tim baru meluncurkan ke produksi setelah hasil uji dapat diterima. Metode artikel ini adalah membandingkan blog rilis resmi dan catatan rilis PyTorch 2.15 dengan liputan Futurum Group dan AlphaSignal. Artikel ini melewati peninjauan editorial sebelum diterbitkan.