在生產中部署深度學習模型可能很有挑戰性，因為這遠遠不僅是訓練出具有良好性能的模型就足夠了。為了部署生產級深度學習系統，還需要正確設計和開發一眾組件。本文介紹了 GitHub 上的一個工程指南，用于構建將部署在實際應用程序中的生產級深度學習系統。

在這篇文章中，我們將詳細介紹生產級深度學習系統的各個模塊，并推薦適合每個組件的工具集和框架，以及實踐者提供的最佳實踐。

1. 數據管理

1.1. 數據源

開源數據 （好的開端，但并非優勢）、數據增強以及合成數據

1.2. 標注

標注的勞動力來源：

• 眾包
• 服務公司：FigureEight
• 雇傭標注員

標注平臺：

• Prodigy：一種由主動學習（active learning）（由 Spacy 開發人員開發）、文本和圖像支持的注釋工具。
• HIVE：用于計算機視覺的人工智能即服務平臺。
• Supervisely：完整的計算機視覺平臺。
• Labelbox：計算機視覺。
• Scale 人工智能數據平臺（計算機視覺和自然語言處理）。

1.3. 存儲

數據存儲選項：

(1) 對象存儲：存儲二進制數據（圖像、聲音文件、壓縮文本）

• Aamzon S3
• Ceph 對象存儲

(2) 數據庫：存儲元數據（文件路徑、標簽、用戶活動等）。

• Postgres 對于大多數應用程序來說都是正確的選擇，它提供了同類最佳的 SQL 和對非結構化 JSON 的強大支持。

(3) 數據湖：用于聚合無法從數據庫獲得的特征（例如日志）。

• Amazon Redshift

(4) 特征存儲：機器學習特征的存儲和訪問。

• FEAST（Google 云，開源）
• Michelangelo（Uber）
• 在訓練期間：將數據復制到本地或集群文件系統中。

1.4. 版本控制

• DVC：用于機器學習項目的開源版本控制系統
• Pachyderm：用于數據的版本控制
• Dolt：用于 SQL 數據庫的版本控制

1.5. 處理

生產模型的訓練數據可能來自不同的源，包括數據庫和對象存儲中的存儲數據、日志處理和其他分類器的輸出。

任務之間存在依賴關系，每個人物都需要在其依賴關系完成后才能啟動。例如，對新的日志數據進行訓練，需要在訓練之前進行預處理。因此，工作流在這方面變得相當重要。

工作流：

• Airflow （最常用的）

2. 開發、訓練與評估

2.1. 軟件工程

編輯器：

• Vim
• Emacs
• VS Code（作者推薦）：內置 Git 暫存和顯示文件差異、Lint 代碼掃描、通過 SSH 遠程打開項目。
• Jupyter Notebooks：作為項目的起點很好，但它難以實現規模化。
• Streamlit：具有小程序的交互式數據科學工具。

建議：

對于個人或初創企業：

• 開發：一臺 4 核圖靈架構的計算機。
• 訓練 / 評估：使用相同的 4 核 GPU 計算機。在運行許多實驗時，可以購買共享服務器或使用云實例。

對于大型公司：

• 開發：為每位機器學習科學家購買一臺 4 核圖靈架構計算機，或者讓他們使用 V100 實例。
• 訓練 / 評估：在正確配置和處理故障的情況下使用云實例。

2.2. 資源管理

為程序分配免費資源：

資源管理選項：

• 舊式集群作業調度程序（如，Slurm 工作負載管理器）
• Docker + Kubernetes
• Kubeflow
• Polyaxon（付費功能）

2.3. 深度學習框架

除非有充分的理由不這樣做，否則請使用 TensorFlow/Keras 或 PyTorch。下圖顯示了不同框架在開發和 生產方面的比較。

2.4. 實驗管理

開發、訓練和評估策略：永遠從簡單開始。在小批量上訓練一個小型模型，只有在它能起作用的情況下，才擴展到更大的數據和模型，并進行超參數調優。

實驗管理工具：

• Tensorboard：提供了機器學習實驗所需的可視化和工具。
• Losswise（用于機器學習的監控）
• Comet：讓你可以跟蹤機器學習項目上的代碼、實驗和結果。
• Weights & Biases：通過簡單的協作，記錄并可視化研究的每個細節。
• MLFlow Tracking：用于記錄參數、代碼版本、指標和輸出文件，以及結果的可視化。

2.5. 超參數調優

Hyperas：用于 Keras 的 hyperopt 的簡單包裝器，使用簡單的模板符號定義要調優的超參數范圍。SIGOPT：可擴展的企業級優化平臺。Ray-Tune：可擴展的分布式模型選擇研究平臺（專注于深度學習和深度強化學習）。Sweeps from Weights & Biases：參數并非由開發人員顯式指定，而是由機器學習模型來近似和學習的。

2.6. 分布式訓練

數據并行性：當迭代時間過長就使用它（TensorFlow 和 PyTorch 均支持）。

模型并行性：當模型不適合單 GPU 的情況下就是用它。

其他解決方案：

• Ray
• Horovod

3. 故障排除『有待完善』

4. 測試與部署

4.1. 測試與 CI/CD

與傳統軟件相比，機器學習生產軟件需要更多樣化的測試套件：

單元測試和集成測試

測試類型：

• 訓練系統測試：測試訓練管道。
• 驗證測試：在驗證集上測試預測系統。
• 功能測試。
• 持續集成：在將每個新代碼更改推送到倉庫后運行測試。

 用于持續集成的 SaaS：

• CircleCI、Travis
• Jenkins、Buildkite

4.2. 網絡部署

（1）由 預測系統 和 服務系統 組成

• 在考慮規模的情況下為預測服務。
• 使用 REST API 為預測 HTTP 請求提供服務。
• 調用預測系統進行響應
• 預測系統：處理輸入數據，進行預測。
• 服務系統（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

從單片應用程序過渡到分布式微服務體系結構可能具有挑戰性。

服務網格（由微服務網絡組成）降低了此類部署的復雜性，并減輕了開發團隊的壓力。

Istio：一種服務網格技術，簡化已部署服務網絡的創建，而服務中的代碼更改很少或沒有。

4.4. 監控

目的：

• 針對停機時間、錯誤和分發變化的警報。
• 抓取服務和數據回歸。

此外，云提供商的解決方案也是相當不錯。

4.5. 在嵌入式和移動設備上部署

主要挑戰：內存占用和計算限制

解決方案：

• 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