显存不够这件事，凡是自己动手跑过大模型的人都被它按在地上摩擦过。加卡是最省事的办法，但多数场景下加不了；换小模型是最不费脑的办法，但效果直接打折。夹在中间的那条路就是把权重压得更小——模型量化。常规做法是统一 4 位或者 8 位，可一旦把位宽压到 2 位附近，统一位宽的精度就开始崩，而 8 位又太占地方。我这两年在几个离线部署项目里反复折腾出来的一个折中方案，就是标题里说的**“二三五六”位量化配合 CPU、GPU 混合推理**：同一个模型里不同层用不同位宽，2 位、3 位、5 位、6 位混着来，把平均位宽压到 3.5 附近，同时把敏感层喂饱；再把这套量化权重按层的算力特征拆开，一部分交给 GPU，一部分留在 CPU，两边各自解包各自的量化权重，只有激活值跨设备流动。
这套东西听起来像是把两件独立的事硬凑在一起，实际上它们是强耦合的：位宽选得怪，解包成本就高；解包成本高，就必须靠混合推理去把不同设备的空闲算力填上。下面我把整个方案从头到尾拆一遍，包括每个参数怎么算出来的、位运算容易写错的地方、以及我实际踩过的几个坑。不管你是在做端侧部署、私有化交付，还是单纯想搞明白非标准位宽量化到底怎么落地，应该都能从里面抠出能直接用的东西。
1. 从一张显存账单说起：为什么要把模型劈成两半跑
1.1 显存、带宽、算力三笔账的失衡点
先算账。一个 70 亿参数左右的模型，fp16 权重是 14 GB，加上 KV cache 和框架开销，一张 16 GB 的卡跑起来已经贴脸了；如果换成 4 位量化，权重降到 3.5 GB 出头，理论上 8 GB 的卡就能装下。但现实是很多人手里只有一张 8 GB 的消费级卡，外加一颗 16 核的 CPU，这时候 4 位量化刚好卡在“能装下但没法跑长上下文”的尴尬位置——KV cache 一涨就爆。
我一开始的思路很简单：那就压到 2 位。结果一测，困惑度直接翻倍，生成的内容开始出现明显的重复和胡言乱语。原因不难理解，2 位只有 4 个量化格点，对权重分布的刻画能力太弱，尤其那些数值跨度大、对输出影响直接的层，被粗暴地塞进 4 个格点里，误差根本没法通过后续的归一化和残差抵消掉。
于是问题变成：能不能不搞“一刀切”的位宽，而是把有限的比特预算花在刀刃上？这就是分层位宽分配，也就是“二三五六”这套组合的由来。而混合推理解决的是另一个维度的问题：就算量化把权重压到 3 GB 以内，剩下的算力瓶颈依然存在——GPU 的显存带宽和 CPU 的内存带宽是两条完全不同的通道，两边同时干活，吞吐才有机会叠起来。
这里有个经常被忽略的点：混合推理不是把同一份权重在两个设备上冗余存放，而是把不同层物理地放在不同设备上。GPU 持有的那部分层，权重就只存在显存里；CPU 持有的那部分，权重就只在内存里。两边各自解包、各自算，中间只传激活值。这个设计决定了很多后续的实现细节，我在第 5 章会展开。
1.2 混合推理里真正需要跨设备传输的是什么
很多人第一次尝试 CPU/GPU 混合推理，会下意识地把“解包后的 fp16 权重”作为传输对象，结果发现慢得离谱。这是典型的路线错误。量化存在的意义就是减少搬运的数据量，你如果把解包结果搬过去，等于把省下来的带宽又原样吐回去，还额外多了一次拷贝。
正确的做法是：解包动作必须发生在计算设备上。GPU 那几层的量化权重常驻显存，GPU 上的 kernel 读进来直接就地解包、就地做矩阵乘；CPU 那几层同理，向量指令读原始字节，解析成定点数后立刻进乘加。跨设备只流动激活值——也就是每一层输出的 hidden state。
算一下激活值的体量：hidden 维度 4096、fp16 存储，单个 token 一层输出是 8 KB。哪怕一次解 32 个 token 的批量，也就 256 KB 量级。这点数据走 PCIe 或者统一内存，开销几乎可以忽略；相比之下，一层 4096×4096 的权重张量就算压到 2.5 位，也有 5 MB 出头。数量级差了二十倍。
所以混合推理的通信开销从来不是瓶颈，瓶颈在两个地方：一是层切分点选得不好，导致两边负载严重不均，一边算完了干等着另一边；二是解包 kernel 写得糙，把省下来的带宽优势又还回去了。这两点是后面几章要重点解决的对象。
顺便提一句，统一内存架构的设备上情况会好一些，因为不需要显式拷贝，但代价是页迁移的抖动——如果层切分点反复横跳，同一块内存页可能在 CPU 和 GPU 之间来回搬，性能反而比显式拷贝更差。这个坑我在一个边缘设备项目上结结实实踩过一次，后面会细说。
2. “二三五六”这组怪位宽不是拍脑袋定的
2.1 位宽选择被硬件指令集绑架
从纯信息论角度看，位宽越连续越好，2 位和 3 位之间明明还有很大空间，为什么非得是整数位、还得是这几个特定的整数？答案不在算法里，在指令集里。
量化权重最终要变成乘加运算。如果硬件有现成的低位宽点积指令，比如一次能吃进若干个 8 位整数做累加，那么 8 位、4 位这类能被整除的位宽就能吃到指令红利；而 3 位、5 位、6 位这些，硬件没有原生支持，必须先解包成 8 位或者 16 位再算，中间多一道转换。
具体到实测数据上，差异很明显：
| 位宽 | 解包路径 | 相对 4 位的额外开销 | 适用判断 |
|---|---|---|---|
| 2 位 | 字节内拆分 + 查表映射 | 约 1.1~1.3 倍 | 极限压缩，需配合非线性码本 |
| 3 位 | 跨字节移位，无原生指令 | 约 1.8~2.2 倍 | 只用在极少数敏感层 |
| 4 位 | 字节高低半拆分，路径成熟 | 基准 1.0 | 主力位宽，但本方案不用 |
| 5 位 | 40 bit 分组，需 64 位寄存器 | 约 1.5~1.7 倍 | 少量中间层补偿 |
| 6 位 | 24 bit 分组，转 8 位有浪费 | 约 1.4~1.6 倍 | 首尾层、输出头 |
| 8 位 | 原生点积指令直接吃 | 约 0.7~0.8 倍 | 精度兜底，但太占空间 |
这张表最关键的一行是 6 位。很多人直觉上觉得 6 位比 8 位省 25% 的空间，应该稳赚，实测下来经常是小幅亏损——因为 6 位解包后要占满 8 位的寄存器槽位，计算密度和 8 位完全一样，但多了一次掩码和移位操作，纯属白干。所以 6 位在本方案里的定位非常明确：只用在那些“8 位浪费、4 位不够”的少数层上，靠数量少来摊薄解包成本。
3 位也是同理。它比 4 位省 25% 空间，但解包要跨字节做移位拼接，成本接近翻倍。如果模型里 3 位层占比超过 15%，整体吞吐就会被拖下水。我的经验阈值是控制在 8% 以内，超过就得回头检查敏感度分配是不是做得太粗。
2.2 分层位宽分配：敏感度矩阵与预算分配
位宽怎么分到每一层？靠拍脑袋肯定不行。我的做法是跑一遍敏感度扫描：把模型逐层单独降一级位宽，测困惑度或者下游任务的准确率变化，得到一个“层 × 位宽”的敏感度矩阵。
具体操作上，先固定一个基准配置（比如全部 6 位），然后每次只把一层从 6 位降到 5 位，记录指标变化；再降到 3 位、2 位，以此类推。这个扫描很费时间，70 亿参数的模型跑一遍大概要小半天，但它是后面所有决策的依据，值得花。
扫完之后你会发现规律非常集中：绝大多数层的敏感度极低，少数几层敏感度高得离谱。典型的高敏感层包括：
- 输入嵌入层和输出头，这两处直接对接词表，量化误差会被 softmax 放大；
- 注意力里负责 value 的投影，误差会直接累加进 KV cache，长上下文下越滚越大；
- 每个残差块的最后一层，因为要和残差直接相加，没有归一化缓冲；
- 归一化层自身的缩放参数，通常直接留 fp16 不动。
低敏感层则集中在中间那些前馈网络的中间投影上，这些层数值分布相对集中、彼此冗余度高，压到 2 位往往只掉零点几个点的困惑度。
拿到矩阵后就是一个带约束的分配问题：总比特预算固定，让整体指标损失最小。我一般用贪心加局部搜索，先按“每省一个比特带来的指标损失”排序，从损失最小的开始降位宽，直到预算用完；然后再做一轮交换，看看能不能把某个 3 位层降到 2 位、把省下的预算给另一个 5 位层升到 6 位，指标反而更好。
分配结果大概长这样（以 32 层模型为例，仅示意比例）：
| 位宽 | 层数占比 | 典型位置 |
|---|---|---|
| 2 位 | 52% | 中段前馈的 gate/up 投影 |
| 3 位 | 8% | 靠近输出端的少数前馈层 |
| 5 位 | 22% | 注意力 Q/K 投影、部分残差末端 |
| 6 位 | 18% | 嵌入、输出头、首尾各两层 |
加权平均下来大概 3.4~3.6 位。对比统一 4 位，显存省了 10% 出头，但精度往往持平甚至略好——因为敏感层拿到了更多比特。这就是这套方案真正的价值所在：不是单纯追求更低位宽，而是在同样的比特预算下重新分配。
2.3 块大小与 scale 开销的账要一起算
说到位宽，很多人只算权重本身的比特数，忘了每组量化都要带一个缩放系数。这个开销在低位宽下占比非常吓人，必须一起算。
假设每个量化块 32 个权重共享一个 fp16 缩放系数，那么实际平均位宽是：
- 2 位：(32 × 2 + 16) / 32 =2.5 位
- 3 位：(32 × 3 + 16) / 32 =3.5 位
- 5 位：(32 × 5 + 16) / 32 =5.5 位
- 6 位：(32 × 6 + 16) / 32 =6.5 位
看到了吗，2 位量化实际是 2.5 位，多出来的 25% 全是缩放系数的开销。如果把块大小放大到 64，2 位能降到 2.25 位；放到 128，降到 2.125 位。但块越大，块内数值分布越分散，量化误差越大，精度会掉。
我在实际项目里试过的折中方案是分级块大小：2 位层用 32 的小块，因为 2 位本身精度就紧，块再大就崩；5 位、6 位层用 64 甚至 128 的块，因为这些位宽有富余精度，块放大一点损失可控，还能把缩放系数的开销摊薄。
还有一招更激进：缩放系数本身也用 8 位浮点存。这样 2 位 + 块 32 的组合，平均位宽降到 (64 + 8) / 32 = 2.25 位。代价是缩放系数的表示范围变窄，遇到极端离群的权重块会溢出，需要在量化前做一次截断。我的做法是先统计所有块的缩放系数分布，把超出 8 位浮点表示范围的块单独挑出来，这批块回退到 fp16 存，其余走 8 位。实测下来被挑出来的块不到 0.3%，几乎不影响整体。
还有一点容易忽略：如果采用非对称量化（带零点偏移），零点本身也要占空间。2 位非对称量化，每个块要存一个 2 位的零点，开销立刻变成 (32×2 + 16 + 2)/32 ≈ 2.56 位。所以我倾向于在 2 位和 3 位上强制用对称量化，把零点省掉，靠块内的缩放系数去吸收偏移；5 位和 6 位精度富余，才用非对称，多出来的那点开销无所谓。
3. 非 2 的幂位宽在内存里长什么样
3.1 三种位宽的打包单元设计
真正写代码的时候，第一个绕不过去的问题就是：3 位、5 位、6 位这些不是 2 的幂的位宽，在内存里怎么摆？
答案是把若干个值打包成一个字节块，让这个字节块的字节数是整数。具体来说，找一个最小的正整数 n，使得 n × 位宽 能被 8 整除：
- 3 位：n = 8，8 × 3 = 24 bit = 3 字节
- 5 位：n = 8，8 × 5 = 40 bit = 5 字节
- 6 位：n = 4，4 × 6 = 24 bit = 3 字节
- 2 位：n = 4，4 × 2 = 8 bit = 1 字节
这四组打包单元就是整个内存布局的地基。注意 3 位和 6 位都落在 3 字节上，但含义完全不同：3 字节里塞 8 个 3 位值，或者塞 4 个 6 位值。这个巧合挺好用，意味着解包函数可以共用一套“读 3 字节成 24 位整数”的骨架，只是后面的移位序列不同。
设计打包单元的时候有个隐含约束：单元的字节数最好能被 4 整除，或者至少能被 2 整除。3 字节和 5 字节都不满足，这会导致做向量化加载的时候地址不对齐，性能损失大概 5%~15%。我试过两种规避办法：一是把多个打包单元组成一个更大的 super-block，让总字节数是 16 的倍数（比如 3 位的时候，16 个打包单元 = 48 字节，还是不对齐；32 个 = 96 字节，还是不对；得凑到 80 个才 240 字节……算了）；二是干脆放弃块内对齐，只保证整个张量的起始地址 64 字节对齐，解包时用非对齐加载指令。第二种更实际，我最终采用的就是这个。
3.2 解包的位运算写法与边界处理
以 6 位为例，3 字节存 4 个值，解包代码大概长这样：
// 输入 ptr 指向 3 个连续字节，输出 4 个 0~63 的整数 static inline void unpack_6bit(const uint8_t *ptr, int32_t out[4]) { // 读成 32 位，高位补零；注意 ptr 可能不对齐，用 memcpy 让编译器生成非对齐加载 uint32_t v = 0; memcpy(&v, ptr, 3); // 只读 3 字节，最高 8 位保持 0 out[0] = (int32_t)( v & 0x3F); out[1] = (int32_t)((v >> 6) & 0x3F); out[2] = (int32_t)((v >> 12) & 0x3F); out[3] = (int32_t)((v >> 18) & 0x3F); }这里有个陷阱：memcpy(&v, ptr, 3)在小端机器上是对的，因为低地址字节对应低位。但如果你的权重文件要在不同字节序的机器间流转，就必须在序列化时统一约定字节序，读入后按需转换。我吃过一次亏，在一个异构集群上部署，一部分机器的字节序不同，加载出来的权重全是乱的，排查了大半天才发现是这里。
3 位的解包更麻烦一点，因为要跨字节：
// 3 字节存 8 个 3 位值 static inline void unpack_3bit(const uint8_t *ptr, int32_t out[8]) { uint32_t v = 0; memcpy(&v, ptr, 3); // 逐个取出，注意第 3 个值跨越了字节边界 out[0] = (int32_t)( v & 0x07); out[1] = (int32_t)((v >> 3) & 0x07); out[2] = (int32_t)((v >> 6) & 0x07); out[3] = (int32_t)((v >> 9) & 0x07); out[4] = (int32_t)((v >> 12) & 0x07); out[5] = (int32_t)((v >> 15) & 0x07); out[6] = (int32_t)((v >> 18) & 0x07); out[7] = (int32_t)((v >> 21) & 0x07); }写这种代码最容易犯的错误是手滑写错移位量。3 位的时候移位序列是 0、3、6、9、12、15、18、21，中间有个 6 到 9 的跨字节跳变，我见过不止一个人在这里把 9 写成 8。检验办法很简单：造一组已知数据，打包再解包，逐位比对；再拿一组全 0x07 的数据测，如果解出来不是全 7，掩码就错了。
5 位的解包单元是 5 字节存 8 个值，40 位超过了 32 位寄存器，得用 64 位来读：
static inline void unpack_5bit(const uint8_t *ptr, int32_t out[8]) { uint64_t v = 0; memcpy(&v, ptr, 5); // 同理，非对齐安全 for (int i = 0; i < 8; ++i) { out[i] = (int32_t)((v >> (5 * i)) & 0x1F); } }这个循环如果编译器不给你展开，手动展开会快很多。我在一个 ARM 平台上测过，手动展开比循环快将近一倍，因为循环里的变量移位在部分架构上是多周期指令。
3.3 内存排布：scale 和数据谁在前
打包搞定了，下一个决策是缩放系数和量化数据的内存排布关系。两种主流做法：
交错排布：每个块的缩放系数紧跟着该块的数据。好处是访问局部性好，一次预取就能把系数和数据都拉进缓存，解包时不用二次访存；坏处是块的起始地址不对齐——一个块的数据 12 字节加 2 字节系数是 14 字节，循环下来每个块的偏移都不同，没法用固定步长做向量化。
分平面排布：所有缩放系数集中放一块连续内存，所有量化数据放另一块。好处是系数可以一次性批量加载，向量化友好，地址计算简单；坏处是多一次访存，而且系数和数据分别占据不同的缓存行，缓存压力稍大。
我两套都实现过，实测结论是：GPU 上用交错，CPU 上用分平面。原因是 GPU 的延迟隐藏靠大量并发线程，交错排布能减少访存事务数，收益明显；CPU 靠预取和向量化，分平面的规整地址更容易让编译器和硬件预取器发挥作用。
还有一个细节：缩放系数的排列顺序最好和 GPU 上的线程块划分对齐。比如一个线程块处理 128 个权重，那这 128 个权重对应的 4 个缩放系数（块 32 的情况下）最好落在同一个 128 字节的缓存行里。这个对齐做不做，实测在 2 位层上能差出 8% 左右的吞吐。
4. 反量化 kernel：把解包藏进计算里
4.1 CPU 侧：查表 vs 位运算的选择
CPU 上解包 2 位权重，有两种典型写法。第一种是纯位运算：读一个字节，四次移位加掩码取出四个值。第二种是查表：字节有 256 种取值，预先算好每种取值对应的四个值，直接查一张 256×4 的表。
我一开始用的是位运算，觉得查表要访存，应该更慢。实测打了脸：在 256 位向量指令下，查表反而快 20% 左右。原因在于，字节置换类指令可以一次性把 32 个字节的下标映射成查表结果，相当于一条指令完成 32 个字节的拆分，而位运算要好几条指令才能处理同样多的数据。
具体思路是：把 256 项查找表按 16 项一组拆成 16 张子表，用字节置换指令做两级查表——先取高 4 位查第一级，再取低 4 位查第二级，两次结果拼起来就是完整的四个值。这个技巧在 4 位量化里很常见，2 位同样适用，只是表更小。
不过查表法有个前提：量化格点到实际数值的映射必须是线性的，或者至少能预先枚举。如果用了非线性的码本（比如对 2 位量化做 k-means 聚类，四个格点不是等距的），那查表就得换成真正的码本索引查表，每次要多一次间接寻址，性能掉得比较多。这也是为什么我在 2 位层上倾向于保持线性对称量化，把非线性码本留给那些确实必要的少数层。
还有一个 CPU 侧的经验：解包和乘加要融在一个循环里，不要分两趟。我见过一些实现先把整层的权重解包到一个 fp32 缓冲区，再做矩阵乘，结果内存带宽直接被这个中间缓冲区吃满，量化白做了。正确做法是一边解包一边累加，中间值只在寄存器里存在。这就要求循环顺序按输出维度展开，让解包出来的值立刻被用完。
4.2 GPU 侧：解包与张量核心的配合
GPU 上的核心矛盾是：张量计算单元喜欢规整的 8 位或 16 位输入，而我们的权重是 2/3/5/6 位。这中间的转换必须做得极其廉价，否则张量单元再快也没用。
我的做法是分两步走。第一步，用字节置换和位选择指令把打包数据拆成 8 位整数，这一步是纯整数操作，不占张量单元的流水线；第二步，把 8 位整数送进点积累加指令。关键是把第一步的延迟藏到第二步的计算后面——具体来说，在处理当前批次的数据时，预取并解包下一批的数据，用双缓冲的寄存器组交替。
对于 2 位，还有一个更激进的优化：把 2 位值直接映射成 8 位整数的四个常量，用选择指令而不是查表。因为只有 4 种取值，可以用两条位选择指令拼出来，比查表少一次全局访存。实测在 2 位层占比超过一半的模型上，这个优化能带来 6%~9% 的端到端提升。
5 位和 6 位在 GPU 上相对尴尬。解包成 8 位之后，高两位是浪费的，张量单元的计算密度和纯 8 位一样，但多花了指令。所以这两个位宽在 GPU 上的性价比不如在 CPU 上——CPU 那边本来就是标量或向量整数运算，浪费不浪费无所谓。这也是我把 5 位层更多分配给 CPU 侧的原因之一，下一章会细说。
还有一个必须处理的细节：累加精度。2 位量化的缩放系数很小，累加过程中如果中途降到 fp16，误差会累积得很难看。GPU 上的点积累加指令通常输出 32 位整数，转成浮点后乘以缩放系数，这一步必须用 fp32，不能省。我试过为了省寄存器用 fp16 累加，困惑度直接涨了 0.4，得不偿失。
4.3 双缓冲与流水线掩盖延迟
不管 CPU 还是 GPU，解包的本质都是“用算力换带宽”，所以要确保解包的指令周期能被矩阵乘的计算周期盖住。做法是双缓冲：准备两组缓冲区，一组正在被计算消费，另一组同时在解包填充，两者交替。
在 CPU 上，这个靠手动展开循环加软件预取实现。具体来说，处理第 i 个块的时候，用预取指令把第 i+4 个块的原始数据拉进缓存，同时在寄存器里解包第 i+1 个块。预取距离 4 是我在几个平台上试出来的经验值，太近了来不及，太远了缓存被冲掉。
在 GPU 上，双缓冲体现在共享内存的使用上：一个线程块把当前 tile 的量化权重从全局内存搬到共享内存并解包，同时另一个 warp 在解包下一 tile。这里要注意共享内存的容量限制，2 位量化虽然全局内存占用小，但解包后的中间结果如果全放共享内存，容量反而吃紧。我的做法是只把解包结果的一部分放共享内存，其余留在寄存器里，靠 warp 内的数据交换来复用。
这套流水线做下来，2 位层的实际吞吐能接近理论带宽的 70%~80%，不做的话只有 40% 出头。差距主要就在解包这一步有没有被藏住。
5. 调度层：CPU 和 GPU 怎么分工不打架
5.1 层切分与 KV cache 的归属
层切分点的选择直接决定混合推理的成败。最朴素的想法是按算力比例切——GPU 快就多分点，CPU 慢就少分点。但实际约束比这复杂。
第一个约束是显存容量。GPU 侧要装下的不只是权重，还有 KV cache。如果 GPU 只负责前几层，那这几层的 KV cache 也在显存里，占用相对可控；但如果切分点靠后，GPU 要维护的 KV cache 就大。我的经验是先按显存容量反推 GPU 最多能装几层，把这个作为上限，再在算力平衡的角度往下调。
第二个约束是跨设备依赖。注意力层的计算依赖完整的 KV cache，如果某一层的 Q 在 GPU 上算、K 和 V 在 CPU 上算，那就得把 KV 来回搬，非常糟糕。所以切分点必须落在完整的层边界上，绝不能把一个注意力块拆开。这一条听起来是常识，但我在早期实现里为了追求负载均衡，动过“把注意力的 QKV 投影拆开”的念头，测下来通信开销直接翻了三倍。
第三个约束是首尾层的特殊性。嵌入层和输出头通常用 6 位甚至 8 位，解包成本高但计算量相对小。如果把输出头放在 CPU 上，最后一步的延迟会很明显，因为输出头要跟整个词表做投影，计算量其实不小。我一般把嵌入和输出头都放 GPU，中间的前馈层按比例分给 CPU。
一个典型的切分是：GPU 持有前 40% 的层加上输出头，CPU 持有中间 60%。这个比例不是固定的，得看具体设备的算力比。我在一张中端卡配 16 核 CPU 的机器上测出来最优点在 45/55 附近，换到高端卡配低频 CPU 就变成 70/30。
5.2 同步粒度与线程模型
同步粒度是第二个大坑。最细的做法是每个算子同步一次，最粗的是整层算完再同步。前者同步开销巨大，后者会让流水线停顿。
我采用的是按层同步 + 异步预取的折中方案：GPU 算完第 i 层，通过事件通知 CPU 可以开始第 i+1 层；同时 CPU 在第 i 层还在算的时候，就已经把第 i+1 层需要的数据准备好。两边通过一个双缓冲的激活值队列连接，队列深度 2 就够，太深了反而增加延迟。
线程模型上，CPU 侧用一个主线程做调度、若干个工作线程做矩阵乘。工作线程的数量不要开满物理核，留一到两个核给调度和内存拷贝，否则会出现调度线程被抢占、流水线卡顿的情况。我在一台 16 核机器上试过开 16 个工作线程，吞吐反而比开 14 个低 8%。
还有一个隐藏的同步点：内存分配。如果每层都动态申请激活值的缓冲区，分配器本身会成为串行瓶颈。解决办法是启动时一次性申请一大块内存做池化，所有中间缓冲区从池里切，这样运行时完全没有分配开销。这个优化看起来和量化无关，但在混合推理场景下影响很大，因为跨设备的缓冲区生命周期管理更复杂，动态分配更容易出问题。
5.3 实测中的失衡与再平衡
纸面算得再漂亮，实测总会失衡。我遇到的典型情况是：GPU 侧算得快，早早算完等着 CPU；或者反过来，CPU 侧的 3 位层解包太慢，把整个流水线拖住。
定位办法是给每一层打时间戳，统计 GPU 和 CPU 各自的空闲率。如果 GPU 空闲率超过 15%，说明 CPU 侧分到的计算太多或者太慢，应该把一部分层挪回 GPU；反过来就往下挪。这个调整是迭代的，一般调两三轮就能收敛。
但有一种失衡是调层数解决不了的：某些层的耗时异常。比如用了 3 位量化的那几层，解包成本是 6 位层的两倍多，如果恰好这几层都分给了 CPU，CPU 侧就会出现明显的长尾。解决办法是把 3 位层打散，均匀分到两个设备上，让长尾被平均掉。我在一个 32 层模型上做过这个调整，端到端吞吐提升了 12%，纯粹是把耗时分布拉平带来的。
还有个反直觉的发现：CPU 侧放 2 位层比放 5 位层更划算。原因是 2 位层的数据量小，内存带宽压力低，而 CPU 恰好是带宽受限的；5 位层数据量中等，解包后转 8 位的浪费在 CPU 上不明显，但带宽占用上去了。所以最终的分配策略是：2 位层优先给 CPU，5 位和 6 位优先给 GPU，3 位层两边均摊。这个策略和我最初“低位宽给 GPU 发挥算力”的直觉完全相反，是实测算出来的。
6. 精度到底掉在哪：一套可复现的定位流程
6.1 从反量化误差到端到端指标
量化做完，第一件事不是直接跑端到端评测，而是分层看反量化误差。具体做法是对每一层，把量化权重解包回来，和原始 fp16 权重逐元素比对，算三个指标：最大绝对误差、均方根误差、余弦相似度。
余弦相似度是最有诊断价值的。如果某一层的余弦相似度低于 0.99，说明这一层的量化方式有问题，可能是位宽给低了，也可能是缩放系数的粒度太粗。我的经验阈值是：2 位层允许降到 0.985，5 位和 6 位层必须在 0.998 以上，低于这个就回头调。
但要注意，单层的余弦相似度低不一定导致端到端指标崩。因为后面还有归一化和残差连接做缓冲，误差可能被吸收掉。所以第二步要做的是逐层替换实验：把量化模型的某一层换回 fp16，看端到端指标恢复多少。恢复得多，说明这层是瓶颈；恢复得少，说明误差在别处。这个实验的成本是每层一次推理，层数多的话很费时间，可以只对余弦相似度偏低的那几层做。
第三步才是端到端评测。我一般同时看困惑度和几个下游任务的小样本准确率，因为困惑度对低位宽量化不够敏感——有时候困惑度只涨了 0.1，但生成内容的连贯性已经明显变差。
6.2 常见精度塌方点
踩过几次之后，我总结出几个高频塌方点，每次上线前都会重点检查。
第一个是嵌入层和输出头的共享权重。很多模型这两处是同一个张量，如果你按嵌入层的敏感度给它分配了 6 位，输出头也跟着 6 位，看起来没问题；但如果反过来按输出头分配了 8 位，嵌入层也跟着占 8 位的空间，比特预算就被吃掉了。处理办法是分离这两处的量化参数，虽然共享权重，但可以按不同的方式量化——技术上就是存两份量化结果，代价是这部分权重的存储翻倍，不过它只占整体很小一部分，可以接受。
第二个是缩放系数的极值。某个块里如果恰好有一个特别大的离群值，缩放系数会被拉得很大，导致块内其他值全被压到接近零，量化格点浪费严重。检测办法是统计每个块的“动态范围比”，也就是块内最大值和次大值的比值，超过阈值就说明这个块有问题。处理办法有两种：把这个块拆成更小的块，或者用非对称量化吸收偏移。我在一个模型上发现某几层的动态范围比高达 40，改成非对称量化后困惑度降了 0.3。
第三个是长上下文下的累积误差。短上下文测试没问题，一到几千 token 的上下文，输出质量就断崖式下降。原因是 KV cache 的量化误差会随着序列长度累积。解决办法是把 K 和 V 的量化位宽单独提高，或者干脆不量化 KV cache。我目前的策略是 KV cache 一律用 8 位，虽然占空间，但省心。
第四个是不同位宽层之间的数值尺度不匹配。2 位层的输出尺度和 6 位层的输出尺度如果差得太多，残差相加的时候会出问题。这个不是量化本身造成的，而是量化误差改变了输出的分布。检测办法是对比量化前后每一层输出的均值和方差，偏差超过 5% 就要警惕。缓解办法是在量化后做一次尺度校准，用一批校准数据跑一遍，把每层的输出尺度拉回原始分布。
7. 我实际跑下来的一些体会
这套方案从最初的想法到能稳定跑起来，中间返工了三次。第一次失败是因为把 3 位层分得太多，想着省空间，结果解包开销把 GPU 拖成了瓶颈；第二次是没注意缩放系数的开销，以为 2 位就是 2 位，实际算下来 2.5 位，显存预算直接超了；第三次是层切分点跨了注意力块，KV cache 来回搬，性能还不如纯 CPU 跑。
如果让我给一个最实用的建议，那就是先把位宽分配和块大小这两件事的账算清楚，再动手写 kernel。很多人一上来就钻位运算的细节，写到一半发现比特预算根本不够，回头重来。拿张纸把每种位宽的“权重 + 缩放系数 + 对齐填充”算一遍，再乘上层数，十分钟的事，能省好几天。
另外一个体会是，混合推理的收益并不总是正向的。在算力差距悬殊的设备组合上（比如高端 GPU 配很老的 CPU），CPU 侧的贡献可能还不如它带来的调度开销，这时候老老实实单 GPU 跑反而更快。我一般会用一个小脚本先跑个快速评估：如果 CPU 侧的层在单独运行时每层耗时超过 GPU 侧的 4 倍，那就别混了，直接把所有层塞 GPU，靠量化省显存就够了。混合推理真正有价值的场景，是两边算力接近、且显存确实卡住了脖子的时候。
最后说个容易被忽略的细节：量化权重的加载时间。一个 3.5 位量化的 70 亿参数模型，文件大概 3 GB 出头，从磁盘读进来的时间可能比你想象的久。如果服务需要频繁冷启动，加载时间会变成用户体验的瓶颈。我的做法是把权重文件按层切分成多个小文件，启动时并行读取并异步解包，这样首 token 的等待时间能压掉一半以上。这个优化和量化方案本身没关系，但在实际交付里，用户感知到的“快不快”，往往就是由这些边角料决定的。
