GPUs are a critical yet expensive commodity for AI workloads. Justifying their high cost requires maximizing utilization. To keep things in focus, we are not discussing token consumption or tokeneconomics here; This is about GPU optimisation (at the infra and platform). In this post I will describe an approach to building an optimized GPU-as-a-Service using the below key components: GPU Sharing : Increases workload density and optimising GPU usage. Model As A Service (MaaS) : Standardizes and centralizes model deployment and consumption. Kueue : Controls prioritisation, duration and placements of GPU workloads. Self serve : Enables different roles to self serve to utilise GPUs available within the organisation for usecases. GPU Sharing + MaaS + Kueue + Self-Serve = GPU-as-a-Service Solution overview: Demonstration of GPU-as-a-Service in action: Let's dive into the bits now. GPU Sharing: The reason for GPU Sharing is pretty simple. More efficient use of GPUs + Fewer GPUs p...
AI agents are rapidly transforming software engineering—introducing new architectural patterns, terminology, and operational workflows designed to automate repetitive tasks. One of the most compelling emerging use cases is Agents for Ops . In this post, I share my journey building a Kubernetes namespace monitoring agent. Think of it as a digital intern performing Level 1 SRE tasks: it monitors K8s workloads and automatically remediates failures strictly within the guardrails of a provided knowledge base—nothing more, nothing less. I built 2 agents: 1 for K8s namespaces per cluster and 1 for VMs fleet; but to keep this post short I will focus on the k8s-namespace-monitoring-agent. The Demo: OpenClaw: Kagenti: The usecase: My usecase is simple: The Environment: Two workloads (a web server and a database-backed microservice) running on OpenShift, with a "Chaos Monkey" injecting random failures to simulate real life application failures. The Knowledge Base: A mapping of known...