内存厂商的噩梦来了：谷歌一篇论文如何让 KV Cache 内存占用缩小六倍

莫潇羽 @ 无忆研习社 | 转载请注明出处

快速摘要

🔑 核心结论（加粗划重点，往下看有完整技术拆解）
2026年3月25日，谷歌研究院（Google Research）悄然发布了一项名为 TurboQuant 的压缩算法，专门针对大语言模型（LLM）推理过程中最大的内存瓶颈——KV Cache（键值缓存）。
TurboQuant 将 KV Cache 从传统 16bit 精度压缩到 3bit，内存占用直降至原来的六分之一（6× 压缩），同时实现精度零损失。
在英伟达 H100 GPU 上，4bit 精度的 TurboQuant 让注意力计算速度最高提升 8 倍。
该算法完全无需重训练、无需微调、无需标定数据，可直接套用于任意基于 Transformer 架构的现有模型。
论文将于 ICLR 2026（国际学习表征会议）正式发表。目前开源社区已出现多个独立实现，llama.cpp 正在积极推进集成。
对于普通用户：内存门槛将大幅降低，本地跑百亿参数模型的时代已在不远处。
👇 往下看，有完整的原理拆解和操作指南。

一、事情的起因：AI 把内存价格炒上天了

如果你最近有装机需求，一定对内存的价格深有感触。

从 2023 年 AI 大模型与智算中心全面铺开起，三星、SK 海力士、美光这三家存储巨头，便将超过七成的先进制程产能全部向高利润的 HBM（高带宽内存）生产方向倾斜。HBM 是专门为 GPU 和 AI 加速器设计的高带宽存储芯片，单位面积的售价和利润率都远高于普通消费级内存，因此厂商自然有强烈的动机减少消费级产品的供给。

消费级内存的供给出现明显萎缩，美光科技（Micron）更是在数月前正式宣布关闭消费级内存生产线，全力押注 AI 服务器所需的 HBM 内存。供给侧的收缩是一方面，需求侧的囤货炒作更是火上浇油。两条 32G DDR5 6400 规格的内存条，从最初不到 2000 元的正常零售价，被硬生生炒到了 8000 元以上——涨幅超过三倍。不光内存，连固态硬盘也随之水涨船高，一副"猪肉涨价带动整个菜篮子"的架势。装机佬与黄牛之间那场无声的拉锯战，一度僵持了大半年。

内存价格的异常上涨，从本质上说，是 AI 算力需求爆发与消费端供给收缩这两股力量叠加的结果。在此之前，没有人预料到，一个算法领域的技术突破，会对硬件市场产生如此直接的冲击——直到 TurboQuant 出现。

然而，就在 2026 年 3 月 25 日，谷歌用一篇技术论文，悄无声息地改变了这场博弈的走向。

美光科技（MU）、西部数据（WDC）、希捷（STX）、闪迪（SNDK）的美股股价，相继出现明显下滑。内存厂商坐不住了，黄牛更是措手不及。Cloudflare CEO Matthew Prince 在社交媒体上甚至公开将这一事件称为"谷歌的 DeepSeek 时刻"——就像 DeepSeek 用低成本训练出高性能模型颠覆了"算力即正义"的叙事，TurboQuant 则用一个算法颠覆了"AI 必须吃掉海量内存"的既有认知。

这篇论文，就是 TurboQuant。

二、搞懂 KV Cache：AI 的"工作记忆"到底是什么

要理解 TurboQuant 的意义，必须先搞清楚它究竟压缩的是什么东西——KV Cache（键值缓存）。

2.1 Transformer 与注意力机制的工作原理

现代大语言模型，包括 GPT 系列、Claude、Llama、Gemini 等，全都基于同一种架构：Transformer。Transformer 的核心是"注意力机制"（Attention Mechanism），直白地说，就是让模型在生成每一个新词时，都能回头看一看前面所有内容，从中找出最相关的部分加以参考。

这个机制非常强大，但也极其耗费计算资源。试想一下，如果你在和 AI 进行一段 5000 字的对话，模型每次生成下一个字，都要把前面所有 5000 个字重新过一遍——计算量将呈平方级爆炸式增长，这在工程上几乎是不可接受的。

于是，工程师们想到了一个优化方案：把之前已经计算过的中间结果缓存起来，下次用直接取，不用重算。这就是 KV Cache 的本质——它保存的是 Transformer 中每一个注意力层在处理历史 Token 时，所生成的 Key（键）向量和 Value（值）向量。

