<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>DeepSpeed on Duo&#39;s Tech Blog</title>
    <link>https://duoan.github.io/tags/deepspeed/</link>
    <description>Recent content in DeepSpeed on Duo&#39;s Tech Blog</description>
    <image>
      <title>Duo&#39;s Tech Blog</title>
      <url>https://duoan.github.io/images/papermod-cover.png</url>
      <link>https://duoan.github.io/images/papermod-cover.png</link>
    </image>
    <generator>Hugo -- 0.153.1</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 16 Jun 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://duoan.github.io/tags/deepspeed/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The ZeRO-3 Diagram Most People Remember Is Wrong</title>
      <link>https://duoan.github.io/posts/zero3-intra-layer-partitioning/</link>
      <pubDate>Mon, 16 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://duoan.github.io/posts/zero3-intra-layer-partitioning/</guid>
      <description>&lt;h1 id=&#34;the-zero-3-diagram-most-people-remember-is-wrong&#34;&gt;The ZeRO-3 Diagram Most People Remember Is Wrong&lt;/h1&gt;
&lt;p&gt;Many engineers first learned ZeRO-3 from an animation that looked like pipeline parallelism.
One GPU owned early layers, another GPU owned later layers, and the active layer block appeared to be broadcast to all other GPUs when needed.
That picture is memorable.
It is also not the right mental model for current DeepSpeed ZeRO-3 training.&lt;/p&gt;
&lt;p&gt;The current steady-state model is intra-layer partitioning.
Each parameter is flattened, padded if necessary, and split across data-parallel ranks.
Before forward or backward compute needs that parameter, ranks AllGather the full parameter.
After gradients are produced, ranks ReduceScatter gradients back to the owning shards.
That is the operational reading of ZeRO-3 from the ZeRO paper (&lt;a href=&#34;https://arxiv.org/abs/1910.02054&#34;&gt;arXiv:1910.02054&lt;/a&gt;) and the current DeepSpeed runtime.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Sequence Parallelism II: DeepSpeed Ulysses and All-to-All Attention</title>
      <link>https://duoan.github.io/posts/sequence-parallelism-ulysses/</link>
      <pubDate>Mon, 19 May 2025 00:00:00 +0000</pubDate>
      <guid>https://duoan.github.io/posts/sequence-parallelism-ulysses/</guid>
      <description>&lt;h1 id=&#34;sequence-parallelism-ii-deepspeed-ulysses-and-all-to-all-attention&#34;&gt;Sequence Parallelism II: DeepSpeed Ulysses and All-to-All Attention&lt;/h1&gt;
&lt;p&gt;Megatron SP is a careful memory optimization around an existing tensor-parallel block.
DeepSpeed Ulysses starts from a different question.
What if each device owns a sequence slice most of the time, but attention temporarily wants each device to own a head slice instead?&lt;/p&gt;
&lt;p&gt;The answer in DeepSpeed Ulysses is an All-to-All transpose (&lt;a href=&#34;https://arxiv.org/abs/2309.14509&#34;&gt;arXiv:2309.14509&lt;/a&gt;).
Before attention, every rank has all heads for a subset of tokens.
After All-to-All, every rank has all tokens for a subset of heads.
That one layout change lets local attention run per head while the rest of the layer can remain sequence-sharded.&lt;/p&gt;</description>
    </item>
    <item>
      <title>MoE Internals: DeepSpeed-Megatron Expert Parallel Implementation</title>
      <link>https://duoan.github.io/posts/moe-deepspeed-megatron-internals/</link>
      <pubDate>Sat, 17 May 2025 00:00:00 +0000</pubDate>
      <guid>https://duoan.github.io/posts/moe-deepspeed-megatron-internals/</guid>
      <description>&lt;h1 id=&#34;moe-internals-deepspeed-megatron-expert-parallel-implementation&#34;&gt;MoE Internals: DeepSpeed-Megatron Expert Parallel Implementation&lt;/h1&gt;
&lt;p&gt;DeepSpeed-Megatron MoE is easy to misread if you only inspect one initialization function. Megatron builds the usual TP, PP, and DP topology. DeepSpeed then wraps the model, finds MoE modules, and gives those modules expert-parallel groups. The topology is split across the training framework and the MoE layer implementation.&lt;/p&gt;
&lt;p&gt;This post connects the pieces: &lt;code&gt;deepspeed.initialize()&lt;/code&gt;, EP groups, expert-DP groups, &lt;code&gt;MoELayer&lt;/code&gt;, and the difference between a DeepSpeed MoE wrapper and a Megatron-integrated SwitchMLP-style module.
For routing, capacity, and All-to-All fundamentals, start with &lt;a href=&#34;../moe-expert-parallelism-principles/&#34;&gt;MoE Parallelism Principles&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ZeRO: Partitioning Optimizer State, Gradients, and Parameters</title>
      <link>https://duoan.github.io/posts/zero-redundancy-optimizer/</link>
      <pubDate>Sun, 27 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://duoan.github.io/posts/zero-redundancy-optimizer/</guid>
      <description>&lt;h1 id=&#34;zero-partitioning-optimizer-state-gradients-and-parameters&#34;&gt;ZeRO: Partitioning Optimizer State, Gradients, and Parameters&lt;/h1&gt;
&lt;p&gt;Plain DDP is clean but wasteful. Every data-parallel rank stores the same parameters, gradients, fp32 master weights, and optimizer moments. At small scale that redundancy is convenient. At LLM scale it is the memory wall.&lt;/p&gt;
&lt;p&gt;ZeRO, the Zero Redundancy Optimizer, keeps data-parallel semantics and removes the redundant storage one category at a time. ZeRO-1 shards optimizer state. ZeRO-2 shards optimizer state and gradients. ZeRO-3 shards optimizer state, gradients, and parameters (&lt;a href=&#34;https://arxiv.org/abs/1910.02054&#34;&gt;arXiv:1910.02054&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>LLM Training Series: A Systems Map for Distributed Transformers</title>
      <link>https://duoan.github.io/posts/llm-training-series/</link>
      <pubDate>Sun, 02 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://duoan.github.io/posts/llm-training-series/</guid>
      <description>&lt;h1 id=&#34;llm-training-series-a-systems-map-for-distributed-transformers&#34;&gt;LLM Training Series: A Systems Map for Distributed Transformers&lt;/h1&gt;
&lt;p&gt;LLM training stops being &amp;ldquo;run the model on more GPUs&amp;rdquo; the moment one replica no longer fits, one link becomes the step time, or one schedule leaves half the cluster idle. From that point on, the training run is a placement problem.&lt;/p&gt;
&lt;p&gt;The stable question is simple: &lt;strong&gt;which bytes are replicated, which bytes are sharded, and which link moves them on the critical path?&lt;/strong&gt; Data parallelism, tensor parallelism, pipeline parallelism, ZeRO, sequence/context parallelism, and expert parallelism are different answers to that question. The public systems that matter - GPipe, Megatron-LM, DeepSpeed ZeRO, PyTorch DDP, GShard, Switch Transformer, and modern Megatron-Core - all expose the same constraints in different shapes (&lt;a href=&#34;https://arxiv.org/abs/1811.06965&#34;&gt;GPipe&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/abs/1909.08053&#34;&gt;Megatron-LM&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/abs/1910.02054&#34;&gt;ZeRO&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/abs/2006.15704&#34;&gt;PyTorch Distributed&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/abs/2006.16668&#34;&gt;GShard&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/abs/2101.03961&#34;&gt;Switch Transformer&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
