0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內(nèi)不再提示

LibTorch-based推理引擎優(yōu)化內(nèi)存使用和線程池

jf_pJlTbmA9 ? 來源:jf_pJlTbmA9 ? 作者:jf_pJlTbmA9 ? 2023-08-31 14:27 ? 次閱讀

由喜馬拉伊·莫漢拉爾·喬里瓦爾、皮埃爾-伊夫·阿基蘭蒂、維韋克·戈溫丹、哈米德·舒賈納澤里、安基思·古納帕勒、特里斯坦·賴斯撰寫

大綱大綱

在博客文章中,我們展示了如何優(yōu)化基于 LibTorrch 的推論引擎,通過減少記憶用量和優(yōu)化線狀組合戰(zhàn)略來最大限度地增加吞吐量。 我們將這些優(yōu)化應用到音頻數(shù)據(jù)模式識別引擎,例如音樂和語音識別或聲波指紋。 本博客文章中討論的優(yōu)化使得內(nèi)存使用率減少了50%,推論端到端的延遲度減少了37.5%。 這些優(yōu)化適用于計算機視覺和自然語言處理。

音頻識別推斷

音頻識別(AR)引擎可用于識別和識別聲音模式。 例如,識別鳥類與錄音的種類和種類,區(qū)分音樂與歌手的聲音,或檢測顯示建筑物有異常故障的聲音。 為了識別有興趣的聲音,AR引擎將音頻處理到4個階段:

文件校驗:AR 引擎驗證輸入音頻文件。

采掘:從音頻文件中的每個部分提取特征。

推斷: LibTorrch 使用 CPU 或加速器進行推論。就我們的情況而言,在 Elastic Cloud 計算( EC2) 實例中,使用 Intel 處理器進行推論。

后處理:后處理模式解碼結果并計算用來將推斷輸出轉換成標記或記錄謄本的分數(shù)。

在這4個步驟中,推論是計算最密集的,根據(jù)模型的復雜性,推論可以占管道處理時間的50%,這意味著現(xiàn)階段的任何優(yōu)化都會對整個管道產(chǎn)生重大影響。

最優(yōu)化音頻識別引擎, 使用 conconconconconcondal 貨幣... 并不簡單

輸入數(shù)據(jù)是一個音頻文件,由幾個短聲段組成(圖1中的S1至S6),輸出數(shù)據(jù)與按時間戳訂購的標記或記錄謄本相對應。

wKgZomTv-CGAN5HEAAGCUuVN5SA551.jpg

圖1 圖1:有段邊框的音頻文件示例

每一部分可以獨立和不按部就班的方式處理,這樣就有機會同時處理各部分,同時處理各部分,優(yōu)化總體推論量,最大限度地利用資源。

實例的平行化可以通過多行( phread: std:: threads, OpenMP) 或多處理來實現(xiàn)。 多處理的多行的好處是能夠使用共享的內(nèi)存。 它使開發(fā)者能夠通過共享線條的數(shù)據(jù)來盡量減少線條上的數(shù)據(jù)重復; 我們的 AR 模型( 以我們?yōu)槔? ( AR 模型) 。圖2 圖2此外,記憶力的減少使我們能夠通過增加引擎線的數(shù)量,同時運行更多的管道,以便利用我們亞馬遜EC2實例中的所有小CPU(VCPU)。c5.4 寬度我們的情況是,它提供了16 VCPUs。 理論上,我們期望看到我們的AR引擎的硬件利用率更高,輸送量更高。

wKgaomTv-CWAMT4uAAEudbJ52UE106.jpg

圖2 圖2:多讀 AR 引擎

但是,我們發(fā)現(xiàn)這些假設是錯誤的。 事實上,我們發(fā)現(xiàn)應用程序的線條數(shù)量增加導致每個音頻段端到端的延遲度增加,引擎輸送量減少。 比如,將同值貨幣從1個線條增加到5個線條導致延緩度增加4x,這對減少吞吐量產(chǎn)生了相應的影響。 事實上,衡量標準顯示,在管道內(nèi),單是推斷階段的延遲度就比單一線線條基線高出3x。

使用一個剖面文件 我們發(fā)現(xiàn)CPU旋轉時間由于CPU 過度訂閱會影響系統(tǒng)和應用性能,我們可能因此增加。 鑒于我們對應用程序多軌執(zhí)行的控制,我們選擇更深入地潛入堆棧,并找出與 LibTorrch 默認設置的潛在沖突。

深入了解LibTorch的多行及其對同貨幣的影響

LibTorch 平行執(zhí)行CPU的推斷依據(jù)是:全環(huán)線串聯(lián)集合執(zhí)行實例是跨業(yè)務和內(nèi)部平行,可視模型的特性選擇。在這兩種情況下,都有可能設定線索數(shù)在每個線性孔中 優(yōu)化潛伏和吞吐量

