GitHub熱門項目:生產級深度學習項目如何構建?
在生產中部署深度學習模型可能很有挑戰(zhàn)性,因為這遠遠不僅是訓練出具有良好性能的模型就足夠了。為了部署生產級深度學習系統(tǒng),還需要正確設計和開發(fā)一眾組件。本文介紹了 GitHub 上的一個工程指南,用于構建將部署在實際應用程序中的生產級深度學習系統(tǒng)。
在這篇文章中,我們將詳細介紹生產級深度學習系統(tǒng)的各個模塊,并推薦適合每個組件的工具集和框架,以及實踐者提供的最佳實踐。
1. 數據管理
1.1. 數據源
開源數據 (好的開端,但并非優(yōu)勢)、數據增強以及合成數據
1.2. 標注
標注的勞動力來源:
- 眾包
- 服務公司:FigureEight
- 雇傭標注員
標注平臺:
- Prodigy:一種由主動學習(active learning)(由 Spacy 開發(fā)人員開發(fā))、文本和圖像支持的注釋工具。
- HIVE:用于計算機視覺的人工智能即服務平臺。
- Supervisely:完整的計算機視覺平臺。
- Labelbox:計算機視覺。
- Scale 人工智能數據平臺(計算機視覺和自然語言處理)。
1.3. 存儲
數據存儲選項:
(1) 對象存儲:存儲二進制數據(圖像、聲音文件、壓縮文本)
- Aamzon S3
- Ceph 對象存儲
(2) 數據庫:存儲元數據(文件路徑、標簽、用戶活動等)。
- Postgres 對于大多數應用程序來說都是正確的選擇,它提供了同類最佳的 SQL 和對非結構化 JSON 的強大支持。
(3) 數據湖:用于聚合無法從數據庫獲得的特征(例如日志)。
- Amazon Redshift
(4) 特征存儲:機器學習特征的存儲和訪問。
- FEAST(Google 云,開源)
- Michelangelo(Uber)
- 在訓練期間:將數據復制到本地或集群文件系統(tǒng)中。
1.4. 版本控制
- DVC:用于機器學習項目的開源版本控制系統(tǒng)
- Pachyderm:用于數據的版本控制
- Dolt:用于 SQL 數據庫的版本控制
1.5. 處理
生產模型的訓練數據可能來自不同的源,包括數據庫和對象存儲中的存儲數據、日志處理和其他分類器的輸出。
任務之間存在依賴關系,每個人物都需要在其依賴關系完成后才能啟動。例如,對新的日志數據進行訓練,需要在訓練之前進行預處理。因此,工作流在這方面變得相當重要。
工作流:
- Airflow (最常用的)
2. 開發(fā)、訓練與評估
2.1. 軟件工程
編輯器:
- Vim
- Emacs
- VS Code(作者推薦):內置 Git 暫存和顯示文件差異、Lint 代碼掃描、通過 SSH 遠程打開項目。
- Jupyter Notebooks:作為項目的起點很好,但它難以實現規(guī)?;?。
- Streamlit:具有小程序的交互式數據科學工具。
建議:
對于個人或初創(chuàng)企業(yè):
- 開發(fā):一臺 4 核圖靈架構的計算機。
- 訓練 / 評估:使用相同的 4 核 GPU 計算機。在運行許多實驗時,可以購買共享服務器或使用云實例。
對于大型公司:
- 開發(fā):為每位機器學習科學家購買一臺 4 核圖靈架構計算機,或者讓他們使用 V100 實例。
- 訓練 / 評估:在正確配置和處理故障的情況下使用云實例。
2.2. 資源管理
為程序分配免費資源:
資源管理選項:
- 舊式集群作業(yè)調度程序(如,Slurm 工作負載管理器)
- Docker + Kubernetes
- Kubeflow
- Polyaxon(付費功能)
2.3. 深度學習框架
除非有充分的理由不這樣做,否則請使用 TensorFlow/Keras 或 PyTorch。下圖顯示了不同框架在開發(fā)和 生產方面的比較。
2.4. 實驗管理
開發(fā)、訓練和評估策略:永遠從簡單開始。在小批量上訓練一個小型模型,只有在它能起作用的情況下,才擴展到更大的數據和模型,并進行超參數調優(yōu)。
實驗管理工具:
- Tensorboard:提供了機器學習實驗所需的可視化和工具。
- Losswise(用于機器學習的監(jiān)控)
- Comet:讓你可以跟蹤機器學習項目上的代碼、實驗和結果。
- Weights & Biases:通過簡單的協作,記錄并可視化研究的每個細節(jié)。
- MLFlow Tracking:用于記錄參數、代碼版本、指標和輸出文件,以及結果的可視化。
2.5. 超參數調優(yōu)
Hyperas:用于 Keras 的 hyperopt 的簡單包裝器,使用簡單的模板符號定義要調優(yōu)的超參數范圍。SIGOPT:可擴展的企業(yè)級優(yōu)化平臺。Ray-Tune:可擴展的分布式模型選擇研究平臺(專注于深度學習和深度強化學習)。Sweeps from Weights & Biases:參數并非由開發(fā)人員顯式指定,而是由機器學習模型來近似和學習的。
2.6. 分布式訓練
數據并行性:當迭代時間過長就使用它(TensorFlow 和 PyTorch 均支持)。
模型并行性:當模型不適合單 GPU 的情況下就是用它。
其他解決方案:
- Ray
- Horovod
3. 故障排除『有待完善』
4. 測試與部署
4.1. 測試與 CI/CD
與傳統(tǒng)軟件相比,機器學習生產軟件需要更多樣化的測試套件:
單元測試和集成測試
測試類型:
- 訓練系統(tǒng)測試:測試訓練管道。
- 驗證測試:在驗證集上測試預測系統(tǒng)。
- 功能測試。
- 持續(xù)集成:在將每個新代碼更改推送到倉庫后運行測試。
用于持續(xù)集成的 SaaS:
- CircleCI、Travis
- Jenkins、Buildkite
4.2. 網絡部署
(1)由 預測系統(tǒng) 和 服務系統(tǒng) 組成
- 在考慮規(guī)模的情況下為預測服務。
- 使用 REST API 為預測 HTTP 請求提供服務。
- 調用預測系統(tǒng)進行響應
- 預測系統(tǒng):處理輸入數據,進行預測。
- 服務系統(tǒng)(Web 服務器):
(2)服務選項:
- Docker
- Kubernetes (現在最流行)
- MESOS
- Marathon
- 通過 模型服務 解決方案部署。
- 將代碼部署為“無服務器函數”。
(3)模型服務:
- Tensorflow 服務
- MXNet Model 服務器
- Clipper (Berkeley)
- SaaS 解決方案 (Seldon,算法)
- 專門針對機器學習模型的網絡部署。
- 用于 GPU 推理的批處理請求。
- 框架:Tensorflow 服務、MXNet Model 服務器、Clipper、SaaS 解決方案 (Seldon,算法)
(4)決策:
- TensorFlow 服務或 Clipper
- 自適應批處理很有用。
- 如果 CPU 推理滿足要求,則更可取。
- 通過添加更多的服務器或無服務器進行擴展。
- CPU 推理:
- GPU 推理:
4.3 Service Mesh 和 Traffic Routing
從單片應用程序過渡到分布式微服務體系結構可能具有挑戰(zhàn)性。
服務網格(由微服務網絡組成)降低了此類部署的復雜性,并減輕了開發(fā)團隊的壓力。
Istio:一種服務網格技術,簡化已部署服務網絡的創(chuàng)建,而服務中的代碼更改很少或沒有。
4.4. 監(jiān)控
目的:
- 針對停機時間、錯誤和分發(fā)變化的警報。
- 抓取服務和數據回歸。
此外,云提供商的解決方案也是相當不錯。
4.5. 在嵌入式和移動設備上部署
主要挑戰(zhàn):內存占用和計算限制
解決方案:
- DistillBERT (用于自然語言處理)
- MobileNets
- 量化
- 縮小模型尺寸
- 知識蒸餾
嵌入式和移動框架:
- Tensorflow Lite
- PyTorch Mobile
- Core ML
- ML Kit
- FRITZ
- OpenVINO
模型轉換:
- 開放神經網絡交換(Open Neural Network Exchange,ONNX):用于深度學習模型的開源格式。
4.6. 一體化解決方案
- Tensorflow Extended (TFX)
- Michelangelo (Uber)
- Google Cloud AI Platform
- Amazon SageMaker
- Neptune
- FLOYD
- Paperspace
- Determined AI
- Domino data lab
Tensorflow Extended (TFX)
Airflow and KubeFlow ML Pipelines