SALT 阅读笔记：子空间对齐质心-残差训练如何让超低秩 LoRA 服务成为可能

笔记日期： 2026-08-07 作者： Zhongzhu Zhou 阅读论文： Pin Once, Swap Light: Subspace-Aligned Centroid-Residual Training for Efficient Ultra-LoRA Serving 论文作者： Xiang Li, Pengcheng Wang, Huazheng Wang, Saurabh Bagchi（普渡大学、俄勒冈州立大学） arXiv： 2608.03579 状态： 预印本（cs.LG），2026 年 8 月

1. 为什么读这篇论文，它到底在解决什么问题

想象一个 LLM-as-a-Service 平台，在同一个共享基座模型上挂着几百个租户各自的 LoRA 适配器——给某家客户微调过的代码助手、给另一家做的数学辅导、给第三家做的法律文档摘要。每一个到来的请求都需要先把那个租户的适配器加载好才能跑前向。像 vLLM（配合 Punica 式批量异构适配器 kernel）这样的推理引擎，不可能把每个租户的权重都永久钉在显存里——几百个租户光是这一项就会把模型实际服务请求所需的 KV cache 挤没了。所以引擎选择热插拔：让一部分适配器常驻在”工作集”里，其余的等到真正需要时再走 PCIe 从主存搬进来。这正是 Amazon Bedrock 之类”LoRA 即服务”产品背后的真实运行模式。

论文开篇提出的张力,是一个真实存在、并非已经被解决的硬约束:适配器的秩 (rank)同时决定了每个租户获得多少任务特定容量,以及服务这个租户要付出多大代价。7B 模型上一个 rank-16 的 LoRA 适配器,每次被调用大概需要热插拔 13.6 MB——这是真实的 PCIe 带宽和真实的延迟,乘以并发轮转的租户数量。把 rank 降到 r=1 或 r=2 让热插拔变便宜,任务精度自然会下降,有时候还下降得很难看。论文自己的表格里记录了一个很不稳定的现象:标准 LoRA 在 MBPP 上,rank=8 时精度只有 3.00%,而 rank=4 时却有 25.50%——秩和下游精度之间根本没有单调、可预测的关系,这让服务商很难围绕”选哪个 rank”来规划容量。

前人对这个困境的应对分成两大阵营,论文对每一派为什么不适合真实多租户部署都说得很具体:

事后压缩(“Compress then Serve”,对多个已经训练好的适配器做联合对角化提取共享基)要求适配器已经以高 rank 的形态存在才能压缩它们——所以在 onboarding 阶段你照样要付出原始的服务成本——更糟的是,它需要同时访问每个租户的私有适配器权重才能算出共享基,这在多租户场景下是真实的数据隔离问题,而且每来一个新租户就要重算一次基,根本不具备可扩展性。

冻结的随机共享基(VeRA 及类似方法,冻结一个任务无关的随机投影,只训练很小的逐任务缩放向量)完全绕开了隔离问题——任何租户的数据都不会碰到另一个租户的训练过程——但代价是表达力:因为共享基没有任何语义结构,那一点点可训练的缩放向量要做极其繁重的补偿工作,论文自己的数字显示 VeRA 需要基维度达到上千(r=1024–4096)才有竞争力,而到那个规模,“共享”部分本身要永久钉在显存里的开销(110 MB)已经超过好几个 rank-16 LoRA 适配器加起来的总量。

,而是从结构上把问题拆开:把一个 LoRA 权重更新拆成——每个领域训练一次、在公开数据上训练、语义上主动对齐、高容量的质心(centroid,跨该领域所有租户共享并常驻显存),加上一个超低秩、逐租户的残差(r≤2,只捕捉这个租户私有数据特有的那一小部分偏移)。因为残差被锚定在一个已经编码了丰富领域结构的质心上,结果发现根本不需要多少残差容量,就能追回一个完全独立训练的 rank-16 适配器本该达到的大部分精度——而残差本身很小,恰恰是让热插拔变便宜的关键。核心实验结论:相比最强的先前压缩基线,绝对精度最多提升 18.5 个百分点;单适配器显存最多缩小 16 倍;接入 vLLM 之后,在 PCIe 带宽受限场景下吞吐最多提升 51%,在显存容量受限场景下最多提升 28%。

前置知识:开始之前需要了解什么

如果你已经熟悉 LoRA 的低秩参数化、多租户 LoRA 服务(Punica/S-LoRA 式的适配器热插拔)、以及”共享子空间”这个基本想法,可以直接跳到第 2 节。否则,这里是最低限度需要知道的背景。

一段话讲清楚 LoRA。 与直接微调完整权重矩阵 $W_{base} \in \mathbb{R}^{d\times d}$ 不同,LoRA 冻结 $W_{base}$,只学习一个低秩更新 $\Delta W = BA$,其中 $B \in \mathbb{R}^{d\times r}$、$A \in \mathbb{R}^{r\times d}$,且 $r \ll d$。前向计算变成 $h = (W_{base} + BA)x$。由于 $r$ 很小(常见取值 4–64,而 $d$ 往往是几千),可训练参数量很小——而对本文关键的是,一个适配器的存储成本和 $r$ 呈线性关系:rank 翻一倍,搬运时需要的字节数大致也翻一倍。

多租户 LoRA 服务,具体地说。 生产环境的 LLM-as-a-Service 平台不会为每个客户跑一个独立微调过的完整模型副本(如果基座权重相同,那样做浪费太大)。相反,它只保留一份共享基座模型常驻,再根据当前请求动态地把它和某个租户的 $\Delta W_i = B_iA_i$ 组合起来。Punica 之类的系统引入了定制的批处理 kernel(Segmented Gather Matrix-Vector,SGMV),让指向不同适配器的请求也能在同一块 GPU 上高效批处理。问题在于内存:几百个租户,而显存和 PCIe 带宽都是有限的,不可能让每个适配器都常驻,所以推理引擎需要随请求动态地把适配器权重从主机端搬到设备端(H2D swap)——而这个热插拔操作,在高并发、高请求率下反复发生,正是本文瞄准的真实瓶颈。这是和”计算受限的前向传播”完全不同的另一种瓶颈,它是一个受内存带宽限制的后勤调度问题。

Rank 是一个同时带着两种代价的旋钮,而不是一种。 很容易把 LoRA 的 rank 单纯理解成”容量”旋钮(rank 越高,表达力越强,精度越好),但在多租户服务场景下,rank 同时也直接是一个”成本”旋钮:每一单位 rank 就是 $2rd$ 字节(A、B 两个矩阵加起来,乘以对应的精度),这些字节必须要么常驻显存(和每个并发请求所需的 KV cache 抢地盘),要么走 PCIe 热插拔进来(和其他所有并发热插拔抢带宽)。正是这种双重角色,让本文把问题定位为从根本上解耦表达能力和物理内存开销,而不是简单地”找一个更好的 rank”。

共享子空间,通俗地说。 如果两个 LoRA 适配器完全独立地在两个不同但相关的任务上训练出来(比如都是小学数学应用题的 GSM8K 和 SVAMP),没有任何算法上的理由要求它们学到的权重更新 $\Delta W_1 = B_1A_1$ 和 $\Delta W_2 = B_2A_2$ 在权重空间里指向相似的方向,尽管这两个任务在语义上明显相关。这是一个真实存在、且相当容易被低估的经验事实,本文直接测量了它(图 5 左图):独立训练的、面向相关任务的适配器,其权重更新之间的余弦相似度接近零。“共享子空间”方法就是任何一种刻意强迫相关适配器落在一个共同的、低维几何区域里的技术,好让一个锚定在共享锚点上的小残差就能低成本地捕捉任务特定的变化——而不是让每个适配器都需要完整独立的容量,既要编码共享的领域知识,又要编码任务特定的增量。

