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


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

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

- 待修正：Whisper 幻覺段落已切除（已移除 1 段幻覺內容，其餘逐字稿保留使用。；原始 Whisper 證據保留在 transcript.whisper.raw.json。）
- 待修正：診斷筆記：目前沒有可可靠理解的逐字稿（asr_language_failure；wrong_language_after_segmented_asr）
- 待修正：逐字稿品質檢核未完全通過（requested_language_repair_inconclusive；保留 133 段 Whisper 逐字稿，已先行發布。）
- 待修正：逐字稿語言與宣告語言不一致（已保留來源字幕/Whisper 內容並繼續產生筆記；請確認影片語言。；若語音辨識輸出英文，也會被語言檢查標記，不會覆蓋日文底稿。）
- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）
- 尚有 2 項待修正細節，請查看工作清單。

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結
影片演示如何在配備 24GB 統一記憶體的 Apple M4 Mac Mini 上，透過 **2-bit 量化**（結合 GSQ 與 RCO 技術）成功運行參數量為 270 億的 Qwen 3.8 模型，在維持與 4-bit 模型相當的輸出品質下，解決記憶體不足問題並支援完整 GPU Offloading。

## 核心重點
1.  **硬體與模型挑戰**：Apple M4 Mac Mini 僅有 24GB 統一記憶體，常規 4-bit 量化的 Qwen 3.8 27B 模型（約 15GB）加上 KV Cache、Runtime 及 macOS 系統後，會觸發記憶體上限導致 Out of Memory。
2.  **2-bit 量化解決方案**：採用 **GSQ (Gumbel Softmax Quantization)** 與 **RCO (Residual Codebook Optimization)** 技術，將模型體積從 16-bit 縮減約 6.4 倍，使模型能在 24GB 記憶體中完整載入。
3.  **性能與品質**：
    *   輸出品質與 4-bit 量化模型相當，未出現明顯智力或品質下降。
    *   支援完整 GPU Offloading 及 Multi-token Prediction (MTP)。
    *   降低 KV Cache 量化（從 FP16 降至 8-bit 或 4-bit）並未顯著提升推理速度（TPS），因為仍需進行去量化（de-quantize）處理。
4.  **實際應用驗證**：在 LM Studio 中測試長提示（Selenium C# .NET 程式碼生成）及 Pi Coding Agent 程式碼分析，確認功能正常且品質穩定。

## 詳細大綱

### A. 問題背景與挑戰
*   **硬體限制**：Apple M4 Mac Mini 配備 24GB 統一記憶體。
*   **常規困境**：
    *   Qwen 3.8 27B 模型（4-bit 量化）大小至少需 15GB。
    *   若完整載入模型、KV Cache、Runtime 及 macOS 作業系統，將超過記憶體上限，導致 Out of Memory 異常。
*   **核心疑問**：能否透過更激進的量化（如 2-bit）解決此問題，且不犧牲模型品質？

### B. 解決方案：2-bit 量化模型技術
*   **模型名稱**：Qwen 3.8 27B GSQ RCO IQ2QS（或稱 QEN3.827BGSQRCOIQ2QS）。
*   **技術核心原理**：
    *   **GSQ (Gumbel Softmax Quantization)**：智能優化量化值。
    *   **RCO (Residual Codebook Optimization)**：智能決定在哪些張量（Tensor）分配更多或更少位元。
    *   **非均勻量化**：並非在所有地方應用相同量化，而是決定哪些張量需要高精度，哪些可容忍激進壓縮。
*   **技術優勢**：
    *   體積從 16-bit 原版縮減約 6.4 倍。
    *   能在 24GB 記憶體中完整載入（含模型、KV Cache、Runtime、OS）。
    *   支援完整 GPU Offloading。
    *   啟用 Multi-token Prediction (MTP)。
    *   輸出品質與 4-bit 模型相當，未損失智力能力。

### C. LM Studio 實測與性能分析
*   **測試環境**：Apple M4 Mac Mini (24GB RAM)，使用 LM Studio。
*   **設定調整**：
    *   Context Length：設為 30,000 - 32,000。
    *   Concurrent Prediction：設為 1（減少總體計算負載）。
    *   KV Cache Quantization：分別測試 FP16、8-bit、4-bit。
*   **測試結果比較**：
    *   **FP16 KV Cache**：
        *   記憶體佔用：約 20-21 GB。
        *   簡單提示（Hi）：約 4.57 - 4.9 TPS。
        *   長提示（Selenium C# .NET 程式碼生成）：約 5.67 TPS，耗時約 4 分鐘。
        *   記憶體壓力穩定，未觸發上限。
    *   **8-bit KV Cache**：
        *   簡單提示：約 5.47 TPS。
        *   長提示：耗時比 FP16 更長（約 4.46 分鐘）。
        *   結論：降低 KV Cache 量化並未加速推理，因為仍需去量化。
    *   **4-bit KV Cache**：
        *   TPS 與上述設定無顯著變化。
        *   長提示耗時約 4.46 分鐘。
    *   **品質觀察**：不同量化設定下，輸出內容基本一致，僅在依賴注入（Dependency Injection）的程式碼結構上有微小差異，但功能正常。

### D. 進階應用與硬體對比
*   **Pi Coding Agent 測試**：
    *   連接 LM Studio 進行程式碼分析。
    *   分析整個儲存庫程式碼耗時超過 27 分鐘。
    *   推理速度較慢，符合密集模型（Dense Model）特性。
*   **Apple M5 Max 對比**：
    *   測試環境：128GB 記憶體的 Apple M5 Max。
    *   同樣運行 2-bit 量化模型。
    *   目的：證明此技術不僅適用於 M4 Mini，在更高階硬體上也能運行，且重點在於「即使量化至 2-bit，輸出品質依然保持」。

