# 影片筆記：How I Ran Qwen3.8-27B GSQ-RCO on a 24GB Mac Mini !


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結
影片演示如何在配備 24GB 統一記憶體的 Apple M4 Mac mini 上，透過使用兩比特量化技術（GSQ RCO）將 Qwen 3.8 27B 模型壓縮，成功在記憶體限制內運行並進行推理，同時對比了不同 KV cache 量化設定下的效能與品質。

## 核心重點
1.  **記憶體突破**：標準 Qwen 3.8 27B 模型（約 15GB）加上 KV cache、運行時及 macOS 系統會超過 24GB 統一記憶體極限。透過將模型量化至兩比特（2-bit），可完整載入記憶體而不觸發 Out of Memory 錯誤。
2.  **GSQ RCO 技術**：採用 Gumbel Softmax Quantization (GSQ RCO) 技術，智能分配位元數，將 16-bit 模型縮減約 6.4 倍體積，同時保持高精度與輸出品質。
3.  **效能與品質平衡**：
    *   兩比特模型體積大幅縮小，支援完整 GPU offloading 及多令牌預測（MTP）。
    *   在 M4 Mac mini 上，KV cache 設為 FP16 時，簡單問候 TPS 約 4.57-4.9，長提示詞約 5.67 TPS。
    *   KV cache 設為 8-bit 或 4-bit 時，因需進行去量化（dequantize）和解壓縮（unpack）計算，導致推理速度變慢，甚至比 FP16 更慢。
    *   輸出品質與四比特模型相近，僅在特定程式碼設定（如 Dependency Injection）上有微小差異。
4.  **硬體瓶頸驗證**：在 Apple M5 Max (128GB) 上測試，實際 TPS 僅約 27，未達預期的高速度。結論指出兩比特模型的推理速度受限於模型密度與去量化計算，而非單純由硬體規格決定。

## 詳細大綱

### A. 問題背景與解決方案
*   **記憶體瓶頸**：標準 Qwen 3.8 27B 模型大小至少 15GB。加上 KV cache、運行時及 macOS 系統，會超過 24GB 統一記憶體的極限，導致 Out of Memory 異常。
*   **解決方案**：引入 Qwen 3.8 27B GSQRCO IQ2 QS 模型（兩比特量化版本）。
*   **核心優勢**：
    *   體積大幅縮小，可完整載入 24GB 記憶體。
    *   支援完整 GPU offloading。
    *   啟用多令牌預測（Multi-token prediction, MTP）。

### B. GSQ RCO 技術原理
*   **技術名稱**：GSQ RCO 或 Gumbel Softmax quantization。
*   **運作機制**：
    *   並非對所有張量（tensors）應用相同的量化標準。
    *   智能決定哪些張量需要更高精度，哪些可容忍激進壓縮。
    *   RCO 部分智能決定在模型的張量間分配多或少位元。
*   **效果**：將 16-bit 原模型縮減至兩比特，體積降低約 6.4 倍，但保持高精度與輸出品質。

### C. LM Studio 實測環境與設定
*   **硬體**：Apple M4 Mac mini，24GB 統一記憶體。
*   **軟體**：LM Studio。
*   **模型格式**：僅提供 GGML 格式（非 MLX 格式）。
*   **測試參數**：
    *   Context length：設為 30,000 - 32,000。
    *   Max concurrent prediction：設為 1（減少計算量，原預設為 4）。
    *   KV cache quantization：分別測試 FP16、8-bit、4-bit。

### D. 性能測試結果（M4 Mac mini）
*   **測試提示詞**：
    1.  簡單問候（Hi）。
    2.  長提示詞：撰寫 Selenium C# .NET 代碼（Google 搜尋操作、Page Object Model、Dependency Injection）。
*   **KV Cache FP16 設定**：
    *   記憶體佔用：約 20-21GB。
    *   簡單問候 TPS：約 4.57 - 4.9 tokens/sec。
    *   長提示詞耗時：約 4 分鐘，TPS 約 5.67 tokens/sec。
    *   結果：未觸發記憶體上限，輸出正常。
*   **KV Cache 8-bit 設定**：
    *   簡單問候 TPS：約 5.47 tokens/sec。
    *   長提示詞耗時：比 FP16 更長。
    *   原因：需進行去量化（dequantize）和解壓縮（unpack）計算，導致效能變慢。
*   **KV Cache 4-bit (FP4) 設定**：
    *   TPS 與 FP16 相近。
    *   長提示詞耗時：約 4.46 分鐘（比 FP16 的 4 分鐘稍慢）。
*   **Pie Coding Agent 測試**：
    *   連接 AI 程式碼代理進行代碼分析。
    *   耗時超過 27 分鐘，因需深入分析每個檔案。
    *   輸出品質：與四比特模型相比，僅在 Dependency Injection 設定（如 driver factory class）上有微小差異，整體運作符合預期。

### E. Apple M5 Max (128GB) 對比測試
*   **硬體**：Apple M5 Max，128GB 記憶體。
*   **預期 vs 實際**：
    *   預期：可能達到 100+ tokens/sec。
    *   實際：約 27 tokens/sec。
