給每一個用戶建立一個獨有 ML 模型，這是一種怎樣的體驗？

時間 2020-08-11

標籤每一個用戶建立一個獨有模型這是一種怎樣體驗简体版

原文原文鏈接

根據業務需求建立一種或幾種 ML 模型，而後根據模型的推理得到業務所需的決策依據，這種作法想必你們都很熟悉了。然而具體到特定應用場景，這種作法可能會存在一些弊端。html

舉例來講，若是咱們須要經過一個 ML 模型來預測某個地區的將來市場趨勢，那麼只要模型自己足夠優秀，而且有必要的數據，這個目標仍是很好實現的。但若是咱們但願經過 ML 模型來學習用戶在線聽歌時候的喜愛，而後給用戶提供個性化的音樂推薦，那麼爲全部用戶使用同一個模型，很明顯，並不能得到最好的結果。python

此時的問題就變成了：咱們可否不要基於羣組或細分市場來創建模型，而是基於個體用戶的數據來創建，以便得到更準確的結果。這也是能夠作到的，但必須注意成本問題。git

雖然構建自定義機器學習模型較好地提升了單個使用案例推理的準確性，但缺點在於部署模型的成本大幅提升，並且在生產中管理如此多的模型很困難。當咱們不用同時訪問全部模型，但仍然須要能夠隨時使用這些模型時，這些問題變得尤其突出。Amazon SageMaker 的多模型終端節點能夠解決這些痛點，而且能爲企業提供一個可擴展但經濟高效的解決方案用於部署多個機器學習模型。github

Amazon SageMaker 是一項模塊化的端到端服務，可用於輕鬆地大規模構建、訓練和部署機器學習模型。在訓練獲得一個機器學習模型後，咱們能夠將它部署到徹底託管的 Amazon SageMaker 終端節點上，該終端節點能夠實時提供低延遲的推理。而在多模型終端節點功能的幫助下，咱們能夠在一個公共終端節點中部署多個模型，並經過一個使用多模型終端節點的服務容器向外提供服務。如此一來，即可以輕鬆地大規模管理機器學習模型的部署，並經過提升終端節點及其下層的基礎計算實例的使用率來下降模型部署成本。緩存

下文將介紹 Amazon SageMaker 多模型終端節點，並演示如何應用這項新功能經過 XGBoost 來預測各個細分市場的房屋價格。下文演示了在多模型終端節點上同時部署10個模型，也演示了在10個獨立的終端節點上分別部署10個模型，並對這兩種使用情形進行了對比。以下圖所示，前者相比後者每個月節省了3000美圓的成本。安全

多模型終端節點能夠輕鬆擴展到數百至數千個模型。下文還將討論終端節點配置和監控須要考慮的因素，並將重點介紹在1000個模型規模的部署樣例中，如何節省超過90%的成本。服務器

Amazon SageMaker 多模型終端節點概述

Amazon SageMaker 可以使咱們跨多個可用區將模型一鍵式部署到自動擴展的 Amazon 機器學習實例上，以實現高冗餘性。咱們只需指定實例類型及所需的最大數和最小值，剩下的部分都將由 Amazon SageMaker 解決。架構

Amazon SageMaker 將啓動實例、部署模型並設置安全的 HTTPS 終端節點。應用程序須要包含到此終端節點的 API 調用，以實現低延遲和高吞吐量推理。此架構可以使咱們在幾分鐘內將新模型集成到應用程序中，由於模型更改再也不須要應用程序代碼同步更改。Amazon SageMaker 是徹底託管的服務，可代爲管理生產計算基礎設施，包括執行運行情況檢查、應用安全補丁及執行其餘的常規維護，這一切均可以使用內置的 Amazon CloudWatch 監控和日誌記錄來進行。框架

