在雲端的 ML/DL 領域中，從分佈式運算模型訓練 (Distributed Training)、調整(Tuning)，最終將 Fine-Tuned 的模型作為服務（Serving）來使用的工具有太多選擇，不管是 MLOps 或 DataOps，可以使用 Airflow、KMINE 或是 DataBricks 等等 Pipeline 的服務做到，但也只是 pipeline 而已。
分佈式運算其實在早期不是太容易做，早期常在 MPI 或是 Hadoop 上部署，這些方法首先會遇到環境問題，如深度學習框架 Tensorflow 和 PyTorch 或 Nvdia、CUDA 或是 cudnn 的版本控管問題。此外，Infra 層的管理也會有難度，例如共享機器的運算結果及開機器運算。 Kubeflow Pipeline 可以當成是一個 AI/ML 生命週期中處理這些的通用場所，它可以利用 K8S 本身的所有優點解決上述問題。
關於 K8S 的優點可以看這篇：https://logz.io/blog/kubernetes-as-a-service-gke-aks-eks/
Kubeflow 的優點是輕量、可攜帶、可擴展以及可跨系統的一致性，這意味著此 ML 系統在未來可以很輕易的部署到混合雲環境的 cluster，像是 AWS EKS、Azure AKE 或是 GCP GKE。非常有利於有規模的資料科學家團隊做跨專案的開發環境分配、搬遷以及權限控管。
SageMaker 做分布式運算也是一個選擇，開發人員不用自己定義環境，只需要權限透過呼叫 API 就可以自建一個 MLOps 的 pipeline。SageMaker 相對於 Kubeflow 算是一個較概括（High-level）的託管服務，可以很快速部署 module 用以解決 80% 常見的問題，之所以是託管就表示有很多地方是開發人員沒有控制權的，也要承擔雲端平台本身的穩定度風險，有些較細節的客製化調整、新的演算法（可能會涉及到很多抽象層）或是有轉移到其他雲的需求，就可以使用 Kubeflow。
AWS 的官方白皮書特別提到 SageMaker 的持有成本是比 EKS 還要低的，這點不難理解，畢竟 SageMaker 已經把大部分的機器學習會用上的工具模組化，不論是模型監控或是分佈式運算的 pipeline。甚至在新的服務 SageMaker Studio 也可以用 UI 管理這些 ML 的實驗，算是很 user friendly 的工具。唯一的缺點就是整個 ML Pipeline 必須綁在 AWS 的環境內。
https://aws.amazon.com/blogs/machine-learning/lowering-total-cost-of-ownership-for-machine-learning-and-increasing-productivity-with-amazon-sagemaker/
其實 SageMaker 也出了一個 SageMaker Component 讓 Kubeflow 可以調用，但我覺得用 Kubeflow Pipelines ContainerOp 直接呼叫 SageMaker SDK 也沒太大的差異。詳細的部署流程和權限設定可以看官方的文件。
AWS 很貼心地讓你在用 Kubeflow 的時候也會想到 SageMaker。SageMaker Component 的存在，其實也一定程度上也解決了重用性（Reusability）和複雜性（Complexity）之間的衝突，開發人員可以自由的在 Kubeflow 中選擇使用 SageMaker 來解決眾多非客製化的單純問題，也可在 K8S 上開發複雜的分散式模型系統架構，讓開發這件事保有了很大程度上的彈性。