*   **結論**：兩比特模型在 M5 Max 上並未顯著快於 M4 Mac mini，證明速度受限於模型密度與去量化計算，而非僅取決於硬體規格。

## 工具 / 模型 / 名詞整理
*   **硬體設備**：
    *   Apple M4 Mac mini
    *   Apple M5 Max (Mac)
*   **模型名稱**：
    *   Qwen 3.8 27 billion parameter model
    *   Qwen 3.8 27 billion GSQRCO IQ2 QS model (兩比特量化版本)
    *   GSQ RCO / Gumbel Softmax quantization (量化技術)
*   **軟體與平台**：
    *   LM Studio
    *   Pie coding agent (AI 程式碼代理工具)
*   **技術格式與參數**：
    *   GGML format
    *   MLX format (影片指出該模型目前無此格式)
    *   Unified Memory (統一記憶體)
    *   KV cache (Key-Value cache)
    *   Quantization levels: 2-bit, 4-bit (FP4), 8-bit, 16-bit (16 BPW), FP16
    *   Multi-token prediction (MTP)
    *   Tokens Per Second (TPS)
*   **程式開發相關**：
    *   Selenium C# .NET
    *   Page Object Model
    *   Dependency Injection
    *   WebDriver

## 操作流程整理
1.  **準備環境**：使用 Apple M4 Mac mini (24GB RAM) 與 LM Studio。
2.  **載入模型**：下載並載入 Qwen 3.8 27B GSQRCO IQ2 QS 模型（GGML 格式）。
3.  **設定參數**：
    *   設定 Context length 為 30,000 - 32,000。
    *   將 Max concurrent prediction 設為 1。
    *   選擇 KV cache quantization 設定（FP16, 8-bit, 或 4-bit）。
4.  **執行測試**：
    *   發送簡單問候（Hi）測試基礎 TPS。
    *   發送長提示詞（撰寫 Selenium C# .NET 代碼）測試長上下文處理能力。
    *   連接 Pie coding agent 進行程式碼分析測試。
5.  **觀察結果**：記錄不同 KV cache 設定下的 TPS、耗時、記憶體佔用及輸出品質。
6.  **對比測試**：在 Apple M5 Max (128GB) 上重複測試，比較硬體升級帶來的效能變化。

## 值得注意的限制或風險
1.  **量化帶來的效能損耗**：雖然兩比特模型體積小，但在 M4 Mac mini 上，KV cache 設為 8-bit 或 4-bit 時，因需進行去量化和解壓縮計算，導致推理速度變慢，甚至不如 FP16 設定。
2.  **硬體規格非唯一決定因素**：在 M5 Max (128GB) 上，兩比特模型的 TPS 僅約 27，未達預期的高速度，顯示速度受限於模型密度與去量化計算，而非僅取決於硬體規格。
3.  **記憶體極限**：標準模型無法在 24GB 記憶體上運行，必須使用特定量化版本。
4.  **輸出品質微小差異**：與四比特模型相比，兩比特模型在特定程式碼設定（如 Dependency Injection）上可能有微小差異，需評估是否影響實際應用。

## 逐字稿辨識疑點
*   **Qwen 3.8**：逐字稿中多次提及「Qwen 3.8」，通常 Qwen 版本號為 1, 2, 2.5, 3 等，「3.8」可能為口誤或特定內部版本號，需查證。
*   **GSQRCO / GSQ RCO**：逐字稿中交替使用「GSQRCO」與「GSQ RCO」，並解釋為「Gumbel Softmax quantization」。此縮寫組合較不常見，需查證是否為特定論文或技術的準確拼寫。
*   **M5 Max**：逐字稿中提到測試硬體為「Apple M5 Max machine」。截至目前公開資訊，Apple 尚未發布 M5 系列晶片，此處可能為口誤（應為 M4 Max 或其他型號）或未來預測，需查證。
*   **IQ2 QS**：模型名稱中出現「IQ2 QS」，此為 GGUF 量化格式的一種，拼寫正確，但需確認是否與 GSQRCO 技術完全對應。
*   **Pie coding agent**：逐字稿中明確提到「pie coding agent」，此名稱較不常見，可能是特定內部工具、口誤（如「Py coding」或「AI coding agent」）或特定產品名稱，需查證。
*   **127 tokens per second**：在 M5 Max 測試段落，講者提到「not like 127 tokens per second」，此數字可能是為了對比而舉例，或為口誤（如 12.7 或 100+），需查證。

## 可延伸追問
1.  GSQ RCO 技術的具體論文或官方文件為何？其與傳統量化方法（如 AWQ, GPTQ）的差異為何？
2.  為何在 M5 Max 上 TPS 僅約 27？是否有其他優化空間或設定建議？
3.  「Pie coding agent」的具體功能與適用場景為何？是否為開源工具？
4.  Qwen 3.8 是否為官方正式發布版本？若非，其與 Qwen 2.5 或 Qwen 3 的關係為何？
5.  在實際生產環境中，兩比特模型的輸出品質差異是否可接受？是否有自動評估指標？