It’s 2:00 AM on a Friday. Maya, a Senior Machine Learning Engineer, wakes up to a piercing, relentless alarm from PagerDuty. A few hours prior, her team had successfully deployed a newly optimised version of their Customer Churn Assessment Model to production. The offline validation metrics had been stellar - higher ROC-AUC, faster feature processing, and tighter probability bounds. The team cheered, closed their laptops, and headed out for the weekend. But real-world data is a chaotic beast. Shortly after midnight, a subtle mismatch in incoming payload structures - an unexpected tensor name and strict precision specifications (FP32) enforced by the serving container - triggered widespread initialisation failures. Real-time dashboards were flashing red, inference calls were throwing HTTP errors, revenue-critical churn alerts were completely dark, and Maya had to frantically roll back the entire architecture under intense pressure. The Lesson: Traditional "all-or-nothing" cutovers are the engineering equivalent of jumping out of an airplane and attempting to sew the parachute on the way down. There has to be a safer way to test models in production without exposing 100% of your user base to a catastrophic failure. Enter the Canary Deployment Think of it like flight-testing a new engine design. Aerospace engineers don't put 300 passengers on a commercial airliner for its first flight test. They mount the prototype engine on a single test aircraft, fly a controlled route, and monitor real-time telemetry before clearing it for the whole fleet. In MLOps, a Canary Deployment is your model's test flight. Instead of routing 100% of your production traffic to a brand-new model iteration (version 2), you route a small, controlled fraction - say, 20% to the newer version. The remaining 80% stays safely on your battle-tested baseline (version 1). If version 2 encounters unexpected runtime errors or schema mismatches, only a tiny fraction of requests are impacted. Your engineering team can immediately route 100% of traffic back to version 1 with a single click - achieving true zero-downtime rollbacks without a full system outage. How Cloudera AI Inference Makes Canary Deployments Effortless With Cloudera AI Inference, implementing an 80/20 (or any other ratio) canary split is quite straight forward. Let’s have a closer look: Native MLflow Integration: Log your baseline and updated XGBoost models directly into the AI Registry using standard MLflow signatures. Open Inference Protocol (OIP v2): Standardized Triton serving engines handle runtime dependencies cleanly in read-only container environments. UI-Driven Traffic Splitting: Under your model endpoint configuration, simply click + Add Version, set the sliders to 80% (version 1) and 20% (version 2), and click Update. By shifting from instant cutovers to controlled canary releases, you turn high-stakes production deployments into routine, low-risk upgrades and ensure your team gets a good night's sleep. Pro-Tip: Understanding Supported Runtime Protocols in Cloudera AI Canary traffic-splitting in Cloudera AI Inference is engineered for predictive models (like ONNX, Scikit-learn, or PyTorch tabular models) operating on the Open Inference Protocol (OIP v2 / KServe v2). Generative AI endpoints powered by single-engine runtimes like NVIDIA NIM do not support multi-version traffic splitting and require 100% traffic allocation per container endpoint. Step-by-Step Canary Rollout Workflow Phase 1: Build, Register & Deploy Baseline Model (Version 1) Train and log Version 1 (cml-churn-xgb-official-1) to the Model Registry using native MLflow signatures. Phase 2: Deploy Initial Endpoint at 100% Traffic Deploy Version 1 from the registry as a live Model Endpoint allocated at 100% initial traffic to establish your production baseline. Phase 3: Train Version 2 & Apply the 80/20 Canary Split Train your improved candidate (Version 2), register it under the same model name, attach it to the active endpoint, and adjust the traffic sliders to 80% (Version 1) and 20% (Version 2). Phase 1: Build, Register & Deploy Baseline Model (Version 1) a. Log in to the Cloudera Control Plane, select Cloudera AI, open a Workbench, and start a session. b. Run your training script to build and register Version 1 (baseline model) under the registered model name cml-churn-xgb-official-1. c. Verify the registered model under the Registered Models tab in the UI to confirm Version 1 is listed. Your baseline Version 1 model is now safely registered and ready for initial deployment! Phase 2: Deploy Initial Endpoint at 100% Traffic a. Navigate to Registered Models in the left sidebar, select cml-churn-xgb-official-1, and click Deploy Model in the top right. b. Configure the endpoint settings in the Served Model Builder: Environment & Inference Service: Select your target workspace environment. Endpoint Name: Enter a unique name (e.g., cml-churn-xgb-official-1-ep). Model Name: Select cml-churn-xgb-official-1. Version: Select Version 1. Traffic Allocation: Leave set to 100% (default for the initial model version). c. Configure resource profile: Select instance type, GPU (if required), CPU, and memory allocations. Configure autoscaling under Other Settings if needed. d. Advanced Options (Optional): Add custom environment variables or tags. e. Review and Create: Verify all configuration details and click Create Endpoint. Phase 3: Train Version 2 & Apply the 80/20 Canary Split Part A: Train & Register Version 2 (In Workbench) a. Return to your Workbench session and open your training notebook. b. Train your improved model candidate (e.g., deeper XGBoost trees, updated hyperparameters, or new features). c. Run the registration script using the exact same registered model name (cml-churn-xgb-official-1). d. Verify in Registered Models: Confirm that Version 2 is now listed alongside Version 1 under cml-churn-xgb-official-1. Part B: Update Endpoint & Route Canary Traffic (In UI) a. Navigate to Deployments -> Model Endpoints and select your active endpoint (cml-churn-xgb-official-1-ep). b. Open Configuration Settings: Click on the Configurations tab and click Edit on the Served Models panel. c. Attach Version 2: Click + Add Version. Select Model Name: cml-churn-xgb-official-1. Select Version: Version 2. d. Set Canary Traffic Split: Version 1 (Baseline): Adjust slider to 80%. Version 2 (Canary Candidate): Adjust slider to 20%. e. Update Endpoint: Click Save / Update Configurations to execute the zero-downtime canary rollout. Congratulations! Your model endpoint is now safely serving live production traffic across both versions without a single second of downtime. Follow this document for API-based guidance for canary deployment https://docs.cloudera.com/machine-learning/cloud/ai-inference/topics/ml-caii-deploy-models-canary-deployment-use-api.html If you are interested in learning more about Cloudera AI, join us in Cloudera Community.   ... View more