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

這件事給梁文鋒提了個醒，網(wǎng)上都說4月份就要發(fā)布DeepSeek-V4了，到時候DeepSeek面臨的壓力會比現(xiàn)在大得多。怎樣讓服務器在峰值壓力下繼續(xù)保持平穩(wěn)工作，這是梁文鋒必須解決的問題。

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

或者多買點服務器，或者多找?guī)讉€網(wǎng)絡運維，總之應該讓平臺更牢固。

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

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

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

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

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

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

01

事故起因是什么？

啥是Web Chat Service？

說白了它就是網(wǎng)頁和APP聊天的入口。

DeepSeek的Web Chat Service，范圍通常覆蓋入口網(wǎng)關、鑒權(quán)、會話保持、上下文讀寫、長連接管理、區(qū)域調(diào)度和限流策略。

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

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

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

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

DeepSeek官方并沒有公開更底層的根因，因此無法斷言是CDN、WAF、Redis、數(shù)據(jù)庫還是網(wǎng)關出現(xiàn)問題。

根據(jù)線索，我們發(fā)現(xiàn)DeepSeek“已讀不回”。

其實這類事故發(fā)生的流程都是相似的。先是某個時間窗口里，新會話創(chuàng)建、老會話恢復、頁面刷新和登錄校驗一起增多，最先被頂?shù)礁呶坏牟皇悄Ｐ?，而是負責分流和驗明身份的前置服務?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣的請求結(jié)構(gòu)，對Web Chat Service的壓力往往比對API更直接。

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

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

如果大量請求集中在首頁、登錄頁和會話初始化環(huán)節(jié)，入口網(wǎng)關和鑒權(quán)服務就會先承壓。

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

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

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

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

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

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

02

給梁文鋒提了個醒

這次事故真正值得重視的地方，是它再次提醒梁文鋒，DeepSeek當前最脆弱的環(huán)節(jié)可能已經(jīng)不是模型，而是模型之外的整套交付系統(tǒng)。

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

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

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

對絕大多數(shù)人來說，產(chǎn)品就是那個能否打開、能否登錄、能否穩(wěn)定回復的入口。

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

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

當天DeepSeek的網(wǎng)站和API都經(jīng)歷了異常。

2026年3月，類似問題又連續(xù)出現(xiàn)。

官方狀態(tài)頁顯示，3月10日網(wǎng)頁和APP一度不可用，3月18日網(wǎng)頁和APP出現(xiàn)性能異常，再到今天這次故障。

問題并不是某一次突發(fā)事故，而是壓力一上來，網(wǎng)頁和APP側(cè)的服務穩(wěn)定性就會優(yōu)先暴露。模型發(fā)布帶來關注，關注帶來高峰，流量高峰又反過來證明交付系統(tǒng)的薄弱。

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

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

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

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

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

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

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

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

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

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

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

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

這些流量并不均勻，也不友善。它們會集中出現(xiàn)在少數(shù)時間窗口里，并優(yōu)先沖擊網(wǎng)頁和APP側(cè)的入口。

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

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

從這個角度看，給梁文鋒的提醒其實只有一句話，DeepSeek下一階段要補的，已經(jīng)不只是模型能力，而是把模型能力穩(wěn)定送到用戶面前的能力。