本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。

機器學(xué)習(xí)(ML)被稱為技術(shù)債務(wù)的高利率信用卡。對于特定的業(yè)務(wù)問題，使用適用的模型會相對容易一些，但是要使該模型在可伸縮的生產(chǎn)環(huán)境中運行，并能夠處理不斷變化的混亂數(shù)據(jù)語義和關(guān)系，以及以可靠的自動化方式演進模式，則完全是另一回事。

[[340153]]

對于機器學(xué)習(xí)生產(chǎn)系統(tǒng)而言，只有5%的實際代碼是模型本身。將一組機器學(xué)習(xí)解決方案轉(zhuǎn)變?yōu)槎说蕉说臋C器學(xué)習(xí)平臺的，是一種運用了加速建模、自動化部署和確保生產(chǎn)中的可伸縮性和可靠性的技術(shù)的架構(gòu)。

筆者此前講過lean D/MLOps，數(shù)據(jù)和機器學(xué)習(xí)操作，因為沒有數(shù)據(jù)的機器學(xué)習(xí)操作是沒有意義的，所以端到端機器學(xué)習(xí)平臺需要進行整體構(gòu)建。CI/CD基金會啟動了一個MLOps特別興趣小組(SIG)。其端到端機器學(xué)習(xí)平臺確定的步驟如下圖所示：

不過，其中掩蓋了一些不太重要的細節(jié)。例如，服務(wù)可能需要不同的技術(shù)取決于它是否是實時完成的?？缮炜s的解決方案通常將模型放在一個負載均衡器后的服務(wù)集群的多個機器上的容器內(nèi)運行。因此，上述圖表中的單個框并不意味著實際平臺的單個步驟、容器或組件。

這并不是對圖中步驟進行批評，而是一個警示：看似簡單的事情在實踐中可能并不那么容易。

圖表中沒有模型(配置)管理。可以考慮諸如版本控制、實驗管理、運行時統(tǒng)計、用于培訓(xùn)、測試和驗證數(shù)據(jù)集的數(shù)據(jù)沿襲跟蹤，從頭開始或從模型快照、超參數(shù)值、精度度量等等對模型進行再培訓(xùn)的能力。

此外，圖中缺失的另一個關(guān)鍵點是檢查模型偏差的能力，例如，根據(jù)不同的維度來分割模型的關(guān)鍵性能指標(biāo)。許多公司也需要能夠熱交換一個模型或并行運行多個模型。前者至關(guān)重要，可以避免模型在后臺更新時，用戶的請求進入服務(wù)器時失敗。而后者對于A/B測試或模型驗證也舉足輕重。

從CI/CD中我們可以得出另一個觀點，它提到了版本化數(shù)據(jù)和代碼的需要，這一點經(jīng)常被忽略。

谷歌：TFX

谷歌開發(fā)TensorFlow eXtended(TFX)的主要動機是將機器學(xué)習(xí)模型的生產(chǎn)時間從數(shù)月縮短到幾周。谷歌工程師和科學(xué)家為此焦頭爛額，因為“當(dāng)機器學(xué)習(xí)需要應(yīng)用于生產(chǎn)時，實際的工作流程將變得更加復(fù)雜。”

TensorFlow和TFX均可免費使用，不過后者在2019年才發(fā)布，比谷歌提供的ML基礎(chǔ)設(shè)施晚了兩年，遠不如前者成熟。

模型性能度量用于部署安全服務(wù)模型。因此，如果新模型的性能不如現(xiàn)有模型，它就無法投入生產(chǎn)。按照TFX的說法，該模型并非幸運兒。有了TFX，整個過程都是自動化的。

以下是一個開源TFX組件的基本概述：

• ExampleGen提取并分割輸入數(shù)據(jù)集。
• StatisticsGen為數(shù)據(jù)集計算統(tǒng)計數(shù)據(jù)。
• SchemaGen檢查統(tǒng)計數(shù)據(jù)并創(chuàng)建數(shù)據(jù)模式。
• ExampleValidator在數(shù)據(jù)集中查找異常值和缺失值。
• Transform對數(shù)據(jù)集執(zhí)行特征工程。
• Trainer使用TensorFlow對模型進行訓(xùn)練。
• Evaluator分析訓(xùn)練結(jié)果。
• ModelValidator確保模型的高安全性。
• Pusher將模型部署到服務(wù)基礎(chǔ)設(shè)施中。

TensorFlow服務(wù)是一個c++后端，服務(wù)于TensorFlow SavedModel文件。為了最小化訓(xùn)練/服務(wù)偏差，TensorFlow轉(zhuǎn)換會“凍結(jié)”計算圖中的值，這樣在訓(xùn)練中發(fā)現(xiàn)的相同值會在服務(wù)中使用。當(dāng)訓(xùn)練在運行時間是單一的固定值時，DAG可能會有若干個操作。

