編者按：模型部署是AI開發生產流程中的重要步驟。對於許多組織而言，選擇最佳的模型部署策略以擴充套件到生產級系統，都是一項複雜且具有挑戰的工作。
今天IDP將和大家一同，跟隨Yashawi Nayak，全面瞭解模型部署策略。
“這篇文章是為那些想了解ML模型如何在生產中部署以及在部署這些模型時可以使用什麼策略的人準備的。本文將說明部署ML模型的基本方法，可以採取的不同部署策略，以及這些策略一般在哪裡實施。每個資料科學團隊都會有一套不同的要求，所以要慎重考慮。”
以下是譯文，Enjoy!
作者 | Yashawi Nayak
編譯 | 嶽揚
一、瞭解機器學習模型的部署
與部署軟體或應用程式相比，模型部署是不一樣的。一個簡單的ML模型生命週期會有如下這些階段，如範圍界定、資料收集、資料工程、模型訓練、模型驗證、部署和監控。
ML生命週期（圖片由本文作者提供）
當我們在部署ML模型時，需要考慮一些因素，比如：
- 模型的大小和打包——模型的大小對我們如何打包有巨大的影響。較小的模型通常可以被放置在FastAPI伺服器中，並在Docker容器中進行封裝。然而，較大的模型可能需要在部署期間載入——從遠端儲存中拉取，並透過模型伺服器（如TFServing或TorchServer）執行。
- 模型的再訓練和版本維護——對模型的再訓練頻率影響著部署策略。你是否經常需要比較你的模型效能？你在生產環境中需要多長時間才能更新你的模型？你會在生產環境中維護你的模型的不同版本嗎？
- 流量和請求路由——根據流量和模型的型別決定實時推理或批次模型部署。你想將多少流量分流到每個版本的模型？有多少使用者會有機會訪問某一個模型版本？
- 資料和概念漂移——隨著時間的推移，現實世界的資料在不斷變化，這可能不會被反映在模型中。比如說，購買力與工資的關係如何，可能每年或每月都在變化。或者在新冠疫情期間，消費者的購買模式如何變化。但模型大多依賴於歷史資料，這影響到我們的部署架構設計：我們應該重新訓練和重新部署嗎？我們是否應該暫時只對模型進行重新訓練和階段性的調整？這個因素在資料科學團隊的長期部署戰略中發揮較大的作用。
對於這些因素，我們有模型部署的六個常見策略。這些策略主要是從DevOps和UX方法論中借用的，在ML場景中也同樣適用。
通常，在技術層面上，生產環境中的模型部署涉及到API端點閘道器、負載平衡器、虛擬機器叢集、服務層、某種形式的永續性資料儲存和模型本身。
通用模型的部署（圖片由本文作者提供）
部署策略通常在負載均衡器和服務層面進行配置，主要是配置路由和入口規則。
以一個動物識別和分類系統為例。從一個簡單的貓狗分類器開始，這將是模型的首個版本。假設我們已經訓練了一個模型的副本來識別考拉，所以第二個版本是一個貓狗考拉分類器。我們將如何部署模型的最新版本？
模型版本 (圖片由本文作者提供)
二、模型部署策略
2.1 Big Bang：重新部署
WHAT：這種形式的部署是一種“從頭開始”的部署方式。你必須移除現有的部署，才能部署新的。
WHERE：在開發環境中一般是可以接受的。可以用不同的配置重新建立部署，次數不限。通常情況
下，部署管道會移除現有的資源，並在其位置上建立新的版本。
重新部署 (圖片由本文作者提供)
這種部署方式會造成到一定時間的中斷。現在這樣的機器學習開發的速度是不可接受的。在我們的例子中，我們用版本2替換版本1，這過程中就會替換掉所有相關的基礎設施和庫配置。
2.2 滾動更新策略
WHAT：滾動更新策略是逐一更新模型/應用程式的所有例項。假設你目前有4個正在執行應用程式的pod，然後使用滾動更新策略部署新版本的模型，這樣一個接一個的pod會被替換成新的。這種方法造成服務中斷的時間為零。
WHERE：當你想用一個新的版本快速更新你的整個模型集時會很有用。使用這種策略也允許你在需要時回滾到舊版本。該策略主要用於測試環境，當團隊需要測試新版本的模型時。
滾動更新策略 (圖片由本文作者提供)
一般來說，這不會是生產系統中的唯一實現方法，除非你僅在整個系統中部署一個特定版本的模型。在上述例子中，我們只替換了模型應用pod，保持其他基礎設施原樣不動。
2.3 ?Blue/Green?部署
WHAT：這種部署形式本質上是一種伺服器交換的部署形式。在這種部署形式中，有兩個相同的系統可用，使用者的請求被轉到其中一個系統，而更新則在另一個系統上完成。一旦更新透過測試和驗證，使用者的請求就會被路由到較新的系統，其實本質上是把舊的模型換成新的。
WHERE：主要是在普通應用程式或網路應用場景中使用該種部署方式，也可以用於模型部署，在批處理和實時推理部署中都可以使用。由於該模式是將負載均衡指向一組不同的機器，因此造成服務中斷的時間基本上為零。
藍綠部署（圖片由本文作者提供）
如你所見，我們用新的模型版本建立一個新的相同系統，然後只需將流量切換到新的系統。然而，我們需要把維護兩個相同的基礎設施系統的成本考慮進去。是否選擇這種方法取決於基礎設施的規模和承受能力。
2.4 ?金絲雀（Canary）部署
WHAT：在Canary部署中，我們將更新後的模型部署到我們現有的系統中，並給部分使用者推送新版本模型。這意味著我們的一小部分使用者將能夠訪問最新的模型，其餘的使用者仍將使用舊的版本。這種部署方式主要是用來測試新版本的執行情況。通常，一小部分使用者（大約5%-30%）會接觸到最新版本，因為這有助於ML工程師和開發人員瞭解哪些功能可能需要推出，哪些需要重構。
WHERE：當團隊需要了解新模型的效能時，通常會在模擬環境（staging）和生產環境（production）中進行Canary部署。這可以透過兩種方式進行：金絲雀滾動部署金絲雀並行部署
金絲雀部署（左側為滾動部署，右側為並行部署)
滾動部署（Rolling Deployment）將最新模型放到同一叢集內的少量例項上，並將一組使用者請求傳送到這些pod。
並行部署（Parallel Deployment）在現有例項旁邊建立了一組較小的新例項，並將一定比例的使用者請求傳送到這些pod上。
使用者的請求通常透過頭資訊進行標記，然後透過負載均衡器的配置，將其傳送到相應的目的地。這意味著有一組使用者被選擇來檢視最新的模型，而且同一組使用者每次都會看到最新模型。使用者請求不會被隨機地傳送到新的pod。這說明Canary部署具有會話親和性。
在上文的貓狗考拉分類器例子中，假設選定10%的使用者可以向模型提交影像，這10%的使用者提交的影像將用考拉選項進行分類，其餘使用者只能使用貓狗分類器。
2.5 A/B測試
WHAT：這種方法在使用者體驗研究中使用最多，可以用來評估使用者喜歡什麼。在機器學習場景中，我們可以使用這種部署方式來了解使用者喜歡什麼，哪種模式可能對他們更有效。
WHERE：全球範圍內的推薦系統部署中大多采用此種部署模式。根據人口統計學，例如一個線上購物網站採用了兩種不同型別的推薦引擎，一個服務於一般的使用者，一個服務於特定的地理區域——有更多的母語支援。工程師們可以在一段時間後確定哪種引擎能給使用者帶來更順暢的體驗。
為什麼我們需要A/B測試 (圖片來自本文作者)
回到我們舉的那個例子中，假設我們在全球範圍內部署了貓狗分類器，但我們在澳大利亞-太平洋島嶼地區部署了版本1和版本2，使用者請求有可能被隨機傳送到版本2。然後重新訓練版本2以識別更多的當地動物品種並部署它，你認為澳大利亞的人們會喜歡哪個版本？
Note：那麼Canary和A/B測試之間有什麼區別？
主要的區別是：
- Canary是基於會話親和性（來自客戶端的請求總是路由到同一個伺服器進行處理）的，大多數情況下，同一組使用者將看到最新的模型，而在A/B測試中，使用者被隨機傳送到不同的版本。
- Canary是專門用來測試應用程式或模型是否按預期工作的，而A/B更多的是為了瞭解使用者體驗。
- Canary的使用者比例從未超過50%，很小比例的使用者請求（理想情況下低於35%）被髮送到較新的測試版本。
2.6 影子部署（Shadow）?
WHAT：影子部署用於生產環境中，用生產資料測試最新版本的模型。生成使用者請求的副本併傳送給新模型，但現有的系統也會同時給出響應。
WHERE：假如有一個高流量的生產系統，為了驗證新模型如何處理生產資料和流量負載，可以用影子模式部署新模型。每次向模型傳送請求時，都會向更新的版本傳送一個請求副本。只由現有的模型傳送響應，而新模型不傳送響應。
影子部署 (圖片來自本文作者)
影子部署主要是用來了解生產負荷、流量和模型效能，其主要用於高容量預測服務。系統架構和設計的複雜性隨著使用這種部署方式而增加。我們必須有包括服務網格、請求路由和基於用例的複雜資料庫設計。
在本文舉的例子中，我們可能會將版本2使用影子部署，以瞭解版本2如何處理生產負載，也瞭解從哪裡得到更多的考拉分類請求?或任何特定型別的模型請求模式。
現在我們對如何在各種情況下部署模型有了基本瞭解。根據不同的要求，資料科學團隊可能需要使用這些方法的組合，這需要根據具體的業務場景來決定。
END
IDP-Inspiration是IDP常設專欄。在這裡，我們會分享國內外資料科學家和演算法工程師在實戰中總結的寶貴經驗，為想要從事資料科學和AI開發生產相關工作的小夥伴提供借鑑！
AI相關技術投稿，請聯絡 Alex@baihai.ai