DeepInfer 之外：DeepSeek-V4.1-Flash 跑在 12 GB 顯卡上
新的 2-bit GGUF、MIT 許可的本地執行時，加上剛合併的 llama.cpp 支援，讓 V4.1-Flash 的本地路線在這週變了。12 GB 是真的；但帳單的其餘部分是 46–64 GB 記憶體、240–275 GB 磁碟，以及十來個 tokens/s。
2026 年 10 月 23 日，奧地利 ISTA-DASLab 發佈了 DeepSeek-V4.1-Flash-1017 的三個 GGUF 版本。模型卡稱，配合 Strata 執行時，它們可以跑在一張 12 GB 顯卡上。兩天後，llama.cpp 合併了 V4.1-Flash 架構支援。對一個由 DeepInfer 在 SM100 叢集上服務的模型來說，這聽起來像矛盾。其實不是。這是另一種產品，有另一張帳單，也有另一份工作。
這是一篇基於公開資料的發佈筆記。我們讀了模型卡、執行時的文件、release notes 和 llama.cpp 的 PR。我們沒有下載那 250 GB 檔案，沒有跑模型，也沒有做基準測試。下文所有效能和品質數字都標明了是專案自測，不是獨立結果。DeepInfer 的核心事實仍以本站 2026-10-20 的快照為準；本地執行時的事實核查於 2026 年 10 月 26 日。本站是獨立、粉絲製作的站點；方法見關於頁。我們與 ISTA-DASLab、Strata 維護者或 DeepSeek 沒有關聯。
先給結論
如果你想在一台桌上電腦試 V4.1-Flash，這是一條不從那 64+64 卡叢集開始的公開路徑。預算按 12 GB VRAM、46–64 GB 系統記憶體、至少 275 GB 的 NVMe 可用空間來算；在專案測過的顯卡上，生成速度大約是 4–11 tokens/s。
如果你要對外服務，這裡沒有任何東西能替代 DeepInfer。DeepInfer 仍是 DeepSeek 面向 SM100 和 Ascend 950 的離線叢集引擎，仍只支援一個模型，仍缺 KV cache 系統、prefill/decode 分離和跨副本負載均衡。一台單請求 5 tokens/s 的桌上電腦，不是 64+64 卡部署的縮小版，而是另一種產品。
如果你想用 llama.cpp 生態，架構支援已經進了上游，但這不等於「這個特定的 GGUF 包能在 mainline llama.cpp 裡載入」。這個包把 Engram 表放在獨立的 110.6 GB 檔案裡；上游轉換器則把 Engram 寫進模型 GGUF。先確認檔案佈局，再決定要不要下 250 GB。
記住一句話：763B 參數的模型沒有縮到 12 GB。 它是把 backbone 壓到每權重 1.75–2.25 bit，其餘部分由執行時從記憶體和 SSD 串流讀取。12 GB 是顯卡下限，不是總記憶體預算。
這週發佈了什麼
本地路線不是一次發佈完成的。它由一串發佈、在四天裡拼起來。
| 日期（UTC） | 發佈 | 新增了什麼 |
|---|---|---|
| 10-23 | ISTA-DASLab GSQ-RCO GGUF | V4.1-Flash-1017 的三個量化版本：1.75、2.00、2.25 bits per weight。GSQ 和 RCO 參考程式碼是 Apache-2.0；量化權重繼承基座模型的 MIT 許可。 |
| 10-24 | Strata 0.2.4 | MIT 許可的第三方執行時，先在 Terminal 路徑裡加入 V4.1-Flash。此時桌面 app 還沒跟上。 |
| 10-25 | Strata 0.2.5 / 0.2.6 | 0.2.5 把 V4.1-Flash 放進桌面 app；0.2.6 跟進壓力測試修復，並讓記憶體足夠大的機器把 CPU 側專家全部載入記憶體，跑得更快。 |
| 10-25 | llama.cpp PR #31086 | 合併 deepseek41 架構：轉換器、DSpark draft、視覺投影器和 DSV4 KV cache。跟進 PR #31137 在 10-26 合併，帶上 review 修復。 |
日期取自 Hugging Face 和 GitHub API。專案 release notes 可能使用本地日期。
這個順序很重要。量化讓模型小到值得一試；執行時讓它不用自己搭編譯鏈就能用；llama.cpp 讓它進入最大的本地推理生態之一。三塊都必要，但沒有一塊單獨夠用。
GSQ-RCO 改變了什麼
GSQ-RCO 不是新模型，而是一套套在已發佈 V4.1-Flash-1017 checkpoint 上的量化方法。GSQ 負責每個 tensor 的低位元標量量化；RCO 在總大小預算下，為每個 tensor 分配一種量化類型。產物是標準 GGUF，不是只有某個執行時能讀的私有格式。
關鍵詞是「逐 tensor」。均勻 2-bit 會給所有地方用同一種類型；這次是在類型之間搜尋：dense 張量（attention、shared experts、embedding、output head）在 Q5_K、Q6_K、Q8_0 裡選，routed experts 在 IQ1_S 到 IQ3_S 裡選。routed experts 佔參數大頭，所以搜尋的大部分自由度都花在它們身上。
| 版本 | backbone 平均 bpw | Backbone | 共享 Engram | 合計（ISTA） | Strata 下載 |
|---|---|---|---|---|---|
IQ1_M | 1.75 | 120.72 GB | 110.60 GB | 231.32 GB | 239 GB |
IQ2_XXS | 2.00 | 138.24 GB | 110.60 GB | 248.84 GB | 257 GB |
IQ2_XS | 2.25 | 155.23 GB | 110.60 GB | 265.83 GB | 274 GB |
Strata 的數字更高，是因為它額外帶了約 8 GB 的 DSpark drafter。Engram 檔案由三個版本共用，只需下一次。
Engram 表是最容易被忽略的部分。它有 196.6B 參數，按 IQ4_NL（4.50 bits per weight）存放，共 110.60 GB 查找表。它不是矩陣乘權重，而是每個 token 稀疏讀一行，所以可以 mmap 在磁碟上，不必佔 VRAM 或記憶體。這正是「12 GB 顯卡」能成立的原因，也是為什麼 NVMe 是硬要求而不是可選項。
基座是稀疏 MoE：763.2B 參數，每層 384 個 routed experts，每個 token 啟用 6 個，上下文 1M。量化卡把發佈權重描述為 FP8 dense、FP4 routed。2-bit 版本是另一個小得多的運行點，不是無損副本。
拆開 12 GB 這個說法
「能跑在 12 GB 顯卡上」在技術上準確，但在實踐上不完整。模型卡說 backbone 不必裝進 VRAM：配合 Strata，模型其餘部分放在系統記憶體裡。執行時把熱專家留在記憶體，其餘從 SSD 串流讀取；Engram 表則留在磁碟。顯卡只是記憶體層級的一環，不是全部。
| 要求 | 資料怎麼說 | 為什麼重要 |
|---|---|---|
| 顯卡 | 12 GB VRAM；Windows/Linux 上的 NVIDIA RTX 30/40/50 系列；Linux 上的 AMD Radeon AI PRO R9700 | 這是下限，不是總記憶體預算。這個版本的 DeepSeek 引擎不支援 macOS。 |
| 系統記憶體 | 專案報告測試過的最低配置約 46 GB；64 GB 是測試過的舒適值；低於約 40 GB 未測試且很慢 | 裝不進 VRAM 的專家放在記憶體裡。記憶體越少，SSD 換頁越多。 |
| 磁碟 | 單個版本 239 / 257 / 274 GB；三個全下 533 GB；建議 NVMe | Engram 表從磁碟讀。慢盤會拖慢每一個生成的 token。 |
| 上下文 | Strata 固定 8K；--context 可以要求更大 | 模型支援到 1M token，但本地執行時核查過的配置短得多。 |
| 併發 | 同時只處理一個請求；--parallel 會被忽略並給出警告 | 這是單使用者執行時，不是多租戶伺服器。 |
| 速度 | RTX 5070 12 GB + 64 GB 記憶體約 4–6 tok/s；RTX 3060 12 GB + 46 GB 記憶體約 9–11 tok/s；單張 R9700 約 21–25 tok/s；四張 R9700 約 74–77 tok/s | 專案自測，不是獨立基準。Prompt 處理是另一項數字，通常快得多。 |
這張表才是真正的購買指南。如果你有一張 12 GB 遊戲卡和 16 GB 記憶體，這條路不適合你。如果你有一張 12 GB 卡、64 GB 記憶體和一塊快的 2 TB NVMe，你就在專案實際測過的配置裡。這兩台機器之間的差距，比三個量化版本之間的差距大得多。
還有一個版本細節值得釘住：速度數字來自 Strata 自己的 release notes 和模型表，不是 ISTA-DASLab。Strata 0.2.6 說，如果機器能把所有 CPU 側專家裝進記憶體並留出 8 GiB 餘量，現在會在載入時全部拷入，跳過按需儲存。這提升了大記憶體機器的速度，但沒有改變 46 GB 這個下限。
還有一個設定會改變比較：Strata 0.2.5 加入了 Faster 模式，每個 token 只用模型 6 個專家中的 5 個，並且在 VRAM 16 GB 或以下的顯卡上預設開啟。公開的品質數字沒有說明是否開啟了 Faster 模式。如果你在 12 GB 顯卡上用預設設定，和基準對比前先確認這一點。
兩套品質數字，說的不是同一件事
ISTA-DASLab 給了一個很乾淨的結果：2.00-bit 版本在三項基準上都追平基座，任務平均恢復率 100.0%。這是個強標題，但它比看起來窄。
| 版本 | bpw | AIME25 | GPQA-Diamond | LiveCodeBench v6 | 任務平均 | 恢復率 |
|---|---|---|---|---|---|---|
| 基座（FP8 / FP4） | — | 100.00 | 90.91 | 89.71 | 93.54 | 100.0% |
| IQ1_M | 1.75 | 100.00 | 88.38 | 88.57 | 92.32 | 98.7% |
| IQ2_XXS | 2.00 | 100.00 | 90.91 | 89.71 | 93.54 | 100.0% |
| IQ2_XS | 2.25 | 100.00 | 90.40 | 89.71 | 93.37 | 99.8% |
ISTA-DASLab 在 reasoning effort 50 下測得。作者自測，沒有獨立復現。AIME25 每一行都是 100.00，已經飽和，無法區分版本。
看列，不要只看平均。AIME25 在基座和每個量化版本上都是 100.00，說明它在這個難度上已經沒有區分度。真正的訊號在 GPQA-Diamond（IQ1_M 88.38，基座 90.91）和 LiveCodeBench v6（88.57 對 89.71）。2.00-bit 兩項都追平；1.75-bit 掉了約 1.2 個任務平均分；2.25-bit 掉了約 0.2 分。放在三項平均裡，這些都是小差異，也是那種在你自己負載上可能消失、也可能放大的差異。
Strata 講的是另一個故事。它在一組固定的 4,995 個位置上測困惑度：2.00-bit 比原模型高 15.5%，2.25 高 7.3%，1.75 高 21%。它還報告了程式碼和 agent 文字的退化：2.00 是 8.6% 和 5.3%，2.25 是 3.2% 和 2.2%，1.75 是 8.9% 和 10.2%。1.75 在普通英文散文上尤其弱（困惑度 +53%），文件類 +24%。
兩套數字可以同時為真。三項基準的平均值很粗，而且會飽和；困惑度和 KL 散度能看到基準平均掩蓋掉的分布偏移。「100.0% 恢復」的意思是：2.00-bit 在那個 reasoning effort 下、那三項任務上追平了基座。它不意味著量化模型在任何文字上都和原模型不可區分。如果你的工作是長文寫作、多語言內容或特殊的工具呼叫軌跡，任務平均不夠當證據。
「100% 品質」不是量化版本的一種屬性。它是在特定基準集、特定 reasoning effort、特定基座 checkpoint 上的一次結果。誠實的寫法是兩句一起說：「在 reasoning effort 50 的 AIME25、GPQA-Diamond 和 LiveCodeBench v6 上，2.00-bit 版本追平了基座的任務平均；在另一組 4,995 個位置上，困惑度高 15.5%。」
llama.cpp 支援合併了，不等於這個包能跑
10 月 25 日，llama.cpp 合併了 PR #31086「model: DSV4.1 flash」。這個 PR 加入 deepseek41 架構、轉換器、DSpark draft 模型、視覺投影器和 DSV4 KV cache 擴展。跟進 PR #31137 在 10 月 26 日合併，帶上 review 修復。這是實打實的上游支援，也是 V4.1-Flash 進入上游 llama.cpp 的時刻。
但「llama.cpp 支援 V4.1-Flash」和「ISTA-DASLab 的 GGUF 能在 mainline llama.cpp 裡載入」是兩個不同的勾選項。ISTA 這個包把 Engram 表作為獨立的 110.60 GB 檔案發佈；上游轉換器把 Engram 表寫進模型 GGUF，作為一個 per-layer token embedding tensor，執行時從模型裡載入。這是兩種佈局。
截至 10 月 26 日核查，模型卡仍寫著：「As of October 23, 2026, llama.cpp does not support DeepSeek-V4.1, so these GGUFs do not run in llama.cpp yet. They are supported in Strata.」它的 llama.cpp 命令寫的是「等 llama.cpp 支援之後」的未來步驟。這句話可能很快過時——架構支援已經合併——但這個包本身還沒有記錄一個能載入其獨立 Engram 檔案的 mainline llama.cpp 構建。
所以實用建議很無聊但很重要：如果你想用 llama.cpp，從一個把 Engram 表嵌進 GGUF 的版本開始，或者用合併後的轉換器從 HF checkpoint 自己轉。如果你想用 ISTA 的 2-bit 版本，先用 Strata，等模型卡記錄上游路徑。不要因為「支援合併了」就預設「這個包能跑」，然後下 250 GB。
還有一個 caveat：合併的 PR 加了兩條 attention 路徑，預設是優化過的 sparse gather，dense 參考路徑在 LLAMA_DSV41_SPARSE=0 後面。dense 路徑是正確性參考，不是速度建議。上游支援也只有幾天，後續修復還在進。把它當新程式碼，不要當已經穩定的執行時。叢集引擎與本地執行時的範圍對比，見DeepInfer 對比 llama.cpp。
DeepInfer 仍贏在哪裡
DeepInfer 是離線推理引擎，不是託管 API，也不是模型；它支援 NVIDIA SM100 和華為 Ascend 950，只服務 DeepSeek-V4.1-Flash 一個模型。它也沒有包含 KV cache 系統、VE/prefill/decode 分離，以及跨資料並行副本的負載均衡。這些不是小缺口，而是引擎和服務之間的差別。
| 維度 | DeepInfer | GSQ-RCO + Strata | llama.cpp |
|---|---|---|---|
| 工作 | 面向單一模型的叢集推理 | 單使用者本地推理 | GGUF 模型的本地/邊緣執行時 |
| 硬體 | NVIDIA SM100；華為 Ascend 950 | 12 GB+ RTX 30/40/50；Radeon AI PRO R9700；46–64 GB 記憶體 | 廣泛的 CPU/GPU 矩陣，取決於構建和模型支援 |
| 模型格式 | HF checkpoint | GGUF，backbone 1.75–2.25 bpw | GGUF，多種量化類型 |
| 上下文 | 模型支援到 1M；由部署配置決定 | Strata 核查為 8K | 取決於構建和記憶體 |
| 併發 | 叢集調度、Wide-EP、EPLB | 一次一個請求 | 本地 server；不是多租戶叢集 |
| 服務層 | 不含：KV cache、PD 分離、副本負載均衡 | 本地 OpenAI 相容端點 | 本地 OpenAI 相容 server |
| 品質證據 | DeepSeek 的圖表；沒有第三方復現 | 作者自測基準；專案自測困惑度 | 取決於 GGUF 和構建 |
DeepSeek 說，最小高效生產單元是 64 張 prefill 卡加 64 張 decode 卡。這個數字最清楚地說明了 DeepInfer 是幹什麼的。一台 5 tokens/s 的桌上電腦，可以用來做私有草稿、prompt 實驗或工具呼叫原型；它接不住有延遲 SLO 的多使用者負載，也沒法把 110 GB 的 Engram 表攤到幾百個併發序列上。
它也不是一個公平的速度對比。DeepInfer 公佈的 decode 圖用的是 64 張 SM100、EP64DP64、131,072 token 上下文，以及 75% 的 draft 接受率假設。單張 RTX 5070、8K 上下文是另一個實驗。兩者沒有公開的同條件實測，這篇也不會編一個。
有用的切法是按負載分。瓶頸在「能不能用上」時，用本地棧：模型在你控制的機器上，沒有按 token 計費，能接受長回答等幾分鐘。瓶頸在吞吐時，用 DeepInfer：多使用者、快取重用、長上下文，以及一套你準備圍繞缺失元件自己補的服務層。瓶頸在可攜性時，用 llama.cpp：你想要一個執行時跑遍筆電、桌上電腦和小伺服器，也願意跟著快速變化的上游走。
怎麼自己驗證
這次的 release notes 異常詳細，所以是可以驗的。如果你準備花一天下 250 GB，先花十分鐘釘住下面幾項。
| # | 釘住這個 | 為什麼 |
|---|---|---|
| 1 | Checkpoint 和量化版本 | 「V4.1-Flash」不夠。釘住 V4.1-Flash-1017 和具體版本（IQ2_XXS、IQ2_XS 或 IQ1_M）。 |
| 2 | 執行時和檔案佈局 | Strata、mainline llama.cpp，還是某個 fork？Engram 是獨立檔案還是內嵌？答案決定這個下載能不能用。 |
| 3 | Reasoning effort 和上下文 | ISTA 的基準用 reasoning effort 50；Strata 核查的上下文是 8K。你的預設值可能不同。 |
| 4 | 記憶體和磁碟，不只是 VRAM | 12 GB VRAM 是標題。46–64 GB 記憶體和 239–274 GB 磁碟才是實際門檻。 |
| 5 | 你自己的任務組合 | 跑散文、程式碼、工具呼叫和多語言樣本。飽和的 AIME 分數不會告訴你模型怎麼寫合約條款。 |
| 6 | 你上下文長度下的 decode 速度 | 8K 下的 tokens/s 不等於 2K 下的。Prompt 處理是另一項數字，不要混在一起。 |
| 7 | 對比基線 | 和 API 或叢集在同一任務、同一 SLO 下比。本地 tok/s 和叢集圖表不是同一種工作單位。 |
如果只做一件事，做第 2 項。這個發佈裡最貴的錯誤，是為正確的模型下了錯誤的執行時。
常見問題
DeepSeek-V4.1-Flash 真的能跑在 12 GB 顯卡上嗎？
按 ISTA-DASLab 和 Strata 的說法，可以，但 12 GB 只是 VRAM 下限。記錄的配置還需要約 46–64 GB 系統記憶體、單個版本 239–274 GB 磁碟，以及一塊 NVMe 硬碟。模型是從記憶體和 SSD 串流讀取的，不是整個塞進 VRAM。專案報告在測試過的 12 GB 顯卡上約為 4–11 tokens/s。
GSQ-RCO 是新模型嗎？
不是。它是對已發佈 DeepSeek-V4.1-Flash-1017 checkpoint 做的非均勻 GGUF 量化。量化權重繼承基座模型的 MIT 許可；GSQ 和 RCO 參考程式碼是 Apache-2.0。發佈包含三個版本：IQ1_M 1.75 bits per weight、IQ2_XXS 2.00、IQ2_XS 2.25。
llama.cpp 現在支援這些 GGUF 了嗎？
llama.cpp 在 2026 年 10 月 25 日合併了 V4.1-Flash 架構支援，10 月 26 日又合併了跟進修復。這不會自動讓 ISTA-DASLab 這個包在 mainline llama.cpp 裡載入：這個包把 Engram 表作為獨立的 110.6 GB 檔案發佈，而上游轉換器把 Engram 寫進模型 GGUF。下載前先確認檔案佈局和模型卡的執行時說明。
它能替代 DeepInfer 嗎？
不能。DeepInfer 是面向 SM100 和 Ascend 950 的離線叢集引擎；這是單使用者本地執行時。DeepInfer 仍缺 KV cache 系統、prefill/decode 分離和副本負載均衡，DeepSeek 說最小高效生產單元是 64 張 prefill 加 64 張 decode 卡。本地棧適合存取和實驗，不適合服務一群人。
我該選哪個版本？
ISTA-DASLab 推薦 IQ2_XXS 2.00 bits per weight：它在三項報告基準上追平基座，比 IQ2_XS 小約 17 GB。如果你有磁碟、又想要最低的實測困惑度增幅，選 IQ2_XS。只有在磁碟或記憶體緊張、並且能接受可測退化（尤其是散文和文件）時，才選 IQ1_M。
它到底有多快？
Strata 報告：RTX 5070 12 GB + 64 GB 記憶體約 4–6 tokens/s；RTX 3060 12 GB + 46 GB 記憶體約 9–11；單張 Radeon AI PRO R9700 約 21–25；四張 R9700 約 74–77。這些是專案自測，不是獨立基準，並且取決於版本、上下文和儲存。Prompt 處理比生成快得多，應該分開測。
資料來源
- ISTA-DASLab《DeepSeek-V4.1-Flash-1017 · GSQ-RCO GGUFs》：版本、大小、基準、量化流程、執行時說明。核查於 2026-10-26。
- IST-DASLab/GSQ 與 IST-DASLab/RCO：參考程式碼，Apache-2.0。
- Strata 及其 DeepSeek V4.1 文件：MIT 許可、要求、速度和品質測量。
- Strata releases：v0.2.4（10-24）、v0.2.5 與 v0.2.6（10-25）。
- llama.cpp PR #31086 與 PR #31137：架構支援與跟進修復。
- llama.cpp
conversion/deepseek41.py：上游轉換器對 Engram 的處理。 - DeepInfer 倉庫與部署問答：範圍、硬體、缺失元件、64+64 卡單元。
- DeepSeek-V4.1-Flash-1017 模型卡：763.2B 參數、384 experts、1M 上下文、MIT 權重。
所有資料來源存取日期：2026-10-26。廠商與專案數字在正文中單獨標註。我們未找到這些版本的獨立基準。