圖源：unsplash

Uber: Michelangelo

大約在2015年，Uber的ML工程師注意到機器學(xué)習(xí)系統(tǒng)中隱藏的技術(shù)債務(wù)。Uber已經(jīng)建立了一個一次性的自定義系統(tǒng)，與ML模型集成在一起，這在大型工程組織中不是很容易擴展。用他們自己的話來說，沒有合適的系統(tǒng)來建立可靠、統(tǒng)一和可重復(fù)的管道以創(chuàng)建和管理大規(guī)模的訓(xùn)練和預(yù)測數(shù)據(jù)。

這就是他們創(chuàng)造Michelangelo的原因。它依賴于Uber的數(shù)據(jù)湖——事務(wù)性和日志數(shù)據(jù)，支持離線(批處理)和在線(流)預(yù)測。對于脫機預(yù)測，包含的Spark作業(yè)生成批預(yù)測，而對于在線部署，模型在預(yù)測服務(wù)集群中提供服務(wù)，該集群通常由負載均衡器后面的數(shù)百臺機器組成，客戶機將單個或批預(yù)測請求作為rpc發(fā)送到該集群。

為每個實驗存儲與模型管理相關(guān)的元數(shù)據(jù)，例如，訓(xùn)練師的運行時統(tǒng)計信息、模型配置、沿襲、分布和特性的相對重要性、模型評估指標(biāo)、標(biāo)準評估圖表、學(xué)習(xí)的參數(shù)值和匯總統(tǒng)計信息等。

Michelangelo可以在同一個服務(wù)容器中部署多個模型，這允許從舊模型版本到新模型版本的安全轉(zhuǎn)換，以及對模型的并行A/B測試。

Michelangelo的最初版本并不支持深度學(xué)習(xí)在GPU上進行訓(xùn)練，但其開發(fā)團隊解決了這一遺漏問題。當(dāng)前平臺使用了Spark的ML管道序列化，但是有一個用于在線服務(wù)的附加接口，該接口添加了一個單例(在線)評分方法，可以既輕量級又能夠處理緊密型SLA，例如用于欺詐檢測和預(yù)防。它通過繞過Spark SQL的Catalyst優(yōu)化器的開銷來實現(xiàn)這一點。

值得注意的是，谷歌和Uber都為服務(wù)構(gòu)建了內(nèi)部協(xié)議緩沖區(qū)解析器和表示物，避免了默認實現(xiàn)中存在的瓶頸。

Airbnb: Bighead

基于類似原因，Airbnb在2016/2017年建立了自己的ML基礎(chǔ)架構(gòu)團隊。首先，盡管他們只有幾款模型正在構(gòu)建中，但每一款模型的構(gòu)建都可能需要長達三個月的時間。第二，模型之間不存在一致性。第三，線上和線下的預(yù)測差異極大。Bighead是其努力的頂峰：

數(shù)據(jù)管理由內(nèi)部工具Zipline處理。Redspot是一個托管的、集裝的、多用戶的Jupyter Notebook服務(wù)。Bighead庫用于數(shù)據(jù)轉(zhuǎn)換和管道提取，為通用模型框架提供了包裝器。其通過轉(zhuǎn)換保存元數(shù)據(jù)，因此可用于跟蹤沿襲。

Deep Thought是一個用于在線預(yù)測的REST API。Kubernetes對服務(wù)進行精心優(yōu)化。對于離線預(yù)測，Airbnb則使用他們自己的自動裝置。

Netflix也面臨著與上述公司類似的問題。他們的解決方案是運用Metaflow，這是一個為數(shù)據(jù)科學(xué)家提供的Python庫，用于處理數(shù)據(jù)管理和模型訓(xùn)練，而不提供預(yù)測服務(wù)。因此，它不是用于機器學(xué)習(xí)的端到端平臺，可能更適合于公司內(nèi)部的用例，而不是面向用戶的用例。當(dāng)然，它可以與由Kubernetes或AWS SageMaker支持的Seldon結(jié)合轉(zhuǎn)化為一個成熟的解決方案。

數(shù)據(jù)科學(xué)家將工作流程寫成DAG步驟，就像數(shù)據(jù)工程師使用Airflow一樣。和Airflow一樣，可以使用任何數(shù)據(jù)科學(xué)庫，因為Metaflow只執(zhí)行Python代碼。Metaflow在后臺分布處理和訓(xùn)練。所有的代碼和數(shù)據(jù)都會自動快照到S3中，以確保每個模型和實驗都有版本歷史。Pickle是默認的模型序列化格式。

