前言

為了進行機器學習工程，首先要部署一個模型，在大多數情況下作為一個預測API。為了使此API在生產中工作，必須首先構建模型服務基礎設施。這包括負載平衡、擴展、監視、更新等等。

乍一看，所有這些工作似乎都很熟悉。Web開發人員和DevOps工程師多年來一直在自動化微服務基礎設施。當然，我們可以重新定位他們的工具？

不幸的是，我們不能。

雖然ML的基礎結構與傳統的DevOps類似，但它與ML的特殊性足以使標準的DevOps工具不那么理想。這就是為什么我們開發了Cortex——機器學習工程的開源平臺。

在一個非常高的層次上，Cortex被設計用來簡化在本地或云上部署模型，從而自動化所有底層基礎設施。該平臺的一個核心組件是預測器接口——一個可編程Python接口，開發人員可以通過該接口編寫預測api。

設計一個專門為web請求提供預測的Python接口是一個挑戰，我們花了幾個月的時間（目前仍在改進）。在這里，我想分享一些我們已經開發的設計原則：

1.預測器只是一個Python類

Cortex的核心是我們的預測器，它本質上是一個預測API，包括所有的請求處理代碼和依賴關系。預測器接口為這些預測api實施了一些簡單的需求。

因為Cortex采用微服務的方式來進行模型服務，預測器界面嚴格關注兩件事：

初始化模型

提供預測

在這種精神下，Cortex的預測界面需要兩種功能，即剩余的init__（）和predict（），它們或多或少做你所期望的事情：

初始化之后，您可以將一個預測器看作一個Python對象，當用戶查詢端點時，將調用它的單個predict（）函數。

這種方法的最大好處之一是，對于任何有軟件工程經驗的人來說，它都是直觀的。不需要接觸數據管道或模型訓練代碼。模型只是一個文件，而預測器只是一個導入模型并運行predict（）方法的對象。

然而，除了語法上的吸引力之外，這種方法還提供了一些關鍵的好處，即它如何補充了皮層更廣泛的方法。

2. 預測只是一個HTTP請求

為生產中提供預測服務而構建接口的復雜性之一是，輸入幾乎肯定會與模型的訓練數據不同，至少在格式上是這樣。

這在兩個層面上起作用：

POST請求的主體不是一個NumPy數組，也不是您的模型用來處理的任何數據結構。

機器學習工程就是使用模型來構建軟件，這通常意味著使用模型來處理它們沒有受過訓練的數據，例如使用GPT-2來編寫民間音樂。

因此，預測器接口不能對預測API的輸入和輸出固執己見。預測只是一個HTTP請求，開發人員可以隨意處理它。例如，如果他們想部署一個多模型端點，并基于請求參數查詢不同的模型，他們可以這樣做：

雖然這個界面讓開發者可以自由地使用他們的API做什么，它也提供了一些自然的范圍，使皮質在基礎設施方面更加固執己見。

例如，在后臺Cortex使用FastAPI來設置請求路由。Cortex在這一層設置了許多與自動排序、監控和其他基礎設施功能相關的過程，如果開發人員需要實現路由，這些功能可能會變得非常復雜。

但是，因為每個API都有一個predict（）方法，所以每個API都有相同數量的路由—1。假設這允許Cortex在基礎設施層面做更多的事情，而不限制工程師。

3.服務模型只是一個微服務

對于在生產中使用機器學習的人來說，規模是一個主要的問題。型號可能會很大（GPT-2大約是6 GB），計算成本高，并且可能有很高的延遲。特別是對于實時推斷，擴大規模來處理流量是一項挑戰——如果你的預算有限，情況更是如此。

為了解決這個問題，Cortex把預測器當作微型服務，可以水平伸縮。更具體地說，當開發人員進行Cortex部署時，Cortex將包含API，旋轉為推理準備的集群，并進行部署。然后，它將API公開為負載平衡器背后的web服務，并配置自動縮放、更新和監視：

預測器接口是此過程的基礎，盡管它“只是”一個Python接口。

預測器接口所做的是強制打包代碼，使其成為推理的單個原子單元。單個API所需的所有請求處理代碼都包含在一個預測器中。這使得大腦皮層能夠很容易地衡量預測因素。

通過這種方式，工程師不必做任何額外的工作——當然，除非他們想做一些調整——準備一個用于生產的API。一個皮層的部署是默認的生產準備就緒。