Sovereignty is decided in the cable plant.

A sovereign AI cluster means the compute, the data and the operator sit under Indian jurisdiction — so a regulated Indian business can train and run models without its data leaving the country’s legal reach. That is a procurement and engineering problem long before it is a legal one, and most of it lands on the links between the GPUs.

A hall like this is mostly cable.

The GPUs get the budget and the headlines. What decides whether they reach their benchmark is the metre of copper or glass between them.

  • At 400G and abovethe margin between a link that works and one that retrains under load is small
  • And it is set byinsertion loss, the reach of the optics actually fitted, the temperature at the top of the rack at 3am
  • None of whichappears in the bill of materials

Sovereign is a supply chain, not a sticker.

If every spare optic is a six-week import and every fault needs an engineer in another time zone, the operator is holding risk that was supposed to be designed out.

We do the India side.

Architecture, design-in, integration, qualification and support — on local time, close to the clusters being built.

Illustrative visualisation. Not a Praverse facility — we supply and design in the interconnect, we do not operate data centres.

Four questions an operator should be able to answer.

“Sovereign” is doing a lot of marketing work at the moment. These are the questions that separate the ones who mean it from the ones who have put an Indian flag on a slide.

  1. 01

    Where does the data physically sit

    Not where the contract is signed — which racks, in which building, under whose operating licence.

  2. 02

    Who can be compelled to hand it over

    The operator’s jurisdiction decides this, and it is not always the same as the customer’s.

  3. 03

    How long is the supply chain

    A cluster that cannot be repaired without a six-week import is sovereign on paper and fragile in practice.

  4. 04

    Who answers at 3am

    Support in the same time zone is not a nicety at this scale; it is part of the availability figure.

Your GPUs are ready. Is the interconnect?

As clusters scale, the hardest decisions move to the links between everything — GPUs, NICs, switches, servers, the whole rack. Get them wrong and you rebuild, burn power, or watch a deployment window disappear. Get them right and everything downstream gets easier.

Inside the rack

Scale-up

GPUs and switches within the rack. Passive DAC where the run is short; ACC and AEC when the rack gets dense or the run gets long.

DAC · ACC · AEC

Between racks

Scale-out

Rack to rack and row to spine. Retimed copper to about 9 m, then AOCs and pluggable optics, with LPO where power matters.

AEC · AOC · SR / DR optics

Across the fabric

Scale-across

Between pods, halls and buildings. Single-mode DR and FR optics to 2 km, with coherent optics for the longest links.

DR / FR optics · coherent

  • Reach

    Match the medium to the distance at every hop. Over-engineering every link wastes money; under-engineering one link means a rebuild.

  • Power

    Every watt moving data is a watt not spent on compute. Copper where reach is short; low-power LPO optics where distance demands glass.

  • Qualification

    Weeks spent validating links are weeks closer to a missed deployment window. Retimed copper with proven link stability shortens bring-up.

The capacity is being built now.

India’s operational data-centre capacity is concentrated in a handful of markets, and our people are in four of the five largest — which matters, because interconnect is a job somebody has to do on site.

  1. Mumbai & Navi MumbaiPraverse team790 MW
  2. ChennaiPraverse team305 MW
  3. BengaluruPraverse team182 MW
  4. Hyderabad152 MW
  5. Delhi NCRPraverse team76 MW

Vadodara, Gujarat — headquarters, about 400 km from Mumbai. Not a capacity market, which is rather the point: the engineering sits close enough to reach the clusters, and the people sit in them.

Operational data-centre capacity by market. Source: MeitY (actuals, March 2026); Savills India (July 2025); Colliers (May 2025); Wood Mackenzie via IANS (July 2026). Forecasts vary widely.

Three situations we are built for.

