# 影片筆記：Qwen's 27B Model Is Now An 11.8GB Download


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

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

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

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

影片詳細分析了將 Qwen 27B 模型壓縮至 11.8GB 並在 12GB 顯存硬體上運行的技術細節，指出雖然透過 GSQ 量化技術實現了壓縮，但視覺投影器（MM Proj）未壓縮導致記憶體極度緊繃，且存在長上下文 Bug、軟體相容性問題及黑盒量化帶來的穩定性風險。

## 核心重點

*   **壓縮技術與架構**：使用 GSQ（一種標量量化方法）結合「精確預算約束」（Exact Budget Constraints）算法，將 270 億參數模型壓縮至 11.8GB。模型採用非均勻量化，將 851 個張量分佈在 11 種不同的存儲格式中，部分組件（如 Feed forward gate）被壓縮至極低比特（低至 1.75 bits）。
*   **記憶體陷阱與視覺投影器**：標題中的 11.8GB 為十進位 GB，而 12GB 顯存為二進位 GB。實際模型權重約佔 10.96GB，但獨立的視覺投影器（MM Proj，約 0.87-0.93GB）未壓縮且必須額外載入，導致 12GB 顯卡在載入多模態能力後幾乎無剩餘空間用於上下文（KV Cache）。
*   **架構與長上下文問題**：模型由 48 個循環層（Recurrent layers）和 16 個完整注意力層組成。循環層固定記憶體佔用，使得 12GB 顯存成為可能，但長上下文測試中出現「立即結束文字標記」（End of text marker）的 Bug，模型偶爾會將結束標記作為第一個令牌生成。
*   **軟體相容性與 Bug**：
    *   **Llama.cpp**：多模態工具在編碼圖像時因未預留記憶體導致分段錯誤（Segmentation fault）。
    *   **Olama**：聊天模板拒絕非第一個出現的系統訊息，導致返回空字串。
    *   **LM Studio**：若顯存不足，會將過剩權重靜默推入系統記憶體，而非報錯。
*   **效能與黑盒風險**：實驗室發布的基準測試顯示壓縮模型與原始模型效能接近，但由於採用 11 種混合格式，依賴 11 條不同的程式碼路徑，其中未被廣泛測試的路徑可能導致矩陣乘法錯誤或隨機輸出。外部開發者缺乏關鍵的組裝程式碼，無法自行驗證或最佳化。

## 詳細大綱

### I. 模型壓縮概覽與檔案結構
*   **核心成就**：將 27 billion 參數模型壓縮為單一 11.8 GB 檔案，適合 12 GB 顯存的硬體。
*   **檔案組成**：
    *   下載頁面提供 8 個主要檢查點（Checkpoints），分為兩種方式。
    *   標題中的 11.8 GB 模型是平面選項中最大的，被實驗室推薦為「任務無損構建」（task lossless build）。
    *   **關鍵分離元件**：存在第 9 個檔案，0.93 GB 的視覺投影器（MM Proj）。
    *   8 個主要檢查點不包含視覺投影器，需單獨獲取以使用多模態能力。

### II. 記憶體單位與實際可用空間計算
*   **單位差異**：
    *   顯存標示的 12 GB 為二進位 GB（Binary GB），硬體實際可用空間。
    *   HuggingFace 下載頁面標示的 11.77 GB 為十進位 GB（Decimal GB）。
*   **實際空間分析**：
    *   GSQ RCO 構建的實際權重僅佔 10.96 GB。
    *   12 GB 減去 10.96 GB，剩餘 1.04 GB 自由空間。
    *   標題暗示的 200 MB 餘量被低估，實際餘量更大。

### III. 視覺投影器（MM Proj）的記憶體懲罰
*   **未壓縮的元件**：MM Proj 是唯一未壓縮的檔案，保持原始 16-bit 格式。
*   **記憶體佔用**：
    *   檔案大小為 931 million bytes 或 0.87 GB。
    *   所有構建共用此單一副本，記憶體懲罰固定。
*   **載入方式**：在 Llama.cpp 中需使用單獨的命令列旗標（command line flag）載入，易被忽略。
*   **影響**：載入後，0.87 GB 從 1.04 GB 餘量中消失，幾乎耗盡剩餘空間。

### IV. 量化方法論：GSQ 與精確預算約束
*   **量化方法分類**：
    *   **標量方法（Scalar methods）**：如 GPTQ、AWQ，普及但準確率在 3-4 bits 時達到瓶頸。
    *   **向量/網格方法（Vector/Trellis methods）**：如 Q-tip、AQLM，準確度高但難以實作與擴展。
*   **GSQ 的定位**：
    *   在保持標量網格（scalar grid）的同時縮小準確率差距。
    *   確保壓縮模型與現有標量推理內核（inference kernels）完全兼容。
    *   可直接應用於現有的 GGUF 發布版，提升準確率並導回相同格式。
    *   兼容日常應用程式：Llama.cpp、Olama、LM Studio。