再补一个日常直觉。 如果你在实际团队里参与过客户定制化 LLM 服务,很可能熟悉这样一个场景:团队给 A 客户微调了一个适用于内部知识库 QA 的 adapter,给 B 客户微调了一个代码审查助手,给 C 客户微调了一个合同摘要。这三个 adapter 在业务语义上完全互不相干,但它们共享同一个基座模型,并且很可能在同一块 GPU 上轮流被服务。这种场景下,三个 adapter 互相之间本来就没有任何共享领域结构可以利用(知识库 QA、代码审查、合同摘要三个领域彼此无关),所以 SALT 的领域划分前提(“服务商必须把任务划分到足够内聚的领域”)在这种场景下就自然成立了:真正能从共享质心中获益的,是同一个客户内部、比如多个不同部门都在微调同一类知识库 QA 的场景,而不是跨行业、跨任务类型的任意组合。

SALT 分三个先后进行的阶段运行,每个阶段有明确不同的执行主体(服务商还是租户)和明确不同的数据隐私边界。

flowchart TB
    subgraph P1["阶段一:服务商训练领域质心(只用公开数据)"]
        direction LR
        A1["公开数学语料<br/>(GSM8K, SVAMP)"] --> C1["联合训练:<br/>任务适配器 ΔW_i + 质心 W̄<br/>+ 对齐正则项"]
        A2["公开代码语料<br/>(MBPP, SPIDER)"] --> C2["联合训练:<br/>任务适配器 ΔW_i + 质心 W̄<br/>+ 对齐正则项"]
        C1 --> M1["数学质心 W̄_math (r=16)"]
        C2 --> M2["代码质心 W̄_code (r=16)"]
    end
    subgraph P2["阶段二:租户在私有数据上微调超低秩残差"]
        direction LR
        M1 -.冻结的锚点.-> R1["公司A残差 δ_A (r≤2)"]
        M2 -.冻结的锚点.-> R2["公司B残差 δ_B (r≤2)"]
        M2 -.冻结的锚点.-> R3["公司C残差 δ_C (r≤2)"]
    end
    subgraph P3["阶段三:多租户服务——钉住一次,轻量热插拔"]
        direction LR
        PIN["质心永久钉在显存里"] --- SW["每个请求只热插拔 δ_i<br/>(r=1时0.85MB, 对比r=16时13.6MB)"]
    end
    P1 --> P2 --> P3

图 2(论文 Fig.2)把数据隔离边界画得非常直观:左边”阶段一”框里的一切都只接触公开语料(Java/C++/Python 代码,公开数学题库);一旦私有的”公司 A/B/C 数据”出现(右侧,阶段二),它只会和已经冻结的质心组合,永远不会反馈回去继续训练质心本身。正是这个结构性机制,让 SALT 能够声称严格的多租户数据隔离——相比之前那些用租户数据持续更新共享组件、每来一个新租户就悄悄污染所有已有租户表征的共享子空间方法,这是一个真正的优势。

在深入公式之前值得先内化的直觉是:一个 rank-16 的”领域质心”只需要在显存里钉一次,它是共享基础设施,由所有该领域内的租户共同分摊——它的一次性训练成本和显存占用由服务商承担一次,而不是按租户计费。真正需要按请求走 PCIe 的,只有那个很小的残差,而由于残差锚定在一个已经承载了丰富语义结构的质心上(而不是从零开始或从一个随机投影开始),结果发现哪怕 rank 低到 1,也足以追回一个完全独立训练的 rank-16 适配器本该达到的大部分效果。

再插入一个直观的对比:低秩分解在不同 LLM 工程阶段都在被重新发明。 本博客先前覆盖过的 GaLore 用低秩投影来压缩训练时的梯度/优化器状态,目标是训练阶段的内存;LoRA 本身用低秩参数化来减少微调阶段的可训练参数量;而 SALT 把同样的低秩思想应用到部署/服务阶段,目标变成了内存带宽。三个工作面对的是 LLM 生命周期中完全不同的阶段,但底层都依赖同一个数学工具:将一个高维矩阵分解成一个低秩部分加一个小修正量。这个观察值得记下:低秩分解作为一种通用数学工具,在 LLM 工程的几乎每个阶段都在被重新发明,只是每次面向不同的约束条件(内存、带宽、隐私、可训练参数量)。

3. 质心-残差分解:逐步推导

3.1 为什么朴素地平均独立适配器不管用

获得”共享质心”最直观的做法,是在相关任务上分别训练若干独立的 LoRA 适配器,然后简单地平均它们的权重更新:$\bar{W} = \frac{1}{M}\sum_i \Delta W_i$。论文说明了这为什么行不通,而图 5(左图)是直接的实证证据:独立训练的适配器会收敛到不同、未对齐的局部极小值——即便 GSM8K 和 SVAMP 都是小学算术应用题,它们独立学到的 $\Delta W = BA$ 矩阵在网络的每一层都呈现出接近零的余弦相似度。对两个近似正交的向量做平均,并不会得到一个有意义的共享方向;它得到的更接近噪声互相抵消,恰恰破坏了你想保留的信号。

联合对角化(“Compress then Serve”)通过在训练之后从已经训练好的独立适配器中数学地提取共享基来绕开这个问题,而不是做平均。但这带来了第 1 节所述的数据隔离和动态扩展问题——每个租户已经独立训练好(因此已经涉及隐私敏感信息)的适配器都必须同时可见才能计算联合分解,而新租户加入就意味着要重算整个基。

SALT 的做法是跳过事后平均和事后联合分解,转而通过一个显式的优化目标,在训练过程中强制对齐——把质心和任务适配器联合训练,让质心从来都不是一个被动的平均值,而是一个被主动优化、任务适配器同时被拉向它的锚点。

3.2 阶段一:逐项拆解联合对齐目标

核心分解看起来出乎意料地简单:

$$\Delta W_i = \bar{W} + \delta_i \tag{结构分解式}$$

其中 $\bar{W}$ 是共享的、面向特定领域、任务无关的质心(高容量,例如 r=16,永久钉在显存里),$\delta_i = B_i'A_i'$ 是超低秩任务残差(r≤2,唯一按请求动态热插拔的部分)。这个分解本身并不是贡献所在——对于任何两个求和等于 $\Delta W_i$ 的矩阵,你都可以随意写出这样的分解。真正的贡献在于怎样训练 $\bar{W}$,才能让这个分解真正有意义:让 $\delta_i$ 真的可以很小而不破坏精度。

阶段一的联合训练目标,完全由云服务商在公开的、面向特定领域的数据上执行:

$$\min_{\{\Delta W_i\}, \bar{W}} \frac{1}{M}\sum_{i=1}^{M}\Big[ w_i\, \mathcal{L}_{task}(W_{base}+\Delta W_i; D_i) + \mathcal{L}_{task}(W_{base}+\bar{W}; D_i) + \lambda\, \mathcal{L}_{align}(W_{base}+\Delta W_i, \bar{W}) \Big] \tag{1}$$

逐项拆解一下,因为每一项在做不同的事:

• $w_i \, \mathcal{L}_{task}(W_{base}+\Delta W_i; D_i)$——第 $i$ 个单独的公开任务适配器在自己的数据集 $D_i$ 上(比如一个适配器用 GSM8K,另一个用 SVAMP,都属于数学领域)的标准任务损失。这一项单独拿出来,恰好就是独立训练 LoRA 会优化的东西。权重 $w_i \propto |D_i|$ 按每个任务相对数据集大小重新加权——没有这一项,一个数据集很小但训练中被循环更频繁的任务,可能会不成比例地主导梯度信号,超出它在整个领域中实际应有的重要性。

• $\mathcal{L}_{task}(W_{base}+\bar{W}; D_i)$——这一项是让 $\bar{W}$ 成为主动参与者而不是被动平均值的关键:质心本身,不加任何任务特定的适配器,直接被优化到在领域内每个任务的数据 $D_i$ 上都表现良好。这让质心本身就是一个真正称职的领域级模型——回想表 1 里的”LoRA(合并数据集)“那一行,本质上就是质心单独效果的一个代理指标,它已经能和独立训练的逐任务 LoRA 竞争(在若干数据集上甚至更好)。

