不要只關注演算法與模型,這裡有份產品級深度學習開發指南
- 2019 年 12 月 6 日
- 筆記
機器之心報道
參與:一鳴、杜偉
深度學習模型距離實際的應用往往還十分遙遠,選擇合適的工具進行開發、部署和測試十分重要,這份面向互聯網產品經理和開發者的技術指南,可以幫助你尋找到合適的解決方案。
眾所周知,深度學習模型僅僅只是構建 AI 產品的重要步驟,但並不是全部。一個互聯網產品(如 APP)想要集成深度學習能力,往往還需要走完很多設計、開發和測試方面的工作。如何部署深度學習往往成為了系統設計中更關鍵的問題。
近日,GitHub 上有這樣一個項目,專門介紹了如何將深度學習演算法和模型融入到互聯網產品中。項目基本以流程、架構圖為主,目前仍在完善中,適合產品經理和開發者學習。
項目地址:https://github.com/alirezadir/Production-Level-Deep-Learning
深度學習產品架構概覽
訓練深度學習模型不及在生產階段部署演算法模型那樣困難。如圖所示,模型僅僅只是整個系統中的一部分。

在深度學習模型之前,有配置、服務基礎設施、數據獲取、特徵抽取等步驟,而在其之後則有數據驗證、分析、監控、流程管理和機器資源管理等。生產級別的深度學習應用非常複雜。
而涉及這些環節的程式、應用、工具和硬體則更加複雜多樣,因此需要遵循特定的流程和步驟,選擇合適的工具進行項目。

