· ai-devtools

Busy GPUs can hide slow AI inference on Kubernetes

A Kubernetes cluster can be healthy while the AI service running on it disappoints users.


A model might return its first token quickly but take too long to finish an answer. It might respond promptly and still give the wrong answer. And a busy GPU tells the operations team little about either outcome.

The operational challenge is connecting AI service behavior with the Kubernetes, GPU, compute, storage, and network conditions behind it—not viewing each layer in isolation. That's why you should measure an inference service before production, then compare live behavior with the baseline. Inference adds a further question: Does the whole service deliver a useful result at a cost and speed the business can support?

Earlier in this series: - Part 1: Developers and platform teams both want Kubernetes self-service. They disagree on who owns it. - Part 2: A live Kubernetes cluster can still have an ownership gap - Part 3: Your Kubernetes dashboard is green. Start with the experience, then establish a baseline For a conversational service, Bogoevici recommends measuring time to first token, time per output token, reliability, capacity, resource efficiency, cost, and answer quality.

Related coverage

Also worth reading

  1. Angular 20.3.35 and 21.2.26 released, fixing downgraded component template compilation
  2. next.js 16.4.4 released
  3. KloudStax CTO details first ten lines of command policy for AI coding agents
  4. Byoky, open-source wallet, stores OpenAI, Anthropic, Gemini AI API keys on device
  5. India floats AI plan under which ‘The model travels to the data, rather than the data travelling to the model’