為大語言模型配伺服器，一直遵循一條粗糙的規則：數清引數，乘上精度，照著這個數買視訊記憶體。DeepSeek的V4.1 Flash打破了這條規則。它的權重合計7630億，按FP8算意味著763GB的加速器記憶體下限，但這個模型實際上用約567GB就能跑起來——其中1960億引數一開始就是按跑在普通系統記憶體上設計的。
核心要點
- 一個模型里約196GB的權重可以完全挪出加速器，部署需要什麼檔位的伺服器配置也隨之改變。
- 能挪走的是那些一次只讀幾十條的查表權重，它們從不去爭搶決定token生成速度的記憶體頻寬。
- 這筆節省只有在GPU下面那一層足夠快時才成立，工程重心因此從視訊記憶體預算轉向系統記憶體與儲存I/O的規劃。
決定上限的是頻寬，不是容量
生成一個token，必須把模型的活躍權重從記憶體裡讀出來。這一讀每個token都要重複一次，正因如此，限制吞吐的通常是記憶體頻寬而非純算力，加速器記憶體也才賣得上這個價。容量當然重要，但權重之所以要放在GPU上，根本原因是它們必須被多快地流過去。
這套邏輯只適用於真正被流式讀取的權重，而有些權重並不屬於此列。DeepSeek的條件記憶體模組把1960億引數存成N-gram查詢表——針對短token序列學到的關聯——查一次的代價是每個token讀幾十條表項，而不是把整塊權重掃一遍。訪問如此稀疏的權重，沒有理由去佔用系統中最快的那層記憶體。
結果是庫存被一分為二。每個token約80億引數保持活躍，這部分必須快；查詢池則可以擱在系統記憶體裡，或者放在快到不會卡住的儲存陣列上。The Register對技術報告的解讀把這一設計的目標概括為：把模型「知道什麼」和「必須算什麼」分開。
採購談判會怎麼變
200GB不是一個可以四捨五入掉的零頭。它常常正好是兩檔節點之間的差距，也因此是兩套資本開支方案之間的差距。只按引數量配的買家會買多，只看解除安裝後數字、卻不核實下層記憶體效能的買家會買少，最後用延遲來還賬。
眼下這兩種錯誤都不好避開，因為模型卡只公佈一個記憶體數字，而不是兩個。真正有用的披露是拆開的兩項：多少必須常駐加速器，多少可以往下挪一層。可以預料，這個問題會先進入廠商評估表，之後才進入文件。
還有第二個數字值得追問。填滿GPU的不只是權重——鍵值快取會隨上下文長度和併發使用者數增長，在高吞吐的聊天或智慧體場景中往往反而佔大頭。DeepSeek這次的釋出另外攻了這一點：通過重做注意力機制並引入新的因果編碼器-解碼器，把快取佔用壓到上一代Flash模型的13%到25%。換算成容量，就是每單位記憶體能承載的併發會話提升四到八倍，對多數運維團隊來說，這個數字比引數算術切身得多。
這套技術有多通用
它並非獨門專利。谷歌Gemma團隊做過類似機制Per-Layer Embedding，用來把好用的模型塞進手機——那裡每一層儲存都很緊張。DeepSeek在1月公開了自己的N-gram變體，阿里巴巴此後也在一款實驗性Qwen模型中內建了510億引數的查詢池。這套設計正在擴散，因為凡是把加速器和一條DRAM放在一起比過價的人，都看得懂其中的賬。
尚未定論的是，它能往層級下面走多遠。系統記憶體是已被驗證的去處；儲存則還停留在主張階段，且高度依賴具體陣列。打算採用的團隊應當在自家推理棧上實測，而不是相信一個標題數字，因為這份節省真實但有條件，而條件正是你手上已有或沒有的基礎設施。
它還給變更管理添了一個變數。服務商若改動端點背後執行的東西，也就一併改動了記憶體畫像。本週一個被固定的模型名開始返回不同權重且無法選擇退出，正好暴露了這一風險。
FAQ
任何模型的權重都能解除安裝到系統記憶體嗎？
不能。只有訪問足夠稀疏、無需批次流式讀取的權重才能在不付出延遲代價的前提下挪走，實踐中指的是查表類引數，而非每個token都要用的活躍權重。把常規稠密權重卸下去，只會把GPU本來要解決的頻寬瓶頸原樣請回來。
DeepSeek V4.1 Flash到底需要多少視訊記憶體？
7630億引數按FP8全部常駐加速器，最低需要763GB。把1960億引數的查詢池卸載出去後，這個下限降到約567GB。生產環境還需為鍵值快取留出額外餘量，而這部分會隨上下文長度和併發使用者數一起增長。
解除安裝權重會讓模型變慢嗎？
完全取決於接收它們的那一層。由系統記憶體響應的查表足夠快，架構因此站得住；而一個慢速儲存陣列會在查表時卡住，把這套設計本想省下的延遲原封不動還回來。唯一可靠的答案，是在自己的硬體上跑一遍基準測試。
