隨著人工智能技術的飛速發(fā)展，大語言模型及相關應用正成為推動科技變革的核心力量。然而，背后支撐這些模型高效運行的基礎設施（Infra）卻鮮為人知。本文將深度解讀DeepSeek開源周的內容，通過通俗易懂的語言，剖析DeepSeek在模型訓練、推理優(yōu)化以及基礎設施建設方面的創(chuàng)新成果。

本篇內容是對DeepSeek Infra開源周內容的一次費曼學習結果

閱讀前最好能看過前置內容《萬字長文：DeepSeek 647天鑄就的登神長階》。否則雖然也能看懂，但會無法建立全局視野，攝入的知識產生折扣。

閱讀的時候可以先跳過每個章節(jié)的“術語說明”，看不懂了，再回去翻術語說明。不然沒有上下文硬啃術語是挺難受的。

DAY1 FlashMLA

地址：https://github.com/deepseek-ai/FlashMLA，11.2K stars

術語說明

• MLA（Multi-Head Latent Attention），DeepSeek-V2中首次提出，用以取代他們在DeepSeek-67B中使用的GQA。是一種成本低，效果好的注意力算法。
• Flash，來自FlashAttention這個項目，Flash是閃光、快速，Attention是注意力。這是一個老牌的，專門優(yōu)化注意力計算/內存效率的項目。
• FlashMLA，所以FlashMLA，就是DeepSeek開源的，借鑒了FlashAttention項目中的一些理念，然后專門針對他們自研MLA進行優(yōu)化的CUDA內核。
• 所以，通俗來講，MLA是MLA，FlashMLA是“如何更好在機器上跑MLA”的優(yōu)化方法。
• SM（Streaming Multiprocessor，流式多處理器），這是GPU上的計算單元，H800上有132個SM。
• Wrap，是SM上線程調度的基本單位，你可以想象為流水線。所以GPU→SM→Wrap，DeepSeek很多精細化的工作是在Wrap層級上進行的。

項目特點

① Hopper專用

Hopper是英偉達的顯卡系列名稱，換成耳熟能詳的就是H800、H100。

也就是說這個項目如果在其他卡上直接運行，例如華為昇騰、英偉達的A100，都是行不通的。至于為什么，下面會說。

② 對KV緩存進行分塊

每塊大小64。分塊后，整個計算和內存的效率會得到相當大的提升。

這就像以前以訂單為單位去做倉庫管理，有的訂單10000個貨品，有的訂單100個貨品，這時候可能出現某個卡車1訂單裝不下或者1訂單裝不滿的情況，利用率很低。

這個時候平臺推動了改革，不再以訂單為單位做管理，而是跟蹤到每個SKU。那么這個時候你的管理顆粒度上升，雖然會帶來更多管理成本，但整體的物流倉管效率也會因為細粒度而得到巨額提升。

不過這個不是DeepSeek的獨特發(fā)明，而是來自FlashAttention的理念。

③ 極致利用共享內存

共享內存（Shared Memory）的訪問速度很快，但容量很小，英偉達的Hopper系列，每個SM（GPU計算單元）上最大的共享內存為228K（數據來源英偉達官網）。

而DeepSeek在項目中將KV計算的中間結果都放在共享內存上了，每個SM單元下利用其中的224K（此數據來源知乎ling ye）,從而實現了224/228=98.2%的利用率。

一方面，這極大利用了共享內存的高速特性，但也將這個項目牢牢限定在Hopper系列上，因為別的系列很難支持228K/SM的共享內存（例如A100僅有164KB）。

④ Wrap級別的精雕細琢

前面講到DeepSeek將每個SM的共享內存利用得淋漓盡致，那么這里講的就是他對每個SM計算、內存通信上的性能壓榨。

DeepSeek將整個KV的計算分為兩個Wrap Group，其中一個主要負責計算，一個主要負責加載內存，在64分塊大小下，剛好每次完成一個分塊的計算。

