文 | 字母 AI
據新浪創智記報道，DeepSeek 創始人梁文鋒在內部溝通中透露，新一代旗艦大模型 DeepSeek V4 將于 4 月下旬正式發布。
然而比起新模型，我更關注 DeepSeek 的服務器。
3 月 29 日晚上 9 點 35 分，DeepSeek 又雙叒叕崩了。
這一次不是小打小鬧的 " 服務器繁忙 "，而是史詩級的 12 小時 58 分鐘全面癱瘓。網頁端、APP 雙雙失守，修復了又崩，崩了又修復，直到第二天上午 10 點才喘過氣來。
DeepSeek-V4 還沒正式發布，沖擊波已經如此強勁，一旦正式發布，目前 DeepSeek 的基礎設施真的扛得住嗎？
這就是為什么我們要關注代達勱，他是 DeepSeek 的基礎設施負責人。
他負責的不是模型有多聰明，而是模型能不能在百萬級用戶同時涌入時不崩盤。
V4 傳聞四起，發布時間從 2 月推到 3 月，又推到 4 月，外界都在盯著性能跑分，但真正的壓力測試，其實在代達勱這邊。
服務器是 DeepSeek 的軟肋，這已經不是秘密。問題是，留給代達勱的時間還有多少？
DeepSeek 基礎設施掌門人
圈內也有人管他叫 " 戴大麥 "。2024 年博士畢業于北京大學計算機學院計算語言所，師從穗志方教授。
在學術圈，他是個狠人。發表 20 余篇頂會論文，Google Scholar 顯示引用次數超過 28000 次。2023 年，他作為第三核心作者，拿下了 EMNLP 最佳長論文獎，這也是中國大陸機構首次獲得該獎項。
這篇獲獎論文名為《Label Words are Anchors: An Information Flow Perspective for Understanding In-Context Learning》（標簽詞是錨點：從信息流視角理解上下文學習），研究的是上下文學習的工作機制，從信息流的視角揭示了大模型如何通過示例中的標簽詞進行預測。
在讀博期間，代達勱還獲得過國家獎學金、校長獎學金、微軟學者提名獎、北京市優秀畢業生、北京大學三好學生標兵等一系列榮譽。
代達勱博士論文入選了中國中文信息學會 " 博士學位論文激勵計劃 "，研究的是預訓練語言模型的知識增強與推理能力對齊。
他的研究方向聚焦在大模型基礎設施和系統優化。說白了，就是怎樣讓模型跑得更快、更穩、更省錢。
代達勱還參與了一篇綜述類文章，在 AI 圈內也很火。標題是《A Survey on In-Context Learning》（上下文學習綜述）。
文章講的是 In-Context Learning（上下文學習）這個方向的整體研究進展，也就是總結這個領域 " 大家都做了什么、怎么分類、有哪些解釋、還有哪些問題沒解決 "。
從 DeepSeek V1 到 V3，代達勱參與了全程。在 DeepSeek，他負責的是整個推理系統的工程優化與規?；渴?，包括多硬件平臺的性能調優、分布式系統架構設計，以及那些用戶看不見但至關重要的底層管道。
DeepSeek 能在開源大模型領域實現彎道超車、以極低推理成本對標頭部閉源模型的核心技術支撐，就是 DeepSeekMoE。
DeepSeekMoE 所解決的，是傳統 MoE 架構的專家知識冗余、專業化不足的行業痛點，這才讓 DeepSeek 能在同等計算成本下實現了模型性能的大幅躍升。
提出這個架構的論文，叫《DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models》，于 2024 年 1 月發表在 ACL 2024。
而這篇論文的第一作者，正是本文的主角代達勱。
DeepSeekMoE 架構提出了 " 細粒度專家分割 " 的創新思路，讓每個 token 可以激活多個專家，提升知識融合能力。傳統的 MoE 架構像 GShard，激活 top-K 個專家。
但如何確保每個專家真正專業化，獲取不重疊的、聚焦的知識？代達勱團隊的方案是把專家細分成更細粒度的單元，從 N 個專家變成 mN 個，激活時從 K 個變成 mK 個，這樣組合更靈活。
同時隔離出一些共享專家，專門捕獲通用知識，減少路由專家之間的冗余。
這套架構后來成為 DeepSeek-V2 和 V3 的核心基礎。
論文提出的 MoE 架構在 145B 參數規模上，只用 28.5% 的計算量就達到了 DeepSeek 67B 的性能。更關鍵的是，DeepSeekMoE 2B 的表現接近同等總參數量的稠密模型，這為 MoE 模型設定了性能上限。這不是紙面數據，而是真刀真槍跑出來的工程成果。
從理論到工程，代達勱不只是提出創新架構，更要確保這套架構能在真實環境中穩定運行。這種 " 理論上好使，工程上也能跑 " 的能力，正是 DeepSeek 能用這么低的算力，跑出如此高性能的原因。
不過這些成就，都是在模型訓練和架構設計層面。真正考驗基礎設施的，是當百萬用戶同時涌入時，系統能不能撐住。
3 月 29 日那場 12 小時的崩潰，恰恰暴露了這個問題。
DeepSeek 的崩潰與代達勱的硬仗
DeepSeek 總是崩，跟代達勱有沒有關系？
有，但不全是他的鍋。
DeepSeek 現在最大的問題，就出在它的交付系統上。
面對流量高峰，DeepSeek 的交付系統不夠穩定。模型再強，如果推理集群扛不住并發、負載均衡沒做好、容錯機制不夠健壯，照樣會崩。
算法團隊可以把模型訓練得再聰明，但如果基礎設施撐不住，用戶看到的就是 " 服務器繁忙 " 四個大字。
代達勱負責的基礎設施，就是這條鏈路上的關鍵一環。推理集群的調度策略、請求的分發邏輯、GPU 資源的動態分配、故障時的降級預案，這些看不見的管道，決定了系統能不能在壓力下穩住。
3 月 29 日晚上 9 點 35 分，DeepSeek 開始出現大規模服務中斷。網頁端、手機 APP 均無法正常使用，大量用戶反饋無法發起新對話、現有對話中斷。技術團隊立即啟動緊急排查，于當日 23 時 23 分完成首次故障修復，部分用戶反饋可短暫登錄平臺，但隨后服務再次出現波動。
3 月 30 日 00 時 20 分，技術團隊再次針對服務性能異常問題展開調查，于 01 時 24 分實施二次修復方案，期間平臺服務始終處于不穩定狀態，直至 30 日上午 10 時左右，所有服務才完全恢復正常。從首次發現異常到徹底恢復，全程耗時超過 12 小時，創下 DeepSeek 成立以來單次服務中斷時長的最長紀錄。
其實咱們如果回顧 DeepSeek 的歷史你就會發現，DeepSeek 雖然也會偶爾卡頓，但網頁端服務從未出現過超過 2 小時的中斷。
雖然宕機對于目前的大模型而言屬于正?，F象，但這么長時間的宕機，以 DeepSeek 的技術能力而言，不應該發生。
現在的問題是，這套系統在 V3 時代已經顯得吃力，V4 來了怎么辦？
不僅如此，根據最新的消息，V4 不只是模型升級，它是一次底層硬件的全面切換。
DeepSeek V4 將全面基于國產芯片完成適配和優化。
這可不是說像你打游戲換塊顯卡那么簡單。大模型要從英偉達的 CUDA 生態遷移到國產芯片框架，意味著底層代碼要大量重寫，推理系統要重新調優，性能瓶頸要重新排查。
核心差異在于算子生態。
CUDA 積累了 15 年，覆蓋幾乎所有場景。國內的框架到現在還在補課階段，只不過從以前的網課，變成線下實體課程了。
尤其是 Flash Attention、Triton 自定義算子這類高性能優化層，適配工作量相當大。
GPU 和 NPU 的計算是高度并行的，同一個矩陣乘法可能被分拆成幾千個線程同時計算，最后求和。而浮點加法不滿足結合律，不同芯片的并行分拆策略不同，導致累積誤差的路徑也不同。
對于那種幾十億參數量的小模型來說，這個誤差的確是可以忽略不計的。
但 V3 就已經是百億級模型了，V4 只可能更大，尤其是在處理長上下文時，誤差會隨層數和序列長度累積，在輸出層可能產生明顯的誤差。
實際部署時，如何讓模型在新硬件上跑出接近甚至超越英偉達的性能？如何保證遷移過程中服務不中斷？如何在多硬件平臺之間做好資源調度？這些問題，都壓在代達勱肩上。
V4 成敗，不只看模型跑分，更看發布時系統能不能穩住。
如果 V4 發布當天又崩好幾個小時，再好的模型也會被噴成篩子。DeepSeek 下一階段要補的，已經不只是模型能力，而是把模型能力穩定送到用戶面前的能力。
沉默的這幾個月，代達勱在憋什么大招？
DeepSeek 太久沒更新了。
V4 的發布時間從 2 月推到 3 月，又推到 4 月，外界都在猜測是不是模型出了問題。
但如果你仔細看 DeepSeek 這幾個月發的論文，會發現他們在為一場更大的戰役做準備。
2026 年 2 月，DeepSeek 聯合清華、北大發布了 DualPath 論文。這篇論文的第一作者是北大博士生吳永彤，研究方向也是 LLM Infrastructure，和代達勱是一個戰壕里的人。
2025 年 7 月，吳永彤加入 DeepSeek 系統組，參與下一代模型推理基礎設施的建設工作。
他的核心職責之一，是對大規模內部軟件系統進行系統級優化，使其能夠在不同硬件平臺上實現高效、穩定的運行。這類工作本質上屬于大模型基礎設施建設范疇，重點在于提升推理系統在復雜集群環境中的性能與資源利用效率。
說白了，就是把大模型的底層系統搭好，讓它在復雜服務器集群里既跑得動，也跑得快，還不浪費機器
還有一點，agent 這么火，如果 V4 要上 agent 能力，推理系統就必須跟上。即便像 DeepSeek MLA 這樣已經過高度緩存優化的模型，其 I/O 壓力依然巨大。
DualPath 解決的是推理系統里的一個吞吐瓶頸，進而提高大規模服務時的承載能力。所以其實 DeepSeek 自己心里也明白，再好吃的菜，端不上桌，也是白扯。
戴大麥和吳永彤，他們這類工程師的壓力更大。
做算法的人，成績往往是看得見的。模型能力更強了，榜單分數更高了，論文發出來了，產品出了爆款功能，外界很快就能感知到變化。
可做基礎設施的人不一樣，他們最好的成績，往往恰恰是 " 什么都沒發生 "。
服務器沒崩，網頁能打開，APP 不卡頓。
但用戶只會覺得 " 那你不是本來就該這樣嗎？"，沒人會專門記住是誰把這件事做成的。
可一旦出了問題，所有壓力又會在第一時間落到他們頭上。
因為對絕大多數用戶來說，系統不是由模型、調度、網關、緩存、數據庫這些抽象模塊組成的，系統只有一種最直觀的體驗——它能不能用。
普通用戶就一個評判標準，" 我打開你網頁的時候轉不轉圈 "。轉圈就是你服務器不行，不轉圈就是應該的。
用戶是分不清楚到底哪層出了問題。對他們來說，任何原因都會被壓縮成一句話：DeepSeek 怎么又崩了？
這就是基礎設施崗位最難的地方。
做好了，沒人鼓掌，因為這是你該做的；做差了，你就等著被唾沫噴死吧！
對一家已經被推上風口浪尖的大模型公司來說，基礎設施團隊背負的東西很多。
如果 V4 發布時不崩，那才是真正的封神時刻。這場仗，代達勱必須贏。因為模型再強，崩了就是零。
