Zendesk 是一家 SaaS 公司，該公司以簡單為本，專注於開發面向所有人的支援、銷售和客戶參與軟體。透過幫助全球超過 17 萬家公司高效地為數億客戶提供服務，該公司得以蓬勃發展。Zendcaesk 的機器學習團隊負責提升客戶體驗團隊，使其實現最佳績效。透過將資料和人員的力量結合起來，Zendesk 開發出了多種智慧產品，這些產品可以自動化手動工作，從而提高客戶的工作效率。
自 2015 年以來，Zendesk 一直在構件機器學習產品，包括 Answer Bot、滿意度預測（Satisfaction Prediction）、內容提示（Content Cues）、建議宏（Suggested Macros）等。在過去的幾年中，隨著深度學習（尤其是 NLP）的發展，他們看到了很多自動化工作流的機會，並幫助座席使用 Zendesk 解決方案為客戶提供支援。Zendesk 目前使用 TensorFlow 和 PyTorch 構建深度學習模型。
| 亞馬遜雲科技開發者社群為開發者們提供全球的開發技術資源。這裡有技術文件、開發案例、技術專欄、培訓影片、活動與競賽等。幫助中國開發者對接世界最前沿技術，觀點，和專案，並將中國優秀開發者或技術推薦給全球雲社群。如果你還沒有關注/收藏，看到這裡請一定不要匆匆劃過，點這裡讓它成為你的技術寶庫！ |
像 Zendesk 這樣的客戶已經在 Amazon Web Services（Amazon）上成功建立了大規模的軟體即服務（SaaS, Software as a Service）業務。成功的 SaaS 業務模式的一個關鍵驅動因素是能夠在應用程式和基礎設施中應用多租戶。這將提高成本效率和運維效率，因為應用程式只需構建一次，但可供多次使用，並且可以共享基礎設施。我們發現許多客戶在 Amazon 的堆疊的所有層（從計算、儲存、資料庫到聯網）上構建了安全、經濟高效的多租戶系統，並且目前我們發現客戶需要將該系統應用於機器學習（ML，Machine Learning）。
在模型重用和超個性化之間做出艱難的權衡
SaaS 業務的多租戶通常意味著將在多個使用者（SaaS 客戶）之間重用單個應用程式。這既實現了成本效率，又降低了運營開銷。不過，有時需要對機器學習模型進行個性化設定，使其達到高度的特異性（超個性化），才能做出準確的預測。這意味著，如果模型具有特異性，則“一次構建，多次使用” 的 SaaS 正規化不能總是應用於 ML。以客戶支援平臺的使用案例為例。使用者在支援票證中包含的語言會有所不同，具體取決於是拼車問題（“乘車時間太長”）還是服裝購買問題（“洗後變色”）。在這個使用案例中，要提高預測最佳補救措施的準確性，可能需要在特定於業務領域或垂直行業的資料集上訓練自然語言處理（NLP，Natural Language Processing）模型。Zendesk 在其解決方案中嘗試利用 ML 時就遇到了這一挑戰。他們需要建立數千個高度定製的 ML 模型，每個模型都是為特定客戶量身定製的。為了經濟高效地應對部署數千個模型這一挑戰，Zendesk 轉而使用 Amazon SageMaker。
在本博文中，我們將說明如何使用 Amazon SageMaker（一種完全託管式機器學習服務）的一些新功能來構建多租戶 ML 推理功能。我們還分享了一個實際例子，說明 Zendesk 如何透過在 ML 模型中支援超個性化與使用 SageMaker 多模型端點（MME，Multi-Model Endpoint）來經濟高效地共用基礎設施之間部署一個良好的媒介，成功實現相同的結果。
SageMaker 多模型端點
藉助 SageMaker 多模型端點，您可以在可能包含一個或多個例項的單個推理端點後面部署多個模型。每個例項均設計為載入和支援多個模型，直至達到其記憶體和 CPU 容量。利用此架構，SaaS 業務可以中斷託管多個模型的成本的線性增長情況，並實現與應用程式堆疊中的其他位置應用的多租戶模式一致的基礎設施的重用。
下圖展示了 SageMaker 多模型端點的架構。
SageMaker 多模型端點在被呼叫時會從 Amazon Simple Storage Service（Amazon S3）動態載入模型，而不是在首次建立端點時下載所有模型。因此，初次呼叫模型的推理延遲可能高於後續推理，這些後續推理以低延遲完成。如果模型在呼叫時已載入到容器中，則可以跳過下載步驟，模型將以低延遲返回推理。例如，假設您有一個一天只使用幾次的模型。它根據需要自動載入，而頻繁訪問的模型則保留的記憶體中，並以一貫的低延遲呼叫。
讓我們仔細看看 Zendesk 如何使用 SageMaker MME 透過其建議宏（Suggested Macros）ML 功能來實現經濟高效的超大規模 ML 部署。
為什麼 Zendesk 構建超個性化模型
Zendesk 的客戶遍佈全球不同的垂直行業，使用不同的支援票證語義。因此，為了向客戶提供最出色的服務，他們通常必須構建個性化模型，這些模型將根據客戶特定的支援票證資料進行訓練，從而正確識別意圖、宏等。
2021 年 10 月，他們釋出了一項新的 NLP ML 功能，即建議宏（Suggested Macros），此功能根據數千個客戶特定的模型預測來推薦宏（預定義的操作）。Zendesk 的 ML 團隊構建了一個基於 TensorFlow 的 NLP 分類器模型，該模型已根據每個客戶以前的票證內容和宏歷史記錄進行訓練。利用這些模型，可以在座席檢視票證時建議宏預測（如以下螢幕截圖所示），這可幫助座席快速為客戶提供服務。由於宏特定於客戶，因此 Zendesk 需要客戶特定的模型來提供準確的預測。
Zendesk 的建議宏（Suggested Macros）揭秘
建議宏（Suggested Macros）模型是基於 NLP 的神經網路，大小約為 7 – 15 MB。主要挑戰是透過經濟高效、可靠且可擴充套件的解決方案將其中的數千個模型投入生產。
每個模型都有不同的流量模式，每秒最少有兩個請求，峰值為每秒數百個請求，當模型在記憶體中可用時，每天提供數百萬個預測，並且模型延遲約為 100 毫秒。SageMaker 端點部署在多個 Amazon 區域中，每個端點每分鐘處理數千個請求。
SageMaker 能夠在單個端點上託管多個模型，與為每個客戶部署單一模型端點相比，它幫助 Zendesk 減少了部署開銷並建立了一個經濟高效的解決方案。這裡的權衡方式是減少對每個模型管理的控制；而這正是 Zendesk 與 Amazon 合作以改進多模型端點的領域。
SageMaker 的多模型功能之一是延遲載入模型，即模型在首次被呼叫時就載入到記憶體中。這是為了最佳化記憶體利用率；但它會導致首次載入時出現響應時間峰值，可以將此情況視為冷啟動問題。對於建議宏（Suggested Macros）來說，這是一個難題；但是，Zendesk 解決了這個難題，方式是基於 SageMaker 端點預置實施預載入功能，從而在提供生產流量之前將模型載入到記憶體中。其次，MME 會從記憶體中解除安裝不常用的模型，因此，為了在所有模型上實現一致的低延遲，並避免“嘈雜的鄰居”影響其他不太活躍的模型，Zendesk 正在與 Amazon 合作來增加新功能（在本博文到後面將討論）以實現更明確的每模型管理。另外，作為一個臨時解決方案，Zendesk 合理精簡了 MME 例項集，以最大限度地減少過量模型解除安裝。這樣一來，Zendesk 便能夠以低延遲（約 100 毫秒）為所有客戶提供預測，與專用端點相比，仍能節省 90% 的成本。
在合理精簡的 MME 上，Zendesk 在負載測試期間觀察到，在 MME 後面有較多的小型例項（偏向於水平擴充套件）優於擁有較少的大型記憶體例項（垂直擴充套件）。Zendesk 發現，無法順利地在單個大型記憶體例項上打包太多模型（超過 500 個 TensorFlow 模型），因為記憶體並不是例項上唯一可能成為瓶頸的資源。更具體地說，他們發現 TensorFlow 為每個模型產生了多個執行緒（例項 vCPU 總數的 3 倍），因此，在單個例項上載入超過 500 個模型會導致在例項上產生的執行緒的最大數目違反核心級別限制。有關使用更少的大型例項的另一個問題會是 Zendesk 在 MME 後面的某些例項上遇到限制（作為一種安全機制）是出現，因為每秒唯一模型呼叫速率超過了多模型伺服器（MMS，Multi Model Server）可以在單個例項上安全處理而不關閉例項的速率。這是透過使用更多小型例項解決的另一個問題。
從作為任何生產應用程式的關鍵組成部分的可觀察性角度來看，Amazon CloudWatch 指標（例如，呼叫、CPU、記憶體利用率）和特定於多模型的指標（例如，記憶體中載入的模型、模型載入時間、模型載入等待時間和模型快取命中）都能提供有用的資訊。具體來說，模型延遲細分有助於 Zendesk 瞭解冷啟動問題及其影響。
MME 自動擴充套件功能揭秘
每個多模型端點後面都有模型託管例項，如下圖所示。這些例項根據模型的流量模式在記憶體中載入和移出多個模型。
SageMaker 仍將模型的推理請求路由到已載入模型的例項，以便從快取的模型副本中處理請求（參見下圖，其中比較了第一個預測請求的請求路徑與快取的預測請求路徑）。不過，如果模型收到許多呼叫請求，並且多模型端點還有其他例項，則 SageMaker 會將一些請求路由到另一個例項以適應增加的請求。要利用 SageMaker 中的自動模型擴充套件功能，請確保將設定例項自動擴充套件以預置額外的例項容量。使用自定義引數或每分鐘呼叫次數（推薦）設定端點級別擴充套件策略，以便向端點例項集新增更多例項。
最適合 MME 的使用案例
SageMaker 多模型端點非常適合託管大量類似的模型，您可以透過共享服務容器提供這些模型，並且不需要同時訪問所有模型。MME 最適合大小和呼叫延遲類似的模型。模型大小發生一些變化是可以接受的；例如，Zendesk 模型的大小在 10-50 Mb 之間變化是可以接受的，但大小的變化超過了 10 倍、50 倍或 100 倍就不合適了。大型模型可能會導致小型模型的載入和解除安裝次數更多，以容納足夠的記憶體空間，這可能會導致端點上的延遲增加。大型模型的效能特性差異也可能會不均勻地消耗 CPU 等資源，從而影響例項上的其他模型。
MME 也為使用相同 ML 框架的共同託管模型而設計，因為它們使用共享容器來載入多個模型。因此，如果您的模型例項集中混合了 ML 框架（例如 PyTorch 和 TensorFlow），則 SageMaker 專用端點或多容器託管是更好的選擇。最後，MME 適用於能夠容忍偶爾的冷啟動延遲損失的應用程式，因為可以解除安裝不常使用的模型來支援頻繁呼叫的模型。如果您有大量不常訪問的模型，則多模型端點可以高效服務這些流量，並實現顯著的成本節省。
總結
在本博文中，您已瞭解 SaaS 和多租戶與 ML 的關係，以及 SageMaker 多模型端點如何實現 ML 推理的多租戶和成本效率。您已瞭解 Zendesk 的每客戶 ML 模型的多租戶使用案例，以及他們如何在 SageMaker MME 中為其建議宏（Suggested Macros）功能託管數千個 ML 模型，並實現 90% 的推理成本節省（與專用端點相比）。超個性化使用案例可能需要數千個 ML 模型，對於這個使用案例而言，MME 是經濟高效的選擇。我們將繼續增強 MME，使您能夠以低延遲託管模型，並針對每個個性化模型提供更加精細的控制。要開始使用 MME，請參閱在一個端點後面的一個容器中託管多個模型。
關於作者
Syed Jaffry 是 Amazon 的高階解決方案構架師。他與許多公司合作（從中型企業到大型企業，從金融服務公司到獨立軟體開發商），幫助他們在雲端構建和運營安全、有彈性、可擴充套件和高效能的應用程式。
**
Sowmya Manusani** 是 Zendesk 的高階員工機器學習工程師。她致力於生產基於 NLP 的機器學習功能，這些功能旨在提高數千名 Zendesk 企業客戶的座席的工作效率。她在為數千個個性化模型構建自動訓練管道以及使用安全、有彈性、可擴充套件和高效能的應用程式為這些模型服務方面擁有豐富的經驗。閒暇時，她喜歡解謎和嘗試繪畫。
Saurabh Trikande 是 Amazon SageMaker Inference 的高階產品經理。他對與客戶打交道和使機器學習更加淺顯易懂很感興趣。業餘時間，Saurabh 喜歡徒步旅行、學習創新性技術、關注 TechCrunch 和陪伴家人。
Deepti Ragha 是 Amazon SageMaker 團隊中的軟體開發工程師。她目前的工作重點是構建用於高效託管機器學習模型的功能。業餘時間，她喜歡旅行、遠足和種植植物。
文章來源：https://dev.amazoncloud.cn/column/article/63098a79d4155422a46...