When our platform team was asked to host open-weight models for three product teams, the inference engine was the easy choice: vLLM, which most teams already used locally. The open question was everything around it. Who creates the pods, who decides how many replicas run, how a 70B model spread across GPUs is scheduled, and how an upgrade rolls out without dropping streams. On Kubernetes the two common answers are KServe, a Kubernetes-native model serving control plane, and KubeRay, an operator...
Serving LLMs on Kubernetes: KServe vs KubeRay with Ray Serve for vLLM inference
Both KServe and KubeRay can put vLLM behind an OpenAI-compatible endpoint on Kubernetes. They differ in who owns the control plane, how scaling decisions are made and how multi-node models are handled. We ran both for the same model and this is how we chose.
This is a paid story
Subscribe to read the full content, access all paid stories, and support the authors.
Add a label
Embed this post
<iframe src="https://www.hibug.me/serving-llms-on-kubernetes-kserve-kuberay" width="700" height="420" frameborder="0" loading="lazy"></iframe>
I am a Senior Software Engineer with over a decade of hands-on experience building, scaling, and maintaining complex systems across the full stack—spanning frontend, backend, and DevOps. Over the last 10 years, I have navigated diverse architectures and untangled some of the most frustrating, elusive bugs in production. I believe that every production incident is a massive learning opportunity. Having discovered hibug.me, I am excited to contribute to this knowledge base, breaking down root causes, and sharing verified fixes to help fellow developers debug faster and build more resilient systems.
Related Stories
GPU inference never scaled under load: HPA on CPU for a GPU-bound LLM server
Istio 503 "upstream connect error" in the first seconds of every pod: app started before the proxy
Comments
0No comments yet. Be the first to comment!
Sign In to post a comment.