影片筆記：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）上有微小差異。

1. 硬體瓶頸驗證：在 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）。

1. 執行測試：

• 發送簡單問候（Hi）測試基礎 TPS。
• 發送長提示詞（撰寫 Selenium C# .NET 代碼）測試長上下文處理能力。
• 連接 Pie coding agent 進行程式碼分析測試。

1. 觀察結果：記錄不同 KV cache 設定下的 TPS、耗時、記憶體佔用及輸出品質。
2. 對比測試：在 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. 在實際生產環境中，兩比特模型的輸出品質差異是否可接受？是否有自動評估指標？