如下圖所示，warp0負責Gemm1 這個矩陣的計算+Gemm2一半的計算。Wrap1則負責整個計算過程Q、K、V的內存加載搬運+Gemm2另一半的計算。

p.s，請記住Gemm這個概念，在兩天后的第三個項目就會提到他。

⑤ 動態(tài)輸入序列的適配

在實際的場景中，輸入的序列是長度不一的，特別是R1類推理模型或閱讀理解類任務，輸入序列會很長。

在這個項目里DS采用了雙線程緩沖的模式，會進行一個動態(tài)負載進行計算。如果短序列就采用計算優(yōu)先模式，長序列就采用內存優(yōu)先模式。（此部分細節(jié)需要要看代碼，我的參考來自ZOMI醬的解說）

總結

最終，在H800 SXM5這個卡上，FlashMLA實現了內存帶寬3000GB/S（上限是3.2TB，利用率已經接近90%了），計算浮點數580 TFLOPS的表現

DeepSeek利用了KV分塊+共享內容利用+精細化的Wrap設計把H800的性能壓榨得一干二凈。

有趣的點

我翻了一下issue和fork，已經有人復現了基于A100的 FlashMLA出來了，我相信基于升騰、H20、V100等其他卡的應該也在路上。

項目最末有一堆社區(qū)支持，我看了一下，國內芯片很多都在，唯一一個海外的芯片廠商就是AMD了。

另外知名推理框架vLLM也已經完成對FlashMLA的集成支持。

這也是開源的優(yōu)勢所在，MLA一下子從DeepSeek獨家的一個注意力機制，變?yōu)闊衢T方案，社區(qū)涌現出的許多創(chuàng)意方案又能再次反哺到DeepSeek的研發(fā)推進當中。

DAY2 DeepEP

地址：https://github.com/deepseek-ai/DeepEP?tab=readme-ov-file，7.1Kstars

術語說明

EP（expert parallelism），專家并行性。大參數的Moe模型必須部署在多機多卡上。而訓練或推理的時候，要把輸入的Token分發(fā)給各個專家處理，處理完后要重新合并?？墒欠职l(fā)和合并的專家們卻分布在多個GPU上，這就是專家并行性。

全對全通信（ALL to ALL），全對全通信和點對點通信（P2P）是計算機通信里的兩種概念。

如下圖，某張卡的數據要發(fā)給4個專家處理，這4個專家又在四張卡上，這就需要黃色的這個“0卡”，與4張卡進行4次通訊。以此類推，1、2、3卡也要做這樣的事情，這就產生了4X4=16次通訊。

點對點就簡單了，0卡把數據發(fā)給1卡，結束。所以全對全通信的通信壓力是非常大的。

但偏偏，全對全通信在大參數的Moe架構必定會發(fā)生，這是因為兩點：① Moe架構的輸入需要分發(fā)給多個專家處理，然后再從多個專家中回收結果合并輸出；② 而大參數的Moe模型，必定需要部署在多機多卡上，所以專家們是分布在多個GPU上的，這就導致整個分發(fā)和合并的過程必定要跨GPU進行。

Dispatch&combine（分發(fā)和整合）。在DeepSeek V2中提到一個門控路由，可以對輸入的序列進行處理，然后只分發(fā)給TOP-N個專家進行處理（在V3中是TOP-8），這個分發(fā)就是Dispatch。當專家們處理完后，再對結果進行回收，統(tǒng)一輸出結果，這個整合過程就是combine。

NCCL（NVIDIA Collective Communications Library）& NVSHMEM。NCCL是英偉達開發(fā)的集合通信庫，專門用于多節(jié)點和多GPU的通信。而NVschmen則把多節(jié)點的內存地址做了統(tǒng)一，可以將多個節(jié)點上的GPU內存視為一個虛擬的超大GPU，從而直接對多個不同節(jié)點的內存進行操作。這一段應該比較晦澀，可以放到后面的項目亮點中一起理解。參考內容：英偉達NVschmen技術文檔