開源版本還沒有內(nèi)置的調(diào)度器。其鼓勵用戶“主要依賴于垂直可伸縮性”，盡管他們可以使用AWS SageMaker實現(xiàn)水平可伸縮性，它與AWS緊密耦合。

Lyft：Flyte

[[340154]]

圖源：unsplash

Lyft已開放了其云本地平臺Flyte，在這個平臺上數(shù)據(jù)和機器學(xué)習(xí)操作融合在一起。這與我的D/MLOps方法相一致——數(shù)據(jù)(Ops)之于MLOps就像燃料之于火箭：沒有它將徒勞無功。

Flyte是建立于Kubernetes之上。它是由Lyft內(nèi)部使用的，可以擴展到至少7000個獨特的工作流，每個月執(zhí)行超過100,000次，100萬個任務(wù)和1000萬個容器。

Flyte中的所有實體都是不可變的，因此可以跟蹤數(shù)據(jù)沿襲、重現(xiàn)實驗和削減部署。重復(fù)任務(wù)可以利用任務(wù)緩存來節(jié)省時間和金錢。目前支持的任務(wù)包括Python、Hive、Presto和Spark以及sidecars。從源代碼來看，似乎是EKS。他們的數(shù)據(jù)目錄也是Amundsen，這與Spotify的Lexikon很像。

AWS、Azure、GCP和Co

公共云領(lǐng)域的主要參與者都有自己的機器學(xué)習(xí)平臺，除了Oracle，他們只為特定的用例和行業(yè)提供封閉的基于機器學(xué)習(xí)的模型。

AWS SageMaker是一個全堆棧的機器學(xué)習(xí)解決方案，支持TensorFlow、Keras、PyTorch和MXNet。使用SageMaker Neo，可以將模型部署到云端和邊緣。它有一個內(nèi)置的功能，可以通過Amazon MechanicalTurk對S3中存儲的數(shù)據(jù)附上標(biāo)簽。

谷歌沒有托管平臺，但是通過TFX、Kubeflow和AI平臺，可以將在CPU、GPU和TPUs上運行的模型所需的組件組合在一起，調(diào)優(yōu)超參數(shù)，并自動部署到生產(chǎn)環(huán)境中。Spotify甚至選擇了TFX/Kubeflow-on-GCP選項。

除了TensorFlow，還有對scikit-learn和XGBoost的支持。自定義容器允許使用任何框架，如PyTorch。SageMaker Ground Truth的標(biāo)簽服務(wù)目前處于測試階段。

Azure機器學(xué)習(xí)支持多種框架，如scikit-learn、Keras、PyTorch、XGBoost、TensorFlow和MXNet。其擁有自己的D/MLOps套件，其中包含大量的圖形。喜歡模型開發(fā)的人可以使用拖放界面，不過也附帶了各種警告。模型和實驗管理，如預(yù)期的那樣由微軟通過注冊表完成。使用Azure Kubernetes服務(wù)進行生產(chǎn)部署，控制轉(zhuǎn)出也是可能的。

IBM Watson ML提供了指向和點擊機器學(xué)習(xí)選項(SPSS)和對常見框架組的支持。作為兩大主要參與者之一，模型是在CPU或GPU上訓(xùn)練的，超參數(shù)調(diào)優(yōu)也包含在框中。該平臺沒有很多關(guān)于數(shù)據(jù)和模型驗證的細節(jié)，因為這些在其他IBM產(chǎn)品中是可用的。

盡管阿里巴巴的人工智能機器學(xué)習(xí)平臺標(biāo)榜著兩個流行詞，但它并沒有改進文檔，關(guān)于最佳實踐的部分寫的是用例而非建議。

不管怎樣，它在拖放方面下了功夫，特別是在數(shù)據(jù)管理和建模方面，這可能對一個自動化的端到端ML平臺幫助不大。該平臺支持諸如TensorFlow、MXNet和Caffe等框架，但它也支持大量的傳統(tǒng)算法。正如所料，它還包括一個超參數(shù)調(diào)諧器。

模型序列化使用PMML、TensorFlow的SavedModel格式或Caffe格式完成。請注意，采用PMML、ONNX或PFA文件的評分引擎可能會支持快速部署，但它有引入培訓(xùn)/服務(wù)傾斜的風(fēng)險，因為服務(wù)的模型是從不同的格式加載的。

其他平臺

H2O提供了一個使用POJO或MOJO進行數(shù)據(jù)操作、多種算法、交叉驗證、超參數(shù)調(diào)優(yōu)網(wǎng)格搜索、特性排序和模型序列化的平臺。

