技术拆解
量化到底换掉了什么：体积、速度，和质量的长尾
fp16、q8_0、q4_k，外加 Qwen 的 q3_k——在同一段音频上，哪些压缩几乎免费，哪些体积优势换不来速度，为什么 moonshine-tiny 的 11.76% WER 该怪模型而不是量化。
量化经常被说成一顿免费午餐：把权重压小，精度不变，模型更轻便。诚实的说法是——它是一笔交易，而唯一知道你付出了什么的办法是测量。OpenASR 的性能套件做的就是这件事：在单台 macos/aarch64 机器上，best-of-N，对一段 6.13 秒、17 个词的 LibriSpeech 片段做基准测试。这段参考音频足够短，一个词转错就会让词错率（WER）跳动大约 5.88%，所以下面的数字描述的是这台机器上这个构建版本的表现，不是对你音频的承诺。
运行时在不同模型家族上提供三种量化档位——fp16、q8_0、q4_k——Qwen3-ASR 额外多一个 q3_k。选择哪个档位，通常被当作一个体积决策。但性能套件告诉我们，这其实同时是三个决策：体积、速度、质量的长尾——而它们并不总是朝同一个方向变化。
速度跟着精度走，不跟着压缩率走
拿 qwen3-asr-0.6b 在这段音频上的表现来看。所有档位的转录结果都是 WER 0.00%，质量恒定，只有实时因子（RTF，越低越快）在动：
q4_k— RTF 0.295q3_k— RTF 0.340q8_0— RTF 0.411fp16— RTF 0.585
“压缩越狠越快”这个直觉在 q3_k 这里失效了：它的包比 q4_k 更小，解码却更慢。在 batch size 为 1 的场景下，decode 受限于内存带宽，而 3-bit 权重的解包比 4-bit 需要更多算术运算——额外的压缩买到的是体积，不是速度。
一段音频，一台机器
以上数据均为单台
macos/aarch64机器上、对同一段 LibriSpeech 短音频的 best-of-N 测量，使用的是性能套件中与其他测试一致的 whisper.cpp 方法论。在 17 个词的参考文本上，WER 的粒度很粗——一个替换错误就是约 5.88%——所以 RTF 阶梯（数值稳定）比微小的 WER 差异更值得信赖。
几乎免费的压缩
有些时候，量化确实主要只是一个体积旋钮。性能套件对 cohere-transcribe 的注释记录了它的 q4_k 模式将包体积缩小了大约 39%，同时 WER 保持 0.00%——套件标注这个数字，是为了说明冷加载 I/O 的削减是合理的。但要把话说清楚：词错率确实保持为零，但转录文本与 q8_0 的输出并非逐字节相同。所以这是”体积 −39%，WER 0.00%“，不是”完全相同的输出白白变小了”。
体积赢了不代表速度也赢了
parakeet-ctc-0.6b 的情况正好相反。它的 q4_k 包比 fp16 小了约 55%，看起来是毫无争议的胜利——直到你计时。在这个小型、计算受限的 conformer 模型上，q4_k 的解码比 q8_0 更慢，因为 4-bit k-quant 的解包开销比 q8 更重；它的 depthwise convolution 甚至保留在 f16 精度以保护质量。所以 q4_k 在这里是一个刻意的体积选择，而非速度选择。
长尾问题出在模型，不在量化器
对诚实原则最重要的案例是 moonshine-tiny。它的 q4_k 包在同一段参考音频上 WER 为 11.76%——17 个词错了 2 个。这很容易被归咎于激进的量化，但那是错的：转录文本与 HuggingFace transformers 官方 Moonshine 参考输出逐字节一致，两个错误是模型本身的特性（“greed/read”和”angryer/angrier”）。这是一个 27M 参数模型真实的质量天花板，量化没有引入任何额外损失。把两者混为一谈，恰恰是这套性能套件要防止的错误。
WER 并非普遍为 0%。大多数档位守住了质量；少数小模型确实有损——而那份损失来自模型本身，不是量化器。
—— OpenASR 性能套件
我们不做的声明
以上所有数据都在内部冒烟测试通道上测量。OpenASR 不做公开的质量或 WER 保证，这些数字背后也没有多语言或口音质量的准入门槛——那些工作是被推迟了，不是被验证过了。性能套件的职责更窄，但也更实用：把体积、速度、质量作为三条独立的、被测量的轴线来维护，让一个更小的包上线是因为有人看过它换掉了什么，而不是因为压缩被默认当成了免费的。
# 在你自己的机器上计时一个量化包openasr transcribe clip.wav --benchmark --model-pack ./qwen3-asr-0.6b.q4_k.oasr --format text# 输出该包的耗时和实时因子