• $\lambda\, \mathcal{L}_{align}(W_{base}+\Delta W_i, \bar{W})$——对齐正则项,是真正解决第 3.1 节”近乎零余弦相似度”问题的机制,它显式惩罚每个任务适配器的更新与质心之间的偏离。

对齐损失本身是一个 epsilon 稳定化的矩阵余弦相似度:

$$\mathcal{L}_{align}(\Delta W_i, \bar{W}) = 1 - \frac{\mathrm{Tr}(\Delta W_i^\top \bar{W})}{\|\Delta W_i\|_F \|\bar{W}\|_F + \epsilon} \tag{2}$$

推导与直觉。 $\mathrm{Tr}(\Delta W_i^\top \bar{W})$ 是两个权重更新矩阵之间的 Frobenius 内积——把每个矩阵当作一个拉直后的向量,这恰好就是它们之间普通的点积。除以两个 Frobenius 范数的乘积 $\|\Delta W_i\|_F \|\bar{W}\|_F$,把结果归一化到 $[-1, 1]$ 之间,和普通向量的余弦相似度完全类似,只是通过矩阵的 Frobenius 内积结构来实现。当两个矩阵方向完全一致(允许正的缩放)时,比值为 1,$\mathcal{L}_{align} = 0$——没有惩罚。当它们正交时,比值为 0,损失为 1——最大惩罚。当它们方向相反时,损失可以达到 2。分母里的 $\epsilon = 10^{-8}$ 纯粹是为了数值稳定性:在初始化时,$\bar{W} \approx 0$(一个刚初始化的 LoRA 式质心通常在或接近零,因为 $B$ 一般被零初始化),没有稳定项的话原始比值会是 $0/0$。

为什么专门选余弦相似度,而不是比如 $L_2$ 距离惩罚 $\|\Delta W_i - \bar{W}\|_F^2$? 这正是那种论文没有明说、但值得展开推敲的设计选择。$L_2$ 惩罚会强迫 $\Delta W_i$ 在数值上接近 $\bar{W}$,不仅方向要接近,大小也要接近——但 $\bar{W}$ 是一个高容量(r=16)矩阵,而 $\Delta W_i$ 作为一个只用于对齐信号的单独公开任务适配器(不是最终的残差),并不需要匹配 $\bar{W}$ 的规模,只需要匹配它的几何方向,因为服务时真正被组合进来的是一个锚定在质心上的、远小得多的残差,而不是 $\Delta W_i$ 本身。余弦相似度天然地对尺度不变——它只关心方向——这正是这个训练时正则项需要的属性:把每个任务独立优化出来的方向拉向质心的方向,而不必和任务损失争夺大小,因为大小的事任务损失已经在处理了。尺度不变性的明显风险:两个适配器可能达到完美的余弦对齐,却拥有天差地别的大小,而对齐损失单独看不提供任何阻止这种情况的信号——但由于 $\mathcal{L}_{task}$ 在同一目标里和 $\mathcal{L}_{align}$ 一起被联合最小化,大小仍然会被隐式约束在真正有助于任务损失的范围内。

3.3 阶段二:为什么把秩限制在 r≤2 是一个特性,不只是妥协

一旦 $\bar{W}$ 被固定(阶段一之后冻结),阶段二会针对某个具体租户的私有数据进行适配,但只优化残差:

$$\min_{\delta_i} \mathcal{L}_{task}(W_{base} + \bar{W} + \delta_i; D^{(i)}_{private}) \tag{3}$$

注意这里被冻结的部分:$W_{base}$(预训练模型)和 $\bar{W}$(质心)在这个优化问题里都是固定常量;只有 $\delta_i = B_i'A_i'$(且 $r \le 2$)拥有可训练参数。正是这个机制在结构上保证了隐私隔离:私有数据在字面意义上无法影响 $\bar{W}$,因为 $\bar{W}$ 在阶段二的优化变量里根本不存在——它是阶段一就固定下来、之后再也不会被触碰的东西。

论文在这里提出了一个值得认真对待、而不是当作脚注一笔带过的论点:把残差限制在 r≤2 不仅仅是”我们能凑合用的最小容量”——它被论证为一种结构性的正则器本身。因为残差确实缺乏独立建模目标任务分布所需的参数容量(对一个 $d\times d$ 矩阵做 rank-2 更新,而 $d$ 通常是几千,这是一个极小的子空间),它被迫依赖预先对齐好的质心作为结构性捷径,而不是试图从零重新发明领域知识。这是一个真实、可检验的因果性论断,下文第 5.4 节讨论的表 6 就是论文给出的证据:在一个子空间对齐的质心上训练残差,大幅优于在一个朴素拼接数据训练出的质心上训练的、容量完全相同的低秩残差——尽管两个质心看到的总数据量是一样的,唯一的区别是质心在训练时的方向是否被主动对齐到各个独立的任务适配器上。如果残差的微小容量本身就足以解释一切(而与质心质量无关),这个差距就不该存在。

3.4 阶段三:服务时的组合方式,以及推理时缩放系数 γ

服务时,某个租户 $i$ 的请求最终使用的权重矩阵是:

$$W_{final} = W_{base} + \gamma \bar{W} + \delta_i \tag{4}$$

残差 $\delta_i$ 以全强度(隐含系数 1)接入,但质心被系数 $\gamma$ 缩放。质心在阶段一已经被直接优化过了,为什么还要在推理时引入一个缩放旋钮? 论文的解释借鉴了已有的任务算术(task arithmetic)思想:在推理时组合多个学到的组件(这里是基座权重+质心+残差)可能引入干扰,而这种干扰在每个组件被单独训练/评估时是看不到的。$\gamma < 1$ 削弱质心的贡献(当干扰正在损害某个特定任务时有用),$\gamma > 1$ 则放大它。表 4 的实测扫描确认了这不只是理论上的担忧:下游精度在 $\gamma \in [0.4, 1.2]$ 范围内呈现清晰的倒 U 型,在 $\gamma = 0.6$–$0.8$ 附近达到峰值,两端都明显退化(GSM8K 从 $\gamma=0.8$ 时的峰值 58.65% 一路降到 $\gamma=1.2$ 时的 48.83%)——所以这个缩放系数确实在做真实的纠偏工作,不是一个多余的超参数。

为什么把 $\gamma$ 离散成少数几个预定义的档位(例如 $\{0.6, 0.8, 1.0\}$),而不是让每个请求都用连续的值? 这是一个有清晰道理的推理引擎工程决策:如果每个请求都能连续变化 $\gamma$,就意味着每一个请求都可能需要一份自己新组装的 $(W_{base} + \gamma\bar{W})$ 矩阵,这会彻底违背钉住共享质心的初衷——你又回到了逐请求权重组合的开销。通过离散化成档位,服务前端可以按分配到的 $(\bar{W}, \gamma)$ 对来给请求分组,对于高频档位,服务商甚至可以在节点启动时把缩放后的质心直接融合进基座权重——之后,这个节点只需要热插拔那些微小的逐租户残差。表 4 的发现——$\gamma \in \{0.6, 0.8, 1.0\}$ 在精度上都紧密聚在一起(数学任务相比峰值平均只掉 3.23%,代码任务只掉 1.53%)——正是让这种离散化变得实用而不是有损近似的关键:服务商不需要费力搜索精确的最优 $\gamma$,因为精度曲面在一个可用的范围内确实很平坦。附录里更细的 $\gamma$ 扫描(论文图 11,此处未复现)标出的一个例外情况值得一提:AQuA(一个选择题式的数学数据集,和以直接生成为主的数学任务在结构上不同)需要更高的 $\gamma \approx 1.3$ 才能完全恢复,这也预示了第 7 节讨论的结构性偏差局限。

对于那些不值得为融合而付出开销的稀有低频请求,论文指出,缩放后的质心和残差可以简单地离线拼接成一个标准适配器(比如一个有效 rank=17 的矩阵)——让服务引擎回退到普通的异构批处理来处理长尾请求,不需要单独的代码路径。