valohai——芬蘭語：輕鯊，是一個管理機器學(xué)習(xí)平臺，其可在私有、公共、混合或多云設(shè)置上運行。

每個操作(或執(zhí)行)都對Docker Image運行一個命令，類似于Kubeflow。二者主要區(qū)別在于，Valohai直接管理Kubernetes部署集群，而Kubeflow要求開發(fā)人員執(zhí)行這一任務(wù)。

然而，Kubeflow和TFX認為他們提供了一些與TensorFlow相關(guān)的工具。使用Valohai，需要重用現(xiàn)有的Docker Image，或者滾動自己的Docker Image，這意味著可使用任何機器學(xué)習(xí)框架，但是自由度必須與可維護性考慮相權(quán)衡。

因此，可以通過Spark、Horovod、TensorFlow或任何適配個人需求和基礎(chǔ)設(shè)施的工具來分配訓(xùn)練，但這些都由個人決定。這還意味著要負責(zé)確保數(shù)據(jù)轉(zhuǎn)換的兼容性，以避免訓(xùn)練/服務(wù)傾斜。注意，它目前只支持對象存儲。

Iguazio提到了從筆記本或IDE在幾秒鐘內(nèi)部署的能力，盡管這似乎錯過了最常見的場景：CI/CD管道，甚至是包含TFX的Pusher組件的平臺本身。它使用Kubeflow進行工作流編制。

Iguazio確實具備功能商店，可為鍵值對和時間序列提供統(tǒng)一的API。盡管大多數(shù)大型科技公司都有特色商店，但許多可用的產(chǎn)品卻并不具備。

功能商店處于核心位置，具有可在多個模型之間共享以加速模型開發(fā)的可隨時重用的功能。它可以在企業(yè)規(guī)模上實現(xiàn)特性工程自動化。例如，可以從時間戳中提取許多特性：年、季節(jié)、月、星期、時間、是否為本地假日、自最新相關(guān)事件以來所經(jīng)過的時間、特定事件在固定窗口中發(fā)生的頻率，等等。

SwiftStack AI通過RAPIDS套件面向NVIDIA gpu的高吞吐量深度學(xué)習(xí)。RAPIDS提供了庫，比如cuML，允許人們使用熟悉的scikit-learn API，但受益于GPU加速支持的算法，以及用于GPU驅(qū)動的圖形分析的cuGraph。

AI層是D/MLOps的API，其內(nèi)置了對多個數(shù)據(jù)源、編程語言和機器學(xué)習(xí)框架的支持。

MLflow由Databricks支持，這解釋了與Spark的緊密集成。它提供了一組有限的部署選項。例如，在PySpark中將模型導(dǎo)出為矢量化的UDF的能力對實時系統(tǒng)來說不是最合理的，因為Python UDF帶來了Python運行時環(huán)境和JVM之間的通信開銷。

盡管開銷沒有使用標(biāo)準PySpark UDFs那么大，因在Python和JVM之間的傳輸中使用了Apache Arrow(一種內(nèi)存中的柱狀格式)，也不是無關(guān)緊要的。如果使用Spark Sreaming作為默認的數(shù)據(jù)提取解決方案，那么使用Spark的微批處理模型可能很難實現(xiàn)亞秒延遲。

對日志記錄的支持仍然處于實驗階段，這對于D/MLOps來說是非常重要的。從文檔可以看出，MLflow并不關(guān)注數(shù)據(jù)和模型驗證，至少不是平臺的標(biāo)準部分。有一個MLflow的托管版本(在AWS和Azure上)提供了更多的特性。

D2iQ的KUDO for Kubeflow是一個基于Kubeflow的面向企業(yè)客戶的平臺。與開源的Kubeflow不同，它自帶Spark和Horovod，以及對TensorFlow、PyTorch和MXNet等主要框架進行預(yù)構(gòu)建和完全測試的CPU/GPU圖像。數(shù)據(jù)科學(xué)家可以在筆記本中部署表單，而不需要切換情景。

[[340155]]

圖源：unsplash

默認情況下，它支持多用戶使用。集成了Istio和Dex以實現(xiàn)額外的安全性和身份驗證。Kubeflow的KUDO位于Konvoy之上，是D2iQ的托管Kubernetes平臺。它可以運行在云、On-Prem、混合或在邊緣，還可用于氣隙集群的端口。

在Kubernet中，Kubeflow中的KUDO是用KUDO定義的操作符集合，KUDO是一個聲明性工具包，用于使用YAML創(chuàng)建Kubernetes操作符，而非Go。Kubernetes統(tǒng)一聲明操作符(KUDOs)的Cassandra、Elastic、Flink、Kafka、Redis等都是開源的，可以與平臺集成。