## 工具 / 模型 / 名詞整理
*   **硬體設備**：
    *   Apple M4 Mac Mini
    *   Apple M5 Max (提及用於對比)
*   **模型名稱**：
    *   Qwen 3.8 27B (逐字稿中多次誤聽為 QN 3.8 或 QUEN 3.8)
    *   Qwen 3.8 27B GSQ RCO IQ2QS (或 QEN3.827BGSQRCOIQ2QS)
    *   GSQ RCO Unsloth MTP Model
*   **軟體/平台**：
    *   LM Studio
    *   Pi Coding Agent
    *   macOS (Mac Operating System)
*   **技術/格式**：
    *   Unified Memory (統一記憶體)
    *   KV Cache (Key-Value Cache)
    *   GPU Offloading
    *   Multi-token Prediction (MTP)
    *   GSQ (Gumbel Softmax Quantization)
    *   RCO (Residual Codebook Optimization)
    *   2-bit Quantization
    *   4-bit Quantization
    *   8-bit Quantization
    *   FP16 (Float 16)
    *   GGF Format (逐字稿提及模型格式為 ggf，非 mlx)
    *   MLX Format (提及模型不可用此格式)
    *   Selenium C# .NET (程式碼範例語言)
    *   WebDriver
    *   Dependency Injection (依賴注入)
    *   Driver Factory Class

## 操作流程整理
1.  **準備硬體與環境**：確認使用 Apple M4 Mac Mini (24GB RAM)。
2.  **載入模型**：使用 LM Studio 載入 Qwen 3.8 27B GSQ RCO IQ2QS 模型。
3.  **調整推理設定**：
    *   設定 Context Length 為 30,000 - 32,000。
    *   設定 Concurrent Prediction 為 1。
    *   選擇 KV Cache Quantization 設定（測試 FP16、8-bit、4-bit）。
4.  **執行測試**：
    *   發送簡單提示（如 "Hi"）測試基礎 TPS。
    *   發送長提示（Selenium C# .NET 程式碼生成）測試長上下文處理能力與耗時。
5.  **驗證品質**：比較不同量化設定下的輸出內容，確認依賴注入結構等功能是否正常。
6.  **進階應用**：連接 Pi Coding Agent 進行完整儲存庫程式碼分析，觀察推理速度與品質。
7.  **硬體對比**：在 Apple M5 Max (128GB) 上重複測試，驗證技術的通用性。

## 值得注意的限制或風險
*   **推理速度未顯著提升**：降低 KV Cache 量化（從 FP16 降至 8-bit 或 4-bit）並未顯著提升推理速度（TPS），因為仍需進行去量化（de-quantize）處理。
*   **長提示處理時間**：處理長提示（如 Selenium C# .NET 程式碼生成）耗時約 4 分鐘以上；進行完整儲存庫程式碼分析耗時超過 27 分鐘，顯示密集模型在低配備硬體上的計算負荷較高。
*   **記憶體壓力**：即使使用 2-bit 量化，在 24GB 記憶體上運行仍佔用約 20-21 GB，接近記憶體上限，需精確調整設定以避免 Out of Memory。

## 逐字稿辨識疑點
*   **模型名稱聽寫錯誤**：
    *   逐字稿中多次出現 "QN 3.8"、"QUEN 3.8"、"QEN3.827BGSQRCOIQ2QS"。根據上下文推測應為 **Qwen 3.8**，但依規則標記為疑點。
    *   "QEN3.827BGSQRCOIQ2QS" 可能是特定權重檔名稱或聽寫錯誤，無法確認標準命名。
*   **技術術語聽寫**：
    *   "gsq rco"：應指 **GSQ** (Gumbel Softmax Quantization) 與 **RCO** (Residual Codebook Optimization) 的組合技術，但逐字稿拼寫不標準。
    *   "de-quantize 安安"：口語贅字或聽寫錯誤。
    *   "Sedium code" / "Serenium WebDriver"：應指 **Selenium**，但逐字稿拼寫為 Sedium/Serenium。
*   **數據與邏輯矛盾**：
    *   關於 8-bit KV Cache 的測試時間：講者提到 "this time the time is going to be a bit higher than compared to the FP16"（時間比 FP16 長），但隨後說 "instead of the 4.04 minutes... it is 4.46"。若 FP16 是 4 分鐘，8-bit 變慢是合理的，但講者前文暗示降低量化可能不會變快，這裡的數據對比稍顯混亂，標記為需查證。
    *   "27 兆兆" / "127 兆兆"：在描述 M5 Max 時，講者口誤將 "GB" 聽寫或口說為 "兆兆" (Tera/Tera?)，實際應為 GB，但依規則保留原樣或標記疑點。
*   **格式名稱**：
    *   "ggf format"：常見 LLM 格式為 GGUF 或 GGML，"ggf" 可能是聽寫錯誤，標記為需查證。
    *   "mlx format"：MLX 是 Apple 的機器學習框架，通常不直接作為模型權重文件格式名稱（除非指特定轉換格式），標記為需查證。
*   **segment 305**：adjacent_duplicate — 與前一段完全重複，可能是滾動字幕或 ASR 重複。

## 可延伸追問
*   GSQ 與 RCO 技術在 2-bit 量化下的具體數學原理為何？
*   為何降低 KV Cache 量化並未提升 TPS？去量化過程的計算開銷是否超過了記憶體頻寬的節省？
*   在 Pi Coding Agent 中分析完整儲存庫時，是否有方法可以優化推理速度或分階段處理？
*   該 2-bit 量化模型在其他非 Apple 硬體（如 NVIDIA GPU）上的表現如何？