NVlink&RDMA。NVlink是一臺服務器內多個GPU的通信方式，H800的帶寬名義雙向400GB/s，DeepSeek實測單向160GB/s，其延遲是納米級別的。而RDMA則是多個服務器之間的通信方式，帶寬50GB/s，延遲為微米級別。

項目特點

① 放棄中臺，完全貼合業(yè)務定制

我們能夠看得出來，這個項目是為了解決Moe模型在訓練、推理過程中的全對全通信問題。而這個問題過去是通過NCCL或其他類似通信庫來解決的。為什么DeepSeek非要自己用NVSHMEM自己手寫呢？

如果我們將計算機通信比作物流（同樣是搬運，區(qū)別只是搬運數據/商品），NCCL就像是淘寶、京東搭建的通用物流平臺，已經能夠便捷地幫你發(fā)貨了。可是你現在創(chuàng)業(yè)了，做了一個去中心的跳蚤平臺，每個人即是賣家，也是賣家，NCCL中的很多設計和封裝對你來說都是冗余的。

偏偏你非常在乎這個通信效率，想壓榨出最極致的性能。所以你選擇NVshcmen，把每個用戶的地址都統(tǒng)一映射為一個巨大無比的虛擬地址簿，然后在這個基礎上進行完全貼合你業(yè)務的改寫。

再用一個互聯網中比較常見的概念——中臺之殤。中臺的原意是抽象通用業(yè)務，加快新業(yè)務的建立。但中臺越維護，就越不好用，越發(fā)在業(yè)務競爭中陷入技術劣勢。尤其在LLM這種耗資巨大的明星項目中，更是無法忍受一絲一毫的效益浪費。

更直觀的概念可以看下面這張圖（左邊變成右邊），整個系統(tǒng)中過去常用、完善的通信庫，被DeepSeek用NVSHMEM直接重寫，改成了完全適配自己Moe模型的通信（物流）方法了。

② 訓練&推理全兼容

在訓練中，輸入序列通常固定且長，例如4096Token。在推理的預填充階段，會一次性對所有輸入Token進行并行計算（例如一次性把“你好，請幫我解釋一下xxx”這幾個字并行計算）。這兩個場景中都會要求極大的吞吐量。

而在推理的解碼階段（即一字一字往外輸出），則要求低延遲性，以保證用戶體驗。

為此這個項目中DeepSeek準備了兩種CUDA內核方案。

第一種，通過NVlink（160GB/s）+RDMA網卡（50GB/s）結合進行，適配訓練+推理預填充階段的需求

第二種，則是純粹RDMA網卡進行，適應推理解碼階段的低延遲需求（因為減少了NVlink到RDMA的轉發(fā)）。

③ 原生支持FP8數據分發(fā)

隨著DeepSeek的開源（包括論文和Github項目），FP8訓練越來越成為業(yè)內的共識。

但這可能也是DeepSeek選擇 NVSHMEM手搓通信的一個原因，因為NCCL 對FP8精度的支持不是那么

p.s 這條不保真，原文來自英偉達24年4月的一條技術博客——“NVIDIA NCCL 僅支持高精度規(guī)約操作 （reduction），所以現在仍然需采用 FP16 進行 reduction，完成后再轉化為 FP8。”

④ 計算與通信重疊

在舊的方案里，我們正常的順序是：

獲取注意力結果→分發(fā)給不同專家（通信）→專家們計算→將專家們結果合并（通信）→decode解碼。

其中通信部分可以理解為數據傳輸，數據沒到，流水線就得等，不能計算——流水線就跑不滿，效率下降。

而在新的方案里，DeepSeek將同時計算兩個批次的結果。所有通信的行為，都發(fā)生在計算中，從而消除流水線氣泡。