用真实数字把这一切串起来。 拿论文表 1 里 Mistral-7B-v0.3 上的具体数字做一次手算,会比只看倍数更有说服力。假设一个服务商同时服务 100 个数学领域的租户:如果每个租户都用独立的 rank=16 Standard LoRA,每次请求的热插拔开销是 $100 \times 13.61\text{ MB} = 1361\text{ MB}$——这已经超过很多消费级 GPU 单卡显存的量级,而这只是一批100 个租户轮转所需要搬运的数据量,不是常驻占用。换成 SALT 的方案:质心只需要常驻一次(13.63 MB,不随租户数增长),而 100 个租户各自的 r=1 残差热插拔总量是 $100 \times 0.85\text{ MB} = 85\text{ MB}$——同样是 100 个租户轮转一遍,总搬运字节数从 1361 MB 降到 85 MB,大约 16 倍,和论文报的倍数完全吻合。这个手算例子的价值在于让字节数的简化对比变得具体、可验证:16 倍不是一个抽象的营销数字,它对应的是服务商真正需要预算、采购的 PCIe 带宽和显存容量就能少绞绞十几倍。而且这个优势会随着租户数量线性放大:假设租户数从 100 增到 1000,Standard LoRA 的热插拔总量会线性增长到 13.61 GB,而 SALT 因为质心常驻一次的成本不随租户数变化,只有残差部分线性增长到 850 MB——差距随规模扩大而变大,这正是论文强调“集群规模越大,SALT 的相对收益越明显”的根本原因。

4. 自动质心路由:算法与推导

一个实用的多租户系统不能假设每个到来的租户都会主动告诉你他们的数据属于哪个领域质心——更糟的是,如果数据根本不干净地属于任何已有质心(真正的分布外数据,OOD),强行把它塞进错误的质心只会主动损害精度而不是帮忙。SALT 的答案是一个两阶段的激活剖析算法,只需要租户阶段二数据的一小份无标签样本就能运行。

4.1 逐步走一遍算法

准备工作,在阶段一结束后离线完成一次。 对于质心库 $\mathcal{C} = \{\bar{W}_1, \ldots, \bar{W}_K\}$ 中的每个质心 $\bar{W}_k$,服务商把该质心自己的领域内验证集喂给模型,记录一个位移范数统计量(下面定义)的经验均值 $\mu_{N,k}$ 和标准差 $\sigma_{N,k}$——本质上是在校准”对于这个质心来说,典型的、领域内的激活行为是什么样”。

第一步——计算新数据的位移范数。 给定新租户的一小份无标签样本 $D$(论文使用 $|D_{profile}| = 100$ 个样本),对每个候选质心 $k$,把这个质心接上去运行模型并计算:

$$N_k = \|h_k - h_{base}\|_2 \tag{5}$$

其中 $h_k$ 是接上质心 $\bar{W}_k$ 后的最终隐藏状态,$h_{base}$ 是不加任何适配器时的隐藏状态。这衡量的是这个质心对这份特定数据实际造成了多大的表征扰动——经过按 token 归一化以控制”更长的序列无论领域相关性如何都会积累更多原始位移”这个混杂因素。直觉是:如果租户的数据确实带有数学味道,接上数学质心应该会相对于未修改的基座模型明显移动隐藏状态,因为质心学到的方向确实被激活了;不相关的数据不应该在任何特定质心的方向上产生大幅移动。

第二步——通过偏差做 OOD 拒绝。 计算与每个质心的校准基线之间的标准化偏差:

$$Z_{N,k} = \frac{|N_k - \mu_{N,k}|}{\sigma_{N,k}} \tag{6}$$

这是一个标准的 z 分数:新数据观测到的位移,离”该质心典型的领域内位移”有多少个标准差。如果在库中所有质心上取最小的偏差仍然超过一个严格阈值($\min_k Z_{N,k} > \tau_N$,例如 $\tau_N = 2.0$,大致对应 95% 置信区间),数据就被标记为和库中任何质心都没有几何重叠——它是 OOD,系统回退到为这个租户训练一个标准的、不锚定的 LoRA 适配器,而不是硬把一个不合适的质心塞给它。

第三步——在领域内候选中做专家路由。 如果 OOD 检查通过(某个质心大致相关),还需要第二轮、更具区分度的比较,因为原始位移范数 $N_k$ 本身就会因为提示结构或词汇复杂度而波动,和真正的领域对齐程度无关。论文计算了一个主导比率:

$$R_k = \frac{N_k}{\frac{1}{K-1}\sum_{j\ne k} N_j}, \qquad k^* = \arg\min_k \frac{|R_k - \mu_{R,k}|}{\sigma_{R,k}} \tag{7}$$

为什么要用相对于其他所有质心平均值的比率,而不是直接取 $\arg\max_k N_k$? 这正是值得推敲的设计选择。如果某个租户的数据恰好在每一个质心上都产生了均匀偏大的位移(可能只是因为文本更长或更复杂,和真正的领域契合度无关),直接 $\arg\max$ 仍然会自信地选出某个质心,即便这个质心其实并不比其他质心更契合。比率 $R_k$ 把每个质心的位移相对于所有其他质心引起的平均位移做归一化,恰好抵消了这种因长度/复杂度导致的、对每个质心大致均匀影响的膨胀——归一化之后剩下的更接近一种相对领域契合度的度量,而这正是路由真正需要的东西。

4.2 完整算法的伪代码

算法 1:自动质心路由
输入:无标签租户样本 D,质心库 C = {W̄_1, ..., W̄_K},
     每个 k 预先校准好的 (μ_N,k, σ_N,k, μ_R,k, σ_R,k),
     阈值 τ_N, τ_R(例如都取 2.0)
输出:选中的质心索引 k*,或 FALLBACK(标准 LoRA)

 1: for k = 1 到 K do
 2:     把 W̄_k 接上模型,在样本 D 上运行
 3:     h_k ← 最终隐藏状态(按 token 归一化)
 4:     h_base ← 不接任何适配器时的最终隐藏状态
 5:     N_k ← ‖h_k − h_base‖_2                     // 式 5
 6: end for
 7: Z_N_min ← min_k |N_k − μ_N,k| / σ_N,k           // 式 6,最佳匹配的 OOD 偏差
 8: if Z_N_min > τ_N then
 9:     return FALLBACK                              // OOD:没有质心足够契合
10: end if
11: for k = 1 到 K do
12:     R_k ← N_k / ( (1/(K−1)) · Σ_{j≠k} N_j )      // 式 7,主导比率
13:     Z_R,k ← |R_k − μ_R,k| / σ_R,k
14: end for
15: k* ← argmin_k Z_R,k
16: if Z_R,k* > τ_R then
17:     return FALLBACK                              // 模糊/混合领域
18: end if
19: return k*                                        // 路由到 W̄_k* 进行阶段二

用真实数字跑一遍路由公式。 拿表 3 里 AQuA 的行为例子把式 6—7 实地计算一下,会比单纯看结果表更能理解这个阈值机制在实际运行。假设数学质心的校准基线是 $\mu_{N,\text{math}}=1.0,\sigma_{N,\text{math}}=0.3$,代码质心是 $\mu_{N,\text{code}}=1.0,\sigma_{N,\text{code}}=0.3$(这些具体校准值未在论文中给出,这里取合理典型值仅为说明计算过程)。对 AQuA,论文报告 $Z_N = 1.32$,明显小于 $\tau_N=2.0$,所以通过 OOD 检测,进入专家路由阶段。接着看式 7 的主导比率:表 3 报告 AQuA 对数学质心的 $Z_R=0.94$,对代码质心的 $Z_R=2.75$——数学侧的偏差远低于代码侧,且 $0.94 < \tau_R=2.0$,所以系统正确地选择数学质心作为锈点。这个手算过程直接展示了第一阶段拒筶和第二阶段路由如何相互配合:先判定“是否值得信任任何质心”,再在可信的候选中比较“到底跟哪个更合适”。而 xnli/german 和 xnli/spanish 两个 OOD 样本,它们的 $Z_N$ 分别是 2.28 和 2.32,均超过 $\tau_N=2.0$——尽管它们对数学/代码两个质心的主导比率 $Z_R$ 均在 1.65—2.19 之间,看似不是很极端,但系统并不会走到第二步去比较这些 $Z_R$,因为它们在第一步就已经被拒筶了——这正是两阶段设计的意义:即使某个 OOD 样本在某个质心上的相对匹配度看上去不错,第一阶段的绝对位移检测已经拦下了它,不会让它流入下游错误路由。

