Fragmented supply
Every provider brings its own contracts, interfaces and operating model. Using more than one means integrating each of them separately.
Verified AI Compute Exchange
Verified AI compute across independent infrastructure.
Access qualified GPU infrastructure across independent providers through one trusted control plane. Every node is verified before its capacity can reach the marketplace.
DiscoverVerifyDeployMeterSettle
Now in early access for AI teams and infrastructure providers.
01Why it matters
AI compute is everywhere. Trusted access to it isn't.
Capable GPU infrastructure is spread across neo-clouds, data centers and enterprises. Buyers have no consistent way to know what they are getting, and providers have no shared way to prove it.
Claims you can't check
Hardware, networking and isolation are usually described rather than demonstrated, and the buyer inherits the risk of the difference.
Dependence on one operator
Teams that standardise on a single cloud inherit its capacity limits, regions and roadmap, whether or not they fit the workload.
Yentri's answerOne exchange where infrastructure is verified before it is listed, and every provider is reached through the same control plane.
02The model
Not another GPU cloud.
A cloud provider owns infrastructure and sells its own capacity. Yentri doesn't own the hardware. It verifies, connects and meters capacity that independent providers already operate, and gives customers one way to use all of it.
Single-operator cloud
Owns infrastructure sells its own capacity
Yentri exchange
Independent providers shared verification and control plane unified access
| Question | Single-operator cloud | Yentri exchange |
|---|---|---|
| Who owns the hardware | The cloud provider | Independent providers, who keep ownership and control |
| Where capacity comes from | One operator's fleet | Many operators, listed in one marketplace |
| How capacity is trusted | The operator's own assurances | Verified by Yentri before it is listed |
| How you use it | That operator's interfaces | One control plane across providers |
| Changing provider | New integration and contract | Designed to keep the same workflow |
Both models have a place. Yentri is built for teams that want verified access across many operators rather than a single fleet.
03Marketplace
One marketplace. Distributed AI infrastructure.
Every listing describes the same attributes the same way: architecture, memory, interconnect, location, deployment model, cooling, networking and verification state. Capacity from different providers can be compared side by side.
-
Example infrastructure profile
NVIDIA B300
8-GPU HGX system
- Architecture
- Blackwell Ultra
- GPU memory
- 288 GB HBM3e per GPU
- Interconnect
- NVLink, fifth generation
- Location
- US Central
- Deployment
- Dedicated node
- Cooling
- Liquid-cooled
- Networking
- Provider-declared fabric
VerificationRequired before listing -
Example infrastructure profile
NVIDIA RTX PRO 6000
Multi-GPU server
- Architecture
- Blackwell
- GPU memory
- 96 GB GDDR7 per GPU
- Interconnect
- PCIe Gen 5
- Location
- US East
- Deployment
- Dedicated node
- Cooling
- Air-cooled
- Networking
- Provider-declared fabric
VerificationRequired before listing -
Example infrastructure profile
NVIDIA GB300 NVL72
Rack-scale system
- Architecture
- Blackwell Ultra with Grace
- GPU memory
- 288 GB HBM3e per GPU
- Interconnect
- Rack-scale NVLink domain
- Location
- Configurable
- Deployment
- Dedicated rack
- Cooling
- Liquid-cooled
- Networking
- Provider-declared fabric
VerificationRequired before listing -
Example infrastructure profile
NVIDIA H200
8-GPU HGX system
- Architecture
- Hopper
- GPU memory
- 141 GB HBM3e per GPU
- Interconnect
- NVLink, fourth generation
- Location
- Europe
- Deployment
- Dedicated node
- Cooling
- Air-cooled
- Networking
- Provider-declared fabric
VerificationRequired before listing
| Attribute | NVIDIA B300 | RTX PRO 6000 | GB300 NVL72 | NVIDIA H200 |
|---|---|---|---|---|
| Form factor | 8-GPU HGX system | Multi-GPU server | Rack-scale system | 8-GPU HGX system |
| Architecture | Blackwell Ultra | Blackwell | Blackwell Ultra with Grace | Hopper |
| GPU memory | 288 GB HBM3e | 96 GB GDDR7 | 288 GB HBM3e | 141 GB HBM3e |
| Interconnect | NVLink, 5th gen | PCIe Gen 5 | Rack-scale NVLink | NVLink, 4th gen |
| Location | US Central | US East | Configurable | Europe |
| Deployment | Dedicated node | Dedicated node | Dedicated rack | Dedicated node |
| Cooling | Liquid | Air | Liquid | Air |
| Verification | Required before listing | Required before listing | Required before listing | Required before listing |
Showing 4 example profiles.
Example profiles show how listings will be described. They are not offers, inventory or availability, and do not represent any specific provider. Commercial terms are shared with early-access participants.
04Verification
Verification before visibility.
Yentri is not a directory of servers. Infrastructure has to pass verification before its capacity becomes marketplace-eligible, and it stays under lifecycle control while customers use it.
- DiscoveredEnrolled by its provider. Not visible to customers.
- VerifyingIdentity, hardware and isolation are being checked.
- EligiblePassed verification. Can be listed in the marketplace.
Hardware identity
Each node is enrolled with its own cryptographic identity, tied to the system's recorded hardware profile. The control plane authenticates every connection against that identity.
- Unique identity issued per node at enrollment
- Identity tied to the system it was issued for
- Every control-plane connection authenticated
Why it mattersCapacity in the marketplace always maps to a specific, known machine.
Infrastructure attestation
The node's accelerators, memory, storage and system configuration are checked against the profile its provider declared, before the capacity can be listed.
- Declared hardware compared with what is present
- Readiness checked before eligibility
- Mismatches keep capacity out of the marketplace
Why it mattersA listing describes the machine you actually get.
Network isolation
Customer workloads are kept separate from other tenants and from the provider's own operations, with privileged infrastructure access kept apart from tenant access.
- Dedicated capacity per customer
- Tenant traffic separated from provider operations
- Privileged operations separated from tenants
Why it mattersYour workload shares hardware with no one you didn't choose.
Lifecycle control
Capacity moves through explicit states, from discovery and verification to eligibility, use and release. Transitions happen through the control plane, not ad hoc.
- Explicit, auditable state transitions
- Capacity leaves the marketplace if checks lapse
- Release returns capacity to a known state
Why it mattersNothing reaches a customer by accident.
Trusted metering
Usage is recorded by the control plane against the verified node that delivered it, rather than reported separately by each party.
- Usage tied to a verified node and a customer
- Lifecycle events and usage in one record
- The same record seen by customer and provider
Why it mattersCustomers and providers start from the same numbers.
Settlement record
Metered usage forms an auditable record that supports customer accounting and provider settlement across every provider in the exchange.
- One accounting basis across providers
- Traceable from usage to the node that produced it
- Designed to support provider payouts
Why it mattersTransparent accounting, whichever provider ran the workload.
These layers describe how the platform is designed. Yentri is in early access, and the depth of each check grows as the platform matures.
05How it works
Discover. Verify. Deploy. Meter. Settle.
One path for every workload, whichever provider runs the hardware.
Screens are illustrative of the planned customer experience and do not show live data.
06For AI teams
Build without being locked to one cloud.
For teams that need GPU infrastructure they can evaluate before they depend on it, and the option to use more than one provider without starting over.
- GPU architecture and memoryGeneration, memory type and capacity per GPU, described consistently.
- Interconnect and networkingNVLink or PCIe topology and the fabric the provider declares.
- LocationRegion and facility attributes for latency and data-handling needs.
- Deployment modelDedicated nodes through to rack-scale systems.
- IsolationSeparation from other tenants and from provider operations.
- Verification stateWhat was checked, before you deploy anything.
07For infrastructure providers
Keep control of your infrastructure. Expand access to qualified demand.
Connect eligible GPU infrastructure to Yentri while you keep ownership and operational control. Yentri verifies it, makes it discoverable to qualified customers and records the usage it delivers.
- 01Your infrastructureYour hardware, facility and operations.
- 02EnrollmentNodes join with their own identity.
- 03VerificationChecked against the profile you declare.
- 04Marketplace eligibilityDiscoverable by qualified customers.
- 05Customer deploymentProvisioned through the control plane.
- 06MeteringUsage recorded against your nodes.
- 07SettlementA shared record for provider payouts.
You decide
- Which systems to connect
- When capacity is offered and withdrawn
- Your facility, hardware and operations
Yentri provides
- Node identity and infrastructure verification
- Discovery by qualified customers
- Lifecycle, metering and settlement records
Built for
- GPU neo-clouds
- Data centers
- GPU hosting providers
- Enterprises with unused GPU capacity
- AI infrastructure operators
- Powered-shell and AI factory operators
08Architecture
Trust starts below the marketplace.
A conceptual view of the layers between an AI team and the hardware its workload runs on, and who operates each one.
-
Customer
- Yentri customer experience
Discover, deploy and track usage in one place.
-
Marketplace
- Discovery
- Matching
- Capacity
Only verified, eligible capacity is listed.
-
Control plane
- Identity
- Lifecycle
- Provisioning
- Metering
- Settlement
The system of record for every node, deployment and usage event.
-
Provider edge
- Yentri agent
- Infrastructure verification
- Workload isolation
Yentri software running on provider hardware.
-
Infrastructure
- GPU
- Network
- Storage
- Power and cooling
Owned and operated by independent providers.
- Operated by YentriCustomer, marketplace and control plane
- Yentri on provider hardwareProvider edge
- Owned by providersPhysical infrastructure
09Enterprise trust
Built for the questions your security team will ask.
- Infrastructure verificationCapacity is checked against its declared profile before it can be listed.
- Identity-bound nodesEvery node holds its own identity, and every connection is authenticated.
- Lifecycle-controlled capacityCapacity moves through explicit states that only the control plane can change.
- Workload isolationTenants, providers and privileged operations are kept apart.
- Trusted meteringUsage is recorded at the source against the node that delivered it.
- Provider accountabilityEvery deployment traces to a known provider, node and record.
What we claim, and what we don't
Yentri is in early access. This site describes the platform's design and the capabilities being built. We do not claim third-party compliance certifications, and we will only publish them once they have been independently issued. Security questions are welcome during early access.
10Company
About Yentri
Yentri is building a verified compute exchange: one place where independent GPU infrastructure becomes trusted, discoverable capacity, and where AI teams can use it without committing to a single cloud.
- Verification before visibilityCapacity is listed only after it has been checked.
- Providers keep controlInfrastructure stays owned and operated by the people who built it.
- Claims we can stand behindWe describe what the platform does today and what we are building, and keep the two apart.
Questions
What is Yentri?
Yentri is a verified AI compute exchange: a GPU marketplace and control plane that verifies infrastructure from independent providers before it becomes capacity AI teams can discover, deploy, meter and settle.
Is Yentri a GPU cloud?
No. Yentri does not own the infrastructure listed through it. Independent providers own and operate their hardware; Yentri verifies it and provides the shared control plane customers use to access it.
Can I deploy workloads through Yentri today?
Yentri is in early access. Customers and providers join through the early-access program, and capacity is listed only after it passes verification.
How is infrastructure verified?
Each node is enrolled with its own identity, checked against the hardware profile its provider declared and kept under lifecycle control before its capacity becomes marketplace-eligible.
Do providers keep ownership of their infrastructure?
Yes. Providers keep ownership and operational control, and decide which systems to connect and when capacity is offered.
What runs on a provider's infrastructure?
Each enrolled node runs the Yentri agent, which holds the node's identity and handles verification checks and the workload lifecycle on behalf of the control plane. Providers choose which nodes to enroll and can withdraw capacity.
What kind of GPU infrastructure will be listed?
Yentri is designed for current-generation data-center GPU infrastructure, from multi-GPU servers to rack-scale systems. What appears depends on what providers connect and what passes verification.
Early access
One control plane. Independent infrastructure.
Through Yentri, customers reach verified GPU infrastructure across independent providers, with one way to discover, deploy, meter and settle. Join as an early customer or infrastructure provider, and we'll follow up as access opens.