如果用通俗例子說，可以用在廚房做兩道菜來舉例：

第一種是，我在廚房里進行備菜+炒菜，要完成番茄炒蛋+宮保雞丁。我先完成番茄炒蛋的備菜，然后炒熟它，再進行宮保雞丁的備菜，再炒熟它。

資本家看不下去了，于是提出第二種方案。我先做番茄炒蛋的備菜，然后炒它，在等它熟的時候，我就去做宮保雞丁的備菜。等宮保雞丁備菜好了，番茄炒蛋也熟了，就緊跟著把宮保雞丁炒了。

當然Deepseek會更邪惡，他會把備菜（通信）和炒菜（計算）的時間對得剛剛好，讓我一個時間單位就做完兩道菜。

如下圖所示，原本dispatch（分發(fā)）和combine（整合）都是通信，是要浪費整個流水線上用于計算的時間的，現在轉換后，都隱藏到計算的背后去了。

總結

DeepEP，說白了就是DeepSeek拋棄了傳統(tǒng)的NCCL通信庫，自己用更底層的NVSHMEM自己手搓了一套通信方法。

這套方法可能不如NCCL那么全面，但在獨特的Moe大模型場景下，卻是絕對效率最好的。

本章節(jié)參考文檔：

英偉達NVschmen技術文檔

B站Zomi的解讀，再次推薦這個博主

有趣的點

我在找NVSHMEN資料的時候，不小心看到下面這張圖，來自2022年5月。兩位GIT佬在交流NCCL和MVSHMEM的看法。這個對話或許有助于你理解兩者的區(qū)別。截圖來源：https://github.com/NVIDIA/nccl/issues/679

DeepSeek在項目中聲明了一個“未定義的PTX用法”。PTX可以理解為CUDA再往下的一層語言，通常是CUDA/C++→PTX→SASS（機器碼）。

所謂未定義即，英偉達官方文檔中沒有說可以這樣用，但結果發(fā)現可以用，性能還提升了。

這下真的詮釋了什么叫“你只是個做顯卡的，你懂什么芯片”。

最后，這個DeepEP在DeepSeek-v3論文中提及過，原文是：“In order to ensure sufficient computational performance for DualPipe, we customize efficient cross-node all-to-all communication kernels (including dispatching and combining) to conserve the number of SMs dedicated to communication”

DAY3 DeepGEMM

地址：https://github.com/deepseek-ai/DeepGEMM，4.9Kstars

術語說明

GEMM（General Matrix Multiplication，通用矩陣乘法）。是大模型訓練推理中經常用到的一種計算方式，在門控路由（推薦TOP-N專家），注意力分數的計算，專家前饋網絡，訓練梯度的反向更新等等都會用到。

GEMM操作幾乎占大模型推理計算量的70%以上。所以只要優(yōu)化GEMM，就能將計算效率推高一截。

項目特點

① 削履適足

事實上GEMM在過去有一個經典的庫，即英偉達的CUTLASS。但和上個項目DeepEP一樣，CUTLASS太過經典通用，在極致的業(yè)務適配上并沒有達到極限。

在項目的說明中，他提及了大量相對于CUTLASS項目的改進，我們在下面展開。事實上DeepGEMM相對CUTLASS的性能改進，正是這些細細碎碎的改進疊加起來的。

② JIT設計

傳統(tǒng)的編譯方式，最終執(zhí)行的代碼是固定的。而JIT則是邊運作邊生成代碼。

在這個生成過程中，他可以根據情況選擇更好的內存分配、減少條件判斷等等，他的代碼性能會比傳統(tǒng)方式更好。

③ 支持非2次方的塊

SM通常只支持2的冪次方塊大小，例如256,128等。但這回答導致工作效率拉不滿（經典的DeepSeek資本家邪惡風格）。

DeepGEMM通過支持非2冪次的塊大小來優(yōu)化特定形狀的效率。