表 3 在六个留出数据集上对这个算法的验证,清楚展示了预期的行为:AQuA 和 MultiArith(都是数学,都在阶段一训练中被留出,所以这真正测试的是泛化,不是记忆)正确路由到数学质心,$Z_R$ 分别是 0.94 和 0.11 且都很低;CodeSearchNet 和 APPs 正确路由到代码质心($Z_R$ = 0.49 和 0.39);而——更重要的负例控制——两份 XNLI 语言分类数据(德语、西班牙语)和数学、代码都没有真正的关系,两者都正确触发了 OOD 回退,$Z_N$ = 2.28 和 2.32,都明显超过 $\tau_N = 2.0$ 的阈值。正确拒绝真正不相关的数据,而不只是正确接受相关数据,是这个验证里更难、也更有信息量的那一半。

5. 值得推敲的设计选择:为什么这样做、替代方案是什么、边界在哪

为什么把对齐惩罚和任务损失联合训练在一个统一目标里(式 1),而不是分两阶段——先正常训练独立适配器,再事后投影到共享基上? 显而易见的替代方案(独立训练适配器到收敛,再事后对齐,更接近”Compress then Serve”的精神)能让每个阶段单独优化得更简单。论文的设计隐含地拒绝了这种方案,因为事后投影只能在独立训练出来的适配器已经收敛到的几何结构基础上,找到最好的共享子空间——而第 3.1 节”近乎零余弦相似度”的发现表明,这个几何结构本身基本上是任意的/未对齐的,所以事后投影是在从下游残差组合的视角看接近噪声的东西里寻找结构。联合训练则从优化过程中就主动塑造适配器收敛的位置,用对齐梯度从一开始就把它们引向一个共同方向,而不是接受梯度下降碰巧找到的方向再事后修正。这种联合方式可能失败的地方:它把质心的优化轨迹和每一个独立任务适配器的轨迹同时耦合在一起(附录表 13 的训练成本分析显示,这在联合训练的适配器数量 $M$ 上呈 $O(M)$ 的内存和单步延迟增长),所以引入一个真正的新领域,仍然需要对该领域所有公开任务做一次完整的联合重训练——比按租户重训练要便宜,但绝不是免费的,这是服务商能维护和刷新多少个领域的一个真实实际约束。

为什么把残差秩上限固定在 r≤2,而不是把秩暴露成一个可调的逐租户旋钮? 一个可调的逐租户 rank 理论上能让愿意为更多热插拔带宽付费的租户获得更高的保真度——听起来更灵活。论文的隐含答案就藏在服务效率论证本身里:整个吞吐提升(见下文第 6.4 节)来自统一地微小的热插拔负载,让所有并发租户同时获得更大的连续批处理规模、更少的 PCIe 冲突;如果有些租户用 r=8 或 r=16 的残差而其他用 r=1,服务引擎又要回到处理异构、不可预测的热插拔大小分布,这会破坏内存占用降低本来想换取的调度可预测性。r≤2 的上限,与其说是精度-成本的权衡,更多是一个服务引擎的设计约束。它失效的地方:第 6 节(局限性)记录了当某个任务需要的输出格式和该领域普遍需要的格式明显不同时——例如选择题式评测(AQuA)出现在一个以直接生成为主的数学领域里——会被实际损害,因为 r≤2 的残差被迫依赖一个主要为直接生成优化的质心,根本没有足够容量去覆盖这个结构性偏差,而这个任务恰好需要偏离它。

为什么用一个由多个领域专属质心组成的分级库(数学、代码……),而不是一个覆盖一切的单一通用质心? 附录 A.3 的多领域干扰实验(表 12,这里没有做成图,但值得直接说出来)给出了实证答案:把单个质心的训练数据从 2 个任务扩展到 6 个任务(把数学和不相关的代码、语言任务混在一起)会单调地损害原有领域内任务的下游精度——GSM8K 从 46.65% 掉到 43.92%,SVAMP 从 74.17% 掉到 70.0%,随着更多异构数据被折叠进来。这直接排除了”用一个万能质心搞定一切”这种诱人的简化方案:把语义上不相关的领域塞进一个共享基里会造成负迁移,和朴素的单一全局模型面临的失败模式一样,只是把问题从基座模型转移到了质心里。论文的方案要求服务商提前把任务划分成”足够内聚的领域”,而这本身就是论文没有提供自动化解法的真实设计负担——领域划分被留给人工/启发式步骤,不是 SALT 算法帮你决定的事。

为什么阶段二的残差是针对未缩放的质心优化的(式 3 里没有 $\gamma$),而 $\gamma$ 只在服务时才被引入(式 4)? 这是一个微妙但有真实后果的顺序选择。如果 $\gamma$ 在阶段二训练时就被固化,残差会学会补偿一种特定的质心缩放,那么服务时对 $\gamma$ 的任何事后调整(比如服务商决定不同档位能更好地平衡当前一批并发租户之间的多任务干扰)都会悄悄破坏这个租户的残差,因为它从没被训练过要和 $\gamma \ne 1$ 配合工作。通过让残差针对未缩放的质心训练,只把 $\gamma$ 引入为一个服务时的组合参数,服务商保留了系统级、按领域重新调整 $\gamma$ 的自由,而不会让任何已经训练好的租户残差失效。代价是:表 4 显示这种解耦并不是完全没有成本的——性能确实明显依赖于 $\gamma$,所以服务商仍然需要合理地选择(经验上 $\gamma \in [0.6, 0.9]$),只是当这个选择变化时,残差不需要重新训练。

为什么 OOD 拒筶(第二步)和专家路由(第三步)要分开两个独立的 z 分数阈值,而不是合并成一个单一的判定? 这两个阶段在概念上回答的是两个不同的问题:第一阶段问的是“这份数据是否和任何组件有几何重叠”,第二阶段问的是“在确定确实有重叠的前提下,哪个组件是相对最合适的”。如果合并成单一判定,就会遇到这样一个尴尾情况:一份真正属于数学领域、但措辞或提示结构比较奇怪的数据,可能对所有质心都产生偏大的位移,单一阈值很难同时处理“是否OOD”和“到底近哪个”两个问题。把它们拆开,让第一阶段彻底专注在“有没有任何一个足够近”这个二元问题上,而第二阶段只在已经确认“至少有一个足够近”的前提下才启动,误判空间就被收窄了一层。这种分层设计的边界在于:两个阶段都假设了同样的高斯分布结构(参见第 8 节的批判分析),如果真实分布偏离高斯很远,分层设计本身并不能修复这个问题,只是把同一个不准确的假设重复了两次。

在进入具体实验结果之前,先把前面四个设计选择用一张表汇总一下,作为后面阅读结果的快查参考:

设计选择	选择了什么	显而易见的替代方案	什么情况下会失效
对齐损失度量	矩阵余弦相似度(式 2)	$L_2$ 距离惩罚	需要同时强制大小一致时,会与任务损失产生不必要的剥夺性竞争
残差容量上限	r≤2	可调节的逐租户秩	统一小载荷才能保持调度可预测性;异构秩混合就丢失这个优势
领域划分粒度	领域专属质心库	单一通用质心	异质领域混入一个质心会因负迁移而掌对内精度
γ 的优化时机	服务时引入,阶段二不受影响	阶段二就引入 γ	重训相对安全,但失去阶段二就已知服务时最优 γ 的自由度

6. 结果复现与解读

6.1 Mistral-7B-v0.3 上的主要精度与内存对比