*   **精確預算約束（Exact Budget Constraints）**：
    *   參考論文：《Model Compression with Exact Budget Constraints》（作者：Michael Hellig 和 Dan Allistar）。
    *   問題定義：在總成本預算下，為每個組群分配一種壓縮選項。
    *   優勢：相比基於懲罰的方法，此方法無需超參數調整即可精確滿足預算。
    *   技術原理：通過在邏輯空間（logit space）中沿著平滑曲面（Remmanion manifold）行走的梯度方法。
    *   程序：將每個張量量化為候選格式 -> 搜尋符合預算的分配 -> 拼接成單一檔案。

### V. 模型內部量化細節與張量分佈
*   **張量分佈**：
    *   搜尋算法將 851 個獨立張量分佈在 11 種不同的存儲格式中。
    *   96 個張量保持完整 16-bit 精度。
    *   其餘張量進入較小的量化格式階梯。
*   **具體案例**：
    *   144 個張量分配至 IQ3S 格式，平均落在實驗室設定的 3.5 bits 目標。
    *   **飢餓格式（Starved format）**：Block 13 的 Feed forward gate 被壓縮至 IQ1M 格式，僅 1 和 3/4 bits。
    *   該張量周圍的矩陣採用 2、3、4 bits 格式，該張量是該區域最便宜的選擇。
*   **詞彙表（Vocabulary）佔比**：
    *   超過 11.77 GB 檔案的十分之一為詞彙。
    *   兩個張量（輸出頭 Output head 和嵌入表 Embedding table）共佔 1.12 GB。
    *   所有未壓縮張量合計僅 58 MB（不到 0.5%）。
*   **注意力機制中的非均勻量化**：
    *   單一注意力區塊中，查詢投影（Query projection）獲得最便宜格式，而鍵（Key）和值（Value）保留較貴格式。
    *   跨四個大小預算觀察：飢餓門控在較大預算時僅 1 bit，中間 3-bit 預算時升至 4 bits，最大預算時又降至 2 bits以下。
    *   原因：全域預算優化器不根據重要性排名張量，而是進行位元組交易，僅保護總體預算。

### VI. 效能評估與模型架構
*   **效能數據來源**：僅由進行壓縮的實驗室發布於其模型卡片（Model card），無外部複現。
*   **基準測試結果**：
    *   **AIM25 與 Live Codebench**：推薦的 11.8 GB 檔案與未壓縮的 53.8 GB 原始模型完全匹配（4.6 倍體積縮減）。
    *   **GPQA Diamond**：推薦構建僅落後原始模型 0.5 分。
    *   **3-bit 構建（10.09 GB）**：在主推理基準測試中獲得完美 100 分，在 GPQA Diamond 上僅落後推薦構建 0.5 分。
    *   **2.75-bit 構建**：恢復原始零樣本平均值的 101.8% 8%（註：原文如此），得分高於未壓縮基準。
    *   **8.4 GB 構建**：在 AIM25 上比 Unslaught 的動態量化高出 10 分。
*   **模型架構配置**：
    *   基礎模型配置包含 64 個 Transformer 層。
    *   重複模式：3 個線性注意力層（Linear attention layers）後接 1 個完整注意力層（Full attention layer）。
    *   總計：48 個閾值 Delta 層（Gated delta layers）和 16 個完整注意力層。
    *   確認方式：Llama.cpp 的 Bug 報告與檔案張量名稱。

### VII. 記憶體行為與長上下文問題
*   **層類型與記憶體行為**：
    *   **完整注意力層**：需保留對話中的所有令牌（Token），記憶體隨字數增長。
    *   **循環層（Recurrent layers）**：保持固定大小的摘要，與上下文長度無關（10 字與 10,000 字相同）。
    *   48 個循環層不累積對話歷史，這是 12 GB 顯存能運行此模型的原因。
*   **KV Cache 計算**：
    *   16 個注意力層，每層包含 2 個鍵值張量，4 個頭，每頭 256 個數字，每數字 2 位元組。
    *   每令牌消耗：全精度 64 KB -> 8-bit 34 KB -> 4-bit 18 KB。
    *   48 個循環層：固定消耗 150 MB。
*   **上下文窗口成本**：
    *   阿里巴達宣稱原生 262,000 令牌上下文。
    *   全精度緩存需 16 GB -> 8-bit 需 8.5 GB -> 4-bit 需 4.5 GB。
    *   若 64 層全為注意力層，緩存需 18 GB，無法放入 16 GB 顯存。
    *   開發者在 16 GB 顯存上運行全上下文需使用 4-bit 緩存。

### VIII. 軟體相容性與已知 Bug
*   **長上下文 Bug**：
    *   8 月底開發者提交 Bug 報告：長上下文下，模型偶爾將「結束文字標記」（End of text marker）作為第一個令牌生成，無錯誤提示。
    *   復現情況：在顯存、CPU（相同構建）及獨立代碼庫分支上均可復現。
    *   測試結果：約 113,000 令牌通過，約 130,000 令牌失敗（立即結束），稍深提示則正常。
    *   原因推測：引擎缺陷而非權重問題（相同提示在 VLM 上通過）。
    *   建議：無安全限制，需驗證具體深度。
