Skip to content
SalvitelleCorporate Hub

CorporateAI

Project vision

AI infrastructureas a sharedutility.

A local compute infrastructure, proposed for the Salvitelle ecosystem: resident companies draw on shared capacity instead of each building its own stack.

Explore the reference dataSee the masterplan
  1. 05Workspaces
  2. 04AI platform
  3. 03Storage and network
  4. 02Compute
  5. 01Energy
Abstract diagram of a building on five stacked levels — energy, compute, storage and network, AI platform, workspaces — crossed by a flow of data rising from the bottom to the top.

The problem

AI is expensive when everyone builds it alone.

Every company working with AI faces the same bill: accelerators, storage, network, models. Multiplied by three companies it becomes the same spend three times over, for capacity that mostly sits idle.

Three companies, three stacks

One infrastructure, many companies

  • Accelerators
  • Storage
  • Network
  • Models

In the proposed model the capacity sits in one place and companies draw on it according to their workload. It is the same logic the project already applies to offices, energy and services.

Select a company to see its workload.

Declared directions

Target

No project document describes AI compute capacity today. What follows are declared directions, not available services.

  • Shared AI compute
  • Open-weight models
  • Inference
  • Fine-tuning
  • RAG and document search
  • Rapid prototyping

Reference hardware

What one node can do.

Reasoning about concrete numbers needs a reference platform. The figures below describe a compute node available on the market: they give an order of magnitude, they do not describe Salvitelle hardware.

Reference specification. The final CorporateAI configuration is to be defined.

Compute per node

1PFLOP FP4

Reference

Unified memory

128GB

Reference

Memory bandwidth

273GB/s

Reference

Network per node

200Gbps

Reference
  • Theoretical FP4 figure, using the sparsity feature.

Measured performance

Two published measurements on the same platform. They use different precisions and different backends: two independent data points, not a race between models.

Prompt processing

  • Qwen3 14B5,928.95tokens/s

    NVFP4 · TRT-LLM

  • GPT-OSS-20B3,670.42tokens/s

    MXFP4 · llama.cpp

Token generation

  • Qwen3 14B22.71tokens/s

    NVFP4 · TRT-LLM

  • GPT-OSS-20B82.74tokens/s

    MXFP4 · llama.cpp

Conditions: ISL|OSL = 2048|128 · BS=1
Results vary by model, backend, precision and workload.

And with more nodes?

Aggregate capacity is a multiplication — which is exactly what makes it theoretical.

aggregate PFLOP FP4
1
GB aggregate memory
128

Theoretical aggregate capacity. Real-world performance depends on workload, networking, software, utilization and model, and does not scale linearly.

From small models to frontier scale.

How much room a model takes, and what one size is good for compared to another.

7B

Local experimentation

Weight footprint at 4-bit

4GB

against the 128 GB unified memory of one node

Educational visualization. The figure covers weights only: real memory use adds KV cache, activations and runtime. It does not imply that every model at every size runs efficiently on the reference platform.

How many machines it actually takes

Move the sliders. The model is arithmetic over two stated assumptions, and it produces no money: no project document states a price per node, so a euro figure here would be invented. It produces machines — how many you need alone, how many sharing, and how many nobody has to buy.

5

110

Light

4 GB of resident weights per company

Scenario

Scenario result

Nodes, each on their own
5

3% of memory used

Nodes, sharing
1

16% of memory used

Nodes not bought
4

Machines, not savings: no source states the price of a node.

5 companies hold 20 GB of weights resident between them. A reference node has 128.

Assumptions

  • A · A node is the unit you can buy. A company that provisions its own capacity provisions at least one node, whether or not it can fill one. That indivisibility is the argument of this page: not that shared hardware is cheaper per unit, but that the smallest unit you can buy is larger than what most companies need.
  • B · Workload is expressed as model weights held resident in memory, in the 4-bit sizes this page publishes just above. Memory is the constraint that can be reasoned about without inventing a throughput figure.

Weights only: KV cache, activations and runtime sit on top of these figures, so they are a floor and not a requirement. Sharing memory is not sharing time: this says the group's models fit, not that they all run at once at full speed. The node is the reference platform described above, not a designed CorporateAI configuration — every Salvitelle-side capacity remains to be determined.

On the Salvitelle side

What has not been decided yet.

The numbers above describe a reference platform. These concern CorporateAI itself, and not one of them is determined: sizing, capacity and operating model all depend on the feasibility study.

Accelerator count

n.

To be determined

Aggregate compute capacity

To be determined

Cluster size

To be determined

Dedicated power envelope

kW

To be determined

Pricing model

To be determined
To be determined
Not yet determined: the financial model will define it.

One infrastructure.Many companies.

CorporateAI is envisioned as a shared AI infrastructure layer inside Salvitelle Corporate Hub. Not another SaaS product: a physical and digital infrastructure designed to help companies build.

Allocation

To be determined

The model foresees that selected resident startups could access a defined allocation of the infrastructure without direct infrastructure charges, subject to the final operating model and available capacity.

The size of the allocation and the operating model are not determined.

Where to start

I'm a startupAccess the ecosystem
I'm a companyBuild with CorporateAI
I'm a partnerSupport the infrastructure
See the campus masterplan