图 1(论文 Fig.1)把论文的核心论断浓缩到两个面板里。左图:在 GSM8K 上,SALT 的 r_res=1 残差(56.9%)超过了包括满秩 rank-16 Standard LoRA(53.9%)在内的所有基线——这确实是一个反直觉、值得停下来想一想的结果,毕竟 SALT 在每个租户身上用的可训练容量更少,却打败了用更多容量的对手。在 MBPP 上,排序是 SALT(69.2%)> Standard LoRA(66.2%)> VeRA(65.4%)> CTS(62.1%)——SALT 赢了,但相对最强基线的优势比 GSM8K 上窄一些。右图则把这一切翻译成真正决定服务成本的指标:每次热插拔的字节数。Standard LoRA 在 r=16 时每次热插拔要 13.61 MB;SALT 的 r=1 残差只要 0.85 MB——16.0 倍缩减——而 CTS(5.24 MB,比 Standard LoRA 小 6.2 倍,但仍比 SALT 大 6 倍)和 VeRA(0.52 MB,甚至比 SALT 还小,但别忘了 VeRA 需要那 110 MB 的巨大基础常驻显存才能做到这一点)补全了对比。只有把两个面板放在一起读,才能看出全貌:SALT 在同时做到匹配或超过精度以及接近所有真实(非退化)竞争对手中最小的单请求热插拔成本。

论文表 1 的完整数字值得直接过一遍,因为汇总的故事掩盖了一些真实的细节纹理:

方法	秩	常驻(MB)	热插拔(MB)	GSM8K‡	SVAMP‡	MBPP‡	SPIDER‡
Standard LoRA	r=16	0.00	13.61	53.88	66.25	26.75	21.34
VeRA	r=4096	109.05	1.05	40.79	60.83	26.50	31.53
CTS(JD-Full)	r=16	8.38	5.24	49.02	62.08	9.25	3.47
SALT(r=1)	r=1	13.63	0.85	56.88(+7.2)	69.17(+5.8)	27.25(+11.5)	56.59(+26.3)

(‡ 代表阶段一质心训练和阶段二残差微调都用了这些数据集——这是”领域内已见”设置;论文也报告了”领域内未见”和”零样本迁移”两种设置,下文会讨论。)

SPIDER 这一列是整张表里最戏剧化的一个数字:CTS 在 r=16 时精度崩到 3.47%(对文本转 SQL 任务基本失效),而 SALT 在 r=1 时达到 56.59%——53 个百分点的差距。这不是某个基线调得不好造成的巧合;附录 A.5(表 14,下文第 6.4 节讨论)显示,这个模式之所以成立,恰恰是因为 SPIDER 对质心是否子空间对齐还是朴素拼接特别敏感,论文还记录了一个具体、明确的失败案例(Listing 1),精确解释了原因。

再看一下 Llama-3.2-3B 和 Pythia-12B 上的对应数字,确认这不是 Mistral 专属现象。 论文表 8(Llama-3.2-3B)上,SALT 在 r=1 时 SPIDER 达到 46.04%,而 CTS 在同样 r=1 时只有 48.08%、在 r=16 时却下滑到 34.29%——CTS 的不稳定性在不同架构上反复出现;表 9(Pythia-12B)上差距更大,SALT 在 r=1 时 SPIDER 达到 42.20%,CTS 在任何测试 rank 下都没超过 0.24%。这种跨架构一致的差距说明 SPIDER 的失败不是某个特定模型或架构的偶发现象,而是 CTS 联合对角化自身对未对齐基底的结构性敏感度。

超越已见任务的泛化能力。 论文有意把评测分成难度递增的三种设置:领域内已见(残差在质心训练用过的同一批数据集上微调)、领域内未见(残差在同领域的留出数据集上微调——MultiArith、AQuA、APPs)、零样本迁移(一个在 MBPP 上训练的残差,不做任何额外训练,直接在 HumanEval 上评测)。MultiArith 的数字是真正泛化(而非过拟合具体训练分布)最有说服力的证据:SALT 在 r=16 时达到 86.21%,而 Standard LoRA 只有 30.35%——在一个从未在 SALT 训练的任何阶段出现过的数据集上,差距达到 +55.86 个百分点。这强烈说明质心真正捕捉到的是可迁移的领域结构(泛泛的小学算术推理模式),而不是记住了 GSM8K/SVAMP 具体训练集的答案。

6.2 跨架构的一致性

图 3(论文 Fig.3)检验了 Mistral-7B 上的结果是否能推广到不同模型家族和规模——Mistral-7B-v0.3、Pythia-12B、Llama-3.2-3B,三个真正不同的架构(不同的注意力配置、不同的预训练语料、参数量跨越一个量级)。恢复率(SALT 精度占满秩 rank-16 Standard LoRA 精度的比例)在三者上都保持在 80–95% 区间,秩缩减倍数从 9x 到 11.5x 不等。有一处值得诚实地指出:Llama-3.2-3B 呈现出三者中最低的恢复率(约 80%)搭配三者中最高的秩缩减倍数(约 11.5x)——这是一个真实的权衡点,不是一个单方面压倒性的结果,说明在测试到的最小模型规模上,压到最极致的压缩确实要比更大规模的模型多付出一点精度代价。这和 LLM 压缩研究里一个更普遍、直觉上说得通的模式是一致的:更小的模型通常有更少的冗余容量可以牺牲,压缩的代价来得更早。

6.3 服务效率:热插拔开销、延迟与端到端 vLLM 吞吐

图 4(论文 Fig.4)左图提供了这个领域大多数论文没有一起给出的、真正有用的双轴视角:x 轴是热插拔开销,y 轴是前向传播延迟。SALT 落在左下角——热插拔开销最小同时前向传播延迟最低,而 VeRA 尽管报告的热插拔开销也很小,但要付出更高的前向传播延迟(它那个巨大的冻结随机基,即便不需要热插拔,推理时仍然要参与矩阵乘法)。右图分解了两个真正影响热插拔密集型服务的延迟组成部分:CPU→GPU 的 PCIe 热插拔(真正昂贵的那部分,Standard LoRA 在 r=16 时是 0.25ms)对比 GPU→GPU 的显存内复制(不管方法如何都很便宜,都在 0.02ms 以下)。SALT 的 PCIe 热插拔延迟(0.02ms)基本处于 VeRA/CTS 的地板水平,比 Standard LoRA 的 0.25ms 低一个量级——这是 16 倍内存缩减直接转化为真实时钟时间节省的实证结果,作用在真正昂贵的资源上,而不只是理论上的字节数改进。

端到端 vLLM 集成的数字(论文表 2)证实了这些微基准的增益能在真实服务栈里存活下来:在 N=512 并发适配器、PCIe 带宽受限的场景下,vLLM+SALT 达到 54.46 req/s,对比原生 vLLM 的 43.42 req/s(+25.4%);在相同并发下的显存容量受限场景,38.41 对 32.59 req/s(+17.9%)。值得注意的是,这些增益完全没有依赖任何定制 kernel——SALT 完全依赖标准的加法矩阵运算($W_{base} + \gamma\bar{W} + \delta_i$ 只是普通的矩阵加法),这正是它能直接接入 vLLM 现有的基于 SGMV 的适配器服务流水线的原因,而论文明确指出 VeRA 和 CTS 由于其特殊的矩阵结构需要非标准的服务流水线,因此在这个端到端对比中被排除——如果只看精度-内存的对比,这种真实世界的可部署性优势完全会被忽略。

6.4 对齐惩罚真的在几何上对齐适配器吗?

图 5(论文 Fig.5)是整个方法背后直接的机制性验证——它回答的问题是”对齐损失(式 2)真的做到了它该做的事,在几何上吗,还是精度提升来自别的地方?”左图:“Standard(独立)“曲线(完全没有对齐惩罚训练出的适配器,相当于 $\lambda=0$)在每一层上基本都停在零余弦相似度附近——这是第 3.1 节论断的直接可视化确认。随着 $\lambda$ 从 0.5 增加到 2.0,曲线单调且大幅攀升,在 $\lambda=2.0$ 时大多数层达到 0.7–0.9 以上的相似度。右图从另一个角度展示了同样的效果:单个适配器与质心本身(不是相互之间)的相似度,对 GSM8K 稳定攀升到 0.9 以上,对 SVAMP 呈现稍微更嘈杂但仍明显偏高的模式,确认了任务适配器和质心确实一起收敛到了一个共同的几何邻域,而不只是两个任务适配器碰巧相互对齐、却同时漂离了质心。