Amazon SageMaker 多模型終端節點可以使咱們在一個終端節點中部署多個通過訓練的模型，並使用一個服務容器向外提供服務。多模型終端節點徹底託管，具備高可用性，可實時提供推理服務。咱們能夠在推理請求中經過參數設置目標模型名稱來輕鬆調用指定模型。若是擁有大量可經過共享服務容器提供服務，且不須要同時訪問全部模型的類似模型，該項功能是不二之選。例如，法律應用程序可能須要全面覆蓋一組普遍的監管轄區，若是有大量不常常訪問的模型，那麼一個多模型終端節點就能夠高效的提供服務，而且顯著的下降成本。機器學習

要在 Amazon SageMaker 中建立多模型終端節點，請選擇多模型選項，提供推理服務容器鏡像的路徑，而後提供用於存儲訓練好的模型構件的 Amazon S3 前綴。只要模型所有使用相同前綴，便可按任何方式在 S3 中組織它們。調用多模型終端節點時，使用 InvokeEndpoint 的新 TargetModel 參數提供特定模型的相對路徑。要在多模型終端節點中添加模型，只需將新訓練的模型構件存儲在與該終端節點關聯的 S3 前綴下，而後該模型將當即可用於調用。要更新已在使用的模型，用新名稱命名模型，並添加到 S3 中，而後用新模型名稱調用終端節點。要中止使用在多模型終端節點上部署的模型，請中止調用該模型，並將它從 S3 中刪除。

Amazon SageMaker 多模型終端節點將在調用時從 S3 中動態加載模型，而不是在建立終端節點時將全部模型從 S3 下載到容器中。所以，初次調用模型的推理延遲可能高於後續推理，後續推理將以低延遲返回調用。若是模型在調用時已加載到容器中，則能夠跳過下載步驟，模型推理將以低延遲返回調用。例如，假設有一個一天只使用幾回的模型，它將根據須要自動加載；而頻繁訪問的模型將保留在內存中，並持續以低延遲返回調用。下圖顯示了從 S3 動態加載到多模型終端節點中的模型。

使用 Amazon SageMaker 多模型終端節點預測房價

下文基於房屋訂價領域帶領你們逐步瞭解多模型終端節點的使用場景示例。有關更多信息，請參閱 GitHub 上的完整工做筆記本。它使用生成的合成數據讓咱們可使用任意數量的模型進行實驗。每一個城市都使用隨機生成的特徵在必定數量的房子上進行了模型訓練。

該實驗包含如下步驟：

使訓練好的模型可用於多模型終端節點
準備容器
建立和部署多模型終端節點
調用多模型終端節點
動態加載新模型

使訓練好的模型可用於多模型終端節點

咱們能夠在不對模型或模型訓練過程進行任何更改的狀況下利用多模型部署，並繼續生成將要保存在 S3 中的模型構件（如model.tar.gz文件）。
在示例筆記本中，將並行訓練一組模型，且每一個訓練做業的模型構件都將複製到S3中指定的位置。訓練並複製一組模型後，文件夾將擁有如下內容：

2019-11-15 14:40:04   11.2 KiB Chicago_IL.tar.gz
  2019-11-15 14:40:04   11.9 KiB Houston_TX.tar.gz
  2019-11-15 14:40:04   11.4 KiB LosAngeles_CA.tar.gz
 
  對象總數：3
     總大小：34.5 KiB

每一個文件都根據原有的model.tar.gz名稱進行重命名，以使每一個模型都具備惟一的名稱。發送請求作預測時，可經過名稱指定目標模型。

準備容器

要使用 Amazon SageMaker 多模型終端節點，可使用通用型多模型服務器功能在 GitHub 上構建 Docker 容器。該容器是一個靈活易用的框架，可託管基於任何框架的機器學習模型並對外提供服務。XGBoost 示例筆記本演示瞭如何將開源 Amazon SageMaker XGBoost 容器用做基礎來構建容器。

建立多模型終端節點

下一步是建立多模型終端節點，該終端節點知道如何在S3中查找目標模型。本文使用 boto3（適用於 Python 的 AWS 開發工具包）建立模型元數據。將其模式設置爲 MultiModel 並告知 Amazon SageMaker 包含全部模型構件的 S3 文件夾的位置，而不是指定某個模型。

