AutomateEdge · MLOps Engineer · Tools

MLOps Engineer Tools: 2026 Install Path

This inventory covers the tools a 2026 MLOps Engineer will use across their day-to-day platform work. The list is deliberately systems-infrastructure-heavy — less Jupyter, more Kubernetes operators. Free or open-source where possible; the two cloud-native exceptions (GCP Vertex AI and AWS SageMaker) are flagged as paid and noted with their free-tier limits. Hours-to-learn estimates are the time to solve a novel production problem with the tool unaided; mastery takes 3-5x that.

Container orchestration and infrastructure

The operational substrate everything else runs on. Kubernetes is not optional at any serious MLOps shop. Helm and Terraform/Pulumi are equally non-optional the moment you have more than one environment.

ToolPurposeHours to learnDocs
Kubernetes 1.30+ Cluster orchestration for ML workloads — training jobs, serving fleets, pipeline DAGs 80h Official docs →
Helm 3 Package manager for Kubernetes; chart authoring and release management 15h Official docs →
Terraform Infrastructure-as-Code; provision cloud resources declaratively with state management 30h Official docs →
Pulumi (Python SDK) IaC in Python — growing fast in ML orgs as an alternative to HCL-based Terraform 20h Official docs →
k3s / kind / minikube Lightweight local Kubernetes for development and CI — run the full stack on a laptop or in a GitHub Actions runner 5h Official docs →
Docker + BuildKit Container build, multi-stage images, layer caching — the atomic unit of every ML deployment 20h Official docs →

Pipeline orchestration and CI/CD

ML pipelines are more complex than software CI pipelines: they version data, gate on statistical metrics, and may run for hours on GPU nodes. The tools below cover the full spectrum from code-level CI to multi-day training DAGs.

ToolPurposeHours to learnDocs
GitHub Actions CI/CD orchestration for code + model pipelines; self-hosted GPU runners 15h Official docs →
GitLab CI/CD Alternative to GitHub Actions; dominant in enterprise and self-hosted environments 15h Official docs →
Argo Workflows Kubernetes-native DAG pipeline engine for ML training, evaluation, and data prep workflows 25h Official docs →
Argo Rollouts Progressive delivery controller for Kubernetes — canary, blue-green, analysis-triggered rollback 10h Official docs →
Prefect 3 Python-native workflow orchestrator with a strong local-to-cloud deployment story; strong competitor to Airflow for ML teams 20h Official docs →
Apache Airflow 2.x De-facto standard for scheduled data + ML pipelines at large organisations; mature ecosystem 25h Official docs →
Dagster Asset-based orchestration model; strong data lineage and software-defined assets story 20h Official docs →

Model training, registry, and experiment tracking

The chain from training run to deployed model version needs to be fully traceable. MLflow is the open-source backbone; Ray handles distributed training at scale; Kubeflow ties the Kubernetes-native ML workflow together.

ToolPurposeHours to learnDocs
MLflow Experiment tracking, model registry, artefact storage, model serving — the open-source MLOps backbone 20h Official docs →
Kubeflow Kubernetes-native ML platform — Pipelines, Training Operator (PyTorchJob, TFJob), KServe 30h Official docs →
Ray 2.x (Train + Tune + Data) Distributed ML compute — DDP training, hyperparameter tuning, scalable data preprocessing on a Ray cluster 25h Official docs →
DVC (Data Version Control) Version datasets alongside code; reproducible pipelines with remote storage (S3, GCS, Azure) 12h Official docs →
LakeFS Git-like branching for object-store datasets — branch, diff, and merge large datasets atomically 10h Official docs →

Model serving runtimes

The 2026 serving stack has consolidated: vLLM and SGLang for generative models, Triton for discriminative and CV models, Ray Serve for heterogeneous multi-model graphs, TorchServe for self-managed PyTorch deployments. Know the trade-offs — latency, throughput, hardware utilisation, operational complexity — well enough to choose without a tutorial.

ToolPurposeHours to learnDocs
vLLM High-throughput LLM serving with paged attention, continuous batching, LoRA hot-swap, OpenAI-compatible API 15h Official docs →
SGLang Structured-generation serving runtime with RadixAttention; faster than vLLM on structured-output workloads 12h Official docs →
NVIDIA Triton Inference Server Production model serving for CV, NLP, and multi-model pipelines; ONNX, TensorRT, PyTorch, TensorFlow backends 20h Official docs →
Ray Serve Scalable heterogeneous model serving on Ray clusters; model composition graphs, actor-based scaling 15h Official docs →
TorchServe PyTorch-native model server with handler API, multi-model workers, gRPC — simpler than Triton, tighter PyTorch integration 12h Official docs →

Monitoring, observability, and drift detection

You cannot manage what you cannot measure. Every serving component should emit Prometheus metrics; every pipeline step should emit OpenTelemetry spans; every production dataset should run through a drift-detection gate. These tools are the nervous system of an ML platform.

ToolPurposeHours to learnDocs
Prometheus + Alertmanager Metrics collection, storage, and alerting — the universal monitoring backbone for Kubernetes-based ML platforms 20h Official docs →
Grafana Dashboarding over Prometheus + Loki + Tempo — GPU utilisation, inference latency, model quality proxies 15h Official docs →
OpenTelemetry Vendor-neutral distributed tracing, metrics, and logging instrumentation for ML pipelines and serving 15h Official docs →
Evidently AI Open-source data and model drift detection, report generation, test suites; integrates with Airflow/Prefect 10h Official docs →
Arize AI or WhyLabs (free tier) Managed model observability platforms — production drift alerts, embedding monitoring, performance tracking 8h Official docs →
DCGM (Data Centre GPU Manager) GPU-level metrics: utilisation, memory bandwidth, thermal throttle, NVLink health — the missing layer below Prometheus node-exporter 8h Official docs →

