August 28, 2026 中 #SVD & Low-Rank #Model Compression #LLM Inference

LowRankArena 阅读笔记：把 SVD 压缩论文放到同一套规则下会发生什么

笔记日期： 2026-08-28 | 作者： Zhongzhu Zhou 阅读论文： LowRankArena: A Standardized Evaluation Platform for SVD-Based LLM Compression 论文作者： Zishan Shao, Lixun Zhang, Kangning Cui, Wenhao Wu, Jinhee Kim, Yixiao Wang, Ting Jiang, Hancheng Ye, Qinsi Wang, Fan Yang, Danyang Zhuo, Yiran Chen, Hai Li（杜克大学、维克森林大学） arXiv： 2608.26389 Venue/Status： arXiv 预印本，提交于 2026 年 8 月 26 日

为什么这篇论文值得读

这个博客系列过去几个月连续追着 SVD 低秩压缩这条线读了很多篇——SVD-LLM、DoBi-SVD、Swift-SVD、SigmaScale、AIR、LACE-SVD、SVD-Surgeon 等等，而几乎每一篇的实验表都会得出”我们超过了之前的 SOTA”这个结论。如果你只是孤立地读每一篇论文，很容易得出这样的印象：这个领域一直在单调、持续地进步，每个新方法都严格优于上一个。

LowRankArena 提出了一个很不客气但也很必要的问题：“更好”是相对于谁的评测协议而言的？ 不同论文用的 LLaMA 版本不同、压缩比(“keep ratio”)的定义不同、校准数据不同、评测任务子集不同——更关键的是，有些论文会悄悄把混合精度量化或权重重映射之类的辅助技巧和低秩分解捆在一起报告，这就让人根本无法判断报告中的提升到底来自 SVD 算法本身，还是来自搭便车的附加技巧。

这不是一篇提出新算法的论文，而是一篇”审计”论文——这一类论文数量不多但价值很高：它们不追求把 SOTA 再往前推一步,而是追问”我们现在所理解的 SOTA,到底是不是真实存在的”。作者搭建了一套共享评测框架——固定模型、固定任务、固定压缩比定义、固定推理后端——把五个具有代表性的 SVD 方法(ASVD、SVD-LLM、DoBi-SVD、Basis Sharing、MoDeGPT)重新跑了一遍,得出的核心结论对任何在追踪这个领域”SOTA”的人来说都相当扎心:不存在一个跨架构稳定的排名。 “最好”的方法会随着测试的骨干模型、压缩比预算、以及你看的是哪一类指标(准确率还是困惑度)而改变。

如果你也在读这个系列的过程中,在脑子里默默排了一个”目前为止最好的 SVD 方法”排行榜——这篇论文正是你需要的纠偏剂:那个排行榜,按照文献里通常报告的方式,可能根本就不存在。

前置知识

SVD 低秩压缩到底在做什么

Transformer 里的一个稠密权重矩阵,比如 $W \in \mathbb{R}^{m \times n}$ (注意力或 MLP 模块里的某个线性投影),总是可以精确地做奇异值分解:

W = U \Sigma V^{\top}

其中 $U \in \mathbb{R}^{m \times m}$ 、 $V \in \mathbb{R}^{n \times n}$ 是正交矩阵, $\Sigma \in \mathbb{R}^{m \times n}$ 是对角矩阵,对角线上是按从大到小排列的非负奇异值 $\sigma_1 \geq \sigma_2 \geq \dots \geq \sigma_{\min(m,n)} \geq 0$ 。经典的 Eckart–Young 定理告诉我们,只保留前 $k$ 个奇异值(以及对应的 $U$ 的列和 $V^{\top}$ 的行),就能得到 Frobenius 范数意义下 $W$ 的最优秩- $k$ 近似:

\hat{W}_k = U_{:,1:k} \, \Sigma_{1:k,1:k} \, V_{:,1:k}^{\top}, \qquad \| W - \hat{W}_k \|_F = \min_{\text{rank}(\hat{W}) \leq k} \| W - \hat{W} \|_F.

这对 LLM 压缩的实际吸引力在于: $\hat{W}_k$ 可以存储和相乘为两个更小的矩阵, $A = U_{:,1:k}\Sigma_{1:k,1:k}^{1/2} \in \mathbb{R}^{m\times k}$ 、 $B = \Sigma_{1:k,1:k}^{1/2}V_{:,1:k}^{\top} \in \mathbb{R}^{k\times n}$ ,于是原本的前向计算 $y = Wx$ 变成 $y = A(Bx)$ ,参数量从 $mn$ 降到 $k(m+n)$ 。当 $k \ll \min(m,n)$ 时,这是相当大的内存节省,原则上也是计算量的节省,因为两个小的 GEMM(通用矩阵乘)理论上可以比一个大的更便宜。

flowchart LR
    subgraph Dense["稠密层: mn 个参数"]
        W["W (m x n)"]
    end
    subgraph SVD["完整 SVD(精确分解,尚无节省)"]
        U["U (m x m)"] --> S["Sigma (m x n)<br/>对角矩阵,已排序"] --> V["V^T (n x n)"]
    end
    subgraph LowRank["截断秩-k: k(m+n) 个参数"]
        A["A = U[:,1:k] Sigma[1:k,1:k]^0.5<br/>(m x k)"] --> B["B = Sigma[1:k,1:k]^0.5 V[:,1:k]^T<br/>(k x n)"]
    end
    W -- "分解" --> U
    S -- "只保留前 k 个奇异值" --> A
    B -- "y = A(Bx) 替代 y = Wx" --> Out["前向计算输出"]