一个形象的比喻：KV Cache 就像一个学生的"草稿纸"，每次做新题时，把之前推导过的中间步骤记在草稿上，下次遇到类似计算直接翻草稿，不用从头推。而对话越长，草稿纸上记录的内容就越多，占用的空间自然也越大。

2.2 KV Cache 为什么会让内存爆炸

KV Cache 的内存占用，可以从以下三个维度来理解：

维度一：上下文长度（序列长度）

你和 AI 说的话越多，对话越长，KV Cache 就越大。这个关系是线性的——对话内容翻倍，缓存大小也翻倍。现代模型的上下文窗口动辄 32K、128K 甚至 100 万 Token，KV Cache 随之线性膨胀。假设你正在处理一份 10 万字的技术文档，AI 在生成总结时，KV Cache 中就会同时缓存处理这 10 万字过程中的全部 Key/Value 对——这是一笔非常可观的存储开支。

维度二：数据精度（Bit 宽度）

每个向量中的数字，在计算机里要存多少位小数，决定了数据的"分辨率"。传统 AI 推理默认使用 FP16（16 位浮点数）来存储 KV Cache，精度高、质量稳，但也意味着每个数字要占 2 个字节的内存。如果把精度降低（比如用 8bit 整数代替 16bit 浮点数），内存消耗可以减半，但如何在压缩的同时不让模型"变笨"，是困扰业界多年的核心难题。

维度三：模型规模

参数量越大的模型，每一层的 Key/Value 向量维度越高，缓存自然更占空间。一个 70B（700 亿参数）的模型，在处理 32K Token 的上下文时，KV Cache 占用的 GPU 显存本身就可以轻松超过 80GB——而整个模型的权重也不过如此。

换言之，当你运行一个 70B 的大模型，同时为 512 个用户提供服务时，仅 KV Cache 一项就可能消耗超过 512GB 的 HBM 显存，是模型权重本身所需显存的将近四倍。这就是所谓的"内存墙"问题。

2.3 一个直观的数量级感受

为了让这些数字更有体感，莫潇羽@无忆研习社 整理了一张不同规模模型在不同上下文长度下，KV Cache 的近似显存占用估算表（以 FP16 精度为基准）：

从这张表可以清晰看到，70B 模型在 128K 的长上下文场景下，仅 KV Cache 就要吃掉 128GB 的显存——这已经超过了 8 张 H100 GPU 的总显存容量。这也是为什么云端大模型服务费如此高昂的重要原因之一，动用的 GPU 资源有相当大的比例被 KV Cache 所消耗，而非实际的计算工作。

如果 TurboQuant 能够把这个数字缩小到原来的六分之一，效果相当于让 128K 上下文的内存需求降至约 21GB，单张 H100 完全可以承载。这个变化，对于 AI 推理成本的影响是革命性的。

三、业界已有的解法，以及它们各自的妥协

在 TurboQuant 出现之前，业界主要通过以下几条路来缓解 KV Cache 的内存压力：

滑动窗口注意力（Sliding Window Attention）

只保留最近 N 个 Token 的 KV Cache，超出窗口的历史记录直接丢弃。这个方法节省了内存，但代价是丧失远程上下文感知能力——AI 只记得"最近说的话"，忘掉了开头的对话。对于需要全局一致性的长文档处理、超长对话等场景，这个方法存在明显缺陷。比如你在第一段告诉 AI 一个人物的姓名，对话进行到第 200 轮后，AI 可能已经"记不住"最初的设定了。

线性注意力（Linear Attention）

将所有历史 Token 的信息压缩为一个固定大小的隐状态（Hidden State），理论上实现了常数级的内存消耗。但压缩是有损的，大量历史信息在压缩过程中流失，模型在长上下文推理中的精度会大幅下降，表现比不上标准注意力。这就像把一本书的内容压缩成一个段落的摘要，虽然节省了存储空间，但细节信息几乎全部丢失。

KV Cache 量化（Quantization）

在有限的 Bit 宽度内，将 KV Cache 中的浮点数"量化"为更少位数的整数表示，以此缩减存储体积。这是目前最主流的方向，代表性工作包括 KIVI（2-bit 量化）等。但传统量化方法存在一个隐藏的硬伤：量化常数（Quantization Constants）的额外开销。

