DeepSeek 的出現是否意味著前沿 LLM 開發不再需要大規模 GPU 叢集？
簡單來說：不是的。雖然 DeepSeek 的 V3 模型透過一些非常厲害的最佳化技術，讓 GPU 的使用效率變得更高了，但這並不意味著像 Google、OpenAI、Meta 和 xAI 這些公司之前花大錢搞的大規模 GPU 叢集就沒用了。AI 開發者的普遍看法是，大規模 GPU 叢集仍然是訓練頂尖 AI 模型的關鍵。
DeepSeek 做了什麼？
DeepSeek 的 V3 模型透過一些“底層魔法”級別的最佳化，把 GPU 的效能榨乾到了極限。
DeepSeek V3是一個低階別的（low level）技術，適用於需要高效能運算的場景。
- 它透過使用GPU來加速處理，特別是對於需要大量平行計算的任務。
DeepSeek在用 NVIDIA的 H800 GPU 訓練 V3 時，對 GPU 的核心計算單元（SM，流多處理器）進行了定製化調整：DeepSeek V3利用了NVIDIA的H800 GPU，該GPU具有132個SM（Streaming Multiprocessor），每個SM有20個SMG（Streaming Multiprocessor Group）。
具體來說，他們把 132 個 SM 中的 20 個專門用來處理伺服器之間的通訊任務，而不是計算任務。
這種調整是在 PTX（並行執行緒執行）級別進行的，PTX 是一種接近組合語言的低階指令集，可以讓開發者對 GPU 進行非常細緻的控制，比如調整暫存器的分配和執行緒的執行方式。
PTX（Parallel Thread Execution）：
- PTX是一種用於GPU的中間表示（IR），它允許開發者編寫可以在不同GPU架構上執行的程式碼。
- PTX程式碼在執行時會被編譯成特定GPU架構的機器碼，從而實現高效的執行。
- DeepSeek V3利用PTX來最佳化程式碼執行，提高效能。
PTX這種級別的最佳化非常複雜，通常大家會用更高階的程式語言（比如 CUDA）來寫 GPU 程式，這樣更容易維護，也能滿足大多數任務的需求。但 DeepSeek 為了把 GPU 的效能用到極限，直接用了 PTX 這種底層工具，這需要超強的工程能力。
CUDA程式設計模型：
- CUDA是一種用於GPU程式設計的框架，它允許開發者使用C/C++等語言編寫GPU程式碼。
- DeepSeek V3也利用CUDA程式設計模型來實現高效的平行計算。
- CUDA程式設計模型允許開發者將任務分解成多個執行緒，這些執行緒可以在GPU的多個核心上並行執行。
GPU資源管理：
- DeepSeek V3透過最佳化GPU資源的使用來提高效能，包括記憶體管理和執行緒排程。
- 它還支援動態調整GPU資源的使用，以適應不同的計算需求。
總的來說，DeepSeek V3是一個高效能的計算框架，它透過利用GPU的平行計算能力和最佳化資源管理來提高計算效率。
DeepSeek V3和它在H800 GPU上自定義SM（Streaming Multiprocessor，流式多處理器）的最佳化過程：
首先，PTX是NVIDIA推出的一種中間程式碼，可以看作是GPU的“高階組合語言”。我們通常寫的CUDA程式碼會被編譯成PTX，然後再轉換成GPU可以直接執行的機器碼（SASS）。直接用PTX程式設計可以讓我們更精細地控制GPU的資源，比如暫存器的使用和執行緒的排程，但這也比用CUDA程式設計要複雜一些。
DeepSeek V3在H800 GPU上做了一些特別的最佳化。H800 GPU有132個SM，DeepSeek V3分配了其中的20個專門用於伺服器之間的通訊任務。這裡的關鍵是，SM通常是用於計算任務的，比如進行大量的數學運算。而DeepSeek V3卻用一部分SM來做通訊任務，這聽起來有點不尋常。
那麼，DeepSeek V3是怎麼做到的呢？
他們透過編寫特定的PTX程式碼來精確控制執行緒如何在SM上分配，這樣可以更有效地管理通訊任務。但是，通常情況下，我們不會在CUDA中明確指定任務執行在哪個SM上，這是由GPU的硬體排程程式來決定的。除非使用一些高階技術，比如MPS（多程序服務）或MIG（多例項GPU），但這通常是在更高層次上進行GPU資源的劃分。
DeepSeek V3可能透過編寫特定的PTX程式碼，使得在SM上執行的核心可以處理通訊任務。例如，他們可能不使用標準的NCCL庫來進行通訊，而是自己編寫核心（用PTX編寫）來管理伺服器之間的資料傳輸。這些核心會在特定的SM上執行，從而實際上“專用”了一部分SM來執行通訊核心，而不是計算核心。
這樣，132個SM中，20個始終忙於通訊相關的核心，剩下的112個用於計算。這聽起來很有道理，但如何確保這20個SM專門用於通訊呢？可能透過精心的排程，比如啟動佔用這些SM的持久通訊核心，並在其餘的SM上啟動計算核心。但在CUDA中，SM之間的工作分配是由硬體排程程式管理的，除非有辦法對GPU進行分割槽，但這並不是標準的做法。
另一種可能是，DeepSeek V3透過最佳化PTX程式碼，使得通訊核心非常高效，以至於可以用更少的SM處理更多的通訊任務，從而釋放更多的SM用於計算。但原文說他們專門為通訊分配了20個SM，這意味著這些SM被保留了下來。
也許他們將GPU分成了兩個區域：一個用於計算，一個用於通訊。使用MIG可以將GPU劃分為多個例項，但MIG更多是為不同的作業或使用者劃分資源，而不是專門用於計算與通訊。即使他們使用了MIG，原文也提到了PTX級別的定製，所以這可能是透過核心設計進行的軟體分割槽。
或者，他們可能已經設計了計算和通訊核心，使得通訊核心經過最佳化以在SM的子集上執行。例如，透過啟動網格大小佔用20個SM的通訊核心，並在剩餘的SM上啟動計算核心。但是，如何確保計算核心不使用這20個SM呢？除非有辦法設定親和性，但這並不是CUDA/PTX的標準。
也許透過併發限制，如果通訊核心是持久的並且始終在那20個SM上執行，那麼計算核心將僅使用剩餘的SM。但CUDA的排程程式仍可能將計算核心分配給所有SM。因此，這種方法可能需要非常仔細地協調核心啟動和資源分配。
或者，使用CUDA流和優先順序，通訊核心的高優先順序流可以搶佔低優先順序計算核心，從而確保通訊核心獲得所需的SM。但同樣，這並不是專門保留SM；它只是優先考慮。
這裡的關鍵點在於是否可以透過PTX為特定任務分配特定SM：
據我所知，CUDA和PTX不提供明確的控制來將執行緒塊固定到特定SM。硬體排程程式動態地將執行緒塊分配給SM。因此，除非有辦法構造核心，使其執行緒塊僅在某些SM上執行（我認為這是不可能的），否則這可能有點誤導。
但也許DeepSeek找到了一種構造其程式碼的方法，以便通訊相關核心的設計方式可以有效地使用SM子集，也許是透過控制執行緒塊的數量及其分佈。例如，如果啟動通訊核心時恰好有足夠的執行緒塊來佔用20個SM，並且這些核心持續執行，那麼這些SM將忙於通訊任務，而其餘SM將處理計算。但這更像是一種軟體排程技巧，而不是硬體級分配。
在PTX級最佳化方面，他們可能已經編寫了高度最佳化的通訊核心，使用PTX指令更有效地管理資料移動、暫存器使用和warp排程。例如，使用非同步資料傳輸、重疊計算和通訊，或最小化暫存器壓力以允許更多併發執行緒。
另一個方面是使用TensorCores。如果通訊任務涉及可以利用Tensor Cores的某些型別的計算，最佳化PTX以更有效地使用這些單元可能會有所幫助。但原文是關於伺服器到伺服器通訊的，這更多地是關於資料傳輸而不是計算。
也許他們正在使用GPUDirect RDMA（遠端直接記憶體訪問），它允許透過網路在GPU之間直接傳輸資料，而無需CPU。這將使用NIC（網路介面卡）和GPU的DMA引擎。
但是，GPUDirect RDMA通常使用PCIe匯流排和NIC，而不是SM。那麼SM在這裡如何發揮作用呢？也許他們有準備傳輸資料的核心，比如將資料打包到緩衝區、管理標頭或加密。
這些任務將在SM上執行。透過在PTX級別最佳化這些核心，它們可以使資料準備更加高效，從而減少通訊開銷。為這些任務分配20個SM意味著這些SM專用於執行這些資料準備核心，其餘的則專注於主要計算。
因此，總而言之，步驟可能涉及：
- 確定可以解除安裝到GPU的通訊相關任務（例如，傳輸的資料預處理）。
- 為這些任務編寫高度最佳化的PTX核心，確保最小開銷和最大吞吐量。
- 設計核心啟動，使這些通訊核心在SM的子集上執行，可能透過控制執行緒塊的數量及其分佈來實現。
- 平衡工作負載，使通訊核心不會干擾計算核心，可能透過流優先順序或持久核心技術來實現。
- 最佳化PTX中的暫存器使用和執行緒/warp排程，使通訊核心儘可能高效，從而允許它們用更少的資源處理更多資料。
為什麼大規模 GPU 叢集還是很重要？
雖然 DeepSeek 的最佳化技術很厲害，但它更多是讓現有的 GPU 資源用得更高效，而不是完全取代大規模 GPU 叢集。
訓練頂尖的 AI 模型仍然需要大量的計算資源，尤其是在處理超大規模資料和複雜任務時。
DeepSeek 的技術更像是一種“錦上添花”，而不是“替代品”。