6.5 对齐惩罚敏感度扫描,以及为什么适度的 λ 就够了

图 6(论文 Fig.6)把 $\lambda$ 从 0.5 扫描到 2.5,同时绘出几何效果(面板 a:余弦相似度从 0.806 攀升到 0.942,基本饱和)和下游效果(面板 b:GSM8K 和 SVAMP 在质心+残差组合下的任务精度)。这里真正有信息量的发现是没有发生的事:尽管对齐惩罚显著变强(从 0.5 到 2.5 几乎翻了三倍),下游精度在整个扫描范围内基本保持平坦。这是一个真实、相当令人安心的负面结果:意味着对齐约束并没有以牺牲任务质量来换取几何整洁,至少在这里测试的领域和任务集合内,可以相当用力地推动对齐而不用付出精度代价。这也意味着 $\lambda$ 的具体取值不是一个需要每个领域小心调优的脆弱超参数;测试范围中间的适度取值就是一个安全的默认选择。

在继续讨论局限性前,先把表 5(叢行与代码路由)里面的一个细节补充完整。 前面式 4 定义的 OOD 拒筶阈值 $\tau_N=2.0$,对应于标准正态分布下 95% 的双侧置信区间。但这里有一个值得终止思考的细微地方:论文实际上只用了单侧(取绝对值 $|N_k-\mu_{N,k}|$)而不是严格的双侧检验,因为位移范数异常地小(而不是异常地大)其实也很可能意味着该质心对这份数据几乎没有任何调用,而这本身也应该被视为领域不契合的一种表现形式。取绝对值的做法把这两种“异常”统一处理了,但论文没有讨论过这两种情况在实践中是否真正可互换。

7. 局限性:论文说了的和没说的

论文对若干局限性说得很直接,第 6 节的内容值得原原本本地体会,而不是一笔带过。首先是对正交任务格式的结构性偏差:因为阶段一的对齐强制在一个领域内的各任务之间形成严格的几何交集,一个自然输出格式和该领域主流格式明显不同的任务——论文自己给的例子是选择题式评测(AQuA)出现在一个以直接生成为主的数学领域里——会受损,因为 r≤2 残差的微小容量不足以覆盖质心学到的、偏向主流格式的偏差。表 1 具体展示了这一点:AQuA 是整个 Mistral-7B 对比里唯一一个 SALT 在匹配或更低秩上落后于 Standard LoRA 的数据集(r=2 时 31.37% 对 34.80%,差 -5.3 个百分点)。

其次,评测严格限定在两个领域(数学和代码)。这是一个真实的、需要坦率承认的范围局限:论文自己的多领域干扰实验(附录 A.3 表 12,前面第 5 节讨论过)展示了不谨慎混合领域会造成负迁移,这意味着论文的核心正面结果只在作者已经知道内部内聚的领域内得到验证——它没有告诉你,对于一个真正全新的、有几十个异构垂直行业租户的部署,该如何发现内聚的领域边界,而这正是真实 LLMaaS 服务商会面对的情况。

第三,作者自己明确标记为未来待解决的开放问题:扩展 SALT 到 Mixture-of-Experts 架构仍未解决。论文自己的推理是合理的,值得复述一遍:MoE 稀疏、互不相交的专家路由路径,使得在专家之间建立统一的几何子空间在数学上变得复杂,而且不额外增加内存成本地做到这一点更难——单一共享质心的概念不能显然地迁移到一个不同 token 路由到完全不同专家子网络的场景,论文没有给出任何部分方案,甚至连一个草图都没有。

论文没有讨论、但值得单独指出的一点:质心路由的离线校准成本(第 4 节)要求服务商在路由能工作之前,已经收集好每个质心的领域内验证统计量($\mu_{N,k}, \sigma_{N,k}, \mu_{R,k}, \sigma_{R,k}$)——这是每个质心的一次性成本,但这意味着往库里添加一个新质心,不只是”训练它”(阶段一)那么简单,还需要跑这个校准流程,而论文完全没有讨论校准本身需要多少数据或算力,也没有讨论路由准确率对这些基线统计量校准质量的敏感程度。

在进入批判性分析之前,值得先把前面幾节的技术论点串起来徒一遍。 SALT 的整个设计可以看作一个三层结构:最底层是一个逆向推导出来的几何事实(第 3.1 节,训练时独立的 adapter 方向几乎互相正交)——没有这个事实,一切都没有必要。中间层是一个显式的训练时机制(式 1—2,余弦对齐正则化项)——把绝对方向强行拉到一块去。最上层是一个服务时机制(式 4,γ 缩放+档位离散化)——把训练时对齐好的几何结构,变换成实际可部署的工程优化。三层重叠在一起,才能得到 16 倍内存压缩这个最终数字——单拿其中任何一层都不够。这个分层结构在后面的批判性分析里会反复出现,因为很多局限性都是因为某一层的假设在某种情况下不成立而冒出来的。

8. 批判性分析

这篇论文特有的缺陷。 首先,路由算法的 OOD/专家路由阈值($\tau_N = 2.0$、$\tau_R = 2.0$)被呈现为固定、通用的默认值,并配上”95% 置信区间”这样的说法,但这个说法隐含地假设了底层的位移范数和主导比率统计量近似服从高斯分布、围绕它们的校准均值分布——论文从未真正测试过这个假设。如果某个质心的 $N_k$ 或 $R_k$ 真实分布明显偏斜或重尾(这是合理的可能性,因为它们来自复杂非线性模型激活,不是原始数据),“2 个标准差”的截断就并不真正对应真实的 95% 置信区间,而路由算法的误接受/误拒绝率可能存在系统性的错误校准,论文六个数据集的验证(表 3)样本量太小,不足以检测出这种问题。其次,表 1 里对 VeRA 的精度对比使用了最高到 r=4096 的 VeRA 配置才达到”有竞争力”——但按论文自己的说法(“VeRA 需要较大的基,因为只学习对角缩放向量”),在低端做对比(比如 VeRA 最小测试配置 r=1024,仍然要常驻 27.26 MB)相对 SALT 常驻 13.63 MB 的质心,并不是真正公平的等量内存对比——VeRA 自己最小的可行配置就已经比 SALT 的质心大约 2 倍,论文没有测试更小的 VeRA 配置(r < 1024)在不同调优下是否可行,留下一个悬而未决的问题:报告的 VeRA 数字是否代表了 VeRA 真正的最小内存运行点,还是仅仅是作者恰好测试到的最小配置。

作者低估或省略的局限性。 论文反复把 r≤2 残差约束描述为纯粹的容量-成本设计选择,但低估了这个约束和服务商必须手动做出的领域粒度选择之间的交互程度——AQuA 的失败案例(表 1)被呈现为一个孤立的例子,但其背后的机制(残差容量不足以覆盖结构上分歧的任务的质心偏差)是一般性的,论文没有刻画这种失败模式在比测试的八个数据集更广泛的任务分布上有多常见或多可预测——从论文提供的信息来看,一个真正部署这个方法的服务商,在实际尝试之前根本没有原则性的方法预先判断哪些新租户任务会撞上这个失败模式。其次,论文自己的训练成本扩展性分析(附录 A.4 表 13)显示阶段一成本在联合训练的任务适配器数量 $M$ 上呈 $O(M)$ 增长,并报告在单块 H100 上扩展到 M=50 个适配器”仍然舒适”——但一个真实的领域(比如宽泛意义上的”代码”)合理地需要吸纳远超过 50 个不同的公开任务数据集,才能真正代表生产平台需要服务的代码任务多样性,而论文没有外推或讨论 $M$ 增长到几百这个更现实的成熟领域场景下,阶段一训练成本或质心质量会发生什么变化。

