India is committing serious public and private capital to AI infrastructure. The IndiaAI Mission has put GPU capacity at the centre of national policy, state digital missions are writing AI into their hardware plans, and the Government e-Marketplace now carries infrastructure that did not exist as a category three years ago.
The specifications are getting better. The proof is not. Most Indian AI tenders describe accelerators, rack power and cooling in careful detail, and then say almost nothing about how the delivered system will be shown to do the work it was bought for. That silence is where sovereignty is actually decided.
The spec sheet is not the machine
A datasheet describes a component under conditions your data centre will never reproduce.
Peak throughput assumes a clock the accelerator holds for seconds, not for a training run. Rated power assumes an inlet temperature your comms room may not sustain in a Hyderabad May. Published benchmark figures assume a model, a batch size, a context length and a latency target that are almost certainly not yours.
None of this is dishonest. It is simply what a datasheet is for. The failure is procedural: we treat the number as a commitment when it is a boundary condition.
The gap shows up in a specific, expensive way. A cluster is delivered, powered, and signed for. Six weeks later the platform team discovers that sustained throughput on the actual workload sits well below the figure the business case assumed. By then the capital is committed, the warranty clock is running, and the only remaining lever is to buy more hardware.
What Indian tenders currently ask for, and what they leave out
Specification maturity and verification maturity have moved at different speeds.
| Usually specified | Usually absent |
|---|---|
| Accelerator model, count and memory | Sustained throughput on the buyer’s own workload |
| Host CPU, RAM, storage capacity | Achieved versus peak, measured and distinguished |
| Fabric type and port speed | Measured collective bandwidth across the delivered fabric |
| Rack power envelope and cooling type | Sustained clock under thermal load at the intended density |
| Warranty duration and response SLA | Acceptance criteria that trigger rejection |
| Delivery timeline | Where validation happens, and who witnesses it |
| Make-in-India and BIS compliance | Whether the buyer can re-run the test themselves |
Read the right-hand column as one question: if the system underperforms, what did the buyer agree in advance would count as evidence? In most contracts the answer is nothing.
This is not carelessness. AI infrastructure arrived as a procurement category faster than the templates that govern it. A tender for desktops or servers can lean on decades of accumulated practice about what a reasonable acceptance test looks like. A tender for a GPU cluster serving a large language model has no such inheritance. The specification sections were updated because vendors supplied the vocabulary. The acceptance sections were not, because nobody did.
Sovereignty is a verification question, not only a manufacturing one
A system designed elsewhere, benchmarked elsewhere and assembled here is not sovereign in any sense that survives a failure at 3 a.m.
The Make-in-India conversation has focused, correctly, on where hardware is manufactured, and BIS and Trusted Sources have given that conversation teeth. We have argued the manufacturing case ourselves in the case for India’s on-prem AI stack.
Verification is the half of the argument that has not been made. Consider what it means when no in-country bench exists for a class of system:
- The buyer accepts a vendor’s benchmark, run on a configuration they have never seen, on a workload that is not theirs.
- Any dispute about performance is arbitrated using the vendor’s own instrument set.
- Re-testing after a firmware, driver or model change means shipping data abroad, joining a queue, or doing without.
- Data that cannot legally leave the country cannot be used to validate the machine that will process it.
Point four is not hypothetical. For regulated buyers in banking, health and government, the datasets that would make a benchmark meaningful are precisely the datasets that cannot travel. A validation capability that only exists offshore is, for those buyers, no validation capability at all.
What a real acceptance test specifies
Write the test into the tender, not into the escalation email.
An acceptance clause that actually protects the buyer names five things:
- The workload. The buyer’s model, or a shape-matched substitute where the real data cannot be used, at the buyer’s context length and concurrency.
- The metric and its basis. Sustained tokens per second at a stated latency target. Achieved, not peak, and labelled as such.
- The conditions. Intended rack density, inlet temperature, and duration long enough for thermal behaviour to appear. A test that ends before the accelerator settles at its sustained clock has measured nothing useful.
- The harness. Delivered to the buyer, so the test can be re-run after any firmware, driver or model change, and so a dispute has a shared instrument.
- The consequence. What happens if the number is missed. Remediation, re-test, or rejection, agreed before delivery rather than negotiated after it.
None of this is exotic. It is ordinary engineering discipline, of the kind already documented in the public literature on cluster commissioning. What is unusual in India is writing it into a purchase contract.
There is a second question hiding inside the first: who watches the test. A number produced by the vendor, on the vendor’s schedule, with the buyer reading a report afterwards, is a different artefact from a number produced with the buyer’s engineers in the room and the harness running on their own machine. Neither is dishonest. Only one of them is evidence.
For public buyers the distinction carries procedural weight. A tender that names the metric but not the witness leaves the evaluating committee holding a supplier’s assertion at exactly the moment it needs an auditable record. Naming the witness costs nothing at drafting time and is close to impossible to add once the system is on the floor.
Where the capability has to sit
In-country validation is infrastructure, and somebody has to own it.
The awkward part of this argument is that acceptance criteria are only as good as the place they can be exercised. A tender can demand a measured number; if there is no bench in India capable of producing that number on the buyer’s data, the clause becomes decorative.
This is why we built RDP AI Labs, and why it sits on the new-product development floor of our own plant in Hyderabad rather than in a separate facility. The same bench that specifies an RDP platform is the bench a customer can bring a workload to. Fourteen years, 300,000+ devices shipped and a 28,000 sq ft plant give us the manufacturing half. The lab is the verification half, and it is the half the Indian market has been missing.
The commercial shape matters as much as the capability. A validation session is scoped and quoted before it starts, the report states the method alongside every number, and the harness goes to the customer’s engineers so they can reproduce and challenge the result. If the honest answer is that a smaller configuration clears the bar, the report says so.
What to do before your next AI tender closes
Three changes, none of which requires a larger budget.
- Add an acceptance clause with a named metric, measured on your workload. If a bidder cannot commit to a sustained figure at your latency target, that is information you wanted before signing.
- Require the harness as a deliverable. A number you cannot reproduce is a claim, not a measurement.
- Ask where the test will physically happen, and whether your data can legally go there. For regulated buyers this determines whether the clause is enforceable at all.
For the wider economics of running this hardware once it lands, we set out the arithmetic in the real cost of moving GPU workloads on-prem, and the fleet-level comparison in five years of TCO data on Indian versus imported hardware. If you are still designing the estate rather than buying it, start with the CIO’s playbook for building an AI factory in India.
India will get the AI infrastructure it specifies. It will only get the performance it verifies.
Bring us a workload. RDP AI Labs runs customer validation on-site in India or over scheduled remote access, with the method published alongside every number. Bring the real dataset if it can travel, or a shape-matched substitute if it cannot; the second case is the one most regulated buyers are actually in, and it is the case the lab was built to handle.