例如傳統(tǒng)128分塊，在M=256，N=7168（M可以近似理解為輸入序列長度，N是FNN的維度）時，(256 / 128) * (7168 / 128) = 112個塊。但H800中有132個SM（計算單元），只分到112個塊，利用率就太小了（112/132=84%）。

而如果采用112分塊，同樣情況下，則(256 / 128) * (7168 / 112) = 128個分塊結果，利用率為128/132=96%。

④ 針對最底層的SASS機器碼動刀

還記得我們前面說到的，CUDA/C++＞PTX＞SASS（機器碼）嗎？

在V3/R1論文中，DeepSeek動了PTX，就被人驚呼繞過了CUDA，英偉達已死（全是bullshit言論）。而在這里他們干脆對最底層的SASS二進制編碼動刀了。

他們的發(fā)現過程很有意思，先是注意到NVCC 在12.2和12.3之間，傳統(tǒng)GEMM項目 CUTLASS FP8的內核提升了。

啊？這是為什么呢？他們進一步比對了最底層的SASS二級制編碼，發(fā)現FADD這個指令中會發(fā)生周期性交錯反轉。進一步調研后，懷疑這個指令通過控制warp線程的釋放提高了效率。

于是他們借鑒這個思路，干脆開發(fā)了一個二進制的腳本來控制另一個指令FFMA，讓他也能實現類似的效果。最后發(fā)現某些情況能夠提升10%以上的性能!

說實在的，這段話，我只能理解一個大概。但是什么FADD、FFMA指令，什么yield位，reuse位是真的不懂，我打算學習Infra，但真沒想過我要學到二進制機器碼這個地步。

但透過這個記錄，我好像看到一個得意的研究員，美滋滋地敲下這段GITHUB說明。

這個世界真正的光芒，總是閃耀在細微之地啊，干杯！

總結

針對大模型訓練推理中占據計算資源最多的GEMM操作，DeepSeek仍然自己做了更底層（甚至到機器碼）的實現以追逐最極致的性能

他們在不同尺寸的矩陣中做了測試，這也是網上很多媒體所說“2.7倍提升”的由來。

但實際上，在Dense（稠密）模型上是1.0倍~2.7倍，其中2.7倍只是極特別的一個場景。

看這個M，N，K的數據，大概是一個低輸入長度，低參數的模型。例如向deepseek-7B提問：”你好呀”。(此條舉例可能有錯，歡迎指出)

事實上我更關心他在Moe結構上的效果

結合下圖來看，在連續(xù)布局（預填充）和掩碼布局下基本上都有1.1X的提升，這已經非常了不起了！

這就類似突然有人和你說全中國的電力成本，能再下降10個百分點…那我馬上把全屋空調開起來！(廣東開始進入夏天了T T)

有趣的點

這個GEMM庫雖然了不起，但需要特別注意的是：他并不支持訓練環(huán)節(jié)，因為訓練環(huán)節(jié)不僅需要GEMM，還需要其他的融合內核，而他們希望這個庫干凈整潔，所以僅僅發(fā)布了面向推理的GEMM內核。

但——DeepSeek內 部正在討論是否發(fā)布可用于預訓練的相關內核。（相關信源）

DAY4 DualPipe&EPLB

https://github.com/deepseek-ai/DualPipe , 2.6K stars

https://github.com/deepseek-ai/eplb 1.1Kstars

DualPipe

DualPipe，雙向流水線。區(qū)別于單線流水線。在DeepSeek-V3中有一個專門的篇幅提及這個方法。

事實上Dualpipe并非DeepSeek首創(chuàng)，根據知乎Fazzie在文章中的說法，其最早可以追溯到 21年SC奇美拉 Chimera: Efficiently Training Large-Scale Neural Networks with Bidirectional Pipelines 這篇文章。

但為什么直到今天才由DeepSeek重新提出并發(fā)揚光大呢？