具体来说，传统的向量量化方法在压缩数据时，需要同时保存一组"元数据"（量化参数，如零点 zero-point 和缩放比例 scale），以便在恢复数据时使用。这些元数据本身要以全精度存储，每个量化块会额外引入 1 至 2 bit 的开销。乍看不多，但随着上下文长度的不断扩展，这个开销会持续累积，最终把量化所节省的空间给抵消掉相当大一部分。

稀疏注意力（Sparse Attention）

另一类思路是只保留"重要"的 KV 对，跳过对最终结果影响较小的历史 Token。这需要一套启发式或学习型的选择机制来判断哪些 Token 值得缓存，实现复杂，且"重要性"的判断本身存在误差，容易在关键任务上产生不可预测的质量抖动。

这三到四条路都有无法回避的代价，业界卷了很久，始终没能找到一个在精度、速度与内存之间三者兼顾的完美方案——直到谷歌带着 TurboQuant 走进来。

四、TurboQuant 的核心原理：两步走的压缩架构

TurboQuant 是谷歌研究院提出的一种在线向量量化（Online Vector Quantization）框架，整个压缩过程分为两个阶段，分别由两个核心子算法承担：PolarQuant（主压缩阶段）和 QJL（Quantized Johnson-Lindenstrauss，量化 JL 变换）（残差纠错阶段）。

这两篇论文分别将在 AISTATS 2026（摩洛哥丹吉尔）和 ICLR 2026（巴西里约热内卢）正式发表。

4.1 第一阶段：PolarQuant——"换个角度"压缩向量

PolarQuant 的核心思路，是通过改变数据的几何表达方式，从根本上消除传统量化方法中必须存储量化常数的需求。

步骤一：随机正交旋转（Random Orthogonal Rotation）

PolarQuant 拿到一个 KV 向量（实质上是一串高维度的浮点数序列）后，第一步并不是直接压缩，而是对它施加一个随机生成的正交变换矩阵（可以理解为一种不改变信息量、只改变"视角"的旋转操作）。

这一步的数学依据是 Johnson-Lindenstrauss 引理：经过随机投影后，数据中各点之间的距离和内积关系会被近似保留，同时数据的整体分布会趋向于一个可预测的多元正态分布（Multivariate Gaussian Distribution）。

换句话说，这次旋转让原本分布形态各异、难以预测的向量坐标，变成了"长得都差不多"的、服从已知分布规律的数值——这为后续量化提供了极大便利。

为什么原始的 KV 向量不能直接量化？因为不同模型、不同层、不同输入，KV 向量的数值分布差异极大——有的高度集中，有的分散不均，有的存在少量极端大值（Outliers）。传统量化方案必须为每一个数据块单独测量分布、保存归一化参数，这才引入了不可避免的额外开销。而随机旋转这一步，相当于把"形态各异的向量"统一转换为"来自同一分布族"的向量，之后就可以用一套固定的策略来量化所有向量，不再需要为每一块数据单独配一把"尺子"。

步骤二：极坐标变换（Polar Coordinate Transformation）

旋转完之后，PolarQuant 将向量从标准笛卡尔坐标系（直角坐标，每个维度记录沿轴线的位置）转换为极坐标系（用一个半径和一组角度来描述向量的位置）。

为什么要转换为极坐标？这里有一个关键的几何洞察：

在极坐标表示中，向量被分解为"半径"（Radius，代表向量的模长/幅度）和"角度"（Angles，代表向量的方向）。经过前面的随机旋转预处理之后，这些角度的分布变得集中而可预测——它们遵循一种可以用解析公式直接计算出来的分布形态。

关键突破在于：由于角度分布是可预测且集中的，PolarQuant 可以跳过传统量化中"必须为每个数据块单独计算并存储归一化参数"的步骤。那个一直占用额外 1~2bit 存储空间的量化常数，就这样被彻底消除了。

取而代之的是一套可以离线预计算的最优量化码本（Lloyd-Max Codebook），这些码本在量化之前就确定好，推理过程中可以复用，几乎没有额外的时间开销。

步骤三：Lloyd-Max 最优标量量化

确定了极坐标角度的分布形态之后，PolarQuant 使用 Lloyd-Max 算法为这个已知分布设计最优的量化方案。所谓最优，是指在给定位宽（比如 3bit）的条件下，能让量化误差（均方误差 MSE）最小化的分桶方案。

