DeepSeek網頁和App在連崩10多個小時后終于恢復了。

比起模型性能，DeepSeek最應該加強的，是整個平臺。

或者多買點服務器，或者多找幾個網絡運維，總之應該讓平臺更牢固。

我們先來回顧一下這次事故吧，3月29日晚到3月30日上午，DeepSeek出現了一次持續10多個小時的異常。

按官方狀態頁時間線看，先是3月29日21:35網頁/APP服務異常，23:23一度恢復；隨后3月30日00:20又進入新一輪性能異常，直到10:33才標記解決。

最關鍵的一點是，官方標記的受影響組件不是籠統的“全站”，而是Web Chat Service，也就是網頁和APP聊天入口這一層。

這說明，出問題的重點大概率不在模型本身，而在承接用戶訪問的前端接入層、會話層和調度層。

它也不是一次公開宣布過的計劃維護，更像是一次連續復發的服務故障。

這已經不是DeepSeek第一次掉鏈子，從2025年爆紅之后到2026年3月，它的網頁、API、登錄注冊都多次出現中斷或性能異常，服務器和運維穩定性，正在成為它最容易被放大的短板。

01

事故起因是什么？

啥是Web Chat Service？

說白了它就是網頁和APP聊天的入口。

DeepSeek的Web Chat Service，范圍通常覆蓋入口網關、鑒權、會話保持、上下文讀寫、長連接管理、區域調度和限流策略。

你打開網頁、登錄賬號、進入對話框、繼續上一輪聊天、等待內容刷出來，這一整段“從點開到聊天”的鏈路出了問題。

如果我們把DeepSeek的模型比作廚子，那么出事的相當于是傳菜員，廚房的一切依舊運作正常，并未對API服務造成系統性影響

一般來說，模型推理資源緊張，通常會先表現為響應變慢、排隊時間拉長、答案生成中斷，或者高峰期出現統一的“繁忙”提示。

Web Chat Service出問題則不同。它可能會導致登錄失敗、網頁一直轉圈、會話無法建立、刷新后掉線、恢復后再次中斷，這些現象都更接近入口服務和會話服務的故障特征。

DeepSeek官方并沒有公開更底層的根因，因此無法斷言是CDN、WAF、Redis、數據庫還是網關出現問題。

根據線索，我們發現DeepSeek“已讀不回”。

其實這類事故發生的流程都是相似的。先是某個時間窗口里，新會話創建、老會話恢復、頁面刷新和登錄校驗一起增多，最先被頂到高位的不是模型，而是負責分流和驗明身份的前置服務。

接著，請求被送進會話層，要去讀取用戶資料、會話歷史、上下文索引和限流狀態，這時候共享緩存和數據庫的讀寫壓力開始升高，連接池被占滿，少量慢請求變成大量排隊請求。

排隊一多，前端超時和掉線就開始出現，用戶看見頁面不動，第一反應通常不是等待，而是刷新、重登、重開新會話。

這樣一來，第二輪請求又被重新打到入口層，系統相當于一邊處理舊流量，一邊接住用戶自己制造出來的新流量。

如果自動擴容跟不上，或者擴出來的新實例還要繼續依賴同一套緩存和數據庫，那么擴容本身也只能緩解表層，并不能消掉瓶頸。

最后大家都會堵在那里，DeepSeek模型沒壞，它能思考，但是DeepSeek說不出來話，因為出口讓人給堵住了。

也就是說，系統表面上像是在“同時處理很多問題”，本質上卻是在被同一批人反復擠壓。到了這個階段，真正麻煩的已經不是那一刻有多少人訪問，而是系統開始自己放大問題。

越是卡，用戶越會重試；用戶越重試，系統越卡。這類故障一旦形成，就很容易從短時擁堵變成長時間反復。

但是我覺得整個事件最有意思的事情是時間，首次出現故障是在北京時間3月29日21:35。

雖然說，這個點鐘的訪問量不低，但也不是最典型的自然新增高峰，尤其不太像一種會把全國性熱門APP瞬間壓穿的常規峰值。

第二次出現故障則是12點以后了，誰會閑到這么晚把DeepSeek刷爆？周一不上班了？

可如果把這個時段換算到海外，情況就完全不同。

它對應的是歐洲下午和美國東海岸早晨，這正好是兩個主要英語用戶時區重疊的窗口。

最近X上流傳著這么一條消息，說DeepSeek現在說話的方式變了，以前它會叫自己是DeepSeek，現在會叫自己是DeepSeek-V3。因此很多人推測，DeepSeek網頁端已經完成了換代，它是DeepSeek-V4，故意微調成V3，掩人耳目。

這條X就跟都市傳說一樣，讓很多海外的網友都來測試這個所謂的“DeepSeek-V4”。

它會吸引大量并不穩定使用DeepSeek的人集中回流，反復登錄、刷新頁面、嘗試新會話、測試輸出風格有沒有變化，試圖從邊緣現象里判斷新模型是否已經暗中上線。

對技術系統來說，這類人未必都在認真使用產品，但他們會不斷試探產品有沒有新變化，這種“圍觀式訪問”對入口系統的消耗往往不比真正使用小。