Cloud-native ML platforms and feature stores

Vertex AI and SageMaker are the two dominant managed ML platforms in 2026. Both abstract a great deal of infrastructure complexity; both have traps around vendor lock-in and cost at scale. Feast is the leading open-source feature store — learn it before the managed alternatives so you understand what they are doing for you.

ToolPurposeHours to learnDocs
Feast (feature store) Open-source feature store with online/offline parity — the primary tool for eliminating training-serving skew 15h Official docs →
GCP Vertex AI Managed ML platform on GCP — Pipelines, Model Registry, Prediction, Feature Store, Vertex AI Workbench (paid; $300 free credit) 25h Official docs →
AWS SageMaker AWS managed ML platform — Training, Endpoints, Pipelines, Model Monitor, Feature Store (paid; limited free tier) 25h Official docs →
GCP GKE or AWS EKS Managed Kubernetes services — the compute backbone for Kubernetes-based ML platforms; GPU node pools, spot/preemptible support 20h Official docs →

Quickstart install path

A step-by-step first-day install that gets you from zero to producing work. Follow in order — later steps assume earlier ones.

  1. Install Docker Desktop (macOS/Windows) or Docker Engine + Compose (Linux). Run `docker run hello-world` to confirm.
  2. Install kubectl and either k3s (Linux VPS) or kind (any OS) for a local Kubernetes cluster. Run `kubectl get nodes` successfully before moving on.
  3. Install Helm 3: `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`. Run `helm repo add stable https://charts.helm.sh/stable`.
  4. Install Terraform or Pulumi. For Pulumi with Python: `pip install pulumi pulumi-gcp` (or pulumi-aws).
  5. Install MLflow: `pip install mlflow`. Run `mlflow ui` locally to confirm the tracking server starts. Understand the artefact store vs tracking DB distinction before the first experiment.
  6. Deploy vLLM on a GPU (Colab or rental): `pip install vllm && python -m vllm.entrypoints.openai.api_server --model mistralai/Mistral-7B-Instruct-v0.3`. Benchmark with a curl loop.
  7. Install Argo Workflows on your local cluster: `kubectl apply -f https://github.com/argoproj/argo-workflows/releases/download/v3.5.8/install.yaml`. Submit your first workflow YAML.
  8. Stand up Prometheus + Grafana via the kube-prometheus-stack Helm chart. Connect a Python service exposing a custom counter metric and watch it appear in Grafana.

Frequently asked questions

Do I need a full cloud account to learn this stack?

No. k3s or kind gives you a full Kubernetes cluster on a laptop or a $5 VPS. MLflow, Argo Workflows, Prometheus, and Feast all run in a local cluster. Cloud-specific tools (Vertex AI, SageMaker) are learnable via their free tiers — but they are not the right starting point. Learn the portable open-source layer first; the managed services will feel like obvious simplifications, not new concepts.

Is Kubeflow still relevant in 2026?

Yes, but with nuance. Kubeflow Pipelines has lost ground to Argo Workflows (more general) and cloud-native orchestrators. Kubeflow Training Operator (PyTorchJob, TFJob) remains the standard way to submit distributed training jobs to Kubernetes. KServe (the inference component) is increasingly the Kubernetes-native serving standard. Think of Kubeflow as a collection of CRDs more than a monolithic platform.

Should I learn Airflow or Prefect or Dagster?

At least one to Intermediate, plus familiarity with the others at the conceptual level. Most job descriptions name Airflow — it has the largest installed base and the most community knowledge. But Prefect 3 and Dagster have better developer-experience stories for Python-native teams. The patterns (DAGs, dependencies, retries, sensors) transfer across all three. Pick whichever your target employers use most.

vLLM vs SGLang — which one is winning in 2026?

Both are production-deployed at serious organisations. vLLM has a larger community and broader hardware support. SGLang is faster on structured-generation workloads (function calling, JSON schema, constrained decoding) due to RadixAttention and its compiler-based approach. The pragmatic answer: learn vLLM first (more community resources, more job postings), then SGLang when you hit a structured-output performance wall.

Do I need to know CUDA programming?

At Beginner to low-Intermediate. You need to understand GPU memory hierarchies, what CUDA kernels are and why they matter for inference optimisation, and how to read DCGM / nvidia-smi output during an incident. You do not need to write CUDA kernels yourself unless you move into ML compiler or inference-optimisation work. What you do need to understand: why attention is compute-bound, why matmul is the bottleneck, and why INT8 quantisation can 2x throughput without accuracy regression.

How big is the gap between local Kubernetes and cloud Kubernetes?

Conceptually small — the control-plane APIs are identical. Operationally significant: managed load balancers, CSI storage drivers, node auto-provisioning, GPU node pools, and IAM integration all behave differently across providers. The discipline is: learn the Kubernetes concepts locally until they are automatic, then learn the cloud-specific operations (EKS node groups, GKE autopilot, spot/preemptible handling) in a $30 cloud lab session.

What's the fastest path to an MLOps job if I'm coming from SRE or platform engineering?

Four projects in public GitHub: (1) deploy a vLLM serving container with Prometheus metrics and a Grafana dashboard, (2) build a CI/CD pipeline that trains a model and gates on accuracy before pushing to MLflow registry, (3) implement drift detection on a real dataset with Evidently and wire an alert, (4) write a Helm chart for a complete ML serving stack. That portfolio, combined with your existing Kubernetes and IaC experience, is competitive for mid-level roles.

Continue on the MLOps Engineer track