A team can look at the cloud bill and know GPU spend is climbing. That does not mean they know which node, pod, volume, or workload should be changed. The missing piece is usually not another dashboard. It is a short, local evidence trail that an operator can trust.

What changed in this release

v2.9.21 adds two scan paths that are meant to be used together:

  • Local AI device scan: checks local NVIDIA and AMD runtime signals for idle or inefficient GPU use.
  • Kubernetes GPU summary: compares node GPU capacity with pod requests and limits, so reserved capacity is easier to explain.

The release also adds report output that is easier to hand to a platform or FinOps review: what was found, where it came from, and what should be checked before action.

Why we built it this way

GPU waste often hides behind container scheduling. A node can look busy while expensive capacity is reserved by the wrong workload. A persistent volume can outlive the job that created it. A LoadBalancer service can stay up after the team that needed it moved on.

Cloud Waste Scanner now reads more of that context without asking you to install a hosted collector. It uses local runtime checks and read-only Kubernetes access, then keeps the scan output on the operator machine unless you export it yourself.

What to look for first

  • GPU devices that are allocated but show little useful activity.
  • Pods with GPU requests or limits that do not match actual usage patterns.
  • Persistent volumes and claims that look disconnected from active work.
  • Services and ownership gaps that make cleanup hard to approve.

The point is not to auto-delete anything. The point is to get from "the AI bill is too high" to a reviewable list of specific resources.

How to run the scan

  1. Open AI Device Scan in the desktop app.
  2. Run the local device scan to collect GPU runtime evidence.
  3. If you are reviewing a Kubernetes environment, run the Kubernetes inventory scan as well.
  4. Compare runtime findings with pod requests, limits, volumes, and service exposure.
  5. Export the report for the weekly platform or cost review.

Local API additions

For teams that already automate reviews, the same data is available through the local API:

  • GET /v1/ai/devices: list detected local runtime devices.
  • POST /v1/ai/scans: start a local AI device scan.
  • GET /v1/ai/findings: read AI runtime findings.
  • GET /v1/ai/recommendations: read recommendations linked to findings.
  • GET /v1/k8s/gpu-summary: compare GPU capacity, requests, and limits.
  • GET /v1/reports/ai-governance: generate a review-oriented report.

Trust boundary

The scan uses local execution and read-only access. Your kubeconfig, runtime signals, and scan results do not need to leave your environment. If a report is shared, that is an operator decision, not a requirement of the scan.

Bottom line

This release is for teams that need a practical first pass on GPU and Kubernetes waste. It will not replace a capacity planning process, but it should make the first review faster and less speculative.