​百川智能:深度学习大模型推理性能优化策略

文摘   2024-11-04 18:01   北京  

导读 随着深度学习技术的不断发展,大模型在各个领域的应用越来越广泛,如自然语言处理、图像识别、语音识别等。随着硬件技术的不断进步,未来的大模型推理框架将更加注重性能优化,提供更高效率的模型推理服务。大模型推理框架作为深度学习领域的一项重要技术,为处理大规模数据和模型提供了有效的解决方案,未来将在更多领域展现出其强大的应用价值。

本文将从四个优化专项介绍如何优化大模型推理框架性能:

1. 量化

2. 投机采样

3. TTFT 与 TPOT 的优化

4. 通信优化

分享嘉宾|肖彬 百川智能 高级专家

编辑整理|杨凯玥

内容校对|李瑶

出品社区|DataFun


01

   量化

量化的本质通常是将模型的参数,或整个模型的推理过程从浮点转化为整型。模型量化是一种将浮点计算转成低比特定点计算的技术,可以有效降低模型计算强度、参数大小和内存消耗,但往往会带来巨大的精度损失。量化精度从高到低排列顺序是:fp16>int8>int4,量化的精度越低,模型的大小和推理所需的显存就越小,但模型的能力也会越差。

量化作为大模型最重要的性能优化手段,能有效降低显存占用,降低访存量,更充分地利用计算资源。大模型的计算流程如下图所示,会经过 attention 和 MLP 两个阶段,其中 attention 会读写 KV cache。

下面具体介绍各个版本的量化。

1. Weight-int8 + KV_cache_int8

可以显著降低显存占用,因为 weight 和 KV cache 在推理框架占用显存为大头,所以将二者分别使用离线/在线量化为 int8,可以使用较少卡启动模型,增大服务承载能力。我们在上线后使成本降低了 50%。

2. Activation int8

A8 是在 W8/KV8 基础上对 GEMM 相关计算的输入激活进行量化,能有效降低  GEMM 运算耗时,首 token 耗时可下降 50%,成本下降 15%。

3. Weight-int4 + kv_cache-int4

Int4 主要目标是将显存占用压至更低,能在低端卡型上部署并支持更长的序列,支持更大的 batch,可以使成本下降 30%。使用了类似 quorate 的技术,并结 w4a16/w4a8 算子,针对性做了优化,已在多个业务落地。

4. Communication int8

通信量化,降低低端卡通信耗时开销,首 token 耗时下降 30%。

5. Attention QKV int8

将 GEMM 计算全线转为 int8 计算 :Q(int8)*K(int8)->softmax(fp32)->V(int8)

02

投机采样

投机采样是利用 decode 过程算力冗余,使用额外的技术生成多个候选 token 同时输送给大模型并行验证,可充分使用算力且不会额外增加过多时延。

投机采样的设计基于两点认知:在模型推理中,token 生成的难度有差别,有部分 token 生成难度低,用小参数草稿模型(下简称小模型)也能够比较好的生成;在小批次情况下,原始模型(下简称大模型)在前向推理的主要时间在加载模型权重而非计算,因此批次数量对推理时间的影响非常小。

1. Clover 模型结构设计路线

我们设计的 Clover 模型,经过两个重要阶段:

(1)尝试获取全局的信息,而不是仅仅当前预测 token 的信息。我们首先使用 transformer block 前几层信息预测,但效果不好。于是单独建一层可学习的 transformer block 收集全局信息,提升不错。

(2)尝试使用前置候选 token 信息,辅助后续 token 预测。通过一层 MLP 整合 h 与 emb 效果提升有限。尝试 attention 结构,h 表示全局信息,不断吸收 token_emb 信息,效果不错。

2. Sample 策略

我们的目标是大 batch 场景下投机有效,要求的候选 token 仅仅为 4,此时 sample 策略就影响很大了,开源的都是固定组合的形式,如 head_0_top1+head_1_top1+head_2_top1, head_0_top2+head_1_top1+head_2_top1

动态构建候选 token 树,我们采用的是较为激进的贪心搜索策略。

核心策略有以下三点:

(1)单 token 级别(保证树深度)

  • prob 先进行 top p 丢弃

  • 按照 top1/4 长尾小概率丢弃

(2)token tree 级别(子节点排序依据)

  • 从根节点的联合概率排序

(3)每层 token 预算数量(保证树最大宽度,防止计算量激增)

去除所有父节点 token 数

具体如下图所示:

3. Clover 收益

实验命中率上提升 50%+,端到端推理速度提升 30%+,效果如下图。

4. Clover2 模型结构升级

Clover-2 是在 Clover 基础上升级而来,在各种模型架构上超越了现有方法,展示了其有效性和稳健性。有如下改进点:

(1)loss 优化

  • 仅仅根据 CrossEntropyLoss 预测 token 偏序关系,训练多轮,过拟合 ,会出现对一些高频 token 增强概率的情况。

  • 增加数据蒸馏 loss 使得 clover 能更加关注与主模型的一致性上,而不是走捷径。

(2)主模型预测 token 信息前置,提前加入 transformer block,帮助更远的预测。

(3)Regressive attention block output projector 结构,提升后几个 head 预测能力。

(4)增加 Augmenting Block 层数,增强全局信息提取能力。Augmenting Block 位于第一个 head 之前只会跑一次,增加层数不会导致跑多次的问题,eagle 增加层就会导致每个 head 都多跑,耗时会暴增。这为 clover 提供更多可能,可以设计更加复杂的 Augmenting Block,我们尝试最简单的加层获取收益。

