<?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[自制给R9700用的paiton/vLLM专用去审查的极速27B-W3A4权重，MMLU-Pro从 56.7 拉到 57.86]]></title><description><![CDATA[<h1>把去审查的 27B 塞进官方 3-bit 栈：MMLU-Pro 从 56.7 拉到 57.86，同题追平官方权重</h1>
<p dir="auto"><img src="https://photos-9ocd.infocused.cc/static/img/a26f25bc8bf2ace9f11ed34abfab4c24.q_zh.webp" alt="质量对比" class="img-markdown  img-fluid" /></p>
<h2>一、背景与结论</h2>
<p dir="auto">经过最近的高强度折腾，手上这台R9700跑的Paiton 的 官方27B（W3A4）速度飞起也很稳，还能八路并发，但它有个毛病：你不让它说的它不说。但是这个框架又只认官方特殊的定制3-bit——想两条都要，只能自己做一套 3-bit的权重了，在这里分享给卡友，可以直接拿去用。</p>
<p dir="auto">结论先放这：</p>
<ul>
<li>格式逆向成功，打包器做到<strong>字节级往返</strong>（解包→重量化→重打包，6/6 张量完全一致）；</li>
<li>先做 abliteration 再量化，<strong>顺序反了会白干</strong>（下面解释）；</li>
<li>同样的 2,800 道 MMLU-Pro 随机题：官方 57.82%，自建 RTN 56.68%，<strong>自建 GPTQ 57.86%</strong>；</li>
<li>BetterBench 单流加权 155.0 vs 官方 174.3（89%），8 并发 436.8 vs 458.9（95%）——差的不是权重，是我这台虚拟机。</li>
</ul>
<h2>二、为什么不能直接改 3-bit 权重</h2>
<p dir="auto">abliteration 是 rank-1 编辑：从 <code>o_proj</code>/<code>down_proj</code> 里把拒绝方向减掉。听着很简单，但 3-bit 是分组量化，步长 0.0067，权重 σ 只有 0.0106——<strong>一个步长就是 0.62 个 σ</strong>。</p>
<p dir="auto">实测 λ=1 的编辑，每个元素只挪 0.03–0.05 个步长，重新四舍五入之后<strong>一个码都不变</strong>。也就是说：量化后的模型和原模型是同一个模型，你改了个寂寞。</p>
<p dir="auto">所以顺序只能是：<strong>bf16 阶段去审查 → 再量化</strong>。这也是为什么社区的去审查模型都发 Q4/Q5，没人发 Q3。</p>
<h2>三、格式：<code>paiton-w3rot-v1</code></h2>
<p dir="auto">官方没文档，从分片头反推：</p>
<ul>
<li>旋转站点右乘 block-diagonal Hadamard-128（<code>W·H128</code>），<strong>激活侧要同步旋转</strong>，不然 Hessian 算错；</li>
<li>3-bit 对称、group=128、<code>q∈[-4,3]</code> 存成 <code>u=q+4</code>，<strong>scale 是有符号 bf16</strong>（一半是负数）；</li>
<li>dense LSB-first 位流打进 int32；</li>
<li><code>in_proj_a/b</code> 是 bf16 的 <code>weight_rot_h128</code>；manifest 里 <code>side.source_sha256_by_layer</code> 校验的是<strong>源 bf16 的字节</strong>，不是分片哈希——这个坑我踩过一次，加载器直接拒载。</li>
</ul>
<h2>四、32G 显存下的 GPTQ</h2>
<p dir="auto">27B bf16 是 54 GB，一张 32G 卡装不下，更别说还要留显存给 Hessian。做法：</p>
<ul>
<li>用 bitsandbytes <strong>NF4 4-bit</strong> 加载 abliterated 权重跑校准（4-bit 的激活误差对 Hessian 估计可以忽略）；</li>
<li>attention 必须用 <strong>eager</strong>：这套 ROCm 上 sdpa 跑 16×2048 会直接 <code>invalid argument</code>，不是 OOM，报错很误导；</li>
<li>8×2048 × 4 批 = <strong>65,536 token</strong>（WikiText-103 + 中文维基）；</li>
<li>Hessian 按 128 列分组存<strong>块对角</strong>（136 个 128×128），量化时组内做 GPTQ 列级误差补偿，组 scale 还是原来的 14 候选搜索。</li>
</ul>
<h2>五、折腾经过</h2>
<ul>
<li>第一版想用全 Hessian，8 个 down_proj 的 H 就要 10 GB，加上模型直接 OOM；</li>
<li>16 序列一批也 OOM（30.5 GB 已分配），降到 8 序列才稳；</li>
<li>把 Hessian 放 CPU 上算——device 不匹配，白跑一次 3 分钟加载；</li>
<li>sdpa 的 <code>invalid argument</code> 查了半天，最后发现换 eager 就好；</li>
<li>块对角 H 是妥协：全 H 能再抠一点，但显存不够，先这样。</li>
</ul>
<h2>六、结果</h2>
<p dir="auto">同题同口径（2,800 题，14 类 × 200，seed 42，0-shot，温度 0）：</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>权重</th>
<th style="text-align:right">MMLU-Pro</th>
</tr>
</thead>
<tbody>
<tr>
<td>官方 W3A4</td>
<td style="text-align:right">57.82%</td>
</tr>
<tr>
<td>自建 RTN</td>
<td style="text-align:right">56.68%</td>
</tr>
<tr>
<td>自建 GPTQ</td>
<td style="text-align:right"><strong>57.86%</strong></td>
</tr>
</tbody>
</table>
<p dir="auto">其余：GSM8K 93.10%（1,319 题）、HumanEval 90.24%（164 题）、Needle@61,440 160/160。</p>
<p dir="auto">速度（BetterBench 20 passes，单流中位数）：</p>
<p dir="auto"><img src="https://photos-9ocd.infocused.cc/static/img/900cfdfd07a43daabcafff4c8544586e.s_zh.webp" alt="速度对比" class="img-markdown  img-fluid" /></p>
<p dir="auto">单流加权 155.0 vs 174.3，8 并发 436.8 vs 458.9。<strong>差距是宿主</strong>：这台是 KVM 虚拟机 + 2019 年的 Xeon Gold 6252，每步 host 侧的调度/采样开销比裸金属高；同机换官方权重测出来速度一模一样，所以不是权重或格式的问题。</p>
<h2>七、一个被证伪的结论</h2>
<p dir="auto">官方 README 写 MMLU-Pro 59.71，我第一版 RTN 只有 54.6，看着差了 5 分，一度以为是自己量化太糙。后来把官方权重复现到同一套题干上——<strong>官方自己也只有 57.82</strong>。</p>
<p dir="auto">那 5 分里，真正属于量化的只有 1.18 分，剩下全是口径（BetterBench full vs 0-shot 同题）。教训：跨口径比分数，比不出东西。</p>
<h2>八、复现</h2>
<pre><code class="language-bash">python3 scripts/build_gptq2.py --src /path/to/abliterated-bf16 --out ./out \
        --calib calib.txt --batches 4 --nseq 8
python3 scripts/gen_manifest.py ./out /path/to/official/w3rot-manifest.json /path/to/abliterated-bf16
</code></pre>
<p dir="auto">模型在盘上的话，构建大约 10 分钟。</p>
<ul>
<li>Fork 仓库（脚本 + 结果）：<a href="https://github.com/halonc/paiton-vllm-plugin-27b-w3a4-abliterated" rel="nofollow ugc">https://github.com/halonc/paiton-vllm-plugin-27b-w3a4-abliterated</a></li>
<li>权重：<a href="https://huggingface.co/halonc/Qwen3.8-27B-W3Rot-INT3-Paiton-RDNA4-abliterated" rel="nofollow ugc">https://huggingface.co/halonc/Qwen3.8-27B-W3Rot-INT3-Paiton-RDNA4-abliterated</a></li>
<li>图文版：<a href="https://blog-eudc.infocused.cc/qwen38-27b-w3a4-abliterated/" rel="nofollow ugc">https://blog-eudc.infocused.cc/qwen38-27b-w3a4-abliterated/</a></li>
</ul>
<h2>说明</h2>
<p dir="auto">块对角 Hessian 不是全 Hessian；没做 scale 蒸馏；abliteration 拆的是拒绝回路，不是政治立场；只在一张卡上验证过。权重 Apache-2.0，派生自 huihui 的 abliterated 检查和 unsloth 的 NVFP4 基座，仅供研究与自用。</p>
<p dir="auto">个人的 repo，欢迎指教。</p>
]]></description><link>https://lcz.me/topic/2714</link><generator>RSS for Node</generator><lastBuildDate>Tue, 10 Nov 2026 01:12:23 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/2714.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 30 Oct 2026 12:30:09 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 自制给R9700用的paiton/vLLM专用去审查的极速27B-W3A4权重，MMLU-Pro从 56.7 拉到 57.86 on Fri, 30 Oct 2026 12:51:07 GMT]]></title><description><![CDATA[<p dir="auto">发个帖子mark一下，做笔记了</p>
]]></description><link>https://lcz.me/post/29555</link><guid isPermaLink="true">https://lcz.me/post/29555</guid><dc:creator><![CDATA[fcme]]></dc:creator><pubDate>Fri, 30 Oct 2026 12:51:07 GMT</pubDate></item></channel></rss>