隨著使用者量的爆炸式增長，DeepSeek頻繁出現“伺服器繁忙”甚至宕機的情況，引發了使用者的廣泛吐槽。本文將深入探討DeepSeek伺服器卡頓背後的原因，同時分析雲服務商和晶片廠商紛紛上線DeepSeek服務卻未能緩解卡頓現象的原因。
DeepSeek頻頻回覆的“伺服器繁忙，請稍後再試”，正在讓各地使用者抓狂。
此前不太被大眾所知的DeepSeek，因2024年12月26日推出對標GPT 4o的語言模型V3而聲名鵲起。
在1月20日DeepSeek又釋出對標OpenAI o1的語言模型R1，之後因為“深度思考”模式生成的答案優質度高，以及其創新揭示出模型訓練前期成本可能驟降的積極訊號，令該公司和應用徹底出圈。
之後，DeepSeek R1就一直在經歷擁堵。它的聯網搜尋功能間歇性癱瘓，深度思考模式則高頻率提示“伺服器繁忙”，此類現象讓大量使用者倍感困擾。
十幾日前，DeepSeek開始經歷伺服器中斷，1月27日中午，DeepSeek官網已數次顯示“deepseek網頁/api不可用”，當日，DeepSeek成為週末期間iPhone下載量最高的應用程式，在美區下載榜超越了ChatGPT。
2月5日，DeepSeek移動端上線26天，日活突破4000萬，ChatGPT移動端日活為5495萬，DeepSeek為ChatGPT的74.3%。
幾乎在DeepSeek走出陡峭增長曲線的同時，關於其伺服器繁忙的吐槽紛至沓來，全世界使用者都開始遭遇問幾個問題就發生宕機的不便，各類替代訪問也開始出現。
比如DeepSeek的平替網站，各大雲服務商、晶片廠商和基礎設施公司都紛紛上線，個人部署教程也到處都是。
但人們的抓狂卻沒有緩解：全球幾乎所有重要廠商都宣稱支援部署了DeepSeek，但各地使用者卻依然在吐槽服務的不穩定。
01 習慣了ChatGPT的人們，
受不了打不開的DeepSeek
人們對“DeepSeek伺服器繁忙”的不滿，來自於此前以ChatGPT為主的AI頂流應用們，甚少出現卡頓。
自OpenAI服務推出以來，ChatGPT雖然也經歷了幾次P0級別（最嚴重的事故級別）宕機事故，但總體來說，它相對可靠，已然在創新和穩定性之間找到平衡，並逐步成為類似傳統雲服務的關鍵組成部分。
ChatGPT的推理過程相對穩定，包括編碼和解碼兩個步驟：
-
編碼階段，把輸入文字轉換成向量，向量包含輸入文字的語義資訊；
-
解碼階段，ChatGPT使用先前生成的文字作為上下文，透過Transformer模型生成下一個單詞或短語，直到生成符合需求的完整語句。
大模型本身屬於Decoder（解碼器）架構，解碼階段就是一個個token（大模型處理文字時的最小單位）的輸出過程，每向ChatGPT提問一次，就啟動一次推理流程。
舉例來說，如果向ChatGPT提問，“你今天心情如何”，ChatGPT會對這句話進行編碼，生成每層的注意力表示，根據之前所有token的注意力表示，預測得到第一個輸出token “我”，之後進行解碼，將“我”拼接到“你今天心情如何？”，後面得到“你今天心情如何？我”，得到新的注意力表示，然後預測下一個token :”的”，之後按照第一步，第二步迴圈，最終得到“你今天心情如何？我的心情很好。”
編排容器的工具Kubernetes是ChatGPT的“幕後指揮官”，它負責排程和分配伺服器資源。
當湧入的使用者承載完全超出Kubernetes控制平面的承受能力時，就會導致ChatGPT系統的全面癱瘓。
ChatGPT發生癱瘓的總次數不算太多，但這背後是它依靠的強大資源作為支撐，維持穩定運轉背後是強大算力，而這是人們忽視的地方。
一般而言，由於推理處理的資料規模往往較小，因此對算力的要求不如訓練般高。
有業界人士估算指出，在正常大模型推理過程中，視訊記憶體的主要佔用模型引數權重佔大頭，大概佔比在80%以上。
現實情況是：在ChatGPT內建的多個模型中，裡面預設模型尺寸都比DeepSeek-R1 的671B要小，加上ChatGPT擁有比DeepSeek多得多的GPU算力，自然展現出比DS- R1更為穩定的表現。
DeepSeek-V3與R1都是一個671B的模型，模型啟動過程就是推理的過程，推理時的算力儲備需要與使用者量相襯，比如有1億使用者量就需配備1億使用者量的顯示卡，不僅龐大，且與訓練時的算力儲備獨立開來，並不相關。
從各方資訊看，DS的顯示卡和算力儲備明顯不足，於是頻頻卡頓。
這種對比讓適應了ChatGPT絲滑體驗的使用者並不習慣，特別是他們對R1的興趣愈發高漲的當下。
02 卡，卡，還是卡
而且，仔細對比，OpenAI和DeepSeek遇到的情況是很不同的。
前者有微軟做後盾，作為OpenAI的獨家平臺，微軟Azure雲服務搭載了ChatGPT、Dalle-E 2影像生成器、GitHub Copilot自動編碼工具，此後，這一組合成為了雲+AI的經典範式，並快速普及成為業界標配；後者雖是初創，卻大部分情況下依靠自建資料中心，與谷歌類似，而不依賴第三方雲計算提供商。
查閱公開資訊後發現，DeepSeek在任何層面都沒有跟雲廠商晶片廠商開啟合作（雖然春節期間雲廠商紛紛宣佈讓DeepSeek模型跑在其上，但他們並沒有開展任何真正意義的合作）。
而且，DeepSeek遇到了史無前例的使用者增長，這意味著它對應激情況的準備時間也比ChatGPT更少。
DeepSeek的良好效能來自其在硬體和系統層面做出的整體最佳化。
DeepSeek的母公司幻方量化，早在2019年就花了2億打造螢火一號超算叢集，到22年就默默儲存萬張A100顯示卡，為了更高效的並行訓練，DeepSeek自研了HAI LLM訓練框架。
業界認為，螢火叢集可能採用了數千至數萬張高效能GPU（如英偉達A100/H100或國產晶片），以提供強大的平行計算能力。
目前螢火叢集支撐了DeepSeek-R1、DeepSeek-MoE等模型訓練，這些模型在數學、程式碼等複雜任務中表現接近於GPT-4水平。
螢火叢集代表著DeepSeek在全新架構和方法上的探索歷程，也讓外界認為，透過這類創新技術，DS降低了訓練的成本，可以僅需西方最先進模型幾分之一的算力，就訓練出與頂級AI模型效能相當的R1。
SemiAnalysis經推算指出，DeepSeek實際擁有龐大的算力儲備：DeepSeek共堆砌了6萬張英偉達GPU卡，其中包括1萬張A100、1萬張H100、1萬張“特供版”H800以及3萬張“特供版”H20。
但實際上，作為推理模型的R1，對標的是OpenAI的O3，這類推理模型需要部署更多算力用於應答環節，但DS在訓練成本側節約的算力，與推理成本側驟增的算力，孰高孰低，目前並不明確。
值得一提的是，DeepSeek-V3和DeepSeek-R1都是大語言模型，但運作方式有差。
DeepSeek-V3 是指令模型，類似ChatGPT，接收提示詞生成相應文字進行回覆。
但DeepSeek-R1是推理模型，使用者向R1提問時，它會首先進行大量的推理過程，然後再生成最終答案。
R1生成的token中首先出現的是大量的思維鏈過程，模型在生成答案之前，會先解釋問題，分解問題，所有這些推理過程都會以token的形式快速生成。
在耀途資本副總裁溫廷燦看來，前述DeepSeek龐大的算力儲備是指訓練階段，訓練階段算力團隊可規劃，可預期，不容易出現算力不足；但推理算力則不確定性較大，因為主要取決於使用者規模和使用量，相對來說彈性較大。
“推理算力會按照一定規律增長，但隨著DeepSeek成為現象級產品，短時間內使用者規模和使用量爆炸性增長，這導致推理階段算力需求爆炸性增長，所以出現卡頓。”
即刻上活躍的模型產品設計師，獨立開發者歸藏認同卡量是DeepSeek卡頓的主因，他認為DS作為當前在全球140個市場下載量最高的移動應用，現在的卡無論如何都撐不住，哪怕用新的卡也不行，因為“新的卡做雲是需要時間”。
“英偉達A100、H100等晶片執行一個小時的成本有公允的市場價格，DeepSeek從輸出token的推理成本上看是比OpenAI同類模型o1便宜90%以上，這個跟大家的計算偏差不大，因此模型架構MOE本身不是最主要問題，但DS擁有的GPU數量決定了他們每分鐘最多可以生產提供的token數，即便可以把更多GPU用來做推理服務使用者，而不用於預訓練研究，但上限在那擺著。”
——AI原生應用小貓補光燈的開發者陳雲飛持類似觀點。
也有業界人士提到，DeepSeek卡頓本質在於私有云沒有做好。
1月30日，媒體從網路安全公司奇安信獲悉，針對DeepSeek線上服務的攻擊烈度突然升級，其攻擊指令較1月28日暴增上百倍。
奇安信Xlab實驗室觀察到至少有2個殭屍網路參與攻擊。
但這種R1自身服務的卡頓，有一個看起來比較顯然的解決方案，是第三方提供服務。
這也是我們在春節期間目睹的最為熱鬧的景觀——各家廠商紛紛部署服務，承接人們對DeepSeek的需求。
1月31日，英偉達宣佈，NVIDIA NIM已經可以使用DeepSeek-R1，此前英偉達受DeepSeek影響，一夜市值蒸發近6000億美元。
同天，亞馬遜雲AWS的使用者可以在其人工智慧平臺，Amazon Bedrock和Amazon SageMaker AI中部署DeepSeek最新R1基礎模型。
隨後，包括Perplexity，Cursor在內的AI應用新貴，也批次接入DeepSeek。微軟則搶在亞馬遜、英偉達之前，率先把DeepSeek-R1部署在了雲服務Azure和Github上。
2月1日大年初四開始，華為雲，阿里雲，字節跳動旗下的火山引擎和騰訊雲也加入其間，他們一般提供的是DeepSeek全系、全尺寸模型部署服務。
再之後是壁仞科技、瀚博半導體、昇騰、沐曦等AI晶片廠商，他們自稱適配了DeepSeek原版或更小尺寸的蒸餾版本。
軟體公司方面，用友、金蝶等是在部分產品中接入DeepSeek模型，增強產品力，最後是終端廠商如聯想、華為、榮耀旗下部分產品接入DeepSeek模型，用作端側個人助手和汽車智慧座艙。
迄今，DeepSeek依靠自身價值吸引來了全面龐大的朋友圈，囊括海內外雲廠商、運營商、券商和國家級平臺國家超算網際網路平臺。
由於DeepSeek-R1是完全開源的模型，接入的服務商都成為了DS模型的受益方。
這一方面極大抬高了DS的聲量，也同時造成了更為頻繁的卡頓現象——服務商和DS自身越來越受困於蜂擁而至的使用者，竟都沒有找到解決穩定使用問題之關鍵竅門。
考慮到DeepSeek V3與R1兩個模型原版都高達6710億引數，適合跑在雲上，雲廠商本身具備更充足的算力和推理能力，他們上線DeepSeek相關部署服務是為降低企業使用的門檻，其部署DeepSeek模型後對外提供DS模型的API，相比DS自己提供是的API，本被認為是可以提供比DS官方更好的使用體驗。
但現實中，DeepSeek-R1模型自身執行的體驗問題，在各家服務中都沒有得到解決。
外界認為服務商們並不缺卡，但實際上他們部署的R1，開發者們對反應體驗不穩定的反饋，頻度完全與R1相當，這更多在於能分配給R1進行推理的卡量也並不太多。
“R1熱度保持在高位，服務商需要兼顧接入的其他模型，能提供給R1的卡很有限，R1的熱度又高，誰家一上R1，又以相對較低的價格提供，就會被沖垮。”
——模型產品設計師，獨立開發者歸藏解釋了原因。
模型部署最佳化是一個涵蓋眾多環節的寬泛領域，從訓練完成到實際硬體部署，涉及多層面工作；但對於DeepSeek的卡頓事件來說，原因可能更為簡單，比如太大的模型和上線之前的最佳化準備不足。
一個熱門大模型上線之前，會遇到涉及技術、工程、業務等多方挑戰，比如訓練資料與生產環境資料的一致性，資料延遲與即時性影響模型推理效果，線上推理效率和資源佔用過高，模型泛化能力不足，以及工程方面像服務穩定性、API與系統整合等方面。
很多當紅大模型上線之前都高度重視做好推理最佳化，這是因為計算耗時和記憶體問題，前者是指推理時延太長，造成使用者體驗差，甚至不能滿足延遲需求，也就是卡頓等現象，後者是指模型引數量多，耗費視訊記憶體，甚至單張 GPU 卡放不下，也會導致卡頓。
溫廷燦對我們解釋了原因，他稱服務商提供提R1服務遇到挑戰，本質是DS模型結構特殊，模型太大+MOE（專家混合結構，一種高效計算的方式）架構，“（服務商）最佳化需要時間，但是市場熱度是有時間視窗的，所以都是先上再最佳化，而不是充分最佳化後上線。”
R1要想穩定執行，如今核心在於推理側的儲備和最佳化之能力。DeepSeek需要做的是，找到方式把推理的成本降下來，把卡的輸出，單次輸出token的數量降下來。
與此同時，卡頓也說明DS本身的算力儲備很可能也沒有SemiAnalysis所述龐大，幻方基金公司要用卡，DeepSeek訓練團隊也要用卡，能排出來給使用者的卡一直不多。
按照目前發展情形看，短期內DeepSeek未必有動力花錢租服務，繼而免費提供給使用者更好的體驗，他們更可能等到第一波C端商業模式梳理清晰之後，再考慮服務租賃的議題，這也意味著，卡頓還會持續不短的時間。
“他們大概需要兩步動作：1）做付費機制，限制免費使用者模型用量；2）找雲服務廠商合作，用上別人的GPU資源。”開發者陳雲飛給出的臨時解法在業界頗有共識。
但目前來看，DeepSeek對自己這個“伺服器繁忙”問題顯得並不太著急。
做為一家追逐AGI的公司，DeepSeek似乎不願太著眼於這蜂擁而來的使用者流量。
可能使用者們在未來不短時間裡還是要習慣面對“伺服器繁忙”的介面了。
來源 | 矽星人Pro（ID：Si-Planet）
作者 | 李京亞 ; 編輯 | 荔枝
內容僅代表作者獨立觀點，不代表早讀課立場