為了測試LibTorrch的平行默認執(zhí)行設置是否對我們的推論延緩期產(chǎn)生了反作用,我們用一個35分鐘的音頻文件對一臺16 vCPus機器進行了實驗,將LibTorrch的連接線條常數(shù)保持在1(因為我們的模型沒有使用操作間線條庫 ) 。 我們收集了以下數(shù)據(jù),如圖3和圖4所示。

wKgZomTv-GGAZqRGAAFl_Bxjf6o762.jpg

圖3 圖3:不同數(shù)量引擎線索的 CPU 利用率

wKgZomTv-GiABBdJAAFLRrdlQ78245.jpg

圖4 圖4: 不同數(shù)量引擎線索的處理時間

圖4中的執(zhí)行時間是處理給定音頻文件所有部分的端到端處理時間。 我們有4個不同配置的 LibTorrch 內(nèi)部線條內(nèi)部配置為 1 、 4 、 8 、 16, 并且我們將每條線內(nèi)配置的引擎線數(shù)從1 改為 16。 如圖3所示, CPU的利用率隨著所有 LibTorrch 內(nèi)部配置的引擎線數(shù)的增加而增加。 但是, 如圖4所示, CPU 利用率的增加并沒有轉化為較低的執(zhí)行時間。 我們發(fā)現(xiàn), 在除1個案例之外的所有案例中, 發(fā)動機線條數(shù)量增加, 執(zhí)行時間也隨之增加。 例外的是, 整個線條內(nèi)庫規(guī)模增加1 的情況是一個例外。

解決全球線索池問題

與全球線索庫使用過多的線索導致性能退化,并造成訂閱過多問題。全球連托全球聯(lián)線人才庫,很難與多過程發(fā)動機的性能相匹配。

將LibTorrch全球線條庫拆解, 簡單到將操作內(nèi)部/操作間平行線線設置為 1, 如下表所示:

:set_num_threads(1) // 禁用內(nèi)部線條庫 :set_ num_interop_threads(1) 。 / 禁用內(nèi)部線條庫 。

如圖4所示,當LibTorch全球線條池被禁用時,最低處理時間是測量的。

這一解決方案在若干情況下改善了AR發(fā)動機的吞吐量。 然而,在評價長數(shù)據(jù)集(在負荷測試中超過2小時的Audio文件)時,我們發(fā)現(xiàn)發(fā)動機的記憶足跡開始逐漸增加。

優(yōu)化內(nèi)存使用

我們用兩個小時長的音頻文件對系統(tǒng)進行了負荷測試,發(fā)現(xiàn)觀察到的內(nèi)存增加是多軌LibTorch推論中內(nèi)存破碎的結果。我們用這個方法解決了這個問題。杰梅洛c,這是一個通用的商場(3)執(zhí)行,強調(diào)避免分散和可縮放的貨幣支持。使用 Jemalloc我們的峰值內(nèi)存使用率平均下降了34%,平均內(nèi)存使用率下降了53%。

wKgZomTv-IOAAjlIAAE0FISO-Hs693.jpg

圖5 圖5:使用有 Jemalloc 和沒有 Jemalloc 的同一輸入文件,隨著時間的推移內(nèi)存使用量

摘要摘要

為了優(yōu)化基于 libTorrch 的多軌 LibTorrch 推斷引擎的性能,我們建議核實LibTorrch 中不存在過量訂閱問題。 就我們而言,多軌引擎中的所有線條都是共享 LibTorrch 全球線條庫,這造成了一個過量訂閱問題。 這一點通過讓全球線條庫失效而得到糾正: 我們通過將線條設為 1 來禁用內(nèi)部和內(nèi)部全球線條庫。 為了優(yōu)化多軌引擎的內(nèi)存, 我們建議使用 Jemalloc 來作為記憶分配工具, 而不是默認的時鐘功能 。

審核編輯:湯梓紅

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • cpu
    cpu
    +關注

    關注

    68

    文章

    10863

    瀏覽量

    211781
  • 內(nèi)存
    +關注

    關注

    8

    文章

    3025

    瀏覽量

    74054
  • 線程池
    +關注

    關注

    0

    文章

    57

    瀏覽量

    6847
  • pytorch
    +關注

    關注

    2

    文章

    808

    瀏覽量

    13226