為了介紹必要的產品構建流程,項目作者將其分為多個部分,包括數據管理、開發訓練評估、測試等步驟。
數據管理
數據管理是產品級深度學習應用需要解決的第一個問題。選擇合適的工具,可以保證模型獲得穩定、標註正確、平衡的數據。
數據源
怎樣獲取數據?這是一個常見的問題。通常有以下三種方法:
- 使用公開數據——剛開始構建產品的時候可以使用;
- 數據增強,如影像數據的旋轉裁剪等;
- 合成數據;
數據標註
正確的數據標註對模型的影響非常大,會影響著整個應用的性能。
標註數據的工作可以交給人工進行,或使用標註平台輔助。
- 人工標註
- 眾包;
- 數據標註公司: FigureEight、僱傭專門的標註人員
- 標註平台:
- Prodigy :一個由 Spacy 團隊開發者開發的標註工具,使用主動學習,適用於文本和影像數據;
- HIVE:AI 標註平台,針對影像數據;
- Supervisely:電腦視覺數據標註平台;
- Labelbox:電腦視覺標註;
- Scale:AI 數據平台,適用於電腦視覺和 NLP 領域。
數據存儲
數據存儲則需要選擇合適伺服器和資料庫,方便業務使用。
- 按對象存儲:(即將數據存儲為二進位數據,包括影像、音頻文件和壓縮文本)
- Aamzon S3
- Ceph Object Store
- 資料庫:(保存存儲文件路徑、標籤和用戶活動等資訊)
- Postgres:對大部分應用都適用的資料庫,支援 SQL 和無結構 json 文件;
- 數據湖:(用於收集資料庫獲得不了的特徵,如日誌)
- Amazon Redshift
- 特徵存儲:(保存機器學習的特徵)
- FEAST:基於Google雲,目前已開源;
- Michelangelo:Uber 的開源平台;
版本控制
- DVC:開源的機器學習版本控制工具;
- Pachyderm:數據版本控制;
- Dolt:SQL 資料庫的版本控制;
處理流程
- 訓練生產級模型時,通常會將不同來源的數據提取出來,包括存儲在資料庫和對象存儲中的數據、日誌,以及其他分類器的輸出結果;
- 此外,如果不同任務之間有依賴,則需要在上一個任務完成後將其移除出工作流;
- 工作流管理:Airflow
開發、訓練和評估
在這一階段,項目開發者需要選擇合適的工具,對深度學習模型、應用框架等進行開發。
軟體工程
- 編輯器
- Vim
- Emacs
- VS Code (https://code.visualstudio.com/)
- 有著內置的 git 和 diff 工具,可以通過 ssh 遠程打開項目;
- Jupyter Notebook:適合項目的開始階段,但是擴展較困難;
- Streamlit:互動式數據科學工具;
- 開發設備推薦配置
- 對於個人和初創公司:開發用 4 核圖靈架構電腦;訓練和評估用同樣的 4 核帶 GPU 的電腦,如果需要運行很多實驗,可以購買雲服務;
- 對大型公司:開發上每個機器學習工程師都可以配備 4 核圖靈架構電腦,或者直接使用 V100 等伺服器;訓練和評估則購買雲服務,並配置合適的運行環境和崩潰處理機制。
資源管理
- 資源管理的作用在於向系統中的任務提供計算資源,提高效率;
- 資源管理工具:
- 集群任務管理系統(如 Slurm);
- Docker + Kubernetes;
- Kubeflow;
- Polyaxon (付費版本)。
深度學習框架
- 除非有充分的理由,否則使用 Tensorflow/Keras 或 PyTorch;
- 以下圖表表示了不同框架在「開發」到「生產」的程度:

實驗管理
開發、訓練和評估流程:
- 從簡單的方法開始:訓練一個小模型,使用小批的數據。如果這一方法可行,則擴展到更大的數據量和模型上,然後進行調參;
- 實驗管理工具:
- Tensorboard;
- 提供機器學習可視化工具;
- Losswise :用於深度學習監控;
- Comet:可以讓用戶追蹤程式碼、實驗和結果;
- Weights & Biases :記錄並可視化研究的每個細節;
- MLFlow Tracking:用於記錄參數、程式碼版本、評估指標和輸出文件,並可視化結果。
- Tensorboard;
調參
調參則是很重要的一個步驟,能讓模型發揮更好的效果。
- Hyperas:Keras 的超參數運算元的簡單封裝,能夠提供一個超參範圍供開發者調整;
- SIGOPT :可擴展的企業級優化平台;
- Ray-Tune:可擴展的研究平台,能夠進行分散式模型選擇(主要關注深度學習和深度強化學習);
- Sweeps from Weights & Biases:參數不會被開發者顯式地定義,而是通過一個機器學習模型進行擬合和學習。
分散式訓練
- 數據並行:如果迭代時間過長,則使用數據並行(TensorFlow 和 PyTorch 都支援);
- 模型並行:當模型無法在單個 GPU 上擬合的時候使用;
- 其他解決方案:
- Ray;
- Horovod。
測試和部署
產品級深度學習的測試和部署需要完成以下幾個步驟:
測試和 CI/CD
與傳統軟體相比,機器學習生產軟體需要更加多樣化的測試套件:

- 單元和集成測試類型
- 訓練系統測試:測試訓練管道;
- 驗證測試:測試驗證集上的預測系統;
- 功能測試:在少數重要的示例上測試預測系統。
- 持續集成:在每次新的程式碼更改推送到 repo 之後,運行測試;
- 用於持續集成的 SaaS(軟體即服務):
- CircleCI, Travis;
- Jenkins, Buildkite。
網路部署
這裡包括預測系統和服務系統:
- 預測系統:處理輸入數據和進行預測
- 服務系統(網路伺服器):
- 為預測考慮規模;
- 使用 REST API 來預測 HTTP 請求;
- 調用預測系統做出響應。
- 服務選項:
- 部署到 VMs,並通過添加實例實現擴展
- 作為容器進行部署,並通過編排(orchestration)實現擴展;
- 容器(Docker)
- 容器編排(最流行的 Kubernetes、MESOS 和 Marathon)
- 將程式碼部署為「無伺服器函數」;
- 通過模型服務解決方案進行部署。
模型服務
- 為 ML 模型進行專門的網路部署
- 批量請求 GPU 推理
- 框架(TensorFlow 服務、MXNet 模型伺服器、Clipper 和 SaaS 解決方案)
決策制定
- CPU 推理
- 如果滿足需求,則最好選擇 CPU 推理;
- 通過添加更多伺服器或選擇無伺服器來實現擴展。
- GPU 推理
- TF 服務或 Clipper;
- 自適應批處理是有用的。
監測
- 目的:防止宕機、錯誤等;
- 捕捉服務和數據惡化的問題;
- 測試雲供應商的解決方案是否有效。
在嵌入和移動設備上部署
- 主要挑戰:記憶體佔用和計算約束
- 解決方案
- 量化
- 縮減模型大小(MobileNets)
- 知識蒸餾(DistillBERT)
- 嵌入式和移動端框架:
- Tensorflow Lite
- PyTorch Mobile
- Core ML
- ML Kit
- FRITZ
- OpenVINO
- 模型轉換
- 開放神經網路交換(Open Neural Network Exchange,ONNX):用於深度學習模型的開源格式
一體化解決方案
- Tensorflow Extended (TFX)
- Michelangelo (Uber)
- Google Cloud AI Platform
- Amazon SageMaker
- Neptune
- FLOYD
- Paperspace
- Determined AI
- Domino data lab
在這裡,作者提供了一張對比圖,用於說明不同的技術選型的優劣勢。


