Red Hat AI 3.5 adds native, priority‑aware multi‑tenant GPU scheduling, safety benchmarking, and real‑time observability to the Red Hat AI platform. The change gives engineering and security teams the ability to isolate workloads, enforce priority rules, and audit GPU usage without provisioning separate hardware for each tenant.
What Changed in Red Hat AI 3.5
The new release introduces three concrete capabilities:
- Priority‑aware GPU allocation: every inference request is evaluated against a priority policy, allowing high‑value workloads to pre‑empt lower‑priority jobs on shared GPUs.
- Native multi‑tenant isolation: hardware‑to‑software isolation is built into the platform, preventing one tenant’s data, models, or compute environment from being accessed by another.
- Operational guardrails: EvalHub provides pre‑deployment model verification, while dashboards expose inference health, GPU utilization, model performance, and per‑user token consumption for showback.
Why the Change Matters to Engineers
AI engineers, platform teams, and SREs often struggle with two competing pressures: maximizing expensive GPU utilization and guaranteeing that a misbehaving experiment cannot impact production services. By turning each GPU request into a priority decision, Red Hat AI 3.5 lets teams:
- Run experimental notebooks on spare capacity without risking latency spikes for critical inference.
- Demonstrate compliance with internal or regulatory safety checks through EvalHub’s benchmarking.
- Provide finance or security auditors with concrete evidence of who ran what, when, and at what cost.
Architectural, Implementation, and Security Implications
Adopting the new platform requires revisiting several layers of the stack:
- Resource planning: capacity models must incorporate priority tiers rather than a simple headroom calculation. Teams should define priority classes that map to business SLAs.
- Isolation strategy: the platform’s built‑in isolation replaces ad‑hoc VM or container boundaries. Engineers should verify that the isolation mechanism aligns with their data‑handling policies, especially for regulated data.
- Observability pipelines: the new dashboards expose GPU metrics and token consumption. Integrating these feeds into existing monitoring (Prometheus, Grafana, etc.) will enable automated alerts on priority violations or unexpected usage spikes.
- Showback and chargeback: per‑user token consumption can be used for internal cost allocation. Implementing a downstream billing process may be required to close the loop.
Security teams should note that the platform’s “fair‑share GPU scheduling” and admission control are the primary enforcement points for isolation; they do not replace network‑level segmentation or secret management, but they reduce the attack surface by limiting cross‑tenant visibility at the hardware level.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
When evaluating Red Hat AI 3.5, start by mapping your existing GPU workloads to priority classes and confirming that the platform’s isolation meets your compliance requirements. Extend your monitoring stack to ingest the new observability streams, and set up alerts for priority breaches. Finally, treat the showback data as a feedback loop for capacity planning and cost optimisation.