簡明科普:DeepSeek Infra開源周全解析

0 評論 489 瀏覽 1 收藏 34 分鐘

隨著人工智能技術的飛速發(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計算收入,所以偏高。

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

作者:馬丁的面包屑 公眾號:馬丁的面包屑

本文由@馬丁的面包屑 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協(xié)議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!