① 在過去，雙向流水線，意味著顯存要加載雙份模型的參數，這個成本太高了，顯存X2。

② 但是現如今大參數的MOE模型，其模型專家是稀疏的，并且可以通過加大專家并行規(guī)模來進一步緩解顯存消耗(即每個GPU放更少專家，增加集群的規(guī)模)。這就導致在今天特別針對大參數量的MOE模型時，其顯存成本并非2倍，而只是1倍多

具體數據我沒找到，DeepSeek-V3論文中的原文是：”盡管DualPipe要求保留模型參數的兩個副本，但由于我們在訓練期間使用了較大的EP大小，因此這并沒有顯著增加內存消耗”

③ 如果僅僅是顯存開支不大，也不是決定性因素。更重要的是Moe架構需要進行的全對全通信（前面DeepEP項目中提到）。這個全對全通信恰好可以讓模型訓練在進行后向傳播（更新權重）時，把另一個Moe的全對全通信（Dispatch或者combine）給做了，從而實現近乎1:1的計算-通信全覆蓋。

本部分參考內容來自知乎Fazzie

但是Dualpipe注定只能成為大玩家的工具。

① 只有在訓練期間，才需要做backward（后向傳播），才能有空余精力去做全對全通信，從而實現計算-通信全覆蓋。

② 只有大參數、MOE架構的模型，才配得上用這個方法，所有單機/少量卡能訓的模型，非MOE架構的模型，都不適用。

所以這個項目的issue只有可憐的三個，實在是受眾太少了。

EPLB

EPLB（Expert Parallelism Load Balancer），專家并行負載均衡器。這個內容也在V3論文中有提及。

大概原理是：在多級多卡條件下，每個GPU會托管不同的MOE專家，但可能有一些專家總是被訪問（例如deepseek Moe方案中獨特的共享專家)。

于是Deepseek就給這些勞累的專家做一下克隆，準備多一個備份放到同個機器上備用，稱之為冗余專家。

在預填充階段，他們會將專家平均分配到每個機器上（一個服務器8張GPU）。然后將復制的冗余專家平均分配給每個GPU。以V3為例，最后每個GPU托管8個專家+1個冗余專家。

在解碼階段，由于內存的高要求，部署的最小單元從32個GPU，變?yōu)?20個GPU，從而每個GPU只托管一個專家，其中64個GPU托管冗余專家和共享專家。

其實這個項目我不是很感興趣，有點乏味了。唯一有趣的點在于，在V3論文中，他們提及正在嘗試動態(tài)冗余專家方案，例如每個GPU托管16個專家，但只激活9個。

如果這個嘗試能夠成功，成本應該會進一步下降。

總結

專用于大參數、Moe架構的訓練流水線設計，能夠顯著減少大型玩家的訓練成本，但對于小玩家訓練成本或推理成本而言沒有幫助。

DAY5 3FS文件系統(tǒng)

地址：https://github.com/deepseek-ai/3FS，7.8Kstars

術語

Fire-Flyer File System (3FS)

這是一個專用于大模型場景的分布式文件系統(tǒng)，我們先拿U盤舉例子，搞明白文件系統(tǒng)是什么。

我之前買過一個1T的固態(tài)硬盤，結果發(fā)現插到MAC上識別不了。百度一下才發(fā)現原來U盤用的是Windows特有的NTFS格式，而MAC只支持FAT32等，就是不支持NTFS。這里的NTFS，FAT32就是文件系統(tǒng)對應的文件格式。

每個文件系統(tǒng)都有自己進行讀、寫操作的方法，不同的平臺也會有不同的文件系統(tǒng)。

而比起我們日常用電腦的場景，現代大數據會有進一步的奇葩的要求：要求極大吞吐，例如PB級別的內容，要求高頻操作，例如1S內讀寫10000次。所以就產生了如HDFS， Lustre這種針對分布式場景的文件系統(tǒng)。

