<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>KServe on StackSimplify | DevOps &amp; Cloud Education by Kalyan Reddy</title><link>https://stacksimplify.com/tags/kserve/</link><description>Recent content in KServe on StackSimplify | DevOps &amp; Cloud Education by Kalyan Reddy</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 14 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://stacksimplify.com/tags/kserve/index.xml" rel="self" type="application/rss+xml"/><item><title>5 Levels of ML Model Deployment on Kubernetes</title><link>https://stacksimplify.com/blog/5-levels-ml-deployment/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/5-levels-ml-deployment/</guid><description>You deploy containers to Kubernetes every day. But how do you deploy ML models?
There are 5 levels. Each adds production capabilities. Here&amp;rsquo;s the progression.
The 5 Levels Level Pattern DevOps Equivalent When to Use L1 Baked Image Static binary in container Learning, simple models L2 MLflow Dynamic Config from external store Versioned, no rebuild L3 KServe Predictor Deployment + HPA + Ingress Scalable, zero downtime L4 KServe Transformer Sidecar pattern Modular, independent scaling L5 KServe Explainer Audit logging Compliance, GDPR Level 1: Baked Image Model baked into the Docker image at build time.</description></item><item><title>A/B Testing for ML Models: When Offline Metrics Lie</title><link>https://stacksimplify.com/blog/ab-testing-ml-models/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/ab-testing-ml-models/</guid><description>You retrained the model. Accuracy went up 2% on the test set. You deployed it. Revenue dropped 5%.
What happened? Offline metrics lie. A model that scores better on historical data can score worse on real users.
Canary vs A/B Testing Approach Question It Answers Traffic Split Canary &amp;ldquo;Does it break anything?&amp;rdquo; 10-20% to new model A/B Testing &amp;ldquo;Does it actually improve outcomes?&amp;rdquo; 50/50 to both models You need both. Canary first, then A/B.</description></item><item><title>Canary Deployments for ML Models with KServe and Istio</title><link>https://stacksimplify.com/blog/canary-rollouts-ml-models/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/canary-rollouts-ml-models/</guid><description>You do canary deployments for APIs every day. Why not for ML models?
New model ready. Looks good in testing. Deploy to production. Hope it works. It doesn&amp;rsquo;t. Rollback takes 5 minutes. Five minutes of garbage predictions. Damage done.
How It Works Role Traffic Description Champion (80%) Production traffic Current model, proven, stable Canary (20%) Test traffic New version, running alongside Both run simultaneously. Same endpoint. Istio handles the traffic split.</description></item><item><title>DevOps Thinking Applied to MLOps: 5 Essential Tools</title><link>https://stacksimplify.com/blog/devops-thinking-mlops-tools/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/devops-thinking-mlops-tools/</guid><description>If you&amp;rsquo;re a DevOps engineer and a data scientist has ever handed you a model.pkl and said &amp;ldquo;deploy this&amp;rdquo;, you know the feeling.
Where did this come from? What data trained it? Which version is this? How do I scale it?
Here&amp;rsquo;s what I&amp;rsquo;ve learned after months building MLOps pipelines: these aren&amp;rsquo;t new problems. We&amp;rsquo;ve already solved them in DevOps. The tools are different, but the thinking is identical.
The Mental Model: Same Problems, Different Artifacts Every MLOps challenge maps directly to a DevOps pattern you already understand:</description></item><item><title>ML Cost Optimization: One YAML Field Cut Our Bill by 80%</title><link>https://stacksimplify.com/blog/ml-cost-optimization/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/ml-cost-optimization/</guid><description>We changed one YAML field from 1 to 0. Infrastructure cost dropped 80%.
The field: minReplicas.
When set to 1, your ML inference pod runs 24/7. Even at 3 AM when nobody is making predictions. That&amp;rsquo;s $50-150 per month per model, running idle.
When set to 0, the pod scales to zero when idle. Traffic arrives, the pod spins up. Traffic stops, the pod disappears. You pay only for what you use.</description></item><item><title>Scale-to-Zero for ML Models: Stop Paying for Idle Compute</title><link>https://stacksimplify.com/blog/scale-to-zero-ml-models/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/scale-to-zero-ml-models/</guid><description>Your ML model runs 24/7. Inference requests come 2% of the time. You&amp;rsquo;re paying for 98% idle compute.
This is the most expensive mistake in ML deployment. And the fix takes one YAML field.
How It Works KServe + Knative handles this natively.
Your model is serving requests Traffic drops. 30 seconds of silence Knative scales pods to ZERO New request arrives Pod spins up in seconds. Request served. Zero requests = zero pods = zero cost.</description></item><item><title>SHAP Explainability: Why Your ML Model Flagged That Transaction</title><link>https://stacksimplify.com/blog/shap-explainability-ml/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/shap-explainability-ml/</guid><description>Your ML model flagged a customer&amp;rsquo;s transaction. They call support and ask: &amp;ldquo;Why?&amp;rdquo;
If you can&amp;rsquo;t answer, you might be breaking the law.
GDPR Article 22 gives users the right to an explanation for automated decisions. Financial regulators require it. Healthcare demands it.
The Explanation Instead of just HIGH RISK: 0.85, you get:
Feature SHAP Value Impact Amount 5x higher than average +0.32 Increases risk International from unusual country +0.21 Increases risk Transaction at 3 AM local time +0.</description></item><item><title>The Two-Container Pattern: Transformer + Predictor for ML Serving</title><link>https://stacksimplify.com/blog/transformer-predictor-pattern/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>https://stacksimplify.com/blog/transformer-predictor-pattern/</guid><description>Your ML model expects clean features. Your API receives raw data. Where does the preprocessing live?
Every team gets this wrong the first time. They stuff everything into one container: data validation, feature engineering, ML inference, output formatting. It works. Until it doesn&amp;rsquo;t.
The Problem with One Container Model retrained? Rebuild the whole container. Feature logic changed? Rebuild the whole container. Need to scale inference independently? Everything scales together. Or breaks together.</description></item></channel></rss>