【LLM 專欄】Deepseek v3 的訓練時間到底合不合理？淺談 LLM Training efficiency
今年台灣過年吵最兇的議題恐怕就是 Deepseek 重創科技股，直接把老黃打出全球前十富豪 XD，台灣的各個媒體也爭相報導，網路上也很多不一樣的討論。
股票的部分不是筆者專業就不發表意見 XD，但很多人說 Deepseek 對於它們的訓練成本說謊，這個議題其實撇除一些偏見，確實是一個企業需要想的問題，如果訓練成本沒有說謊的話是不是一個值得投入的方向。
考量到年後應該很多相關從業者也會被主管問 Deepseek v3 到底有沒有料？公司要不要投入？我們有辦法自己做一個 Deepseek v3 嗎？
筆者這裡就提供我的答案，基於筆者過去訓練大模型的經驗，提供一個分析框架，試圖解決這個問題。
Deepseek 到底宣稱了甚麼？
在判斷 Deepseek 這個數字到底合不合理之前，我們要先正確解讀 Deepseek 宣稱的「只需要不到 600萬美元就可以訓練一個 GPT4o 等級模型」這句話到底是甚麼意思。
這個議題因為太多爭論，很多說法都越傳越奇怪，因此我們就依照 Deepseek v3 論文本體來看 Deepseek 團隊到底宣稱了甚麼。
Deepseek 在論文中把他們的訓練階段分成三個階段: 1. Pre-training 2. Context Extension 3. Post-Training，而其中的 Post-Training 又包含了我們常說的 SFT 跟 RLHF（讓模型變得以對話為主且對齊某種人類價值觀）。
論文中他們先計算了每一個訓練階段在 H800 GPU 上面需要多少 GPU Hours 完成，接下來再以 H800 每小時 2 美元的租用價格換算成美金，最終換算出來是 5.576M 美元，因此宣稱不到 600 萬美元。（如下表）
同時在論文中又說 Deepseek v3 的 chat version 效果跟 GPT-4o 以及 Claude-3.5-Sonnet 相當。
結合這兩者，Deepseek 宣稱了「只需要 2.788K H800 GPU hours，換算 H800 租用費用不到 600萬美元，就可以訓練出 Deepseek v3，效果比肩 GPT-4o 跟 Claude-3.5-Sonnet」
因此如果我們認為 Deepseek 有造假/說謊的嫌疑，就要從這三個方面去打：
- Deepseek 公布的 H800 GPU hours 是假的，根本不足以完成訓練 Deepseek v3。
- 每小時 2 美元不可能租到 H800。
- Deepseek v3 效果根本不如 GPT-4o 或 Claude-3.5-Sonnet。
只要這三個論述有任何一個證明為真，我們就可以大膽說 Deepseek 真的造假。而我們既然想要打假，依照正確的學術研究態度，我們就要做為挑戰者來找出一個證據說明這三個論述其中「至少一個絕對為真」。
這邊筆者會忽略討論第二第三個論述，專注討論訓練的 GPU hours 到底足不足夠。其中第三點 Benchmark score 很好 reproduce，只要等第三方驗證即可，每個人也可以作為用戶上去比較一下 4o 跟 Deepseek v3。而第二點 H800 的租用費用 Deepseek 團隊應該是參照 H100 現在大概就在每小時 2 美元的價格作為參照，也沒多少人認為這有問題，因此也忽略。（說實話筆者認為 2 美元這個價格還真的有爭議，畢竟當你要一次性租 2,400 片 GPU 時，廠商很難不薛你 XD）
常見錯誤解讀：
- Deepseek 不是買了 2,400片 H100 嗎？600 萬美元怎麼樣買到這麼多 GPU？❌實際上這裡 Deepseek 計算的是 GPU hours，再換算成租用 GPU 的價格。這就像是我說 1500 元可以搭計程車從桃園機場到新竹，然後你質疑我說 1500 元根本買不起汽車。
- OpenAI 不是花了 10B 嗎，Deepseek 怎麼可能省這麼多，超過 100 倍？❌實際上 OpenAI 是總共融資金額高達 10B，實際單次模型訓練成本沒有人知道，但一定遠小於這個數字，不然早就倒閉了 XD
- Deepseek v3 哪有 o1 強？能力差多了？❌Deepseek v3 只有 claim 跟 GPT-4o 和 Claude-3.5-Sonnet 效果差不多，並沒有跟 o1 對比。真正跟 o1 相當的是 Deepseek r1，但那又包含了 r1 的 training。（雖然相當於 pretraining ， r1 的訓練是九牛一毛，總共成本大概率還是小於 600 萬美元，但我們還是依照 Deepseek 論文中的原意為主）
Deepseek 宣稱的訓練時長到底夠不夠？
接下來我們來解決最重要的問題，就是Deepseek 公布的 2.788M H800 GPU hours 到底足不足以完成訓練 Deepseek v3。
在評估 Deepseek 公布的 2.788M H800 GPU hours 是否足以完成整個 Deepseek v3 的訓練任務時，我們需要先了解 MFU（Model FLOPS Utilization） 這個指標。
MFU 可以視為「模型在訓練過程中，實際使用到的運算量占理論可用運算量的比例」。以 GPU 為例，當 GPU 的浮點運算理論峰值（理論上可提供的 FLOPS 數值）很高，但在實際運行時，不一定能達到 100% 的使用效率，原因可能包括：
- 記憶體頻寬或 IO 成為瓶頸：資料讀取、寫入與傳輸過程中，硬體無法持續滿載運算單元。
- 模型結構特性：不同的網路結構（如注意力機制、卷積操作、特殊算子）會影響運算排程效率，使 GPU 無法持續被「餵飽」。
- 分散式訓練的溝通開銷：尤其在多 GPU、多機分散式訓練時，節點間參數同步會產生非運算開銷。
簡單來說，MFU 能告訴我們：Deepseek 該批 GPU 在訓練過程中到底有多大比例的時間真正跑滿運算。也就是我們 GPU 的利用效率。在正常情況下，相似的模型、相似的訓練方法，會取得相似的 GPU 利用效率。
那我們如何使用 MFU 來判斷 Deepseek v3的 training GPU Hours 到底合不合理呢？
答：判斷 Deepseek v3 的 training MFU 數字跟正常 LLM 的 training MFU 相比合不合理，如果超出「合理範圍」，那就代表他們宣稱的 training GPU Hours 有問題，類似你開一台最高時速 100 km 的車永遠不可能只用一小時就從紐約開車到LA。
明確了 MFU 的用處後，我們接下來就剩下兩個問題：
- 怎樣的 MFU 是合理的？
- 計算 Deepseek v3 的 MFU 並判斷有在和合理範圍中嗎？
怎麼樣的 MFU 是合理的？
首先我們可以知道，如果 MFU > 100%，那肯定不合理，畢竟 GPU 可沒辦法超頻幫你運算 XD，甚至要達到 100% 都是不可能的，因為老黃在各個 GPU 的 datasheet 上寫的理論 FLOPs 從來沒有辦法真正跑到 XD。
接著我們知道，深度學習的核心運算是矩陣乘法，在整個 GPU 的數值運算中，GEMM 是被優化的最好的幾個，而訓練 LLM 的過程中除了 GEMM 以外還有很多額外低效操作，所以我們訓練的 MFU 永遠不可能超過 GEMM 的 MFU。這個數值大約在 90% 左右，只要 MFU 算出來後超過 90% 也絕對有問題。
剛剛提到 LLM 訓練中有很多額外的低效操作，所以我們也參考其他 LLM 的 training MFU，藉由參考普遍業界的硬體效率來找出一個合理的 MFU 範圍。
- Deepspeed 官方報他們的訓練 MFU 大約可以達到 40~56 %，模型越大 MFU 越高。[1]
- 在 Mosaic 平台上回報的 LLM 訓練 MFU，從模型小到大，包含單卡多卡訓練，普遍坐落在 35%~60% 之間。[2]
- Megatron 官方回報訓練 8x7b Mixtral 達到 47% MFU。[3]
- Skywork 官方回報訓練 Skywork MoE 模型達到 38% MFU。[4]
類似的數據還可以找到很多，不過總結來說 training LLM 大多時候 MFU 會在 35~60% 之間，而 training MoE LLM 通常會低一點，20%~40%都算正常。（推薦大家也可以自己直接單卡、多卡、跨機跑跑看 LLM training 並計算 MFU，感覺一下正常的範圍在哪裡）
因此綜合理論數據跟我們過往訓練 LLM 的經驗數據，我們可以大概得出以下這張圖，在 60% 以下我們都還可以當作安全範圍。
考量到 Deepseek v3 論文上是用 H800 GPU，相較於 H100 傳輸速度只剩一半，所以 MFU 應該會比正常我們用 H100 估出來的還要再低一點，整個軸可能要稍微左移，但我們就先以這個軸為主。設定好一個合理範圍後，我們接著計算 Deepseek v3 的 MFU。
Deepseek v3 的 MFU 是多少？
回顧 MFU 公式，分母「理論峰值 FLOPS」 是被 Nvidia 的官方數字所決定，以 H800 為標準的話，我們參考 H800 的 data sheet，其中以 SXM 為標準的話，BF16 是 1979 TFLOPS，FP8 是 3958 TFLOPS。
但實際上 Nvidia 在 datasheet 上寫的都是 2:4 sparsity 的數字（每 4 個權重中只有 2 個非零，稀疏操作可以讓 GEMM 效率變兩倍），如果我們不是使用 sparse 運算的話都要打對折，因此 BF16 是 989 TFLOPS 而 FP8 是 1979 FLOPS。
這邊我們分母就以 BF16 的 989 TFLOPS 為標準來計算，因為 Deepseek v3 可以跑通 mix precision training 這塊我們也當成他們優化了他們的 pipeline，而且 BF16 的數字較嚴格（因為分母較小，所以 MFU 計算就會更大），同時我們永遠最後都可以再把 MFU 除 2 換算出以 FP8 為主的 MFU。
接下來就是真正麻煩的地方，怎麼計算「實際執行的 FLOPs」？
我們已知從 Deepseek v3 的論文已知他們 pretraining 花了 2,664K GPU hours，同時 pretrain 的時候總共訓練了 14.8T Tokens。
把上面的數字帶入後就變成以下公式，因此我們只要能夠算出訓練 Deepseek v3 的時候每訓練一個 token 需要耗費多少 FLOP，就可以算出精準的 Deepseekv3 training MFU。
如何估算訓練每一 Token 所需耗費的 FLOP
這個問題其實要算精準非常困難，但我們過去在估計 Scaling law 的時候其實 OpenAI 就提供了我們一個很簡單的估算方法。
Overall Training FLOPS = 6ND
N 是模型參數量，D 是 Training dataset 大小（Tokens 數）。而每一個 Token 的 Training FLOPS 則等於 6N 。
這個 6ND 是怎麼來的呢？OpenAI 在最早提出 LLM scaling law [5] 的論文中，先計算了每一個 Token forward pass 所需的 FLOPs（下圖的 C_forward）
而訓練同時要 forward 跟 backward 計算，backward 計算大約是 forward 的兩倍，因此總共 = 3 * C_forward。
同時 OpenAI 發現當我們 context length 不長的時候，C_forward 幾乎等於 2N（也就是說後面那項不重要），因此最後 OpenAI 就提出說我們乾脆用 6N 來估計單個 token 的 training flop。每一個 Token 需要 6N FLOPS 來訓練，而我們總共要訓練 D 的 tokens，因此總共完整訓練就需要 6ND FLOPS。
而後到 Chichilla scaling law [6] 以及大量論文都沿用了 6ND 這個計算方法。
因此筆者這邊從 6ND 根源想要讓大家重視的是， 6ND 這個計算方法其實是在刻意忽略了一些計算後簡化而成的（如下圖）
而筆者主張在計算 Deepseek v3 的 MFU 時，不能直接套用 6ND，因為 Deepseek v3 是一個極稀疏的 MoE LLM，因此 FFN 的影響會顯著減小，而 Attention 的影響會顯著放大，舉例而言 Deepseek v2 中 MLA 跟 MoE 的 training flop 接近 1:1，因此我們其實就不能說 context window 小的時候 Attention 計算 Mask 的那個項目可以省略了，我們需要更精準地估算方法。
前面解釋了 6ND 的起源、計算內容以及侷限，接下來我們其實就有兩個方法可以得到更精準的 Deepseek v3 的 training FLOP：
- 6ND + 補償計算 Attention 部分被忽略的 training FLOPS。
- 3 * 計算 Deepseek v3 的所有 forward 操作。
其中第二個辦法又會更精準，本來這是個大工程，所幸已經有網友提供精準的計算方法 https://zhuanlan.zhihu.com/p/16445683081。（這個計算非常完整且直觀，非常值得細讀，如果有疑惑筆者可以再出另一篇文解讀）
這邊我就直接引用他的結論，經過計算後 Deepseek v3 的 MFU 為 39%。考量到數值誤差後大約就在 35%~45% 這個範圍。（筆者用相似的算法驗算過一輪，數字差不多）
因此從 MFU 的角度來判斷 Deepseek 所宣稱的訓練時間相當合理，資源十分充足，比他們所宣稱數字的 MFU 更高的其實多的是。
Deepseek 這兩年到底做了甚麼優化？
那回過頭來說，為甚麼業內人士很多人還是對 Deepseek v3 的訓練資源感到震驚呢？
我想最主要是因為 Deepseek v3 只花了 2.778M GPU hours 就可以訓練出 671B models，總共學習資料 14.8T tokens，並且效果比肩 GPT-4o，而 Meta 的 LLama-3.1 405B 一樣只訓練 15T tokens 卻需要 30.84M GPU hours，效果還沒有 GPT-4o 好。乍看之下 Deepseek 達到了 10 倍以上的效率優化。
但真的是 10 倍效率優化嗎？
前面筆者討論了從 MFU 的角度直接計算 Deepseek v3 training 所需要的運算資源，接下來筆者更想談的是 Deepseek 是如何從 v1 演化成 v3 的，途中哪些改變帶來最大的 training 效率提升，藉此我們就能看得很清楚所謂的「10 倍效率優化」是多大的誤解。
Deepseek v1
在談 deepseek v1 之前，我們先來看一下 LLaMA-2，作為一個代表性的 milestone，LLaMA-2 也公布了他的 training GPU hours [7]，總共花了 1.72M GPU hours，訓練了總共 2T tokens。
相比之下，Deepseek v1 同樣是 Dense model，大小為 67B，每訓練 1T tokens 需要 300.6K GPU hours。乍看之下好像比 LLaMA-2 的訓練速度快很多（每 1T tokens 的訓練時間大概只需要 1/3）。
但這其實是假象，因為 LLaMA-2 的 GPU hours 是用 A100 來計算的，而 Deepseek v1 則是用 H800 GPU。A100 的 bf16 FLOPS 只有 312 TFLOPS，而 H800 有 989 TFLOPS。也就是說 H800 的計算能力是 A100 的三倍。
如果我們精準計算 MFU 的話就會發現， LLaMA-2 的 MFU 大約是 43.5%，Deepseek v1 的 MFU 只有 37.6%，Deepseek v1 實際上 GPU 硬體利用效率是比 LLaMA-2 還要更差的。
訓練時間可以大幅縮減，只是因為用了計算能力比較強的 H800。（Btw H800 的 MFU 天生應該就會比 A100/H100 低一點，因為 IO 的成本變高了）
因此 Deepseek v1 乍看達到了接近 3 倍的訓練效率優化，但實際上單純只是 GPU 計算能力差異帶來的效果。
Deepseek v2
接下來進到 Deepseek v2 的時代，同時引入了 MoE 跟 MLA 兩個改變，模型變成 236B，每一個 token 會 activate 21B parameters。
並且論文中說這個 236B MoE 模型相比於 67B Dense 模型實際上可以用更少的 GPU hours 來學完 1T tokens。
達成 42.5% 的訓練效率提升。（而且效果還更好）
乍看之下我們可能會想，Deepseek v2 是不是做了甚麼很厲害的硬體優化？怎麼模型更大還訓練更快？
但我們如果認真計算 Deepseek v2 的 MFU，反而會發現 Deepseek v2 的 MFU 僅僅只是 27%，非常低的一個數字，遠低於 Deepseek v1 的 37.6%。
那為甚麼這麼低的 MFU，Deepseek v2 模型又更大，GPU 也同樣都是 H800，Deepseek v2 的學習效率還能比 Deepseek v1 更好呢？
因為 MoE 每次需要計算的參數數量非常少，以 Deepseek v2 而言，每一次只 activate 21B parameters，90%以上的參數都是靜止的不用做任何 forward backward 計算，即便我們把 attention 的部分計算進去，大約也就相當於一個 40B 的 Dense 模型的訓練 FLOPs，相比於 67B 的 Dense 模型所需運算量大幅縮水。（詳細計算方法其實還是攤開整個 forward 運算，在 Deepseek v2 中，MLA 跟 MoE 所需運算量接近 1:1）
因此 Deepseek v2 藉由 MoE 達成了總模型變大，效果變好，訓練還變快的成就。
其實同樣的概念筆者在剛好一年前就有發現並寫一篇文，當時就有談及 Qwen 實驗的一樣的現象。
原本預期 2024 應該所有 LLM 都會轉往 MoE 發展，結果沒想到大家跟進的比想像中還要慢，現在 Deepseek 算是給大家當頭一棒。
解釋了 MoE 帶來的正面影響，我們其實也要注意 MoE 帶來的負面影響，就是 MFU 顯著降低，因為 MoE 的 IO 成本大幅上升（像是 All2All 就很難節省），因此大多時候 MoE LLM 訓練時的 MFU 達到 30% 就算不錯了。
Deepseek v3
Deepseek v3 相對於 v2 其實沒做甚麼架構改變，就是變的更大 671B ，每一個 token 會 activate 37B parameters。
但 Deepseek v3 的 MFU 卻能 v2 的 27% 直接飆漲至 39%，這就是 Deepseek v3 整篇論文中討論的各種 infrastructure 優化帶來的優勢，也包含 mix precision 帶來的效果。
實際 MFU 相比於 Deepseek v2 提升了接近 50%，這是合理但仍然滿厲害的一件事，以 Deepseek 有 2400 片 H800 而言，這相當於每個月幫公司多榨出 1.5M 價值的 GPU。
綜合來看，Deepseek v3 跟 LLaMA-3.1 看起來 10倍的訓練效率差距，其實其中 1/3 是 GPU 差異造成的（A100 vs H800），1/2 是 MoE 帶來的好處，還有少量是因為 Deepseek v3 優化了 infra。其實並沒有想像中那麼不合理。
那企業 2025 要不要 All in 做下一個 Deepseek v3？
簡單來講，不要
這次爭議中很多媒體喜歡拿 OpenAI 的 10B 跟 Deepseek 的 6M 做比較，但這其實是非常混淆的說法。
因為 OpenAI 的 10B 是營運整個公司，可能包含訓練數十上百次模型，而 Deepseek 的 6M 只是單次模型訓練成本。
因此台灣企業如果因為看到 6M 就可以做一個世界級大模型，就想要入局，那就正好中了陷阱。
舉個例子，Google 在 2022/5 推出 Chinchilla Scaling law 之後，Meta 整整花了 8 個月，到 2023/2 才推出 LLaMA-1（LLaMA-1 其實就是在 reproduce Chinchilla 的結果）。其中 LLaMA-1 的 paper 中說他們單次訓練成本其實只需要 21 天，也就是說對於 Meta 而言，單次模型訓練只占他們整個復現過程不到 1/10 的時間。這還是建立在 Meta 已有完整的 AI 研究團隊跟運算資源。
因此如果企業想要 reproduce Deepseek v3，最少最少也是要投入 10x 6M USD，這還是假設每個企業都跟 Meta 有一樣的人才。（但如果有公司真的想做這塊請務必抓我入局 XD）
結語
本篇文章藉由 Deepseek v3 的爭議回頭討論大模型訓練時的一個重要指標 MFU，利用 MFU 來可以判斷我們的硬體效率，更好的去評斷現階段的 infra 跟訓練策略是否有 bug。同時也側面證明 Deepseek v3 的數據其實是合理的。
接受了 Deepseek v3 的數字後，筆者討論 Deepseek v1~v3 到底做了，效率優化的根源主要還是來自 MoE 架構，也期待 2025 年可以看到更多的 MoE 模型出現。
Reference
- https://github.com/microsoft/Megatron-DeepSpeed
- https://github.com/mosaicml/llm-foundry/blob/main/scripts/train/benchmarking/README.md
- https://github.com/NVIDIA/Megatron-LM
- Wei, Tianwen, et al. “Skywork-MoE: A Deep Dive into Training Techniques for Mixture-of-Experts Language Models.” arXiv preprint arXiv:2406.06563 (2024).
- Kaplan, Jared, et al. “Scaling laws for neural language models.” arXiv preprint arXiv:2001.08361 (2020).
- Hoffmann, Jordan, et al. “Training compute-optimal large language models.” arXiv preprint arXiv:2203.15556 (2022).
- https://github.com/meta-llama/llama/blob/main/MODEL_CARD.md
