<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>llmd on Ritesh Sonawane</title><link>https://riteshsonawane.com/tags/llmd/</link><description>Recent content in llmd on Ritesh Sonawane</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 26 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://riteshsonawane.com/tags/llmd/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes Gateway API Inference Extension</title><link>https://riteshsonawane.com/blog/k8s-gateway-api-inference/</link><pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate><guid>https://riteshsonawane.com/blog/k8s-gateway-api-inference/</guid><description>&lt;h2 id="kubernetes-gateway-api-inference-extension-what-it-is-and-why-it-matters"&gt;Kubernetes Gateway API Inference Extension: What It Is and Why It Matters&lt;/h2&gt;
&lt;p&gt;If you are running LLM workloads on Kubernetes today, you have almost certainly hit the same wall. Your standard Ingress or Gateway routes traffic to pods based on HTTP path or headers. Round-robin distributes load across replicas. Everything looks fine from the control plane perspective. But your GPU utilization is uneven, some replicas are getting hammered while others sit idle, latency is unpredictable, and you have no way to differentiate a low-latency interactive chat request from a background batch job that can afford to wait.&lt;/p&gt;</description></item></channel></rss>