大型開源模型愈來愈強，但也愈來愈大。想在自己的電腦上執行時，第一個遇到的問題往往不是模型能力，而是記憶體不夠。
Qwen3.8-Flash-Next 受到本地 AI 玩家與開發者關注，除了採用 MoE 架構，也因為它把一部分大型資料表設計成適合分層存取的 N-gram embedding table。
白話來說，模型不再要求所有資料都塞進 GPU。真正需要高速運算的部分留在 GPU，較大但每次只讀取少量資料的表格，則可以交給主機 RAM，甚至透過 NVMe SSD 的 mmap 方式存取。
這不是拿硬碟硬撐記憶體，而是模型中剛好有一塊資料很適合這樣使用。
模型很大，不代表每次都要全讀
Qwen 官方資料指出，Qwen3.8-Flash-Next 包含 125B 參數的主模型，以及額外 51B 的 N-gram embedding，每個 token 約啟用 6B 參數。
模型生成文字時，不需要每一步讀取整張 embedding table，而是依照前文查詢少量資料列。它比較像一本很厚的百科全書，使用時只翻到指定頁面，而不是每次從第一頁讀到最後一頁。
官方文件也說明，N-gram embedding 可以卸載到主機記憶體，並透過非同步預取與模型運算重疊。這讓 GPU 空間可以優先留給主要權重與 KV cache。
對使用者而言，最重要的差別是：原本因為 VRAM 不足而完全無法啟動的模型，多了一條分層部署的路線。
SSD 可以幫忙，但不是任何硬碟都適合
社群實驗進一步把 N-gram table 以 mmap 方式放在 NVMe SSD 上。這不是每次推論都把整個模型從硬碟讀進來，而是讓作業系統把 SSD 當成可分頁的後備資料池，常用資料則留在 page cache。
實務上比較適合的條件包括：
- 本機 PCIe NVMe SSD，建議 PCIe 4.0 或以上
- 具備穩定隨機讀取能力的 TLC SSD
- 預留足夠空間保存模型、量化檔、N-gram table 與快取
- 避免使用傳統 HDD、USB 外接硬碟、NAS 網路磁碟或雲端同步資料夾
- 保留足夠系統記憶體給 Linux page cache
這些是部署上的實務建議，不是 Qwen 官方公布的最低硬體規格。
SSD 在這裡比較像模型的倉庫，不是模型的引擎。真正高速運算仍然發生在 GPU 與記憶體中。
社群實測：速度會下降，但不一定不能用
在 Hugging Face 社群測試中，單張 Blackwell GPU 將 N-gram table 放在主機 RAM 時，單一請求生成速度約 84 tok/s。
改用 SSD mmap，並把容器記憶體限制在 48 GB，測試結果約為 77 至 79 tok/s。速度有所下降，但仍可維持可用的互動體驗。
真正需要注意的是冷 page cache。
當 SSD 中的資料尚未進入系統快取時，首次回應時間可能從約半秒拉長到 4 至 5 秒，生成速度也可能降到約 37 至 41 tok/s。等常用資料進入 page cache 後，速度才會逐漸恢復。
第一次像是在倉庫找貨，之後常用的東西放到手邊，反應就會快很多。
關鍵不是 SSD，而是記憶體管理
SSD offload 最容易被誤解的地方，是以為只要換一顆快速 SSD 就能解決所有問題。
實際上，Linux page cache 如何分配，以及 Docker 或容器是否限制好記憶體使用量，都會直接影響穩定性。
如果模型載入時大量 checkpoint 檔案塞滿 page cache，原本已經變熱的 N-gram table 可能被擠出去。模型生成途中就必須反覆回 SSD 讀取，速度自然會變慢。
社群測試指出，替容器設定明確的記憶體上限，例如 48 GB RAM，可以避免 checkpoint 讀取失控，讓 SSD mmap 版本維持較穩定的延遲與吞吐。
這不是裝完模型、按下執行就結束，而是要安排好 GPU、RAM 與 SSD 各自負責的工作。
哪些設備比較適合？
| 使用情境 | 建議做法 | 使用感受 |
|---|---|---|
| 多張 H100、H200 等伺服器 GPU | 使用官方 vLLM 與 CPU offload | 較穩定，適合高併發服務 |
| 單張 96 GB Blackwell GPU | 優先將表放入 RAM，不足時考慮 NVMe mmap | 可以部署，但需要調校 |
| DGX Spark、GB10、GX10 | 使用針對 PLE table 的 mmap 方案 | 適合將統一記憶體留給長上下文 |
| Apple Silicon 64 至 128 GB | 使用拆分 N-gram table 的 GGUF 與 llama.cpp | 適合本地互動 |
| 一般 24 至 48 GB 顯卡與 64 GB RAM | 不建議作為主力部署 | 主模型與 KV cache 仍有壓力 |
DGX Spark 與 GB10 的社群案例顯示，透過 NVMe mmap 提供約 44 至 48 GiB 的 N-gram table，可以把主要模型權重控制在約 76 GiB，將剩餘統一記憶體留給 KV cache 與長上下文推論。
Apple Silicon 也有類似路線。社群 GGUF 版本會把 N-gram table 拆成獨立 shard，避免 Metal 將整個混合檔案一次鎖進統一記憶體。
從買更大顯卡，走向分層使用資源
Qwen3.8-Flash-Next 的意義，不只是多一個大型模型可以執行。
它更像是一個訊號：未來本地 AI 的硬體門檻，不一定只靠更大的 VRAM 解決，也可以透過模型架構、量化、主機 RAM、NVMe SSD 與作業系統快取的分工，把有限硬體用得更有效率。
當然，SSD 路線目前仍偏向進階玩家與工程團隊的實驗方案，不代表每台 64 GB 電腦都能立刻變成 AI 伺服器。
但它已經證明一件事：
模型能不能跑，不再只是看顯卡有多大，也開始看系統懂不懂得把資料放在對的位置。