这相当于用最精确的方式，把无限连续的角度值映射到有限的整数码本中。每个角度值就近找到码本里最接近的代表值，然后只存储这个代表值在码本中的索引编号（Index），就完成了压缩。这一步每个维度大约需要 2~3bit。

用一个直白的比喻：传统量化就像给每一块砖头量身定制一把尺子来记录它的尺寸，PolarQuant 则是把所有砖头"旋转"成统一的形状，再用同一把标准尺去量，尺子本身不用随砖头带着走，省掉了大量存储开支。

这一步完成之后，原始向量的绝大部分信息（主要的"能量"）已经被紧凑地用极少量的 bit 表达出来，完成了主体压缩。

4.2 第二阶段：QJL——用 1bit 消灭残差偏差

PolarQuant 做完之后，数据确实被大幅压缩了，但量化本身是有损操作，一定会留下一个微小的残差误差（Residual Error）。

对于一般的数据存储来说，这个残差可以接受。但在 Transformer 的注意力机制里，计算的核心操作是向量之间的内积（Inner Product）——也就是 Query 向量与各个 Key 向量之间的点积运算，注意力分数由此得来。

量化引入的残差如果带有系统性偏差（Bias），就会导致内积估计值偏高或偏低，让模型在判断"哪些 Token 最相关"时产生系统性失误，最终影响回答质量。这也是为什么极低 bit 宽度量化通常会显著降低模型表现的根本原因。

以数学方式来说明这个问题：1-bit MSE 最优量化器在高维空间中，会对内积产生约 2/π ≈ 0.637 倍的乘性偏差（Multiplicative Bias）。这意味着模型计算出的注意力分数，系统性地低估了所有向量之间的相似度，导致注意力权重的分配出现扭曲。

QJL（量化 Johnson-Lindenstrauss 变换） 专门为消除这个偏差而设计。

其做法是：将 PolarQuant 压缩后剩余的残差向量，通过一个随机高斯投影矩阵投影到低维空间，然后只保留每个投影结果的符号位（Sign Bit，正数记为 +1，负数记为 -1）。整个操作只占用 1bit 的额外存储空间。

这 1bit 的信息，通过一个被称为"非对称估计器（Asymmetric Estimator）"的数学技巧，与高精度的 Query 向量配合使用，使得最终的注意力分数内积估计在统计意义上无偏（Unbiased）——也就是说，估计值的期望等于真实值，残差偏差被数学地"抵消掉"了。

用一个更通俗的比喻来说：PolarQuant 像是用素描大致勾勒出了一幅画的主体轮廓，捕捉到了最重要的结构信息；但素描难免有一些微小的形变，让你在判断"哪个局部和参考图最像"时产生轻微的误判。QJL 就是在素描旁边加一张小纸片，上面只记着"每条线往哪个方向偏了"（正方向还是负方向）——信息量极小，但足以让你修正判断方向，恢复准确的相似度排序。

理论上，谷歌的团队证明了 TurboQuant 的误差率接近香农信源编码理论下界（Shannon Lower Bound），误差仅为理论极限值的约 2.7 倍常数因子以内。这意味着压缩效率几乎已经逼近了信息论所允许的理论天花板。从另一个角度看，这也意味着继续在这个方向优化，后续的改进空间将变得越来越小——TurboQuant 在一定程度上已经是这类方案的"终局形态"。

4.3 两个阶段的协同：整合为一套体系

把两个阶段合在一起看：

• PolarQuant 负责主体压缩，用大部分的 bit 预算（比如 3bit 方案中的 2bit）捕捉向量的主要信息；
• QJL 负责用剩余的 1bit 做偏差修正，确保注意力分数计算时不出现系统性偏差；
• 两者叠加之后，整体比特宽度约为 3bit，而精度表现可以媲美 16bit FP16 的完整精度。

下面用一段伪代码来展示核心量化流程：

import numpy as np

# =====================================================
# TurboQuant 核心量化流程（简化版示意）
# =====================================================

