讓pytorch模型更快速投入生產(chǎn)的方法

大家好，非常感謝大家的加入。我是馬克，在推理和PyTorch方面有著豐富的經(jīng)驗(yàn)。今天我想和大家談?wù)勔环N讓你的模型快速投入生產(chǎn)的方法。訓(xùn)練模型的過程非常艱難，你需要花費(fèi)大量時間和計(jì)算資源。但是推理問題似乎相對簡單一些。基本上，你只需要將模型在一個批次上運(yùn)行即可。這就是推理過程所需要的。然而，如果你更接近真實(shí)的場景，可能需要進(jìn)行一些額外的步驟。比如，你不能每次推理都重新加載模型，而且你可能需要設(shè)置一個HTTP服務(wù)器，并對其進(jìn)行推理。然后你需要加載模型權(quán)重和相關(guān)數(shù)據(jù)，對于大型模型，這可能需要很長時間。此外，用戶不會發(fā)送張量給你，他們可能發(fā)送文本或圖像，所以你可能需要對這些輸入進(jìn)行預(yù)處理。然后你就可以運(yùn)行推理了。

1.SetupanHTTpserver
2.Loadmodelweightsandartifacts
3.Preprocessinputs
4.Runaninference
5.Maketheinferencefast
6.Collectperformancemetrics
7.DeployonDockerorKubernetes
8.Scaletomultipleworkersandmachines

然后你就會想，太好了，我想要運(yùn)行一個推理，但是這個推理要花很長時間。它需要幾秒鐘的時間。而實(shí)時通常不超過10毫秒——這是很多用戶對我們推理的期望。所以至少還有一個10倍的乘數(shù)在里面。你需要不斷地對此進(jìn)行測量，因?yàn)槟悴荒艿却脩粢驗(yàn)樗俣忍艞壥褂媚愕膽?yīng)用程序。最終你可能需要將其部署在一種可復(fù)現(xiàn)的環(huán)境中，比如Docker Kubernetes。一旦你完成了所有這些，那么你還需要處理多進(jìn)程的問題。因?yàn)槟銓?個GPU，你需要讓這八個GPU都保持繁忙。你的CPU有數(shù)百個核心，你需要讓所有這些核心都保持繁忙。很多時候，我在TorchServe上工作，人們經(jīng)常問我TorchServe和FastAPI之間的區(qū)別，我的回答是，如果你只是做前面其中的四點(diǎn)，F(xiàn)astAPI做得很好，不需要再去使用TorchServe。

然而，如果你真的擔(dān)心推斷速度的快慢并且想讓它在多進(jìn)程中工作，我們解決了一些比較困難的問題?；旧?，我們有一個管理API，在這里你可以說，我想加載這些模型；一個推斷API，在這里你可以說，嘿，我想對這個模型進(jìn)行請求。這將啟動幾個后端工作器，這些后端工作器實(shí)際上是Python進(jìn)程。你正在啟動Python工作器。堆棧的其余部分大部分是用Java編寫的。人們經(jīng)常問我的一個問題是，Java不是很慢嗎？為了回答這個問題，這是一個火焰圖。

你可以看到這里，基本上你看到了左側(cè)的一條線，那是我們的框架開銷。順便說一下，讀這種圖的方式是x軸表示的不是時間，而是持續(xù)的消耗，因?yàn)檫@是一個采樣分析器。所以，這就是Java的開銷。還有很多空閑時間，"swapper"的意思是這內(nèi)核CPU根本不做任何事情。這大約占總運(yùn)行時間的50％，在我查看的典型客戶模型中如此，另外50％的時間花在Python環(huán)境中。所以你看這個，你需要做什么呢？首先，你需要做更多的處理，其次，你需要編寫更高效的PyTorch代碼。讓我們談?wù)勥@兩件事。

在做更多工作方面，你可用的最重要的優(yōu)化之一是所謂的動態(tài)批處理。動態(tài)批處理的本質(zhì)上是這樣的，你說：嘿，我有一個批次大小為4，但我最多等待30毫秒來獲取這三個元素。然后當(dāng)30毫秒過去時，只要有可用的數(shù)據(jù)，你就把它們組成一個批次(當(dāng)新的推理請求到達(dá)時，它們會被加入到當(dāng)前正在處理的批次中，而不是單獨(dú)進(jìn)行處理)。所以你需要不斷讓你的機(jī)器保持忙碌。

您使用產(chǎn)品的用戶體驗(yàn)就像使用Torch服務(wù)一樣，您需要編寫一個被稱為處理程序的東西。這個處理程序是一個Python類，基本上需要學(xué)會如何預(yù)處理您的數(shù)據(jù)，并將處理后的數(shù)據(jù)返回。因此，從根本上講，您希望在純Python中創(chuàng)建一個推斷服務(wù)器。這是您需要構(gòu)建的主要部分。您可以使用類似PDB這樣的工具。

