When more than 170 people gather in Bengaluru to discuss profilers, kernels, and GPU communication, the real signal is a shift from consuming models to building the systems that keep them running. The event co-hosted by Red Hat and Hugging Face included three speakers from Hugging Face and two from Red Hat's PyTorch engineering team, skipping demos to focus on what makes AI viable in production.

The central thread was explicit. India already has plenty of talent using models and building applications; the harder and more valuable transition is turning part of that base into maintainers and designers of profilers, runtimes, training abstractions, reinforcement learning tooling, and distributed communication libraries. This is not just a career issue: it is the difference between absorbing decisions made by core stack developers and participating in choices that determine cost, latency, and controllability of deployments.

Technically, the talks formed a single path. Aritra Roy Gosthipaty presented PyTorch profiling as a disciplined practice: annotate regions of interest, separate wait and collection phases, read traces to distinguish CPU bottlenecks from real GPU work. The idea of being overhead bound is central: many slowdowns do not come from the model but from CPU-side orchestration costs that only a profiler makes visible.

Adarsh then moved to LLM inference. The distinction between prefill and decode, with KV cache dominating decode costs, explains why serving engines are not an application detail but a systems choice. SGLang, with RadixAttention and prefix caching, turns repeated traffic structure into a real capacity advantage. The division of labor with Hugging Face Transformers matters too: models remain the source of truth, while serving engines build the fast path. For anyone evaluating self-hosted deployment, this is not theoretical detail: it means serving a long tail of models without hand-porting each one into a bespoke runtime.

The post-training section showed another growth axis. Adithya S Kolavi described RL environments as a combination of tasks, state, tools, observations, reward logic, and episode control. The shift from RLHF to programmatically verifiable rewards turns code repositories into potential sources of trainable environments, as with Repo2RLEnv. It is a signal for those building local infrastructure: training is not only about weights but about the ability to generate and orchestrate verifiable environments.

The final two talks, by Mansi Agarwal and Arkadip Maitra, touched the substrate of distributed training. DeviceMesh, DTensor, and FSDP2 promise composability where hand-crafted process groups were once required; zero-copy GPU communication shows that real efficiency lies in reducing costs in invisible layers. The acknowledged limits of DTensor, such as eager-mode overhead and incomplete operator coverage, give the picture credibility: this is not magic but an engineering direction.

The underlying thesis, introduced by Sudhir Dharanendraiah, is that India should not remain a large AI consumer. That position has structural implications. If the Indian community produces maintainers and designers of these layers, the open ML stack's center of gravity shifts and space grows for local and hybrid deployments not dependent on proprietary APIs. It is no accident that Red Hat, the open source company par excellence, invested here: the battle for stack control is fought in kernels and communication primitives, not in model advertisements.