弄完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。

想必也是抱著這個信念。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克、芝蘭山

>/ 投稿或爆料，請聯系郵箱：wzglyay@gmail.com