文 | 字母AI

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

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

比起模型性能，DeepSeek最應(yīng)該加強(qiáng)的，是整個(gè)平臺。

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

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

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

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

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

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

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

01 事故起因是什么？

啥是Web Chat Service？

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

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

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

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

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

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

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

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

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

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

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

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

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

最后大家都會堵在那里，DeepSeek模型沒壞，它能思考，但是DeepSeek說不出來話，因?yàn)槌隹谧屓私o堵住了。

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

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

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

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

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

可如果把這個(gè)時(shí)段換算到海外，情況就完全不同。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02 給梁文鋒提了個(gè)醒

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

過去一年，DeepSeek最強(qiáng)的部分一直是模型能力、訓(xùn)練效率和開源影響力。

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

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

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

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

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

當(dāng)天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ù)穩(wěn)定性就會優(yōu)先暴露。模型發(fā)布帶來關(guān)注，關(guān)注帶來高峰，流量高峰又反過來證明交付系統(tǒng)的薄弱。

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

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

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

這也是為什么V4如果真的要來，最大的風(fēng)險(xiǎn)未必在模型本身。

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

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

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

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

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

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

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

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

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

像這種情況是最難處理的，因?yàn)樗炔皇瞧椒€(wěn)增長，也不是完全可以預(yù)測的營銷活動流量，完全是由外部預(yù)期驅(qū)動的突發(fā)同步訪問。

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

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