在軟件工程的諸多領域內，生產用例是相當標準化的。以Web開發為例，要在Web應用中實現身份認證，你不會去創造一個數據庫，自己寫出散列功能，或者去設計一個新的認證方法。你會從幾個明確定義的方法之中選一個，并利用標準的工具手段。

然而，對于機器學習來說，這種標準化還不存在。想要建立一個從模型訓練到部署的一體化pipeline，團隊不得不自己構建解決方案，基本上都是從零開始。

因此，該領域對于許多工程師來說都是觸不可及的，而進一步，對于那些沒有能力請專家的公司來說，也是如此。

但是，這種局面正在發生變化。模型的生產化正在變得越來越常規化。方法正在逐步標準化，工具的選擇正在逐步成熟，到最后，非專業的ML工程師的也能搭建出軟件了。

“將模型投入生產”是什么意思？

只要看一看你每天使用的那些軟件，Gmail、Uber、Netflix，或者任何哪個你喜歡的社交媒體平臺，你就會看到許多由機器學習驅動的功能：自動完成電子郵件，語音轉文字，對象檢測，ETA預測等。

雖然這些模型背后的數學是機器學習領域的科研人員要操心的事情，但能將其轉化為產品的架構卻應該為所有開發者所熟知：

從軟件工程的角度來看，一個訓練好的模型也只是一個API罷了，將模型投入生產意味著將其部署為一個微服務（microservice）。

注意：其他形式的模型部署（例如，對于沒有連接到互聯網的設備）也是存在的，但那不是本文的重點。

你想搭建出類似Gmail的Smart Compose這樣的東西嗎？把一個語言模型部署為web服務，用文本ping終端，然后在你的前端顯示預測結果。你想實現一個像Facebook的推薦標簽（Suggested Tagging）那樣的東西嗎？還是同樣的流程：部署一個圖像識別模型，然后就像使用其他web服務一樣了。

但是，雖然用手比劃著對別人說“把你的模型部署成微服務就好了”是很容易的，但如何做到卻是個很有挑戰性的問題。

不久前，想要部署一個實時推理模型，還需要先回答幾個問題：

• 你要如何編寫一個能從你的模型中生成預測結果的API？

• 將該API部署到生產中的最佳方式是什么？

• 如何實現生產型Web服務所需要的所有基礎設施功能？比如自動縮放、監控、負載均衡、滾動更新等等。

根據你模型的特性的不同（它是用什么框架訓練出來的，需要多少算力和內存，能處理什么類型的數據等等），答案可能會有很大的差異。

這就是為什么大型科技公司有專門的ML基礎設施團隊，也是大多數初創公司在生產中用不起ML的原因。

而現在，上面的問題都有了標準答案。

要想從你的模型中生成預測，你就用你的框架所附帶的服務庫（TensorFlow/TF Serving，PyTorch/TorchServe）。要想把你的模型封裝成API并部署，你需要使用一個模型服務平臺（請容我無恥的插播一句：我參與Cortex的維護，它是我們的開源模型服務平臺，地址：https://github.com/cortexlabs/cortex）。

現在，任何一個軟件工程師拿到一個模型以后，無論這個模型是由他們的數據科學團隊訓練好的，還是他們微調以后的開源模型，又或者只是一個普通的預訓練模型，都能夠把它變成一個web服務投入生產了，而不需要非得成為機器學習或Kubernetes專家。

舉例：文本生成并不是只有Gmail的Smart Compose能做到

如果你在過去幾年中用過Gmail，你一定對Smart Compose很熟悉。在你輸入郵件內容時，它負責讓Gmail給出一些建議的回復。

雖然Google肯定是有一個復雜的需要大量投資的ML pipeline的，但如果你想搭建一些模仿Smart Compose功能的東西，你不需要Google那樣的資源就可以做到。

這方面的一個例子：AI Dungeon，一款由ML驅動的choose-your-own-adventure游戲。（地址：https://aidungeon.io/）

從底層來看，AI Dungeon 是 OpenAI 的 GPT-2（一種最先進的語言模型）微調后的版本，被部署為 Web 服務的形式。用戶將他們的詞匯提交給模型微服務，然后它就會回復一個故事。

介紹一下，GPT-2是非常大的。一個訓練好的模型超過5GB，進行一項預測能夠完全占用GPU。在不久前，探索如何將其大規模地部署為微服務，是一個重大的基礎設施項目。你需要：

• 將其托管到有足夠空間/GPU來為預測服務的實例上。

• 配置autoscaling來處理任意數量的并發用戶。

• 實施各種成本優化方案，以保持你的云計算總花銷在可控范圍內。

而這每個任務中都包含許多需要解決的子問題。你autoscale的時候，是應該依據內存利用率，還是依據隊列中的請求數量？你是否能順利地處理故障切換（failover），來讓自己可以放心地通過現貨實例來節省成本？

在谷歌，這些事情都是有ML基礎架構團隊負責的，而AI Dungeon則是僅由一位工程師獨立打造出來的。

正如Nick Walton（AI Dungeon背后的工程師）在其關于將AI Dungeon擴展到超過100萬用戶的文章中所解釋的那樣，他所要做的就只是編寫他的預測API，并讓他的模型服務平臺（Cortex）實現基礎架構的自動化。（文章地址：https://medium.com/@aidungeon/how-we-scaled-ai-dungeon-2-to-support-over-1-000-000-users-d207d5623de9）

注：即使對那些不熟悉轉移學習的人來說，AI Dungeon用很少的數據獲得最先進的結果的故事也非常有趣。

設計模型應該是很有挑戰性的。

而將它們投入生產則應該是很枯燥的。

幾年前，生產型ML的瓶頸會限制AI Dungeon的產生。而現在，AI Dungeon只是眾多ML原生創業公司中的一個。

比如說Glisten，它就將多個模型結合在一起，從而產出一個可以用來從圖像中提取產品信息的API。

圖源：Glisten.ai

盡管Glisten每月要處理各個公司成千上萬的產品，但它也只是一家只有兩人的初創公司而已。只有他們不需要基礎設施團隊，這一點才有可能實現。

而且，生產型ML的大眾化并不僅僅只影響著初創公司。比如說，下面這位工程師，就決定在被隔離期間部署一個對話模型，并錄下自己對著對話模型說話的視頻，以此來打發時間。

視頻地址：https://youtu.be/ZnjlV2-qD1c

這些只是工程師們正在著手的項目中的幾個例子，他們的資源很少，而且通常也缺乏DevOps的專業知識。然而這些項目之所以重要，不僅僅是因為它們本身就很有趣，還因為它們代表了機器學習生態系統中的一個進步。

隨著機器學習生產化問題的解決，ML科研人員和軟件工程師之間的壁壘被打破了。研究方面的突破能更快地體現在產品的特性上。結果就是，我們所有人都會從中受益。