add intro/tldr

convert.py

@@ -0,0 +1,32 @@
+#!/usr/bin/env python3
+import markdown
+from pathlib import Path
+import sys
+
+def convert_md_to_html(filepath):
+   input_path = Path(filepath)
+   output_path = input_path.with_suffix('.html')
+   
+   try:
+       with open(input_path, 'r', encoding='utf-8') as md_file:
+           text = md_file.read()
+           html = markdown.markdown(text)
+       
+       with open(output_path, 'w', encoding='utf-8', errors='xmlcharrefreplace') as html_file:
+           html_file.write(html)
+           
+       print(f"Converted {input_path} -> {output_path}")
+           
+   except FileNotFoundError:
+       print(f"Error: Could not find file {input_path}")
+       sys.exit(1)
+   except Exception as e:
+       print(f"Error converting file: {e}")
+       sys.exit(1)
+
+if __name__ == '__main__':
+   if len(sys.argv) != 2:
+       print("Usage: python convert.py FILEPATH.md")
+       sys.exit(1)
+       
+   convert_md_to_html(sys.argv[1])

dist/bibliography.bib

@@ -331,4 +331,40 @@ url = {https://github.com/meta-llama/llama3/blob/main/MODEL_CARD.md}
       eprint={2212.05129},
       archivePrefix={arXiv},
       primaryClass={cs.AI}
+}
+@misc{kaplan2020scalinglaws,
+      title={Scaling Laws for Neural Language Models}, 
+      author={Jared Kaplan and Sam McCandlish and Tom Henighan and Tom B. Brown and Benjamin Chess and Rewon Child and Scott Gray and Alec Radford and Jeffrey Wu and Dario Amodei},
+      year={2020},
+      eprint={2001.08361},
+      archivePrefix={arXiv},
+      primaryClass={cs.LG},
+      url={https://arxiv.org/abs/2001.08361}, 
+}
+@misc{hoffmann2022chinchilla,
+      title={Training Compute-Optimal Large Language Models}, 
+      author={Jordan Hoffmann and Sebastian Borgeaud and Arthur Mensch and Elena Buchatskaya and Trevor Cai and Eliza Rutherford and Diego de Las Casas and Lisa Anne Hendricks and Johannes Welbl and Aidan Clark and Tom Hennigan and Eric Noland and Katie Millican and George van den Driessche and Bogdan Damoc and Aurelia Guy and Simon Osindero and Karen Simonyan and Erich Elsen and Jack W. Rae and Oriol Vinyals and Laurent Sifre},
+      year={2022},
+      eprint={2203.15556},
+      archivePrefix={arXiv},
+      primaryClass={cs.CL},
+      url={https://arxiv.org/abs/2203.15556}, 
+}
+@misc{grattafiori2024llama3herdmodels,
+      title={The Llama 3 Herd of Models}, 
+      author={Aaron Grattafiori and Abhimanyu Dubey and Abhinav Jauhri and Abhinav Pandey and Abhishek Kadian and Ahmad Al-Dahle and Aiesha Letman and Akhil Mathur and Alan Schelten and Alex Vaughan and Amy Yang and Angela Fan and Anirudh Goyal and Anthony Hartshorn and Aobo Yang and Archi Mitra and Archie Sravankumar and Artem Korenev and Arthur Hinsvark and Arun Rao and Aston Zhang and Aurelien Rodriguez and Austen Gregerson and Ava Spataru and Baptiste Roziere and Bethany Biron and Binh Tang and Bobbie Chern and Charlotte Caucheteux and Chaya Nayak and Chloe Bi and Chris Marra and Chris McConnell and Christian Keller and Christophe Touret and Chunyang Wu and Corinne Wong and Cristian Canton Ferrer and Cyrus Nikolaidis and Damien Allonsius and Daniel Song and Danielle Pintz and Danny Livshits and Danny Wyatt and David Esiobu and Dhruv Choudhary and Dhruv Mahajan and Diego Garcia-Olano and Diego Perino and Dieuwke Hupkes and Egor Lakomkin and Ehab AlBadawy and Elina Lobanova and Emily Dinan and Eric Michael Smith and Filip Radenovic and Francisco Guzmán and Frank Zhang and Gabriel Synnaeve and Gabrielle Lee and Georgia Lewis Anderson and Govind Thattai and Graeme Nail and Gregoire Mialon and Guan Pang and Guillem Cucurell and Hailey Nguyen and Hannah Korevaar and Hu Xu and Hugo Touvron and Iliyan Zarov and Imanol Arrieta Ibarra and Isabel Kloumann and Ishan Misra and Ivan Evtimov and Jack Zhang and Jade Copet and Jaewon Lee and Jan Geffert and Jana Vranes and Jason Park and Jay Mahadeokar and Jeet Shah and Jelmer van der Linde and Jennifer Billock and Jenny Hong and Jenya Lee and Jeremy Fu and Jianfeng Chi and Jianyu Huang and Jiawen Liu and Jie Wang and Jiecao Yu and Joanna Bitton and Joe Spisak and Jongsoo Park and Joseph Rocca and Joshua Johnstun and Joshua Saxe and Junteng Jia and Kalyan Vasuden Alwala and Karthik Prasad and Kartikeya Upasani and Kate Plawiak and Ke Li and Kenneth Heafield and Kevin Stone and Khalid El-Arini and Krithika Iyer and Kshitiz Malik and Kuenley Chiu and Kunal Bhalla and Kushal Lakhotia and Lauren Rantala-Yeary and Laurens van der Maaten and Lawrence Chen and Liang Tan and Liz Jenkins and Louis Martin and Lovish Madaan and Lubo Malo and Lukas Blecher and Lukas Landzaat and Luke de Oliveira and Madeline Muzzi and Mahesh Pasupuleti and Mannat Singh and Manohar Paluri and Marcin Kardas and Maria Tsimpoukelli and Mathew Oldham and Mathieu Rita and Maya Pavlova and Melanie Kambadur and Mike Lewis and Min Si and Mitesh Kumar Singh and Mona Hassan and Naman Goyal and Narjes Torabi and Nikolay Bashlykov and Nikolay Bogoychev and Niladri Chatterji and Ning Zhang and Olivier Duchenne and Onur Çelebi and Patrick Alrassy and Pengchuan Zhang and Pengwei Li and Petar Vasic and Peter Weng and Prajjwal Bhargava and Pratik Dubal and Praveen Krishnan and Punit Singh Koura and Puxin Xu and Qing He and Qingxiao Dong and Ragavan Srinivasan and Raj Ganapathy and Ramon Calderer and Ricardo Silveira Cabral and Robert Stojnic and Roberta Raileanu and Rohan Maheswari and Rohit Girdhar and Rohit Patel and Romain Sauvestre and Ronnie Polidoro and Roshan Sumbaly and Ross Taylor and Ruan Silva and Rui Hou and Rui Wang and Saghar Hosseini and Sahana Chennabasappa and Sanjay Singh and Sean Bell and Seohyun Sonia Kim and Sergey Edunov and Shaoliang Nie and Sharan Narang and Sharath Raparthy and Sheng Shen and Shengye Wan and Shruti Bhosale and Shun Zhang and Simon Vandenhende and Soumya Batra and Spencer Whitman and Sten Sootla and Stephane Collot and Suchin Gururangan and Sydney Borodinsky and Tamar Herman and Tara Fowler and Tarek Sheasha and Thomas Georgiou and Thomas Scialom and Tobias Speckbacher and Todor Mihaylov and Tong Xiao and Ujjwal Karn and Vedanuj Goswami and Vibhor Gupta and Vignesh Ramanathan and Viktor Kerkez and Vincent Gonguet and Virginie Do and Vish Vogeti and Vítor Albiero and Vladan Petrovic and Weiwei Chu and Wenhan Xiong and Wenyin Fu and Whitney Meers and Xavier Martinet and Xiaodong Wang and Xiaofang Wang and Xiaoqing Ellen Tan and Xide Xia and Xinfeng Xie and Xuchao Jia and Xuewei Wang and Yaelle Goldschlag and Yashesh Gaur and Yasmine Babaei and Yi Wen and Yiwen Song and Yuchen Zhang and Yue Li and Yuning Mao and Zacharie Delpierre Coudert and Zheng Yan and Zhengxing Chen and Zoe Papakipos and Aaditya Singh and Aayushi Srivastava and Abha Jain and Adam Kelsey and Adam Shajnfeld and Adithya Gangidi and Adolfo Victoria and Ahuva Goldstand and Ajay Menon and Ajay Sharma and Alex Boesenberg and Alexei Baevski and Allie Feinstein and Amanda Kallet and Amit Sangani and Amos Teo and Anam Yunus and Andrei Lupu and Andres Alvarado and Andrew Caples and Andrew Gu and Andrew Ho and Andrew Poulton and Andrew Ryan and Ankit Ramchandani and Annie Dong and Annie Franco and Anuj Goyal and Aparajita Saraf and Arkabandhu Chowdhury and Ashley Gabriel and Ashwin Bharambe and Assaf Eisenman and Azadeh Yazdan and Beau James and Ben Maurer and Benjamin Leonhardi and Bernie Huang and Beth Loyd and Beto De Paola and Bhargavi Paranjape and Bing Liu and Bo Wu and Boyu Ni and Braden Hancock and Bram Wasti and Brandon Spence and Brani Stojkovic and Brian Gamido and Britt Montalvo and Carl Parker and Carly Burton and Catalina Mejia and Ce Liu and Changhan Wang and Changkyu Kim and Chao Zhou and Chester Hu and Ching-Hsiang Chu and Chris Cai and Chris Tindal and Christoph Feichtenhofer and Cynthia Gao and Damon Civin and Dana Beaty and Daniel Kreymer and Daniel Li and David Adkins and David Xu and Davide Testuggine and Delia David and Devi Parikh and Diana Liskovich and Didem Foss and Dingkang Wang and Duc Le and Dustin Holland and Edward Dowling and Eissa Jamil and Elaine Montgomery and Eleonora Presani and Emily Hahn and Emily Wood and Eric-Tuan Le and Erik Brinkman and Esteban Arcaute and Evan Dunbar and Evan Smothers and Fei Sun and Felix Kreuk and Feng Tian and Filippos Kokkinos and Firat Ozgenel and Francesco Caggioni and Frank Kanayet and Frank Seide and Gabriela Medina Florez and Gabriella Schwarz and Gada Badeer and Georgia Swee and Gil Halpern and Grant Herman and Grigory Sizov and Guangyi and Zhang and Guna Lakshminarayanan and Hakan Inan and Hamid Shojanazeri and Han Zou and Hannah Wang and Hanwen Zha and Haroun Habeeb and Harrison Rudolph and Helen Suk and Henry Aspegren and Hunter Goldman and Hongyuan Zhan and Ibrahim Damlaj and Igor Molybog and Igor Tufanov and Ilias Leontiadis and Irina-Elena Veliche and Itai Gat and Jake Weissman and James Geboski and James Kohli and Janice Lam and Japhet Asher and Jean-Baptiste Gaya and Jeff Marcus and Jeff Tang and Jennifer Chan and Jenny Zhen and Jeremy Reizenstein and Jeremy Teboul and Jessica Zhong and Jian Jin and Jingyi Yang and Joe Cummings and Jon Carvill and Jon Shepard and Jonathan McPhie and Jonathan Torres and Josh Ginsburg and Junjie Wang and Kai Wu and Kam Hou U and Karan Saxena and Kartikay Khandelwal and Katayoun Zand and Kathy Matosich and Kaushik Veeraraghavan and Kelly Michelena and Keqian Li and Kiran Jagadeesh and Kun Huang and Kunal Chawla and Kyle Huang and Lailin Chen and Lakshya Garg and Lavender A and Leandro Silva and Lee Bell and Lei Zhang and Liangpeng Guo and Licheng Yu and Liron Moshkovich and Luca Wehrstedt and Madian Khabsa and Manav Avalani and Manish Bhatt and Martynas Mankus and Matan Hasson and Matthew Lennie and Matthias Reso and Maxim Groshev and Maxim Naumov and Maya Lathi and Meghan Keneally and Miao Liu and Michael L. Seltzer and Michal Valko and Michelle Restrepo and Mihir Patel and Mik Vyatskov and Mikayel Samvelyan and Mike Clark and Mike Macey and Mike Wang and Miquel Jubert Hermoso and Mo Metanat and Mohammad Rastegari and Munish Bansal and Nandhini Santhanam and Natascha Parks and Natasha White and Navyata Bawa and Nayan Singhal and Nick Egebo and Nicolas Usunier and Nikhil Mehta and Nikolay Pavlovich Laptev and Ning Dong and Norman Cheng and Oleg Chernoguz and Olivia Hart and Omkar Salpekar and Ozlem Kalinli and Parkin Kent and Parth Parekh and Paul Saab and Pavan Balaji and Pedro Rittner and Philip Bontrager and Pierre Roux and Piotr Dollar and Polina Zvyagina and Prashant Ratanchandani and Pritish Yuvraj and Qian Liang and Rachad Alao and Rachel Rodriguez and Rafi Ayub and Raghotham Murthy and Raghu Nayani and Rahul Mitra and Rangaprabhu Parthasarathy and Raymond Li and Rebekkah Hogan and Robin Battey and Rocky Wang and Russ Howes and Ruty Rinott and Sachin Mehta and Sachin Siby and Sai Jayesh Bondu and Samyak Datta and Sara Chugh and Sara Hunt and Sargun Dhillon and Sasha Sidorov and Satadru Pan and Saurabh Mahajan and Saurabh Verma and Seiji Yamamoto and Sharadh Ramaswamy and Shaun Lindsay and Shaun Lindsay and Sheng Feng and Shenghao Lin and Shengxin Cindy Zha and Shishir Patil and Shiva Shankar and Shuqiang Zhang and Shuqiang Zhang and Sinong Wang and Sneha Agarwal and Soji Sajuyigbe and Soumith Chintala and Stephanie Max and Stephen Chen and Steve Kehoe and Steve Satterfield and Sudarshan Govindaprasad and Sumit Gupta and Summer Deng and Sungmin Cho and Sunny Virk and Suraj Subramanian and Sy Choudhury and Sydney Goldman and Tal Remez and Tamar Glaser and Tamara Best and Thilo Koehler and Thomas Robinson and Tianhe Li and Tianjun Zhang and Tim Matthews and Timothy Chou and Tzook Shaked and Varun Vontimitta and Victoria Ajayi and Victoria Montanez and Vijai Mohan and Vinay Satish Kumar and Vishal Mangla and Vlad Ionescu and Vlad Poenaru and Vlad Tiberiu Mihailescu and Vladimir Ivanov and Wei Li and Wenchen Wang and Wenwen Jiang and Wes Bouaziz and Will Constable and Xiaocheng Tang and Xiaojian Wu and Xiaolan Wang and Xilun Wu and Xinbo Gao and Yaniv Kleinman and Yanjun Chen and Ye Hu and Ye Jia and Ye Qi and Yenda Li and Yilin Zhang and Ying Zhang and Yossi Adi and Youngjin Nam and Yu and Wang and Yu Zhao and Yuchen Hao and Yundi Qian and Yunlu Li and Yuzi He and Zach Rait and Zachary DeVito and Zef Rosnbrick and Zhaoduo Wen and Zhenyu Yang and Zhiwei Zhao and Zhiyu Ma},
+      year={2024},
+      eprint={2407.21783},
+      archivePrefix={arXiv},
+      primaryClass={cs.AI},
+      url={https://arxiv.org/abs/2407.21783}, 
+}
+@misc{deepseekai2024deepseekv3technicalreport,
+      title={DeepSeek-V3 Technical Report}, 
+      author={DeepSeek-AI and Aixin Liu and Bei Feng and Bing Xue and Bingxuan Wang and Bochao Wu and Chengda Lu and Chenggang Zhao and Chengqi Deng and Chenyu Zhang and Chong Ruan and Damai Dai and Daya Guo and Dejian Yang and Deli Chen and Dongjie Ji and Erhang Li and Fangyun Lin and Fucong Dai and Fuli Luo and Guangbo Hao and Guanting Chen and Guowei Li and H. Zhang and Han Bao and Hanwei Xu and Haocheng Wang and Haowei Zhang and Honghui Ding and Huajian Xin and Huazuo Gao and Hui Li and Hui Qu and J. L. Cai and Jian Liang and Jianzhong Guo and Jiaqi Ni and Jiashi Li and Jiawei Wang and Jin Chen and Jingchang Chen and Jingyang Yuan and Junjie Qiu and Junlong Li and Junxiao Song and Kai Dong and Kai Hu and Kaige Gao and Kang Guan and Kexin Huang and Kuai Yu and Lean Wang and Lecong Zhang and Lei Xu and Leyi Xia and Liang Zhao and Litong Wang and Liyue Zhang and Meng Li and Miaojun Wang and Mingchuan Zhang and Minghua Zhang and Minghui Tang and Mingming Li and Ning Tian and Panpan Huang and Peiyi Wang and Peng Zhang and Qiancheng Wang and Qihao Zhu and Qinyu Chen and Qiushi Du and R. J. Chen and R. L. Jin and Ruiqi Ge and Ruisong Zhang and Ruizhe Pan and Runji Wang and Runxin Xu and Ruoyu Zhang and Ruyi Chen and S. S. Li and Shanghao Lu and Shangyan Zhou and Shanhuang Chen and Shaoqing Wu and Shengfeng Ye and Shengfeng Ye and Shirong Ma and Shiyu Wang and Shuang Zhou and Shuiping Yu and Shunfeng Zhou and Shuting Pan and T. Wang and Tao Yun and Tian Pei and Tianyu Sun and W. L. Xiao and Wangding Zeng and Wanjia Zhao and Wei An and Wen Liu and Wenfeng Liang and Wenjun Gao and Wenqin Yu and Wentao Zhang and X. Q. Li and Xiangyue Jin and Xianzu Wang and Xiao Bi and Xiaodong Liu and Xiaohan Wang and Xiaojin Shen and Xiaokang Chen and Xiaokang Zhang and Xiaosha Chen and Xiaotao Nie and Xiaowen Sun and Xiaoxiang Wang and Xin Cheng and Xin Liu and Xin Xie and Xingchao Liu and Xingkai Yu and Xinnan Song and Xinxia Shan and Xinyi Zhou and Xinyu Yang and Xinyuan Li and Xuecheng Su and Xuheng Lin and Y. K. Li and Y. Q. Wang and Y. X. Wei and Y. X. Zhu and Yang Zhang and Yanhong Xu and Yanhong Xu and Yanping Huang and Yao Li and Yao Zhao and Yaofeng Sun and Yaohui Li and Yaohui Wang and Yi Yu and Yi Zheng and Yichao Zhang and Yifan Shi and Yiliang Xiong and Ying He and Ying Tang and Yishi Piao and Yisong Wang and Yixuan Tan and Yiyang Ma and Yiyuan Liu and Yongqiang Guo and Yu Wu and Yuan Ou and Yuchen Zhu and Yuduan Wang and Yue Gong and Yuheng Zou and Yujia He and Yukun Zha and Yunfan Xiong and Yunxian Ma and Yuting Yan and Yuxiang Luo and Yuxiang You and Yuxuan Liu and Yuyang Zhou and Z. F. Wu and Z. Z. Ren and Zehui Ren and Zhangli Sha and Zhe Fu and Zhean Xu and Zhen Huang and Zhen Zhang and Zhenda Xie and Zhengyan Zhang and Zhewen Hao and Zhibin Gou and Zhicheng Ma and Zhigang Yan and Zhihong Shao and Zhipeng Xu and Zhiyu Wu and Zhongyu Zhang and Zhuoshu Li and Zihui Gu and Zijia Zhu and Zijun Liu and Zilin Li and Ziwei Xie and Ziyang Song and Ziyi Gao and Zizheng Pan},
+      year={2024},
+      eprint={2412.19437},
+      archivePrefix={arXiv},
+      primaryClass={cs.CL},
+      url={https://arxiv.org/abs/2412.19437}, 
 }

dist/index.html

@@ -7,82 +7,15 @@
     <meta name="viewport" content="width=device-width, initial-scale=1">
     <meta charset="utf8">
     <base target="_blank">
-    <title>FineWeb: decanting the web for the finest text data at scale</title>
+    <title>The Ultra-Scale Playbook: Training LLMs on GPU Clusters</title>
     <link rel="stylesheet" href="style.css">
-    <style>
-        #controls {
-            display: grid;
-            grid-template-columns: 350px 350px;
-            gap: 1px;
-            align-items: center;
-            max-width: 700px;
-            margin: 0 auto 20px;
-            padding: 0 10px;
-        }
-
-        #controls .row {
-            display: contents;
-        }
-
-        #controls .cell {
-            padding: 1px;
-            box-sizing: border-box;
-        }
-
-        #controls .column-1 {
-            display: flex;
-            align-items: center;
-            justify-content: space-between;
-        }
-
-        #controls .column-2 {
-            display: flex;
-            align-items: center;
-            justify-content: space-between;
-        }
-
-        #controls label {
-            text-align: right;
-            padding-right: 10px;
-            flex: 0 0 auto;
-            width: 150px;
-            line-height: 1.5em;
-            font-size: 0.8em;
-        }
-
-        #controls input[type="range"] {
-            width: 50%;
-            margin: 0 10px;
-        }
-
-        #controls input[type="number"] {
-            width: 60px;
-            height: 20px;
-        }
-
-        #controls select {
-            width: 100%;
-        }
-
-        #controls .column {
-            display: contents;
-        }
-
-        #graph svg {
-            font-family: sans-serif;
-        }
-
-        #graph svg rect {
-            cursor: pointer;
-        }
-    </style>
 </head>
 
 <body>
     <d-front-matter>
         <script id='distill-front-matter' type="text/json">{
-    "title": "🔭 Ultra-Guide to Scaling LLM training",
-    "description": "This blog covers everything about scaling LLMs in 2024.",
+    "title": "The Ultra-Scale Playbook: Training LLMs on GPU Clusters",
+    "description": "This blog covers everything about scaling LLMs in 2025.",
     "published": "Sept 28, 2024",
     "affiliation": {"name": "HuggingFace"},
     "authors": [
@@ -104,7 +37,7 @@
     </script>
     </d-front-matter>
     <d-title>
-        <h1 class="l-page" style="text-align: center;">🔭 Ultra-Guide to Scaling LLM training</h1>
+        <h1 class="l-page" style="text-align: center;">The Ultra-Scale Playbook: Training LLMs on GPU Clusters</h1>
         <div id="title-plot" class="main-plot-container l-screen">
             <figure>
                 <img src="assets/images/banner.png" alt="FineWeb">
@@ -118,1107 +51,168 @@
     <d-article>
         <d-contents>
         </d-contents>
+        
+        <p>Fueled by the scaling laws<d-cite bibtex-key="kaplan2020scalinglaws"></d-cite><d-cite bibtex-key="hoffmann2022chinchilla"></d-cite>, the trend of training ever larger language models on vaster amounts of data has been driving progress in AI for the past couple years. Initially, the development of the largest models happened exclusively behind closed doors of a handful of research labs but recently opened up more with the release of models such as Llama 3.1 405B<d-cite bibtex-key="grattafiori2024llama3herdmodels"></d-cite> and DeepSeek R1<d-cite bibtex-key="deepseekai2024deepseekv3technicalreport"></d-cite>. While these models have <a href="https://huggingface.co/meta-llama">openly shared</a> <a href="https://huggingface.co/deepseek-ai">weights</a> and their training recipes are described in <a href="https://ai.meta.com/research/publications/the-llama-3-herd-of-models/">technical</a> <a href="https://github.com/deepseek-ai/DeepSeek-R1/blob/main/DeepSeek_R1.pdf">reports</a>, the challenging engineering to involved to train at the necessary infrastructure scale is still hidden between the lines of a handful of papers and complex training frameworks. This ~~long blog post~~ open-source book is here to open this black box!</p>
 
-        <p>The performance of a large language model (LLM) depends heavily on the quality and size of the LLMs.
-            However, the pretraining datasets for state-of-the-art open LLMs like Llama 3<d-cite
-                bibtex-key="llama3modelcard"></d-cite> and Mixtral<d-cite bibtex-key="jiang2024mixtral"></d-cite> are
-            not publicly available and very little is known about how they were created.</p>
         <aside>Reading time: 7 days. For the best reading experience, we recommend not using a mobile phone.</aside>
 
-        <p>Recently, we released <a href="https://huggingface.co/datasets/HuggingFaceFW/fineweb"><strong>🍷
-                    FineWeb</strong></a>, a new, large-scale
-            (<strong>15-trillion tokens, 44TB disk space</strong>) dataset for LLM pretraining. FineWeb is derived from
-            96 <a href="https://commoncrawl.org/">CommonCrawl</a> snapshots and produces <strong>better-performing LLMs
-                than other open pretraining datasets</strong>.
+        <p>In this book we invite you to follow us in the wonderful world of scaling training of Large Language Models to tens, hundreds, thousands of GPUs. It assumes you know the basics on LLM architecture and training, but are new to distributed training. This writing can be seen as a second part of a trilogy following our first blog on processing data for pre-training, the so-called “<a href="https://huggingface.co/spaces/HuggingFaceFW/blogpost-fineweb-v1">FineWeb blog post</a>”. Having read both blog posts, you should have almost all the core knowledge needed to deeply understand how LLMs are being built nowadays, just missing a bit the final spices like data mixing or architecture choices to complete the recipe (stay tuned…).</p>
+
+        <p>Pre-training LLMs from scratch now requires amounts of compute which exceed in almost every case the use of a single GPU or machine. The clusters used to train these models range from hundreds to thousands of nodes each usually equipped with 4 to 8 GPUs. To make the best use of such an expensive hardware as well as to train in a reasonable time, a range of distributed training methods have been developed with the goal of ensuring that GPUs are highly utilized at all times. Efficiently scaling LLM training is also not confined to pretraining anymore, as fine-tuning larger models on more domain specific data is becoming the standard practice to achieve the best results.</p>
 
         <aside>We are extremely thankful to the whole <a href="https://distill.pub/">distill.pub</a> team for creating
             the template on which we based this blog post.</aside>
+        
+        <p>In this post we’ll cover these scaling methods exhaustively while keeping a single story-line to understand where each technique comes from. We’ll cover data, tensor, pipeline and context parallelism as well as ZeRO and kernel fusion. The post is built on the following <strong>three foundations</strong>:</p>
+
+        <p><strong>Quick intros on theory and concepts:</strong> before diving into code and experiments, we want to understand how each method works at a high level and what it’s advantages and limits are. You’ll learn about which parts of a language model eat away your memory and when during training it happens. You’ll learn how we can solve memory constraints by parallelizing the models and increase the throughput by scaling up GPUs. As a result you'll understand how the following widget to compute the memory breakdown of a transformer model works: </p>
 
-        <div id="graph" style="position: relative; width: 700px; height: 500px;"></div>
+        <div id="graph"></div>
         <div id="controls">
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="a">Attention Heads (a):</label>
-                    <input type="range" id="a" name="a" min="1" max="128" value="8">
-                    <input type="number" id="a_input" value="8" min="1" max="128">
-                </div>
-                <div class="cell column-2">
-                    <label for="mixed">Mixed Precision:</label>
-                    <input type="checkbox" id="mixed" name="mixed" checked>
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-                </div>
+            <div class="cell column-1">
+            <label for="a">Attention Heads (a):</label>
+            <input type="range" id="a" name="a" min="1" max="128" value="8">
+            <input type="number" id="a_input" value="8" min="1" max="128">
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="b">Micro Batch Size (b):</label>
-                    <input type="range" id="b" name="b" min="1" max="53248" value="32">
-                    <input type="number" id="b_input" value="32" min="1" max="53248">
-                </div>
-                <div class="cell column-2">
-                    <label for="seq_parallel">Sequence Parallelism:</label>
-                    <input type="checkbox" id="seq_parallel" name="seq_parallel">
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-                </div>
+            <div class="cell column-2">
+            <label for="mixed">Mixed Precision:</label>
+            <input type="checkbox" id="mixed" name="mixed" checked>
+            <span></span> <!-- Empty span to maintain grid alignment -->
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="h">Hidden Dimension (h):</label>
-                    <input type="range" id="h" name="h" min="1" max="16384" value="512">
-                    <input type="number" id="h_input" value="512" min="128" max="16384">
-                </div>
-                <div class="cell column-2">
-                    <label for="recomputation">Recomputation:</label>
-                    <select id="recomputation" name="recomputation">
-                        <option value="none">None</option>
-                        <option value="selective">Selective</option>
-                        <option value="full">Full</option>
-                    </select>
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-
-                </div>
+            <div class="cell column-1">
+            <label for="b">Micro Batch Size (b):</label>
+            <input type="range" id="b" name="b" min="1" max="53248" value="32">
+            <input type="number" id="b_input" value="32" min="1" max="53248">
+            </div>
+            <div class="cell column-2">
+            <label for="seq_parallel">Sequence Parallelism:</label>
+            <input type="checkbox" id="seq_parallel" name="seq_parallel">
+            <span></span> <!-- Empty span to maintain grid alignment -->
+            </div>
+            <div class="cell column-1">
+            <label for="h">Hidden Dimension (h):</label>
+            <input type="range" id="h" name="h" min="1" max="16384" value="512">
+            <input type="number" id="h_input" value="512" min="128" max="16384">
+            </div>
+            <div class="cell column-2">
+            <label for="recomputation">Recomputation:</label>
+            <select id="recomputation" name="recomputation">
+                <option value="none">None</option>
+                <option value="selective">Selective</option>
+                <option value="full">Full</option>
+            </select>
+            <span></span> <!-- Empty span to maintain grid alignment -->
+            </div>
+            <div class="cell column-1">
+            <label for="h_ff">Feedforward Dimension (h_ff):</label>
+            <input type="range" id="h_ff" name="h_ff" min="1" max="65536" value="2048">
+            <input type="number" id="h_ff_input" value="2048" min="512" max="65536">
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="h_ff">Feedforward Dimension (h_ff):</label>
-                    <input type="range" id="h_ff" name="h_ff" min="1" max="65536" value="2048">
-                    <input type="number" id="h_ff_input" value="2048" min="512" max="65536">
-                </div>
-                <div class="cell column-2">
-                    <label for="zero">Zero:</label>
-                    <select id="zero" name="zero">
-                        <option value="0">0</option>
-                        <option value="1">1</option>
-                        <option value="2">2</option>
-                        <option value="3">3</option>
-                    </select>
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-                </div>
+            <div class="cell column-2">
+            <label for="zero">Zero:</label>
+            <select id="zero" name="zero">
+                <option value="0">0</option>
+                <option value="1">1</option>
+                <option value="2">2</option>
+                <option value="3">3</option>
+            </select>
+            <span></span> <!-- Empty span to maintain grid alignment -->
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="L">Number of Layers (L):</label>
-                    <input type="range" id="L" name="L" min="1" max="126" value="12">
-                    <input type="number" id="L_input" value="12" min="1" max="126">
-                </div>
-                <div class="cell column-2">
-                    <label for="ff_activation">FF Activation:</label>
-                    <select id="ff_activation" name="ff_activation">
-                        <option value="relu">ReLU</option>
-                        <option value="gelu">GELU</option>
-                        <option value="swiglu">SwiGLU</option>
-                    </select>
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-                </div>
+            <div class="cell column-1">
+            <label for="L">Number of Layers (L):</label>
+            <input type="range" id="L" name="L" min="1" max="126" value="12">
+            <input type="number" id="L_input" value="12" min="1" max="126">
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="s">Sequence Length (s):</label>
-                    <input type="range" id="s" name="s" min="1" max="128000" value="128">
-                    <input type="number" id="s_input" value="128" min="64" max="128000">
-                </div>
-                <div class="cell column-2">
-                    <label for="presets">Presets:</label>
-                    <select id="presets" name="presets">
-                        <option value="Llama 3 Tiny">Llama 3 Tiny</option>
-                        <option value="Llama 3 8B">Llama 3 8B</option>
-                        <option value="Llama 3 70B">Llama 3 70B</option>
-                        <option value="Llama 3 405B">Llama 3 405B</option>
-                    </select>
-                    <span></span> <!-- Empty span to maintain grid alignment -->
-                </div>
+            <div class="cell column-2">
+            <label for="ff_activation">FF Activation:</label>
+            <select id="ff_activation" name="ff_activation">
+                <option value="relu">ReLU</option>
+                <option value="gelu">GELU</option>
+                <option value="swiglu">SwiGLU</option>
+            </select>
+            <span></span> <!-- Empty span to maintain grid alignment -->
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="v">Vocabulary Size (v):</label>
-                    <input type="range" id="v" name="v" min="1000" max="100000" value="30522">
-                    <input type="number" id="v_input" value="30522" min="1000" max="100000">
-                </div>
-                <div class="cell column-2">
-                    <label for="tp">Tensor Parallelism (t):</label>
-                    <input type="range" id="tp" name="tp" min="1" max="16" value="8">
-                    <input type="number" id="tp_input" value="8" min="1" max="16">
-                </div>
+            <div class="cell column-1">
+            <label for="s">Sequence Length (s):</label>
+            <input type="range" id="s" name="s" min="1" max="128000" value="128">
+            <input type="number" id="s_input" value="128" min="64" max="128000">
             </div>
-            <div class="row">
-                <div class="cell column-1">
-                    <label for="k">Optimizer Parameters (k):</label>
-                    <input type="range" id="k" name="k" min="1" max="16" value="8">
-                    <input type="number" id="k_input" value="8" min="1" max="16">
-                </div>
-                <div class="cell column-2">
-                    <label for="dp">Data Parallelism (d):</label>
-                    <input type="range" id="dp" name="dp" min="1" max="256" value="1">
-                    <input type="number" id="dp_input" value="1" min="1" max="256">
-                </div>
+            <div class="cell column-2">
+            <label for="presets">Presets:</label>
+            <select id="presets" name="presets">
+                <option value="Llama 3 Tiny">Llama 3 Tiny</option>
+                <option value="Llama 3 8B">Llama 3 8B</option>
+                <option value="Llama 3 70B">Llama 3 70B</option>
+                <option value="Llama 3 405B">Llama 3 405B</option>
+            </select>
+            <span></span> <!-- Empty span to maintain grid alignment -->
+            </div>
+            <div class="cell column-1">
+            <label for="v">Vocabulary Size (v):</label>
+            <input type="range" id="v" name="v" min="1000" max="100000" value="30522">
+            <input type="number" id="v_input" value="30522" min="1000" max="100000">
+            </div>
+            <div class="cell column-2">
+            <label for="tp">Tensor Parallelism (t):</label>
+            <input type="range" id="tp" name="tp" min="1" max="16" value="8">
+            <input type="number" id="tp_input" value="8" min="1" max="16">
+            </div>
+            <div class="cell column-1">
+            <label for="k">Optimizer Parameters (k):</label>
+            <input type="range" id="k" name="k" min="1" max="16" value="8">
+            <input type="number" id="k_input" value="8" min="1" max="16">
+            </div>
+            <div class="cell column-2">
+            <label for="dp">Data Parallelism (d):</label>
+            <input type="range" id="dp" name="dp" min="1" max="256" value="1">
+            <input type="number" id="dp_input" value="1" min="1" max="256">
             </div>
         </div>
 
-        <p><strong>TLDR:</strong> This blog covers a discussion on processing and evaluating data quality at scale, the
-            🍷 FineWeb
-            recipe (listing and explaining all of our design choices), and the process followed to create its 📚
-            FineWeb-Edu subset.</p>
-
-        <h2>Scaling Models and Hardware</h2>
-
-        <p>Now that we know the basics of distributed communication and computations it's time to apply this to training
-            LLMs at scale. Here's the plan of action: we'll go through increasingly complex distribution strategies,
-            namely data, then tensor and finally pipeline parallelism, and show three things:</p>
-
-        <ol>
-            <li>conceptual explanations with diagrams</li>
-            <li>a minimal coding example illustrating how to implement said strategy</li>
-            <li>scaling experiments show casing strengths and limits of the method with real data</li>
-        </ol>
-
-        <p>For the experiments we scale across two dimensions: we make the models larger and larger and add more and
-            more compute nodes and measure how throughput changes.</p>
-
-        <p>So this is a good point to get ☕ #2 and we'll have a look at the setup for the practical experiments.</p>
-
-        <h2>Experiment setup</h2>
-
-        <table>
-            <thead>
-                <tr>
-                    <th></th>
-                    <th><strong>1B (1)</strong></th>
-                    <th><strong>7B</strong></th>
-                    <th><strong>70B</strong></th>
-                    <th><strong>340B (2)</strong></th>
-                    <th><strong>400B (3)</strong></th>
-                </tr>
-            </thead>
-            <tbody>
-                <tr>
-                    <td><strong>N Layers</strong></td>
-                    <td>24</td>
-                    <td>32</td>
-                    <td>80</td>
-                    <td>96</td>
-                    <td>126</td>
-                </tr>
-                <tr>
-                    <td><strong>N Heads</strong></td>
-                    <td>32</td>
-                    <td>32</td>
-                    <td>64</td>
-                    <td>96</td>
-                    <td>128</td>
-                </tr>
-                <tr>
-                    <td><strong>Dimension</strong></td>
-                    <td>2048</td>
-                    <td>4096</td>
-                    <td>8192</td>
-                    <td>18432</td>
-                    <td>16384</td>
-                </tr>
-            </tbody>
-        </table>
-
-        <p>(1) FineWeb ablation models</p>
-        <p>(2) Nemotron-340B architecture (without GQA)</p>
-        <p>(3) Llama-400B, ffn dim = 1.2 hidden dim (without GQA)</p>
-
+        <p>While this widget gives a theoretical breakdown the following tool can be used to predict the memory usage:</p>
+        
+        <p><img alt="image.png" src="assets/images/placeholder.png"/></p>
 
-        <h2>Distribution Methods</h2>
+        <p><strong>Clear code implementations:</strong> theory is one thing, but we discover all kinds of edge cases and important details when we implement something. That’s why we link to implementation references where possible. Depending on the case, we’ll use two code references: the <a href="https://github.com/huggingface/picotron">picotron</a> repository is built for education, thus it implements concepts usually in single, self-contained short files. On the other hand, to look at production ready code, we’ll refer to the <a href="https://github.com/huggingface/nanotron">nanotron</a> implementations which is a production training codebase used at Hugging Face.</p>
 
-        <p>Efficiently training LLMs now requires amounts of compute which exceed in most case single GPUs or machine.
-            Large distributed clusters are thus used to train these models and can range from hundreds to thousands of
-            nodes each usually equipped with up to 8 GPUs. To make the best use of such an expensive hardware, a range
-            of distributed training methods have been developed with the goal of ensuring that GPUs are highly utilized
-            at all times and not waiting for data/synchronization/etc.</p>
+        <p><img alt="Picotron implements each key concept in a self-contained way, such that the method can be studied separately and in isolation." src="assets/images/placeholder.png" /></p>
 
-        <p>Several methods can be used to distribute training and we'll start with 4D parallelism followed-up by
-            DeepSpeed stages. While we explain these strategies we'll also run experiments to determine the trade-offs
-            and understand the optimal settings.</p>
-        <p>The name "4D parallelism" originates from the fact that it involves combining up to 4 distribution methods:
-            data, tensor, pipeline, and sequence parallelism (each of these techniques can be used independently of the
-            other). You may thus ask "So which one should I use?".</p>
+        <p><strong>Real training efficiency benchmarks:</strong> Finally, how to <em>actually</em> scale your LLM training depends on your infrastructure, such as the kind of chips, interconnect etc., and we can’t give a single unified recipe. What we will give though is a way to benchmark several setups and it is what we have done on our cluster! We ran over 4100 distributed experiments with up to 512 GPUs to scan many possible distributed training layouts and model sizes. TODO: link to dataset too </p>
 
-        <p>Unfortunately, there is no universal answer as the response will actually depend on the cluster setup as well
-            as the model architecture. But do not despair for in this section we'll develop strategies to figure out the
-            best setting experimentally!</p>
+        <p><img alt="An overview of the over 4000 experiments across all Llama architectures where each data point corresponds to an experiment launch." src="assets/images/placeholder.png" /></p>
 
-        <p>In addition to 4D parallelism we'll also take a look at "DeepSpeed", a method developed by Microsoft which is
-            generally complimentary to 4D parallelism and can be leveraged on top of it.</p>
+        <p>As you can see, there’s a lot of ground to be covered. Before getting into the trenches of distributed training let’s take a quick high level look on we’ll cover in the post.</p>
 
-        <p><strong>Idea: show two things in every section</strong></p>
+        <h2>TL;DR</h2>
+        <p>This book is very extensive so we decide to start with a very general overview of how you can think about distributed training. At a high level, the key challenge in scaling LLM training is to make a training step (forward/backward/optimizer step) with a large batch size the fastest possible.</p>
+        <p>When scaling up models and input batches, we quickly end up in situations where either our target batch size won't fit in memory, or/and the model itself is too large to fit in a single GPU's memory.</p>
+        <p>To solve this scaling issue we’ll need to carefully evaluate different parallelization strategies and find the optimal balance between three main factors:</p>
         <ol>
-            <li>a small toy model (e.g. 4 layer FFN) we can interactively show with every approach</li>
-            <li>a benchmark showing the improvement/limits of the approach (e.g. when you cross 1 node with TP)</li>
-        </ol>
-
-        <h3>No Parallelism</h3>
-
-        <p>Let's quickly go over the basics before going into distributed training. When a model is trained on a single
-            GPU, the training consists of 3 steps in the simplest case:</p>
-        <ol>
-            <li>one forward pass,</li>
-            <li>one backward pass to compute the gradients, and</li>
-            <li>an optimization step using the gradients to update the parameters</li>
-        </ol>
-
-        <p>As we'll see in the future, these steps may be repeated or intertwined but for now we'll start simple:</p>
-        <p>As we'll see in the future, these steps may be repeated or intertwined but for now we'll start simple:</p>
-
-        <img src="assets/images/IMG_7537D08D7F41-1.jpeg" alt="Training Steps">
-
-        <p>In this figure the successive blue boxes on the top line can be seen as successive layers inside a model
-            (same for the last line). The red boxes are the associated gradients for each of these layers.</p>
-
-        <p>The batch size (<em>bs</em>) is one of the most important hyper-parameters in machine learning, affecting
-            both model convergence and throughput.</p>
-
-        <p>If the batch size is too small, gradients will tend to be noisy and the model may not be able to converge to
-            optimal performances while a batch size too large can make the convergence of the model slower and waste
-            compute. You can find a nice discussion of this topic in OpenAI's paper on large batch training (<a
-                href="https://arxiv.org/abs/1812.06162">https://arxiv.org/pdf/1812.06162</a>).</p>
-
-        <p>The batch size also affects the throughput: a small batch size will require more optimizer steps to train on
-            a given amount of samples. Optimizer steps are costly (in compute time) and the throughput will thus be
-            lower than when using a larger batch size. On the other hand, larger batches, while leading to higher
-            throughput may suffer from slow convergence in the limits as we've just seen. There is generally an optimal
-            batch size from a convergence/performance point of view (note that the batch size can usually still be
-            changed around the optimal batch size without major impact to the performance of the model).</p>
-
-        <p>Note that in the LLM community, batch sizes are commonly reported in terms of tokens instead of number of
-            samples (BST - Batch Size Tokens) as each token has a label and thus a loss term and can thus be considered
-            individual (although highly correlated) samples.</p>
-
-        <p>A sweet spot for LLM training is usually on the order of 4-20 million tokens per batch (links GPT-3,
-            DeepSeek, Llama). In the simplest case, training on a single machine, the <em>BS</em> and <em>BST</em> can
-            be computed from the model input sequence length as follows:</p>
-
-        <d-math>
-            bst=bs *seq
-        </d-math>
-
-        <p>(note that from here on forward we'll show the formulas for the batch size in number of samples but you can
-            always get its token-unit counterpart by multiplying it with the sequence length)</p>
-
-        <p>And we're now hitting our first scaling problem:</p>
-
-        <blockquote>
-            <p>what if we can't fit the model into GPU memory even with <code>BS=1</code>?</p>
-        </blockquote>
-
-        <p>Good question, reader!</p>
-
-        <p>Let's start by understanding what led to our out-of-memory issue in the first place.</p>
-
-        <h2>A brief overview of memory usage in Transformers</h2>
-
-        <p>To train a neural network model, one needs to store many elements in memory besides the weights themselves.
-            Generally, the memory usage is made up from the following elements:</p>
-        <ul>
-            <li>model weights</li>
-            <li>model gradients</li>
-            <li>optimizer states</li>
-            <li>activations computed during the forward pass and which are needed to compute the backward pass</li>
-            <li>also CUDA Kernels require 1-2GB of GPU memory which you can quickly check yourself by running
-                <code>import torch; torch.ones((1, 1)).to("cuda")</code> and then checking the GPU memory with
-                <code>nvidia-smi</code>
-            </li>
-            <li>lower rest memory usage from buffers, intermediate results and some memory that can't be used due to
-                fragmentation</li>
+        <li><strong>Memory Usage</strong><ul>
+        <li>Hard limitation - if a training step doesn't fit in memory, training cannot proceed</li>
+        <li>Sometimes we can increase compute (e.g. recomputation) or increase communication (e.g. ZeRO) to reduce memory usage</li>
         </ul>
-
-        <p>Scaling up training is usually a question of playing with those constituents to keep memory low while not
-            impacting performance too much. We'll neglect the last two contributors as there's usually not that much you
-            can do about them unless you dive deep in the code.</p>
-
-        <p>For the rest, they are usually different types of tensors that can have various sizes (usually multiples of
-            one or several of batch size, sequence length, model hidden dimension and some potential sharding) and
-            various precisions (with optimizer states and weights copy being often kept in full FP32 precision while
-            activations can be of lower precision like BF16 or FP8). Let's try to get some intuition for the memory
-            requirement of these various elements.</p>
-
-        <p>Let's first look at the weights, gradients and optimizer states. They are all dependent on the number of
-            parameters in a model. For a simple LLM the number of parameters is given by the following formula:</p>
-
-        <d-math>
-            N = h*v + L * (12 * h^2 + 13*h) + 2*h
-        </d-math>
-
-        <p>In that equation, <em>h</em> corresponds to the hidden dimension, <em>v</em> to the vocabulary size, and
-            <em>L</em> the number of layers in the model. Note that looking at the equation we can see that the term
-            that will dominate at large model scales is the one with <em>h^2</em> since it's the only term growing
-            quadratically as we scale the models.
-        </p>
-
-        <p>Let's see how the number of parameters translates to memory usage. The memory requirements for the parameters
-            and gradients are the number of parameters multiplied by the number of bytes per parameter. Mixed precision
-            training with BF16 is the default nowadays which requires 2 bytes per parameter. In addition, there are a
-            number of values necessary for the optimizer states: for ADAM it requires the momentum and the variance in
-            FP32, each using 4 bytes, and an additional copy of the model weights in FP32, thus 12 bytes per parameter
-            (ref: <a href="https://arxiv.org/pdf/1910.02054">ZeRO</a>):</p>
-
-        <d-math>
-            m_{params} = 2 * N
-            m_{grad} = 2 * N
-            m_{opt} = (4+4+4) * N
-        </d-math>
-
-        <p>In old-fashioned full precision training both parameters and gradients would require 4 bytes each but the
-            optimizer on the other hand wouldn't need to store an extra full precision copy of the weights:</p>
-
-        <d-math>
-            m_{params} = 4 * N
-            m_{grad} = 4 * N
-            m_{opt} = (4+4) * N
-        </d-math>
-
-        <p>So we can easily see that mixed precision itself doesn't save memory as it just distributes the memory
-            differently across the three components. So by multiplying the number of parameters by 16 (=2+2+12) you can
-            quickly get a sense of how much GPU memory we need for a model:</p>
-        <p>So we can easily see that mixed precision itself doesn't save memory as it just distributes the memory
-            differently across the three components. So by multiplying the number of parameters by 16 (=2+2+12) you can
-            quickly get a sense of how much GPU memory we need for a model:</p>
-
-        <table>
-            <thead>
-                <tr>
-                    <th>Model parameters</th>
-                    <th>Memory requirements</th>
-                </tr>
-            </thead>
-            <tbody>
-                <tr>
-                    <td>1B</td>
-                    <td>16 GB</td>
-                </tr>
-                <tr>
-                    <td>7B</td>
-                    <td>112 GB</td>
-                </tr>
-                <tr>
-                    <td>70B</td>
-                    <td>1120 GB</td>
-                </tr>
-                <tr>
-                    <td>405B</td>
-                    <td>6480 GB</td>
-                </tr>
-            </tbody>
-        </table>
-
-        <p>We can further decrease the memory usage if we choose FP8 training instead of BF16 but it is much less stable
-            and a very active research topic (see <a href="https://x.com/xariusrke/status/1826669126955278401">here</a>)
-            thus we won't go in details here.</p>
-
-        <p>But we are not done yet, we'll also need to store the forward pass activations which are used during the
-            backward pass to compute the gradients. The total memory required for the activations in mixed precision
-            (which contributes the leading factor of 2 below) is given by the following equation:</p>
-
-        <d-math>
-            m_{act} = 2 * L* seq * bs * h * (34 + \frac{5*n_{heads}*seq}{h})
-        </d-math>
-
-        <p>You can follow <a href="https://arxiv.org/pdf/2205.05198">this NVIDIA paper</a> for a complete derivation, it
-            essentially requires you to do some accounting of all the sizes of intermediate activations between each
-            operation. What's interesting here is that the memory is not static for a given model but depends critically
-            on the sequence length. We can use the memory formulas and have a look how the memory usage changes for a
-            model for various sequence lengths:</p>
-
-        <img src="assets/images/image%206.png" alt="Memory Usage Graph 1">
-        <img src="assets/images/image%207.png" alt="Memory Usage Graph 2">
-
-        <p>This graph tells a striking story: for short sequences, activations are almost negligible, but starting at
-            around 2-4k tokens they start to take up a significant amount of memory while parameter, gradient and
-            optimizer state are roughly independent of the sequence length and batch size. For large batch/sequence,
-            activations however become by far the largest memory burden.</p>
-
-        <p>Is there a way to tame this "activation explosion"?</p>
-
-        <p>Good question, reader! I see you're following well and you're lucky as the answer is "Yes"! Let's talk about
-            a technique called <strong>gradient checkpointing</strong> or more frequently <strong>activation
-                recomputation</strong> which can help us cap activation memory footprint and is an essential tool in
-            today's large model training toolbox.</p>
-
-        <h3>Activation recomputation</h3>
-
-        <p>The general idea behind gradient checkpointing is to discard some activations to save memory if we are
-            willing to spend some extra compute to recompute them when needed. Typically we will save activations at
-            some key points in memory and discard the rest and recompute them during the backward pass from the nearest
-            activations:</p>
-
-        <img src="assets/images/IMG_C4260C5C58DC-1.jpeg" alt="Activation Recompute">
-
-        <p>We can select these key activations according to several strategies and modern frameworks usually choose
-            among the following three strategies:</p>
-        <ul>
-            <li><strong>None</strong>: We don't recompute activations during the backward pass and keep all activations
-                in memory. While this is the fastest and thus computationally cheapest option, it also requires the most
-                memory.</li>
-            <li><strong>Full</strong>: The simplest strategy from a conceptual point of view is to checkpoint
-                activations between each Transformer layer. This is usually called the <code>full</code> strategy since
-                it requires a forward pass through each layer essentially adding a full forward pass during the backward
-                pass. This strategy saves the most memory but is the most expensive one in terms of compute. This
-                increases the compute cost by up to 30-40% which is very noticeable.</li>
-            <li><strong>Selective</strong>: In general we can do better than full. The authors of <a
-                    href="https://arxiv.org/pdf/2205.05198">this paper</a> did a detailed analysis studying which
-                activations grow the largest and have the cheapest recomputation cost in terms of FLOPs. Turns out that
-                the attention computations fall in that category, and thus we can usually discard them and focus on
-                checkpointing expensive feedforward computations. Note: for a GPT-3 (175B) model this means 70%
-                activation memory reduction at a 2.7% compute cost.</li>
+        </li>
+        <li><strong>Compute Efficiency</strong><ul>
+        <li>Memory transfer can also decrease compute efficiency.</li>
+        <li>We want our hardware to spend most time computing, so we need to reduce time spent on data transfers or unoptimized kernels.</li>
+        <li>GPUs need sufficient workload (large enough matrices/batch sizes) to maintain high utilization (compute-bound) otherwise they become memory-bound (limited by memory bandwidth).</li>
         </ul>
-
-        <p>Let's see how recomputation strategies can drastically reduce the memory footprint while selective
-            recomputation strikes a nice balance between memory saving and recomputation cost:</p>
-        <p>Let's see how recomputation strategies can drastically reduce the memory footprint while selective
-            recomputation strikes a nice balance between memory saving and recomputation cost:</p>
-
-        <img src="assets/images/image%208.png" alt="Recomputation Strategies">
-
-        <p>Note: Hardware vs Model flops.</p>
-
-        <p>Most frameworks these days use FlashAttention (TODO: see later) which makes the attention computation less
-            memory intensive through kernel fusion, thus most trainings use the <code>full</code> settings.</p>
-
-        <p>We can save some GPU memory with activation recomputation but this only delays by a bit the next bottleneck:
-            as hinted earlier for LLM training there is usually a sweet spot for the GBST and we need to work out the
-            training configuration backward from there. However, you can't choose MBS to be an arbitrary large number on
-            your GPU; at some point you will run out of GPU memory again since you need to store at least some of the
-            activations in memory.</p>
-
-        <p>There is a useful trick to compensate for that: <strong>gradient accumulation</strong> (<em>GradAcc</em>).
-            With gradient accumulation we will split our batch in micro-batch, do forward and backward passes repeatedly
-            on each micro-batch, compute the gradients, and, as the name suggests, sum the gradients step by step before
-            doing a final optimizer step.</p>
-
-        <p>We call the <code>micro batch size</code> (MBS) the batch size for each forward pass on a single node (the
-            number of samples flowing through the model in one forward pass). We'll refer to the overall batch size
-            between each optimizer step as the <code>global batch size</code> (GBS). If we do one optimizer step each 8
-            forward/backward pass, the <code>global batch size</code> will be 8 times the <code>micro batch size</code>.
-        </p>
-
-        <p>What we now call <code>global batch size</code> thus corresponds to what we've called up to now just
-            <code>batch size</code> for simplicity (we now make the terms more precise to avoid ambiguity).
-        </p>
-
-        <p>With gradient accumulation the global batch size can be computed as follows:</p>
-
-        <d-math>
-            BS = GBS=MBS * GradAcc
-        </d-math>
-
-        <p>Gradient accumulation allows us to effectively increase our batch size up to infinity (!) while the memory
-            footprint stays constant. Gradient accumulation is also compatible with activation recomputation for further
-            memory reduction. One drawback however, is that gradient accumulation requires multiple consecutive
-            forward/backward passes per optimization step thereby increasing the compute overhead and slowing down
-            training. No free lunch!</p>
-
-        <img src="assets/images/IMG_DA188FF29F45-1.jpeg" alt="Gradient Accumulation">
-
-        <p>This is actually a bummer since the forward/backward passes for each micro-batch could actually totally be
-            run in parallel. They are independent from each other and the only changing parameter are the input samples.
-        </p>
-
-        <p>Here comes data parallelism to solve exactly this problem! Let's take a look, you say? Okay sure!</p>
-
-        <h3>Data Parallelism</h3>
-
-        <p>The idea behind data parallelism (DP) is to parallelize forward and backward passes across GPUs, passing
-            different batches of data per GPU (or groups of GPUs) to the same model instance. Just like for gradient
-            accumulation, we need to average gradients across instances before we do the optimization step. The GBS
-            equation can then be extended to:</p>
-
-        <d-math>
-            GBS=MBS * GradAcc * DP
-        </d-math>
-
-        <p>This means that we can reduce the number of gradient accumulation steps in favor of data parallel processes
-            which speeds up training. In practice, people will tend to max out the number of data parallel nodes (the DP
-            above) as much as possible as it's inherently parallel versus the sequential Gradient Accumulation. Gradient
-            accumulation is then added only to achieve a target batch size if DP alone is not sufficient. One exception
-            to that is pipeline parallelism which we'll discuss later.</p>
-
-        <img src="assets/images/IMG_A95961668B3F-1.jpeg" alt="Data Parallelism">
-
-        <p>As you can see on the figure above, some gradients can already be gathered and summed (red boxes) even before
-            gradients down the line (red boxes on the left of the current gradient) are still being computed. This
-            significantly speeds up data parallelism. For instance, as soon as the backward pass of the last layer is
-            done (last boxes on the right) those gradients can already be gathered/summed while the backward pass
-            computations move to earlier layers, aka to the left. This lowers the communication/bandwidth pressure to
-            sync gradients of the full model as it can be performed in part in parallel to the computation of said
-            gradients. See <a href="https://siboehm.com/articles/22/data-parallel-training">this article</a> for more
-            information.</p>
-
-        <p>A general recipe to determine an optimal data-parallel setup can be as follows:</p>
-        <ol>
-            <li>Determine the best (global) batch size in tokens to use either by consulting literature or running
-                experiments? This determines the GBST.</li>
-            <li>Select a sequence length for training, again by either consulting literature or running experiments.
-                Generally 2-8k tokens works reliably well.</li>
-            <li>You now know the batch size (GBS=GBST/SeqLen). Find the maximum MBS on a single GPU by increasing the
-                local batch size until you run out of memory. This determines the MBS.</li>
-            <li>Finally, the number of available GPUs corresponds to the potential DP. The ratio of GPT to DP determines
-                the remaining number of gradient accumulation steps needed for the desired GBS.</li>
-        </ol>
-
-        <p>If the gradient accumulation ratio is lower than one, i.e. you have too many GPUs (!), you can either choose
-            to not use all your GPUs or test if a lower MBS will speed up training. In these cases, you may want to
-            prioritize throughput over the individual GPU utilization, you can then choose DP first and use a smaller
-            MBS than possible in order to speed up training.</p>
-
-        <p>Time to take a concrete example: We want to train a model with a GBS of 4M tokens and a sequence length of
-            4k. This means our batch size will be 1024 samples (we pick powers of two). We observe that a single of our
-            GPU can fit MBS=2 in memory and we have 128 GPUs available for training. This means with 4 gradient
-            accumulation steps we'll achieve our goal of 1024 samples or 4M tokens per training step. Now what if we
-            suddenly have 1024 GPUs available? We can achieve the same GBS and thus identical training by setting both
-            MBS and gradient accumulation to 1 speeding up training significantly.</p>
-
-        <p>[EXPERIMENTS WHERE WE INCREASE DP AND SHOW THROUGHPUT FOR SEVERAL MODELS]</p>
-
-        <p>We've explored data parallelism, a simple strategy to scale training across more GPUs and gives consistent
-            speed improvements. The keen reader might have noticed however that it rests on the assumption that we can
-            fit at least one input sample forward pass (<em>MBS=1</em>) into our GPU memory. This is not always the
-            case! In particular for larger models which often don't fit into a single GPU anymore even with activation
-            recomputations activated.</p>
-
-        <p>In such case, we need to shard the model across devices! We'll now study two complementary sharding methods,
-            tensor and pipeline parallelism which are doing that. Let's start by the simplest, tensor parallelism!</p>
-
-        <h3>Tensor Parallelism</h3>
-
-        <p>So you've exhausted all the previous textbook tricks to try to fit your model on a single GPU but it still
-            doesn't fit? Let's try to distribute this model across several GPUs. Unlike DP we will not simply duplicate
-            the model but various parts of the model instance will be living on various GPUs.</p>
-
-        <p>If we take a look at a typical matrix multiplication (the core of a neural network), we can get an idea about
-            how we could split the model:</p>
-
-        <img src="assets/images/image%209.png" alt="Matrix Multiplication Example">
-
-        <p>Tensor parallelism is a technique in which a tensor is split into N shards along a particular dimension
-            across N GPUs. Matrices can be split either on the column part or row part leading to row and column
-            parallelism. Depending on which splitting strategy we choose will require different communications
-            primitives.</p>
-
-        <p><strong>Column linear:</strong></p>
-        <ul>
-            <li>Splitting by column or row involves different synchronization primitives:
-                <ul>
-                    <li>column:
-                        <ul>
-                            <li>A <strong>Broadcast</strong> operation is used to send the same input to different GPUs,
-                            </li>
-                            <li>Multiplications are done independently on the GPUs, and finally</li>
-                            <li>An <strong>All-gather</strong> operation is used to gather the output results.</li>
-                        </ul>
-                    </li>
-                    <li>Row:
-                        <ul>
-                            <li>A <strong>Scatter</strong> operation is used to split the input and send it to different
-                                GPUs (we split the weight row-wise),</li>
-                            <li>Multiplications are done independently on the GPUs, and finally</li>
-                            <li>An <strong>All-reduce</strong> operation is used to add the results together and the
-                                full output results.</li>
-                        </ul>
-                    </li>
-                </ul>
-            </li>
-        </ul>
-
-        <p>This was for an example matrix multiplication. How do we apply this in practice to a real model? In the
-            Transformer, there are 2 basic building blocks where tensor parallel can be applied:</p>
-        <ul>
-            <li>Feedforward layers (MLP)</li>
-            <li>Multi-Head Attention (MHA)</li>
-        </ul>
-
-        <p>Feedforward layers comprise 2 successive MLPs with a non-linearity in-between. Here is the first part of it:
-        </p>
-
-        <img src="assets/images/image%2012.png" alt="Feedforward Layers">
-
-        <p>Should we use row or column parallelization for the first MLP?</p>
-
-        <p>Well it turns out parallelized GeLU only works in Column schema:</p>
-
-        <p>In column schema:</p>
-        <d-math>
-            GeLU(cat([XW1, XW2])) = cat([GeLU(XW1), GeLU(XW2)])
-        </d-math>
-
-        <p>In row schema:</p>
-        <d-math>
-            GeLU(XW1 + XW2) \neq GeLU(XW1) + GeLU(XW2)
-        </d-math>
-
-        <p>If you rather like code, note that we can prove this with the following snippet as well:</p>
-
-        <d-code block language="python">
-            ```
-            </region_of_file_to_rewritten_file>
-            def example_gelu():
-            from torch.nn.functional import gelu
-
-            X = torch.randn(4, 2, device="cuda", dtype=torch.float32)
-            W = torch.randn(2, 2, device="cuda", dtype=torch.float32)
-
-            W_0, W_1 = W.chunk(2, dim=1)
-
-            # Column linear
-            y_col_1 = torch.cat([gelu(X @ W_0), gelu(X @ W_1)], dim=1)
-            y_col_2 = gelu(torch.cat([X @ W_0, X @ W_1], dim=1))
-
-            # All match
-            torch.testing.assert_close(y_col_1, y_col_2, rtol=1e-5, atol=1e-5)
-
-            # Row linear
-            X_0, X_1 = X.chunk(2, dim=1)
-            W_0, W_1 = W.chunk(2, dim=0)
-            y_row_1 = gelu(X_0 @ W_0) + gelu(X_1 @ W_1)
-            y_row_2 = gelu(X_0 @ W_0 + X_1 @ W_1)
-
-            # Mismatch
-            torch.testing.assert_close(y_row_1, y_row_2, rtol=1e-5, atol=1e-5)
-        </d-code>
-
-        <p>To avoid a synchronization step directly after the first MLP, we'll thus start with Column Parallel and be
-            able to directly perform parallel GELU.</p>
-
-        <p>Now, what about the second MLP? Should it be column or row parallel? Let's draft both options:</p>
-        <ul>
-            <li>Column Parallel followed by Column Parallel</li>
-            <img src="assets/images/image%2013.png" alt="Column Parallel Schema 1">
-            <li>Column Parallel followed by Row Parallel</li>
-            <img src="assets/images/image%2014.png" alt="Column Parallel Schema 2">
+        </li>
+        <li><strong>Communication overhead</strong><ul>
+        <li>Two main types. For GPUs: intra-node (NVLink TODO: bandwidth) and inter-node (network TODO: bandwidth)</li>
+        <li>Two main attributes: base latency and peak bandwidth. Base latency is a constant overhead that makes us want to do the least number of comms possible, and peak bandwidth controls the how fast we can move data between gpus</li>
+        <li>We prioritize using the fastest communication channels (like NVLink) for operations that occur frequently and/or block computation (e.g. tensor parallelism)</li>
+        <li>We want to minimize communication overhead as it keeps GPUs idle, so we try to overlap communication with compute as much as possible</li>
         </ul>
-
-        <p>We see that the "Column Parallel followed by Row Parallel" schema only involves two communications instead of
-            four. It's thus the most efficient schema in terms of communications.</p>
-
-        <p>Let's take a quick look at the backward pass:</p>
-        <img src="assets/images/image%2015.png" alt="Backward Pass 1">
-        <img src="assets/images/image%2016.png" alt="Backward Pass 2">
-
-        <d-code block language="python">
-            def column_linear_forward(X, local_W, group):
-            Y_local = X @ local_W.t()
-            return Y_local
-
-            def column_linear_backward(local_grad_Y, X, local_W, group):
-            local_grad_X = local_grad_Y @ local_W
-            grad_W = local_grad_Y.t() @ X
-            return local_grad_X, grad_W
-
-            def row_linear_forward(local_X, local_W, group):
-            Y_local = local_X @ local_W.t()
-            dist.all_reduce(Y_local, group=group)
-            Y = Y_local
-            return Y
-
-            def row_linear_backward(grad_Y, X, local_W, group):
-            local_grad_X = grad_Y @ local_W
-            grad_W = grad_Y.t() @ X
-            return local_grad_X, grad_W
-
-            def example_column_row_linear():
-            # torchrun --nproc_per_node=2 tp_all_reduce.py
-            group = dist.distributed_c10d._get_default_group()
-
-            X_ref = torch.arange(4 * 2, device="cuda", dtype=torch.float32, requires_grad=True).reshape(4, 2)
-            W_ref_layer1 = torch.arange(1, 5, device="cuda", dtype=torch.float32, requires_grad=True).reshape(2, 2) * 10
-            W_ref_layer2 = torch.arange(1, 5, device="cuda", dtype=torch.float32, requires_grad=True).reshape(2, 2)
-
-            X_ref.retain_grad()
-            W_ref_layer1.retain_grad()
-            W_ref_layer2.retain_grad()
-
-            dist.broadcast(X_ref, src=0, group=group)
-            dist.broadcast(W_ref_layer1, src=0, group=group)
-            dist.broadcast(W_ref_layer2, src=0, group=group)
-
-            X = X_ref.clone()
-            W_layer1 = W_ref_layer1.clone()
-            W_layer2 = W_ref_layer2.clone()
-
-            # Forward
-            Y_ref_linear1 = X_ref @ W_ref_layer1.t()
-            Y_ref_linear1.retain_grad()
-
-            # We will transpose for matrix multiplication. As a result, we need to split row-wise
-            Y_local_linear1 = column_linear_forward(X, split_tensor(W_layer1, dim=0), group)
-
-            torch.testing.assert_close(Y_local_linear1, split_tensor(Y_ref_linear1, dim=1), rtol=1e-5, atol=1e-5)
-
-            Y_local_linear2 = row_linear_forward(Y_local_linear1, split_tensor(W_ref_layer2, dim=1), group)
-            Y_ref_linear2 = Y_ref_linear1 @ W_ref_layer2.t()
-            torch.testing.assert_close(Y_local_linear2, Y_ref_linear2, rtol=1e-5, atol=1e-5)
-
-            # Backward
-            Y_ref_linear2.sum().backward()
-
-            grad_Y = torch.ones_like(Y_ref_linear2)
-            grad_X_linear2, grad_W_linear2 = row_linear_backward(grad_Y, Y_local_linear1, split_tensor(W_layer2, dim=1),
-            group)
-
-            torch.testing.assert_close(grad_X_linear2, split_tensor(Y_ref_linear1.grad, dim=1), rtol=1e-5, atol=1e-5)
-            torch.testing.assert_close(grad_W_linear2, split_tensor(W_ref_layer2.grad, dim=1), rtol=1e-5, atol=1e-5)
-
-            grad_X, grad_W = column_linear_backward(grad_X_linear2, X, split_tensor(W_layer1, dim=0), group)
-
-            torch.testing.assert_close(grad_X, X_ref.grad, rtol=1e-5, atol=1e-5)
-            torch.testing.assert_close(grad_W, split_tensor(W_ref_layer1.grad, dim=0), rtol=1e-5, atol=1e-5)
-
-            if __name__ == "__main__":
-            dist.init_process_group("nccl", rank=int(os.environ["RANK"]), world_size=int(os.environ["WORLD_SIZE"]))
-            torch.cuda.set_device(int(os.environ["LOCAL_RANK"]))
-
-            example_column_row_linear()
-        </d-code>
-
-        <p>Now that we've found the most efficient schema for the Feedforward part of the transformer, let's take a look
-            at the multi-head attention block (MHA).</p>
-
-        <p>We can generally follow a similar approach where the Q, K, V will be split in a Column Parallel fashion and
-            the output projection will be split along the Row dimension.</p>
-
-        <img src="assets/images/image%2017.png" alt="Multi-Head Attention Block">
-
-        <p>To dive in further particularities, a nice reference paper detailing TP is for instance <a
-                href="https://arxiv.org/abs/2205.05198">Megatron-LM: Training Multi-Billion Parameter Language Models
-                Using Model Parallelism</a>.</p>
-
-        <p>Note: Sequence Parallel</p>
-
-        <h3>Sequence Parallelism</h3>
-
-        <p>Tensor parallelism has been a great help to parallelize some of our computation on several GPU nodes with the
-            limited cost of a few communication operations.</p>
-
-        <p>It also had the additional benefit of reducing memory usage by splitting intermediate activations inside the
-            feedforward elements across GPUs and thereby reducing the activations to store on each node.</p>
-
-        <p>Could we push this approach further?</p>
-
-        <p>Sequence parallelism applies this same idea to other parts of our model. We've applied tensor parallelism to
-            two main parts in our models where combination of MLP allowed to naturally split the weights along major
-            axis.</p>
-
-        <p>The rest of the model mostly comprises layer norms, dropout and various summation of residuals, these
-            contribute little to the computation but come with rather large forward activations to store.</p>
-
-        <p>[Add some illustration of the forward activations to store for each part]</p>
-
-        <h3>Context Parallelism</h3>
-
-        <p>Even though TP-SP mode helps reduce the memory used by activation values, it has two main drawbacks:</p>
-        <ol>
-            <li>Internode connections are usually slow, so the TP degree shouldn't typically exceed 8</li>
-            <li>The TP degree is limited by the number of Key/Value heads, which is 8 for LLaMA 3 8B.</li>
-        </ol>
-
-        <p>An empirical estimation is that with TP=8, you can only train an 8B model with a 20K context length. However,
-            LLaMA 3.1 has managed to scale the context length to 128K by using context parallelism.</p>
-
-        <p>There are several ways to implement sequence parallelism. We used ring attention, which overlaps
-            communication and computation. LLaMA3.1 uses all-gather along the sequence dimension because it is easier
-            and more flexible to support different types of attention masks in all-gather based CP attention, such as
-            the document mask.</p>
-
-        <h3>Pipeline Parallelism</h3>
-
-        <h3>Overlapping computation and communication</h3>
-
-        <h3>ZeRO</h3>
-
-        <h2>II – Architecture</h2>
-
-        <h3>Transformers</h3>
-
-        <h3>Choosing the right dimensions</h3>
-
-        <h3>Positional Embeddings (Learned, RoPE, ALiBi)</h3>
-
-        <h3>RoPE</h3>
-
-        <p>In the transformer model, tokens have no inherent information about their positional information. For these
-            reasons, we need to use a positional encoding function.</p>
-
-        <p>Assuming that in the multi-head attention layer, <em>q_m</em> is the "position-aware" query vector
-            corresponding to a token at position <em>m</em>, <em>k_n</em> the "position-aware" key vector corresponding
-            to the token at position <em>n</em> and <em>f</em> is our position embedding function, we would like our
-            position vector to be a function of the input vectors and absolute positions like this:</p>
-
-        <d-math>
-            q_m = f(q,m)
-            k_n = f(k,n)
-        </d-math>
-
-        <p>We may also want the positional encoding to model relative positional information between two input tokens.
-            Relative positions help the model to operate across longer context spans and even context lengths not seen
-            during training. The attention operation is generally a dot product operation between "position-aware"
-            vectors <em>q</em> and <em>k</em>, so for a positional encoding that contains relative positional
-            information, we'll want to have:</p>
-
-        <d-math>
-            <q_m, k_n> = g(q, k, m-n)
-        </d-math>
-
-        <p>In other words, we want the result of <em>⟨ 𝑞_𝑚 , 𝑘_𝑛 ⟩</em> to depend on the values of <em>q</em> and
-            <em>k</em> themselves, as well as their relative position <em>m − n</em>, but not <em>m</em> and <em>n</em>.
-            This way, the model can focus on the relative difference between two tokens rather than their absolute
-            positions.
-        </p>
-
-        <p>Let's show that the RoPE positional embedding formulation satisfies the above formula.</p>
-
-        <p><strong>Rotation matrix</strong></p>
-
-        <p>RoPE are based on rotation matrices which have simple and interesting properties for us. In a 2D space, a
-            rotation matrix has the following form:</p>
-
-        <d-math>
-            R(θ) =
-            \begin{pmatrix}
-            \cosθ & -\sinθ \\
-            \sinθ & \cosθ
-            \end{pmatrix}
-        </d-math>
-
-        <p>The rotation matrix has the following properties:</p>
-        <ul>
-            <li><em>R(θ)</em><sup>T</sup> = <em>R(-θ)</em></li>
-            <li><em>R(θ<sub>1</sub>)R(θ<sub>2</sub>) = R(θ<sub>1</sub>+θ<sub>2</sub>)</li>
-        </ul>
-
-        <img src="assets/images/rotation.jpeg" alt="Rotation Matrix">
-
-        <p><strong>RoPE in 2D space</strong></p>
-
-        <p>Assuming <em>q</em> and <em>k</em> are 2D column vectors, we can show that:</p>
-
-        <d-math>
-            <R(θ_1)q, R(θ_2)k> = (R(θ_1)q)<sup>T</sup> (R(θ_2)k) = q<sup>T</sup>R(-θ_1)R(θ_2)k =
-                q<sup>T</sup>R(θ_2-θ_1)k = (R(θ_1-θ_2)q)<sup>T</sup>k = <R(θ_1-θ_2)q,k>
-        </d-math>
-
-        <p>Therefore, if we define our position embedding like this: <em>f(x, m) = R(mθ)x</em> where <em>R</em> is a 2D
-            rotation matrix, we have <em>q_m = R(mθ)q</em> and <em>k_n = R(nθ)k</em> and then:</p>
-
-        <d-math>
-            <q_m, k_n> = <R(mθ)q, R(nθ)k> = <R((m-n)θ)q, k>
-        </d-math>
-
-        <p>We can see that a multiplication with a rotation matrix is exactly the positional encoding we were looking
-            for. The result of <em>⟨ 𝑞_𝑚 , 𝑘_𝑛 ⟩</em> only depends on <em>q</em>, <em>k</em> and <em>m-n</em>.</p>
-
-        <p><strong>Implementation</strong></p>
-
-        <p>In our case, our internal vectors (the activations in our model) have much more than two elements. Let's pair
-            elements to get 2D vectors and apply the 2D rotation operation on these pairs.</p>
-
-        <p>There are combinatorially many ways we can pair elements but generally two options are the most popular for
-            implementing RoPE: we call them the <em>interleaved</em> and <em>non-interleaved</em> versions. (It's still
-            rather unfortunate to have two popular options)</p>
-
-        <ol>
-            <li>In the interleaved version, we pair consecutive elements <em>(x<sub>0</sub>,
-                    x<sub>1</sub>),(x<sub>2</sub>,x<sub>3</sub>),…</em> before applying the rotation matrix:</li>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0 \\
-                x_1 \\
-                x_2 \\
-                x_3 \\
-                \vdots \\
-                x_{d-2} \\
-                x_{d-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \cos mθ_0 \\
-                \cos mθ_0 \\
-                \cos mθ_1 \\
-                \cos mθ_1 \\
-                \vdots \\
-                \cos mθ_{d/2-1} \\
-                \cos mθ_{d/2-1}
-                \end{pmatrix}
-                +
-                \begin{pmatrix}
-                -x_1 \\
-                x_0 \\
-                -x_3 \\
-                x_2 \\
-                \vdots \\
-                -x_{d-1} \\
-                x_{d-2}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \sin mθ_0 \\
-                \sin mθ_0 \\
-                \sin mθ_1 \\
-                \sin mθ_1 \\
-                \vdots \\
-                \sin mθ_{d/2-1} \\
-                \sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0\cos mθ_0 - x_1\sin mθ_0 \\
-                x_1\cos mθ_0 + x_0\sin mθ_0 \\
-                x_2\cos mθ_1 - x_3\sin mθ_1 \\
-                x_3\cos mθ_1 + x_2\sin mθ_1 \\
-                \vdots \\
-                x_{d-2}\cos mθ_{d/2-1} - x_{d-1}\sin mθ_{d/2-1} \\
-                x_{d-1}\cos mθ_{d/2-1} + x_{d-2}\sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <li>In the non-interleaved version, we split the vector in two to pair elements as follows:
-                <em>(x<sub>0</sub>, x<sub>d/2</sub>),(x<sub>1</sub>,x<sub>d/2+1</sub>),…</em> This is the implementation
-                used in the <code>transformers</code> library:
-            </li>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0 \\
-                x_1 \\
-                \vdots \\
-                x_{d/2-1} \\
-                x_{d/2} \\
-                x_{d/2+1} \\
-                \vdots \\
-                x_{d-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \cos mθ_0 \\
-                \cos mθ_1 \\
-                \vdots \\
-                \cos mθ_{d/2-1} \\
-                \cos mθ_{0} \\
-                \cos mθ_{1} \\
-                \vdots \\
-                \cos mθ_{d/2-1}
-                \end{pmatrix}
-                +
-                \begin{pmatrix}
-                -x_{d/2} \\
-                -x_{d/2+1} \\
-                \vdots \\
-                -x_{d-1} \\
-                x_{0} \\
-                x_{1} \\
-                \vdots \\
-                x_{d/2-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \sin mθ_0 \\
-                \sin mθ_1 \\
-                \vdots \\
-                \sin mθ_{d/2-1} \\
-                \sin mθ_{0} \\
-                \sin mθ_{1} \\
-                \vdots \\
-                \sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0\cos mθ_0 - x_{d/2}\sin mθ_0 \\
-                x_1\cos mθ_1 - x_{d/2+1}\sin mθ_1 \\
-                \vdots \\
-                x_{d/2-1}\cos mθ_{d/2-1} - x_{d-1}\sin mθ_{d/2-1} \\
-                x_{d/2}\cos mθ_0 + x_0\sin mθ_0 \\
-                x_{d/2+1}\cos mθ_1 + x_0\sin mθ_1 \\
-                \vdots \\
-                x_{d-1}\cos mθ_{d/2-1} + x_{d-1}\sin mθ_{d/2-1} \\
-                \end{pmatrix}
-            </d-math>
-            <p>The angle of rotation, <em>θ<sub>i</sub></em> is defined as follows, where <em>d</em> is the dimension of
-                the attention head:</p>
-            <d-math>
-                θ<sub>i</sub> = base<sup>-2(i-1)/d</sup>, i \in [1,2,...,d/2]
-            </d-math>
-            <p>How does this look? When moving the same distance, vectors in some dimensions rotate faster than vectors
-                in other dimensions.</p>
-            <img src="assets/images/rotation_speed.jpeg" alt="Rotation Speed">
+        </li>
         </ol>
+        <p>But let’s not get too much ahead of our self and scale progressively. To guide you along the journey and as a practical reference we summarized the key concepts in a cheatsheet:</p>
+        <p>[TODO: ADD CHEATSHEET]</p>
+        <p>Now that we nailed a few key concept and terms let’s get started by revisiting the basic training steps of an LLM!</p>
+                
+        <h2>First Steps: Training on one GPU</h2>
 
-        <h3>Attention (MHA, MQA, GQA)</h3>
-
-        <h2>Optimized Operations</h2>
-
-        <h3>Flash Attention 1&2&3</h3>
-
-        <h3>Fused Kernels</h3>
-
-        <h2>III – Training Recipe</h2>
-
-        <h3>Batch Size</h3>
-
-        <h3>Initialization + rescaling activations inside the model</h3>
-
-        <h3>Numerical Precision</h3>
-
-        <h4>FP16/BF16/FP8</h4>
-
-        <p>@Phuc Nguyen?</p>
-
-        <h3>Long Context Training</h3>
-
-        <h3>Evaluation</h3>
-
-        <p>@Haojun Zhao</p>
-
-        <h3>Infini-Attention</h3>
-
-        <p>@Phuc Nguyen</p>
-
-        <h3>Ring Attention</h3>
-
-        <p>@Haojun Zhao</p>
-
-        <h3>RoPE scaling / Yarn</h3>
-
-        <p>@Haojun Zhao maybe?</p>
-
-        <h2>References</h2>
-
-        <ul>
-            <li>Harm's posts:
-                <ul>
-                    <li><a
-                            href="https://www.harmdevries.com/post/context-length/">https://www.harmdevries.com/post/context-length/</a>
-                    </li>
-                    <li><a
-                            href="https://www.harmdevries.com/post/model-size-vs-compute-overhead/">https://www.harmdevries.com/post/model-size-vs-compute-overhead/</a>
-                    </li>
-                </ul>
-            </li>
-            <li>Stas' guides:
-                <ul>
-                    <li><a href="https://github.com/stas00/ml-engineering">https://github.com/stas00/ml-engineering</a>
-                    </li>
-                    <li><a
-                            href="https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md">https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md</a>
-                    </li>
-                </ul>
-            </li>
-            <li>data parallel: <a
-                    href="https://siboehm.com/articles/22/data-parallel-training">https://siboehm.com/articles/22/data-parallel-training</a>
-            </li>
-            <li>ZeRO: <a href="https://arxiv.org/abs/1910.02054">https://arxiv.org/abs/1910.02054</a></li>
-            <li>TP/SP + Selective Recomputation: <a
-                    href="https://arxiv.org/abs/2205.05198">https://arxiv.org/abs/2205.05198</a></li>
-        </ul>
-        <h2>Conclusion and looking forward</h2>
-        <p>Through our open science efforts we hope to keep shining a light on the black box that is the training of
-            high performance large language models as well as to give every model trainer the ability to create
-            state-of-the-art LLMs. We are excited to continue iterating on FineWeb and to release increasingly better
-            filtered subsets of web data, in a fully open and reproducible manner.</p>
-        <p>In the short term, we are looking forward to applying the learnings from (English) FineWeb to other
-            languages. While English currently dominates the LLM landscape, we believe that making high quality web data
-            in other languages as accessible as possible would be incredibly impactful.</p>
-        <p>In a nutshell: the future is bright and exciting for studying the science of creating datasets at scale and
-            in the open 🤗.</p>
     </d-article>
 
     <d-appendix>
@@ -1244,16 +238,12 @@
         <h3 id="citation">Citation</h3>
         <p>For attribution in academic contexts, please cite this work as</p>
         <pre
-            class="citation short">Penedo, et al., "The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale", 2024.</pre>
+            class="citation short">XXX, et al., "The Ultra-Scale Playbook: Training LLMs on GPU Clusterse", 2025.</pre>
         <p>BibTeX citation</p>
-        <pre class="citation long">@misc{penedo2024finewebdatasetsdecantingweb,
-      title={The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale},
-      author={Guilherme Penedo and Hynek Kydlíček and Loubna Ben allal and Anton Lozhkov and Margaret Mitchell and Colin Raffel and Leandro Von Werra and Thomas Wolf},
-      year={2024},
-      eprint={2406.17557},
-      archivePrefix={arXiv},
-      primaryClass={cs.CL}
-      url={https://arxiv.org/abs/2406.17557},
+        <pre class="citation long">@misc{TODO,
+      title={The Ultra-Scale Playbook: Training LLMs on GPU Clusters},
+      author={TODO},
+      year={2025},
 }</pre>
     </d-appendix>
 

dist/style.css

@@ -246,6 +246,10 @@ d-article aside {
     margin-bottom: 1em;
 }
 
+d-article img {
+    max-width: 100%;
+}
+
 @media (min-width: 768px) {
     d-article aside {
         margin-bottom: 0;
@@ -257,3 +261,78 @@ d-contents nav > ul > li > a:hover {
     text-decoration: none;
 }
 
+/* memory */
+#controls {
+    display: grid;
+    grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
+    column-gap: 10px;
+    margin-bottom: 20px;
+    max-width: 100%;
+    @supports (container-type: inline-size) {
+        container-type: inline-size;
+    }
+}
+
+#controls .cell {
+    padding: 1px;
+    box-sizing: border-box;
+}
+
+#controls .column-1 {
+    display: flex;
+    align-items: center;
+}
+
+#controls .column-2 {
+    display: flex;
+    align-items: center;
+}
+@supports (container-type: inline-size) {
+    @container (max-width: 600px) {
+        #controls .column-2 {
+            order: 2;
+        }
+    }
+}
+
+#controls label {
+    text-align: right;
+    padding-right: 10px;
+    flex: 0 0 auto;
+    width: 150px;
+    line-height: 1.5em;
+    font-size: 0.8em;
+}
+
+#controls input[type="range"] {
+    width: 50%;
+    margin: 0 10px;
+}
+
+#controls input[type="number"] {
+    flex-shrink: 0;
+    width: 60px;
+    height: 24px;
+    border: 1px solid var(--distill-gray-light);
+    border-radius: 0.2rem;
+}
+
+#controls select {
+    width: 100%;
+    min-height: 28px;
+    border: 1px solid var(--distill-gray-light);
+    border-radius: 0.2rem;
+}
+
+#controls .column {
+    display: contents;
+}
+
+#graph svg {
+    font-family: sans-serif;
+}
+
+#graph svg rect {
+    cursor: pointer;
+}
+

src/bibliography.bib

@@ -331,4 +331,40 @@ url = {https://github.com/meta-llama/llama3/blob/main/MODEL_CARD.md}
       eprint={2212.05129},
       archivePrefix={arXiv},
       primaryClass={cs.AI}
+}
+@misc{kaplan2020scalinglaws,
+      title={Scaling Laws for Neural Language Models}, 
+      author={Jared Kaplan and Sam McCandlish and Tom Henighan and Tom B. Brown and Benjamin Chess and Rewon Child and Scott Gray and Alec Radford and Jeffrey Wu and Dario Amodei},
+      year={2020},
+      eprint={2001.08361},
+      archivePrefix={arXiv},
+      primaryClass={cs.LG},
+      url={https://arxiv.org/abs/2001.08361}, 
+}
+@misc{hoffmann2022chinchilla,
+      title={Training Compute-Optimal Large Language Models}, 
+      author={Jordan Hoffmann and Sebastian Borgeaud and Arthur Mensch and Elena Buchatskaya and Trevor Cai and Eliza Rutherford and Diego de Las Casas and Lisa Anne Hendricks and Johannes Welbl and Aidan Clark and Tom Hennigan and Eric Noland and Katie Millican and George van den Driessche and Bogdan Damoc and Aurelia Guy and Simon Osindero and Karen Simonyan and Erich Elsen and Jack W. Rae and Oriol Vinyals and Laurent Sifre},
+      year={2022},
+      eprint={2203.15556},
+      archivePrefix={arXiv},
+      primaryClass={cs.CL},
+      url={https://arxiv.org/abs/2203.15556}, 
+}
+@misc{grattafiori2024llama3herdmodels,
+      title={The Llama 3 Herd of Models}, 
+      author={Aaron Grattafiori and Abhimanyu Dubey and Abhinav Jauhri and Abhinav Pandey and Abhishek Kadian and Ahmad Al-Dahle and Aiesha Letman and Akhil Mathur and Alan Schelten and Alex Vaughan and Amy Yang and Angela Fan and Anirudh Goyal and Anthony Hartshorn and Aobo Yang and Archi Mitra and Archie Sravankumar and Artem Korenev and Arthur Hinsvark and Arun Rao and Aston Zhang and Aurelien Rodriguez and Austen Gregerson and Ava Spataru and Baptiste Roziere and Bethany Biron and Binh Tang and Bobbie Chern and Charlotte Caucheteux and Chaya Nayak and Chloe Bi and Chris Marra and Chris McConnell and Christian Keller and Christophe Touret and Chunyang Wu and Corinne Wong and Cristian Canton Ferrer and Cyrus Nikolaidis and Damien Allonsius and Daniel Song and Danielle Pintz and Danny Livshits and Danny Wyatt and David Esiobu and Dhruv Choudhary and Dhruv Mahajan and Diego Garcia-Olano and Diego Perino and Dieuwke Hupkes and Egor Lakomkin and Ehab AlBadawy and Elina Lobanova and Emily Dinan and Eric Michael Smith and Filip Radenovic and Francisco Guzmán and Frank Zhang and Gabriel Synnaeve and Gabrielle Lee and Georgia Lewis Anderson and Govind Thattai and Graeme Nail and Gregoire Mialon and Guan Pang and Guillem Cucurell and Hailey Nguyen and Hannah Korevaar and Hu Xu and Hugo Touvron and Iliyan Zarov and Imanol Arrieta Ibarra and Isabel Kloumann and Ishan Misra and Ivan Evtimov and Jack Zhang and Jade Copet and Jaewon Lee and Jan Geffert and Jana Vranes and Jason Park and Jay Mahadeokar and Jeet Shah and Jelmer van der Linde and Jennifer Billock and Jenny Hong and Jenya Lee and Jeremy Fu and Jianfeng Chi and Jianyu Huang and Jiawen Liu and Jie Wang and Jiecao Yu and Joanna Bitton and Joe Spisak and Jongsoo Park and Joseph Rocca and Joshua Johnstun and Joshua Saxe and Junteng Jia and Kalyan Vasuden Alwala and Karthik Prasad and Kartikeya Upasani and Kate Plawiak and Ke Li and Kenneth Heafield and Kevin Stone and Khalid El-Arini and Krithika Iyer and Kshitiz Malik and Kuenley Chiu and Kunal Bhalla and Kushal Lakhotia and Lauren Rantala-Yeary and Laurens van der Maaten and Lawrence Chen and Liang Tan and Liz Jenkins and Louis Martin and Lovish Madaan and Lubo Malo and Lukas Blecher and Lukas Landzaat and Luke de Oliveira and Madeline Muzzi and Mahesh Pasupuleti and Mannat Singh and Manohar Paluri and Marcin Kardas and Maria Tsimpoukelli and Mathew Oldham and Mathieu Rita and Maya Pavlova and Melanie Kambadur and Mike Lewis and Min Si and Mitesh Kumar Singh and Mona Hassan and Naman Goyal and Narjes Torabi and Nikolay Bashlykov and Nikolay Bogoychev and Niladri Chatterji and Ning Zhang and Olivier Duchenne and Onur Çelebi and Patrick Alrassy and Pengchuan Zhang and Pengwei Li and Petar Vasic and Peter Weng and Prajjwal Bhargava and Pratik Dubal and Praveen Krishnan and Punit Singh Koura and Puxin Xu and Qing He and Qingxiao Dong and Ragavan Srinivasan and Raj Ganapathy and Ramon Calderer and Ricardo Silveira Cabral and Robert Stojnic and Roberta Raileanu and Rohan Maheswari and Rohit Girdhar and Rohit Patel and Romain Sauvestre and Ronnie Polidoro and Roshan Sumbaly and Ross Taylor and Ruan Silva and Rui Hou and Rui Wang and Saghar Hosseini and Sahana Chennabasappa and Sanjay Singh and Sean Bell and Seohyun Sonia Kim and Sergey Edunov and Shaoliang Nie and Sharan Narang and Sharath Raparthy and Sheng Shen and Shengye Wan and Shruti Bhosale and Shun Zhang and Simon Vandenhende and Soumya Batra and Spencer Whitman and Sten Sootla and Stephane Collot and Suchin Gururangan and Sydney Borodinsky and Tamar Herman and Tara Fowler and Tarek Sheasha and Thomas Georgiou and Thomas Scialom and Tobias Speckbacher and Todor Mihaylov and Tong Xiao and Ujjwal Karn and Vedanuj Goswami and Vibhor Gupta and Vignesh Ramanathan and Viktor Kerkez and Vincent Gonguet and Virginie Do and Vish Vogeti and Vítor Albiero and Vladan Petrovic and Weiwei Chu and Wenhan Xiong and Wenyin Fu and Whitney Meers and Xavier Martinet and Xiaodong Wang and Xiaofang Wang and Xiaoqing Ellen Tan and Xide Xia and Xinfeng Xie and Xuchao Jia and Xuewei Wang and Yaelle Goldschlag and Yashesh Gaur and Yasmine Babaei and Yi Wen and Yiwen Song and Yuchen Zhang and Yue Li and Yuning Mao and Zacharie Delpierre Coudert and Zheng Yan and Zhengxing Chen and Zoe Papakipos and Aaditya Singh and Aayushi Srivastava and Abha Jain and Adam Kelsey and Adam Shajnfeld and Adithya Gangidi and Adolfo Victoria and Ahuva Goldstand and Ajay Menon and Ajay Sharma and Alex Boesenberg and Alexei Baevski and Allie Feinstein and Amanda Kallet and Amit Sangani and Amos Teo and Anam Yunus and Andrei Lupu and Andres Alvarado and Andrew Caples and Andrew Gu and Andrew Ho and Andrew Poulton and Andrew Ryan and Ankit Ramchandani and Annie Dong and Annie Franco and Anuj Goyal and Aparajita Saraf and Arkabandhu Chowdhury and Ashley Gabriel and Ashwin Bharambe and Assaf Eisenman and Azadeh Yazdan and Beau James and Ben Maurer and Benjamin Leonhardi and Bernie Huang and Beth Loyd and Beto De Paola and Bhargavi Paranjape and Bing Liu and Bo Wu and Boyu Ni and Braden Hancock and Bram Wasti and Brandon Spence and Brani Stojkovic and Brian Gamido and Britt Montalvo and Carl Parker and Carly Burton and Catalina Mejia and Ce Liu and Changhan Wang and Changkyu Kim and Chao Zhou and Chester Hu and Ching-Hsiang Chu and Chris Cai and Chris Tindal and Christoph Feichtenhofer and Cynthia Gao and Damon Civin and Dana Beaty and Daniel Kreymer and Daniel Li and David Adkins and David Xu and Davide Testuggine and Delia David and Devi Parikh and Diana Liskovich and Didem Foss and Dingkang Wang and Duc Le and Dustin Holland and Edward Dowling and Eissa Jamil and Elaine Montgomery and Eleonora Presani and Emily Hahn and Emily Wood and Eric-Tuan Le and Erik Brinkman and Esteban Arcaute and Evan Dunbar and Evan Smothers and Fei Sun and Felix Kreuk and Feng Tian and Filippos Kokkinos and Firat Ozgenel and Francesco Caggioni and Frank Kanayet and Frank Seide and Gabriela Medina Florez and Gabriella Schwarz and Gada Badeer and Georgia Swee and Gil Halpern and Grant Herman and Grigory Sizov and Guangyi and Zhang and Guna Lakshminarayanan and Hakan Inan and Hamid Shojanazeri and Han Zou and Hannah Wang and Hanwen Zha and Haroun Habeeb and Harrison Rudolph and Helen Suk and Henry Aspegren and Hunter Goldman and Hongyuan Zhan and Ibrahim Damlaj and Igor Molybog and Igor Tufanov and Ilias Leontiadis and Irina-Elena Veliche and Itai Gat and Jake Weissman and James Geboski and James Kohli and Janice Lam and Japhet Asher and Jean-Baptiste Gaya and Jeff Marcus and Jeff Tang and Jennifer Chan and Jenny Zhen and Jeremy Reizenstein and Jeremy Teboul and Jessica Zhong and Jian Jin and Jingyi Yang and Joe Cummings and Jon Carvill and Jon Shepard and Jonathan McPhie and Jonathan Torres and Josh Ginsburg and Junjie Wang and Kai Wu and Kam Hou U and Karan Saxena and Kartikay Khandelwal and Katayoun Zand and Kathy Matosich and Kaushik Veeraraghavan and Kelly Michelena and Keqian Li and Kiran Jagadeesh and Kun Huang and Kunal Chawla and Kyle Huang and Lailin Chen and Lakshya Garg and Lavender A and Leandro Silva and Lee Bell and Lei Zhang and Liangpeng Guo and Licheng Yu and Liron Moshkovich and Luca Wehrstedt and Madian Khabsa and Manav Avalani and Manish Bhatt and Martynas Mankus and Matan Hasson and Matthew Lennie and Matthias Reso and Maxim Groshev and Maxim Naumov and Maya Lathi and Meghan Keneally and Miao Liu and Michael L. Seltzer and Michal Valko and Michelle Restrepo and Mihir Patel and Mik Vyatskov and Mikayel Samvelyan and Mike Clark and Mike Macey and Mike Wang and Miquel Jubert Hermoso and Mo Metanat and Mohammad Rastegari and Munish Bansal and Nandhini Santhanam and Natascha Parks and Natasha White and Navyata Bawa and Nayan Singhal and Nick Egebo and Nicolas Usunier and Nikhil Mehta and Nikolay Pavlovich Laptev and Ning Dong and Norman Cheng and Oleg Chernoguz and Olivia Hart and Omkar Salpekar and Ozlem Kalinli and Parkin Kent and Parth Parekh and Paul Saab and Pavan Balaji and Pedro Rittner and Philip Bontrager and Pierre Roux and Piotr Dollar and Polina Zvyagina and Prashant Ratanchandani and Pritish Yuvraj and Qian Liang and Rachad Alao and Rachel Rodriguez and Rafi Ayub and Raghotham Murthy and Raghu Nayani and Rahul Mitra and Rangaprabhu Parthasarathy and Raymond Li and Rebekkah Hogan and Robin Battey and Rocky Wang and Russ Howes and Ruty Rinott and Sachin Mehta and Sachin Siby and Sai Jayesh Bondu and Samyak Datta and Sara Chugh and Sara Hunt and Sargun Dhillon and Sasha Sidorov and Satadru Pan and Saurabh Mahajan and Saurabh Verma and Seiji Yamamoto and Sharadh Ramaswamy and Shaun Lindsay and Shaun Lindsay and Sheng Feng and Shenghao Lin and Shengxin Cindy Zha and Shishir Patil and Shiva Shankar and Shuqiang Zhang and Shuqiang Zhang and Sinong Wang and Sneha Agarwal and Soji Sajuyigbe and Soumith Chintala and Stephanie Max and Stephen Chen and Steve Kehoe and Steve Satterfield and Sudarshan Govindaprasad and Sumit Gupta and Summer Deng and Sungmin Cho and Sunny Virk and Suraj Subramanian and Sy Choudhury and Sydney Goldman and Tal Remez and Tamar Glaser and Tamara Best and Thilo Koehler and Thomas Robinson and Tianhe Li and Tianjun Zhang and Tim Matthews and Timothy Chou and Tzook Shaked and Varun Vontimitta and Victoria Ajayi and Victoria Montanez and Vijai Mohan and Vinay Satish Kumar and Vishal Mangla and Vlad Ionescu and Vlad Poenaru and Vlad Tiberiu Mihailescu and Vladimir Ivanov and Wei Li and Wenchen Wang and Wenwen Jiang and Wes Bouaziz and Will Constable and Xiaocheng Tang and Xiaojian Wu and Xiaolan Wang and Xilun Wu and Xinbo Gao and Yaniv Kleinman and Yanjun Chen and Ye Hu and Ye Jia and Ye Qi and Yenda Li and Yilin Zhang and Ying Zhang and Yossi Adi and Youngjin Nam and Yu and Wang and Yu Zhao and Yuchen Hao and Yundi Qian and Yunlu Li and Yuzi He and Zach Rait and Zachary DeVito and Zef Rosnbrick and Zhaoduo Wen and Zhenyu Yang and Zhiwei Zhao and Zhiyu Ma},
+      year={2024},
+      eprint={2407.21783},
+      archivePrefix={arXiv},
+      primaryClass={cs.AI},
+      url={https://arxiv.org/abs/2407.21783}, 
+}
+@misc{deepseekai2024deepseekv3technicalreport,
+      title={DeepSeek-V3 Technical Report}, 
+      author={DeepSeek-AI and Aixin Liu and Bei Feng and Bing Xue and Bingxuan Wang and Bochao Wu and Chengda Lu and Chenggang Zhao and Chengqi Deng and Chenyu Zhang and Chong Ruan and Damai Dai and Daya Guo and Dejian Yang and Deli Chen and Dongjie Ji and Erhang Li and Fangyun Lin and Fucong Dai and Fuli Luo and Guangbo Hao and Guanting Chen and Guowei Li and H. Zhang and Han Bao and Hanwei Xu and Haocheng Wang and Haowei Zhang and Honghui Ding and Huajian Xin and Huazuo Gao and Hui Li and Hui Qu and J. L. Cai and Jian Liang and Jianzhong Guo and Jiaqi Ni and Jiashi Li and Jiawei Wang and Jin Chen and Jingchang Chen and Jingyang Yuan and Junjie Qiu and Junlong Li and Junxiao Song and Kai Dong and Kai Hu and Kaige Gao and Kang Guan and Kexin Huang and Kuai Yu and Lean Wang and Lecong Zhang and Lei Xu and Leyi Xia and Liang Zhao and Litong Wang and Liyue Zhang and Meng Li and Miaojun Wang and Mingchuan Zhang and Minghua Zhang and Minghui Tang and Mingming Li and Ning Tian and Panpan Huang and Peiyi Wang and Peng Zhang and Qiancheng Wang and Qihao Zhu and Qinyu Chen and Qiushi Du and R. J. Chen and R. L. Jin and Ruiqi Ge and Ruisong Zhang and Ruizhe Pan and Runji Wang and Runxin Xu and Ruoyu Zhang and Ruyi Chen and S. S. Li and Shanghao Lu and Shangyan Zhou and Shanhuang Chen and Shaoqing Wu and Shengfeng Ye and Shengfeng Ye and Shirong Ma and Shiyu Wang and Shuang Zhou and Shuiping Yu and Shunfeng Zhou and Shuting Pan and T. Wang and Tao Yun and Tian Pei and Tianyu Sun and W. L. Xiao and Wangding Zeng and Wanjia Zhao and Wei An and Wen Liu and Wenfeng Liang and Wenjun Gao and Wenqin Yu and Wentao Zhang and X. Q. Li and Xiangyue Jin and Xianzu Wang and Xiao Bi and Xiaodong Liu and Xiaohan Wang and Xiaojin Shen and Xiaokang Chen and Xiaokang Zhang and Xiaosha Chen and Xiaotao Nie and Xiaowen Sun and Xiaoxiang Wang and Xin Cheng and Xin Liu and Xin Xie and Xingchao Liu and Xingkai Yu and Xinnan Song and Xinxia Shan and Xinyi Zhou and Xinyu Yang and Xinyuan Li and Xuecheng Su and Xuheng Lin and Y. K. Li and Y. Q. Wang and Y. X. Wei and Y. X. Zhu and Yang Zhang and Yanhong Xu and Yanhong Xu and Yanping Huang and Yao Li and Yao Zhao and Yaofeng Sun and Yaohui Li and Yaohui Wang and Yi Yu and Yi Zheng and Yichao Zhang and Yifan Shi and Yiliang Xiong and Ying He and Ying Tang and Yishi Piao and Yisong Wang and Yixuan Tan and Yiyang Ma and Yiyuan Liu and Yongqiang Guo and Yu Wu and Yuan Ou and Yuchen Zhu and Yuduan Wang and Yue Gong and Yuheng Zou and Yujia He and Yukun Zha and Yunfan Xiong and Yunxian Ma and Yuting Yan and Yuxiang Luo and Yuxiang You and Yuxuan Liu and Yuyang Zhou and Z. F. Wu and Z. Z. Ren and Zehui Ren and Zhangli Sha and Zhe Fu and Zhean Xu and Zhen Huang and Zhen Zhang and Zhenda Xie and Zhengyan Zhang and Zhewen Hao and Zhibin Gou and Zhicheng Ma and Zhigang Yan and Zhihong Shao and Zhipeng Xu and Zhiyu Wu and Zhongyu Zhang and Zhuoshu Li and Zihui Gu and Zijia Zhu and Zijun Liu and Zilin Li and Ziwei Xie and Ziyang Song and Ziyi Gao and Zizheng Pan},
+      year={2024},
+      eprint={2412.19437},
+      archivePrefix={arXiv},
+      primaryClass={cs.CL},
+      url={https://arxiv.org/abs/2412.19437}, 
 }

src/index.html

@@ -7,15 +7,15 @@
     <meta name="viewport" content="width=device-width, initial-scale=1">
     <meta charset="utf8">
     <base target="_blank">
-    <title>FineWeb: decanting the web for the finest text data at scale</title>
+    <title>The Ultra-Scale Playbook: Training LLMs on GPU Clusters</title>
     <link rel="stylesheet" href="style.css">
 </head>
 
 <body>
     <d-front-matter>
         <script id='distill-front-matter' type="text/json">{
-    "title": "🔭 Ultra-Guide to Scaling LLM training",
-    "description": "This blog covers everything about scaling LLMs in 2024.",
+    "title": "The Ultra-Scale Playbook: Training LLMs on GPU Clusters",
+    "description": "This blog covers everything about scaling LLMs in 2025.",
     "published": "Sept 28, 2024",
     "affiliation": {"name": "HuggingFace"},
     "authors": [
@@ -37,7 +37,7 @@
     </script>
     </d-front-matter>
     <d-title>
-        <h1 class="l-page" style="text-align: center;">🔭 Ultra-Guide to Scaling LLM training</h1>
+        <h1 class="l-page" style="text-align: center;">The Ultra-Scale Playbook: Training LLMs on GPU Clusters</h1>
         <div id="title-plot" class="main-plot-container l-screen">
             <figure>
                 <img src="assets/images/banner.png" alt="FineWeb">
@@ -51,21 +51,22 @@
     <d-article>
         <d-contents>
         </d-contents>
+        
+        <p>Fueled by the scaling laws<d-cite bibtex-key="kaplan2020scalinglaws"></d-cite><d-cite bibtex-key="hoffmann2022chinchilla"></d-cite>, the trend of training ever larger language models on vaster amounts of data has been driving progress in AI for the past couple years. Initially, the development of the largest models happened exclusively behind closed doors of a handful of research labs but recently opened up more with the release of models such as Llama 3.1 405B<d-cite bibtex-key="grattafiori2024llama3herdmodels"></d-cite> and DeepSeek R1<d-cite bibtex-key="deepseekai2024deepseekv3technicalreport"></d-cite>. While these models have <a href="https://huggingface.co/meta-llama">openly shared</a> <a href="https://huggingface.co/deepseek-ai">weights</a> and their training recipes are described in <a href="https://ai.meta.com/research/publications/the-llama-3-herd-of-models/">technical</a> <a href="https://github.com/deepseek-ai/DeepSeek-R1/blob/main/DeepSeek_R1.pdf">reports</a>, the challenging engineering to involved to train at the necessary infrastructure scale is still hidden between the lines of a handful of papers and complex training frameworks. This ~~long blog post~~ open-source book is here to open this black box!</p>
 
-        <p>The performance of a large language model (LLM) depends heavily on the quality and size of the LLMs.
-            However, the pretraining datasets for state-of-the-art open LLMs like Llama 3<d-cite
-                bibtex-key="llama3modelcard"></d-cite> and Mixtral<d-cite bibtex-key="jiang2024mixtral"></d-cite> are
-            not publicly available and very little is known about how they were created.</p>
         <aside>Reading time: 7 days. For the best reading experience, we recommend not using a mobile phone.</aside>
 
-        <p>Recently, we released <a href="https://huggingface.co/datasets/HuggingFaceFW/fineweb"><strong>🍷
-                    FineWeb</strong></a>, a new, large-scale
-            (<strong>15-trillion tokens, 44TB disk space</strong>) dataset for LLM pretraining. FineWeb is derived from
-            96 <a href="https://commoncrawl.org/">CommonCrawl</a> snapshots and produces <strong>better-performing LLMs
-                than other open pretraining datasets</strong>.
+        <p>In this book we invite you to follow us in the wonderful world of scaling training of Large Language Models to tens, hundreds, thousands of GPUs. It assumes you know the basics on LLM architecture and training, but are new to distributed training. This writing can be seen as a second part of a trilogy following our first blog on processing data for pre-training, the so-called “<a href="https://huggingface.co/spaces/HuggingFaceFW/blogpost-fineweb-v1">FineWeb blog post</a>”. Having read both blog posts, you should have almost all the core knowledge needed to deeply understand how LLMs are being built nowadays, just missing a bit the final spices like data mixing or architecture choices to complete the recipe (stay tuned…).</p>
+
+        <p>Pre-training LLMs from scratch now requires amounts of compute which exceed in almost every case the use of a single GPU or machine. The clusters used to train these models range from hundreds to thousands of nodes each usually equipped with 4 to 8 GPUs. To make the best use of such an expensive hardware as well as to train in a reasonable time, a range of distributed training methods have been developed with the goal of ensuring that GPUs are highly utilized at all times. Efficiently scaling LLM training is also not confined to pretraining anymore, as fine-tuning larger models on more domain specific data is becoming the standard practice to achieve the best results.</p>
 
         <aside>We are extremely thankful to the whole <a href="https://distill.pub/">distill.pub</a> team for creating
             the template on which we based this blog post.</aside>
+        
+        <p>In this post we’ll cover these scaling methods exhaustively while keeping a single story-line to understand where each technique comes from. We’ll cover data, tensor, pipeline and context parallelism as well as ZeRO and kernel fusion. The post is built on the following <strong>three foundations</strong>:</p>
+
+        <p><strong>Quick intros on theory and concepts:</strong> before diving into code and experiments, we want to understand how each method works at a high level and what it’s advantages and limits are. You’ll learn about which parts of a language model eat away your memory and when during training it happens. You’ll learn how we can solve memory constraints by parallelizing the models and increase the throughput by scaling up GPUs. As a result you'll understand how the following widget to compute the memory breakdown of a transformer model works: </p>
+
         <div id="graph"></div>
         <div id="controls">
             <div class="cell column-1">
@@ -168,972 +169,50 @@
             </div>
         </div>
 
-        <p><strong>TLDR:</strong> This blog covers a discussion on processing and evaluating data quality at scale, the
-            🍷 FineWeb
-            recipe (listing and explaining all of our design choices), and the process followed to create its 📚
-            FineWeb-Edu subset.</p>
-
-        <h2>Scaling Models and Hardware</h2>
-
-        <p>Now that we know the basics of distributed communication and computations it's time to apply this to training
-            LLMs at scale. Here's the plan of action: we'll go through increasingly complex distribution strategies,
-            namely data, then tensor and finally pipeline parallelism, and show three things:</p>
-
-        <ol>
-            <li>conceptual explanations with diagrams</li>
-            <li>a minimal coding example illustrating how to implement said strategy</li>
-            <li>scaling experiments show casing strengths and limits of the method with real data</li>
-        </ol>
-
-        <p>For the experiments we scale across two dimensions: we make the models larger and larger and add more and
-            more compute nodes and measure how throughput changes.</p>
-
-        <p>So this is a good point to get ☕ #2 and we'll have a look at the setup for the practical experiments.</p>
-
-        <h2>Experiment setup</h2>
-
-        <table>
-            <thead>
-                <tr>
-                    <th></th>
-                    <th><strong>1B (1)</strong></th>
-                    <th><strong>7B</strong></th>
-                    <th><strong>70B</strong></th>
-                    <th><strong>340B (2)</strong></th>
-                    <th><strong>400B (3)</strong></th>
-                </tr>
-            </thead>
-            <tbody>
-                <tr>
-                    <td><strong>N Layers</strong></td>
-                    <td>24</td>
-                    <td>32</td>
-                    <td>80</td>
-                    <td>96</td>
-                    <td>126</td>
-                </tr>
-                <tr>
-                    <td><strong>N Heads</strong></td>
-                    <td>32</td>
-                    <td>32</td>
-                    <td>64</td>
-                    <td>96</td>
-                    <td>128</td>
-                </tr>
-                <tr>
-                    <td><strong>Dimension</strong></td>
-                    <td>2048</td>
-                    <td>4096</td>
-                    <td>8192</td>
-                    <td>18432</td>
-                    <td>16384</td>
-                </tr>
-            </tbody>
-        </table>
-
-        <p>(1) FineWeb ablation models</p>
-        <p>(2) Nemotron-340B architecture (without GQA)</p>
-        <p>(3) Llama-400B, ffn dim = 1.2 hidden dim (without GQA)</p>
-
-
-        <h2>Distribution Methods</h2>
-
-        <p>Efficiently training LLMs now requires amounts of compute which exceed in most case single GPUs or machine.
-            Large distributed clusters are thus used to train these models and can range from hundreds to thousands of
-            nodes each usually equipped with up to 8 GPUs. To make the best use of such an expensive hardware, a range
-            of distributed training methods have been developed with the goal of ensuring that GPUs are highly utilized
-            at all times and not waiting for data/synchronization/etc.</p>
-
-        <p>Several methods can be used to distribute training and we'll start with 4D parallelism followed-up by
-            DeepSpeed stages. While we explain these strategies we'll also run experiments to determine the trade-offs
-            and understand the optimal settings.</p>
-        <p>The name "4D parallelism" originates from the fact that it involves combining up to 4 distribution methods:
-            data, tensor, pipeline, and sequence parallelism (each of these techniques can be used independently of the
-            other). You may thus ask "So which one should I use?".</p>
-
-        <p>Unfortunately, there is no universal answer as the response will actually depend on the cluster setup as well
-            as the model architecture. But do not despair for in this section we'll develop strategies to figure out the
-            best setting experimentally!</p>
-
-        <p>In addition to 4D parallelism we'll also take a look at "DeepSpeed", a method developed by Microsoft which is
-            generally complimentary to 4D parallelism and can be leveraged on top of it.</p>
-
-        <p><strong>Idea: show two things in every section</strong></p>
-        <ol>
-            <li>a small toy model (e.g. 4 layer FFN) we can interactively show with every approach</li>
-            <li>a benchmark showing the improvement/limits of the approach (e.g. when you cross 1 node with TP)</li>
-        </ol>
-
-        <h3>No Parallelism</h3>
-
-        <p>Let's quickly go over the basics before going into distributed training. When a model is trained on a single
-            GPU, the training consists of 3 steps in the simplest case:</p>
-        <ol>
-            <li>one forward pass,</li>
-            <li>one backward pass to compute the gradients, and</li>
-            <li>an optimization step using the gradients to update the parameters</li>
-        </ol>
-
-        <p>As we'll see in the future, these steps may be repeated or intertwined but for now we'll start simple:</p>
-        <p>As we'll see in the future, these steps may be repeated or intertwined but for now we'll start simple:</p>
-
-        <img src="assets/images/IMG_7537D08D7F41-1.jpeg" alt="Training Steps">
-
-        <p>In this figure the successive blue boxes on the top line can be seen as successive layers inside a model
-            (same for the last line). The red boxes are the associated gradients for each of these layers.</p>
-
-        <p>The batch size (<em>bs</em>) is one of the most important hyper-parameters in machine learning, affecting
-            both model convergence and throughput.</p>
-
-        <p>If the batch size is too small, gradients will tend to be noisy and the model may not be able to converge to
-            optimal performances while a batch size too large can make the convergence of the model slower and waste
-            compute. You can find a nice discussion of this topic in OpenAI's paper on large batch training (<a
-                href="https://arxiv.org/abs/1812.06162">https://arxiv.org/pdf/1812.06162</a>).</p>
-
-        <p>The batch size also affects the throughput: a small batch size will require more optimizer steps to train on
-            a given amount of samples. Optimizer steps are costly (in compute time) and the throughput will thus be
-            lower than when using a larger batch size. On the other hand, larger batches, while leading to higher
-            throughput may suffer from slow convergence in the limits as we've just seen. There is generally an optimal
-            batch size from a convergence/performance point of view (note that the batch size can usually still be
-            changed around the optimal batch size without major impact to the performance of the model).</p>
-
-        <p>Note that in the LLM community, batch sizes are commonly reported in terms of tokens instead of number of
-            samples (BST - Batch Size Tokens) as each token has a label and thus a loss term and can thus be considered
-            individual (although highly correlated) samples.</p>
-
-        <p>A sweet spot for LLM training is usually on the order of 4-20 million tokens per batch (links GPT-3,
-            DeepSeek, Llama). In the simplest case, training on a single machine, the <em>BS</em> and <em>BST</em> can
-            be computed from the model input sequence length as follows:</p>
-
-        <d-math>
-            bst=bs *seq
-        </d-math>
-
-        <p>(note that from here on forward we'll show the formulas for the batch size in number of samples but you can
-            always get its token-unit counterpart by multiplying it with the sequence length)</p>
-
-        <p>And we're now hitting our first scaling problem:</p>
-
-        <blockquote>
-            <p>what if we can't fit the model into GPU memory even with <code>BS=1</code>?</p>
-        </blockquote>
-
-        <p>Good question, reader!</p>
-
-        <p>Let's start by understanding what led to our out-of-memory issue in the first place.</p>
-
-        <h2>A brief overview of memory usage in Transformers</h2>
-
-        <p>To train a neural network model, one needs to store many elements in memory besides the weights themselves.
-            Generally, the memory usage is made up from the following elements:</p>
-        <ul>
-            <li>model weights</li>
-            <li>model gradients</li>
-            <li>optimizer states</li>
-            <li>activations computed during the forward pass and which are needed to compute the backward pass</li>
-            <li>also CUDA Kernels require 1-2GB of GPU memory which you can quickly check yourself by running
-                <code>import torch; torch.ones((1, 1)).to("cuda")</code> and then checking the GPU memory with
-                <code>nvidia-smi</code>
-            </li>
-            <li>lower rest memory usage from buffers, intermediate results and some memory that can't be used due to
-                fragmentation</li>
-        </ul>
-
-        <p>Scaling up training is usually a question of playing with those constituents to keep memory low while not
-            impacting performance too much. We'll neglect the last two contributors as there's usually not that much you
-            can do about them unless you dive deep in the code.</p>
-
-        <p>For the rest, they are usually different types of tensors that can have various sizes (usually multiples of
-            one or several of batch size, sequence length, model hidden dimension and some potential sharding) and
-            various precisions (with optimizer states and weights copy being often kept in full FP32 precision while
-            activations can be of lower precision like BF16 or FP8). Let's try to get some intuition for the memory
-            requirement of these various elements.</p>
-
-        <p>Let's first look at the weights, gradients and optimizer states. They are all dependent on the number of
-            parameters in a model. For a simple LLM the number of parameters is given by the following formula:</p>
-
-        <d-math>
-            N = h*v + L * (12 * h^2 + 13*h) + 2*h
-        </d-math>
-
-        <p>In that equation, <em>h</em> corresponds to the hidden dimension, <em>v</em> to the vocabulary size, and
-            <em>L</em> the number of layers in the model. Note that looking at the equation we can see that the term
-            that will dominate at large model scales is the one with <em>h^2</em> since it's the only term growing
-            quadratically as we scale the models.
-        </p>
-
-        <p>Let's see how the number of parameters translates to memory usage. The memory requirements for the parameters
-            and gradients are the number of parameters multiplied by the number of bytes per parameter. Mixed precision
-            training with BF16 is the default nowadays which requires 2 bytes per parameter. In addition, there are a
-            number of values necessary for the optimizer states: for ADAM it requires the momentum and the variance in
-            FP32, each using 4 bytes, and an additional copy of the model weights in FP32, thus 12 bytes per parameter
-            (ref: <a href="https://arxiv.org/pdf/1910.02054">ZeRO</a>):</p>
-
-        <d-math>
-            m_{params} = 2 * N
-            m_{grad} = 2 * N
-            m_{opt} = (4+4+4) * N
-        </d-math>
-
-        <p>In old-fashioned full precision training both parameters and gradients would require 4 bytes each but the
-            optimizer on the other hand wouldn't need to store an extra full precision copy of the weights:</p>
+        <p>While this widget gives a theoretical breakdown the following tool can be used to predict the memory usage:</p>
+        
+        <p><img alt="image.png" src="assets/images/placeholder.png"/></p>
 
-        <d-math>
-            m_{params} = 4 * N
-            m_{grad} = 4 * N
-            m_{opt} = (4+4) * N
-        </d-math>
+        <p><strong>Clear code implementations:</strong> theory is one thing, but we discover all kinds of edge cases and important details when we implement something. That’s why we link to implementation references where possible. Depending on the case, we’ll use two code references: the <a href="https://github.com/huggingface/picotron">picotron</a> repository is built for education, thus it implements concepts usually in single, self-contained short files. On the other hand, to look at production ready code, we’ll refer to the <a href="https://github.com/huggingface/nanotron">nanotron</a> implementations which is a production training codebase used at Hugging Face.</p>
 
-        <p>So we can easily see that mixed precision itself doesn't save memory as it just distributes the memory
-            differently across the three components. So by multiplying the number of parameters by 16 (=2+2+12) you can
-            quickly get a sense of how much GPU memory we need for a model:</p>
-        <p>So we can easily see that mixed precision itself doesn't save memory as it just distributes the memory
-            differently across the three components. So by multiplying the number of parameters by 16 (=2+2+12) you can
-            quickly get a sense of how much GPU memory we need for a model:</p>
+        <p><img alt="Picotron implements each key concept in a self-contained way, such that the method can be studied separately and in isolation." src="assets/images/placeholder.png" /></p>
 
-        <table>
-            <thead>
-                <tr>
-                    <th>Model parameters</th>
-                    <th>Memory requirements</th>
-                </tr>
-            </thead>
-            <tbody>
-                <tr>
-                    <td>1B</td>
-                    <td>16 GB</td>
-                </tr>
-                <tr>
-                    <td>7B</td>
-                    <td>112 GB</td>
-                </tr>
-                <tr>
-                    <td>70B</td>
-                    <td>1120 GB</td>
-                </tr>
-                <tr>
-                    <td>405B</td>
-                    <td>6480 GB</td>
-                </tr>
-            </tbody>
-        </table>
+        <p><strong>Real training efficiency benchmarks:</strong> Finally, how to <em>actually</em> scale your LLM training depends on your infrastructure, such as the kind of chips, interconnect etc., and we can’t give a single unified recipe. What we will give though is a way to benchmark several setups and it is what we have done on our cluster! We ran over 4100 distributed experiments with up to 512 GPUs to scan many possible distributed training layouts and model sizes. TODO: link to dataset too </p>
 
-        <p>We can further decrease the memory usage if we choose FP8 training instead of BF16 but it is much less stable
-            and a very active research topic (see <a href="https://x.com/xariusrke/status/1826669126955278401">here</a>)
-            thus we won't go in details here.</p>
+        <p><img alt="An overview of the over 4000 experiments across all Llama architectures where each data point corresponds to an experiment launch." src="assets/images/placeholder.png" /></p>
 
-        <p>But we are not done yet, we'll also need to store the forward pass activations which are used during the
-            backward pass to compute the gradients. The total memory required for the activations in mixed precision
-            (which contributes the leading factor of 2 below) is given by the following equation:</p>
+        <p>As you can see, there’s a lot of ground to be covered. Before getting into the trenches of distributed training let’s take a quick high level look on we’ll cover in the post.</p>
 
-        <d-math>
-            m_{act} = 2 * L* seq * bs * h * (34 + \frac{5*n_{heads}*seq}{h})
-        </d-math>
-
-        <p>You can follow <a href="https://arxiv.org/pdf/2205.05198">this NVIDIA paper</a> for a complete derivation, it
-            essentially requires you to do some accounting of all the sizes of intermediate activations between each
-            operation. What's interesting here is that the memory is not static for a given model but depends critically
-            on the sequence length. We can use the memory formulas and have a look how the memory usage changes for a
-            model for various sequence lengths:</p>
-
-        <img src="assets/images/image%206.png" alt="Memory Usage Graph 1">
-        <img src="assets/images/image%207.png" alt="Memory Usage Graph 2">
-
-        <p>This graph tells a striking story: for short sequences, activations are almost negligible, but starting at
-            around 2-4k tokens they start to take up a significant amount of memory while parameter, gradient and
-            optimizer state are roughly independent of the sequence length and batch size. For large batch/sequence,
-            activations however become by far the largest memory burden.</p>
-
-        <p>Is there a way to tame this "activation explosion"?</p>
-
-        <p>Good question, reader! I see you're following well and you're lucky as the answer is "Yes"! Let's talk about
-            a technique called <strong>gradient checkpointing</strong> or more frequently <strong>activation
-                recomputation</strong> which can help us cap activation memory footprint and is an essential tool in
-            today's large model training toolbox.</p>
-
-        <h3>Activation recomputation</h3>
-
-        <p>The general idea behind gradient checkpointing is to discard some activations to save memory if we are
-            willing to spend some extra compute to recompute them when needed. Typically we will save activations at
-            some key points in memory and discard the rest and recompute them during the backward pass from the nearest
-            activations:</p>
-
-        <img src="assets/images/IMG_C4260C5C58DC-1.jpeg" alt="Activation Recompute">
-
-        <p>We can select these key activations according to several strategies and modern frameworks usually choose
-            among the following three strategies:</p>
-        <ul>
-            <li><strong>None</strong>: We don't recompute activations during the backward pass and keep all activations
-                in memory. While this is the fastest and thus computationally cheapest option, it also requires the most
-                memory.</li>
-            <li><strong>Full</strong>: The simplest strategy from a conceptual point of view is to checkpoint
-                activations between each Transformer layer. This is usually called the <code>full</code> strategy since
-                it requires a forward pass through each layer essentially adding a full forward pass during the backward
-                pass. This strategy saves the most memory but is the most expensive one in terms of compute. This
-                increases the compute cost by up to 30-40% which is very noticeable.</li>
-            <li><strong>Selective</strong>: In general we can do better than full. The authors of <a
-                    href="https://arxiv.org/pdf/2205.05198">this paper</a> did a detailed analysis studying which
-                activations grow the largest and have the cheapest recomputation cost in terms of FLOPs. Turns out that
-                the attention computations fall in that category, and thus we can usually discard them and focus on
-                checkpointing expensive feedforward computations. Note: for a GPT-3 (175B) model this means 70%
-                activation memory reduction at a 2.7% compute cost.</li>
-        </ul>
-
-        <p>Let's see how recomputation strategies can drastically reduce the memory footprint while selective
-            recomputation strikes a nice balance between memory saving and recomputation cost:</p>
-        <p>Let's see how recomputation strategies can drastically reduce the memory footprint while selective
-            recomputation strikes a nice balance between memory saving and recomputation cost:</p>
-
-        <img src="assets/images/image%208.png" alt="Recomputation Strategies">
-
-        <p>Note: Hardware vs Model flops.</p>
-
-        <p>Most frameworks these days use FlashAttention (TODO: see later) which makes the attention computation less
-            memory intensive through kernel fusion, thus most trainings use the <code>full</code> settings.</p>
-
-        <p>We can save some GPU memory with activation recomputation but this only delays by a bit the next bottleneck:
-            as hinted earlier for LLM training there is usually a sweet spot for the GBST and we need to work out the
-            training configuration backward from there. However, you can't choose MBS to be an arbitrary large number on
-            your GPU; at some point you will run out of GPU memory again since you need to store at least some of the
-            activations in memory.</p>
-
-        <p>There is a useful trick to compensate for that: <strong>gradient accumulation</strong> (<em>GradAcc</em>).
-            With gradient accumulation we will split our batch in micro-batch, do forward and backward passes repeatedly
-            on each micro-batch, compute the gradients, and, as the name suggests, sum the gradients step by step before
-            doing a final optimizer step.</p>
-
-        <p>We call the <code>micro batch size</code> (MBS) the batch size for each forward pass on a single node (the
-            number of samples flowing through the model in one forward pass). We'll refer to the overall batch size
-            between each optimizer step as the <code>global batch size</code> (GBS). If we do one optimizer step each 8
-            forward/backward pass, the <code>global batch size</code> will be 8 times the <code>micro batch size</code>.
-        </p>
-
-        <p>What we now call <code>global batch size</code> thus corresponds to what we've called up to now just
-            <code>batch size</code> for simplicity (we now make the terms more precise to avoid ambiguity).
-        </p>
-
-        <p>With gradient accumulation the global batch size can be computed as follows:</p>
-
-        <d-math>
-            BS = GBS=MBS * GradAcc
-        </d-math>
-
-        <p>Gradient accumulation allows us to effectively increase our batch size up to infinity (!) while the memory
-            footprint stays constant. Gradient accumulation is also compatible with activation recomputation for further
-            memory reduction. One drawback however, is that gradient accumulation requires multiple consecutive
-            forward/backward passes per optimization step thereby increasing the compute overhead and slowing down
-            training. No free lunch!</p>
-
-        <img src="assets/images/IMG_DA188FF29F45-1.jpeg" alt="Gradient Accumulation">
-
-        <p>This is actually a bummer since the forward/backward passes for each micro-batch could actually totally be
-            run in parallel. They are independent from each other and the only changing parameter are the input samples.
-        </p>
-
-        <p>Here comes data parallelism to solve exactly this problem! Let's take a look, you say? Okay sure!</p>
-
-        <h3>Data Parallelism</h3>
-
-        <p>The idea behind data parallelism (DP) is to parallelize forward and backward passes across GPUs, passing
-            different batches of data per GPU (or groups of GPUs) to the same model instance. Just like for gradient
-            accumulation, we need to average gradients across instances before we do the optimization step. The GBS
-            equation can then be extended to:</p>
-
-        <d-math>
-            GBS=MBS * GradAcc * DP
-        </d-math>
-
-        <p>This means that we can reduce the number of gradient accumulation steps in favor of data parallel processes
-            which speeds up training. In practice, people will tend to max out the number of data parallel nodes (the DP
-            above) as much as possible as it's inherently parallel versus the sequential Gradient Accumulation. Gradient
-            accumulation is then added only to achieve a target batch size if DP alone is not sufficient. One exception
-            to that is pipeline parallelism which we'll discuss later.</p>
-
-        <img src="assets/images/IMG_A95961668B3F-1.jpeg" alt="Data Parallelism">
-
-        <p>As you can see on the figure above, some gradients can already be gathered and summed (red boxes) even before
-            gradients down the line (red boxes on the left of the current gradient) are still being computed. This
-            significantly speeds up data parallelism. For instance, as soon as the backward pass of the last layer is
-            done (last boxes on the right) those gradients can already be gathered/summed while the backward pass
-            computations move to earlier layers, aka to the left. This lowers the communication/bandwidth pressure to
-            sync gradients of the full model as it can be performed in part in parallel to the computation of said
-            gradients. See <a href="https://siboehm.com/articles/22/data-parallel-training">this article</a> for more
-            information.</p>
-
-        <p>A general recipe to determine an optimal data-parallel setup can be as follows:</p>
+        <h2>TL;DR</h2>
+        <p>This book is very extensive so we decide to start with a very general overview of how you can think about distributed training. At a high level, the key challenge in scaling LLM training is to make a training step (forward/backward/optimizer step) with a large batch size the fastest possible.</p>
+        <p>When scaling up models and input batches, we quickly end up in situations where either our target batch size won't fit in memory, or/and the model itself is too large to fit in a single GPU's memory.</p>
+        <p>To solve this scaling issue we’ll need to carefully evaluate different parallelization strategies and find the optimal balance between three main factors:</p>
         <ol>
-            <li>Determine the best (global) batch size in tokens to use either by consulting literature or running
-                experiments? This determines the GBST.</li>
-            <li>Select a sequence length for training, again by either consulting literature or running experiments.
-                Generally 2-8k tokens works reliably well.</li>
-            <li>You now know the batch size (GBS=GBST/SeqLen). Find the maximum MBS on a single GPU by increasing the
-                local batch size until you run out of memory. This determines the MBS.</li>
-            <li>Finally, the number of available GPUs corresponds to the potential DP. The ratio of GPT to DP determines
-                the remaining number of gradient accumulation steps needed for the desired GBS.</li>
-        </ol>
-
-        <p>If the gradient accumulation ratio is lower than one, i.e. you have too many GPUs (!), you can either choose
-            to not use all your GPUs or test if a lower MBS will speed up training. In these cases, you may want to
-            prioritize throughput over the individual GPU utilization, you can then choose DP first and use a smaller
-            MBS than possible in order to speed up training.</p>
-
-        <p>Time to take a concrete example: We want to train a model with a GBS of 4M tokens and a sequence length of
-            4k. This means our batch size will be 1024 samples (we pick powers of two). We observe that a single of our
-            GPU can fit MBS=2 in memory and we have 128 GPUs available for training. This means with 4 gradient
-            accumulation steps we'll achieve our goal of 1024 samples or 4M tokens per training step. Now what if we
-            suddenly have 1024 GPUs available? We can achieve the same GBS and thus identical training by setting both
-            MBS and gradient accumulation to 1 speeding up training significantly.</p>
-
-        <p>[EXPERIMENTS WHERE WE INCREASE DP AND SHOW THROUGHPUT FOR SEVERAL MODELS]</p>
-
-        <p>We've explored data parallelism, a simple strategy to scale training across more GPUs and gives consistent
-            speed improvements. The keen reader might have noticed however that it rests on the assumption that we can
-            fit at least one input sample forward pass (<em>MBS=1</em>) into our GPU memory. This is not always the
-            case! In particular for larger models which often don't fit into a single GPU anymore even with activation
-            recomputations activated.</p>
-
-        <p>In such case, we need to shard the model across devices! We'll now study two complementary sharding methods,
-            tensor and pipeline parallelism which are doing that. Let's start by the simplest, tensor parallelism!</p>
-
-        <h3>Tensor Parallelism</h3>
-
-        <p>So you've exhausted all the previous textbook tricks to try to fit your model on a single GPU but it still
-            doesn't fit? Let's try to distribute this model across several GPUs. Unlike DP we will not simply duplicate
-            the model but various parts of the model instance will be living on various GPUs.</p>
-
-        <p>If we take a look at a typical matrix multiplication (the core of a neural network), we can get an idea about
-            how we could split the model:</p>
-
-        <img src="assets/images/image%209.png" alt="Matrix Multiplication Example">
-
-        <p>Tensor parallelism is a technique in which a tensor is split into N shards along a particular dimension
-            across N GPUs. Matrices can be split either on the column part or row part leading to row and column
-            parallelism. Depending on which splitting strategy we choose will require different communications
-            primitives.</p>
-
-        <p><strong>Column linear:</strong></p>
-        <ul>
-            <li>Splitting by column or row involves different synchronization primitives:
-                <ul>
-                    <li>column:
-                        <ul>
-                            <li>A <strong>Broadcast</strong> operation is used to send the same input to different GPUs,
-                            </li>
-                            <li>Multiplications are done independently on the GPUs, and finally</li>
-                            <li>An <strong>All-gather</strong> operation is used to gather the output results.</li>
-                        </ul>
-                    </li>
-                    <li>Row:
-                        <ul>
-                            <li>A <strong>Scatter</strong> operation is used to split the input and send it to different
-                                GPUs (we split the weight row-wise),</li>
-                            <li>Multiplications are done independently on the GPUs, and finally</li>
-                            <li>An <strong>All-reduce</strong> operation is used to add the results together and the
-                                full output results.</li>
-                        </ul>
-                    </li>
-                </ul>
-            </li>
-        </ul>
-
-        <p>This was for an example matrix multiplication. How do we apply this in practice to a real model? In the
-            Transformer, there are 2 basic building blocks where tensor parallel can be applied:</p>
-        <ul>
-            <li>Feedforward layers (MLP)</li>
-            <li>Multi-Head Attention (MHA)</li>
+        <li><strong>Memory Usage</strong><ul>
+        <li>Hard limitation - if a training step doesn't fit in memory, training cannot proceed</li>
+        <li>Sometimes we can increase compute (e.g. recomputation) or increase communication (e.g. ZeRO) to reduce memory usage</li>
         </ul>
-
-        <p>Feedforward layers comprise 2 successive MLPs with a non-linearity in-between. Here is the first part of it:
-        </p>
-
-        <img src="assets/images/image%2012.png" alt="Feedforward Layers">
-
-        <p>Should we use row or column parallelization for the first MLP?</p>
-
-        <p>Well it turns out parallelized GeLU only works in Column schema:</p>
-
-        <p>In column schema:</p>
-        <d-math>
-            GeLU(cat([XW1, XW2])) = cat([GeLU(XW1), GeLU(XW2)])
-        </d-math>
-
-        <p>In row schema:</p>
-        <d-math>
-            GeLU(XW1 + XW2) \neq GeLU(XW1) + GeLU(XW2)
-        </d-math>
-
-        <p>If you rather like code, note that we can prove this with the following snippet as well:</p>
-
-        <d-code block language="python">
-            ```
-            </region_of_file_to_rewritten_file>
-            def example_gelu():
-            from torch.nn.functional import gelu
-
-            X = torch.randn(4, 2, device="cuda", dtype=torch.float32)
-            W = torch.randn(2, 2, device="cuda", dtype=torch.float32)
-
-            W_0, W_1 = W.chunk(2, dim=1)
-
-            # Column linear
-            y_col_1 = torch.cat([gelu(X @ W_0), gelu(X @ W_1)], dim=1)
-            y_col_2 = gelu(torch.cat([X @ W_0, X @ W_1], dim=1))
-
-            # All match
-            torch.testing.assert_close(y_col_1, y_col_2, rtol=1e-5, atol=1e-5)
-
-            # Row linear
-            X_0, X_1 = X.chunk(2, dim=1)
-            W_0, W_1 = W.chunk(2, dim=0)
-            y_row_1 = gelu(X_0 @ W_0) + gelu(X_1 @ W_1)
-            y_row_2 = gelu(X_0 @ W_0 + X_1 @ W_1)
-
-            # Mismatch
-            torch.testing.assert_close(y_row_1, y_row_2, rtol=1e-5, atol=1e-5)
-        </d-code>
-
-        <p>To avoid a synchronization step directly after the first MLP, we'll thus start with Column Parallel and be
-            able to directly perform parallel GELU.</p>
-
-        <p>Now, what about the second MLP? Should it be column or row parallel? Let's draft both options:</p>
-        <ul>
-            <li>Column Parallel followed by Column Parallel</li>
-            <img src="assets/images/image%2013.png" alt="Column Parallel Schema 1">
-            <li>Column Parallel followed by Row Parallel</li>
-            <img src="assets/images/image%2014.png" alt="Column Parallel Schema 2">
+        </li>
+        <li><strong>Compute Efficiency</strong><ul>
+        <li>Memory transfer can also decrease compute efficiency.</li>
+        <li>We want our hardware to spend most time computing, so we need to reduce time spent on data transfers or unoptimized kernels.</li>
+        <li>GPUs need sufficient workload (large enough matrices/batch sizes) to maintain high utilization (compute-bound) otherwise they become memory-bound (limited by memory bandwidth).</li>
         </ul>
-
-        <p>We see that the "Column Parallel followed by Row Parallel" schema only involves two communications instead of
-            four. It's thus the most efficient schema in terms of communications.</p>
-
-        <p>Let's take a quick look at the backward pass:</p>
-        <img src="assets/images/image%2015.png" alt="Backward Pass 1">
-        <img src="assets/images/image%2016.png" alt="Backward Pass 2">
-
-        <d-code block language="python">
-            def column_linear_forward(X, local_W, group):
-            Y_local = X @ local_W.t()
-            return Y_local
-
-            def column_linear_backward(local_grad_Y, X, local_W, group):
-            local_grad_X = local_grad_Y @ local_W
-            grad_W = local_grad_Y.t() @ X
-            return local_grad_X, grad_W
-
-            def row_linear_forward(local_X, local_W, group):
-            Y_local = local_X @ local_W.t()
-            dist.all_reduce(Y_local, group=group)
-            Y = Y_local
-            return Y
-
-            def row_linear_backward(grad_Y, X, local_W, group):
-            local_grad_X = grad_Y @ local_W
-            grad_W = grad_Y.t() @ X
-            return local_grad_X, grad_W
-
-            def example_column_row_linear():
-            # torchrun --nproc_per_node=2 tp_all_reduce.py
-            group = dist.distributed_c10d._get_default_group()
-
-            X_ref = torch.arange(4 * 2, device="cuda", dtype=torch.float32, requires_grad=True).reshape(4, 2)
-            W_ref_layer1 = torch.arange(1, 5, device="cuda", dtype=torch.float32, requires_grad=True).reshape(2, 2) * 10
-            W_ref_layer2 = torch.arange(1, 5, device="cuda", dtype=torch.float32, requires_grad=True).reshape(2, 2)
-
-            X_ref.retain_grad()
-            W_ref_layer1.retain_grad()
-            W_ref_layer2.retain_grad()
-
-            dist.broadcast(X_ref, src=0, group=group)
-            dist.broadcast(W_ref_layer1, src=0, group=group)
-            dist.broadcast(W_ref_layer2, src=0, group=group)
-
-            X = X_ref.clone()
-            W_layer1 = W_ref_layer1.clone()
-            W_layer2 = W_ref_layer2.clone()
-
-            # Forward
-            Y_ref_linear1 = X_ref @ W_ref_layer1.t()
-            Y_ref_linear1.retain_grad()
-
-            # We will transpose for matrix multiplication. As a result, we need to split row-wise
-            Y_local_linear1 = column_linear_forward(X, split_tensor(W_layer1, dim=0), group)
-
-            torch.testing.assert_close(Y_local_linear1, split_tensor(Y_ref_linear1, dim=1), rtol=1e-5, atol=1e-5)
-
-            Y_local_linear2 = row_linear_forward(Y_local_linear1, split_tensor(W_ref_layer2, dim=1), group)
-            Y_ref_linear2 = Y_ref_linear1 @ W_ref_layer2.t()
-            torch.testing.assert_close(Y_local_linear2, Y_ref_linear2, rtol=1e-5, atol=1e-5)
-
-            # Backward
-            Y_ref_linear2.sum().backward()
-
-            grad_Y = torch.ones_like(Y_ref_linear2)
-            grad_X_linear2, grad_W_linear2 = row_linear_backward(grad_Y, Y_local_linear1, split_tensor(W_layer2, dim=1),
-            group)
-
-            torch.testing.assert_close(grad_X_linear2, split_tensor(Y_ref_linear1.grad, dim=1), rtol=1e-5, atol=1e-5)
-            torch.testing.assert_close(grad_W_linear2, split_tensor(W_ref_layer2.grad, dim=1), rtol=1e-5, atol=1e-5)
-
-            grad_X, grad_W = column_linear_backward(grad_X_linear2, X, split_tensor(W_layer1, dim=0), group)
-
-            torch.testing.assert_close(grad_X, X_ref.grad, rtol=1e-5, atol=1e-5)
-            torch.testing.assert_close(grad_W, split_tensor(W_ref_layer1.grad, dim=0), rtol=1e-5, atol=1e-5)
-
-            if __name__ == "__main__":
-            dist.init_process_group("nccl", rank=int(os.environ["RANK"]), world_size=int(os.environ["WORLD_SIZE"]))
-            torch.cuda.set_device(int(os.environ["LOCAL_RANK"]))
-
-            example_column_row_linear()
-        </d-code>
-
-        <p>Now that we've found the most efficient schema for the Feedforward part of the transformer, let's take a look
-            at the multi-head attention block (MHA).</p>
-
-        <p>We can generally follow a similar approach where the Q, K, V will be split in a Column Parallel fashion and
-            the output projection will be split along the Row dimension.</p>
-
-        <img src="assets/images/image%2017.png" alt="Multi-Head Attention Block">
-
-        <p>To dive in further particularities, a nice reference paper detailing TP is for instance <a
-                href="https://arxiv.org/abs/2205.05198">Megatron-LM: Training Multi-Billion Parameter Language Models
-                Using Model Parallelism</a>.</p>
-
-        <p>Note: Sequence Parallel</p>
-
-        <h3>Sequence Parallelism</h3>
-
-        <p>Tensor parallelism has been a great help to parallelize some of our computation on several GPU nodes with the
-            limited cost of a few communication operations.</p>
-
-        <p>It also had the additional benefit of reducing memory usage by splitting intermediate activations inside the
-            feedforward elements across GPUs and thereby reducing the activations to store on each node.</p>
-
-        <p>Could we push this approach further?</p>
-
-        <p>Sequence parallelism applies this same idea to other parts of our model. We've applied tensor parallelism to
-            two main parts in our models where combination of MLP allowed to naturally split the weights along major
-            axis.</p>
-
-        <p>The rest of the model mostly comprises layer norms, dropout and various summation of residuals, these
-            contribute little to the computation but come with rather large forward activations to store.</p>
-
-        <p>[Add some illustration of the forward activations to store for each part]</p>
-
-        <h3>Context Parallelism</h3>
-
-        <p>Even though TP-SP mode helps reduce the memory used by activation values, it has two main drawbacks:</p>
-        <ol>
-            <li>Internode connections are usually slow, so the TP degree shouldn't typically exceed 8</li>
-            <li>The TP degree is limited by the number of Key/Value heads, which is 8 for LLaMA 3 8B.</li>
-        </ol>
-
-        <p>An empirical estimation is that with TP=8, you can only train an 8B model with a 20K context length. However,
-            LLaMA 3.1 has managed to scale the context length to 128K by using context parallelism.</p>
-
-        <p>There are several ways to implement sequence parallelism. We used ring attention, which overlaps
-            communication and computation. LLaMA3.1 uses all-gather along the sequence dimension because it is easier
-            and more flexible to support different types of attention masks in all-gather based CP attention, such as
-            the document mask.</p>
-
-        <h3>Pipeline Parallelism</h3>
-
-        <h3>Overlapping computation and communication</h3>
-
-        <h3>ZeRO</h3>
-
-        <h2>II – Architecture</h2>
-
-        <h3>Transformers</h3>
-
-        <h3>Choosing the right dimensions</h3>
-
-        <h3>Positional Embeddings (Learned, RoPE, ALiBi)</h3>
-
-        <h3>RoPE</h3>
-
-        <p>In the transformer model, tokens have no inherent information about their positional information. For these
-            reasons, we need to use a positional encoding function.</p>
-
-        <p>Assuming that in the multi-head attention layer, <em>q_m</em> is the "position-aware" query vector
-            corresponding to a token at position <em>m</em>, <em>k_n</em> the "position-aware" key vector corresponding
-            to the token at position <em>n</em> and <em>f</em> is our position embedding function, we would like our
-            position vector to be a function of the input vectors and absolute positions like this:</p>
-
-        <d-math>
-            q_m = f(q,m)
-            k_n = f(k,n)
-        </d-math>
-
-        <p>We may also want the positional encoding to model relative positional information between two input tokens.
-            Relative positions help the model to operate across longer context spans and even context lengths not seen
-            during training. The attention operation is generally a dot product operation between "position-aware"
-            vectors <em>q</em> and <em>k</em>, so for a positional encoding that contains relative positional
-            information, we'll want to have:</p>
-
-        <d-math>
-            <q_m, k_n> = g(q, k, m-n)
-        </d-math>
-
-        <p>In other words, we want the result of <em>⟨ 𝑞_𝑚 , 𝑘_𝑛 ⟩</em> to depend on the values of <em>q</em> and
-            <em>k</em> themselves, as well as their relative position <em>m − n</em>, but not <em>m</em> and <em>n</em>.
-            This way, the model can focus on the relative difference between two tokens rather than their absolute
-            positions.
-        </p>
-
-        <p>Let's show that the RoPE positional embedding formulation satisfies the above formula.</p>
-
-        <p><strong>Rotation matrix</strong></p>
-
-        <p>RoPE are based on rotation matrices which have simple and interesting properties for us. In a 2D space, a
-            rotation matrix has the following form:</p>
-
-        <d-math>
-            R(θ) =
-            \begin{pmatrix}
-            \cosθ & -\sinθ \\
-            \sinθ & \cosθ
-            \end{pmatrix}
-        </d-math>
-
-        <p>The rotation matrix has the following properties:</p>
-        <ul>
-            <li><em>R(θ)</em><sup>T</sup> = <em>R(-θ)</em></li>
-            <li><em>R(θ<sub>1</sub>)R(θ<sub>2</sub>) = R(θ<sub>1</sub>+θ<sub>2</sub>)</li>
+        </li>
+        <li><strong>Communication overhead</strong><ul>
+        <li>Two main types. For GPUs: intra-node (NVLink TODO: bandwidth) and inter-node (network TODO: bandwidth)</li>
+        <li>Two main attributes: base latency and peak bandwidth. Base latency is a constant overhead that makes us want to do the least number of comms possible, and peak bandwidth controls the how fast we can move data between gpus</li>
+        <li>We prioritize using the fastest communication channels (like NVLink) for operations that occur frequently and/or block computation (e.g. tensor parallelism)</li>
+        <li>We want to minimize communication overhead as it keeps GPUs idle, so we try to overlap communication with compute as much as possible</li>
         </ul>
-
-        <img src="assets/images/rotation.jpeg" alt="Rotation Matrix">
-
-        <p><strong>RoPE in 2D space</strong></p>
-
-        <p>Assuming <em>q</em> and <em>k</em> are 2D column vectors, we can show that:</p>
-
-        <d-math>
-            <R(θ_1)q, R(θ_2)k> = (R(θ_1)q)<sup>T</sup> (R(θ_2)k) = q<sup>T</sup>R(-θ_1)R(θ_2)k =
-                q<sup>T</sup>R(θ_2-θ_1)k = (R(θ_1-θ_2)q)<sup>T</sup>k = <R(θ_1-θ_2)q,k>
-        </d-math>
-
-        <p>Therefore, if we define our position embedding like this: <em>f(x, m) = R(mθ)x</em> where <em>R</em> is a 2D
-            rotation matrix, we have <em>q_m = R(mθ)q</em> and <em>k_n = R(nθ)k</em> and then:</p>
-
-        <d-math>
-            <q_m, k_n> = <R(mθ)q, R(nθ)k> = <R((m-n)θ)q, k>
-        </d-math>
-
-        <p>We can see that a multiplication with a rotation matrix is exactly the positional encoding we were looking
-            for. The result of <em>⟨ 𝑞_𝑚 , 𝑘_𝑛 ⟩</em> only depends on <em>q</em>, <em>k</em> and <em>m-n</em>.</p>
-
-        <p><strong>Implementation</strong></p>
-
-        <p>In our case, our internal vectors (the activations in our model) have much more than two elements. Let's pair
-            elements to get 2D vectors and apply the 2D rotation operation on these pairs.</p>
-
-        <p>There are combinatorially many ways we can pair elements but generally two options are the most popular for
-            implementing RoPE: we call them the <em>interleaved</em> and <em>non-interleaved</em> versions. (It's still
-            rather unfortunate to have two popular options)</p>
-
-        <ol>
-            <li>In the interleaved version, we pair consecutive elements <em>(x<sub>0</sub>,
-                    x<sub>1</sub>),(x<sub>2</sub>,x<sub>3</sub>),…</em> before applying the rotation matrix:</li>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0 \\
-                x_1 \\
-                x_2 \\
-                x_3 \\
-                \vdots \\
-                x_{d-2} \\
-                x_{d-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \cos mθ_0 \\
-                \cos mθ_0 \\
-                \cos mθ_1 \\
-                \cos mθ_1 \\
-                \vdots \\
-                \cos mθ_{d/2-1} \\
-                \cos mθ_{d/2-1}
-                \end{pmatrix}
-                +
-                \begin{pmatrix}
-                -x_1 \\
-                x_0 \\
-                -x_3 \\
-                x_2 \\
-                \vdots \\
-                -x_{d-1} \\
-                x_{d-2}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \sin mθ_0 \\
-                \sin mθ_0 \\
-                \sin mθ_1 \\
-                \sin mθ_1 \\
-                \vdots \\
-                \sin mθ_{d/2-1} \\
-                \sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0\cos mθ_0 - x_1\sin mθ_0 \\
-                x_1\cos mθ_0 + x_0\sin mθ_0 \\
-                x_2\cos mθ_1 - x_3\sin mθ_1 \\
-                x_3\cos mθ_1 + x_2\sin mθ_1 \\
-                \vdots \\
-                x_{d-2}\cos mθ_{d/2-1} - x_{d-1}\sin mθ_{d/2-1} \\
-                x_{d-1}\cos mθ_{d/2-1} + x_{d-2}\sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <li>In the non-interleaved version, we split the vector in two to pair elements as follows:
-                <em>(x<sub>0</sub>, x<sub>d/2</sub>),(x<sub>1</sub>,x<sub>d/2+1</sub>),…</em> This is the implementation
-                used in the <code>transformers</code> library:
-            </li>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0 \\
-                x_1 \\
-                \vdots \\
-                x_{d/2-1} \\
-                x_{d/2} \\
-                x_{d/2+1} \\
-                \vdots \\
-                x_{d-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \cos mθ_0 \\
-                \cos mθ_1 \\
-                \vdots \\
-                \cos mθ_{d/2-1} \\
-                \cos mθ_{0} \\
-                \cos mθ_{1} \\
-                \vdots \\
-                \cos mθ_{d/2-1}
-                \end{pmatrix}
-                +
-                \begin{pmatrix}
-                -x_{d/2} \\
-                -x_{d/2+1} \\
-                \vdots \\
-                -x_{d-1} \\
-                x_{0} \\
-                x_{1} \\
-                \vdots \\
-                x_{d/2-1}
-                \end{pmatrix}
-                \odot
-                \begin{pmatrix}
-                \sin mθ_0 \\
-                \sin mθ_1 \\
-                \vdots \\
-                \sin mθ_{d/2-1} \\
-                \sin mθ_{0} \\
-                \sin mθ_{1} \\
-                \vdots \\
-                \sin mθ_{d/2-1}
-                \end{pmatrix}
-            </d-math>
-            <d-math>
-                R<sup>d</sup>_{θ,m}x=\begin{pmatrix}
-                x_0\cos mθ_0 - x_{d/2}\sin mθ_0 \\
-                x_1\cos mθ_1 - x_{d/2+1}\sin mθ_1 \\
-                \vdots \\
-                x_{d/2-1}\cos mθ_{d/2-1} - x_{d-1}\sin mθ_{d/2-1} \\
-                x_{d/2}\cos mθ_0 + x_0\sin mθ_0 \\
-                x_{d/2+1}\cos mθ_1 + x_0\sin mθ_1 \\
-                \vdots \\
-                x_{d-1}\cos mθ_{d/2-1} + x_{d-1}\sin mθ_{d/2-1} \\
-                \end{pmatrix}
-            </d-math>
-            <p>The angle of rotation, <em>θ<sub>i</sub></em> is defined as follows, where <em>d</em> is the dimension of
-                the attention head:</p>
-            <d-math>
-                θ<sub>i</sub> = base<sup>-2(i-1)/d</sup>, i \in [1,2,...,d/2]
-            </d-math>
-            <p>How does this look? When moving the same distance, vectors in some dimensions rotate faster than vectors
-                in other dimensions.</p>
-            <img src="assets/images/rotation_speed.jpeg" alt="Rotation Speed">
+        </li>
         </ol>
+        <p>But let’s not get too much ahead of our self and scale progressively. To guide you along the journey and as a practical reference we summarized the key concepts in a cheatsheet:</p>
+        <p>[TODO: ADD CHEATSHEET]</p>
+        <p>Now that we nailed a few key concept and terms let’s get started by revisiting the basic training steps of an LLM!</p>
+                
+        <h2>First Steps: Training on one GPU</h2>
 
-        <h3>Attention (MHA, MQA, GQA)</h3>
-
-        <h2>Optimized Operations</h2>
-
-        <h3>Flash Attention 1&2&3</h3>
-
-        <h3>Fused Kernels</h3>
-
-        <h2>III – Training Recipe</h2>
-
-        <h3>Batch Size</h3>
-
-        <h3>Initialization + rescaling activations inside the model</h3>
-
-        <h3>Numerical Precision</h3>
-
-        <h4>FP16/BF16/FP8</h4>
-
-        <p>@Phuc Nguyen?</p>
-
-        <h3>Long Context Training</h3>
-
-        <h3>Evaluation</h3>
-
-        <p>@Haojun Zhao</p>
-
-        <h3>Infini-Attention</h3>
-
-        <p>@Phuc Nguyen</p>
-
-        <h3>Ring Attention</h3>
-
-        <p>@Haojun Zhao</p>
-
-        <h3>RoPE scaling / Yarn</h3>
-
-        <p>@Haojun Zhao maybe?</p>
-
-        <h2>References</h2>
-
-        <ul>
-            <li>Harm's posts:
-                <ul>
-                    <li><a
-                            href="https://www.harmdevries.com/post/context-length/">https://www.harmdevries.com/post/context-length/</a>
-                    </li>
-                    <li><a
-                            href="https://www.harmdevries.com/post/model-size-vs-compute-overhead/">https://www.harmdevries.com/post/model-size-vs-compute-overhead/</a>
-                    </li>
-                </ul>
-            </li>
-            <li>Stas' guides:
-                <ul>
-                    <li><a href="https://github.com/stas00/ml-engineering">https://github.com/stas00/ml-engineering</a>
-                    </li>
-                    <li><a
-                            href="https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md">https://github.com/bigscience-workshop/bigscience/blob/master/train/tr11-176B-ml/chronicles.md</a>
-                    </li>
-                </ul>
-            </li>
-            <li>data parallel: <a
-                    href="https://siboehm.com/articles/22/data-parallel-training">https://siboehm.com/articles/22/data-parallel-training</a>
-            </li>
-            <li>ZeRO: <a href="https://arxiv.org/abs/1910.02054">https://arxiv.org/abs/1910.02054</a></li>
-            <li>TP/SP + Selective Recomputation: <a
-                    href="https://arxiv.org/abs/2205.05198">https://arxiv.org/abs/2205.05198</a></li>
-        </ul>
-        <h2>Conclusion and looking forward</h2>
-        <p>Through our open science efforts we hope to keep shining a light on the black box that is the training of
-            high performance large language models as well as to give every model trainer the ability to create
-            state-of-the-art LLMs. We are excited to continue iterating on FineWeb and to release increasingly better
-            filtered subsets of web data, in a fully open and reproducible manner.</p>
-        <p>In the short term, we are looking forward to applying the learnings from (English) FineWeb to other
-            languages. While English currently dominates the LLM landscape, we believe that making high quality web data
-            in other languages as accessible as possible would be incredibly impactful.</p>
-        <p>In a nutshell: the future is bright and exciting for studying the science of creating datasets at scale and
-            in the open 🤗.</p>
     </d-article>
 
     <d-appendix>
@@ -1159,16 +238,12 @@
         <h3 id="citation">Citation</h3>
         <p>For attribution in academic contexts, please cite this work as</p>
         <pre
-            class="citation short">Penedo, et al., "The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale", 2024.</pre>
+            class="citation short">XXX, et al., "The Ultra-Scale Playbook: Training LLMs on GPU Clusterse", 2025.</pre>
         <p>BibTeX citation</p>
-        <pre class="citation long">@misc{penedo2024finewebdatasetsdecantingweb,
-      title={The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale},
-      author={Guilherme Penedo and Hynek Kydlíček and Loubna Ben allal and Anton Lozhkov and Margaret Mitchell and Colin Raffel and Leandro Von Werra and Thomas Wolf},
-      year={2024},
-      eprint={2406.17557},
-      archivePrefix={arXiv},
-      primaryClass={cs.CL}
-      url={https://arxiv.org/abs/2406.17557},
+        <pre class="citation long">@misc{TODO,
+      title={The Ultra-Scale Playbook: Training LLMs on GPU Clusters},
+      author={TODO},
+      year={2025},
 }</pre>
     </d-appendix>