<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>PyTorch Distributed: Experiences on Accelerating Data Parallel Training · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2006.15704/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2006.15704/feed.xml" rel="self" type="application/rss+xml" /><item><title>PyTorch Distributed: Experiences on Accelerating Data Parallel Training — mentioned by BadInformatics</title><link>https://news.ycombinator.com/item?id=26451750</link><guid isPermaLink="false">urn:hackerpapers:mention:2006.15704:26451750</guid><pubDate>Sun, 14 Mar 2021 01:02:38 GMT</pubDate><description>&lt;p&gt;Having followed this DeepSpeed stuff for a little while, the ZeRO paper is probably as close as you can get to an ELI5 because there&amp;#x27;s no singular brilliant idea behind this. Most of the ideas have been explored already (see e.g. the PyTorch DDP paper), but ZeRO takes them to their logical conclusion by throwing a TON of engineering work into the equation. For example, they implement custom fused kernels on CPU/GPU and a hand-vectorized Adam implementation. I found that this earlier blog post [2] has a much better deep dive (with decent animations and more) into the underlying architecture.…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2006.15704/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DC</category></item></channel></rss>