5. Clover2 收益

Clover 为 rnn 为主的架构,但仍然能打败 eagle 这种以 decode layer 为主的模型结构,在各个数据集上都超过 eagle,下面是 Clover2 结构。

03

TTFT 与 TPOT 的优化

TTFT:首个 Token 响应时间,用户输入查询后,多快可以开始看到模型的输出。在实时交互中,响应时间需要尽可能短,但在离线工作负载中则不那么重要。这个指标由处理提示信息和生成第一个输出 token 所需的时间决定。

TPOT:每个输出 Token 的时间,系统生成每个用户查询的输出 token 所需的时间。这个指标与用户感知模型速度的方式直接相关。例如,如果 TPOT 100 毫秒/token,那么每秒可以生成 10 token,或者每分钟约 450 个词,这比一般人的阅读速度要快。

首 token 耗时 与 decode 每个 token 间耗时 的平衡驱动来源于用户体验上优化,当一个新的用户请求进入时会导致现有做 decode 的请求被卡住。

1. Chunk prefill

Chunk prefill,即切块式 prefil,是将单次 prefill 计算拆分为多段计算的技术,能有效降低 decode 间隔时间。

Split fused 技术,将 chunk prefill 与 decode 计算整合,有效提升计算利用率。

最终收益:decode token 间隔 p99 下降在各个业务都非常明显。

2. PD 分离

Prefill 性能评估指标:TTFT,Decode 性能评估指标:TPOT。不同的推理任务中,Prefill 和 Decode 的分布不同,在 P/D 混合部署中,大部分时间消耗在 Decode 阶段,未充分利用到 GPU 的算力,对大部分的请求,E2E 时间消耗在 Decode 阶段,Prefill 阶段应该限制 Batch size 从而避免影响性能,相反,Decode 阶段应该增大Batch size 来获得更高的吞吐,Prefill 阶段算力是瓶颈,Decode 阶段内存是瓶颈,Prefill 阶段能充分使用算力,Decode 阶段不能,Decode 阶段可以使用性能较弱、成本较低的设备。

解决 TTFT 与 TPOT 的平衡,PD 分离是终极方案。prefill decode 在独立阶段完成,通过异步传输完成 kv cache 迁移。

较短的输入仍然采用 split-fused 的混合推理方案,长请求会单独扔给 prefill 节点完成,长请求来的时间不一定,此时需要 PD 动态调度策略。

3. Cache 策略

Session cache 缓存多轮请求 KV cache 结果,多级动态 LRU 排除老数据,对于第二轮的请求首 token 延迟提升巨大,同时也支持 sys_prompt cache 功能。

04
通信优化

在大模型推理中,计算通信由于模型结构限制是串行执行的,会导致通信过程中算力被浪费。在 4090 卡上,由于通信能力很弱,问题更加明显,通信耗时占比很高,导致 GPU 大部分时间算力浪费。为解决这个问题,提出了很多计算通信 overlap 的方法。

1. 计算通信 overlap

常见方法:

  • GEMM overlap: 许多场景通信耗时会长于矩阵乘(GEMM)计算,导致不能很好 overlap

  • Request overlap: 需要组批两个请求,还需要两个请求间尽量计算量均衡

  • 我们的设计:ISO,sequence 内的 overlap 方法,如图所示:

计算通信占比越均衡收益越大,最终收益上限取最小的占比,在 a800 4090 上计算通信占比都比较极端

我们针对性地做了优化:

  • 4090 通信占大头,通信>attention && 通信>MLP,8bit 通信,对通信进行量化。

  • A800 计算占大头,通信<attention && 通信<MLP,GEMM 与 comm 多 stream 会导致 GEMM 耗时增加 20% 采用 GEMM 切块的策略,减少 GEMM 与 comm 之间的重叠。

除了以上两个极端的情况,可能会出现 MLP<通信<attention 的情况,为此我们设计了可能的优化手段:

  • attention 计算量的不平衡,sequence 的第二段 attention 计算量明显高于第一段,通过调整 sequence 切分占比。

  • attention-MLP-通信间的不平衡,采用下图更加复杂的 4 段切分策略。

2. 计算通信 overlap 收益

最终获得了显著收益,4090 4 卡 40%,8 卡 25%,A800 4 卡 10%,8 卡 15%。计算通信占比越均衡收益越大,最终收益上限取最小的占比。

以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


肖彬

百川智能

高级专家

北京理工大学本硕,先后在搜狗负责推荐架构,在字节跳动负责智能推荐平台训推架构,目前在百川智能负责大模型推理架构研发

往期推荐


统一元数据管理 - Gravitino 在 B 站的最佳实践

大模型与行业融合:推动钢铁、医疗、教育领域的智能化变革

多模态大语言模型领域进展分享

智能驾驶技术趋势及成熟应用场景

万字讲解标签体系技术|附福利

360在图文多模态大模型领域的突破与实践

西门子利用 LLM 打造通用公司智能助理的实践

大模型+数据智能分析应用发展趋势及标准化工作介绍

B 站基于大模型的大数据智能诊断助手实践

现代化实时数据仓库 SelectDB 产品全面解读

点个在看你最好看

SPRING HAS ARRIVED

DataFunSummit
DataFun社区旗下账号,专注于分享大数据、人工智能领域行业峰会信息和嘉宾演讲内容,定期提供资料合集下载。
 最新文章