推测解码:在不降低准确性的情况下将LLM推理速度提高2 - 3倍

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 在本篇文章我们将详细讨论推测解码,这是一种可以将LLM推理速度提高约2 - 3倍而不降低任何准确性的方法。我们还将会介绍推测解码代码实现,并看看它与原始transformer 实现相比到底能快多少。

在本篇文章我们将详细讨论推测解码,这是一种可以将LLM推理速度提高约2 - 3倍而不降低任何准确性的方法。我们还将会介绍推测解码代码实现,并看看它与原始transformer 实现相比到底能快多少。

推测解码是一种“先推测后验证” (Draft-then-Verify) 的解码算法,涉及并行运行两个模型,可与i将语言模型推理的速度有望提高2-3倍。

自回归抽样

从语言模型生成文本的标准方法是使用自回归采样,其中解码K个标记需要对模型进行K次串行运行。

从像Transformers 这样的大型自回归模型中进行推理是缓慢的——解码K个令牌需要对模型进行K次连续运行。

 def generate(prompt: str, tokens_to_generate: int) -> str:
     tokens = tokenize(prompt)
     for i in range(tokens_to_generate):
         next_token = model(tokens)
         tokens.append(next_token)
     return detokenize(tokens)

推测解码

使用一种称为推测解码的方法可以使语言模型(LLM)在不改变其结果的情况下工作得更快。通过并行运行两个模型,有望将LLM推理的速度提高2 - 3倍,这两个模型是

1、目标模型;在任务中使用的主要LLM;2、小型草稿模型:一个更小,轻量级的LLM,与主LLM一起运行,以帮助加快主LLM的推理过程。目标模型和草稿模型都必须使用相同的标记器。

他的工作工作方式如下:

预测一个token“of”非常容易,而且它可能很容易被更小的模型预测,因此使用较小的模型来预测容易的token,而使用大模型只用于预测更困难的token。

虽然模型通常一次生成一个单词,但它们可以一次处理多个令牌。在生成下一个标记时,它们需要一次检查序列中的所有标记。较小的模型预测“Toronto”,但正确的单词是“Edinburgh”,较大的模型可以看到“Toronto”的概率较低,并将其修正为“Edinburgh”。

语言建模任务通常包括一些更容易的子任务,这些子任务可以通过更有效的轻量级模型很好地解决,这些模型的执行时间非常短。当在LLM上执行推理时,推测解码使用较小的草稿模型生成推测令牌,然后目标LLM验证由较小草稿模型生成的那些草稿输出令牌。通过推测执行,可以更快地从大型模型生成精确解码。这是通过同时在较小模型的粗略猜测上运行较大模型来实现的。这意味着我们可以在一个较大模型的前向传播中生成几个令牌,而不改变输出分布。

所以推测解码提供的加速在很大程度上取决于草稿模型的选择。使用更通俗的语言描述就是,使用一个小模型来编写草稿,然后让大模型对草稿进行修正。

上图的算法解释如下:

(1)使用更高效的小模型Mq生成γ完井。

(2)使用目标模型Mp来并行评估所有来自Mq的猜测及其各自的概率,接受所有可能导致相同分布的猜测。

(3)从调整后的分布中采样一个额外的令牌,修复第一个被拒绝的令牌。或者如果它们都被接受,则添加一个额外的令牌。这样目标模型Mp的每次并行运行将至少产生一个新的标记(即使在最坏的情况下,目标模型的串行运行的数量也永远不会大于简单的自回归方法),但它可以潜在地生成许多新的标记(最高可达γ + 1),这取决于Mq和Mp输出的近似程度

代码实现和实验结果

为了运行和评估LLM,所以需要一个显存大一些的GPU,这里使用NVIDIA RTX 6000。

我们使用transformers库直接指定assistant_model就可以实现推测解码

 fromtransformersimportAutoModelForCausalLM, AutoTokenizer
 importtorch

 prompt="Alice and Bob"
 checkpoint="EleutherAI/pythia-1.4b-deduped"
 assistant_checkpoint="EleutherAI/pythia-160m-deduped"
 device="cuda"iftorch.cuda.is_available() else"cpu"

 tokenizer=AutoTokenizer.from_pretrained(checkpoint)
 inputs=tokenizer(prompt, return_tensors="pt").to(device)

 model=AutoModelForCausalLM.from_pretrained(checkpoint).to(device)
 assistant_model=AutoModelForCausalLM.from_pretrained(assistant_checkpoint).to(device)
 outputs=model.generate(**inputs, assistant_model=assistant_model)
 print(tokenizer.batch_decode(outputs, skip_special_tokens=True))

这里的参数num_assistant_tokens:定义在每次迭代中由目标模型检查之前,草稿模型应生成的speculative token的数量。较高的' num_assistant_tokens '值使生成更好:如果辅助模型性能良好,则可以达到较大的加速,如果辅助模型需要大量修正,则可以达到较低的加速。

最后我们来看看结果:

总结

我们看到,推理的速度的还真是有2倍的提升,并且还可以看到我们的草稿模型要比目标模型小了10倍左右(1.4B和160M)

Deepmind论文中提到的2 - 2.5倍的加速比也可能适用于70B目标模型和7B草稿模型,所以如果多卡的话可以加载2个大语言模型来提供加速。

以下是推测解码的论文

https://avoid.overfit.cn/post/5a5ec75eec9f48a685c2686b0009e8fc