而DeepSeek的3FS，是對如HDFS這類分布式文件系統(tǒng)的再升級，專門定制以用于大模型訓練推理。

DRAM、VRAM、SSD

DRAM就是CPU的內存，VRAM是顯卡的內存，SSD可以理解為硬盤

這三者的價格，我給一個不精準的數字：

① VRAM: 4090顯卡 24G 18000元，H100顯卡 80G 25萬元；

② DRAM: 32G DRAM，320元

③ SSD: 1T 300元

很顯然，顯存最貴，內存其次，SSD（硬盤）便宜如土。

項目特點

① 有助于預訓練的一些改進

DeepSeek實測在180節(jié)點集群中吞吐6.6TiB/s，25節(jié)點集群中吞吐3.66TiB/min。我不了解傳統(tǒng)分布式文件系統(tǒng)如HDFS在同等規(guī)模節(jié)點的性能表現如何（因為DeepSeek沒做對比，我也找不到資料）。

但從社區(qū)的反饋來看，這個結果非常棒，甚至認為建立了大模型訓練文件系統(tǒng)的新標準。

② 我更感興趣的是推理成本的改進！

我們先了解一個概念叫KVCache。例如你進行了一個20輪的上下文對話，或者有很多人預置了Prompt模板

那么這部分輸入是可以重復利用的，只需要把他先存起來，就可以節(jié)約每次重復計算的成本。大概的示例可以看下面這張圖

在過去，這部分KV緩存一般會放在內存或顯存中，而DeepSeek通過幾個方法的結合將他放到了SSD。

Deepseek依靠的方法：

① 基于MLA注意力機制，可以將KV緩存壓縮為低秩數據，從而降低93.3%的內存占用（來自DeepSeek-V2論文數據）

② 而收益于MLA帶來的內存空間減少，使得KV緩存可以利用本項目的3FS實現在SSD上的高速讀取，吞吐速度為50GB/s

在3月1日DeepSeek公布的推理成本說明中，實際上服務部署運行中KV緩存的命中率為56.3%。也就是有將近一半的KV緩存成本，可以實現90%+的降本。

總結

3FS是一個專門針對大語言模型模型訓練&推理所開發(fā)的文件系統(tǒng)。其性能提升有助于訓練提速

但基于3FS+KVCache所帶來的推理成本降低對我來說更有趣。

有趣的點

網友查看開源的3FS文件，發(fā)現他最早的開發(fā)時間是2014年5月。

但是…2014年幻方還沒成立呢。

按照網上檢索的信息，2008年到2014年間，梁文鋒通過自己的量化算法，實現億萬身家。2015年幻方才成立，2016年幻方才上線第一個完全基于深度學習的量化模型。2019年幻方的深度學習平臺螢火一號才上線。

所以，這行14年的代碼不會是梁文鋒親自寫的吧？

我又找出來一篇我漏掉的DeepSeek論文，關于3FS的，論文標題為：Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning，其中梁文鋒真的在作者清單里。

2014年5月，我的朋友們，你們在做什么呢？

我當時應該在大學宿舍里打英雄聯盟。

這個事情的玄幻程度就像1644年崇禎上吊，而同時期英國爆發(fā)了資產階級革命（攤手.jpg）。

3月1日 Deep推理成本公布

地址：https://zhuanlan.zhihu.com/p/27181462601（官方中文版！五星好評）

這篇內容我就不解讀了，是前述多個項目的整合說明版本，對大模型推理成本感興趣的可以自己去看一下。

重點說說很多媒體無腦轉發(fā)的成本收益率545%，其實是存在一些偏差的（DeepSeek自己也有說明）：

① 整個計算混合了V3和R1兩個模型，而V3價格比R1價格要低，但最終按R1計算收入，所以偏高。

② 把免費服務和降價的夜間服務都按滿額費用計算了，所以也偏高了。