此外，指定模型用於推理的框架鏡像。本文使用在上一步構建的 XGBoost 容器。咱們能夠在爲該框架配置的多模型終端節點中託管使用相同框架構建的模型。請參閱如下代碼來建立模型實體：

container = {
   'Image':        XGB_CONTAINER,
   'ModelDataUrl': ‘s3://my-bucket/path/to/artifacts/’,
   'Mode':         'MultiModel'
  }
 
  response = sm_client.create_model(
              ModelName        = ‘my-multi-model-name’,
              ExecutionRoleArn = role,
              Containers       = [container])

有了適當的模型定義後，還須要一個終端節點配置，該配置引用上面建立的模型實體名稱。請參閱如下代碼：

  response = sm_client.create_endpoint_config(
    EndpointConfigName = ‘my-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])

最後，使用如下代碼建立終端節點：

response = sm_client.create_endpoint(
              EndpointName       = ‘my-endpoint’,
              EndpointConfigName = ‘my-epc’)

調用多模型終端節點

要調用多模型終端節點，只須要傳遞一個新參數，該參數表示要調用的目標模型。如下示例代碼爲使用boto3的預測請求：

  response = runtime_sm_client.invoke_endpoint(
                        EndpointName = ’my-endpoint’,
                        ContentType  = 'text/csv',
                        TargetModel  = ’Houston_TX.tar.gz’,
                        Body         = body)

針對單一終端節點後託管的多個目標模型，示例筆記本經過一組隨機調用進行迭代。它顯示了終端節點如何按需動態加載目標模型。請參閱如下輸出：

Using model Houston_TX.tar.gz to predict price of this house：
 
[1994, 3188, 5, 1.5, 1.62, 3]
 
486551.41 USD，took 1375 ms
 
Using model Chicago_IL.tar.gz to predict price of this house：
 
[1990, 3047, 5, 1.0, 1.11, 2]
 
428404.88 USD，took 850 ms
 
Using model Chicago_IL.tar.gz to predict price of this house：
 
[1995, 3514, 6, 2.0, 0.79, 2]
 
512149.66 USD，took 17 ms
 
Using model Houston_TX.tar.gz to predict price of this house：
 
[1978, 2973, 2, 1.5, 0.99, 1]
 
328904.12 USD，took 17 ms

因爲要從 S3 下載特定模型並將其加載到內存中，針對該模型完成第一次請求的時間有更多延遲（稱爲冷啓動）。後續，由於該模型已加載完成，調用不會產生額外的開銷。

動態加載新模型到現有終端節點中

將新模型部署到現有的多模型終端節點中很簡單。在終端節點已在運行的狀況下，將一組新的模型構件複製到早前設置的相同的 S3 位置，而後客戶端應用程序能夠自由地請求來自於該目標模型的預測，剩餘工做則交由 Amazon SageMaker 處理。下面的示例代碼爲紐約建立了一個能夠當即投入使用的新模型：

!aws s3 cp NewYork_NY.tar.gz s3://my-bucket/path/to/artifacts/
 
  response = runtime_sm_client.invoke_endpoint(
                        EndpointName=endpoint_name,
                        ContentType='text/csv',
                        TargetModel=’NewYork_NY.tar.gz’,
                        Body=body)

使用多模型終端節點，咱們無需進行完整的終端節點更新，只需部署新模型（即一個 S3 副本），而且能夠避免爲每一個新模型單獨設置終端節點的成本開銷。

爲大量模型擴展多模型終端節點

隨着捆綁模型的規模增大，Amazon SageMaker 多模型終端節點的好處也隨之增長。使用一個終端節點託管兩個模型時，能夠節省成本，對於具備數百個甚至數千個模型的使用案例，節省幅度會更高。

