當前位置:區(qū)塊鏈 >區(qū)塊鏈 > 多輪對話推理速度提升46%,開源方案打破LLM多輪對話的長度限制?

多輪對話推理速度提升46%,開源方案打破LLM多輪對話的長度限制?

更新時間:2024-01-08 13:28:19 | 作者:佚名
來源:機器之心 圖片來源:由無界AI生成 在大型語言模型(LLM)的世界中,處理多輪對話一直是一個挑戰(zhàn)。前不久麻省理工GuangxuanXiao等人推出的StreamingLLM,能夠在不犧牲推理速度和生成效果的前提下,可實現(xiàn)多輪對話總共400萬個token的流式輸入,22.2倍的推理速度提升。 但StreamingLLM使用原生PyTorch實現(xiàn),對于多...

來源:機器之心

圖片來源:由無界 AI生成

在大型語言模型(LLM)的世界中,處理多輪對話一直是一個挑戰(zhàn)。前不久麻省理工 Guangxuan Xiao 等人推出的 StreamingLLM,能夠在不犧牲推理速度和生成效果的前提下,可實現(xiàn)多輪對話總共 400 萬個 token 的流式輸入,22.2 倍的推理速度提升。

但 StreamingLLM 使用原生 PyTorch 實現(xiàn),對于多輪對話推理場景落地應用的低成本、低延遲、高吞吐等需求仍有優(yōu)化空間。

Colossal-AI 團隊開源了SwiftInfer,基于 TensorRT 實現(xiàn)了 StreamingLLM,可以進一步提升大模型推理性能 46%,為多輪對話推理提供了高效可靠的落地方案。

開源地址:https://github.com/hpcaitech/SwiftInfer


StreamingLLM 簡介


大語言模型能夠記住的上下文長度,直接影響了 ChatGPT 等大模型應用與用戶互動的質量。

如何讓 LLM 在多輪對話場景下保持生成質量,對推理系統(tǒng)提出了更高的要求,因為 LLM 在預訓練期間只能在有限的注意力窗口的限制下進行訓練。

常見的 KV Cache 機制能夠節(jié)約模型計算的時間,但是在多輪對話的情景下,key 和 value 的緩存會消耗大量的內存,無法在有限的顯存下無限擴展上下文。同時,訓練好的模型在不做二次微調的前提下也無法很好地泛化到比訓練序列長度更長的文本,導致生成效果糟糕。

圖來源:https://arxiv.org/pdf/2309.17453.pdf

StreamingLLM 為了解決了這個問題,通過觀察了注意力模塊中 Softmax 的輸出,發(fā)現(xiàn)了 attention sink 的現(xiàn)象。我們知道注意力機制會為每一個 token 分配一個注意力值,而文本最初的幾個 token 總是會分配到很多無用的注意力。當我們使用基于滑動窗口的注意力機制時,一旦這幾個 token 被踢出了窗口,模型的生成效果就會迅速崩潰。只要一直把這幾個 token 保留在窗口內,模型就能穩(wěn)定地生成出高質量的文本。

比起密集注意力(Dense Attention)、窗口注意力(Window Attention)以及帶重計算的滑動窗口注意力 (Sliding Window w/ Re-computing),StreamingLLM 基于 attention sink 的注意力機制無論是在計算復雜度還是生成效果上都表現(xiàn)優(yōu)異。在不需要重新訓練模型的前提下,StreamingLLM 能夠直接兼容目前的主流大語言模型并改善推理性能。


SwiftInfer:基于 TensorRT 的 StreamingLLM 實現(xiàn)


為了將 StreamingLLM 這一技術更好的應用到落地場景,Colossal-AI 團隊成功地將 StreamingLLM 方法與 TensorRT 推理優(yōu)化結合,不僅繼承了原始 StreamingLLM 的所有優(yōu)點,而且還具有更高的運行效率。使用 TensorRT-LLM 的 API,我們還能夠獲得接近于 PyTorch API 的模型編寫體驗。

基于 TensorRT-LLM,我們重新實現(xiàn)了 KV Cache 機制以及帶有位置偏移的注意力模塊。如下圖所示,假設我們的窗口大小為 10 個 token,隨著生成的 token 增加(由黃色方塊表示),我們在 KV 緩存中將中間的 token 踢出,與此同時,始終保持著文本開始的幾個 token(由藍色方塊表示)。由于黃色方塊的位置會發(fā)生變化,在計算注意力時,我們也需要重新注入位置信息。

需要注意的是,StreamingLLM 不會直接提高模型能訪問的上下文窗口,而是能夠在支持流式超多輪對話的同時保證模型的生成效果。


大模型無限輸入流推理加速 46%


原版本的 StreamingLLM 可以可靠地實現(xiàn)超過 400 萬個 token 的流式輸入,實現(xiàn)了比帶重計算的滑動窗口注意力機制高出 22.2 倍的速度提升。

Colossal-AI 團隊發(fā)布的 SwiftInfer 可以進一步提升推理性能,最多帶來額外的最多46% 的推理吞吐速度提升,為大模型多輪對話推理提供低成本、低延遲、高吞吐的最佳實踐。TensorRT-LLM 團隊也在同期對 StreamingLLM 進行了類似支持。


Colossal-AI 社區(qū)動態(tài)


Colossal-AI 目前已獲得 GitHub 星數(shù)三萬五千多顆,位列全球 TOP400,細分賽道排名世界第一,可通過高效多維并行、異構內存等,降低 AI 大模型訓練 / 微調 / 推理的開發(fā)與應用成本,提升模型任務表現(xiàn),降低 GPU 需求。作為主流開源 AI 大模型系統(tǒng)社區(qū),Colossal-AI 生態(tài)在多方面保持活躍更新。

Colossal-LLaMA-2-13B 開源

Colossal-LLaMA-2-13B 模型,僅用 25B token 數(shù)據(jù)和萬元算力,效果遠超基于 LLaMA-2 的其他中文漢化模型。即使與其他采用中文語料,可能花費上千萬元成本,從頭預訓練的各大知名模型相比,Colossal-LLaMA-2 在同規(guī)模下仍表現(xiàn)搶眼。13B 版本通過構建更為完善的數(shù)據(jù)體系,在知識性內容掌握程度,自然語言處理任務理解程度,以及安全性,價值觀等問題上,都有質的提升。

Colossal-AI 云平臺

Colossal-AI 云平臺在整合 Colossal-AI 系統(tǒng)優(yōu)化和廉價算力的基礎上,近期發(fā)布了 AI 云主機的功能,方便用戶以近似裸機的方式進行 AI 大模型的開發(fā)和調試,并提供了多種使用方式,包括:Jupyter Notebook、ssh、服務本地端口映射和 grafana 監(jiān)控,全方位的為用戶提供便捷的開發(fā)體驗。同時,還為用戶預制了含有 ColossalAI 代碼倉庫和運行環(huán)境的 docker 鏡像,用戶無需環(huán)境和資源配置,便可一鍵運行 ColossalAI 代碼倉庫中的代碼樣例。

Colossal-AI 開源地址:https://github.com/hpcaitech/ColossalAI

參考鏈接:

https://hpc-ai.com/blog/Colossal-AI-SwiftInfer

本站提醒:投資有風險,入市須謹慎,本內容不作為投資理財建議。