ZeRO Optimizer
PremiumProgressive de-redundancy: three-stage sharding from optimizer states to parameters
Get code accessIn the previous chapter we saw DDP's memory problem: to guarantee training consistency (by synchronizing gradients via All-Reduce), each GPU needs to store the complete model state. Four GPUs means 4 complete copies (parameters, gradients, optimizer states). The core idea of ZeRO (Zero Redundancy Optimizer) is straightforward: since the final state is consistent anyway, let each GPU store only a portion, and communicate to fetch the rest when needed.
Redundancy Analysis of Training State
Let's first quantify DDP's waste. Taking mixed precision + Adam as an example, with GPUs training a model with parameters, each GPU needs to store:
- Parameters (fp16): bytes
- Gradients (fp16): bytes
- Optimizer states (fp32): bytes (parameter copy + first moment + second moment)
For a total of bytes, of which optimizer states account for 75%.
GPUs means -fold redundancy: global storage of bytes, when only bytes are actually needed. ZeRO's three stages eliminate these redundancies one by one, in order from largest to smallest.
Log in to continue reading
This is premium content. Please log in to access the full article.
CookLLM Docs