全网整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:4009-999-999

米乐体育APP官网微软打破 Decoder-Only 架构:大幅降低 GPU 内存需求

  ,可大幅降低 GPU 内存需求,且保留全局注意力能力。一张图来看 YOCO 和标准 Transformer 的比较。

  那么这个新出的 Decoder-Decoder 架构到底长啥样?嗯,如网友所言,要读的论文又增加了。

  具体来说,YOCO 由 L 个块堆叠而成,其中前 L / 2 层是自解码器,其余模块是交叉解码器。

  接收输入序列的嵌入表示,并使用高效自注意力来生成中间向量表示;使用因果掩码(causal masking)保证解码的自回归特性;自解码器的输出用于生成全局 KV 缓存。

  而交叉解码器使用交叉注意力(cross-attention)来重用自解码器生成的共享 KV 缓存:

  在自解码器生成的 KV 缓存基础上进行堆叠,以获得最终的输出向量;同样使用因果掩码来维持自回归生成;允许交叉解码器层间高效地重用 KV 缓存,减少了对 GPU 内存的需求。

  总的来说,自解码器和交叉解码器的模块设计与 Transformer 的解码器层类似,包含交错注意力和前馈网络子层。不过,研究人员还进行了预 RMSNorm、SwiGLU 和分组查询注意力等改进。

  而交叉解码器使用标准的多头交叉注意力,Query 向量通过注意力与自解码器产生的全局键值缓存相关联。

  实验阶段,研究人员将 YOCO 模型与同体量的 Transformer 模型进行比较。

  分析维度有四个:语言建模评估、与 Transformer 比较的可扩展性、长上下文评估、推理优势。

  研究人员训练了一个 3B 参数的 YOCO 语言模型,并根据训练 token 数量(1T 和 1.6T)进行评估。

  接着,研究人员在 160M 到 13B 参数规模范围内,分别训练了 YOCO(门控保留和滑动窗口注意力版本)和 Transformer 语言模型。

  对比了它们在验证集上的语言模型损失,YOCO 的表现与 Transformer 基本持平:

  此外,YOCO 模型在长序列上的 NLL 随着上下文长度的增加而一致下降,表明 YOCO 能够有效地利用长距离依赖信息进行语言建模:

  综上,可见 YOCO 在性能上完全不输 Transformer,关键来看 YOCO 在推理效率上取得的显著提升。

  研究人员评估了 YOCO 在 GPU 内存占用、prefilling 延迟、吞吐量和服务容量等方面的优势,评估上下文范围为 32K 至 1M。

  如下图所示,与 Transformer 相比,YOCO 大幅度降低了 GPU 内存占用,且 YOCO 的内存消耗随上下文长度增加,增长幅度很小。

  YOCO 模型只缓存一层全局的键值对,因此与 Transformer 模型相比,它需要的内存约少了 L(指模型的层数)倍。

  在预填充阶段,模型并行编码输入 token。对于 512K 和 1M 长度的输入,Transformer 分别需要大约 180 秒和 300 秒。Transformer 的计算复杂度为 O (N^2),处理长上下文需要大量的浮点运算操作。

  预填充阶段可以在进入交叉解码器之前提前退出。因此,即使对于短上下文,预填充延迟的加速至少是两倍。例如,对于 32K 长度,YOCO 比 Transformer 快 2.87 倍。

  吞吐量表示模型每秒可以处理多少个 token,涵盖了预填充和生成时间。如下图所示,与 Transformer 相比,YOCO 在不同上下文长度下实现了更高的吞吐量。

  吞吐量提高的原因如前所述,YOCO 减少了预填充所需的时间。其次,由于内存消耗减少,因此可以在推理时使用更大的批量大小,这也有助于提高吞吐量。

  广告声明:文内含有的对外跳转链接(包括不限于超链接、二维码、口令等形式),用于传递更多信息,节省甄选时间,结果仅供参考,IT之家所有文章均包含本声明。

  网友发现新 Prompt,让微软 Copilot“坦白”说出系统版本、已装应用等

  微软 Win11 截图工具隐藏新特性:调用 Bing 搜索识别图片内容

  李彦宏:目前已有近 10 万家企业调用百度文心一言 AI 能力,萝卜快跑无人化商业运营指日可待

  微软 Win11 Dev 26120.470 发布:设置主页新增 XGP 服务推广卡片、修复大量 Bug

  微软 Win11 Beta 22635.3575 发布,共享窗口新增快捷复制按钮


本文由:m6米乐安装提供

您的项目需求

*请认真填写需求信息,我们会在24小时内与您取得联系。