如何為機器學習工程設計Python接口
前言
為了進行機器學習工程，首先要部署一個模型，在大多數情況下作為一個預測API。為了使此API在生產中工作，必須首先構建模型服務基礎設施。這包括負載平衡、擴展、監視、更新等等。
乍一看，所有這些工作似乎都很熟悉。Web開發人員和DevOps工程師多年來一直在自動化微服務基礎設施。當然，我們可以重新定位他們的工具?
不幸的是，我們不能。
雖然ML的基礎結構與傳統的DevOps類似，但它與ML的特殊性足以使標準的DevOps工具不那么理想。這就是為什么我們開發了Cortex——機器學習工程的開源平臺。
在一個非常高的層次上，Cortex被設計用來簡化在本地或云上部署模型，從而自動化所有底層基礎設施。該平臺的一個核心組件是預測器接口——一個可編程Python接口，開發人員可以通過該接口編寫預測api。
設計一個專門為web請求提供預測的Python接口是一個挑戰，我們花了幾個月的時間(目前仍在改進)。在這里，我想分享一些我們已經開發的設計原則:
1.預測器只是一個Python類
Cortex的核心是我們的預測器，它本質上是一個預測API，包括所有的請求處理代碼和依賴關系。預測器接口為這些預測api實施了一些簡單的需求。
因為Cortex采用微服務的方式來進行模型服務，預測器界面嚴格關注兩件事:
- 初始化模型
- 提供預測
在這種精神下，Cortex的預測界面需要兩種功能，即剩余的init__()和predict()，它們或多或少做你所期望的事情:
- import torch
- from transformers import pipeline
- class PythonPredictor:
- def __init__(self, config):
- # Use GPUs, if available
- device = 0 if torch.cuda.is_available() else -1
- # Initialize model
- self.summarizer = pipeline(task="summarization", device=device)
- def predict(self, payload):
- # Generate prediction
- summary = self.summarizer(
- payload["text"], num_beams=4, length_penalty=2.0, max_length=142, no_repeat_ngram_size=3
- )
- # Return prediction
- return summary[0]["summary_text"]
初始化之后，您可以將一個預測器看作一個Python對象，當用戶查詢端點時，將調用它的單個predict()函數。
這種方法的最大好處之一是，對于任何有軟件工程經驗的人來說，它都是直觀的。不需要接觸數據管道或模型訓練代碼。模型只是一個文件，而預測器只是一個導入模型并運行predict()方法的對象。
然而，除了語法上的吸引力之外，這種方法還提供了一些關鍵的好處，即它如何補充了皮層更廣泛的方法。
2. 預測只是一個HTTP請求
為生產中提供預測服務而構建接口的復雜性之一是，輸入幾乎肯定會與模型的訓練數據不同，至少在格式上是這樣。
這在兩個層面上起作用:
- POST請求的主體不是一個NumPy數組，也不是您的模型用來處理的任何數據結構。
- 機器學習工程就是使用模型來構建軟件，這通常意味著使用模型來處理它們沒有受過訓練的數據，例如使用GPT-2來編寫民間音樂。
因此，預測器接口不能對預測API的輸入和輸出固執己見。預測只是一個HTTP請求，開發人員可以隨意處理它。例如，如果他們想部署一個多模型端點，并基于請求參數查詢不同的模型，他們可以這樣做:
- import torch
- from transformers import pipeline
- from starlette.responses import JSONResponse
- class PythonPredictor:
- def __init__(self, config):
- self.analyzer = pipeline(task="sentiment-analysis")
- self.summarizer = pipeline(task="summarization")
- def predict(self, query_params, payload):
- model_name = query_params.get("model")
- if model_name == "sentiment":
- return self.analyzer(payload["text"])[0]
- elif model_name == "summarizer":
- summary = self.summarizer(payload["text"])[0]
- else:
- return JSONResponse({"error": f"unknown model: {model_name}"}, status_code=400)
雖然這個界面讓開發者可以自由地使用他們的API做什么，它也提供了一些自然的范圍，使皮質在基礎設施方面更加固執己見。
例如，在后臺Cortex使用FastAPI來設置請求路由。Cortex在這一層設置了許多與自動排序、監控和其他基礎設施功能相關的過程，如果開發人員需要實現路由，這些功能可能會變得非常復雜。
但是，因為每個API都有一個predict()方法，所以每個API都有相同數量的路由—1。假設這允許Cortex在基礎設施層面做更多的事情，而不限制工程師。
3.服務模型只是一個微服務
對于在生產中使用機器學習的人來說，規模是一個主要的問題。型號可能會很大(GPT-2大約是6 GB)，計算成本高，并且可能有很高的延遲。特別是對于實時推斷，擴大規模來處理流量是一項挑戰——如果你的預算有限，情況更是如此。
為了解決這個問題，Cortex把預測器當作微型服務，可以水平伸縮。更具體地說，當開發人員進行Cortex部署時，Cortex將包含API，旋轉為推理準備的集群，并進行部署。然后，它將API公開為負載平衡器背后的web服務，并配置自動縮放、更新和監視:
預測器接口是此過程的基礎，盡管它“只是”一個Python接口。
預測器接口所做的是強制打包代碼，使其成為推理的單個原子單元。單個API所需的所有請求處理代碼都包含在一個預測器中。這使得大腦皮層能夠很容易地衡量預測因素。
通過這種方式，工程師不必做任何額外的工作——當然，除非他們想做一些調整——準備一個用于生產的API。一個皮層的部署是默認的生產準備就緒。
