[Paper] LLM-CoOpt：面向异构平台的高效 LLM 推理协同设计与优化框架

发布: 3天前 (2026年2月10日 GMT+8 09:31)

7 分钟阅读

原文: arXiv

Source: arXiv - 2602.09323v1

Overview

LLM‑CoOpt 是一个全新的协同设计框架，旨在解决大型语言模型（LLM）推理过程中长期存在的三个痛点：内存带宽瓶颈、冗余计算以及处理超长输入序列的困难。通过对算法和硬件友好型数据通路的共同重新设计，作者展示了在不牺牲模型质量的前提下，推理速度可以更快、内存使用更高效。

缓存重新设计 (Opt‑KV)
- KV 缓存用于存储自回归生成的中间激活，传统上保持在 FP16/32。LLM‑CoOpt 将这些张量压缩到 FP8，使每个 token 所需的内存带宽减半。
- 自定义写回缓冲区和预取逻辑重新排序缓存访问，以提升空间局部性，减少 CPU/GPU 上的缓存未命中停顿。
分组查询注意力 (Opt‑GQA)
- 与每个头部独立的 query/key/value 投影不同，Opt‑GQA 将多个头部分组，共享相同的 key/value 矩阵，同时保留各自的 query 矩阵。
- 这将矩阵乘法的数量从 H（头数）降低到 G（组数），并实现相同 key/value 数据在多个头部之间的更好复用，尤其在 SIMD 友好硬件上受益显著。
分页注意力 (Opt‑Pa)
- 将长序列首先划分为固定大小的页面（例如 512 token）。
- 在生成过程中，仅对与当前注意力窗口相交的页面进行实例化（“惰性映射”），其余页面保持在压缩存储中。
- 该方法利用操作系统级的页面错误处理和自定义内核，将活跃工作集保持在较小规模。
集成与评估
- 将上述三项优化组合成单一推理流水线。
- 实验在服务器级 GPU（NVIDIA A100）和仅 CPU 基线上运行，使用 LLaMa‑13B‑GPTQ 检查点。
- 在标准语言模型基准（如 WikiText‑103、LAMBADA）上测量准确性，以确保量化和算法改动不会降低性能。

指标	基线	LLM‑CoOpt（组合）	Δ
吞吐量（tokens / s）	1.00×	1.13×	+13.4 %
端到端延迟（ms / token）	1.00×	0.83×	–16.8 %
KV‑缓存内存占用	100 %	≈50 % (FP8)	–50 %
准确率（困惑度 / LAMBADA）	基线	与基线相差不超过 0.2 %	无明显下降

数据表明，每项单独的优化都对整体提升有贡献，但最大幅度的提升来源于降低内存流量（Opt‑KV）和减少 FLOPs（Opt‑GQA）的组合。Opt‑Pa 在输入长度超过 4 k tokens 时表现尤为突出，此时基线的内存使用会急剧增长。

更快的 SaaS API – 云服务提供商可以在每个 GPU 上处理更多请求，降低聊天机器人或代码助手等服务的每 token 成本。
边缘与设备端推理 – FP8 缓存和降低的计算量使得在高端移动或嵌入式 GPU 上运行 13 B 规模模型成为可能，即使内存带宽受限。
长上下文应用 – 检索增强生成、文档摘要和代码分析等常常需要 >8 k token 窗口；Opt‑Pa 使这些工作负载无需采用昂贵的模型拆分技巧。
简化部署 – 由于优化实现为即插即用的内核替换（例如通过自定义 CUDA 内核或 ONNX Runtime 扩展），现有推理堆栈可以以最少的代码更改采用 LLM‑CoOpt。

硬件特定性 – 当前实现针对 NVIDIA GPU 和 x86 CPU 进行调优；在 AMD GPU 或基于 ARM 的加速器上的性能尚未测试。
量化敏感性 – 虽然 FP8 在 LLaMa‑13B‑GPTQ 上表现良好，但其他模型系列（例如密集训练或指令微调的变体）可能需要逐层校准，以避免精度下降。
可扩展至 >100 B – 作者指出，对于参数超过 100 B 的模型，需要额外的层次结构（例如多节点 KV 缓存）来支撑。
未来方向 – 扩展 Opt‑Pa 以支持动态页大小、集成稀疏感知注意力内核，以及通过编译器层面的优化实现协同设计过程自动化，被视为有前景的下一步工作。