這是我的同事Ankit Gunapal添加的功能。通過這樣的方式，您可以輕松地調(diào)試程序，找出錯誤并主動解決崩潰問題。擁有Pythonic的工作流程的好處之一是我們的一些客戶，比如Ryan Avery覺得我們的迭代速度很快，因?yàn)槟恍枰獙⒛Ｐ椭貙憺椴煌恼Z言來進(jìn)行交互。您可以使用同樣的工具進(jìn)行本地開發(fā)和生產(chǎn)部署。

所以，正如我之前提到的，典型程序的一半時間都在一個慢的PyTorch程序中度過。一種非常有用的調(diào)試方法是使用PyTorch分析器。你可以通過設(shè)置環(huán)境變量來啟用它。它的工作原理是顯示一個跟蹤結(jié)果。

在跟蹤結(jié)果中，你要注意的主要內(nèi)容是，如果你有類似"stream 7"的標(biāo)志，那就是你的GPU。（圖中的中間）你要注意的一個主要問題是有很多很小的線。這意味著你的GPU在派發(fā)獨(dú)立的核函數(shù)，這就意味著沒有融合，也就是你沒有充分利用你的GPU，相當(dāng)于你在浪費(fèi)錢。所以，你要希望那些線是厚厚的條狀，而不是這些細(xì)小的線。接下來，你可能會問，我的模型很慢，我該怎么辦？一種方法是編寫一個更小的模型，但也許這個更小的模型并不夠好。那么，在不改變模型代碼的情況下，你如何減少模型的延遲時間呢？

torch.compile(m,backend="inductor")
torch.compile(m,backend="xla")
torch.compile(m,backend="onnx")
Highlyrecommended:torch.compile(m,
mode="reduce-overhead"
ButJITshaveastartupoverhead

我一直向人們推薦的主要是Torch編譯。你基本上可以使用Torch編譯你的模型和感應(yīng)器。但編譯的好處在于它有一個后端參數(shù)。例如，如果你想在XLA和TPU上支持Torch服務(wù)，我們只需改變一個參數(shù)。也許像ONNX對于你正在查看的特定模型有更好的性能特征。所以你可以很容易地進(jìn)行基準(zhǔn)測試和查看。這與pytorch分析器和NVIDIA Insight結(jié)合使用，可以幫助你快速找出是什么使得事情變得更快。此外我還推薦了減少開銷這種模式。(reduce-overhead)CUDA圖表很棒，使一切都變得快速。所以，請使用它們?，F(xiàn)在它們終于能夠與動態(tài)形狀一起工作，因此它們與動態(tài)批處理很好地配合。這是一件大事，并且最近在2.1版中才支持，所以我極力推薦。

modelbt=BetterTransformer.transform(model
NowforGPUandCPU!

另一件事關(guān)于模型，目前非常流行的模型是transformers。但是，你不一定需要改變自己的模型去增加更快的核函數(shù)。因此，更好的transformer API在神經(jīng)網(wǎng)絡(luò)模塊級別上工作，可以讓你更換更高效的核函數(shù)。最好的是，現(xiàn)在這個API可以加速GPU和CPU的工作負(fù)載，最新版本是2.1。另外需要記住的一點(diǎn)是，如果你在編譯代碼，JIT有一定的開銷，這是一個無法回避的開銷，但是如果你使用更多的緩存，可以大大減輕這個開銷。

TORCHINDUCTORCACHEDIR
TORCHINDUCTORFXGRAPHCACHE
Makesuretocopytheseovertoreduce
yourwarmstarttimes

在像TorchServe這樣的推斷框架中，你將會生成多個Python進(jìn)程，所有這些進(jìn)程都可以共享同一個緩存，因?yàn)橥茢嗍且环N尷尬的并行任務(wù)。只要你在系統(tǒng)中設(shè)置這兩個環(huán)境變量，甚至可以將它們復(fù)制到多個節(jié)點(diǎn)上。這將大大減少您的熱啟動時間。所以我強(qiáng)烈建議您這樣做。只需在Docker命令或其他地方復(fù)制即可，沒有什么花哨的東西。

withtorch.device("meta")
model=Llama2
ckpt=torch.load(ckpt,mmap=True)
model.load_state_dict(ckpt,assign=True)

另一件事是在TorchServe中，我們過去推薦人們對模型進(jìn)行壓縮和解壓縮，因?yàn)樗梢猿蔀橐粋€獨(dú)立的工件。不幸的是，壓縮LLAMA7B大約需要24分鐘，解壓縮需要大約三分鐘，這是不可接受的。所以我們不再建議您進(jìn)行壓縮。只需直接使用文件夾即可。然后，在加載實(shí)際的權(quán)重時，將元設(shè)備初始化與MMAP加載結(jié)合使用，可以大大加快模型的運(yùn)行速度，在LLAMA7B上可能快約10倍。這基本上應(yīng)該成為默認(rèn)設(shè)置。