def polar_quant(kv_vector, rotation_matrix, codebook):
    """
    PolarQuant 主压缩阶段

    参数：
        kv_vector    : 原始 KV 向量，形状 (d,)，d 为注意力头维度
        rotation_matrix : 离线预生成的随机正交矩阵，形状 (d, d)
        codebook     : 离线预计算的 Lloyd-Max 最优码本

    返回：
        indices      : 量化索引（极坐标角度）
    """
    # 第一步：随机正交旋转（统一分布形态）
    rotated = rotation_matrix @ kv_vector  # 矩阵乘法，O(d^2) 操作

    # 第二步：转换为极坐标（分离半径与角度）
    # 递归极坐标变换，将 d 维向量变为 (d-1) 个角度值 + 1 个半径
    angles = cartesian_to_polar_recursive(rotated)

    # 第三步：查表量化（用预计算码本找最近邻）
    indices = find_nearest_centroid(angles, codebook)

    return indices

def qjl_residual_correction(residual, projection_matrix):
    """
    QJL 残差纠偏阶段

    参数：
        residual         : PolarQuant 量化后的残差向量
        projection_matrix: 随机高斯投影矩阵

    返回：
        sign_bits        : 1-bit 符号向量（+1/-1）
    """
    # 随机投影 + 只保留符号位
    projected = projection_matrix @ residual
    sign_bits = np.sign(projected)  # 每个元素只存正负号，1bit
    return sign_bits

def turboquant_compress(kv_vector, rotation_matrix, codebook, proj_matrix):
    """
    TurboQuant 完整压缩流程（两阶段合并）
    """
    # 阶段一：PolarQuant 主体压缩（约 b-1 bit）
    compressed_indices = polar_quant(kv_vector, rotation_matrix, codebook)

    # 计算残差：原始向量与重建向量之差
    reconstructed = dequant(compressed_indices, rotation_matrix, codebook)
    residual = kv_vector - reconstructed

    # 阶段二：QJL 残差纠偏（1 bit）
    sign_correction = qjl_residual_correction(residual, proj_matrix)

    # 存储：量化索引 + 符号向量 ≈ 3bit per dimension
    return compressed_indices, sign_correction

def asymmetric_attention_score(query_fp16, compressed_keys, sign_corrections, 
                                rotation_matrix, codebook, proj_matrix):
    """
    非对称注意力分数计算（推理时核心路径）

    Key 向量以 3-bit TurboQuant 压缩格式存储
    Query 向量仍以高精度 FP16 参与计算
    这种"高精度 Query + 低精度 Key"的组合是 TurboQuant 无偏估计的关键
    """
    scores = []
    for k_idx, sign_corr in zip(compressed_keys, sign_corrections):
        # 从量化索引恢复近似 Key 向量
        k_approx = dequant(k_idx, rotation_matrix, codebook)

        # 主体内积（使用 PolarQuant 重建值）
        main_score = np.dot(query_fp16, k_approx)

        # QJL 偏差修正（消除系统性误差）
        correction = np.dot(query_fp16, proj_matrix.T) @ sign_corr

        # 组合得到无偏注意力分数估计
        final_score = main_score + correction
        scores.append(final_score)

    return np.array(scores)

上述代码是为了帮助理解而做的简化示意。真实的 TurboQuant 实现会涉及到 CUDA/Metal 内核优化、WHT（Walsh-Hadamard 变换）等高效矩阵运算替代方案，在实际部署中整体吞吐量的提升远比伪代码表现的直观。

五、TurboQuant 解决了传统量化的哪个根本问题

这里有一个很多文章没有说透彻的关键点，值得单独展开。

大家平时说到"AI 跑得慢"或者"AI 内存不够"，往往会直觉地以为是计算量太大。但在实际的 LLM 推理中，很多时候真正的瓶颈并非 GPU 的浮点计算能力（FLOPs），而是内存带宽（Memory Bandwidth）。

这是因为：GPU 执行注意力计算时，要先把数据从显存（HBM，高带宽内存）搬运到 GPU 片上的高速缓存（SRAM），再开始计算。这个"搬砖"的过程，往往比计算本身花的时间还多。业界把这类问题称为内存带宽瓶颈（Memory-Bandwidth Bound）。

以英伟达 H100 GPU 为例：其片上 SRAM 的带宽约为 33 TB/s，而 HBM 到 SRAM 的传输带宽约为 3.35 TB/s——两者相差约 10 倍。每次做注意力计算，需要把所有缓存在 HBM 里的 KV 向量搬进 SRAM 参与运算；KV Cache 越大，搬运时间越长，计算单元就等在那里空转。