目录
相关文章
|
4月前
|
机器学习/深度学习 缓存
Block Transformer:通过全局到局部的语言建模加速LLM推理
Block Transformer是一种优化自回归语言模型推理效率的新架构,通过块级自注意力来平衡全局和局部依赖,提高吞吐量。模型包含嵌入器、块解码器和令牌解码器,其中块解码器处理全局依赖,令牌解码器处理局部细节。这种方法减轻了KV缓存的延迟和内存开销,尤其是在长序列处理中。实验显示,尽管Block Transformer参数量增加,但推理速度显著提升,尤其是在大块长度和优化的组件比例下,实现了性能与速度的平衡。
295 7
|
1天前
|
机器学习/深度学习 自然语言处理 测试技术
CoT神话破灭,并非LLM标配!三大学府机构联手证实,CoT仅在数学符号推理有用
【10月更文挑战第16天】近期,加州大学伯克利分校、斯坦福大学和卡内基梅隆大学联合研究发现,链式思维(CoT)方法在数学和符号推理任务中表现优异,但在其他类型任务中效果不明显。这一研究打破了CoT作为大型语言模型(LLM)标配的神话,为重新审视LLM的推理能力提供了新视角。
6 2
|
1月前
|
人工智能 Prometheus 监控
使用 NVIDIA NIM 在阿里云容器服务(ACK)中加速 LLM 推理
本文介绍了在阿里云容器服务 ACK 上部署 NVIDIA NIM,结合云原生 AI 套件和 KServe 快速构建高性能模型推理服务的方法。通过阿里云 Prometheus 和 Grafana 实现实时监控,并基于排队请求数配置弹性扩缩容策略,提升服务稳定性和效率。文章提供了详细的部署步骤和示例,帮助读者快速搭建和优化模型推理服务。
136 7
使用 NVIDIA NIM 在阿里云容器服务(ACK)中加速 LLM 推理
|
1月前
|
人工智能 Prometheus 监控
使用NVIDIA NIM在阿里云ACK中加速LLM推理
介绍在阿里云ACK集群上结合AI套件能力快速部署NVIDIA NIM模型推理服务,同时提供全面的监控指标和实现弹性伸缩。
使用NVIDIA NIM在阿里云ACK中加速LLM推理
|
1月前
|
编解码 定位技术 计算机视觉
多模态LLM视觉推理能力堪忧,浙大领衔用GPT-4合成数据构建多模态基准
【9月更文挑战第2天】浙江大学领衔的研究团队针对多模态大型模型(MLLM)在抽象图像理解和视觉推理上的不足,提出了一种利用GPT-4合成数据构建多模态基准的方法。该研究通过合成数据提高了MLLM处理图表、文档等复杂图像的能力,并构建了一个包含11,193条指令的基准,涵盖8种视觉场景。实验表明,这种方法能显著提升模型性能,但依赖闭源模型和高计算成本是其局限。论文详细内容见:https://arxiv.org/pdf/2407.07053
72 10
|
3月前
|
并行计算 PyTorch 算法框架/工具
LLM推理引擎怎么选?TensorRT vs vLLM vs LMDeploy vs MLC-LLM
有很多个框架和包可以优化LLM推理和服务,所以在本文中我将整理一些常用的推理引擎并进行比较。
300 2
|
3月前
|
人工智能 算法
等不来OpenAI的Q*,华为诺亚探索LLM推理的秘密武器MindStar先来了
【7月更文挑战第13天】华为诺亚方舟实验室推出MindStar,一种增强LLM推理能力的搜索框架。MindStar通过PRM奖励模型和Beam/Levin Search策略选择最佳推理路径,提升开源模型如LLaMA-2-13B、Mistral-7B的性能,与GPT-3.5等闭源模型媲美,但成本更低。尽管推理成本高和需预训练PRM,MindStar为LLM推理研究开辟新途径。[论文链接](https://arxiv.org/pdf/2405.16265v4)
72 9
|
3月前
|
算法 API 数据中心
魔搭社区利用 NVIDIA TensorRT-LLM 加速开源大语言模型推理
魔搭社区于 2022 年 11 月初创建,首次在业界提出了 “模型即服务”( MaaS, Model as a Service)的理念。
|
3月前
LLM用于时序预测真的不行,连推理能力都没用到
【7月更文挑战第15天】LLM在时序预测上的应用遇挫:研究显示,大型语言模型在多个实验中未显优势,甚至被简单注意力层替代时效果不变或更好。预训练知识未能有效利用,处理时序依赖性不足,且在小样本学习中未见提升。[链接:](https://arxiv.org/pdf/2406.16964)**
71 2
|
3月前
|
测试技术
谷歌DeepMind全新ToT基准:全面评估LLM时间推理能力
【7月更文挑战第10天】DeepMind的ToT基准测试了大型语言模型的时间推理能力,分为ToT-Semantic(合成数据,评估时间逻辑理解)和ToT-Arithmetic(真实数据,检查时间计算)。研究使用Claude-3-Sonnet、GPT-4和Gemini 1.5 Pro进行评估,发现模型在时间逻辑理解上表现各异,而时间计算上均较强。 Gemini 1.5 Pro在复杂问题上表现出色,而GPT-4在数学相关问题上较弱。[[1](https://arxiv.org/pdf/2406.09170)]
43 1