14 years. 28,000 sq ft. 300,000+ devices. From desktops to data center — designed, engineered, and manufactured in India.
Why choose RDP14 product categories across compute, AI, and data center. Deployment-ready from our 28,000 sq ft facility.
Download Product CatalogEnd-to-end AI compute under one sovereign umbrella. Designed here. Manufactured here. Supported here.
Talk to a Solutions ArchitectWarranty. SLA. On-site service. Account management. Every commitment documented, every response time defined.
Download SLA CommitmentISO 9001. PLI 2.0. SOP-led manufacturing. The systems behind every device we ship.
Our Story
Home / RDP AI Labs
We engineer the machine—then prove it on the workload.
RDP AI Labs is where our AI hardware is designed and where it is measured. We engineer platforms to open and reference architectures for the lowest cost per useful token, build them in our own Hyderabad plant with ODM and component partners, and validate them on real workloads—ours and yours—before anything ships.
Platform engineering and workload validation, in one place, attached to a factory that builds what it specifies.
What the lab does
The point of doing both is that the team deciding what goes into an RDP system is the team that defends it on the bench.
The lab
We decide what RDP's AI systems are made of, and why. Accelerator, host platform, memory and cache strategy, storage, fabric, cooling, power and the software baseline—chosen against a written design brief rather than a vendor deck.
The bench
We measure. Every RDP platform is benchmarked against its own design brief before it ships, on the same harness we make available to customers who want to prove a configuration on their own workload.
The lab · platform engineering
Four targets, written down before a bill of materials exists. A configuration that misses any of them is not a cheaper product—it is a different product, and we say so.
Not the lowest sticker price. A system is specified against the work it will actually serve—tokens, images, simulations—at a fully-loaded rupee cost including power and amortisation. A cheaper rack that serves fewer tokens per rupee is the more expensive machine.
Thermal margin at the intended rack density, not at bench idle. Serviceable parts, documented failure behaviour, and a burn-in that runs long enough to find what a short test misses.
Designed and integrated in India, supportable in India, with an auditable bill of materials. Sovereignty is a supply chain and a service model, not a label applied at the end.
Itemised BOM, INR pricing, GeM route available for public-sector buyers, and a specification a technical evaluator can check line by line without a sales call.
The decision framework
Ten layers, ten decisions, each with a reason behind it. Where a layer is also a cost-per-token lever, the deck below takes it apart.
| Layer | The decision | What drives it |
|---|---|---|
| Accelerator | GPU, dedicated inference silicon, or edge module | Workload shape and how mature the toolchain is for the part. The fastest part is not the right part if the software is not there. Lever 01 → |
| Host CPU | AMD EPYC or Intel Xeon | Lanes per accelerator, memory channels, NUMA layout — and per-core licensing. Lever 06 → |
| Memory | Capacity, bandwidth, or tiering | Whether the workload is capacity-bound or bandwidth-bound. Lever 03 → |
| Cache strategy | HBM only, or tiered KV-cache offload | Context length and concurrency, and how much of the cache truly has to stay resident. Lever 03 → |
| Storage | NVMe scratch, parallel file system, object tier | Checkpoint bandwidth and restart cost, not capacity alone. A GPU waiting on storage is the costliest idle asset in the building. |
| Fabric | InfiniBand, RoCE, or a single scale-up domain | The collective pattern, and whether the job leaves one box at all. Lever 07 → |
| Cooling | Air, rear-door heat exchanger, or direct liquid | Rack density and the building it lands in. The facility usually decides before the datasheet does. Lever 08 → |
| Power | Topology, phasing, redundancy | Measured sustained draw rather than nameplate, and headroom for the next node. Lever 09 → |
| OS & stack | Distribution, kernel, driver and container baseline | Combinations validated to work together, plus a versioning policy so a rebuild in twelve months reproduces the machine we shipped. Lever 04 → |
| Form factor | Workstation, 2U–8U server, or rack-scale | Where the workload sits today and how it grows. The growth path is part of the specification, not an afterthought. Lever 10 → |
Value engineering
Only the second number decides whether a machine was worth buying — so it is the number we engineer against. It decomposes.
Eight terms. Ten levers. No orphans.
Every lever below moves one of these terms, and every term has a lever against it. The token is the unit because measured inference is where we set the bar; write frames, concurrent streams, training steps or seats in its place, for your workload, and the fraction does not change. A machine that serves one person is judged in a different currency — latency, privacy, watts at the seat — and it is engineered on the same bench. A decision that does not move a term on this page is not value engineering, it is preference.
Costs add. Output multiplies — the capital line is committed the day the purchase order is signed; energy, cooling and support keep accruing for as long as the machine runs, and the denominator has to be earned every hour after.
How we build
We are not trying to reinvent the rack. We build to published modular and open architectures, and compose the rest with ODM and component partners already excellent at their layer.
What we build to
How we compose
Design to line
Six gates.
Targets set before parts are chosen.
The decision framework, layer by layer.
First article on the bench.
Measured against its own brief.
Made repeatable.
Into the catalogue.
The bench · workload validation
Everything the lab uses to prove an RDP platform is available to prove a configuration against yours—before you commit capital to scale. On-site in India, or over scheduled remote access.
Your team works alongside ours on the bench. Best when you expect to change the configuration mid-session, want to see the thermals yourself, or need a decision in the room rather than a report three weeks later.
Booked access to lab hardware so your engineers run their own harness on their own terms, without travel. Best when the workload is already scripted or your people are distributed.
A representative workload, a dataset or a shape-matched substitute if the real data cannot leave your estate, the target you are trying to hit, and the constraints you already know—power per rack, cooling, floor space, timeline.
A written benchmark report with the method published alongside every number, the test harness so your engineers can reproduce and challenge it, and a bill of materials sized against what was measured.
The instrument set
Each of these is a question with a measurable answer, and an expensive one to get wrong after the hardware has landed. One instrument set serves both sides of the lab: what we run against a candidate design is what your session reports. The harness ships with the results—an unreproducible number is marketing.
| Metric | What it actually tells you | Why it decides the outcome |
|---|---|---|
| What it costs | ||
| Cost per million tokens↓ lower is better | Fully-loaded rupee cost of served output, including power, cooling and amortisation. | The number a CFO can compare against a cloud invoice. It is the design brief in one figure. |
| Cache hit rate and reuse↑ higher is better | How much of the KV working set is served from the fast tier rather than recomputed. | The lever behind memory tiering. It converts directly into tokens per rupee on long-context work. |
| What it produces | ||
| Tokens / sec / GPU↑ higher is better | Serving throughput normalised to hardware at a stated batch size and context length. | A necessary normalisation when comparing like hardware at a stated batch size and context length. Cost per million tokens is what settles comparisons across different hardware. |
| Model FLOPs utilisation↑ higher is better | How much of the silicon you are paying for is doing useful mathematics, as a fraction of dense peak at the training precision. | A widely used efficiency number in training. A low figure means you are about to buy capacity you will not use. |
| Scaling efficiency↑ higher is better | Throughput retained going from one node to N. | Exposes fabric and topology mistakes that no single-node test will ever reveal. |
| Collective bandwidth↑ higher is better | Measured all-reduce and all-gather bandwidth across the fabric. | The ceiling on distributed training whenever the job is communication-bound, and the one rarely tested before purchase. |
| Storage throughput↑ higher is better | Whether the data path sustains the accelerators or starves them. | Starved accelerators cap every number above this row. |
| What the user feels | ||
| Time to first token↓ lower is better | How long a user waits before anything appears, at target concurrency. | Decides whether an internal assistant gets adopted or quietly abandoned. |
| p99 latency↓ lower is better | The tail experience under load, not the average. | Averages hide failures. Users and SLAs live in the tail. |
| Whether it holds up | ||
| Checkpoint time↓ lower is better | Write and restore duration at your model size. | Determines what a failure costs you and how often you can afford to save. |
| Job failure rate↓ lower is better | Interruptions and restarts per thousand GPU-hours. | Sets the effective capacity of the cluster, as opposed to the nameplate capacity. |
| Sustained power and thermal margin↑ more margin is better | Draw per rack under continuous load, and the headroom left before throttling. | Separates a burst benchmark from a machine that holds its numbers on day ninety. |
Starting points
Reference designs, sized to you. Each stands on a configuration we have already benchmarked and locked at the component level; the sizing—nodes, memory, storage, fabric—is what your workload settles on the bench. Full bills of materials live on the data centre and AI infrastructure page.
For: universities, R&D groups, platform teams
For: enterprises serving internal AI to production users
For: AI teams, neoclouds, national and research programmes
Honest scope
RDP is a hardware OEM. We design, build and support the machine and the rack around it. We are not the right people to write your retrieval pipeline.
RDP delivers
Specialist partners deliver
We work alongside system integrators and AI consultancies rather than competing with them, and we benchmark on behalf of partner engagements already under way.
Why RDP AI Labs
Fourteen years designing and manufacturing computing hardware in India. AI Labs is where the next generation of it is engineered and proven—one design team, one factory, one contract.
Every layer of the platform is a decision we take and defend with measurements. We design to the NVIDIA MGX modular reference architecture and follow OCP Open Rack conventions so the work composes with the rest of the industry instead of stranding you.
No overseas benchmarking queue, no shipping your data across borders to get a number, no waiting on a regional lab slot that belongs to a larger account.
A 28,000 sq ft facility in Hyderabad, 300,000+ devices shipped, 1M+ end users. The system on the bench is not a loaner from a distributor—it is the thing we build or are qualifying to build, so what you validate is what you receive.
Platform certifications and partner-programme memberships are listed on request, with the certificate or catalogue listing behind each one. We publish what we hold and do not imply what we do not.
Designed and built in India, supported by an Indian entity, with spares and engineering in-country. For public-sector and regulated buyers that is not a marketing line—it is who holds the design, the build record and the phone number.
Itemised bills of materials, rupee pricing, GeM route for public-sector buyers, and standard systems purchasable online at RDP GPU Mart. Finance and procurement can see line by line what they are approving.
Questions we get asked
Talk to the lab
A short brief is enough—a workload to benchmark, a configuration to argue out, a component to evaluate. An engineer reads it and replies with a plan, or the questions to write one.
RDP AI Labs
One brief—the lowest cost per useful token, held reliably, sovereign-ready. Bring us a workload and we will measure it against exactly that.