Written as the shape of a real decision rather than as case studies: the question that gets asked, the constraint that turns out to be the real one, and what changes.

  • Illustrative scenario

    A training hall that is only as fast as its slowest link

    A multi-megawatt GPU hall in a western India colocation facility.

    The question
    The cluster benchmarks beautifully on a single node and badly across the fabric. Where is the time going?
    What actually bites
    At 400G and above, the margin between a link that works and a link that retrains under load is small, and it is set by things nobody put in the bill of materials: insertion loss across the patch panels, the reach of the optics actually fitted, the temperature at the top of the rack at 3am.
    What we do
    We qualify the interconnect against the topology it is going into rather than against a datasheet, and supply the copper and optical links that hold the margin at the distances that site really has.
  • Illustrative scenario

    An inference row that has to stay inside the country

    A few hundred kilowatts of inference capacity for a regulated Indian business.

    The question
    The workload cannot leave Indian jurisdiction. What does that change about the build?
    What actually bites
    Sovereignty is a supply-chain question long before it is a legal one. If every spare optic is a six-week import and every fault needs an engineer in another time zone, the operator ends up holding risk that was supposed to be designed out.
    What we do
    Programming, testing, labelling and qualification happen on the India side, and support answers on local time. The compute staying in India is worth less if the parts keeping it running do not.
  • Illustrative scenario

    The step from one pod to ten

    A build that worked at pilot scale and is now being multiplied.

    The question
    Everything was fine with one pod. Why is the second one harder than the first?
    What actually bites
    Pilots hide the cable plant. At ten pods the structured cabling, the breakout topology and the optics budget stop being procurement details and start being the thing that decides whether the cluster scales linearly.
    What we do
    We do the architecture and design-in before the order, not after it — link budgets, breakout plan, and a parts list that still makes sense at the tenth pod.

These are illustrative scenarios, not customers. We do not publish a client’s deployment without their written permission, and we will not dress a hypothetical up as a reference.

Don’t design around the cable. Design around the cluster.

Training clusters

Reach, power and density hit their limits at once. The fabric is designed around the GPUs before the rack is built, and today's choices are made with the next generation in view.

  • Reach
  • Power
  • Density
  • Interoperability

1.6T today. 3.2T on the roadmap.

Inference

Little room for wasted power or latency. Link distance, data rate, latency, power budget, port density, thermals and the deployment environment are all sized before a part is chosen.

  • Power
  • Latency
  • Reach
  • Density

Keep the power on compute.

At national scale

A great design is only the beginning. The interconnect has to qualify, repeat, ship and perform the same way across thousands of units — through architecture, design-in, production and delivery.

  • Qualification
  • Yield
  • Supply
  • Responsiveness

Same-day answers, not same-quarter.

Every way a switch port meets a ConnectX-8.

The ConnectX-8 SuperNIC brings 800G to the server on PCIe Gen6, in a single-OSFP card (C8180) and a dual-QSFP112 card (C8240). Against an 800G switch such as the Spectrum SN5600 there are four Ethernet configurations — and a DAC, ACC, AEC, AOC or LPO optic for each, chosen by the distance.

800G Ethernet to ConnectX-8
LinkResult
Switch → 1 × CX8 C8180800G OSFP to OSFP-RHSOne 800G link, or 2 × 400G
Switch → 2 × CX8 C8180800G OSFP broken out to 2 × 400GEach leg to its own NIC in 400G mode
Switch → 1 × CX8 C8240800G OSFP to 2 × QSFP112Both cages on one NIC, full 800G
Switch → 2 × CX8 C8240800G OSFP to 2 × QSFP112One 400G cage per NIC

From 224G to 448G per lane

Doubling the lane rate means new signalling, stronger error correction and moving the connection closer to the silicon. Copper keeps up — retimed 1.6T copper already runs 3 m at 18–20 W per end, against about 22 W for a 1.6T optic over 500 m — but where copper ends and optics begins keeps moving. The job is to measure that boundary for each build, not argue where it should be.

The layer underneath.

High-speed copper and optical interconnect for AI clusters, with our USA technology partner building the technology and Praverse doing the Indian architecture, design-in, integration, qualification and support.

We do not manufacture in India today. Local testing and qualification come first; assembly follows when volumes justify it. Phases 2 and 3 below are plans, not facilities.

The full photonics capability →

  1. PHASE 1 · NOW

    Supply and design-in

    Interconnect supplied with our US technology partner, with India-side programming, testing, labelling and qualification, and support on local time.

  2. PHASE 2 · NEXT

    Semi-finished assembly in India

    Assembly of semi-finished interconnect in India, close to the clusters being built.

  3. PHASE 3 · PLANNED

    Indian manufacturing

    An Indian manufacturing facility for copper interconnect first, then optical, as volumes justify it.

Building one?

Send us the topology and the distances. You get a written plan within two business days — link budgets, breakout plan, and a parts list that still makes sense at the tenth pod.