Máté Hajnal
Senior MLOps Engineer, CNCF-Volcano Core Contributor, LFX Mentor, Kubeastronaut
Kecskemét, Hungary
Actions
is a Senior Machine Learning Operations Engineer at Aumovio, following the spin-off of Continental’s automotive branch. With a background in DevOps and Platform Engineering at Red Hat and Nokia, he brings deep expertise in cloud-native infrastructure, Kubernetes, and scalable ML systems. Being a Golden Kubeastronaut, CNCF-Volcano Core contributor, and LFX mentor, Mate is an active member in the CNCF ecosystem and enjoys building bridges between data science, artificial intelligence, and modern operational practices.
Area of Expertise
Topics
Topology-Aware Inference: Connecting Kthena and Volcano
Distributed inference brings competing placement needs: workers benefit from fast interconnects, prefill and decode exchange KV cache, and independent serving instances need fault isolation. How can these requirements hold as a service scales and changes?
This session follows an inference service from workload definition to placement with Kthena and Volcano. We show how Kthena models serving groups and roles, and how Volcano combines hierarchical gang scheduling with multilevel network topology to place cooperating components. Concrete scenarios explore locality within worker groups, isolation across serving instances, and evolving support for group and subgroup affinity and anti-affinity. We also examine how scaling and rolling updates interact with these constraints.
Attendees will learn to translate inference architectures into scheduling policies and reason about trade-offs between communication locality, service availability, and capacity for growth.
GPUs Are a Scarce Resource: Lessons Learned from Multi-Tenant GPU Orchestration on Kubernetes
Kubernetes namespaces are a useful boundary, but they are not a complete multi-tenancy model. This becomes painfully visible when teams start sharing AI infrastructure, with different expectations around latency, cost, fairness, isolation, and scarce resources.
The hard part is not creating separate spaces for teams. The hard part is deciding what happens when those teams compete for the same accelerators, model endpoints, sandboxes, network paths, and latency budgets. Some workloads can wait in a queue or be safely preempted. Others need stronger guarantees. Agentic workloads add tool calls, model calls, memory stores, browser or code sandboxes, external APIs, and human-facing latency. Inference workloads add another twist, especially when patterns such as prefill/decode disaggregation make placement, locality, and capacity planning part of the serving path.
In this talk, we will look at why “one namespace per team” is not enough for multi-tenant AI platforms on Kubernetes. We will discuss hierarchical queues, PrioriyClasses, preemptable and non-preemptable workload classes, topology-aware scheduling, sandboxed execution, GPU scarcity, inference placement, and the operational limits of namespace-based isolation. Along the way, I will share the pitfalls we found ourselves in, and the questions that would have helped earlier: how to think about fairness before and after the cluster is full, how to separate workload guarantees before users lose trust, how to reason about topology before latency becomes mysterious, and what users need to understand when the platform says “not yet.”
The Hitchhiker’s Guide to Kubernetes Scheduling and Orchestration
Kubernetes scheduling looks simple from the outside: a Pod needs a node, the scheduler picks one. But real platforms quickly discover that “where should this workload run?” is not one question. It is many.
Batch jobs need queues and fairness. AI workloads need GPUs and gang scheduling. Multi-tenant platforms need quotas, priorities, preemption, and isolation. Edge or hybrid clusters need placement across failure domains. For agentic workloads everything is about latency. Some teams can stay with the default Kubernetes scheduler, while others eventually reach for Kueue, Volcano, custom scheduler plugins, deschedulers, autoscalers, or external orchestration systems.
In this talk, we will travel through several “worlds” of Kubernetes orchestration and scheduling. For each world, we will look at the problem it solves, the trade-offs it introduces, and when it is probably the wrong tool. The goal is not to crown one scheduler as the answer to everything, but to build a practical mental map for choosing the right orchestration pattern for your workload.
And yes, we will end up with 42 scheduling problems you should ask about before building your next platform.
Volcano: Orchestrating the Full AI Lifecycle – From Training to Inference and Agents
The rapid evolution of AI has led to infrastructure fragmentation, where training, inference, and agent workloads run in isolated systems, causing resource inefficiency. Volcano addresses this as a Unified Scheduling Platform for the full AI lifecycle, delivering robust scheduling capabilities with high throughput.
Volcano is evolving into the next-generation platform capable of orchestrating diverse workloads beyond batch jobs, enabling multi-scheduler coordination.
At the workload layer:
- Volcano-Global splits massive training jobs across clusters, removing single-cluster limits
- Kthena delivers enterprise-grade LLM serving with frameworks like vLLM
- AgentCube enables rapid agent workload scheduling
At the infra layer, Volcano provides modern resource abstraction through DRA integration, HyperNode discovery, GPU sharing, and heterogeneous pooling for efficient task-to-accelerator mapping.
Join us to explore how Volcano is shaping the future of Cloud Native AI infra.
More Than YARN on K8s: Unified Queuing for Mixed AI & Big Data Workloads
The greatest challenge in migrating YARN workloads to Kubernetes is perfectly replicating its robust multi-tenant capabilities. This session demonstrates how Volcano uses hierarchical queues as the cornerstone for multi-tenancy, providing granular quota management, fair-share scheduling, and powerful cross-queue elastic preemption.
But the true evolution lies in moving beyond YARN. We will then show how Volcano provides an advanced framework for heterogeneous hardware under a single, unified queuing system. We will dive deep into the scheduling capabilities that the YARN model lacks but modern AI platforms demand, including: tenant-to-hardware affinity, workload-aware resource isolation, and performance-driven topology awareness (for networks, GPUs, etc.).
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top