llama-modchip 解讀：64GB 真能跑 284B DeepSeek？速度與品質證據（2026）

2026 年 11 月 4 日，開發者 synchopate 在 GitHub 公開了 llama-modchip v2.4.0 發布說明，主張用 64 GB 系統記憶體、純 CPU 執行 284B 的 DeepSeek-V4-Flash。11 月 8 日，這個專案又因 Hacker News 討論受到關注。最值得問的問題是：模型放得下之後，速度與品質各證明到哪一步？

下面先讀清楚原文的工程主張，再拆開容量、生成速度與品質的證據，最後判斷誰值得繼續追。本文未在本機執行這份大型權重；效能數字屬開發者公開報告，不能視為 AlphaLab 實測或跨硬體保證。

一、llama-modchip 想改變什麼：讓大模型先住進 RAM

大型模型的門檻不只在運算量，也在於每一步要從哪裡讀取權重。混合專家模型（MoE）像一間有許多專業小組的公司，每次只請部分小組工作；但其他小組的資料仍要有地方保存。啟用參數較少，有助於降低每步計算，並不會自動把整份模型縮成同樣大小。

DeepSeek 官方模型卡列出 Flash 約 284B 總參數、13B 啟用參數。這能確認基礎模型的規模；它不能替第三方重新量化後的成品背書。這次要評估的對象，是以 DeepSeek-V4-Flash-0731 為基礎的 Fractal GGUF，以及配套的修改版推論引擎。

依 專案 README，llama-modchip 把量化轉碼、CPU 運算核心與執行時工具放在一起。它不是重新訓練出一個叫作 284B 的小模型，而是嘗試讓既有稀疏模型以更緊湊的表示與更合適的運算排程運行。

By default, all 6 routed experts per layer (Top-6) are evaluated without pruning.

中文：預設會計算每層全部六個被路由選中的專家，不做這一層的專家裁減。

synchopate，llama-modchip README（移除原文行內程式碼樣式）

這句話有兩個界線。第一，「六個」指每次路由選中的專家，不是模型總共只有六個。第二，不裁減這六個專家，仍然可以使用低位元量化。運算時保留哪些專家，與權重用多少位元保存，是兩個不同決定。

這也與 DeepSeek GSQ-RCO 的裁剪與容量教學不同：那篇討論 V4.1 的 Coder 裁剪成品及額外共享檔；本篇分析的是 V4-Flash-0731 的 CPU 工程報告，不能互套下載量或成績。

二、56.56 GiB 是檔案帳，64 GB 還要看執行帳

專案把 GGUF 大小寫為約 56.56 GiB，並自報在指定配置下，程序常駐記憶體約 57.61–58.9 GiB。前者是磁碟檔案，後者是程序觀察值；作業系統、其他程式、頁面快取與並行工作還有自己的需求。不要把兩個數字相減，就當成每台電腦可用的安全餘裕。

容量至少有一部分可以不用下載權重就核對。2026 年 11 月 9 日，本文讀取 發布者 Hugging Face 檔案清單的固定版本，三個 GGUF 分片合計 60,739,342,752 bytes，約 60.739 GB／56.568 GiB。這與宣傳的約數接近，但只是遠端檔案中繼資料加總，並未驗證內容雜湊、載入成功或 RAM 峰值。

GB 與 GiB 的除數不同：前者按十億 bytes，後者按 2 的 30 次方 bytes。硬體標示、Linux 顯示與作者口語中的「64 GB」應逐項對照；直接記錄系統回報的可用 bytes，更能避免誤會。檔案總量也不是安裝總量，還要加引擎、下載暫存與你選擇保留的原始檔。

原文的壓縮策略，概念上是讓不同部位使用不同精度，而不是所有權重都套同一個 bit 數。技術指南另把 CPU 的暫存器、快取與記憶體搬運一起最佳化：同一塊權重解開後多用幾次，少做重複工作。這個方向合理，但每個張量的實際格式與每台機器的收益，仍要回到成品及量測。

三、llama-modchip 的 9–15 tok/s，必須拆成三種速度

在作者標示的 Ryzen 9 9955HX、16 核心、64 GB DDR5、零 GPU 測試環境中，公開文件同時出現三類速度。它們回答不同問題，不能挑最大的數字替整段對話作結論。

作者報告的階段／設定	公開數字	應怎麼讀
輸入處理 Prefill	約 43.16–44.36 tok/s	處理送入的提示，不是輸出答案速度
Top-6、逐 Token Decode	9.06 tok/s（技術表基準）	同一壓縮成品，不加推測解碼；README 另列的較高值有設定歧義
加入 Stockfish-PVS 推測解碼	列為約 11.5–14.7 tok/s	依草稿接受、工作內容與快取狀態而變；舊版敘述也把高端值標為峰值

以上是作者公開報告，不是三組經本文重跑的平均值。還有一個具體矛盾：README 彙整把 9.06–9.95 tok/s 標為 Top-6，但技術指南的裁減比較表把 9.95 列在 Hybrid 5/4/5，而 Top-6 基準列為 9.06。指南另有 Top-6 9.44 的配置範例。不同輪次可以有不同速度，但文件未把這個區間完整對齊；因此本表保留能直接對到設定的 9.06，不把 9.95 當成已釐清的 Top-6 上限。

Prefill 可以想成讀資料，Decode 是開始寫答案。推測解碼則先提出一小段候選，再由目標模型驗證；猜得準時可能省時間，猜錯後要付驗證與回退成本。重複改寫既有程式和從頭回答新問題，得到的加速未必相同。冷啟動、首次輸入與熱快取應另外記。

