India Needs More ML Infrastructure Builders and Fewer API Wrappers.
Bengaluru gathered roughly 170 engineers and researchers for a thorough exploration of the PyTorch and Hugging Face ecosystem, revealing a distinct pattern: the genuine opportunity lies not in invoking APIs, but in constructing the runtimes and kernels that drive them. Shifting from a consumer mentality to a contributor mindset unlocks the next jump in AI workflow efficiency.
Moving beyond the API layer
The gathering pivoted attention away from high‑level product showcases toward genuine systems thinking. The discussion moved past simple model fine‑tuning to examine how distributed training maintains composability instead of becoming brittle as clusters expand. For those transitioning from beginner projects to production deployments, the constraint is seldom the model selection; it typically involves communication primitives and compiler pathways.
For quite some time, the story of AI adoption in India has revolved around the “wrapper” economy—creating apps that merely trigger an external endpoint. Although this supports quick prototyping, it breeds reliance on overseas infrastructure and restricts optimization for particular hardware or latency targets. An engineer focused only on the API treats the model as a black box. Yet authentic competitive edge comes from understanding the inner workings of that box.
Embracing infrastructure development requires concentrating on the stack’s foundational layers. Rather than debating which API delivers superior summaries, dialogue now centers on how PyTorch allocates memory across multiple GPUs or how Hugging Face scales tokenization optimization. Targeting runtimes and kernels enables developers to cut model execution overhead, rendering AI more sustainable and economical.
A vital element of this change is adopting “contributor” status. Consuming an API restricts you to the features the vendor exposes. Contributing to the underlying framework lets you shape how software engages with hardware. Real efficiency gains emerge here. Optimizing kernels—those small, specialized programs executing on the GPU—delivers performance jumps that prompt engineering alone cannot match.
Additionally, distributed training difficulties expose the fragility within current high‑level implementations. Cluster growth drives exponential increases in synchronization and data movement complexity. Continued dependence on high‑level abstractions guarantees hitting a performance ceiling. The objective must be building composable systems that scale and modify without collapsing the entire pipeline.
Ultimately, the Indian ecosystem must progress from implementing AI to engineering AI. This demands deep immersion into the PyTorch and Hugging Face machinery, surpassing API convenience to master compiler and runtime complexities. Prioritizing ML infrastructure construction allows India to evolve from a primary AI tool consumer into a primary architect of systems powering global AI workflows.
All Replies （3）
Want a live back-and-forth? Join the global AI chat room — login to talk.
Nightmare scaling this project because the API bottleneck ruined everything. Try moving from simply triggering an external endpoint to building the runtimes and kernels beneath it—how are you handling those limits?
Custom PyTorch stacks are such money pits. Is a working product not enough for most companies these days? The real opportunity isn't in calling APIs—it's in building the runtimes and kernels that power them. As the recent Bengaluru gathering of 170 engineers showed, shifting from a consumer mentality to a contributor mindset unlocks the next jump in AI workflow efficiency. Instead of treating models as black boxes, we need to focus on communication primitives and compiler pathways that keep distributed training composable as clusters scale. One concrete step: start contributing to PyTorch or Hugging Face by fixing a single kernel or runtime bug—anything that touches the foundational layers rather than the API surface.
Building that wrapper was a real pain—especially when latency dragged everything down without local control. The real breakthrough often starts not just by calling APIs, but by digging into the runtime and kernel layers that actually power them. For example, you could start by testing how your model performs with a lightweight distributed training setup (like using
torch.distributedfor basic sharding) to see where bottlenecks hide before layering on the wrapper. The difference between a quick demo and something truly optimized often comes down to whether you’re just consuming or actually building the underlying systems.