收藏 人收藏

    評論

    相關推薦

    Java中的線程包括哪些

    線程是用來統(tǒng)一管理線程的,在 Java 中創(chuàng)建和銷毀線程都是一件消耗資源的事情,線程可以重復
    的頭像 發(fā)表于 10-11 15:33 ?817次閱讀
    Java中的<b class='flag-5'>線程</b><b class='flag-5'>池</b>包括哪些

    針對Arm嵌入式設備優(yōu)化的神經(jīng)網(wǎng)絡推理引擎

    專門針對Arm嵌入式設備優(yōu)化的神經(jīng)網(wǎng)絡推理引擎Tengine + HCL,不同人群的量身定制
    發(fā)表于 01-15 08:00

    線程是如何實現(xiàn)的

    線程的概念是什么?線程是如何實現(xiàn)的?
    發(fā)表于 02-28 06:20

    關于RT-Thread內(nèi)存管理的內(nèi)存簡析

    :支持線程掛起。內(nèi)存無空閑內(nèi)存塊時,申請線程會被掛起,直到有可用內(nèi)存塊。簡單理解,就是將相同大
    發(fā)表于 04-06 17:02

    線程線程

    線程通常用于服務器應用程序。 每個傳入請求都將分配給線程池中的一個線程,因此可以異步處理請求,而不會占用主線程,也不會延遲后續(xù)請求的處理
    的頭像 發(fā)表于 02-28 09:53 ?795次閱讀
    多<b class='flag-5'>線程</b>之<b class='flag-5'>線程</b><b class='flag-5'>池</b>

    線程線程怎么釋放

    線程分組看,pool名開頭線程占616條,而且waiting狀態(tài)也是616條,這個點就非??梢闪?,我斷定就是這個pool開頭線程導致的問題。我們先排查為何這個
    發(fā)表于 07-31 10:49 ?2295次閱讀
    <b class='flag-5'>線程</b><b class='flag-5'>池</b>的<b class='flag-5'>線程</b>怎么釋放

    Spring 的線程應用

    我們在日常開發(fā)中,經(jīng)常跟多線程打交道,Spring 為我們提供了一個線程方便我們開發(fā),它就是 ThreadPoolTaskExecutor ,接下來我們就來聊聊 Spring 的線程
    的頭像 發(fā)表于 10-13 10:47 ?623次閱讀
    Spring 的<b class='flag-5'>線程</b><b class='flag-5'>池</b>應用

    什么是內(nèi)存

    使用時就會變得非???捷,大大提高程序運行效率。 在計算機中,有很多使用“”這種技術的地方,除了內(nèi)存,還有連接、線程
    的頭像 發(fā)表于 11-08 16:26 ?905次閱讀
    什么是<b class='flag-5'>內(nèi)存</b><b class='flag-5'>池</b>

    高并發(fā)內(nèi)存項目實現(xiàn)

    本項目實現(xiàn)了一個高并發(fā)內(nèi)存,參考了Google的開源項目tcmalloc實現(xiàn)的簡易版;其功能就是實現(xiàn)高效的多線程內(nèi)存管理。由功能可知,高并發(fā)指的是高效的多
    的頭像 發(fā)表于 11-09 11:16 ?722次閱讀
    高并發(fā)<b class='flag-5'>內(nèi)存</b><b class='flag-5'>池</b>項目實現(xiàn)

    了解連接線程、內(nèi)存、異步請求

    可被重復使用像常見的線程、內(nèi)存、連接、對象都具有以上的共同特點。 連接
    的頭像 發(fā)表于 11-09 14:44 ?1338次閱讀
    了解連接<b class='flag-5'>池</b>、<b class='flag-5'>線程</b><b class='flag-5'>池</b>、<b class='flag-5'>內(nèi)存</b><b class='flag-5'>池</b>、異步請求<b class='flag-5'>池</b>

    線程基本概念與原理

    一、線程基本概念與原理 1.1 線程概念及優(yōu)勢 C++線程簡介
    的頭像 發(fā)表于 11-10 10:24 ?537次閱讀

    線程的基本概念

    線程的基本概念 不管線程是什么東西!但是我們必須知道線程被搞出來的目的就是:提高程序執(zhí)行效
    的頭像 發(fā)表于 11-10 16:37 ?527次閱讀
    <b class='flag-5'>線程</b><b class='flag-5'>池</b>的基本概念

    內(nèi)存主要解決的問題

    程 序占有的資源數(shù)量。 經(jīng)常使用的技術包括內(nèi)存、線程和連接等,其中尤以
    的頭像 發(fā)表于 11-13 15:23 ?710次閱讀
    <b class='flag-5'>內(nèi)存</b><b class='flag-5'>池</b>主要解決的問題

    線程的創(chuàng)建方式有幾種

    線程是一種用于管理和調(diào)度線程的技術,能夠有效地提高系統(tǒng)的性能和資源利用率。它通過預先創(chuàng)建一組線程并維護一個工作隊列,將任務提交給線程
    的頭像 發(fā)表于 12-04 16:52 ?869次閱讀

    什么是動態(tài)線程?動態(tài)線程的簡單實現(xiàn)思路

    因此,動態(tài)可監(jiān)控線程一種針對以上痛點開發(fā)的線程管理工具。主要可實現(xiàn)功能有:提供對 Spring 應用內(nèi)線程
    的頭像 發(fā)表于 02-28 10:42 ?645次閱讀