另外，README 裡較高的 30B 數字，以及 Windows／Vulkan 的 GPU 混合配置，屬其他模型或硬體路線。看到同一份發布說明出現更快的數字時，先讀模型名與 GPU 欄，避免把另一場比賽的成績搬到 284B 純 CPU 這一列。

四、最重要的品質問題：「Lossless」究竟相對誰？

README 彙整表的說明寫明，表中的機率與 KL 散度，是相對同一份約 56.56 GiB Fractal 成品的未修改 Top-6 執行來量。這種對照適合檢查核心修改或額外裁減造成什麼差異；它沒有直接回答「重新量化後，還保留多少官方原始模型能力」。

同一份壓縮檔前後相同，與壓縮前後相同，是兩個命題。像把一本書先縮印，再比較兩台影印機的輸出是否一致；即使影印機彼此一致，也不能據此證明縮印時沒有遺失難讀的細節。

專案還提供 Top-5／Top-4 與 Gate-First SwiGLU 路徑：少算部分專家或中間列，換取更多速度。作者列出的局部機率差異，是這項取捨的線索；Cosine similarity、Top-1／Top-3 一致率與局部 Top-10 的困惑度變化，都不能直接改名成整體任務正確率。

對工具任務尤其如此。JSON 格式相同，只能說這一次的結構或 Token 對得上；參數是否正確、工具執行後能否恢復、任務是否完成，還需要各自的答案與紀錄。想補上這個差別，可以接著讀 Shears 的一致率與正確率教學。

五、100 分報告值得讀，先認清受測模型

100.0% parity

中文：該表列測項達到完全相同的得分。

synchopate，Fractal-MoE Quality Gate 比較表

這是 品質報告中的用語。該報告比較 Q4_0、Fractal-MXFP4 與 Fractal-64-BF16 三種 Nemotron-3.5-30B-A3B 成品，涵蓋工具呼叫、程式生成、約 8.5K Needle／數學，以及速度與 RAM 遙測。它是這組模型、這組題目的作者測試，不能當成 DeepSeek 284B 在廣泛任務上保留 100% 能力的證據。

這份小型報告的價值，在於讓讀者看見題型與評分組成，能沿著程式繼續檢查；它的限制也同樣具體：一組測項全過，無法推估所有繁中寫作、長文件或多輪工具工作的失誤率。尤其表中總分包含效能遙測，不能把總分直接當成純能力百分比。

截至 2026 年 11 月 9 日，本次檢索未找到足以獨立確認「這份 DeepSeek 壓縮成品，在同一硬體上同時達成宣傳速度與可接受品質」的公開重現。搜尋到的轉述不能當第二份測試。這是本文此次查證的範圍，不是宣稱世界上不存在其他測量。

六、AlphaLab 的判讀：容量突破值得追，採用要看另一張考卷

我同意：跨過常駐記憶體門檻，可能比加幾個百分點更有意義

如果一個工作原本反覆把權重搬出搬入磁碟，讓它常駐 RAM，可能改變整個等待的來源。這是為什麼 56.56 GiB 值得注意：它讓一種原本受容量限制的配置，有機會成為可測試的候選。這個價值不需要靠「取代所有 GPU」才成立。

我存疑：順暢展示，距離穩定可用仍有一段

聊天時覺得順，只看到少數答案；多步任務則會放大一個錯誤參數的代價。越積極的量化與裁減，越需要用同題對照確認錯誤落在哪裡。作者願意公開實作、比較設定與失敗方向，是可以繼續追的理由；目前證據仍不足以替每一類工作決定採用。

我會追：同一成品、同一任務，品質與總等待能否一起過關

最有說服力的下一份證據，是另一位測試者固定完整權重版本、引擎提交、CPU／記憶體、執行參數與題目，同時公開原始輸出、失敗案例、RAM／swap 與總時間。若只有吞吐上升，品質或等待的另一端仍空白，就先維持候選身分。

七、現在可以做什麼：先選三種工作，再決定是否下載

如果已有可用硬體與儲存空間，先選一段有可核對事實的繁中摘要、一個能執行測試的小型程式修改，以及一個需要兩輪工具的假資料任務。事前寫下答案與失敗條件，再用較保守的 Top-6 設定做基準；之後一次只改推測解碼或裁減其中一項。這是建議的驗收設計，本文沒有預填結果。

每題記四件事：產物是否合格、從送出到交件的總秒數、峰值記憶體與 swap、所有重試和人工修正。固定輸入長度，分開冷啟動與熱快取；不要只留下最快的一輪。本機 LLM 成績單教學與 同條件 A/B 排查可以幫你把紀錄留下來。

還不確定設備條件的人，今天先核對權重分片與相容引擎即可。GGUF 是容器名稱，不代表任意執行器都理解其中的自訂張量；此成品的發布者要求配套 llama-modchip 引擎。先閱讀固定版本程式與啟動配置，再在隔離、只放假資料的環境試用。大型模型的下載和外部執行檔，都應發生在你已決定要測之後。

llama-modchip 提出的好問題，是大型 MoE 能否更接近一般 CPU 主機；讀者要補完的問題，是這份壓縮成品能否把自己的工作做對。把容量、速度、品質放在同一張表裡，才能知道跨過門檻後，得到的是一個展示，還是一條真正可用的路。