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

大綱大綱

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

音頻識(shí)別推斷

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

文件校驗(yàn):AR 引擎驗(yàn)證輸入音頻文件。

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

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

后處理:后處理模式解碼結(jié)果并計(jì)算用來將推斷輸出轉(zhuǎn)換成標(biāo)記或記錄謄本的分?jǐn)?shù)。

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

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

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

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

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

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

圖2 圖2:多讀 AR 引擎

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

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

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

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

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

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

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

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

解決全球線索池問題

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

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

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

如圖4所示,當(dāng)LibTorch全球線條池被禁用時(shí),最低處理時(shí)間是測量的。

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

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

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

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

摘要摘要

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

審核編輯：湯梓紅