這類流量和正常日活流量不是一回事。正常流量更接近日常問答，分布相對平緩，用戶行為也較為穩定。圍觀流量和探測流量則更像一陣被消息驅動的短時沖擊，它的特點不是所有人都在高強度調用模型，而是很多人同時觸發首頁訪問、賬號鑒權、會話創建和頁面重連。

這樣的請求結構，對Web Chat Service的壓力往往比對API更直接。

因為API用戶通常有明確調用路徑，接入層更標準，失敗后也不一定會在極短時間內重復刷請求。網頁和APP端不同，刷新、退回、重新登錄、重建會話、長連接斷開后重連，都會在短時段內放大入口層和狀態層的負載。

真正危險的不是流量本身，而是流量打到了哪一層。

如果大量請求集中在首頁、登錄頁和會話初始化環節，入口網關和鑒權服務就會先承壓。

如果用戶不斷開新會話，會話元數據和上下文索引就會快速升溫。

如果頁面在異常狀態下頻繁刷新和重連，WebSocket和重試機制又會把問題放大。

用戶一邊掉線一邊重試，系統一邊恢復一邊又被新的重連壓上去，像一扇本來就卡住的門，后面的人還在不斷往前擠。

一個系統只要有一段鏈路是有狀態的，恢復就往往不是把計算節點擴一擴那么簡單。所謂“有狀態”，就是系統需要記住你是誰、你聊到哪了、這輪對話是不是你的。

無狀態應用可以彈性擴容，有狀態服務卻可能受制于共享緩存、數據庫連接池、消息隊列吞吐和寫熱點。

一旦入口層把壓力繼續往后傳，局部問題就會變成鏈路問題。

02

給梁文鋒提了個醒

這次事故真正值得重視的地方，是它再次提醒梁文鋒，DeepSeek當前最脆弱的環節可能已經不是模型，而是模型之外的整套交付系統。

過去一年，DeepSeek最強的部分一直是模型能力、訓練效率和開源影響力。

無論是V3、R1還是后續的V3.2，DeepSeek都不斷把外界注意力拉回到能力躍升本身。但面向普通用戶的產品市場并不只看模型本身。

用戶不會把“模型很好，只是服務不穩”當成兩件獨立的事。

對絕大多數人來說，產品就是那個能否打開、能否登錄、能否穩定回復的入口。

我都沒辦法打開你的網頁和APP，你跟我說你的模型多強多快，我又怎么會信呢？

2025年1月27日，DeepSeek在美國APP Store熱度暴漲后，官方公開表示服務遭遇“大規模惡意攻擊”，并臨時限制新用戶注冊。

當天DeepSeek的網站和API都經歷了異常。

2026年3月，類似問題又連續出現。

官方狀態頁顯示，3月10日網頁和APP一度不可用，3月18日網頁和APP出現性能異常，再到今天這次故障。

問題并不是某一次突發事故，而是壓力一上來，網頁和APP側的服務穩定性就會優先暴露。模型發布帶來關注，關注帶來高峰，流量高峰又反過來證明交付系統的薄弱。

模型評測榜單領先，影響的是專業討論，服務高峰期連續掉線，影響的是大眾記憶。

評分榜差個百分之零點幾，你覺得我能感受得出來差別？但是打不打得開，我看得清清楚楚。

一個用戶未必能講清楚DeepSeek在長上下文、推理路徑或工具調用上比競爭對手強在哪里，但他一定記得自己是否在關鍵時刻打不開頁面，是否總能看到“服務繁忙”。

這也是為什么V4如果真的要來，最大的風險未必在模型本身。

關于V4，雖然坊間流傳著無數種說法，可DeepSeek官方文檔并沒有正式發布V4說明，官方API文檔當前公開可見的主線仍是V3.2。

下一次版本升級如果到來，真正考驗DeepSeek的不是技術報告，而是灰度、容量和故障隔離能力。

新模型只要更強推理、更長上下文、更偏代碼和Agent場景，單次會話占用的資源就不會更輕。

再疊加圍觀者集中回流、媒體關注、開發者測試和舊用戶嘗鮮，DeepSeek-V4的發布日對系統的壓力通常會比平時高出一個層級。

服務器是梁文鋒的軟肋，這是一個完整的系統工程判斷。

模型公司走到一定規模后，真正決定體驗的，已經不只是GPU數量，而是全鏈路的容量治理能力。

DeepSeek面對的不是封閉的小眾流量，而是帶有全球傳播屬性的公共流量。只要下一代模型繼續具備話題性，下一次壓力就不只是用戶規模擴大而已了，用戶的結構也會變得越來越復雜。

有人是真正來使用，有人是來圍觀，有人是來做高強度測試，也有人只是想驗證新版本到底有沒有暗中上線。

這些流量并不均勻，也不友善。它們會集中出現在少數時間窗口里，并優先沖擊網頁和APP側的入口。

像這種情況是最難處理的，因為它既不是平穩增長，也不是完全可以預測的營銷活動流量，完全是由外部預期驅動的突發同步訪問。

過去兩個月圍繞V4的各種討論已經說明，只要DeepSeek繼續處在聚光燈下，這種沖擊未來大概率還會反復出現。