9月10日凌晨一點多，很多人正準備睡覺，順手打開DeepSeek想問最後一個問題。屏幕上彈出來的不是回答，而是一行字：對話長度已達上限，請開啓新對話。

詭異的是，這個窗口本身就是剛開的新對話，裏面一句話都還沒聊。有人試着發了句"你好"，等來的還是同一句提示。第一財經的記者隨後測試，確認客戶端確實無法正常反饋。#deepseek崩了#很快衝上微博熱搜。

01 一個"新窗口"爲什麼會"對話超限"

這個錯誤提示本身就很說明問題。

"對話長度上限"是大模型的常規機制——上下文窗口有限，聊得太長，模型記不住前面的內容，就會提示用戶開新對話。DeepSeek V3的上下文是64K tokens，大約四五萬字，正常使用很難觸頂。

但凌晨的情況是：用戶剛開了一個空白窗口，什麼都沒說，系統就判定"對話長度已達上限"。問題不在用戶的對話長度，而在服務端——要麼是會話狀態管理出了bug，把某個已超限的舊會話狀態錯誤地套到了新窗口上；要麼是後端緩存或數據庫同步異常，導致請求路由到了錯誤的會話上下文。

換句話說，這不是用戶"聊太多了"，而是DeepSeek自己記錯賬了。

02 這不是第一次，今年已經18次

如果只是一次深夜小故障，不至於衝上熱搜。真正讓用戶集體"被氣暈"的是：這已經是老毛病了。

有網友統計，2026年以來DeepSeek至少發生了18次服務異常。5月8日、21日、24日、28日更是連續四天崩潰。3月29日那次更嚴重，直接宕機12個小時，用戶從下午等到第二天凌晨才恢復。

每次崩潰的直接原因都差不多：用戶量暴漲，算力跟不上。5月那波，日活從1.2億衝到2億，漲了66.7%，而同期算力儲備只增長了8.3%。這個缺口，翻譯成用戶體驗就是：深夜想聊一句"你好"，系統告訴你"對話超限了"。

DeepSeek不是不知道這個問題。但算力這東西，不是想加就能加——一張H100顯卡十幾萬元，一個萬卡集羣就是十幾億的投入，還不算電費、運維和機房。對一家還在燒錢的創業公司來說，每一塊GPU都要算着用。

03 V4.1發佈前夜，賬算得過來嗎

這次崩潰的時間點很微妙。

據DeepSeek官網消息，V4.1版本計劃在9月10日前後正式發佈。也就是說，凌晨崩潰的時候，團隊很可能正在爲新版本做最後的部署和壓力測試。新版本上線前的部署窗口，往往是系統最脆弱的時候——配置切換、流量調度、緩存刷新，任何一個環節出問題，都可能導致服務異常。

更巧的是，9月10日也是蘋果秋季發佈會的日子。一邊是蘋果發佈新品，全球科技媒體聚焦；一邊是DeepSeek深夜崩潰，用戶在微博上集體吐槽。兩個事件撞在同一天，很難不讓人產生聯想。

但平心而論，DeepSeek走到今天已經不容易。它用免費策略迅速積累了海量用戶，用開源模型贏得了開發者社區，用極致的成本控制在巨頭夾縫中殺出了一條路。這條路的底層邏輯是：用免費換規模，用規模換關注度，用關注度換融資，用融資買算力。

問題是，這個循環能不能轉得下去，取決於每一環的效率。用戶漲得越快，算力缺口越大；算力缺口越大，崩潰越頻繁；崩潰越頻繁，用戶體驗越差——這是一個反向循環。深夜的一個錯誤提示，看起來是個小bug，背後其實是一本一直沒完全算明白的算力賬。

V4.1能不能解決問題，還得看發佈後的實際表現。但至少在9月10日凌晨，很多用戶關掉DeepSeek窗口的時候，心裏想的可能是：免費是真免費，但好用，還得再等等。

參考資料【第一財經】《深夜，DeepSeek崩了》

參考資料【虎嗅網】《深夜，DeepSeek崩了》

參考資料【新浪財經】《DeepSeek突然"崩"上熱搜》