[论文] ZipServ：快速且内存高效的 LLM 推理，具备硬件感知的无损压缩

发布: 2天前 (2026年3月18日 GMT+8 15:21)

7 分钟阅读

原文: arXiv

Source: arXiv - 2603.17435v1

概览

本文介绍了 ZipServ，一种无损压缩系统，使在 GPU 上部署大型语言模型（LLMs）既更小巧又更快速。通过重新设计压缩格式以及使用该格式的 GPU 核心，作者实现了最高 30 % 的模型体积缩减以及可观的推理加速——这是大多数先前的“位精确”压缩器无法做到的。

Tensor‑Core‑Aware Triple Bitmap Encoding (TCA‑TBE) – 一种固定长度、基于位图的表示，可在常数时间内解码，并能无缝映射到 NVIDIA Tensor Cores。
ZipGEMM kernel – 一个融合的“解压‑乘法”内核，可将压缩权重直接流入 Tensor‑Core 寄存器，消除中间缓冲区。
Hardware‑aware co‑design – 压缩格式与计算内核协同设计，保持 SIMT 并行性并避免额外的内存流量。
Empirical gains – 模型大小最高可降低 30 %，相较于 cuBLAS，内核层面加速 2.21×，在流行的 vLLM 服务栈上端到端推理加速 1.22×。
First lossless system – 首个在 GPU 上同时实现存储节省和推理加速的无损系统，针对大语言模型（LLM）。

编码设计 – 传统的熵编码器（例如 Huffman、算术编码）会产生可变长度的比特流，这会破坏 GPU warp 的同步执行模型。ZipServ 用 三位图 布局取而代之：三个并行位图分别对每个权重的符号位、指数位和尾数位进行固定大小块的编码。由于每个位图都是规则的、字对齐的数组，所有线程都可以独立读取各自的切片，从而保持 SIMT 执行。
Tensor‑Core 集成 – 这三个位图直接流入 Tensor Core 矩阵乘法单元。作者实现了自定义的 ZipGEMM 内核，其工作流程为：
- 从全局内存加载压缩的位图块。
- 在寄存器中即时解压（无需额外的全局内存写入）。
- 将得到的 FP16/FP32 数值送入 Tensor Core 的 GEMM 运算。
系统级融合 – 在典型的服务流水线中，模型权重首先被解压到稠密缓冲区，然后另一个 GEMM 内核读取该缓冲区。ZipServ 将这两个步骤合并，减半内存往返次数并降低缓存压力。
评估 – 作者在多款最先进的 LLM（如 LLaMA‑7B、LLaMA‑13B）上使用 NVIDIA A100 GPU 对 ZipServ 进行基准测试，并与以下方案进行比较：
- 未压缩基线（cuBLAS）。
- 现有的无损压缩器（例如 DeepCompress）。
- 用于端到端延迟的流行服务框架（vLLM）。

模型	压缩率	相对于 cuBLAS 的内核加速	相对于 vLLM 的端到端加速
LLaMA‑7B	小 28 %	1.9×	1.18×
LLaMA‑13B	小 30 %	2.21×	1.22×
GPT‑NeoX‑20B	小 26 %	1.7×	1.15×

成本效益的扩展 – 云服务提供商可以在相同的 GPU 集群上托管更大的大语言模型，降低硬件支出或实现更高的请求并发。
面向边缘的推理 – 内存需求的降低为在配备 NVIDIA Jetson 或类似 GPU 的高端边缘设备上部署 7‑13 B 参数模型打开了可能。
简化流水线 – 开发者可以用一次 ZipGEMM 调用取代“加载‑解压‑计算”序列，降低代码复杂度和潜在错误。
兼容性 – 由于 ZipServ 在 GEMM 层面工作，可通过自定义 CUDA kernel 包装器直接嵌入现有框架（如 PyTorch、TensorFlow），无需重新训练或微调模型。
面向未来 – 随着新一代 GPU 提供更大的 Tensor‑Core 矩阵（例如 Hopper 的 FP8 支持），基于位图的编码可以扩展以匹配原生数据格式，保持相同的加速效果。

硬件特定性 – 当前设计与 NVIDIA Tensor Cores 紧密耦合；移植到 AMD 或基于 CPU 的加速器需要采用不同的编码或内核策略。
压缩上限 – 由于是无损的，ZipServ 无法实现量化或剪枝那样显著的尺寸缩减；观察到的 30 % 节省是实际的上限。
内核复杂性 – 融合内核比标准 GEMM 更为复杂，可能增加维护负担并限制在高级库中的即时采用。
未来方向 作者提出的包括：将 TCA‑TBE 扩展以支持混合精度（例如 FP8/FP16）流水线，探索针对不同层的自适应位图粒度，并将该方法集成到多 GPU 模型并行框架中。