*   **Olama 相容性問題**：
    *   可直接從 Hugging Face 拉取構建。
    *   問題：聊天模板（Chat template）拒絕非第一個出現的系統訊息（System message）。
    *   後果：發送中途系統訊息會返回空字串和完成狀態，無錯誤。
    *   修復：需對模型檔案進行三行修補。
    *   註：此故障在 8 月針對純權重時被報告兩次，非此構建特有。
*   **Llama.cpp 多模態工具問題**：
    *   問題：編碼圖像時未預留記憶體導致崩潰。
    *   結果：分段錯誤（Segmentation fault），而非報告錯誤。
    *   日誌顯示工具在...（內容截斷）。

### IX. 記憶體溢出與軟體行為比較（分段 2 補充）
*   嘗試分配 247 MB 失敗的案例。
*   LM Studio 的行為：不崩潰，但將過剩權重靜默推入系統記憶體。
*   實驗室指南僅建議搜尋儲存庫，缺乏明確的「模型無法載入」提示。
*   用戶需自行計算記憶體需求（「點擊下載前計算位元數」）。

### X. Blackwell 顯卡與工具包的相容性爭議
*   早期 9 月案例：16 GB Blackwell 顯卡搭配特定工具包版本。
*   Llama.cpp 後端測試失敗：矩陣乘法在三種格式上失敗，包含該構建命名的格式。
*   錯誤率高達 1.1，導致隨機垃圾輸出，但相鄰格式通過測試。
*   用戶反饋分歧：
    *   用戶 A：報告垃圾輸出，通過修改位元處理程式碼本地修復。
    *   用戶 B：在同一晶片世代無法重現，認為問題在於構建鏈而非硬體，因為這些格式沒有晶片特定路徑。
*   結論：選擇包含 11 種格式的檔案意味著依賴 11 條不同的程式碼路徑，爭議集中在最少使用的那些路徑上。

### XI. 最佳化構建與效能取捨
*   **推薦的 3-bit 構建**：
    *   下載頁面大小：10.09 GB。
    *   顯卡單位大小：約 9.40 GB。
    *   剩餘緩衝：1,624 MB。
    *   帶圖像上下文上限：約 26,000 個 token。
    *   純文字上下文上限：40,000 個 token。
*   **更低比特構建（2.75 bit）**：
    *   進一步拉伸上述數字。
*   **準確度代價**：
    *   GPQA Diamond：下降 0.5 分。
    *   Live Codebench：下降 1 分。
    *   AIM25：保持完美分數 100 不變。
*   **代價換取**：約 26,000 個 token 的對話空間。
*   **注意**：這些是絕對數學上限，未包含運行時工作緩衝區，實際容量更低。

### XII. 外部開發者的困境與技術黑盒
*   兩個團隊向實驗室儲存庫提交請求，要求公開關鍵程式碼，目前無回覆。
*   缺失的關鍵組件：
    *   每張量成本模型（per tensor cost model）。
    *   兩個預算的設定（settings for two of the budgets）。
    *   組裝混合格式檔案的匯出程式碼（export code）。
    *   候選生成（candidate generation）完全缺失。
*   開發者需求原因：伺服器叢集受限於記憶體頻寬而非容量，較小檔案帶來直接速度優勢，混合格式是唯一的實際部署路徑。
*   實驗室方法論：混合精度量化、非均勻剪枝、選擇保留哪些專家，本質上是將 K 個選項分配給 N 個組的問題，用於將幾乎任何內容適應固定記憶體佔用。
*   最終結論：實驗室發布了單一特定模型預算的完成答案，但未發布適用於其他模型的通用方法。

## 工具 / 模型 / 名詞整理

*   **模型/技術名稱**：
    *   Quen's 27 billion parameter model
    *   GSQ RCO build
    *   MM Proj (Vision projector)
    *   GPTQ
    *   AWQ
    *   Q-tip
    *   AQLM
    *   GGUF
    *   IQ3S
    *   IQ1M
    *   AIM25
    *   Live Codebench
    *   GPQA Diamond
    *   Unslaught's dynamic quantizations
    *   VLM
    *   Llama.cpp
    *   Olama
    *   LM Studio
    *   HuggingFace
    *   Blackwell (顯卡晶片世代)

*   **論文/作者**：
    *   《Model Compression with Exact Budget Constraints》
    *   Michael Hellig
    *   Dan Allistar

*   **其他專有名詞**：
    *   Binary gigabytes
    *   Decimal GB
    *   Scalar inference kernels
    *   Logit space
    *   Remmanion manifold
    *   Transformer layers
    *   Linear attention layers
    *   Full attention layers
    *   Gated delta layers
    *   KV Cache
    *   End of text marker
    *   Segmentation fault
    *   Recurrent State Layers
    *   bite handling code (疑為 bit handling code