TurboQuant 把 KV Cache 从 16bit 压缩到 3bit，数据体积直接缩小为原来的约六分之一。这意味着每次注意力计算，GPU 需要搬运的数据量少了将近六倍。搬的砖少了，传输时间自然大幅缩短，速度自然飞起来——这就是为什么 TurboQuant 能在 H100 上实现最高 8× 的注意力计算加速，而不仅仅是节省了一些显存那么简单。

与此同时，传统量化方案绕不开的"量化常数存储开销"问题，也被 PolarQuant 从根源上解决了。下面用一个表格对比来直观说明：

可以看到，TurboQuant 最大的工程优势在于：彻底消除了量化开销，并且在 3bit 下实现了此前被认为几乎不可能的精度零损失——这也是它与之前所有竞争方案最本质的差别。

还有一点值得注意：TurboQuant 的压缩是完全在线、流式进行的。传统的一些离线量化方案（如 GPTQ），需要提前用大量校准数据对模型进行重量化处理，耗时数小时到数天不等。TurboQuant 不需要任何预处理——Token 一产生，KV 向量就立刻完成压缩存入缓存，没有任何"预热"阶段。这使得它可以无缝集成进现有的 LLM 服务架构，不需要改变任何推理管线的前置流程。

六、实测数据：谷歌做了哪些测试，结果怎么样

谷歌对 TurboQuant 进行了系统性的基准测试，使用的主要测试模型包括 Llama-3.1-8B-Instruct、Gemma 和 Mistral-7B，覆盖了五大业界标准的长上下文评测集。

6.1 长文本基准测试（LongBench）

LongBench 是覆盖问答、代码生成、文本摘要等多种任务的综合性长上下文评测集。在这项测试中，TurboQuant 在全部任务类别上均能匹配甚至超越 KIVI 基线方案的得分，同时将 KV Cache 内存占用压缩至少 6 倍。

6.2 大海捞针测试（Needle In A Haystack）

这是 LLM 长上下文能力中最严苛的考核项目之一：将一段关键信息（"针"）随机埋入一篇长达数万、甚至十万词的文档（"草堆"）中，测试模型能否准确找到它。

TurboQuant 在覆盖 4K 到 104K Token 的全部上下文长度范围内，全部任务均达到满分（100% 召回率）——这与无压缩的 FP16 基线完全一致。在如此激进的 3.5bit 压缩下，精度零损失这个结论得到了实验验证。

第三方开发者也独立验证了这一结果。有开发者在自己的 RTX 4090 上使用 Gemma 3 4B 模型进行测试，将 TurboQuant 压缩到 2bit 后，模型输出与完整精度版本的结果逐字节完全一致——这在量化领域是极为罕见的现象。

6.3 速度提升（H100 GPU 上的注意力计算加速）

谷歌官方数据：在英伟达 H100 GPU 上，TurboQuant 的 4-bit 实现将注意力分数计算（Attention Logits Computation）的速度提升了最高 8 倍，相较于经过高度优化的 JAX FP32 基线。

6.4 向量搜索场景评估

除了 LLM 推理，谷歌还评估了 TurboQuant 在向量搜索（Vector Search）场景下的表现。

测试使用了 GloVe 数据集（d=200，200 维词向量），与当时的最优竞品方案 PQ（Product Quantization，乘积量化）和 RabbiQ 进行对比。TurboQuant 在 1@k 召回率（即目标向量是否出现在前 k 个搜索结果中）上超过所有竞品，并且不需要竞品所依赖的大型码本和数据集特定调优。

更为惊人的是，TurboQuant 的索引构建时间约为 0.0013 秒（对于 1536 维向量），而 PQ 在同等设置下需要约 239.75 秒——快了将近 18 万倍。这使得 TurboQuant 特别适合需要实时在线索引更新的 RAG（检索增强生成）场景。

七、理论深度：为什么说 TurboQuant 具有理论最优性

技术人员可能会好奇：TurboQuant 究竟有多"最优"？是不是只是工程上比别人好一点，还是有严格的数学保证？

根据论文，TurboQuant 的误差率被证明位于香农理论下界（Shannon Information-Theoretic Lower Bound） 的常数因子以内——具体来说，误差率最多是理论下界的约 2.7 倍。

所谓香农下界，是信息论给出的"任何压缩算法都无法突破的极限"。它好比物理世界中的光速上限，告诉你"再怎么优化，也不可能超过这条线"。当一个算法的误差已经控制在这条线的 2.7 倍常数以内时，工程意义上已经被认为是"接近理论最优"——继续优化的空间极为有限。

另一个重要的