TensorDex：以 Tensor 为单位压缩模型仓库（SOSP 2026）
原题：TensorDex: A Compact, Tensor-Centric Storage System for Modern AI Models
一句话总结：模型仓库中的微调模型存在大量跨模型冗余，但“整模型选一个参考模型”会错过不同 tensor 各自最相似的来源。TensorDex 用位级指纹预测可压缩性、增量聚类选参考 tensor，再做无损差分压缩；在 2890 个模型的样本上减少 70.5% 存储，占用比 ZipLLM 再低约 37%（摘要、§6）。
问题与动机
模型仓库中全量微调权重和 checkpoint 的数量增长很快。差分压缩可以只保存相对某个基础权重的变化，但公开模型卡的谱系信息常缺失或不准确，同一模型的不同 tensor 也可能分别更像不同参考模型（§1–§2、图 4–5）。只按模型级谱系配对，会把可压缩的 tensor 对漏掉。
这里的主要问题是仓库存储与模型装载 I/O，不是训练计算本身。压缩率、摄取吞吐、解压吞吐和随机读取延迟必须一起看，不能只报告节约的 TB 数。
关键观察 / 隐含假设
- 冗余发生在 tensor 粒度：模型内不同 tensor 的最佳参考对象可能不同；依赖模型卡谱系会错配（§2–§3、图 5）。这要求 tensor 能按名称、形状和 dtype 合法配对，也意味着架构差异很大的仓库可能没有足够候选。
- 浮点值近不等于压缩后残差小：差分编码处理的是原始位模式；两个 tensor 数值距离接近，也可能因符号位、指数位和尾数变化而产生难压缩残差。因此普通数值向量指纹不能直接拿来选参考（§4.2、图 9）。
- 模型以流式顺序进入仓库：不能每来一个模型就对全库做二次组合搜索。TensorDex 用增量聚类限制候选数（§4–§5）。
- 高压缩率与吞吐存在取舍：TensorDex-TX 侧重编码解码速度，TensorDex-FM++ 侧重最小存储；这两种配置不能用一个数字评价（§6.1–§6.2）。
核心方法
系统先拆出 tensor 并用 TensorID 做精确去重，再为每个唯一 tensor 计算 8 KB 位级 TensorSketch。指纹把每个元素的每个 bit 位置分别哈希到带符号桶，以指纹差值估计原始位模式的 Hamming 距离，而不是把浮点值简单平均（§4.2、图 9、算法 1）。对评测的 741689 个唯一 tensor，指纹总量约 6.08 GB，只占去重后 40.11 TB 的约 0.015%（§6.1、表 2）。
TensorPred 接着把位差距离与二元熵一起放进离线拟合的回归式，预测某个 tensor 相对候选参考 tensor 的存储节约比例，无需真的对候选逐个压缩（§4.3）。这个近似解决的是选哪个参考的排序问题；它不是无损压缩器本身，预测偏差可能改变最终规划。
FlexSplit 分两步规划：新 tensor 先在已有参考集合中选预测收益最高的中心；定期检查簇中“被当前中心压得不好”的成员，若提升其中一个为新中心能让整个簇净省更多字节，就局部拆簇、重分配成员。新参考本身要完整存储，因而拆簇只在净收益为正时发生（§4.4、图 10）。这避免了全局 ILP 对每次模型上传重算。一个模型的 tensor 可选来自不同模型的参考；最终再调用无损差分编码后端存储。
TensorDex-TX 与 TensorDex-FM++ 共用规划器，换用不同压缩后端，分别展示吞吐和容量方向的选择。参考 tensor 以完整数据保存，差分 tensor 依赖其参考和残差，读取时要先取参考；这种细粒度布局也使引用生命周期与冷启动随机读取成为运维议题（§5–§6）。它与 Strata-OSDI26 的 KV cache 分层不同，处理的是权重仓库的长期冗余。
设计取舍
- 细粒度参考换元数据与依赖管理：每个 tensor 单独选基准可以提高压缩率，但仓库必须维护可达性、引用计数和删除顺序。
- 更强压缩换吞吐：FM++ 减少更多字节；TX 提高摄取和解压速度。模型冷启动路径需要按读取频率选策略。
- 无损压缩保住权重精度：相比量化不会改变数值，但跨模型引用使恢复链条更复杂。
实验与结果
- 评测按创建时间增量摄取 2890 个 Hugging Face 模型，覆盖 Qwen、Llama、Mistral、Gemma 家族；样本来自这些微调家族，不能视为整个模型仓库的随机代表（§6.1、表 1）。
- 数据去重先将 44.86 TB 原始 tensor 缩到 40.11 TB；70.5% 的压缩率以这个去重后容量为分母。TensorDex-FM++ 减少 70.5%，TensorDex-TX 减少 65.1%，ZipLLM 为 53.4%（§6.2.1、图 11）。
- 吞吐优先版本达到 22.9 GB/s 压缩与 28.4 GB/s 解压，分别是次优系统的 3.86 倍与 1.49 倍；这不是 FM++ 压缩率配置的吞吐（摘要、§6.2、表 3）。
- 规划器消融：保持编码后端一致时，ZipLLM 的 53.4% 到 TensorDex-TX 的 65.1% 是选参考规划收益；保持同一规划，只换更强的 FM++ 编码器才从 65.1% 到 70.5%。因此不能把 17.1 个百分点差距都归给 TensorSketch/FlexSplit（§6.2.1）。
- 搜索与求解代价：TensorSketch 在所测 Qwen/Llama/Gemma 家族上 Recall@1 为 1.00、查询超过 25000 QPS；精确位距离每 tensor 查询 I/O 约 35 MB，指纹约 8 KB。800 个 tensor 的 ILP 求解超过 70 秒，FlexSplit 近乎常量时间且压缩率距最优仅数个百分点（§6.3–§6.4、图 12、图 14）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| tensor 级规划比模型级配对节省更多空间 | TX 65.1%，ZipLLM 53.4%（§6.2.1、图 11） | 2890 个所选微调模型 | 强（该样本） |
| 更强编码器进一步降低容量 | FM++ 70.5%，TX 65.1%（§6.2.1） | 相同规划器，不同压缩后端 | 强（该样本） |
| 快速路径保有高吞吐 | 压缩 22.9 GB/s、解压 28.4 GB/s（§6.2、表 3） | 测试硬件和数据分布 | 中到强 |
| 指纹足以近似筛选参考 | Recall@1=1.00，>25000 QPS（§6.3、图 12） | 所测 Qwen/Llama/Gemma tensor 家族 | 中到强 |
批判性分析
论证链条
图 5 的参考选取敏感性支持 tensor 粒度规划，固定压缩后端再比较 ZipLLM 与 TX 有助于隔离规划器收益。70.5% 的 headline 包含 FM++ 后端的效果，不能全部归因于 FlexSplit。
假设压力测试
若仓库主要是架构完全不同、几乎无共同初始化的模型，TensorSketch 难找到高收益候选。若大量模型被频繁删除或重写，参考对象的生命周期管理可能抵消容量收益。量化和 LoRA 可以作为 tensor 集合进入流程，但 dtype 兼容与实际存储收益需单独确认。
实验可信度
论文披露去重前后分母，并分别固定规划器与编码器做消融，能够区分两种收益来源。Recall@1=1.00 也是所测家族的结果，不能等同于对任意新架构的保证。数据集是从代表性微调家族挑出的 2890 个模型，外推到多模态、非同源架构和频繁删除的仓库时需要重新测量。
系统性缺陷
跨模型差分引入引用依赖；用户删除基础模型时，仓库必须重写被依赖的差分或延迟物理删除。隐私和租户边界也可能限制跨用户模型之间的内容共享，论文未把这些约束作为主要评测维度。
局限与后续工作
- 测量模型删除、覆盖与跨租户隔离条件下的空间放大和重写流量。
- 把远程对象存储延迟、并发冷启动和压缩布局合在同一评测中，报告 P99 加载时间。
相关
- 同会议：SOSP-2026；相邻系统：SANDHI-SOSP26 压缩共置模型显存，TensorHub-SOSP26 分发训练权重。
- 全文：公开预印本。