<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI]]></title><description><![CDATA[<p dir="auto">這篇如其說是心得不如更像說是筆記, 寫來分享一下, 有錯歡迎指出</p>
<p dir="auto">模型消耗VRAM基本上就2個方向, 模型權重 (Model Weight)以及KV Cache, 引擎如果涉及到Pytorch跟Transform運算的話基本上也會使用部分, 但在引擎準備完後則會歸還, 這也是通常在任何引擎啓動時最容易撞到OOM的時候</p>
<p dir="auto">其實整個量化技術都在圍繞這個問題: "<em><strong>如何盡力壓縮模型後同時保持解壓縮後的精度</strong></em>"</p>
<p dir="auto">基本上在HF下載模型的時候我們都會遇到Model Card, 上面通常寫著模型的基本參數, 有時也會有寫關於這個模型的量化標準, 但是很多時候用家就直接下載, 沒有太管它的量化技術, 個人感覺這個算是有點遺憾的地方, 所以也誕生了這篇文</p>
<p dir="auto">其實我也順便拿來測試一下我自己的27B在應付非編程跟學術文章上的表現, 主要是用RAGFlow + 自己vLLM, GPT + Gemini負責外向尋找資料跟提供原鏈接, 27B則是助手負責整理, 這個也算一個系列吧, 留言主要就是一個分類, 避免把一卡車的信息塞在一起</p>
]]></description><link>https://lcz.me/topic/551/淺談模型權重以及kv-cache的量化-gguf-k-quant-i-quant-awq-gptq-autoround-smoothquant-turboquant-kivi</link><generator>RSS for Node</generator><lastBuildDate>Wed, 01 Jul 2026 09:31:33 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/551.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 13 Jun 2026 14:45:23 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 28 Jun 2026 02:37:06 GMT]]></title><description><![CDATA[<p dir="auto">非常好的系列，再次置顶。</p>
]]></description><link>https://lcz.me/post/8605</link><guid isPermaLink="true">https://lcz.me/post/8605</guid><dc:creator><![CDATA[terry]]></dc:creator><pubDate>Sun, 28 Jun 2026 02:37:06 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 28 Jun 2026 02:42:59 GMT]]></title><description><![CDATA[<p dir="auto">然後額外再補充一點</p>
<p dir="auto">正常的模型都會默認為W4A16 / W8A16, Smooth Quant則為W4A8 / W8A8 / W4A4</p>
<p dir="auto">前面的Wx 指的就是儲存權重的Bit, 然而這個Bit單看數字某個程度上省略一個蠻重要的資訊:</p>
<p dir="auto"><em><strong>模型是否在訓練階段特意選用低精度訓練</strong></em></p>
<p dir="auto">正常來説大部分的模型都是BF16 / FP16 甚至 FP32等高精度開始訓練, 再將權重量化</p>
<p dir="auto">然而DeepSeek V4 自己提出的<a href="https://arxiv.org/html/2606.19348v1" rel="nofollow ugc">學術期刊報告</a> 則寫明團隊打從訓練一開始目標就是使用低精度 (FP4 + FP8) 混合來進行量化感知訓練 (QAT, Quantization-Aware Training)</p>
<p dir="auto"><em><strong>目的是强迫模型一開始就在低精度下進行模型訓練, 解決的就是在傳統量化後低精度推論下精度降低的問題</strong></em></p>
<p dir="auto">某個程度上這個也是推進低成本訓練的關鍵, 畢竟相對以前訓練能降低顯存用量, 也是DeepSeek V4能夠這麽便宜的其中一個原因</p>
]]></description><link>https://lcz.me/post/8549</link><guid isPermaLink="true">https://lcz.me/post/8549</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Sun, 28 Jun 2026 02:42:59 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sat, 27 Jun 2026 13:50:23 GMT]]></title><description><![CDATA[<hr />
<h2>模型激活量化方式: SmoothQuant</h2>
<p dir="auto">正如之前的文章所說, 目前大部分模型都是W4A16 / W8A16, 自然就有專家會去探討激活參數中的16Bit (無論是FP16還是BF16) 是否能量化</p>
<p dir="auto">但是他們遇到的問題則是: <em><strong>量化激活比量化權重參數難</strong></em></p>
<p dir="auto">權重量化相對容易是因為分佈平坦且均勻, 然而當大型語言模型的參數規模突破 67 億時，其激活值基本上會出現Outliers (系統性離群值), 則該數值趨近無限大或者無限小 , 比大部分的數值高出不少的倍數</p>
<p dir="auto"><img src="https://upload.lcz.me/uploads/3eba438a-618c-4529-ba1a-64796c9c8553.jpeg" alt="5e767f53-8f79-4feb-9838-2fffbb07064b-image.jpeg" class=" img-fluid img-markdown" /><br />
就是這些圈起來的東西, 雖然這個圖只有寥寥數個, 但是試想一下這個情況套用在DeepSeek 或者 GLM上那恐怖的參數量, 就算單純拿個1%分分鐘也比目前最好的小開源模型 (27B / 31B)大</p>
<p dir="auto">而強行將這些極端離群值壓縮進小整數網格 (INT8 / INT4)的話, 量化範圍必須拉得非常寬, 導致所有正常的較小激活值被壓縮至趨近於零, 進而嚴重摧毀模型的準確度</p>
<hr />
<p dir="auto">不能輕易動激活參數的位置的話, 專家們就把想法從 <em><strong>單純壓縮激活參數</strong></em> 轉移到 <em><strong>將量化的難度從「激活值」轉移至「權重」</strong></em> :</p>
<ol>
<li>縮小包含離群值的問題激活通道的數值</li>
<li>以完全相同的比例放大模型權重中對應通道的數值, 以維持底層數學運算的一致 (Scale Up跟 Scale down的運算)</li>
</ol>
<p dir="auto">透過引入一個叫 遷移強度 (migration strength) 的超參數 (hyperparameter) 來平衡量化難度, 確保權重與激活值都不會過於極端</p>
<p dir="auto">SmoothQuant 是可以成功將激活值同時壓縮到W8A8 (論文中則是使用INT8), 讓硬體得以使用 INT8 * INT8 矩陣乘法, 相較當初的FP16能帶來高達 1.56 倍的加速比並使記憶體佔用量減半, 且幾乎完全不會損耗模型智能</p>
<p dir="auto"><em><strong>SmoothQuant本身并不會針對權重本身進行任何更改, 本意在於調整權重在激活時候的通道數量跟方式</strong></em></p>
<hr />
<p dir="auto">理論比較難懂, 給個比較具體點的例子</p>
<p dir="auto">你準備搬家, 正在打包兩種不同類型的物品：</p>
<ul>
<li>書籍: 這個就是權重, 平坦跟有固定規則, 天生就非常容易打包</li>
<li>衣物: 這個就是激活值, 多數是普通的襯衫/T恤, 但混著幾件巨大且硬挺的冬季大衣/外套 (Outliers)</li>
</ul>
<p dir="auto">儘管裝書本的箱子很迷你方便 (4bit / 8 bit), 但是因爲冬季衣服你不僅需要用個超大箱子裝 (16bit), 而且搬家的車子也被迫需要超大貨車 (不能用普通房車然後把箱子放在頂上吧, 這不是印度)</p>
<p dir="auto">如果盲目硬把衣物塞進 8-bit 箱子, 那件巨大的冬季大衣會佔據太多空間，導致所有普通的衣物被壓到不成樣子</p>
<p dir="auto">SmoothQuant 就像一台 <em><strong>真空壓縮機</strong></em>, 自帶調節功率的功能 (遷移強度)</p>
<p dir="auto">透過調整功率來決定氣壓, 稍微放大書本跟縮小所有衣服, 讓他們能放到8 Bit箱子, 書本跟衣服都要在這裏互相配合才行, 然後所有東西在氣壓回歸正常後就能變回原樣</p>
<p dir="auto">而貨車也能在這裏換成比較快的房車了, 整體搬家 (生成) 的速度也會更快</p>
<p dir="auto">一圖流:<br />
<img src="https://upload.lcz.me/uploads/0b4bc6ab-b25f-440e-a552-30ed2e86329d.jpeg" alt="ca7337fb-6d19-4911-bb26-81785cb21153-image.jpeg" class=" img-fluid img-markdown" /></p>
<hr />
<p dir="auto">因爲Smooth Quant是針對激活參數進行量化, 理論上能配合任何的權重量化方式使用 (K/I Quant, GPTQ/AWQ), 不過我也沒找到huggingface 上有相對應的模型所以也沒有例子, 只找到單純SmoothQuant模型</p>
<pre><code>Locosdeamor/Olmo-3.1-32B-Think-w8a8-smoothquant
</code></pre>
<p dir="auto">混合邏輯就是以下:</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th style="text-align:left">應用情境 / 架構</th>
<th style="text-align:left">量化方案</th>
<th style="text-align:left">技術說明與備註</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left"><strong>Hopper / Ampere</strong>（僅量化權重至 INT4）</td>
<td style="text-align:left"><code>AWQ</code></td>
<td style="text-align:left">若已擁有預訓練權重檔（Checkpoints），<code>GPTQ</code> 同樣適用。</td>
</tr>
<tr>
<td style="text-align:left"><strong>Hopper</strong>（同時量化 INT4 權重與 INT8 激活值）</td>
<td style="text-align:left"><code>AWQ</code> + <code>SmoothQuant</code></td>
<td style="text-align:left">需依序執行：先以 AWQ 壓縮權重，再以 SmoothQuant 平滑激活值。</td>
</tr>
<tr>
<td style="text-align:left"><strong>Blackwell</strong>（權重 FP4 + 激活值 FP4）</td>
<td style="text-align:left"><code>NVFP4</code></td>
<td style="text-align:left">AWQ 的縮放機制已直接整合至 NVFP4 官方量化工具中，無需額外搭配。</td>
</tr>
<tr>
<td style="text-align:left"><strong>CPU / Apple Silicon</strong>（推論部署）</td>
<td style="text-align:left"><code>GGUF</code>（K-quants）</td>
<td style="text-align:left">AWQ 針對 GPU 最佳化；GGUF 則為 CPU/Apple Silicon 專用的底層實作。</td>
</tr>
</tbody>
</table>
<p dir="auto">下回終於聊到關於KV Cache的量化/優化方案, 第一個就是TurboQuant</p>
]]></description><link>https://lcz.me/post/8544</link><guid isPermaLink="true">https://lcz.me/post/8544</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Sat, 27 Jun 2026 13:50:23 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Fri, 19 Jun 2026 04:33:36 GMT]]></title><description><![CDATA[<hr />
<h2>模型權重(優化後的?)量化方式: Autoround</h2>
<p dir="auto">來到一個可能是最多硬件都適配的量化方式了, Intel在2025年4月推出了一個名爲<a href="https://huggingface.co/blog/autoround" rel="nofollow ugc">AutoRound</a>的僅權重訓練後量化技術 (PTQ), 可以當成是上一篇有關AWQ跟GPTQ的衍生, 所以想要瞭解這個之前就需要搞清楚AWQ跟GPTQ的基礎概念</p>
<p dir="auto">儘管上一篇説過AWQ跟GPTQ的4 Bit可以使用其他不同方式 (MXFP4或NVFP4) 來表現, 但是目前大部分流行模型引擎内核都是在使用 <code>awq_marlin</code> (Ampere跟Hopper架構都是), 因此這篇也會以INT4作爲基礎</p>
<p dir="auto">AWQ跟GPTQ在量化後就會進行低精度壓縮, AWQ會使用大量的INT4去先壓縮重要的權重, GPTQ則會直接把重要權重直接變成INT4, 然後在後面未量化的權重去進行補償</p>
<p dir="auto">在這個壓縮過程的 <em><strong>最後</strong></em> 就是使用近約數 (Round-to-Nearest, RTN), 最簡單理解就是四捨五入</p>
<p dir="auto">然後Intel就是在這裏下了功夫, 使用了一個名叫<code>符號梯度下降</code>的技術 (Signed Gradient Descent, SignSGD), 透過反覆測試與學習, 找出捨入 (Round) 權重的絕對最佳方式，以及保存 (Clip, 也叫截斷) 權重範圍的最佳位置</p>
<p dir="auto">流程就是這樣:<br />
<img src="https://upload.lcz.me/uploads/a61bc692-2678-4d6e-95c9-5496eb9ee04b.jpeg" alt="91d541f9-8b00-4332-a558-220c27a6ff1e-image.jpeg" class=" img-fluid img-markdown" /><br />
普通的AWQ / GPTQ基本上量化+壓縮後就直接推到HF用了</p>
<hr />
<p dir="auto">Autoround透過引入一個小型的校準資料集 (約128到512個樣本) 到模型中, 讓模型檢視由壓縮所引起的區塊層級 (Block-wise) 的輸出誤差, 通過稍微調整捨入偏移量 (rounding offsets) 與保存範圍 (clipping ranges), 務求達到最低誤差</p>
<p dir="auto"><img src="https://upload.lcz.me/uploads/1d2fd6e9-ef40-4bb5-a4ca-fdc6392227b8.jpeg" alt="738826f8-0903-4632-bedf-ada418bd77b6-image.jpeg" class=" img-fluid img-markdown" /></p>
<p dir="auto">Autoround自己也支持混合Bit, 比較不重要的權重可以用少點Bit (1到2), 重要的話可以拉滿4個Bit</p>
<p dir="auto"><img src="https://upload.lcz.me/uploads/a95b54f1-2b04-4946-a302-8d28e4fc9a6b.jpeg" alt="7de48d47-eadb-4fd6-be70-89afc2af69c4-image.jpeg" class=" img-fluid img-markdown" /><br />
一個簡單的分佈圖, 然後壓縮後(下圖)會發現其實一個模型重要權重不會太多</p>
<p dir="auto">在輸出層(lm-head), 通常的量化方式都會保留最高精度 (FP16/FP32), Autoround也順道一并把這個壓縮了 (<s>雖然我覺得應該不會有太大影響就是了</s>)</p>
<p dir="auto">正是以上的特點集合, Autoround在低Bit的情況下表現很出色, 很適合用在受限於INT4跟INT8的硬件 (尤其在Turing跟Ampere)</p>
<hr />
<p dir="auto">簡單類比下的話就是</p>
<p dir="auto">GPTQ =&gt; 被動應變的畫家<br />
AWQ =&gt; 主動應對的畫家, 會畫草稿<br />
AutoRound =&gt; 操練過後的畫家</p>
<p dir="auto">本質上GPTQ跟AWQ就是單純使用色盤上顔色最近的顔料, AutoRound就再用一個更小的練習畫布嘗試畫畫看, 發現不對勁就會再調和整體色盤顔色 (例如簡單加黑或者加白來拉高或者拉低對比度), 通過小規模的反復試錯來找出畫整個畫像的規則, 最後用這個方法畫出整圖</p>
<hr />
<p dir="auto">Autoround嚴格上來説是一種屬於優化目前量化的思路, 所以也可以應用在GGUF上面, 所以我們會看到有應用Autoround的K Quant:</p>
<pre><code>sphaela/Qwen3.6-27B-AutoRound-GGUF
</code></pre>
<p dir="auto">理論上I Quant也適用, 不過我還沒見到有人這麽做, 估計可能就是精度損失太大</p>
<hr />
<p dir="auto">Intel 自己也説了<a href="https://www.lmsys.org/blog/2025-11-13-AutoRound/" rel="nofollow ugc">未來的方向就是低精度推算</a>, SGLang配置INT2 到 INT8, MXFP4, NVFP4, FP8, and MXFP8的Autoround, 不過我是不太懂爲什麽特意拿SGLang作爲例子出來說, 可能有特別優化?</p>
<p dir="auto">下篇講講SmoothQuant</p>
]]></description><link>https://lcz.me/post/7448</link><guid isPermaLink="true">https://lcz.me/post/7448</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Fri, 19 Jun 2026 04:33:36 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Fri, 19 Jun 2026 02:26:28 GMT]]></title><description><![CDATA[<p dir="auto">補上AWQ/GPTQ講解圖片跟GGUF解説圖片</p>
]]></description><link>https://lcz.me/post/7419</link><guid isPermaLink="true">https://lcz.me/post/7419</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Fri, 19 Jun 2026 02:26:28 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 14 Jun 2026 07:31:54 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/applejuice" aria-label="Profile: applejuice">@<bdi>applejuice</bdi></a></p>
<p dir="auto">某個程度上算是基礎知識吧, 寫來能分清楚模型量化的技術跟預計效果之類的 <img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f912.png?v=9a87c0a6150" class="not-responsive emoji emoji-android emoji--face_with_thermometer" style="height:23px;width:auto;vertical-align:middle" title=":face_with_thermometer:" alt="🤒" /></p>
]]></description><link>https://lcz.me/post/6791</link><guid isPermaLink="true">https://lcz.me/post/6791</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Sun, 14 Jun 2026 07:31:54 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 14 Jun 2026 06:27:03 GMT]]></title><description><![CDATA[<p dir="auto">给个支持<img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f33b.png?v=9a87c0a6150" class="not-responsive emoji emoji-android emoji--sunflower" style="height:23px;width:auto;vertical-align:middle" title=":sunflower:" alt="🌻" /><br />
我读完了<br />
虽然不一定明白就对了<img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f606.png?v=9a87c0a6150" class="not-responsive emoji emoji-android emoji--laughing" style="height:23px;width:auto;vertical-align:middle" title=":laughing:" alt="😆" /></p>
]]></description><link>https://lcz.me/post/6781</link><guid isPermaLink="true">https://lcz.me/post/6781</guid><dc:creator><![CDATA[applejuice]]></dc:creator><pubDate>Sun, 14 Jun 2026 06:27:03 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 14 Jun 2026 06:11:26 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/terry" aria-label="Profile: terry">@<bdi>terry</bdi></a></p>
<p dir="auto">可能因為大多數我看的資料都來自長文章或者期刊, 這幾篇主要都是消化後的理論跟筆記</p>
<p dir="auto">我下次找找看有沒有類似的文章能借鑑幾張圖, 或者叫gpt畫點圖示意一下吧 <img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f616.png?v=9a87c0a6150" class="not-responsive emoji emoji-android emoji--confounded" style="height:23px;width:auto;vertical-align:middle" title=":confounded:" alt="😖" /></p>
]]></description><link>https://lcz.me/post/6780</link><guid isPermaLink="true">https://lcz.me/post/6780</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Sun, 14 Jun 2026 06:11:26 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Sun, 14 Jun 2026 04:46:19 GMT]]></title><description><![CDATA[<p dir="auto">纯理论，太枯燥，没有图文并茂，看不下去。</p>
]]></description><link>https://lcz.me/post/6771</link><guid isPermaLink="true">https://lcz.me/post/6771</guid><dc:creator><![CDATA[terry]]></dc:creator><pubDate>Sun, 14 Jun 2026 04:46:19 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Fri, 19 Jun 2026 02:01:23 GMT]]></title><description><![CDATA[<hr />
<h2>模型權重量化: AWQ/GPTQ</h2>
<p dir="auto">這個就是常用在vLLM的量化模式 (不是説GGUF不行, 但還在實驗性質)</p>
<p dir="auto">兩者都屬 "僅權重訓練後量化" (Weight-only post-training quantization), 意思指在模型完成訓練後, 特意加入從高精度 (FP32/FP16) 轉換為低精度 (INT8/INT4) 的過程上做特殊處理, 這個就是與GGUF最大的分別</p>
<p dir="auto">GGUF就單純只是將權重分塊打包壓縮, 并不涉及加入變成低精度的過程</p>
<p dir="auto">GPTQ則是轉換時, 將權重壓縮成固定整數並計算誤差, 主要使用海森矩陣 (Hessian Matrix) 動態調整 "剩餘尚未量化的權重" 來進行進行精度補償</p>
<p dir="auto">AWQ則是轉換時, 先尋找重要權重 (很多文章特別用了個salient, 顯著的意思?), 先將以其盡可能保留精度的方式壓縮, 其後再對其他比較不這麽重要的權重進行壓縮</p>
<p dir="auto">示意圖<br />
<img src="https://upload.lcz.me/uploads/711445c1-5bfc-4e8d-85f8-098e0b1fe2cb.jpg" alt="Gemini_Generated_Image_9ib2p09ib2p09ib2.jpg" class=" img-fluid img-markdown" /></p>
<p dir="auto">看見分別了嗎? 一個注重在壓縮前, 一個注重在壓縮後</p>
<p dir="auto">再另外一個簡單類比的方式說其實就是兩個畫家嘗試將一副很大的壁畫畫在一塊小小的畫布上</p>
<p dir="auto">一個畫家選擇直接下手, 以分塊的形式將每一部分都畫在畫布上, 然而因爲缺乏事前分析不可避免地會出現誤差, 然後這個畫師選擇在剩餘的空白畫布進行色差補償, 細看每一塊的話會明顯發現分別, 但是在放大整塊畫布上其實還是能大致看到輪廓</p>
<p dir="auto">另外一個畫家選擇先研究整個壁畫, 找出比較重要/顯眼的部分, 例如人臉, 眼睛, 人的輪廓之類的, 在分析其他比較沒有這麽重要的地方 (例如背景, 天空), 在畫布上提前進行對於重要部分的對等比例縮放, 其他就簡單壓縮</p>
<p dir="auto">示意圖<br />
<img src="https://upload.lcz.me/uploads/98f5daf8-c8a1-4b5b-a2a8-fcb6b2b522ff.jpeg" alt="e9867f96-6596-4536-8287-4bddad1b9820-image.jpeg" class=" img-fluid img-markdown" /></p>
<p dir="auto">從比較高一點的角度看的話, 其實會發現AWQ的思路是跟I Quant十分類似, 兩者都是針對重要權重先進行比例壓縮, 盡可能保留高精度, 其他則按正常情況下壓縮</p>
<p dir="auto">有人可能會問AWQ是不是比GPTQ好, 以精度上是, 但是這個也有代價, 則是AWQ在解壓後的VRAM <em><strong>理論上</strong></em> 會比GPTQ多, 不過這個據聞現在已經有技術控制到兩者差不多了</p>
<hr />
<p dir="auto">那來講一下HF的model card</p>
<p dir="auto">在HF上面會有寫INT4:</p>
<pre><code>cyankiwi/Qwen3.6-27B-AWQ-INT4
</code></pre>
<p dir="auto">其實這個同時也代表4bit, 可以看成</p>
<pre><code>cyankiwi/Qwen3.6-27B-AWQ-4bit
</code></pre>
<p dir="auto">4 bit只是單純指壓縮大小, 然後INT4指是這個壓縮4 bit的方式, 它是用integer裝載這4 bit, 而不是floating point, 理論上,它可以用MXFP4跟NVFP4來裝載這4 bit, 精度損失會比單純用INT4少, 但NVFP4屬於Blackwell架構專用, 其他卡則只能使用MXFP4, 老黃聲稱MXFP4精度會比NVFP4少, 不過目前也算是聲稱吧</p>
<p dir="auto">INT4示意圖:<br />
<img src="https://upload.lcz.me/uploads/b83a2be7-1c81-4dc6-a9d2-810d4da81d87.jpeg" alt="57c576f2-7dfa-4d69-b27c-5f447f2ac6bb-image.jpeg" class=" img-fluid img-markdown" />  紅色是符號位, 藍色則是指數位</p>
<p dir="auto">MXFP4跟NVFP4示意圖:<br />
<img src="https://upload.lcz.me/uploads/302cbe76-aeb9-41fe-8ef5-0b129eb1f1a6.jpeg" alt="883958c0-2b5f-43f7-a25d-8077382047d8-image.jpeg" class=" img-fluid img-markdown" /></p>
<p dir="auto">然後有人可能會見到莫名其妙地有個6bit, 例如這個</p>
<pre><code>QuantTrio/Qwen3.6-27B-AWQ-6Bit
</code></pre>
<p dir="auto">也許有人會好奇說6 bit, 但是顯示卡沒有INT6支持啊? 其實這個就是用了bit packing, 將幾個6 bit壓成多個4 bit再使用INT4的硬件加速</p>
<p dir="auto">示意圖<br />
<img src="https://upload.lcz.me/uploads/eb8ad4e7-d673-4501-9399-545f9bcafd78.jpeg" alt="9dfb7fc4-2bbb-4732-9bb2-11cb8d9e6313-image.jpeg" class=" img-fluid img-markdown" /></p>
<hr />
<p dir="auto">無論GGUF, AWQ, GPTQ怎麽壓縮, 它們都會把Activiation變回FP16, 則是W4A16的樣子</p>
<p dir="auto">而從名字得知, 既然有僅權重訓練後量化, 會有不會有權重與激活一起量化?</p>
<p dir="auto">有的, 這個就是SmoothQuant, 有SmoothQuant W8A8 (INT8), SmoothQuant W4A4 (INT4), 不過這個留在後面吧</p>
<p dir="auto">下一篇講一下Intel出的Autoround, 不過估計得到下周末了</p>
]]></description><link>https://lcz.me/post/6766</link><guid isPermaLink="true">https://lcz.me/post/6766</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Fri, 19 Jun 2026 02:01:23 GMT</pubDate></item><item><title><![CDATA[Reply to 淺談模型權重以及KV Cache的量化, GGUF (K Quant, I Quant), AWQ&#x2F;GPTQ, Autoround, SmoothQuant, TurboQuant, KIVI on Fri, 19 Jun 2026 02:25:27 GMT]]></title><description><![CDATA[<h3>模型權重量化: GGUF</h3>
<p dir="auto">這個相信這裏很多人都會不停接觸</p>
<p dir="auto">GGUF分了2種方式: K Quant或者I Quant</p>
<p dir="auto">最常見的就是K Quant (Q4_K_M之類的), 采用2段式量化進行壓縮/解壓縮 (small block &lt;-&gt; super block), 前面的數字其實代表壓成多少bit的整數, 這個例子就是4-bit integer, 16個可能數字 (2 ^ 4), 後面所跟隨的L/M/S/XS其實就代表混合精度下的壓縮方式</p>
<p dir="auto">簡單類比的話就像是在一個城市裏面會分區域/街區 (super block), 然後區域/街區會再分成一個個獨立屋或者公寓(small block)</p>
<p dir="auto">然後L/M/S/XS其實就代表人住的格式(?)<br />
XS =&gt; 韓國/香港的劏房, 基本上就是一個公寓單位裏面再劃分幾個細房子, 專爲最大容納人數而設計<br />
S =&gt; 正常的公寓, 很多家庭住在同一座建築<br />
M =&gt; 普通獨立屋, 一個家庭一座建築<br />
L =&gt; 占地少點的豪華獨立屋<br />
原生 =&gt; 豪宅</p>
<p dir="auto"><img src="https://upload.lcz.me/uploads/1481ef86-e192-40c2-8f08-c36bf32ac861.jpeg" alt="189dc3d3-37be-43f0-bf22-4770048a8e91-image.jpeg" class=" img-fluid img-markdown" /></p>
<p dir="auto">然後屋子裏面住著有著不同腦容量/IQ的人, Bit per weight越高, 這個人就越聰明</p>
<p dir="auto">聽起來XS很棒是不是? 問題就在於長期住在這裏的人會更加煩躁跟脾氣不好, 對任何人都凶巴巴的, 對於模型來說XS也有同樣的表現, 因爲過度壓縮導致權重在變回FP16/FP32時精度喪失過於嚴重, 表現反而變得更差了</p>
<p dir="auto">然後Bit per Weight的話會基於用K Quant或者I Quant以及壓縮方式的不同而浮動, 這個就要看Model Card有沒有寫了</p>
<p dir="auto">目前K Quant的甜蜜點在於Q4_K_M</p>
<hr />
<p dir="auto">I Quant則是采取與K Quant不同的道路, 這個會針對重要的權重給予更高精度, 進一步壓縮不重要的權重, 用的就是重要矩陣 (Importance Matrix, imatrix) 去判斷權重, K Quant則是均勻量化, 重要跟不重要都用同一個方式打包</p>
<p dir="auto"><em><strong>注意Important Matrix并不能直接與I Quant打上等號, K Quant一樣可以使用imatrix, 這個只是計算方式而已, I Quant的I不代表Imatrix的I</strong></em></p>
<p dir="auto">壓縮方式為XXS / XS / S / M / NL (NL這個比較特別點)</p>
<p dir="auto">基本上可以用K Quant的方式去同樣理解就可以, 然後因爲I Quant其實是爲了在極低Bit per weight保持最高的精度而生, 所以他通常都只到IQ4</p>
<p dir="auto">說一下NL, NL代表的意思是Non Linear, Super block正常情況下用的是256, 這個NL用的則是32, 據聞會比傳統Q4表現更好, 不過也只是傳聞而已</p>
<p dir="auto">目前I Quant的甜蜜點在IQ4_XS</p>
<hr />
<p dir="auto">也許會有人好奇問, 那我該用Q4_K_M還是IQ4_XS, 這個其實取決個人偏好, 這兩個都是4 bit範圍, 只不過通常來説IQ4_XS的Bit per weight會比Q4_K_M小一點, 精度會差一點, 然而卻也因爲小一點, decode速度會比Q4_K_M快一點</p>
<p dir="auto">個人覺得可以記住這一句就可以: <em><strong>越高Bit per weight代表token精度越高, 代價則是decode速度的降低</strong></em></p>
]]></description><link>https://lcz.me/post/6720</link><guid isPermaLink="true">https://lcz.me/post/6720</guid><dc:creator><![CDATA[566656661]]></dc:creator><pubDate>Fri, 19 Jun 2026 02:25:27 GMT</pubDate></item></channel></rss>