本文最初發表在 Towards Data Science，經原作者 Caleb Kaiser 授權，InfoQ 中文站翻譯並分享。
在許多軟件工程學科中，生產用例是相當標準化的。以 Web 開發爲例：要在 Web 應用中實現身份驗證，你無需發明數據庫，編寫自己的哈希函數，或者設計一個新的身份驗證策略。你可以使用某個定義好的方法，並利用標準工具就能在 Web 應用中實現身份驗證。
然而，在機器學習中，這種標準化並不存在。爲了構建從模型訓練到部署的管道，團隊不得不構建自己的解決方案，主要的問題是從頭開始開始構建解決方案。
這樣一來，這一領域對於許多工程師來說成了不可企及的禁區，推而廣之，對那些很多請不起專業專家的公司來說也是如此。
但這一情況正在改變。生產模式正變得越來越常規。這些方法正在標準化，工具也正在日益成熟。到最後，軟件可以由非專業的機器學習工程師開發了。
將模型投入生產意味着什麼？
如果你看看自己每天都使用的軟件，如 Gmail、Uber、Netflix 等，無論你喜歡哪種社交媒體平臺，都能在裏面看到機器學習的身影，比如：自動完成電子郵件、語音轉文本、對象檢測、預計到達時間等等。
雖然這些模型背後的數學是機器學習研究人員的領域，但用來將它們轉化爲產品的架構應該是任何開發人員都熟悉的：
從軟件工程的角度來看，經過訓練的模型只不過是另一個 API，將模型投入生產意味着將其部署爲微服務。
注意：還有其他形式的模型部署（例如，未連接到國際互聯網的設備），但它們不是本文要討論的重點。
想要構建類似 Gmail 的智能撰寫（Smart Compose）這樣的功能嗎？將語言模型部署爲 Web 服務，用文本 ping 端點，並在前段顯示預測。想要實現像 Facebook 建議的標籤功能嗎？還是同樣的過程，部署一個圖像識別模型，並像使用其他 Web 服務一樣使用它。
雖然“把你的模型部署成微服務”，這句話聽起來很容易，但是要如何做到這一點，卻是一個很有挑戰性的問題。
部署用於實時推理的模型需要回答幾個問題：
- 如何編寫一個從模型生成預測的 API？
- 將該 API 部署到生產環境的最佳方式是什麼？
- 如何實現生產 Web 服務所需要的所有基礎設施特性：自動伸縮、監控、負載平衡、滾動更新等？
根據模型的具體情況（如模型所有的框架、需要多少計算和內存、可以處理的數據種類等等），答案可能會有很大的差異。
這就是爲什麼大型科技公司有專門的機器學習基礎設施團隊，也是爲什麼大多數創業公司無法在生產中使用機器學習的原因。
但現在，這些問題有了標準答案。
要從模型中生成預測，可以使用框架附帶的任何服務庫（如 TensorFlow/TF serving、PyTorch/TorchServe）。要將你的模型封裝在 API 中並進行部署，你就需要使用模型服務平臺。
現在，任何軟件工程師都可以採用一個模型（無論該模型是由他們的數據科學團隊訓練的模型，還是經過他們調優的開源模型，或者只是一個普通的預訓練模型），並將其轉換爲生產 Web 服務，而不必成爲機器學習或 Kubernetes 方面的專家。
示例：文本生成不僅僅是 Gmail 的智能撰寫
如果你在過去的幾年裏使用過 Gmail，那麼你一定很熟悉它的智能撰寫功能。當你在寫電子郵件時，Gmail 會拋出一些建議回覆：
雖然 Google 有一個複雜的機器學習管道，需要大量投資，但如果你想構建一些模仿 Gmail 的智能撰寫的功能，不需要 Google 的資源你也能做到這一點。
舉個例子：AI Dungeon。這是一款基於機器學習的文字冒險遊戲。
從本質上說，AI Dungeon 是 OpenAI 的 GPT-2（一種最先進的語言模型）的微調版本，以 Web 服務的形式部署。用戶將他們的提示提交到模型-微服務中，它就會用一個故事來回應。
就上下文而言，GPT-2 非常龐大。經過訓練的模型超過了 5GB，完全可以利用 GPU 來服務於一個預測。在不久之前，要想知道如何將其作爲微服務進行規模化部署，是一個重大的基礎設施項目。你需要：
- 將其託管在具有足夠空間 / GPU 的實例上，已提供預測服務。
- 配置自動縮放以處理任意數量的併發用戶。
- 實現各種成本優化，讓你的雲賬單處於可控狀態。
在這些任務中，有許多子問題需要解決。比如，你是否應該根據內存使用情況或對壘中的請求數量進行自動縮放？你是否能夠平穩地處理故障轉移，從而能夠輕鬆地使用 Spot 實例來節省成本？
譯註：Spot 實例，是一種未使用的 EC2 實例，以低於按需價格提供。由於 Spot 實例允許用戶以極低的折扣請求未使用的 EC2 實例，這可能會顯著降低你的 Amazon EC2 成本。Spot 實例的每小時價格稱爲 Spot 價格。每個可用區中的每種實例類型的 Spot 實例的價格是由 Amazon EC2 設置的，並根據 Spot 實例的長期供求趨勢逐步調整價格。只要容量可用，並且請求的每小時最高價超過 Spot 價格，Spot 實例就會運行。如果能靈活控制應用程序的運行時間並且應用程序可以中斷，Spot實例就是經濟實惠之選。例如，Spot 實例非常適合數據分析、批處理作業、後臺處理和可選的任務。
正如 AI Dungeon 背後的工程師 Nick Walton 在他的文章《我們如何擴展 AI Dungeon 來支持超過 100 萬用戶》（How we scaled AI Dungeon 2 to support over 1,000,000 users) 中稱，他所要做的就是編寫他的預測 API，並允許他的模型服務平臺（Cortex）實現基礎設施的自動化。
注：如果你不熟悉遷移學習，那麼看一看 AI Dungeon 是如何用很少的數據就能獲得最先進的結果的故事也是很有趣的。
設計模型具有挑戰性，將其生產化的過程很枯燥
多年前，機器學習產品的瓶頸問題如果不解決，就不會有 AI Dungeon。但現在，它只是衆多機器學習原生創業公司之一。
例如，Glisten 將多個模型組合在一起，生成了一個 API，可以用於從圖像中提取產品信息：
儘管公司用 Glisten 來處理每月數以千計的產品，但 Glisten 只是一家只有兩個人的初創公司。這只是因爲他們不需要基礎設施團隊而已，所以公司只有兩個人就夠了。
隨着機器學習的生產化的問題得到解決，機器學習研究人員和軟件工程師之間的障礙也被打破。研究方面的突破更快地體現爲產品方面的功能，因此，我們所有人都會受益。
作者介紹：
Caleb Kaiser，Cortex Lab 創始團隊成員，曾在 AngelList 工作，最初在 Cadillac 供職。
原文鏈接：
https://towardsdatascience.com/production-machine-learning-isnt-hard-anymore-932bd91e138f