具体、可执行的改进建议。 (1)直接检验路由阈值背后的高斯近似假设——在比表 3 测试的六个数据集更大、更多样的留出数据集上,报告 $N_k$ 和 $R_k$ 的真实经验分布形状,如果分布明显非高斯,用不依赖正态性假设的非参数方法(例如经验百分位截断)替换固定的 z 分数阈值。(2)专门做一个消融实验,验证在阶段二被标记为 r≤2 服务效果不佳的任务上,能否用稍高的残差秩(例如 r=3 或 r=4,仍远低于 r=16)来缓解 AQuA 式的结构格式失败——这能澄清失败究竟是根本性地源于 r≤2 上限,还是源于对齐惩罚的强度,因为目前论文的设计里这两者是纠缠在一起的。(3)在 $M$ 达到几百的规模上(而不仅仅到 50)报告阶段一训练成本和下游质心质量,因为这才是成熟生产领域的现实规模,目前 $O(M)$ 扩展性论断中”舒适”的说法只在比一个成熟部署可能需要的规模低一个量级左右的规模上得到过验证。(4)把目前只在一小组精心挑选的任务组合上做的多领域干扰研究(仅测试了 2/4/6 个任务的混合)扩展成检验一个分级质心结构(例如一个宽泛的”STEM”质心,数学和代码作为其下的子质心)能否在保留比完全独立领域更多共享结构的同时,恢复一部分过宽领域造成的负迁移代价——这能直接回应第 7 节标记为未解决的领域划分负担问题。

9. 可复现性说明

论文以合理但并非最大限度的详尽程度记录了实验设置:精确的优化器设置(AdamW,权重衰减 0.01,余弦衰减调度,3% 线性预热,梯度裁剪到范数 1.0),精确的数据集划分和大小(附录 A.1 表 7,精确到全部八个数据集的训练/验证/测试样本数),以及编码任务的精确提示模板(论文图 7 和图 8,已原样复现)。三个基座模型家族(Llama-3.2-3B、Mistral-7B-v0.3、Pythia-12B)都是公开可用的权重,所有评测数据集(GSM8K、SVAMP、MultiArith、AQuA、MBPP、SPIDER、APPs、HumanEval,以及用于 OOD 路由测试的 XNLI)都是标准的、公开发布的基准,有良好文档化的评测协议,这实实在在地降低了不公平或难以复现的基线对比风险。截至本篇笔记撰写时唯一开放的可复现性缺口是:论文没有说明是否会开源代码,预印本中也没有链接任何代码仓库——所以尽管算法描述本身(式 1–7,以及上文重构出的算法 1)足够精确,可以直接重新实现核心方法,但基线的具体超参数选择(VeRA 具体的秩扫描方法、CTS 联合对角化的实现细节)需要独立地从被引用的先前工作中重新推导,而不能直接沿用本文自己的代码。

再用一个具体场景把第 6.3 节的服务效率数字串起来。 论文表 2 报告 N=512 并发适配器、PCIe 带宽受限时,vLLM+SALT 达到 54.46 req/s,而原生 vLLM 只有 43.42 req/s。把这个数字换算成实际运营含义:假设一个服务集群每小时需要处理 15万次请求(大致对应 43 req/s 的量级),那么在相同的 GPU 数量下,SALT 能多处理约 25% 的请求量,或等价地,处理同样请求量只需要少绞绞 4/5 的 GPU 数量——这直接转化为硬件采购成本的节省。显存容量受限场景下(38.41 对 32.59 req/s,+17.9%)的改善幅度略小于 PCIe 场景,论文对这个差异的解释是:显存容量受限时,瞬时批处理大小受到 KV cache 和适配器内存共享的两重约束,SALT 虽然把适配器占用缩小了 16 倍,但这个优势在比例上不能完全直接传递到批处理规模上,因为 KV cache 本身的占用不随适配器大小变化。

10. 在更广阔的低秩适应版图中的位置

如果你一直在关注本博客对低秩和 PEFT 方法的报道,值得把 SALT 直接放到已经覆盖过的几条脉络里对照。LoRA 本身(这整条工作线所建立在其上的基础低秩分解)把秩纯粹当作一个容量旋钮,没有内建任何服务效率机制。PiSSA 及相关的 SVD 初始化方法,在初始化时直接从基座模型自身的权重中通过 SVD 提取结构——这和 SALT 的质心(从任务数据中学到的)是一种根本不同的结构来源(内在于预训练权重)。VeRA,本文全篇作为 SALT 的直接对比对象反复讨论,代表了隔离性-表达力谱系上的另一个极端:通过冻结随机基实现完美的租户隔离,代价是需要巨大的基维度才有竞争力。HydraLoRA(一个共享的 $A$ 矩阵配合多个通过 mixture-of-experts 路由的任务特定 $B$ 矩阵)和 LoraHub(推理时动态组合独立适配器)都在追求共享组件的思路,但两者都没有像 SALT 式 2 那样,在训练时引入一个显式的几何对齐目标——它们通过架构约束(一个共享矩阵,或事后组合)来共享结构,而不是主动训练独立初始化的组件朝一个共同方向靠拢。SALT 相对这些方法最鲜明的差异在于两点结合:(a)在联合训练过程中使用一个显式的、可微分的对齐损失,而不是架构上的共享约束或事后基提取;(b)从方法设计之初就把服务效率论证直接嵌入其中(统一微小的残差大小、γ 档位离散化以便融合、与 vLLM 标准 kernel 的兼容性),而不是在一个以精度为先的方法上事后补一个效率论证。对于今天真正要搭建多租户 LoRA 服务平台的实践者来说,论文自己的数字表明,当租户可以被划分到数量适中的、内部内聚的领域,且每个租户的微调数据是私有的时——这恰恰是绝大多数已经在做客户特定微调的 LLMaaS 平台已经身处的情形——SALT 是目前能拿到的最强选项之一。

对部署方的实际建议。 如果你是一个真实在评估能否采用 SALT 的 LLMaaS 工程团队,论文自己的数据暗示了一个粗略的决策流程:先检查你的租户集合是否真正能被划分成少数几个内部内聚的领域(参考附录 A.3 的负迁移实验作为反例);如果答案是“是”,再检查每个租户的任务输出格式是否与领域主流格式一致(参考 AQuA 的反例);如果两个条件都满足,那么 SALT 相对 VeRA 和 CTS 的优势应该能完整体现。如果任何一个条件不满足,本笔记第 8 节的批判分析列出的具体失败模式就是你应该预期会遇到的。

11. 结论

SALT 的核心赌注是:“更高秩换更好精度”与”更低秩换更便宜服务”之间那种惯常的权衡框架本身就选错了坐标轴,因为它把两件真正可以分开的事情混为一谈:一个适配器需要编码多少领域知识,以及它需要捕捉多少租户特定的偏离领域的部分。通过为每个领域训练一次高容量、主动几何对齐的质心(一次性付费,由所有租户共同分摊,且从不被私有数据触碰),再让每个租户的残差小到 r=1(因为它只需要捕捉租户特定的增量,不需要承载整个领域),SALT 追回了一个完全独立的 rank-16 适配器本该达到的大部分甚至全部效果,同时把真正决定多租户服务吞吐的单请求热插拔成本压低最多 16 倍。让这一切成立的机制端到端都有充分的理据:一个 epsilon 稳定化的余弦对齐损失,解决了一个真实、可测量的几何发散问题(图 5 里近乎为零的基线相似度);一个基于 z 分数的两阶段路由算法,能在不需要标签的情况下正确区分领域内数据和分布外租户数据;一个离散化的 γ 缩放机制,让服务时的组合能兼容标准的批处理 kernel 推理引擎,而不需要定制基础设施。诚实的警示——对格式偏离领域主流模式的任务存在结构性偏差、评测范围局限在两个精心挑选的内聚领域、扩展到 Mixture-of-Experts 架构尚未解决、以及路由算法置信阈值背后未经检验的假设——并不会削弱这项工作的核心贡献,但在假设论文报告的 16 倍内存缩减和 51% 吞吐提升能不加改变地迁移到一个有几十个异构垂直行业租户、而不是这里测试的两个干净领域的部署之前,这些恰恰是最应该仔细审视的地方。