Figure A(数学可视化图）：从稠密权重矩阵到其截断低秩因子化的过程。 中间那一块是精确、无损的 SVD;底部那一块才是只保留前 $k$ 个奇异方向后真正被存储和执行的部分——这正是本文审计的每一个方法在机制上都会执行的操作,它们的区别仅在于如何选择哪些方向重要。

问题在于——也正是为什么这个方向能积累出几十篇论文而不是一篇——对原始权重直接做 SVD 是对”模型行为”很糟糕的近似,因为我们真正关心的是模型的行为,而不是权重矩阵本身在 Frobenius 范数下的重构误差。一个奇异值很小的方向,如果流经它的激活值很大,依然可能非常重要(ASVD、SVD-LLM 这类”激活感知”方法就是为了修正这一点);而对所有层用统一的秩预算,又忽略了不同层的可压缩程度天差地别(MoDeGPT、Basis Sharing 这类”自适应秩分配”方法针对的正是这一点)。这也是为什么这个领域积累了这么多变体:激活感知重缩放、损失敏感截断、跨层参数共享、自适应秩分配、可微/可学习截断。

Keep Ratio(保留比):大家定义方式各不相同的那个预算轴

每篇 SVD 压缩论文都需要说清楚”我们压缩了多少”,而这恰恰是可比性问题的起点。LowRankArena 的做法是敲定一个统一的标准定义(下面会展开)。直觉上,“keep ratio” $r$ 应该表示:对于这些被压缩层原本需要存储的全部参数,压缩后实际存储了其中的多大比例。keep ratio 为 60% 意味着压缩层用了原始参数预算的 60%(即真实降低了 40%),而不是”保留了 60% 的奇异值”——后者是一个不同、且方法相关的数字,因为 $k(m+n)/mn$ 和 $k/\min(m,n)$ 并不是同一个比例。

困惑度 vs. 多选题准确率:两种截然不同的失效模式

这篇论文反复出现的两类评测指标,衡量的是压缩模型两种完全不同的失效模式:

困惑度(PPL),在留存文本(WikiText-2、C4)上计算,衡量模型预测的下一个 token 分布与真实文本的匹配程度,对每个 token 做(几何)平均。它对生成质量极其敏感:即使一段本来还算流畅的文本中只有一个 token 被严重误判,也会让困惑度飙升,因为 $\text{PPL} = \exp\left(-\frac{1}{T}\sum_{t=1}^T \log p(x_t \mid x_{<t})\right)$ 是负对数似然平均值的指数,少数几个极低概率的 token 会在指数内部主导整个平均值。
多选题准确率(MCQ),在 BoolQ、ARC、HellaSwag、WinoGrande 等任务上计算,只要求模型正确地给少数几个候选答案排序。即便模型的生成流畅度已经严重退化,它仍然可能正确地把”是”排在”否”之上——因为对少数几个选项排序,是比重现整段流畅 token 序列粗糙得多的信号。

这篇论文的核心警示是:这两类指标可能严重不一致,一个在 MCQ 上看起来还行的方法,在 PPL 上可能已经悄悄崩溃——意味着它在实际使用中会产生支离破碎、不连贯的生成结果,即便”通过”了多选题评测集。

一个具体的数字直观感受,解释为什么 PPL 要苛刻得多。 假设一个模型在 $T=100$ 个位置中,每个位置都对正确的下一个 token 给出概率 $p=0.5$ ,但其中一个位置因为压缩得很差的层导致对正确 token 只给出了 $p=0.0001$ 的概率(那个位置的信心下降了 5000 倍,对一个遇到分布外激活模式的压缩模型而言完全可能)。困惑度的贡献主要由那一项主导:那个位置的 $-\log(0.0001) \approx 9.21$ 的单位是 nat,相比之下其他每个位置只有 $-\log(0.5) \approx 0.69$ nat。在 $T=100$ 个位置上求平均,单单这一个坏掉的 token 就向平均值贡献了大约 $9.21/100 \approx 0.092$ nat——相当于另外大约 13 个本来完美的位置变错才会带来的贡献。只要出现少量这样的罕见但严重误判的 token(而激进的低秩截断恰恰容易产生这样的 token,因为它会不均匀地扰乱权重方向谱的尾部),就足以把困惑度推到数百甚至数千,而一个恰巧不会探问到这些脆弱位置的 MCQ 任务则根本注意不到。

结构化剪枝:另一条压缩范式

结构化剪枝(如 LLM-Pruner、SliceGPT、BlockPruner)整体移除架构组件——注意力头、权重矩阵的整行/整列,或整个 Transformer 块——产生一个更小的稠密模型,而不是因子化模型。二者的取舍是:剪枝改变了模型的形状,无法精确保留原始接口(存活下来的组件需要重新拼接,拼接处有时会丢失信息),而 SVD 因子化精确保留了每一层原始的输入/输出接口,只改变层内部发生的计算。这篇论文把结构化剪枝当作一个关键基线,要求 SVD 方法在同等参数预算下与之诚实比较,而不只是自己内部相互比较。

为什么”理论 FLOPs 节省”不等于”推理更快”

GPU 在跑 LLM 推理任务时会经历两种截然不同的计算模式:

Prefill(预填充,处理输入 prompt):计算受限(compute-bound)。GPU 一次性对很多个 token 做大量矩阵乘法,减少 FLOPs(SVD 因子化在名义上做到的事)能直接带来帮助,因为瓶颈就是算术吞吐量。
Decode(解码,逐 token 自回归生成输出):内存带宽受限(memory-bandwidth-bound)。每一步只处理每个序列新增的一个 token,涉及的矩阵乘法是”瘦”的(相对权重矩阵大小,批量/序列维度很小),真正的瓶颈变成了权重从 GPU 内存流出的速度,以及内核启动开销,而不是这些权重需要多少次乘加运算。

这个区分正是这篇论文第三个、也是实践上最重要的发现的核心:一个 SVD 方法可以减少原始参数量和 FLOPs(帮助 prefill),同时对解码阶段的吞吐量毫无帮助——甚至有害,因为在内存带宽/内核启动开销主导的场景下,用两个更小的低秩 GEMM 替代一个大而优化良好的稠密 GEMM,实际上可能更慢,即便它做的算术运算严格更少。

LowRankArena 平台:设计与机制

架构总览:各部分如何拼接在一起

在深入探讨促成这个平台诞生的审计之前,先看看平台本身的架构会更有帮助。LowRankArena 不是一个单一脚本——它是一个分层系统,把方法适配器、固定的预算/任务/推理规范,以及一组报告轨道连接在一起:

flowchart TB
    subgraph Input["输入"]
        A1[SVD 方法代码<br/>ASVD / SVD-LLM / DoBi-SVD<br/>Basis Sharing / MoDeGPT]
        A2[骨干模型<br/>Llama-1-7B / Llama-3.1-8B<br/>Qwen3-8B-Base]
    end
    subgraph Core["LowRankArena 核心"]
        B1[方法适配层<br/>统一调用约定]
        B2[标准化保留比<br/>预算强制执行]
        B3[任务集<br/>MCQ + PPL + 数学/MMLU]
        B4[vLLM 推理链路<br/>TTFT / 端到端 / 吞吐量]
    end
    subgraph Output["报告轨道"]
        C1[主排行榜]
        C2[文献对齐]
        C3[更广泛的评测]
        C4[推理加速]
        C5[可行性审计]
    end
    A1 --> B1
    A2 --> B1
    B1 --> B2
    B2 --> B3
    B2 --> B4
    B3 --> C1
    B3 --> C2
    B3 --> C3
    B4 --> C4
    B2 --> C5

Figure 1（架构总览图）：LowRankArena 的分层评测架构。 方法代码和骨干模型权重通过一个共同的适配层进入系统;标准化的保留比预算和固定的任务/推理规范随后被统一应用,再分流到五个报告轨道中。

这张图想传达的关键结构性事实是:每个方法都要经过相同的适配、预算强制执行,以及任务/推理层,结果才会进入任何一个报告轨道。这正是跨方法比较之所以有意义的根本原因——没有任何方法能走一条私有的评测通路。

数据流:从原始方法主张到标准化结论

把这个审计看作一个随时间推进的流水线也很有帮助——每个方法都要经历一次从”发表时的原始自报形态”到”在本平台下被标准化的形态”的转变:

flowchart LR
    P1[原始论文<br/>自报比例,<br/>自选任务子集] --> P2[在统一接口下<br/>重新实现/适配]
    P2 --> P3[应用标准化<br/>保留比公式]
    P3 --> P4[在固定任务集<br/>上评测]
    P3 --> P5[通过共享 vLLM<br/>链路服务]
    P4 --> P6[标准化后的<br/>准确率/PPL 结论]
    P5 --> P7[标准化后的<br/>加速比结论]
    P6 --> P8[跨骨干模型/<br/>保留比比较]
    P7 --> P8
    P8 --> P9[已报告的进步:<br/>条件性的,而非普适的]

Figure 2（数据流/流水线图）：从一个方法最初自报的主张到 LowRankArena 标准化结论的过程。 每个方法在 P2 这一步都会失去它原本由作者选定的评测条件,从 P3 开始被完全一致地重新测量——正是这一步真正消除了下文审计所发现的协议层面的混淆因素。

在设计评测平台之前,作者做了一件方法论上很聪明、也相当少见的事:不是凭个人经验断言”先前的评测不一致”,而是系统性地抓取了 76 条关于近期 SVD 压缩论文的公开 OpenReview 审稿人/领域主席意见,并对反复出现的抱怨进行了分类。

Figure 3（论文 Fig.2）：76 条公开 OpenReview 意见中反复出现的评审关切——覆盖范围狭窄、基线薄弱各占 22.4%,缺少端到端速度报告占 21.1%,预算不匹配占 17.1%,混合精度/重映射混淆占 6.6%,缺失可复现材料占 5.3%。

六大反复出现的抱怨类别,按出现频率排序:

覆盖范围狭窄(22.4%,17/76):测试的模型家族或任务版本太少,难以泛化。
基线薄弱(22.4%,17/76):与过时或调参不充分的既有方法做比较。
缺少端到端速度(21.1%,16/76):只报告压缩比,从未用真实推理延迟/吞吐量做验证。
预算不匹配(17.1%,13/76):不同论文对”压缩比”的定义互不兼容,跨论文比较毫无意义。
混合精度/重映射(6.6%,5/76):量化辅助技巧被不透明地折入所谓的”低秩”数字中。
缺失可复现材料(5.3%,4/76):没有发布代码/权重,后续比较只能依赖自报数字。

这个审计本身就是一个很好的”用证据说话”式动机构建案例:不是套路化地喊一句”这个领域缺乏标准化”,而是用真实审稿文本样本给出可量化的证据——这比大多数系统论文的证据标准要高一档。

设计原则:把”什么变了”和”怎么测的”分开

LowRankArena 的核心设计哲学,按作者的说法,是固定住那些在先前工作中最容易变化的评测假设,这样性能差异才能归因于压缩方法本身,而不是评测设置里隐藏的差异。具体来说,它同时且独立地控制四个轴:

模型覆盖 —— 测哪些骨干模型(老一代 LLaMA-1/2-7B,以及更新的 Llama-3.1-8B、Qwen3-8B-Base)。
任务覆盖 —— 测哪些评测集、如何打分(固定的 LM-Eval-Harness 版本、固定的 prompt/shot 配置、固定的困惑度计算协议)。
压缩预算 —— keep-ratio 定义(下文展开),对每个方法一视同仁地应用。
推理测量 —— 单一共享的 vLLM 推理链路,固定硬件、精度、请求画像。

标准化 Keep-Ratio 公式,逐项展开

这是论文里唯一一块真正的数学机制,值得仔细推导,因为搞错这一点正好会导致 17% 的审稿人所抱怨的”预算不匹配”问题。对于一组被压缩的线性层 $\mathcal{L}$ ,层 $l$ 的原始权重为 $W_l \in \mathbb{R}^{m_l \times n_l}$ ,压缩后保留秩 $k_l$ :

r = \frac{\sum_{l \in \mathcal{L}} k_l (m_l + n_l)}{\sum_{l \in \mathcal{L}} m_l n_l}, \qquad \text{满足} \quad \text{prec}(\hat{W}_l) = \text{prec}(W_l).

逐项拆解:

分子 $k_l(m_l+n_l)$ :低秩因子化后层 $l$ 实际存储的参数数量——回顾前面 SVD 那一节,秩- $k_l$ 因子化存储两个矩阵,大小分别为 $m_l \times k_l$ 和 $k_l \times n_l$ ,总共 $k_l m_l + k_l n_l = k_l(m_l+n_l)$ 个标量。
分母 $m_l n_l$ :原始稠密层本来需要存储的参数数量。
“先对所有压缩层求和再算比例”而不是”逐层算比例再平均”:这一点很重要。以参数量加权的”分子求和/分母求和”跟”逐层比例的平均”并不是一回事,因为各层大小差异极大(注意力投影 vs. MLP 上/下投影)。先累加原始参数计数再求比例,才能正确地按每层实际贡献的参数量来加权整体预算——这正是”总内存占用”这个实际部署中真正关心的量所需要的加权方式。
精度约束 $\text{prec}(\hat{W}_l) = \text{prec}(W_l)$ :这是一个容易被忽略、但直接针对”混合精度/重映射”这类抱怨的关键约束。它规定:压缩后的权重必须保持与原始权重相同的数值精度(比如 FP16 保持 FP16)。没有这条约束,一个方法可以悄悄地在做秩压缩的同时再量化到 INT8 或 INT4,然后把合并后的比例当作纯粹的低秩节省来报告。通过把精度锁定为相等,这个公式把低秩效应从量化效应中隔离出来——这是两个正交的压缩轴,把它们混在一起(正如 6.6% 的审稿样本所指出的)会让人根本无法判断哪个杠杆才是实际提升的来源。

设计取舍讨论——为什么用这种特定的归一化,以及它在哪里仍然可能误导人。 一个显而易见的替代方案是把 keep ratio 报告为简单的秩比例 $k_l / \min(m_l, n_l)$ ,逐层平均。这样计算更简单,但有两个缺陷是论文所选公式避免了的:(1)它忽略了 $m_l \neq n_l$ 的一般情况(例如 MLP 上投影通常比其”高”要宽 4 倍),因此在同样的秩比例下,不同层形状实际节省的参数量是不同的;(2)朴素的逐层平均会让方法能够通过”用力压缩许多不重要的小层、几乎不动少数几个巨大而重要的层”来在整体数字上作弊——而参数量加权的公式让这种”钻空子”变得更难,因为最大的层必然主导求和结果。但即便是这个公式仍有可能误导人的边界情况:它只反映了聚合结果,却完全不说明哪些层被压缩到了什么程度。两个 $r=0.6$ 相同的方法,如果一个对每一层都均匀压缩到 60%,另一个把 90% 的层压缩到 40% 而完全不动最敏感的 10% 的层,实际质量可能天差地别——聚合比例完全掩盖了这种分布式选择,而这恰恰是像 MoDeGPT、Basis Sharing 这类”自适应秩分配”策略赖以取胜的地方。

Keep-Ratio 公式的一个实际数值例子

抽象公式在代入真实数字跑一遍之后会更容易被信任。考虑一个小型双层 Transformer 块：一个注意力输出投影 $W_1 \in \mathbb{R}^{4096 \times 4096}$ ,一个 MLP 下投影 $W_2 \in \mathbb{R}^{4096 \times 11008}$ （大体按 Llama 风格的比例）。假设某个方法对 $W_1$ 保留秩 $k_1 = 1024$ ,对 $W_2$ 保留秩 $k_2 = 2048$ 。代入公式:

r = \frac{k_1(m_1+n_1) + k_2(m_2+n_2)}{m_1 n_1 + m_2 n_2} = \frac{1024 \times 8192 + 2048 \times 15104}{4096 \times 4096 + 4096 \times 11008}.

分开计算分子与分母:分子 $= 8{,}388{,}608 + 30{,}932{,}992 = 39{,}321{,}600$ 。分母 $= 16{,}777{,}216 + 45{,}088{,}768 = 61{,}865{,}984$ 。所以 $r \approx 0.636$ ,即 63.6% 的保留比——尽管 $W_1$ 的秩比例 $k_1/\min(m_1,n_1) = 1024/4096 = 0.25$ 和 $W_2$ 的秩比例 $k_2/\min(m_2,n_2) = 2048/4096 = 0.5$ 看上去彼此相差不小,与聚合值 0.636 也很不一样。这具体地说明了前面的设计取舍要点:聚合 keep ratio 被更大的 MLP 层参数量（4500 万 vs. 1680 万）主导,因此一个方法可以在向 MLP 层宽松分配秩、对注意力层保留一个更激进的 0.25 秩比例(而注意力层可能对表征能力更关键)的情况下,依然报告出一个相对较高的聚合 $r$ ——这正是聚合数字本身无法单独区分出来的那种分配选择。

对比制度:为什么论文明确拒绝把所有方法都放到同一张排行榜上

第二个不那么显而易见但很有价值的设计决策:LowRankArena 刻意不把统一精度 SVD、混合精度 SVD、基于重映射的方法和运行时自适应方法混合成一张排行榜。而是:

主要评测制度是统一精度 SVD,在完全相同的预算和精度下与结构化剪枝比较。论文所有的头条结论都来自这个制度。
混合精度、重映射、运行时自适应变体仅作为辅助审计报告(可复现材料覆盖度、70B 规模下的可行性、跨设备鲁棒性)——明确不并入主排行榜。

为什么/替代方案/边界: 显而易见的替代方案是搭建一张大排行榜,把所有方法放进去,让每个方法用它”最好”的配置(包括辅助技巧)一起排名——这实际上更接近目前大多数综述和后续论文常见的比较方式,即从每篇原始论文的最佳配置中借用数字。这个设计选择避免的问题是:一个使用了混合精度的方法会仅仅因为它多用了一个额外的、不相关的压缩轴(位宽降低)而在整体”压缩比”上取胜,而不是因为它的低秩子空间选择做得更好——这正是论文想要消除的混淆因素。这个选择带来的边界/局限是:意味着这篇论文无法得出诸如”DoBi-SVD 的混合策略是最佳可部署方案”这类结论,因为这个策略被明确排除在主比较之外;真正关心”不论技术手段、实际部署中最好的压缩效果”的读者,需要单独查阅辅助审计部分——而这些部分在论文自身的叙事框架里是次要的。

标准化评测流程,逐步拆解

虽然 LowRankArena 是一个平台而不是一个学习算法,但它确实定义了一套精确、可重复的流程——按本系列一贯的做法,值得把这个流程写成明确的伪代码,因为”标准化具体如何落地执行”的细节恰恰决定了这个平台的结论是否可信。

算法 1:标准化 SVD 方法审计流程(LowRankArena 的核心比较流程)

输入: 方法集合 M = {ASVD, SVD-LLM, DoBi-SVD, Basis Sharing, MoDeGPT}
     骨干模型集合 B = {Llama-1-7B, Llama-3.1-8B, Qwen3-8B-Base}
     保留比集合 R = {0.8, 0.6, 0.4}
     固定任务集 T(7 个 MCQ 任务 + WikiText-2/C4 困惑度 + MathQA/MMLU-Math)
     固定推理链路 H(vLLM 0.18.1,固定硬件/精度/请求画像)

1.  对每个骨干模型 b in B:
2.      计算 dense_baseline_scores(b, T)          # 建立未压缩的参考基线
3.      对每个保留比 r in R:
4.          对每个方法 m in M:
5.              # 步骤 A:标准化预算
6.              把方法 m 应用到骨干模型 b,目标保留比 r
7.                  使用(保留比公式),精度固定与原始模型一致
8.              # 步骤 B:在方法自身需要校准的地方标准化校准
9.              使用方法 m 原生的默认校准配方
10.                 (逐方法记录:如 ASVD 用 32 条 WikiText-2 序列,
11.                  MoDeGPT 用 128 条,SVD-LLM/DoBi-SVD/Basis Sharing 各用 256 条)
12.             # 步骤 C:主比较中排除额外附加的压缩后恢复训练
13.             不应用 update_u256 / alpaca_recover 之类的额外微调步骤
14.             # 步骤 D:在固定任务集上评测
15.             scores[b][r][m] = evaluate(压缩后模型, T)  使用 LM-Eval-Harness v0.4.11
16.             # 步骤 E:在固定链路上评测推理效率
17.             speed[b][r][m] = serve_and_measure(压缩后模型, H)
18.     记录 ranking(b, r) = sort(M, by = scores[b][r][*].mcq_avg, 降序)
19. 比较相同 r 下不同骨干模型 b1 vs b2 的 ranking(b, r) → Q1(稳定性)
20. 比较 scores[*][r][*] 与 structured_pruning_scores[*][r]     → Q2(与剪枝比)
21. 比较 speed[*][r][*] 与理论 FLOPs 降幅               → Q3(收益是否真实?)
输出: 标准化排行榜(Table 1)、排名变化图(Fig.4)、
     与剪枝对比图(Fig.5)、推理加速图(Fig.6)

逐步说明每一步为什么重要:

步骤 A(第 6–7 行) 直接落实上面推导的保留比公式——每个方法都被强制放到完全相同的有效参数预算、完全相同的数值精度上,这是让最终数字具备可比性的最大一根杠杆。
步骤 B(第 9–11 行) 是一个更微妙、在我看来略显不完美的折中:论文并没有强制所有方法使用完全一致的校准集大小,而是让每个方法保留自己”原生”的默认设置(ASVD 用 32 条序列,其他方法最多用 256 条)。论文自己的 Table 2(下文讨论)明确对这个未标准化的选择到底有多大影响做了审计——这是罕见的、论文主动坦诚审视自身协议软肋的做法。
步骤 C(第 13 行) 排除了一整类混淆因素:多篇 SVD 论文的最佳数字是在额外的轻量微调/恢复训练(比如 LoRA 风格的低秩适配器恢复)之后得到的。通过在主比较中排除这一步,LowRankArena 把”纯粹的子空间选择算法质量”从”你的微调配方有多好”这个不同的、值得单独研究的问题中分离出来——论文明确表示不将两者混为一谈,这是一个诚实的范围界定。
第 19–21 行 是构成论文后续部分的三个研究问题(Q1、Q2、Q3),每一个都是固定其他所有变量、只变化一个感兴趣变量的受控比较。

实验发现,逐条拆解

Q1:排名并非跨架构不变

Figure 4（论文 Fig.4）：80% 保留比下 Llama-1-7B、Llama-3.1-8B、Qwen3-8B-Base 之间的方法排名变化。MoDeGPT 在两个 Llama 骨干上都领先,但在 Qwen3 上跌至第 2;ASVD 从 Llama-1 到 Llama-3.1 从第 2 跌到第 5,又在 Qwen3 上反弹到第 1。

支撑论文核心结论的关键证据是 Table 1 和 Figure 4,一旦摊开来看,这个模式相当引人注目:在 80% 保留比下,MoDeGPT 在 Llama-1-7B(0.880 MCQ 均值)和 Llama-3.1-8B(0.766)上都是明确的第一,但在 Qwen3-8B-Base 上却跌到第二(0.594),被 ASVD(0.696)超越——而 ASVD 正是在同一保留比下,在 Llama-3.1-8B 上排名最后(第 5,0.304)的方法。Basis Sharing 呈现相反的模式:它在 Llama-1-7B 上排第 4,到 Llama-3.1-8B 上升到第 2,又在 Qwen3 上回落到第 3。

为什么会这样,机制上: 论文把这归因于不同模型家族的架构特性与各方法的假设之间产生了不同的交互。ASVD 的激活感知重缩放假设了激活幅度与奇异值重要性之间的特定关系,这种关系似乎在 Qwen3 的激活统计特征上表现良好,但在 Llama-3.1 上表现较差;MoDeGPT 的模块化分解策略(执行自适应的模块级秩分配)似乎能在两代 LLaMA 之间(它们共享相当多的架构血缘)很好地迁移,但在结构不同的 Qwen3 注意力/MLP 模块上就不那么灵了。论文谨慎地指出这只是一个经验观察,而不是一个被充分解释的因果机制——没有哪个方法的设计被证明确切地因为某个已识别的具体架构原因而失败;这篇论文的贡献是证明了这种不稳定性存在且幅度很大,而不是逐层解释其根本原因。

60% 保留比面板(此处未完整复现,详见论文 Table 1)显示了同样的定性模式:MoDeGPT 和 Basis Sharing 在 Llama-1-7B 到 Llama-3.1-8B 之间互换了前两位,而 Basis Sharing 在这个更激进的预算下成为 Qwen3-8B-Base 上的绝对领先者。

设计取舍讨论——为什么是三个骨干模型,够不够? 在架构上截然不同的模型家族(老一代 LLaMA vs. 现代 Llama-3.1 vs. Qwen3)之间进行测试,是证明”非不变性”效应所需的最小合理实验——单一骨干模型永远无法展示这种效应。显而易见的替代方案——测试更多骨干模型(Mistral、Gemma、DeepSeek 等)——会进一步强化泛化性主张,而它的缺失是一个真实的范围局限:只用三个骨干模型(其中两个还共享 LLaMA 血缘),我们还无法判断”架构相关的排名不稳定性”是 SVD 压缩的普遍属性,还是特定于 LLaMA 风格与 Qwen 风格 Transformer 模块之间的某些差异(RMSNorm 的位置、QK 归一化、GQA 头组配置等——其中几项架构细节都有可能与哪些权重方向承载”重要”的激活对齐信号产生交互)。

困惑度揭示了准确率指标掩盖的差距

论文的第二个主要发现,也是对实践者更具指导意义的一个,直接体现在 Table 1 的 PPL 列中:在 Llama-3.1-8B 上的 60% 保留比下,SVD-LLM 和 Basis Sharing 的 C4 困惑度分别达到 1187.78 和 461.21——相比之下,稠密模型的 C4 困惑度只有 9.10。这不是”稍微差一点”,而是质变式的崩溃:数百甚至数千的困惑度通常对应着一个基本无法产出连贯文本的模型。然而这两个方法各自的 MCQ 均值(分别为 0.425 和 0.469,详见完整 Table 1)仍然远高于论文为其七任务 MCQ 集计算出的 35.7% 随机猜测下限。

Figure 5（论文 Fig.5）：Llama-3.1-8B 上零样本低秩压缩的"能力悬崖"。左图:在各保留比下,SVD 方法在 MCQ 准确率上大体与结构化剪枝保持竞争力。右图:在对数刻度的 C4 困惑度轴上,几种 SVD 方法(虚线青色 = SVD-LLM v1)在激进保留比下呈现出剪枝方法(实线)不那么明显的严重上扬"悬崖"。

为什么这种差异重要,而不只是一个奇闻。 MCQ 任务只要求模型给正确答案分配比(通常 2–5 个)候选选项更高的对数概率——这是一种粗糙的相对排序信号,即便模型整体生成分布已经相当严重地退化,这个信号也可能存活下来。而困惑度则要求模型预测的分布在流畅、开放式文本的每一个 token 位置上都要与真实分布保持接近。一个模型可能保留了”A 比 B 更可信”这种判断力,却完全丧失了生成连贯自由文本的能力——这正是本文双指标协议要暴露的那种差距。如果一篇压缩方法论文只报告 MCQ 准确率(论文 Fig.2 审计隐含批评的一种常见做法),它就可能隐藏一种在任何开放式生成任务(聊天、代码、摘要)中都不可用的压缩配置,而在排行榜上看起来依然体面。

论文在这里还补充了一个细微之处:ASVD 在 Llama-3.1-8B 80% 保留比下的 0.353 MCQ 均值,几乎正好落在 0.357 的随机猜测下限上——意味着这个数字应该被读作”没有保留任何能力”,而不是”轻度退化”,这个区分如果没有明确计算并报告随机下限,单看一个百分比数字是传达不出来的。

Q2:SVD vs. 结构化剪枝——准确率上有竞争力,生成稳定性上落后

在匹配的参数预算下与 LLM-Pruner、SliceGPT、BlockPruner 比较(上图 Figure 3,左图),SVD 方法在整个 80%→40% 保留比范围内的 MCQ 准确率上都保持了大体上的竞争力——没有出现明显差距。但右图(C4 困惑度,对数刻度)讲述了不同的故事:在 60% 保留比下,即便是被测 SVD 方法中表现最好的 MoDeGPT(困惑度 51.82),仍然落后于 LLM-Pruner 的 34.85,而其他几种 SVD 方法差了一到两个数量级。论文的总结判断是:SVD 在粗粒度的准确率指标上与剪枝具备竞争力,但在激进压缩下呈现出剪枝更能优雅避免的”能力悬崖”——这很可能是因为剪枝整体移除结构单元(留下的组件是完整、未经修改的子网络),而 SVD 对每一个保留下来的权重都重新构造为近似值,因此近似误差在每一个保留参数上累积,而不是集中在移除边界处。

论文自身提出的实验设计警示: 这个 Q2 比较明确排除了剪枝和 SVD 双方任何压缩后的恢复微调(与前面伪代码 Algorithm 1 中”不做额外恢复”的策略一致),论文谨慎地指出,一旦重新引入每种方法各自的默认恢复协议,这个排名可能不再成立——这是一个诚实的范围界定声明,避免从这个特定实验中得出过度结论。

Q3:FLOPs 节省到延迟收益之间的差距

Figure 6（论文 Fig.6）：Llama-3.1-8B、60% 保留比下按请求画像划分的推理加速比。Prefill 与 Balanced 画像展示了很大的 TTFT 加速(SVD-LLM v2 最高达 4.20x)。Decode-heavy 画像下,端到端吞吐量接近 1x 或低于 1x,SVD-LLM v1 跌至 0.80x——即比未压缩的稠密模型更慢。

在我看来,这是这篇论文实践意义上最重要的单一发现,因为它直接挑战了几乎每篇 SVD 压缩论文摘要里隐含的一个假设:“参数/FLOPs 减少 N%” 会转化为”推理速度提升大约 N%“。用一套匹配的 vLLM 服务链路,在相同硬件、精度和请求流下测量得到的实际情况是:

Prefill-heavy 画像(长输入、短输出):五种方法的 TTFT 加速在 2.72x–4.20x 之间——这是减少 FLOPs 真正起作用的场景,因为 prefill 是计算受限的。
Decode-heavy 画像(短输入、长输出):端到端吞吐量加速塌缩到 0.68x–0.91x 的区间——意味着所有被测方法,包括表现最好的一个,一旦解码主导整个工作负载,都比未压缩的稠密基线更慢。

为什么会这样,机制上,呼应前面前置知识那一节: 解码阶段的推理每一步只发出一个 token 的计算量,这让每一次矩阵乘法都变成”瘦”的 GEMM(相对于庞大的权重矩阵,批量/序列维度很小)。在这种场景下,瓶颈是把权重矩阵从 HBM 流入 GPU 计算单元的速度,而不是算术运算本身——所以用两个较小的低秩 GEMM 内核(前面 SVD 那一节中的 $A(Bx)$ 分解)取代一个大而优化良好的稠密 GEMM 内核,增加了内核启动开销和中间张量的内存流量,却不能按比例减少真正卡瓶颈的内存带宽压力。两个”FLOPs 便宜”但依次执行的内核,可能会输给一个”FLOPs 昂贵”但只执行一次的内核——恰恰因为在这个场景下 FLOPs 从来就不是瓶颈。

论文自己标注的一个必要提醒: DoBi-SVD 实现了一种稠密回退机制——对于保留秩足够高、低秩因子化实际上无法节省内存带宽的层,它会回退为把该层作为一个稠密 GEMM 执行,而不是两个低秩 GEMM。这意味着 DoBi-SVD 的加速数字不能纯粹归因于”低秩因子化很快”;它部分反映的是一个关于何时不使用低秩执行的混合运行时策略决策。论文对此说明得很清楚,这对可解释性是个好信号,但也意味着上面 Figure 4(论文 Fig.6)的比较并非完全公平——被测量的一部分是算法质量,一部分是运行时工程复杂度。

辅助审计:校准敏感性、更大模型、更多设备

除了三个头条问题之外,论文还运行了几个更细粒度的辅助审计,每一个都在探究一个针对主结论的潜在质疑,值得总结:

校准敏感性(Table 2): 在 Llama-3.1-8B 80% 保留比下,只改变校准语料(WikiText-2 vs. C4 vs. Pile-Val),保持其他一切不变,发现三次 WikiText-2 重采样的排名顺序保持稳定,但具体分数会漂移,而 Basis Sharing 和 SVD-LLM 之间接近的一对排名,在换用 C4 校准时实际发生了反转。这说明 Algorithm 1 步骤 B 中”每个方法用原生校准配方”这个未标准化的折中,确实给接近的排名带来了一些真实的不确定性,但还不足以颠覆”明确领先者”的结论(那里的优势幅度大于观察到的校准诱发方差)。
70B 可行性审计: 尝试在单张 H200 GPU、固定算力预算下把每个方法扩展到 70B 参数模型,论文发现每一个被测方法都先撞上了工程墙,而不是算法墙:ASVD 被过时的 lm_eval 依赖冲突卡住,SVD-LLM v1 和 DoBi-SVD 撞上 GPU 内存上限,Basis Sharing 在其 CUDA 特征值求解器步骤中崩溃,MoDeGPT 在 Accelerate 的 GPU 卸载逻辑中失败。这些都不是根本性的算法局限——是软件成熟度的差距——但论文能标注出这一点是对的,因为这是一个真实存在的”实现就绪度”维度,如果只看 7B 规模的已报告数字是看不到的。
跨设备鲁棒性(Table 3): 在 RTX A5000(而非主评测用的 A100)上,以 60% 保留比重新测试 SVD-LLM v1,呈现出与主结果相同的定性模式——很大的 TTFT 收益(3.37x–3.80x)在端到端层面缩小或反转(0.68x–1.06x),取决于工作负载所处阶段——这说明 prefill/decode 不对称这个发现并非 A100 特有的假象。

完整重刷的定量结果:Llama-3.1-8B

为了让排名不稳定性这个论点从文字描述变得具体可见,值得重刷一下论文在 80% 保留比下在 Llama-3.1-8B 上的实际数字(原论文 Table 1),因为这正是上文讨论的、相对老代 Llama-1-7B 数字分歧最大的那个骨干模型。

方法	WikiText-2 PPL ↓	C4 PPL ↓	BoolQ	ARC-E	ARC-C	WinoG.	PIQA	HellaS.	OBQA	MCQ 均值 ↑	MathQA	MMLU-Math
Dense FP	6.24	9.10	0.831	0.824	0.549	0.746	0.812	0.793	0.454	0.716	0.396	0.437
ASVD	2011.38	1281.96	0.382	0.285	0.226	0.512	0.536	0.285	0.244	0.353	0.201	0.223
SVD-LLM v1	14.83	80.94	0.661	0.528	0.315	0.645	0.639	0.476	0.350	0.516	0.256	0.305
DoBi-SVD	556.59	1008.41	0.378	0.298	0.226	0.516	0.522	0.282	0.266	0.355	0.205	0.292
Basis Sharing	15.61	54.36	0.632	0.637	0.367	0.667	0.701	0.548	0.372	0.561	0.248	0.297
MoDeGPT	9.01	17.68	0.412	0.715	0.436	0.730	0.743	0.710	0.382	0.590	0.344	0.407

只有将这些数字完整铺开、而不是只看摘要,才能看到一些隐藏的事实:

MoDeGPT 的聚合领先(0.590 MCQ 均值)部分掌盖了一个单独看很异常的弱 BoolQ 得分(0.412) —— 它主要赢在 ARC-E/ARC-C/WinoGrande/PIQA/HellaSwag 上,而非在七个任务上均衡领先。Basis Sharing 尽管聚合分更低(0.561),却在 BoolQ 原始分上真正超过 MoDeGPT(0.632 vs. 0.412)。这正是论文说“聚合排名反映的是“生成稳定性与下游准确率之间的取舍，而不是方法质量的普适排序”这一说法的具体证据——即便在单一骨干模型单一保留比下,也没有任何一个方法能同时在每一个任务上都领先。
PPL 列的波动幅度远比 MCQ 列剧烈。 DoBi-SVD 的 C4 PPL(1008.41)大约是稠密基线 9.10 的 111 倍,而它的 MCQ 均值(0.355)却只比稠密基线的 0.716 低了大约 50%——这是对前面“困惑度要比 MCQ 准确率苛刻得多”这一说法的一个直接的、用单行真实数据就能看到的数字化例证,而不只是一个抽象主张。
SVD-LLM v1 和 Basis Sharing 的 PPL 值(80.94 和 54.36)都远比 MoDeGPT(17.68)差,尽管它们的 MCQ 均值还算有竞争力(0.516 和 0.561 vs. 0.590) —— 对一个在 MCQ 均值上只落后 5–13 个百分点的方法来说,C4 困惑度却差了大约 5 倍,这正是这篇论文双指标协议旨在暴露的那种 PPL/MCQ 分歧——而如果只看基于 MCQ 的排行榜,这种分歧将完全不可见。

批判性分析

(a) 这篇论文本身的弱点与瑕疵

被审计的方法全部来自 2023–2025 年;这个领域一直在往前走。 被重新评测的五种方法(ASVD 2023;SVD-LLM、Basis Sharing、MoDeGPT 2024;DoBi-SVD 2025)不包括本系列已经报道过的几种 2026 年方法——SigmaScale、AIR、Swift-SVD、LACE-SVD、SVD-Surgeon、GRASP、Zero-Sum SVD、CARE-LoRA。论文的相关工作部分承认了大多数方法的存在(用编号引用),但没有把它们通过标准化框架重新跑一遍。这意味着,论文的具体数字排名在发表时相对于该领域的当前前沿已经有些过时,尽管其方法论意义——排名是上下文相关的,先标准化再相信排行榜——依然有效,而且很可能同样适用于它没有测试的新方法。
只有五种方法,对于一篇核心论点是”排名不稳定”的论文来说样本偏窄。 在五种方法、三个骨干模型之间证明不稳定性,是有说服力但不是决定性的;更大的样本(比如 10–12 种方法)会让”不存在稳定排名”这个论断更有说服力,因为只有五个候选者时,排列组合数量受限(5! = 120 种可能的排序),在三个骨干模型上观察到”排名变了”是即便仅有相当程度的测量噪声,也相对容易达到的门槛。
论文没有为主表(Table 1)排行榜报告置信区间或重复实验。 校准敏感性审计(Table 2)确实为某一骨干模型某一保留比下的 WikiText-2 重采样报告了标准差,但排名变化主张(Figure 4/Q1)所依据的主排行榜数字似乎是单次点估计。如果不知道在固定校准集但其它随机因素(如评测框架的打散、argmax 打分中的平局判定)不同的情况下 MCQ 均值的运行间方差,就很难完全区分”真实存在的架构相关排名不稳定性”和”恰好比通常假设的更大一些的测量噪声”。Table 2 的审计部分缓解了这一担忧(展示了 WikiText-2 内部最大差距 0.0284 小于大多数已报告的领先者优势),但并未覆盖主表的每一格。

(b) 作者低估或省略的局限

论文没有报告每个方法对各层/模块选择了怎样的压缩激进程度,尽管这很可能是解释架构相关排名变化最有说服力的机制。既然前面推导过的 keep-ratio 公式是隐藏了逐层分配选择的参数加权聚合值,要理解为什么MoDeGPT 能在两代 LLaMA 之间良好迁移却不能迁移到 Qwen3,恰恰需要这种逐层拆解——而这在论文正文乃至附录概述中都没有提供。这是一个错失的机会:把一个经验性观察(“排名变了”)转化为一个机制性解释(“排名变化是因为方法 X 把秩分配给了注意力投影而方法 Y 分配给了 MLP 投影,而 Qwen3 的 GQA 配置改变了哪种分配策略更有利”)。
BoolQ 异常值(某个方法得分 0.41,被标注为”完全可复现……反映了强烈的输出标签偏置”)在正文中被提及但没有深入探究。 论文把这个问题留给了附录(“Appendix B.6”),但一个在广泛使用的评测任务上出现的可复现、确定性异常,恰恰是那种可能超出这一篇论文范畴的发现——如果某个特定压缩配置系统性地偏向 BoolQ 上的某一个标签而不管实际问题是什么,这就是关于校准/压缩交互的证据,其他大量使用 MCQ 的压缩论文也应该检查一下这个问题;正文中更充分的处理(而不是指向附录)会让这个贡献更有力。
摘要中”没有对结构化剪枝的一致优势”这个表述,略微夸大了 Q2 证据实际支持的结论。 MCQ 上有竞争力、PPL 上落后的模式是一个真实且重要的细微差别,但”没有一致优势”读起来比其证据基础(单一骨干模型,两个方法家族都没有应用恢复微调)能完全支撑的结论更强——论文正文对这个细微差别的处理其实比摘要级别的总结措辞更谨慎。

(c) 具体、可执行的改进建议

把标准化框架扩展到至少覆盖 2023–2026 年的 10 种方法,包括本系列已经报道过的更新的激活感知和损失感知变体(SigmaScale、AIR、Swift-SVD、GRASP、Zero-Sum SVD),测试”没有稳定排名”这个发现是变强、变弱,还是揭示出一种不同的模式(比如,或许更新的方法确实随着领域成熟而收敛到更稳定的排名,这本身就是一个有趣且可检验的假设)。
报告每个方法在每个骨干模型上的逐层秩分配画像,至少作为一份补充可视化材料(比如按层索引和层类型——注意力 vs. MLP——绘制保留秩比例的热力图),把”架构相关不稳定性”这个观察转化为一个未来方法设计者可以据此检验的可操作机制假设。
对主表(Table 1)排行榜的每一格至少跑 3 个随机种子(在保持校准语料固定的情况下,变化流程中存在的任何随机因素),并在点估计之外报告标准误,这样读者才能区分”这个特定的排名变化是一个稳健的发现”和”这个特定的排名变化落在测量流程的噪声下限之内”——这个区分,以论文本身谨慎、以证据为驱动的风格来看,如果资源允许,作者应该也会想要弄清楚。

补充说明:为什么“聚合 vs. 分任务”的差异对部署决策也很重要

有一个含义值得明确说出来,因为很容易在看一张结果表时一掃而过、没能内化:如果你是在为一个具体的生产场景选择 SVD 压缩方法,而不是为了一份论文的排行榜,Table 1 中的聚合 MCQ 均值对你的决策而言,可能是整篇论文里最不有用的数字。假设你的生产系统是一个事实问答助手,很依赖是/否、对/错这类判断(类似 BoolQ),而不是常识推理完成(类似 HellaSwag)或物理推理(类似 PIQA)判断。只看聚合 MCQ 均值,在 Llama-3.1-8B 80% 保留比下 MoDeGPT(0.590)似乎完全压倒 Basis Sharing(0.561)。但看 BoolQ 专属列,Basis Sharing(0.632)明显优于 MoDeGPT(0.412)——这个反转被聚合数字完全掩盖了。这并不是为本文人为构造的假设关切;它直接来自前文重刷的逐任务拆解数据,而且正是那种实践者在为某个具体下游应用评估这些方法时,应该直接对照自己的任务混合比例去检验、而不是只信任任何一个单一聚合排行榜数字的那种敏感度——论文自己的方法论教训(先标准化,再信任比较)其实同样递归地适用于读者应该如何对待这篇论文自己的聚合列。

可行性与成本:那个隐藏的第四个轴

有一个发现值得用超过一段话的篇幅来处理,因为它是这篇论文中最“工程实践”、最不“算法”的发现:70B 可行性审计可以说是实践者在真正想在生产规模下采用这些方法时,最先会撞上的东西——远早于他们有机会去争论准确率数字是否具备竞争力之前。

为什么这个发现在机制上重要。 SVD 压缩在压缩步骤本身(不是推理,而是产生压缩后权重的一次性成本)的计算瓶颈通常是对大矩阵的奇异值分解计算,对于 ASVD、SVD-LLM 这类激活感知方法来说,还需要一个校准前向传播来收集激活统计信息,这个前向传播必须与模型本身一同容纳在内存中。在7–8B 规模下,这对单张高内存 GPU 来说完全无压。到了 70B 规模,光是校准前向传播就需要多 GPU 张量并行设置,或 CPU/磁盘卸载——而正是在这个转折点上,论文发现每个被测方法的发布实现(而不是底层算法)都以不同的方式失败了:

方法	在 70B(单张 H200)下的失败模式	根本原因分类
ASVD	被过时的 `lm_eval` 依赖换卡	软件依赖过时
SVD-LLM v1	撞上内存上限	已发布代码无卸载支持
DoBi-SVD	撞上内存上限	已发布代码无卸载支持
Basis Sharing	在 CUDA 特征值求解器中崩溃	数值内核未在这个矩阵规模下验证过
MoDeGPT	在 Accelerate GPU 卸载过程中失败	卸载集成不兼容

设计取舍讨论——为什么把这个框架化为“实现就绪度”而不是“算法可扩展性”,以及这种框架仍可能误导人的地方。 论文小心地将这两个问题区分开来,这个区分在分析上很重要:这五种失败模式中没有一种能证明底层数学方法(基于 SVD 的因子化、激活感知重缩放、自适应秩分配)无法扩展到 70B——在每一种情况下,一个足够有动机的工程团队很可能能修复那个具体依赖、添加卸载支持,或换一个特征值求解器。但值得标注的边界情况是:这种框架可能会被读成在安抚实践者——“等工程问题解决了,准确率/排名结论(Q1/Q2)就会成立”,但论文实际上从未证明这一点,因为在固定的单张 H200 预算下,五种方法中没有一个成功在 70B 上完整跑完。MoDeGPT 在 LLaMA 家族上的优势,或者 Basis Sharing 在尾部任务上更强的表现,是否会在 70B 规模下持续、加强,还是反转,仍然是一个开放、未经检验的问题;读者不应该在没有独立验证的情况下,把 7–8B 规模的排名结论直接外推到更大的模型上——这是一个论文摘要里没有像 Q1 排名不稳定性发现那样突出强调的告诫。

可复现性说明

代码与权重库: 论文表示完整的平台、标准化方法适配器,以及超过 3 TiB 的压缩权重发布在 https://github.com/Zishan-Shao/lowrankarena.git,权重另外托管在 https://huggingface.co/Duke-CEI-SVD/LowRankArena。发布真实的压缩权重(而不只是代码)在压缩类论文中是一个明显更强的可复现性承诺,因为它让第三方可以完全跳过(通常需要大量 GPU 资源的)压缩步骤,直接进行独立重新评测。
任务/框架版本: LM-Eval-Harness v0.4.11、vLLM 0.18.1——两者都明确锁定版本,这一点很重要,因为这两个库在历史上都曾改变默认打分行为和服务性能特征,如果不锁定版本会悄悄破坏精确的可复现性。
硬件: 主要结果基于一张 NVIDIA A100 80GB PCIe GPU;跨设备鲁棒性检查还额外使用了 RTX A5000、L40S,以及单张 H200 141GB(用于 70B 可行性审计)——对于 7–8B 规模的主要实验来说,这是一个相当容易达到的硬件门槛,不过 70B 可行性工作需要 H200 级别的资源,大多数独立研究者并不具备。
正文未完全说明的部分: 具体的请求到达过程参数、预热次数、百分位数报告惯例,论文说明它们保存在附录表(A.1/A.2)中——这是标准做法,但意味着如果读者只依赖正文(而大多数对这篇论文的引用可能就只依赖正文),需要查阅附录或发布的 YAML 配置,才能精确复现 Figure 4(论文 Fig.6)中的推理评测数字。

补充 60% 保留比完整表格,与上表对比

为了让定量结果更完整,上面的 80% 保留比表格之外,这里补充 Llama-3.1-8B 上 60% 保留比的那一行——这是论文“能力悬岰”发现最明显的、更激进的压缩制度:

方法	WikiText-2 PPL ↓	C4 PPL ↓	BoolQ	ARC-E	ARC-C	WinoG.	PIQA	HellaS.	OBQA	MCQ 均值 ↑	MathQA	MMLU-Math
ASVD	22684.63	14186.23	0.405	0.254	0.257	0.491	0.507	0.260	0.284	0.351	0.192	0.286
SVD-LLM v1	199.84	1187.78	0.378	0.295	0.246	0.533	0.515	0.283	0.268	0.360	0.205	0.257
DoBi-SVD	987.51	1529.38	0.378	0.271	0.251	0.481	0.511	0.265	0.288	0.349	0.203	0.268
Basis Sharing	82.96	461.21	0.380	0.409	0.241	0.562	0.568	0.325	0.284	0.396	0.205	0.211
MoDeGPT	24.50	51.82	0.622	0.460	0.312	0.672	0.629	0.516	0.316	0.504	0.241	0.213

将这与上面的 80% 保留比表格对比,“能力悬岰”这个说法就变得具体了:ASVD 的 C4 PPL 从 1281.96(80% 保留)跃升到 14186.23(60% 保留)——保留比只降低了相对温和的 20 个百分点,却带来了 11 倍的进一步恶化,而 MoDeGPT 的 C4 PPL 在同样的预算降低下仅大约变为三倍(17.68 → 51.82)。这种对 keep-ratio 轴敏感度的不对称性本身就是方法相关的,如果你只孤立地看单一保留比,它根本不可见——这进一步说明了论文采用多保留比扫描设计(而不是单一点比较)的必要性,只有这样才能暴露出这个不稳定性发现。

一个值得命名的另一项设计取舍:为什么是五种方法,而不是更少或更多

任何仔细的读者对任何基准测试论文都应该问的一个问题:样本大小(五种方法)是基于有原则的理由选定的,还只是”在可用时间里能复现什么就用什么”?论文自己的表达(“公开可复现的 SVD 风格方法”)提示后者更接近真实情况——ASVD、SVD-LLM、DoBi-SVD、Basis Sharing、MoDeGPT 被选中,具体是因为它们的原始实现可用且可以适配到共享链路,而不是因为它们事先被选定为方法设计空间中最具代表性的(例如,这里没有一种以纯学习/可微秩分配为主要机制、与 MoDeGPT 的模块化分解区分开来的方法)。这是构建一个标准化平台首个版本时可理解且诚实的做法——你对自己真正能跑通的东西进行审计——但这确实意味着,就可复现性而言,这五种方法的样本是便利样本,而不是对算法设计空间的分层抽样。论文坐诚地说明了 DoBi-SVD 重复的压缩运行在校准敏感度审计(Table 2)的可用计算预算内未能完成,这本身就是这一点的一个小侁证据——可复现性的制约影响的不仅是最初包含了哪些方法,还影响了哪些比较甚至能被尝试。一个自然、可检验的预测:这类平台的下一代应该报告一个有原则的 SVD 压缩设计空间分类学(激活感知 vs. 损失感知截断;逐层 vs. 跨层分配;静态 vs. 学习式秩选择),并从每个格子中至少选定一个代表,而不是默认选择写作时候巧好拥有维护良好、可工作的公开仓库的那五个方法。

第二个实际例子:精确解读推理加速比数字

值得把论文实际报告的数字再推一遍具体计算,因为“4.20x TTFT 加速,0.80x 端到端吞吐量”这种说法对很容易说出口但也容易在不实际计算的情况下被误读。Table 3(在 RTX A5000 上的跨设备审计)给出了 SVD-LLM v1 在 0.6 保留比下的原始毫秒数字与加速比:

Prefill-heavy 画像: TTFT 从 3417ms(稠密)降到 1013ms(压缩后)——简单莫策的 3.37x 的首 token 时间降低,意味着用户等待第一个生成 token 的时间大约只有之前的三分之一。但端到端延迟只从 4925ms 降到 4659ms,仅 1.06x——因为 prefill-heavy 画像仍要生成 32 个输出 token(参见前面前置知识部分的画像表),且这个解码尾部完全未因压缩在 prefill 侧的收益而获益,一旦你看的是整个请求而不仅是首 token,它就主导了总墨钟时间。
Balanced 画像: TTFT 改善了 3.80x(1668ms → 439ms),但端到端延迟实际上变差了:5905ms → 7358ms,0.80x 的“加速比”(即实际上变慢了)。这是因为 balanced 画像的 128 个输出 token 放大了前文提到的解码时间成本(每步两个低秩 GEMM 而不是一个稠密 GEMM),这个按 token 计的解码开销乘以 128 步后,超过抵销了 prefill 时间的节省。
Decode-heavy 画像: TTFT 几乎没变(187ms → 205ms,实际上是 0.91x “加速比”即略慢一些,因为几乎没有 prefill 工作可以节省时间),而端到端延迟大幅度恶化:15136ms → 22359ms,0.68x——当工作负载以解码为主时,整个请求的墨钟时间慢了将近 50%。

为什么把这个计算走完比只看论文自己的汇总图表重要: 原始毫秒数字让一些只看比例的展示方式(主结果中的 Figure 6)可能掩盖的东西变得可见——decode-heavy 情况下的绝对延迟增加量(7223ms)在原始数值上超过了 prefill-heavy 情况下节省下来的绝对延迟(TTFT 和剩余时间共节省 2404ms + 266ms)。如果一个真实生产系统的请求混合即便只是适度地偏向 decode-heavy(而大多数对话式、智能体式 LLM 工作负载确实如此,因为输出长度通常超过输入处理的边际成本),部署这个特定压缩权重的净效果可能是比稠密模型更差的平均用户体验延迟,尽管单独看每一个 TTFT 数字都看似是一个改进。这正是论文 Q3 发现旨在防止读者掉进去的陷阱,而只有在看绝对延迟而非仅看比例时,它才完全可见。

结论

LowRankArena 的贡献不是一个新的压缩技巧——它是给整个子领域举起的一面镜子,它照出的景象对”单调进步”这个叙事(包括我在这个系列里已经写过的几篇论文,或多或少都在暗示这一点)并不友好。核心发现——SVD 压缩方法的排名是架构相关、预算相关、指标相关的,而不是普适的——正是那种发表起来令人不太舒服(它不会推进任何特定方法),但对文献而言很有价值的结果,因为它改变了下一个读到某篇 SVD 压缩论文结果表的人,应该以多大的信心去对待其中”超过先前 SOTA”这类主张。

在我看来,对实践者而言最具可操作性的单一收获是第三个发现:不要把”FLOPs 减少 N%“当作”推理速度提升约 N%“的代理指标,除非你专门测量了端到端的、decode-heavy 场景下的吞吐量——因为这篇论文记录的 prefill/decode 不对称(prefill 加速最高达 4.2x,decode 吞吐量却塌缩到 1x 以下)意味着你真正关心的那个工作负载——对大多数生产环境中的聊天/智能体/代码生成场景来说,通常是解码主导的——恰恰是名义上的低秩节省最不可能转化为真实墙钟时间收益的那个场景。如果你是在为部署而不是为论文排行榜评估某个 SVD 压缩方法,这篇论文的方法论(而不只是它对五种方法的快照)才是更持久有用的收获:在相信任何已报告的加速数字之前,坚持要求一个匹配的、端到端的、decode-heavy 推理评测——这与论文本身坚持在相信任何”新 SOTA”主张之前先要求一个匹配的、标准化的准确率评测,是同一种精神。

最后,对于每周追踪这个博客系列的读者:接下来几篇 SVD/低秩压缩相关的重评,在讨论任何声称的准确率或速度提升时,请预期会明确引用这篇论文的协议;也请预期本作者日后对任何”超过之前 SOTA”的主张,都会按 LowRankArena 设立的标准去审视——匹配的骨干模型、匹配的 keep-ratio 定义、匹配的精度,以及一个 decode-heavy 的端到端推理数字,而不只是一个头条比例。这是读者能从这篇论文里养成的最持久、成本最低的习惯——在接受任何单一结果表表面意义之前,花一点时间先持怀疑。

快速寄检清单:如何评判未来任何一个 SVD 压缩方法的主张

作为实用的结尾总结,从上面讨论过的每一项设计取舍中提取出来,这里是下次遇到新的 SVD 压缩论文(不论是在这个博客系列里还是其他地方)时可以应用的一份具体清单:

keep-ratio/压缩比定义是否阐述得足够精确,能否独立计算得到? 特别检查精度匹配条款(前面 2.2 节的公式)——如果一篇论文没有说明其报告的比例是否保持精度不变,就假设它可能没有,并相应地对该数字打个折扣。
困惑度是否与多选题准确率一并报告,并且在与校准集分开的留存语料上评估? 一篇只报告 MCQ 准确率、面向生成型压缩方法的论文应该引起警觉,根据本文 Table 1 摘录中展示的 PPL/MCQ 分歧证据。
是否与结构化剪枝在匹配的参数预算下进行了比较? 如果一篇论文只与其他 SVD 方法比较,问一问它在相同预算下与剪枝基线相比是否仍然占优——本文 Q2 发现提示,答案往往是”不如看上去那么好”。
是否存在端到端的、decode-heavy 推理测量,而不只是 FLOPs 或参数量减少? 根据 Q3 发现和上文 TTFT/E2E 的实际例子,一个 prefill 加速很亮眼的压缩方法,对解码主导的生产工作负载可能是净减速——总是单独要 decode-heavy 的数字。
结果是否在不止一个模型家族上得到验证? 鉴于上文 Figure 2/4 展示的架构相关排名不稳定性,仅在单一骨干模型(特别是只在老代 LLaMA-1/2)上展示的结果应被视为初步结果而非普适结论。
校准集大小与构成是否已披露,是否有任何敏感度分析? 根据 Table 2 发现接近的排名可能在不同校准语料下反转,未披露或未变化的校准配方是任何已报告排名中一个真实、尽管是次要的不确定性来源。

将这六项检查中的任何三四项应用于该领域的任何新论文,通常就能暴露本文详细讨论过的大部分可比性问题——这归根到底,正是 LowRankArena 本身想要传达的要点。

最后一个方法论提醒:这套协议可以进一步推广到 SVD 压缩之外

在结论之前值得明确说一点:这篇论文展示的标准化精神——固定预算定义、固定任务集、固定推理链路,将算法轴与辅助轴分开,然后让每个方法在相同条件下重新测量——完全不是 SVD 压缩的专属方法论。同样的配方可以,也可以说应该,应用到量化方法(“4-bit”在不同 group size 和异常值处理方式下含义不同)、推测式解码方法(“接受率”很大程度依赖于具体的 draft/target 模型搭配与解码温度),或 KV 缓存压缩方法(“压缩比”声明往往把驱逐策略变化与量化救杂在一块,类似于本文隔离出来的 SVD/混合精度混淆问题)。长期追踪量化、推测式解码、KV 缓存压缩重评三条线的读者应该把这篇论文的方法论当作一个模板,而不是一次性审计——本文对 SVD 压缩诊断出的协议碎化问题,很可能在那些邻近子领域里也大为存在,只是尚未得到充分审视。

术语辨析:“标准化”与”基准测试”的区别

值得精确地说明这到底是一种什么样的贡献,因为”benchmark paper(基准测试论文)“和”standardization platform(标准化平台)“这两个术语在 ML 系统会议中往往被混杂且交换地使用,但它们背后的认识论承诺其实不同。一篇纯基准测试论文的任务是回答”在任务 X 上谁能获胜”——它优化的是一个干净、决定性的排行榜。一篇标准化论文的任务,更接近 LowRankArena 实际在做的事,是回答”我们能信任这个排行榜真实地代表它声称的含义吗”——它的成功标准不是一个决定性的头名,而是一个可靠、可复现的测量协议,让其他研究者可以在其上建立工作,即便(如本文发生的那样)头条发现本身对其审计的领域而言不一定舌心。根据这个标准来衡量——不是”是否安了一个冠军”,而是”是否产出了其他人可以信任并扩展的协议”——LowRankArena 正是因为其主要实证结果(不存在稳定排名)在没有本文前面部分描述的标准化机制的支持下不可能达到,才能被评作成功。一篇追逐决定性胜者的基准测试论文本来有共同动机去抑制或弱化正是这种不稳定性发现;而标准化论文的激励机制则往相反的方向——寥于把它暴露出来。

关于超过 SVD 压缩本身的泛化提醒(结尾前的最后一点)

在结论之前,还有一点值得明确说出来:本文展示的标准化精神——固定预算定义、固定任务集、固定推理链路,将算法轴与辅助轴分开,然后让每个方法在相同条件下重新测量——完全不是 SVD 压缩的专属方法论。同样的配方可以,也应该,应用到量化方法(“4-bit”在不同 group size 与异常值处理方式下含义不同)、推测式解码方法(“接受率”很大程度依赖于具体的 draft/target 模型搭配与解码温度),或 KV 缓存压缩方法(“压缩比”声明往往把驱逐策略变化与量化救杂在一块,类似于本文隔离出来的 SVD/混合精度混淆问题)。长期追踪量化、推测式解码、KV 缓存压缩重评三条线的读者应该把这篇论文的方法论当作一个模板,而不是一次性审计——本文对 SVD 压缩诊断出的协议碎化问题,很可能在那些邻近子领域里也大为存在,只是尚未得到充分审视。对于同时在追踪量化、推测式解码、KV 缓存压缩系列的读者,这里可以将本文发现的一个具体方法推广:下次在那些领域里读到一个新方法的”头条数字”时,不妨问一问:它的 keep ratio/压缩比/接受率定义是否与先前的方法完全可比?它是否报告了与本方法黄金时期无关、但可能同样影响部署的头条数字(如解码主导工作负载下的端到端延迟)?这两个问题,就是本文自始至终在追问的东西。

对每个阶段预算的再展开:处理地站与磁盘/网络卸载的另一个维度

回到前面“可行性与成本”一节提到的 70B 失败模式,还有一个值得展开的机制细节:对于 ASVD、SVD-LLM这类需要校准前向传播的方法,前向传播本身的内存占用与校准序列数 $\times$ 序列长度成比例。对一个 70B 参数模型,即便只是对单一层权重做前向传播,激活张量本身的内存占用就可能远超过单张 GPU 的显存容量,这意味着前向传播本身需要层级卸载(layer offloading)——让当前未用到的层在 CPU 内存或磁盘上睡眠,需要时才把它们换入 GPU。这正是为什么论文发现 SVD-LLM v1 和 DoBi-SVD 在 70B 下撞上内存上限——它们发布的实现本来就没有层级卸载逻辑。而 MoDeGPT 失败在 Accelerate 的 GPU 卸载集成中,说明它确实尝试使用了卸载,但集成本身不兼容,这与完全没有卸载逻辑是两种完全不同的失败性质。

这个细节值得担忧的地方在于:对于 Charles 这个博客系列长期关注的 KV 缓存、分布式推理类方向,这里存在一个有趣的交叉点:SVD 压缩本身在“压缩阶段”遇到的内存瓶颈,与它在“推理阶段”遇到的内存带宽瓶颈,是完全不同的两个问题,却很容易在讨论中被混为一谈。前者是一次性的、发生在离线压缩时的工程问题;后者是持久性的、发生在在线推理时的系统问题。本文的 Q3(推理加速)发现针对的是后者,但 70B 审计发现的是前者——两个发现合在一起才能得出一个完整的结论:当前的 SVD 压缩方法生态不仅在大规模部署时需要重新工程化,在大规模压缩本身时也需要重新工程化。

对本博客同方向其他论文的回顾意义

既然这个博客系列已经单独审过了好几篇 SVD 压缩论文,就值得明确地说一下这篇论文应该如何回顾影响那些审计的阅读方式。这不是对任何单个方法贡献的否定——SigmaScale 的学习式缩放矩阵、AIR 的激活与影响感知加权、Swift-SVD 的最优性保证、GRASP 的自适应奇异参数,每个都是合理、有动机的技术思路,在其作者选定的范围内被诚实地评估过。LowRankArena 改变的,是我们对任何单一论文自报的对比表应该抱持多少信心,把它当作一个持久、跨上下文的排名,而不只是在某个骨干模型、预算、指标组合下有效的一张快照。以后读任何单一 SVD 压缩论文的”我们超过了之前 SOTA”主张时,首先把它看作关于该论文具体评测条件的主张,其次才是关于普适优越性的证据——这恰恰是 LowRankArena 自己方法论建议的那种训练有旰。

再补一个数值例子:精确理解 60% 保留比下的困惑度悬岰有有多极端

前面的 60% 保留比表格中,ASVD 在 C4 上的困惑度达到 14186.23,这个数字具体意味着什么?回到困惑度定义 $\text{PPL} = \exp\left(-\frac{1}{T}\sum_{t=1}^T \log p(x_t \mid x_{<t})\right)$ ,若困惑度为 14186,反推回去,模型对真实文本平均每个 token 只能分配大约 $1/14186 \approx 0.00007$ 的概率——而一个典型英文 tokenizer 的词表大小大约在 3–5 万,所以这个概率大体相当于模型在真实下一个 token 上的预测基本等同于在词表中随机猜——完全没有学到任何语言建模信号。这与 MoDeGPT 在同一预算下的 C4 困惑度 55.66(相比之下仍然能产生可识别、虽不完美的文本)形成了两个数量级的差异,而两者在 MCQ 均值上只差 0.351 vs. 0.504——并不是一个相应的量级差距。这个具体数字对比,比抽象地说“PPL 揭露了 MCQ 掩盖的能力悬岰”更能给人直观的冲击。

关于校准集规模的一个补充细节

前面提到每个方法保留自己原生校准配方(ASVD 32 条,MoDeGPT 128 条,其他 256 条 WikiText-2 序列,每条 2048 token)。这个差异本身就值得具体化理解:256 条 × 2048 token 意味着 SVD-LLM、DoBi-SVD、Basis Sharing 在校准阶段观察到的激活统计量,是 ASVD 的 16 倍(256/32)。若激活分布存在重尾(少数极端激活值对重构误差影响很大,这在激活感知 SVD 方法中常见),那么校准集越小,越容易遗漏低频但高影响的激活模式——这可能部分解释了为什么 ASVD 在某些骨干模型上表现不稳定(回忆前面 Table 1:ASVD 在 Llama-3.1-8B 60% 保留比下的 C4 PPL 高达 14186.23,在其他骨干上则稳定得多)。但论文本身没有直接验证这个假设——它没有将 ASVD 的校准集人为放大到 256 条重新测试,看看不稳定性是否会缓解。这属于本文第二个批判性分析要点中提到的、值得进一步挖掘的机制性问题。

对“为什么需要发布真实权重而不仅仅是代码”的补充说明

前面可复现性部分提到,LowRankArena 发布了超过 3 TiB 的实际压缩权重,而不仅仅是产生它们的代码。这个选择背后的实际价值值得具体化:对于第三方研究者,要独立重新实现本文 Table 1 中的一行数字,需要(1)获取每个方法原始代码,(2)自己重新运行校准/压缩流程(对一个 8B 模型、单张 A100,这个过程可能需要几小时到几天,取决于方法是否需要校准前向传播),(3)监控这个过程是否与原始论文实现完全一致——而任何一个环节出错(例如注意到前面提到 SVD-LLM 有 v1 和 v2 两个版本,两个版本在奇异值截断方式上不同)都可能导致得到与论文不一样的数字。而直接发布压缩后的权重让这个很容易出错的环节完全被绕开——第三方研究者可以直接加载已压缩好的 checkpoint,直接进入评测阶段,把可能引入新误差的重实现步骤完全省略。这对于本博客日后若需要对某个 SVD 方法的报告数字进行交叉验证,是一个值得优先考虑的资源。

再提一个具体场景:如果你是在写 SVD 压缩论文,这篇论文建议你怎么做

把前面所有分散讨论集中到一个实践清单上:如果你自己在开发一个新的 SVD 压缩方法,这篇论文隐含地建议了一个较高的发表标准:(1)在多个架构不同的骨干模型上报告结果,不要只在同一个模型家族内测试;(2)同时报告 MCQ 准确率和困惑度,并明确计算随机猜测下限,不要只报告对自己有利的那一项;(3)报告标准化、与精度无关的 keep ratio,并明确声明是否包含混合精度或重映射;(4)与同一参数预算下的结构化剪枝相比,而不仅仅与其他 SVD 方法相比;(5)报告至少一个 decode-heavy 工作负载下的端到端推理数字,不要只报告理论 FLOPs 减少或 prefill 阶段的加速。这五项中的任何一项缺失,都意味着读者无法完全信任你的报告数字具备普适性。

再补一段:为什么需要将这些发现放到多任务情境下重新检验

前面反复提到,本文的主评测集涵盖七个常见多选题任务、WikiText-2/C4 困惑度,以及数学推理相关任务(MathQA/MMLU-Math)。这套任务混合,本身就已经是一个具体选择,而不是唯一合理选择。对于不同的实际应用场景(代码生成、多轮对话、长文本摘要、工具调用智能体),任务组合可能完全不同,而本文发现的“排名不稳定”结论,很可能在不同任务组合下也呈现不同的具体形态(虽然定性结论很可能仍然成立)。这就是为什么前面“快速寄检清单”中第 6 项特别强调“对照自己的任务混合”——本文的一手数据应被理解为一个重要但不完全普适的参考点,而不是对任何下游应用均成立的最终结论。

附录笔记:术语交叉参考

对于对这个领域相对较新的读者,一份简短的术语对应表,将本文中使用的术语交叉引用到它们第一次出现的上下文,因为其中多个术语与论文自身的符号精确且可互换地使用:

Keep ratio( $r$ ): 压缩后保留的原始参数数量占比,在前面”标准化 Keep-Ratio 公式,逐项展开”一节中正式定义;等价地, $1-r$ 就是参数减少的比例。
秩比例: 单一层的 $k/\min(m,n)$ ——与聚合 keep ratio $r$ 不同、更细粒度的量;前面的实际数值例子展示了对同一个压缩后模型,这两个数可以相差很大。
TTFT(首 token 时间): 请求到达到产出第一个输出 token 之间的延迟;主要由 prefill 计算主导。
E2E(端到端)延迟: 一个请求从到达到最后一个输出 token 的全部延迟;即 prefill 时间加上完整解码序列的时间。
MCQ 均值: 在前置知识部分列出的七个多选题任务(BoolQ、ARC-Easy、ARC-Challenge、WinoGrande、PIQA、HellaSwag、OpenBookQA)上的宏平均零样本准确率(或归一化准确率 acc_norm,若可用)。
原生校准配方: 每个方法的原始作者指定作为默认的特定校准数据集与样本数(例如 ASVD 的 32 条 WikiText-2 序列 vs. SVD-LLM 的 256 条)——在 LowRankArena 的算法 1 步骤 B 中原样保留,而不是在方法间标准化,这是一个有意且已披露的折中。
统一精度制度: 本文的主要比较制度,压缩后权重与原始权重共享相同的数值位宽,从量化效应中隔离出低秩效应(参见 keep-ratio 公式的精度约束)。