A voice agent can understand a customer perfectly and still deliver a poor experience. If it takes too long to respond, struggles with an interruption or mispronounces a name, the interaction breaks down. In a real-time conversation, intelligence is only useful if it arrives at the right moment.
This is one of the problems that makes building AI systems fundamentally different from simply building larger models. For businesses deploying AI, the relevant question now is how much useful performance it can deliver within the available compute, time and cost constraints.
This is also why smaller, specialised models are becoming an important part of India’s AI strategy.
The shift does not suggest that large foundation models have outlived their usefulness. They remain important for complex reasoning, broad knowledge and tasks that require general-purpose intelligence. But not every application needs that level of capability. A voice agent, for instance, needs to generate natural speech with consistent pronunciation and low latency. An enterprise document-processing system needs to extract specific information accurately and reliably. In these cases, a model designed around the task can be more practical than a general-purpose model carrying capabilities the application rarely uses.
The distinction matters particularly in India, where the economics of AI deployment are shaped by infrastructure availability, compute costs, linguistic diversity and the scale at which applications need to operate. Developing indigenous AI capabilities cannot be only about replicating the largest models. It also requires building systems that can be deployed affordably, serve specific use cases and perform reliably under real-world conditions.
Initiatives such as the IndiaAI Mission recognise this need by supporting the development of indigenous AI capabilities across different model sizes and applications.
The engineering case for specialisation
A smaller model is not automatically an efficient model. Parameter count is only one part of the equation. Architecture, training data, inference optimisation and the surrounding infrastructure all determine how much compute a model consumes and how well it performs.
Techniques such as quantisation, pruning and knowledge distillation can reduce a model’s computational requirements. But these methods are not substitutes for designing around the workload from the beginning.
We encountered this directly while building our next-generation real-time voice model. Having had control over the model and the complete inference pipeline, we optimised for the requirements of real-time speech generation.
One important design decision was to separate phonetic information from voice identity. Pronunciation, language-specific characteristics and prosody need to be handled without compromising the identity of the selected voice. This becomes particularly relevant in multilingual environments, where speakers may switch between languages within a sentence. A system must handle that transition without introducing inconsistent pronunciation or accent bleed.
We also had to account for the less obvious complexities of spoken language. Numbers, currencies, dates, addresses and pincodes need to be normalised correctly before they are converted into speech. Conversational delivery requires the model to interpret context and determine where emphasis, pauses and changes in pacing belong. These are not simply matters of generating audio; they are requirements that need to be reflected in the model’s design and training.
The infrastructure presents another challenge. We think about compute in two distinct workloads: training and inference. Training happens in scheduled bursts, often on reserved GPU capacity. Inference is different. It involves serving live traffic continuously, with capacity requirements that fluctuate across regions and workloads.
The challenge is matching compute capacity to actual demand while minimising idle hardware. A lightweight architecture makes a material difference here: it allows us to deliver the required performance without provisioning the infrastructure that a larger model might demand. Distributed inference across geographies also helps us serve users closer to where requests originate, supporting more consistent performance.
This distinction between training efficiency and inference efficiency is important. A model may be expensive to train but economical to run, or relatively inexpensive to train but costly to serve at scale. For a commercial AI application, the latter can become a significant constraint because inference happens every time a user interacts with the system.
Measuring intelligence differently
The industry will need to reconsider how it evaluates model performance. Parameter count and benchmark scores tell us something about capability, but they do not tell us the full cost of delivering that capability to a user.
For an application developer, other measures matter just as much: latency, task completion accuracy, reliability under concurrent workloads, infrastructure utilisation and the cost per successful interaction. A model that performs marginally better in isolation may be a worse choice if it requires substantially more compute or introduces delays that undermine the user experience.
This does not mean every workload should be handled by a small model. Complex reasoning may still require a larger model, while other parts of the same application can be handled by smaller, specialised systems. Increasingly, production AI will rely on combinations of models, with each assigned work suited to its capabilities and cost profile.
India has an opportunity to contribute to this shift. Its linguistic diversity, varied operating environments and cost-sensitive markets create demanding conditions for AI systems. Solving for these conditions requires more than access to compute or the ability to train models at scale. It requires engineering models around the environments in which they will actually be used.
Smaller models are not the destination in themselves. They are part of building AI that can work at scale.