Two cost curves with different shapes.
This decision is usually argued about in terms of visual quality. That is the least useful axis, because both approaches can look excellent and the answer still differs.
What actually distinguishes them is the shape of the spending.
| Local rendering | Remote rendering (CloudXR) | |
|---|---|---|
| Up front | High — optimisation, LODs, material rebuild, possibly re-authoring | Low — the application runs largely as it is |
| Per session | Near zero | A GPU for the duration, per concurrent viewer |
| When the model changes | Re-derive the optimised build | Nothing — the source is what streams |
| Scaling to more people | Free | Linear, and it never stops |
| Network failure | Degraded or irrelevant | Session over |
| Ceiling on fidelity | The device | The server GPU |
Read the “scaling” row twice. Local rendering has the economics of software: build it once, distribute it at no marginal cost. Remote rendering has the economics of a utility. Neither is better; they suit different situations, and the mistake is choosing one on aesthetics and discovering the other’s cost curve a year later.
The arithmetic, with real numbers.
Here is the calculation in full. Substitute your own figures; the structure is what matters.
The remote side. Annual GPU cost is: hourly instance rate × average session length in hours × sessions per year × peak concurrency you must support — plus idle time if instances are not started and stopped per session.
A reference rate: an AWS g6e.xlarge is one NVIDIA L40S with 48GB of GPU memory, 4 vCPUs and 32GB of RAM, listed at $1.861 per hour on demand in us-east-1, or $1.172 per hour on a one-year reservation. Use your own region and provider, but the order of magnitude holds.
Scenario A -- design review
6 concurrent reviewers
1.5 hour sessions, twice monthly = 36 sessions/year
6 x 1.5 x 36 x $1.861 = $603/year of GPU time
... at 1-year reserved = $380/year
Scenario B -- an operational twin
40 concurrent users
1 hour average, every working day = 250 days/year
40 x 1 x 250 x $1.861 = $18,610/year
... and that is before idle time,
redundancy or multi-region
Scenario C -- a launch or an event
200 concurrent
2 peak hours/day, over three days = 6 GPU-hours each
200 x 6 x $1.861 = $2,233 for the event
... but 200 GPUs at once is a
capacity problem, not a billing oneThe local side. Cost is the optimisation programme — the initial pass, plus re-deriving it on every meaningful model change, plus maintaining the tooling that does it. Price the recurring half properly. A twin that updates monthly and needs two days of re-optimisation each time is roughly twenty-four days a year of specialist time, indefinitely.
Set those two against each other and the answer usually declares itself. Scenario A is not a close call: no optimisation programme costs less than $603 a year. Scenario B genuinely is close, and turns on how volatile the model is. Scenario C is not a cost question at all — it is a capacity question, and the answer is local rendering.
The three variables that decide it.
1. Concurrency, not total users. The number that matters is how many people are in a session at the same moment, because that is how many GPUs you are renting. A thousand people who each visit alone for ten minutes may never exceed five concurrent. Two hundred people in a launch webinar are two hundred concurrent. Model the peak, not the total — and if you cannot predict the peak, that is itself an argument for local rendering.
2. How often the source model changes. This is the variable most often left out, and it can dominate. Every change to the master model means re-running the optimisation pipeline for a local build. If your twin tracks a live construction site or a factory reconfiguration, that recurring cost compounds until it exceeds a very large GPU bill. If the model is signed off and stable, local rendering’s one-off cost stays one-off.
3. Whether you control the network. NVIDIA’s recommendation for the browser client is Wi-Fi 6 or 6E, under 20ms latency and 100+ Mbps. On a managed corporate network, achievable. On a construction site, a vessel, a client’s guest Wi-Fi or a conference floor, not reliably — and the failure mode in a headset is physical discomfort, not a spinner.
Two secondary variables are worth pricing once you have the first three: instance start time, because a cold GPU instance is not instant and someone must decide whether users wait or you pay for warm capacity; and regional placement, because latency is geography and a twin used across three continents needs GPUs in three continents.
The question underneath: is it inhabited or consulted?
Before any of the arithmetic, there is a design question that resolves a lot of these debates on its own.
Is the twin somewhere people go, or something people consult?
An inhabited twin is walked through. People spend real time inside it, at scale, and fidelity is doing the work — design review, spatial planning, training in an environment that must feel like the real one. Sessions are long, the audience is small, and the value comes from being convincingly there. This is remote rendering’s natural home.
A consulted twin is checked. Someone opens it to answer a question — what is the state of this asset, where is this fault, what changed since Friday. Sessions are short and frequent, the audience is wide, and the value is in the data and the speed of access, not the photorealism. This is a browser application that happens to have 3D in it, and streaming it would be spending a great deal to render a picture nobody is admiring.
Most systems described as digital twins are consulted, not inhabited — and most of the arguments about rendering quality are being had about the wrong ones.
Our own twin work — connected highways, construction command centres, GIS site operations — is overwhelmingly the consulted kind, delivered in a browser and optimised for how fast someone gets to an answer. When we have built the inhabited kind, it has been for training and review, with a small audience and long sessions. The split is consistent enough to be a useful first filter.
The hybrid that usually wins.
Framing this as a binary is the most common mistake. In practice the answer for a serious programme is frequently both, split by audience.
- A lightweight browser twin for everyone. Optimised geometry or Gaussian-splat capture, real data, fast to open, works on a laptop and a phone, no headset required. This serves the ninety percent whose need is informational.
- A streamed full-fidelity session for the few who need it. Booked, scheduled, on a controlled network, for design review or detailed inspection where the accuracy genuinely decides something. Small concurrency, predictable, budgetable.
This works because the two audiences want different things and the costs stay in proportion to the value. The expensive path is used by the people for whom it is worth being expensive.
It also fails gracefully. When the streaming session cannot run — a bad network, no capacity, someone on a train — there is still a product, rather than nothing.
The way to get this wrong is to build the streamed version first because it demos better, then discover that most of the organisation needs the lightweight one and it does not exist. Build the thing most people need first. Add fidelity where fidelity is the deciding factor.
What to do next.
A short sequence that produces a defensible answer rather than a preference.
- Count concurrency at peak. Not registered users. Not sessions per month. Simultaneous viewers at the busiest realistic moment. Everything else follows from this.
- Price the optimisation programme honestly, including the recurring half. The initial pass is the small part if your model changes.
- Run the GPU-hour calculation with your own concurrency and rates. Three scenarios: typical, peak, and the launch event someone will eventually ask for.
- Test the network where it will actually be used. Not the boardroom — the site, the client office, the show floor.
- Classify the twin: inhabited or consulted. If consulted, you have probably already got your answer and it is a browser application.
Then pilot the narrow version of whichever way that points, with real people and one real model, before anything is committed. For completeness: we build browser-delivered twins and real-time 3D, and we have not deployed CloudXR in production. The figures above are NVIDIA’s published requirements and public cloud list prices, laid out so you can run the numbers yourself.
What this means for a buyer.
Start with the business decision, audience, and evidence the project must produce. Simam Digital can turn that into a focused discovery, prototype, MVP, or production roadmap across AI applications, SaaS platforms, digital twins, real-time 3D, XR, and interactive systems.