我們架構(gòu)的一個很酷的地方是，我們可以隨意生成任意的后端工作進(jìn)程，這些工作進(jìn)程甚至不需要是Python進(jìn)程。

Modelhandlercanbeinanylanguage!
#include
handle=dlopen("aot.so",RTLDNOW)

所以，例如，像我的同行Matias、Resso和Li Ning一樣，一直在致力于為對延遲極為敏感的人們創(chuàng)建C++進(jìn)程。另外一件事是，當(dāng)你從單個Python進(jìn)程轉(zhuǎn)向多個進(jìn)程時，性能會大幅下降。因此，我設(shè)置了一個稱為魔法配置的配置變量，將線程數(shù)設(shè)置為1，很多人可能一直在生產(chǎn)環(huán)境中使用這個配置。有一個稍微更好的啟發(fā)方法，即將物理核心數(shù)除以工作線程的數(shù)量，這會給你一個稍微更好的結(jié)果。通常你能觀察到，但問題是，隨著核心數(shù)量的增加，你會注意到性能并不呈線性增長。所以我非常高興我們團(tuán)隊(duì)有Intel的Minjin Cho加入。她注意到了一個問題，我們的線程在CPU上的兩個插槽間遷移。因此，如果一個核心正在執(zhí)行一些工作。然后它會移動到另一個核心，然后又移動回來。所以最終的結(jié)果就是你有一個進(jìn)程，它基本上會不斷地丟失緩存，導(dǎo)致性能大幅度下降。我說的是像5到10倍的時間慢下來。

所以關(guān)鍵在于當(dāng)我們啟動Python進(jìn)程時，我們希望確保它們與特定的進(jìn)程有一定的關(guān)聯(lián)性。這是我們默認(rèn)啟用并且Torch服務(wù)作為一個環(huán)境變量所實(shí)現(xiàn)的。但你所希望看到的是，有一個忙碌的socket塊，而另一個則沒有工作。這是HTOP中你希望看到的良好視圖，以確保CPU推斷是快速的。

這很棒，因?yàn)楸热鏝avver就在使用這些優(yōu)化。他們在博客中提到每年節(jié)省了340k，并且通過使用這樣的技術(shù)，他們的服務(wù)器成本也減少了。

Naver:
https://pytorch.org/blog/ml-model-server-re
source-saving/
PyTorchGeometric:
https://pytorch-geometric.readthedocs.io/en/
latest/advanced/cpuaffinity.html

一、你知道的，有一個隱藏的技巧。嗯，PyTorch Geometric也談到了類似的優(yōu)化方法應(yīng)用于他們的GNN工作負(fù)載中。所以這是我強(qiáng)烈推薦的一點(diǎn)。我們還討論了很多關(guān)于主動測量模型性能的事情，最近AWS添加了一個新的指標(biāo)API。你可以在你的Python代碼中添加一些儀器，指定這是什么樣的指標(biāo)？是一個計(jì)數(shù)器嗎？是一個量規(guī)嗎？然后你就可以得到一個看起來很酷的科幻儀表盤。

這是一個來自沃爾瑪搜索團(tuán)隊(duì)的儀表盤示例，他們一直在使用TorchServe來擴(kuò)展他們的搜索，并且效果很好。這很酷，因?yàn)槲譅柆斒鞘澜缟献畲蟮?a target="_blank">公司之一，他們是世界上最大的雇主。對于他們來說，使用TorchServe和Python進(jìn)行擴(kuò)展工作真的很不錯。

我很高興地看到TorchServe運(yùn)行得非常順利。所以，現(xiàn)在來做一個總結(jié)，我感到很幸運(yùn)的是，TorchServe現(xiàn)在成為了SageMaker、Vertex、MLflow和Kubeflow這些平臺上服務(wù)PyTorch模型的默認(rèn)方法。它已經(jīng)成功地為沃爾瑪、Navver和亞馬遜廣告等工作負(fù)載提供服務(wù)。雖然我站在這里講演，但這真的是META、AWS和最近的英特爾團(tuán)隊(duì)之間的眾多優(yōu)秀人士的合作成果。謝謝。

審核編輯：湯梓紅