Qwen3.8-27B：SSD Streaming 低記憶體 CPU 推理
本 repo 是推論程式、patch 與驗證證據，不包含模型權重。它使用
unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf（約 15.33 GiB），
透過 file-backed mmap、背景 page reclaim 與 SSD-backed KV cache，讓 dense
27B 模型在約 3 GiB RAM、swap=0 的環境中運行。
這不是 MoE expert paging，也不是 EPQ：Qwen3.8-27B 是 dense 模型，每個 token 都需要讀取整份權重。這個專案的核心機制是 SSD Streaming + KV SSD Paging， 以 I/O 時間換取 RAM 容量，而不是利用稀疏專家跳過計算。
驗證摘要
| 項目 | 結果 |
|---|---|
| 1K context 峰值總 RSS | 0.35–0.67 GiB |
| 理論最高 context | 262,144；峰值約 2.118 GiB |
| swap | 0（驗證紀錄） |
| decode | 0.022 tok/s，每 token 約 45 秒 |
| 模型權重 | 15.33 GiB，保留在 SSD |
| KV cache @262144 | 約 4.78 GiB，使用 SSD mmap |
1K 測試的區間上緣 0.67 GiB 才是部署應參考的最壞情況。完整證據在
validate/、STATUS.md 與 AGENTS.md。
為什麼速度很慢
Dense 模型的每個 token 都會使用全部權重，專家沒有可利用的重複使用工作集。 因此每個 decode token 近似需要從 SSD 重讀 15.33 GiB。文件中的實測速度是 儲存裝置與模型的結果，不是一般 CPU 速度保證。
這個機制與 HelloSun/qwen35a3b-moe-expert-paging-q4 不同：後者是 MoE，
每個 token 只載入被選中的 experts；兩者不可直接以 tok/s 比較。
使用方法
git clone https://huggingface.co/HelloSun/qwen38-27b-ssd-streaming
cd qwen38-27b-ssd-streaming
# 編譯、下載模型、啟動並驗證 1K context
./installpi.sh
# 只重跑驗證
./installpi.sh --validate-only
# 額外驗證 262144 context
./installpi.sh --probe-maxctx
必要條件：Linux x86-64、Git、CMake、C++ toolchain、Python 3、約 16 GiB 磁碟空間。
HF_TOKEN 僅作為環境變數傳給下載工具，公開模型不需要認證。
Patch
| Patch | 功能 |
|---|---|
0001-ssd-mmap-release.patch |
背景 madvise(MADV_DONTNEED) 釋放權重頁 |
0002-kv-ssd-pager.patch |
將 KV buffer 改成檔案 mmap，讓 KV 留在 SSD |
llama.cpp 固定 commit 為 0504396140d1c882f5f6ee34466a42db7ae90114；換版本前
必須重新驗證 patch。
已知限制
--ram-budget類似的部署保證必須用 OS/cgroup 硬限制與 swap.max=0 複驗。- SSD、page cache、CPU、NUMA、context 與 prompt 都會改變速度。
- 262144 context 的數字是已有驗證紀錄，不代表所有機器都能在相同 RAM 中完成。
- 不能把 dense SSD streaming 的結果解讀成 MoE expert paging 或 EPQ 效能。