在雲端的 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 的環境內。
其實 SageMaker 也出了一個 SageMaker Component 讓 Kubeflow 可以調用，但我覺得用 Kubeflow Pipelines ContainerOp 直接呼叫 SageMaker SDK 也沒太大的差異。詳細的部署流程和權限設定可以看官方的文件。
AWS 很貼心地讓你在用 Kubeflow 的時候也會想到 SageMaker。SageMaker Component 的存在，其實也一定程度上也解決了重用性（Reusability）和複雜性（Complexity）之間的衝突，開發人員可以自由的在 Kubeflow 中選擇使用 SageMaker 來解決眾多非客製化的單純問題，也可在 K8S 上開發複雜的分散式模型系統架構，讓開發這件事保有了很大程度上的彈性。
