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

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

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

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

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

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

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

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

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

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

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

modelbt=BetterTransformer.transform(model
NowforGPUandCPU!

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

TORCHINDUCTORCACHEDIR
TORCHINDUCTORFXGRAPHCACHE
Makesuretocopytheseovertoreduce
yourwarmstarttimes

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

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

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

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

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

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

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

這很棒，因?yàn)楸热鏝avver就在使用這些優(yōu)化。他們?cè)诓┛椭刑岬矫磕旯?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

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

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

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

審核編輯：湯梓紅