例如，假設有1000個小型XGBoost模型，每一個模型自己均可以由ml.c5.large終端節點（4GiB內存）提供服務，在 us-east-1 每實例小時的成本爲0.119USD。若是爲所有1000個模型各自提供終端節點，每個月將花費171,360 USD。若是使用 Amazon SageMaker 多模型終端節點，使用ml.r5.2xlarge 實例的單個終端節點（64GiB內存）便可以託管所有1000個模型。這能夠將生產推理成本下降99%，使每月的成本僅爲1,017 USD。下表總結了本示例中單個終端節點與多模型終端節點之間的區別。請注意，對每一個目標模型進行冷啓動調用後，多模型案例實現了7毫秒的第90個百分位延遲。假定終端節點配置爲您的目標模型提供了足夠的內存，全部模型都加載後的穩態調用延遲將與單模型終端節點的延遲類似。

使用 Amazon CloudWatch 指標監控多模型終端節點

爲了在價格與性能之間進行權衡，咱們要使用本身應用程序的模型和表明性流量對多模型終端節點進行測試。Amazon SageMaker在CloudWatch中爲多模型終端節點提供額外的指標，以便肯定終端節點的使用狀況和緩存命中率，並對終端節點進行優化。指標以下：

ModelLoadingWaitTime – 調用請求等待目標模型被下載或加載以執行推理的時間間隔。
ModelUnloadingTime – 經過容器的 UnloadModel API 調用卸載模型所須要的時間間隔。
ModelDownloadingTime – 從 S3 中下載模型所須要的時間間隔。
ModelLoadingTime – 經過容器的 LoadModel API 調用加載模型所須要的時間間隔。
ModelCacheHit – 發送至已加載模型的終端節點的 InvokeEndpoint請求數量。取平均統計值將顯示模型已加載的請求的比率。
LoadedModelCount – 已加載到終端節點的容器中的模型數量。每一個實例都會發出該指標。1分鐘內的平均（Average）統計量將顯示每一個實例已加載的模型平均數量，總（Sum）統計量顯示在終端節點的全部實例中加載的模型總數量。由於咱們能夠將一個模型加載到終端節點的多個容器中，此指標跟蹤的模型不必定是惟一的。

咱們可使用 CloudWatch 圖表幫助持續做出決策，選擇出最佳的實例類型、實例計數和某個特定終端節點應託管的模型數量。例如，下面的圖表顯示加載的模型數量在不斷增長，緩存命中率也在相應增長。

在本例中，緩存命中率的起始值爲0，當時沒有加載模型。隨着加載的模型數量增長，緩存命中率最終達到100%。

將終端節點配置與使用案例匹配

爲 Amazon SageMaker 終端節點選擇適當的終端節點配置，尤爲是實例類型和實例數量，這在很大程度上取決於特定使用案例要求。對於多模型終端節點也是如此。咱們能夠在內存中保存的模型數量取決於終端節點配置（如實例類型和計數）、模型配置文件（如模型大小和模型延遲）及推理流量模式。咱們應該綜合考慮上述因素來配置多模型終端節點並適當調整實例的大小，而且還應該爲終端節點設置自動縮放。

Amazon SageMaker 多模型終端節點徹底支持自動縮放。調用速率用於觸發自動縮放事件，該速率基於終端節點服務之完整模型集的聚合預測集。
有些情形下，咱們能夠經過選擇不能同時在內存中保存全部目標模型的實例類型來下降成本。Amazon SageMaker 將在內存用完時動態卸載模型，從而爲新目標模型騰出空間。對於不常常請求的模型，動態加載能夠節省成本，延遲尚可接受。對延遲敏感的情形，可能須要選擇更大的實例類型或更多實例。對於特定使用案例，預先投入時間使用多模型終端節點進行測試和分析，將有助於優化成本，同時知足應用程序的性能需求。

結論

Amazon SageMaker 多模型終端節點可幫助咱們以儘量低的成本提供高性能機器學習解決方案。經過將一組相似的模型捆綁到單個終端節點後面，能夠顯著下降推理成本，咱們可使用單個共享服務容器提供服務。一樣地，Amazon SageMaker 提供的託管 Spot 訓練以幫助下降訓練成本，並針對深度學習工做負載爲 Amazon Elastic Inference 提供集成支持。最重要的是，它們將助力於 Amazon SageMaker 改進生產力，並有助於提升機器學習團隊的影響力。