Compute & Cost
Shared Compute Across Departments: Feasible?
· 9 minute read
Sharing a GPU is easy. Sharing a purpose, a bill and a breach is not. Feasible when tenancy is hard, metering is dull, and one owner can say no.
Every state data centre conversation in 2026 reaches the same slide: one shared GPU farm, many departments, utilisation rescued, money saved. The slide is not wrong about idle cards. It is silent about the afternoon a scholarship embedding lands in a police collection because someone reused a key.
Shared compute is feasible. It is a product, not a slogan. The product has a tenancy design, a metering design, a purpose map, a denial right, and a story for DPDP roles when two fiduciaries sit on one card. If any of those is missing, you have not built a pool. You have built a corridor with a lock that everyone has copied.
This explainer is for SDC heads, departmental CIOs and finance officers who are being asked to contribute budget to a common cluster. It is not a design for an intelligence agency's air-gap. If your data class cannot tolerate a neighbour, do not share. Buy a smaller card and sleep.
What sharing is, in a sentence you can audit
Sharing means more than one administrative owner can submit jobs to the same accelerators, with isolation that survives a curious admin, a bad script and a vendor engineer, and with a bill that can be shown to two PAOs. If you cannot say that sentence, you are proposing hospitality, not a platform.
Isolation has layers: separate accounts, separate namespaces, separate keys, separate vector collections, separate log streams, and, when the data class demands it, separate nodes. Logical tenancy is cheaper. Physical tenancy is clearer. Mixing affidavits with a tourism chatbot on the same logical collection is how you get a newspaper.
DPDP does not forbid two departments from using one processor. It does require purpose, roles and security. A shared card is a processor relationship that needs a written map. We are all government is not a lawful basis and not a purpose.
Five tests before you pool money
Denial. Can the platform owner refuse a job that has no purpose tag or no gold set? If no, the pool will become a dumping ground and then a scandal. Metering. Can you show GPU-seconds, storage and egress per department without a vendor engineer? If no, the first reconciliation will end the friendship.
Break-glass. Who can open a tenant, from where, and how is it logged? If the answer is a shared sudo, stop. Exit. Can a department leave with its weights, objects and logs in 30 days? If no, the pool is a hostage. Calendar. Who wins when exams and budget close land on the same week? If the answer is we will coordinate, write a pre-emption rule now.
| Pattern | When it works | When it does not |
|---|---|---|
| SDC-operated pool, hard tenants, showback bills | Several departments with similar data classes and a real SDC owner | No owner, no meter, family access |
| One department hosts, others buy a slice | A written MoU, a denial right, a leave clause | A handshake in a corridor |
| IndiaAI as the shared burst | Eligible entities, dated reservations | Standing inference on citizen data you will not put on that cloud |
| Shared small-model inference, separate large-model bursts | Most traffic is extractive and dull | Every department thinks it needs the 70B all day |
Money, and the politics that eat the saving
The economic case is idle GPU and duplicate AMC. It is real. It dies when every contributor demands a dedicated node just in case and the pool quietly becomes three clusters with extra meetings. Write a minimum share and a maximum reservation. Charge for reserved slices whether they are used. Free reservations recreate idle inside the pool.
Showback first, chargeback later. Many departments cannot pay each other cleanly. A showback report that the finance secretary sees is often enough to shame idle. A premature chargeback without a treasury path is a reason to never join. Prcept will run an agent inside a tenant you control. We will not pretend a shared namespace is a tenant. If the SDC cannot show a deny-by-default key, we will recommend a dedicated small card for that workflow. Saving VRAM is not a reason to mix purposes.
What the MoU must say
Name the owner who can refuse a job. Name the meter and the showback cadence. Name the pre-emption rule for gazetted weeks. Name the exit days and the format. Name who is fiduciary and who is processor for each data class. Name the classes that will never share. If legal cannot put those sentences on a letterhead, you do not have a pool. You have a corridor with extra meetings.
Do not wait for a perfect treasury chargeback path. Showback that the finance secretary sees is enough to start. Chargeback can come later if the accountant-general's door opens. Metering cannot wait.
Objections you will hear — and what to do with them
These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.
We trust sister departments
Trust is not a control. Staff move. Vendors rotate. Keys leak. Build for the curious intern.
Sharing violates DPDP
Not automatically. Unmapped sharing with mixed purposes and no processor contract is the problem. Map it or do not share.
Chargeback is impossible in our treasury
Then showback, and let the finance secretary allocate. Do not use impossibility of chargeback as an excuse for no meter.
A shared cluster is sovereignty
A shared cluster is a utilisation tactic. Sovereignty is a control-plane story. Do not confuse the two.
A six-week feasibility file
- Weeks 1–2: list candidate departments, data classes and dated peaks. Mark any class that cannot have a neighbour.
- Weeks 3–4: design tenancy, keys, logs, denial, pre-emption and exit on two pages. If you cannot, stop.
- Weeks 5–6: run a tabletop: a wrong-collection write, a contested exam week, a department leaving. Write the MoU only if the tabletop is boring.
How this shows up in the file
Subject: Feasibility of shared GPU / AI compute for [departments].
Isolation model: [logical / physical / mixed]. Denial owner: [name]. Meter: [export described]. Pre-emption: [rule]. Exit: [days, format]. DPDP roles: [map]. Classes that will not share: [list]. Recommendation: [pool / dedicated / IndiaAI burst / mix].
This explainer is not legal advice and not a security accreditation. A corridor with copied keys is not a pool.
This article is informational field guidance for Indian public institutions, not legal, procurement, tax, accounting, tariff or engineering advice. Confirm against the current Gazette, GFR, GeM term, SERC tariff order, IndiaAI portal rule, CAG mandate, DPDP text, departmental finance manual and your counsel before you file it. Figures are methods and order-of-magnitude illustrations, not a dataset of real deployments and not a substitute for a live quote.
How to put this in the finance note
A P1 CIO/CTO searching “shared GPU government departments” needs a number a CFO can defend, not a GPU brand. “Shared Compute Across Departments: Feasible?” belongs in a cost model with people, power, idle time, AMC and the cost of a failed pilot.
Sharing a GPU is easy. Sharing a purpose, a bill and a breach is not. Feasible when tenancy is hard, metering is dull, and one owner can say no. IndiaAI subsidy, if you use it, is a live notice — not a permanent discount. On-prem TCO includes ops headcount. Do not invent Rs/hour. Cite the source of every rupee.
- Separate capex, opex, and one-time cleanup.
- Show utilisation, not just peak GPUs.
- Price the human fallback, not only inference.
- Date every tariff and subsidy assumption.
Close this loop before the next CAB
Put “Shared Compute Across Departments: Feasible?” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P1 CIO/CTO, not “the vendor.”
Revisit the item when the model, the GeM term, the region, or the SI changes. “shared GPU government departments” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.
What must be true before you file this
If “Shared Compute Across Departments: Feasible?” is only a heading, it will not survive a file inspection. A P1 CIO/CTO should be able to attach one artefact that proves “shared GPU government departments”: a log export, a clause, a scored row, a dated notice, or a refusal rule.
Write three dated sentences: what was decided, who owns it, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.
- Name the owner of “shared GPU government departments” inside the institution.
- Attach one artefact a stranger can open next year.
- Revisit when the model, the notice, or the SI changes.
- Do not treat a vendor slide as evidence.
Questions this usually raises
- Is shared GPU feasible for Indian departments?
- Yes, when tenancy is hard, metering exists, someone can refuse a job, and data classes are compatible. Otherwise no.
- Does sharing reduce electricity cost?
- It can, if you power fewer idle cards. It does not if every member still demands a warm dedicated node.
- Who is the data fiduciary on a shared node?
- Usually each department for its personal data. The SDC or vendor may be a processor. Write it. Do not let the rack decide.
- Can universities join a state pool?
- Only with a written tenancy and a data-class review. Student records are not a tourism chatbot.
- Will Prcept operate a multi-department pool?
- We will run agents in tenants you define. We will not sell a shared wiki of passwords as a pool.
- Does DPDP forbid sharing?
- Not automatically. Unmapped sharing with mixed purposes and no processor contract is the problem. Map it or do not share.