端侧推理今年是真的火了——WebGPU 1.0 落地、WebLLM / Transformers.js 把大模型直接塞进浏览器数据不出端、延迟压到几十毫秒。圈子里的共识也跟着简化成一句口号「把权重从 FP32 量化成 INT8体积砍到 1/4端侧就跑得动了」。这话对了一半。而且偏偏是对的那一半最不值钱。我用 Node v22 在一百万个元素的张量上把这件事拆开测了一遍内存比确实严丝合缝是 4.0×但精度的账完全不是「压小一点、损失可忽略」那么简单——对真实模型里那种「绝大多数很小、偶尔几个很大」的激活张量朴素量化会把占 95% 的小值毁掉近三成更要命的是在纯浏览器 JS 里量化后的计算反而慢了 34 倍。下面是一组可复现的数字。背景为什么「压到 1/4」这句口号会误导人端侧推理的瓶颈从来不是「能不能算」而是「装不装得下、跑不跑得动」。一个 7B 参数的小模型FP32 权重就要 26 GB任何消费级设备都直接出局量化到 INT8 后理论只剩 6.5 GB听起来就活了。问题出在省略号从 FP32 到 INT8 不是无损打包而是把连续的浮点值映射成 256 个整数档位。这一步省下的内存是真的但腾出的空间是用精度换的——而精度的损失高度依赖你的数据长什么样。把「体积 1/4」和「精度够用」画等号等于默认所有张量都是均匀干净的分布可真实模型的权重和激活恰恰不是。解剖INT8 量化到底怎么运作最常用的是对称逐张量per-tensor量化找一个全局缩放因子scale maxAbs / 127把每个浮点值除以 scale 后四舍五入夹到 [-127,127] 的整数推理时再乘回 scale 还原。十几行就能写出来// 对称逐张量 INT8 量化推理侧还原 function quantizePerTensor(a) { let maxAbs 0; for (const v of a) if (Math.abs(v) maxAbs) maxAbs Math.abs(v); const scale maxAbs / 127; // 全局缩放因子 const q new Int8Array(a.length); for (let i 0; i a.length; i) { let v Math.round(a[i] / scale); if (v 127) v 127; else if (v -127) v -127; q[i] v; } return { q, scale }; } function dequant(q, scale) { const d new Float32Array(q.length); for (let i 0; i q.length; i) d[i] q[i] * scale; return d; }图1FP32 张量 → 取全局 maxAbs 算 scale → 取整夹到 [-127,127] → 以 Int8 存储 → 推理时乘 scale 还原。整条链路唯一的「免费午餐」是存储体积。关键在于scale是全局的一个特别大的异常值会撑大 scale从而把所有小值的量化步长也一起拉粗。这一步的代价下面用数字说话。实证一内存——唯一严丝合缝的 4 倍先说好的那半。在 100 万元素的张量上Float32 占 4,000,000 字节恰好 4 MB量化成 Int8 占 1,000,000 字节1 MB比值是精确的 4.0——因为字节宽度就是 4:1没有魔法。# 复现Node v22.22.2纯 JS零依赖 node _bench_quant.mjs # - memory.ratio 4 # - 7B 模型FP32 26.08 GB → INT8 6.52 GB图21M 元素张量 4 MB → 1 MB精确 4×放大到 7B 参数模型26.08 GB → 6.52 GB正好四分之一。内存节省是确定的、可预期的。所以「压到 1/4」这句口号在存储维度上完全成立且毫无意外。真正要小心的是它顺手暗示的下一句「既然体积够了精度也够用了」。实证二精度——干净数据 1%异常值数据毁掉 29%我用三种有代表性的分布各生成 100 万元素量化后算归一化均方根误差NRMSE除以数据自身标准差方便横向比取 5 个随机种子的均值分布总体 NRMSE说明均匀[-1,1]0.39%教科书里的「干净」数据高斯N(0,1)1.10%权重近似这种形状异常值型95%×0.1 5%×34.31%像真实激活多数很小、少数很大异常值型 → per-channel1k 块2.56%改用分块独立 scale图3干净数据误差不到 1.1%异常值型总体冲到 4.31%改用 per-channel 分块缩放后回落到 2.56%。但总体指标会骗人——这里有一个被「总体 NRMSE」藏起来的坑。上面那个异常值分布总体 NRMSE 只有 4.31%看起来还行——可那是因为 5% 的大异常值贡献了绝大部分方差把指标撑住了。单独看占 95% 的「小值主体」它们的相对误差高达 29.2%全局 scale 被少数异常值撑大小值的量化步长被一起拉粗等于用 95% 数据的精度去补贴 5% 的 outlier。真实 LLM 的激活正是这种形状所以这个 29% 不是边缘情况而是常态。per-channel按 1024 个元素一块、各自算 scale能把异常值隔离在自己的块里让小值块拿到更紧的 scale总体从 4.31% 压回 2.56%——但前提是你的推理框架真的实现了逐通道 / 逐 token 缩放而不是懒懒地用全局一个 scale。局限纯 JS 里量化后的计算反而慢 34 倍最后一个边界专治「量化后算得更快」的另一种错觉。量化的计算收益来自 INT8 的 SIMD / 专用矩阵单元——只有 WebGPU、WASM SIMD 这类真有 INT8 执行单元的地方才成立。在普通浏览器 JS里没有这东西量化反而要额外付出「量化存储 推理时反量化」的搬运成本。同一组 100 万维向量分别测 1M 维点积原生 FP32 点积中位数0.514 ms而「量化成 Int8 再乘 scale 还原」的点积中位数17.394 ms——慢了33.87 倍。换句话说在纯 JS 路径上INT8 既没省时间还丢了精度。诚实的边界清单内存 4× 是确定的、无条件的闭眼用。精度损失取决于分布异常值多的激活张量主体会被毁掉近三成必须上 per-channel / per-token 缩放才稳妥。计算加速只在有真 INT8 硬件时存在WebGPU / WASM SIMD纯 JS 里量化计算是负优化别指望它提速。结论与下一步一句话方法论INT8 量化省内存是白送的但「精度够用」和「算得更快」都要看硬件和缩放策略——全局 scale 配异常值数据是在用 95% 的小值精度补贴 5% 的 outlier。落地时先把三件事对齐再动手存储体积确定 4×→ 缩放策略per-channel 保精度→ 执行后端有没有真 INT8 单元决定计算是否变快。把「压到 1/4」当存储结论用别当性能结论用。开源地址矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 1310 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器GitHub - wangzifan396-wzf/nano-workbench: Single-file tabbed launcher for the nano-tools matrix - one tab, 382 curated tools (of 1310), instant switching. Zero-dep. Part of nano-tools. · GitHubGitHub 组织主页wangzifan396-wzf (WangZi) · GitHub