弄完OpenAI的GPT-4.5，已經是7點多了。
但是感覺我真的有罪，我居然熬夜就為了看這個大垃圾。
雖然很想睡覺，但，今天可是DeepSeek開源的最後一天。
之前，連續4天，5個硬核專案，FlashMLA、DeepGEMM、DeepE、DualPipe、EPLB，兩萬多個Github星星，這都是全世界開源小夥伴們的傾情貢獻。
既然已經肝了4天了，那最後一天，我才不要錯過。
等到早上9點，DeepSeek如期而至。
這次，他們開源的東西還是極度硬核：
3FS（Fire-Flyer File System）
連結在此：https://github.com/deepseek-ai/3FS
還給了一個基於3FS的資料處理框架：
Smallpond。
https://github.com/deepseek-ai/smallpond
先說3FS。
簡單來說，3FS就是一個專門AI模型和推理做的檔案系統，只不過，它是分散式的，效能太強了。
昨天是麵包廠，那我今天，在用奶茶工廠來給大家舉個例子。
比如，你是一個奶茶世家，經營著一家超大規模的超級奶茶原材料工廠，開的賊大，專門給喜茶、霸王茶姬、CoCo、茶百道、蜜雪冰城等等全國各大奶茶品牌供應原材料。
每天有上萬家門店等待著你的各種果汁、茶湯、蔗糖、珍珠、椰果啥的全都得從你這兒以極快的速度輸送過去。
因為一旦原材料供不上，各家奶茶店就沒法及時出茶，排隊的顧客就得錘門店，門店就會來捶你。
而切大家的配方比例是要嚴格控制的，一旦某些配方倉庫搞混資料，比如喜茶家的葡萄果肉和茶凍比例調錯了，或芭樂瓶裡面的原料配比發錯了，又可能要被顧客捶。
所以你可以想象，這工廠聽著就很牛逼很複雜對吧。
所以你為了保持整套工廠是靠譜的、準確的，不會被各大家品牌方捶，你就需要一個無比寬敞、極度智慧的流水線+庫存網路。
這就是你的究極智慧奶茶原料分發系統。
而3FS（Fire-Flyer File System），就是你的這個究極分發系統。
每天都有成千上萬的奶茶店要來倉庫調取、回傳各種資訊，比如店家庫存不足時要申請更多原材料，原材料運到門店後又需要登記消耗情況，遇到新品上線還要緊急排程不同產線來增產。
所有這些海量資料讀寫都得在極短時間內完成，否則延時太高就會造成門店斷供或生產線浪費。
3FS不僅能把所有的分發全部處理掉，而且延時極低。
核心技術就在於，我們在廠區裡安插了大量全新的高速自動化儲物櫃（這就是SSD），這些儲物櫃隨時能被排程，門店的所有配方、原材料需求等資訊都是數字化的，一按按鈕就能知道哪裡還剩下多少牛奶，哪裡的茶葉正處在發貨階段。
而且，我們還造了一堆的光速傳送帶（RDMA），不需要過多的中轉，一旦原料從儲物櫃那邊這邊發出，直接可以到達對應的節點，而不用像傳統的先裝車，然後普通貨車開一大圈，再交給搬運工二次處理。
效率拉滿。
同時，我們這個工廠，把原材料加工區和原材料儲存區分開，還把各種茶葉處理流水線和配料混合區都搞成了獨立模組。
當某天喜茶或者蜜雪冰城研發了一個新品，門店突然給你下單了一個全新的配方，需要一種新的組合了，也沒關係。
3FS讓你不必關心這個原料是存在哪個倉庫、由誰負責加工，因為在邏輯上，你可以看作整個工廠就是一個大同心圓，任何角落都能直接訪問儲存資源。這叫 locality-oblivious（不用再因為地理位置不同而做繁瑣的排程），相當於你只要告訴工廠我要一批A茶葉和B奶蓋，系統就能自動把所有加工、分發環節安排好。
對你來說幾乎毫無感知，就像整個工廠是一個統一的池子。
這就是3FS的“分離式架構”。
現在再回去看DeepSeek給出的介紹，是不是就大概能看懂，知道這玩意是個啥了？
再看看3FS的實際表現。
也比較炸裂，效能直接拉滿。
現在我們假設，你家的這個奶茶工廠，有180個高速自動化儲物櫃（儲存節點），16個超大容量（14TB）的冷凍箱（NVMe SSDs），還有兩個超快的光速傳送帶（200Gbps InfiniBand網絡卡）。
那在3FS的加持下，這個奶茶工廠，它1秒鐘能送出6.6TiB的原材料。。。（1 TiB約等於1.1TB，有個有個換算關係，1TiB=1024GiB，1TB=1000GB）
這吞吐量是啥概念呢？
約等於你可以一次性載入數千部高畫質乃至4K影片，一部 1080p 高畫質電影大小在2~3GB，4K電影大概10GB往上跑，以6.6TiB/s的吞吐來說，一秒鐘就可以把幾百到上千部電影打包塞進記憶體。
6.6 TiB/s已經屬於往裡塞東西時，硬碟都來不及轉，網路都快成瓶頸的級別。
在現實的大規模分散式集群裡能跑到這種速度，說明它已經把SSD和 RDMA網路的優勢榨到極致，遠超一般人日常認知的網速或儲存吞吐。
然後還有一個KVCache，其實就是最佳化大模型推理過程的技術。
KVCache 的讀吞吐能飆到40GiB/s，也就意味著，當大量門店需要不斷查詢某些關鍵庫存或即時交易資料時，3FS依然能挺住。
不至於像傳統系統那樣面對上萬次請求就卡死。對比之下，其他系統要麼沒有足夠的頻寬，要麼在同時進行移除垃圾或歸檔時會大幅拖慢讀取速度。但在3FS這套工廠體系裡，即使一邊有人清理過期原材料（GC IOPS），另一邊的訂單讀操作也能流暢進行，互不掣肘。
如果只看平均速度，那也穩的不能再穩了。這玩意兒最可怕的是，上下限都極高。
整個3FS就像DeepSeek開源的老作風，他們把所有使用教程統統給了出來，真是生怕我們不會用。。。
我還發現個好玩的，除了上面這個使用操作，還有個說明書大禮包。
就在這。設計筆記、安裝指南、API參考、詳細引數表都一應俱全。
安裝指南這部分，還給了一個測試叢集，隨便執行。
我甚至以為DeepSeek，不想把日子過下去了。。。
再回過頭，提一嘴開源的另一個東西，Smallpond。
簡單來說，這是一個特別輕量化的、但確實厲害的資料處理工具，基於DuckDB和3FS打造的。
比如，你可能想知道，哪些門店最喜歡什麼口味？要從幾十TB的銷售記錄裡跑SQL查詢統計，這在過去可能得搭Spark、Hadoop又或者別的大型分散式系統。
但現在，smallpond就能搞定了。
特點一共三個：
處理資料太快了。
能處理PB級（也就是千萬億位元組那種牛逼的級別）的資料。
用起來確實省心，操作簡單不費腦子。
它背後最大的功臣，還是3FS提供的高併發讀寫和儲存共享能力，以及 DuckDB提供的高效SQL執行引擎。
所以，smallpond+3FS就是絕配，一個負責排程資料加工，一個負責高速資料通道，讓PB級別的資料處理變得像做一杯奶茶那麼輕鬆，真的。
Python 3.8到3.12版本就能用。DeepSeek一併把操作連結放下面了。
總結下這幾天。
這幾天，DeepSeek對老黃的GPU，下多少猛料了？
在V3剛出來時，本來大家覺得。
一張好卡，是不是沒那麼重要了？
馬斯克在孟菲斯的萬卡叢集是不是不用搞了？
但你回過頭來看，會發現：
DeepSeek跟老黃的命運，扯的太深了。
英偉達的卡，尼瑪有無窮的最佳化潛力啊。
這下，為期五天的DeepSeek開源節正式華麗落幕了。
但是，新的英雄之旅說不定現在才剛剛開始。
路漫漫其修遠兮。
吾將上下而求索。
深度求索DeepSeek。
想必也是抱著這個信念。
以上，既然看到這裡了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章，我們，下次再見。
>/ 作者：卡茲克、芝蘭山
>/ 投稿或爆料，請聯絡郵箱：[email protected]