In this article

The OpenMetal XL v5 is built on dual Intel Xeon 6530P processors (Granite Rapids, Intel 3 process) with 1TB DDR5-6400, 25.6TB of Micron 7500 MAX NVMe, and full Intel TDX support as a base configuration. This article covers the workloads it’s built for, why TDX matters for specific use cases, how the private cloud and bare metal configurations compare, and where it fits in the v5 lineup relative to the Large.


The XL v5 is OpenMetal’s high-memory Granite Rapids server, and several of its workload advantages stem directly from that 1TB RAM base configuration. It’s the entry point for Intel TDX confidential computing in the v5 lineup. Intel TDX requires all DIMM channels to be fully populated, and OpenMetal stocks 64GB RDIMMs across 16 slots per server, which means TDX-capable configurations start at 1TB. The XL v5 satisfies that requirement at its base configuration, making it the practical TDX platform without a costly memory upgrade. It’s also the right platform for large in-memory workloads that exceed what the Large v5’s 512GB can handle, and a strong fit for AI inference and multi-chain validator operations at production scale.

How the XL v5 Compares to the XL v4

The XL v4 is still available and a capable server. The v5 is a newer option built on a different processor architecture, and the differences are worth understanding when deciding which fits your workload better.

The Xeon 6530P moves from Emerald Rapids on Intel 7 to Granite Rapids on Intel 3. The core count stays the same at 32 physical cores per socket, but the architectural improvements are meaningful:

L3 cache: The 6530P delivers significantly more L3 cache per socket than the XL v4’s Xeon Gold 6530. A larger working set stays in cache, which benefits memory-intensive workloads including large analytics queries, in-memory databases at scale, and AI inference with large batch sizes.

Memory: DDR5-6400 at 1TB versus the XL v4’s DDR5-4800 at 1TB. The faster memory bus improves bandwidth for workloads that move large amounts of data between CPU and RAM, including vectorized compute, large state trie operations, and model inference.

Storage: 4x 6.4TB Micron 7500 MAX NVMe per server, delivering 25.6TB of data storage at 1.1 million random read IOPS per drive. The XL v4 used the Micron 7450 MAX. The 7500 MAX is a meaningful step forward for random I/O intensive workloads.

TDX: Both the XL v4 and XL v5 support Intel TDX out of the box at their base 1TB configurations. Intel TDX requires all IMC channels to be fully populated, and both servers ship with that requirement already satisfied. If TDX is your primary driver and you’re already on XL v4 hardware, that remains a valid platform. The XL v5 makes sense when you also need faster memory bandwidth (DDR5-6400 vs. DDR5-4800), higher random I/O from the Micron 7500 MAX NVMe, or the newer Granite Rapids architecture.

A three-node XL v5 private cloud cluster gives you 192 cores and 384 threads, 3TB of DDR5-6400 RAM, and 76.8TB of Micron 7500 MAX NVMe across the cluster, with 40Gbps private bandwidth per node.

What Workloads Is the XL v5 Best For?

Confidential Computing and Intel TDX Workloads

The XL v5 is the practical TDX platform in the v5 lineup. Intel TDX requires all DIMM channels to be fully populated. OpenMetal stocks 64GB RDIMMs across 16 slots per server, which means TDX-capable configurations start at 1TB. The XL v5 satisfies that at its base configuration. The Medium and Large v5 technically support TDX but would require expensive RAM upgrades to fully populate their DIMM channels, making it cost-prohibitive in practice.

Intel TDX creates isolated Trust Domains where memory is encrypted and inaccessible to the host OS, the hypervisor, and the infrastructure operator. Even someone with physical access to the server cannot read the contents of a TDX Trust Domain’s memory. Remote attestation provides cryptographic proof that a workload is running inside a genuine TDX environment with the expected configuration, which changes the security guarantee from a contractual commitment to a verifiable one.

The workloads that benefit most from TDX on the XL v5 are those where sensitive data in memory is the attack surface:

Institutional validator operations where signing keys must be isolated even from the infrastructure provider. For organizations running staking services on behalf of clients or managing large validator sets, TDX attestation is the only way to provide cryptographic proof of key isolation to delegators.

Healthcare AI and clinical data processing where patient data is processed in memory and HIPAA compliance requires demonstrating that data is inaccessible to unauthorized parties including the hosting provider.

Financial services workloads including risk model execution, trading algorithms, and payment processing where proprietary logic and customer data must be isolated even from infrastructure operators. For firms subject to DORA or MAS requirements, TDX provides the infrastructure-level evidence regulators ask for.

Multi-party computation where data from multiple organizations needs to be processed jointly without any party exposing their raw data to the others. TDX provides the hardware isolation layer that makes MPC practical without requiring full homomorphic encryption.

AI model training on sensitive data where training datasets include personal data, healthcare records, or proprietary information that must not be accessible to the infrastructure provider during the training process.

For these workloads, the XL v5 private cloud or bare metal with TDX enabled is the right configuration. Intel TDX requires all DIMM channels to be fully populated, and since OpenMetal stocks 64GB RDIMMs across 16 slots, that means configurations start at 1TB. The XL v5 meets that at its base configuration, so TDX is available without any additional cost beyond standard XL v5 pricing. OpenMetal’s Intel TDX infrastructure includes remote attestation support for cryptographic verification of the isolated environment.

Large In-Memory Analytics and Database Workloads

The XL v5’s 1TB per node puts a different class of workload within reach compared to the Large v5’s 512GB.

For ClickHouse clusters running large analytical workloads, the 1TB per node means significantly more of the working dataset stays in memory rather than hitting NVMe. For time-series databases like InfluxDB or TimescaleDB handling high-cardinality metrics at scale, 1TB allows larger retention windows to be served from memory. For Elasticsearch clusters with large index sizes, the heap allocation headroom at 1TB changes what’s possible without sharding.

Big data pipelines using Apache Spark benefit directly from executor memory capacity. Spark stages that spill to disk on a Large v5 because executor memory is exhausted run entirely in memory on the XL v5. For iterative ML training jobs, data transformation pipelines, and large aggregation queries, that difference is a meaningful performance improvement rather than a marginal one.

On a three-node XL v5 private cloud, you’re working with 3TB of DDR5-6400 RAM and 76.8TB of Micron 7500 MAX NVMe across the cluster. Ceph-backed storage provides the distributed storage layer with replication across all three nodes, giving your analytics infrastructure the redundancy it needs without a separate storage cluster.

AI Inference at Scale

The Xeon 6530P includes Intel AMX for INT8 and BF16 matrix acceleration, AVX-512 with dual FMA units, and Intel DL Boost. At 1TB RAM per node, the XL v5 handles a different class of inference workload than the Large v5.

Larger fine-tuned language models that don’t fit within the Large v5’s 512GB memory footprint can be loaded entirely into memory on the XL v5. Embedding models, reranking models, and retrieval-augmented generation pipelines with large vector indexes benefit from the additional memory headroom. Multi-model inference serving, where multiple models are loaded simultaneously to serve different endpoints, is practical at 1TB in ways it isn’t at 512GB.

The honest constraint remains the same as for the Large v5: for large language model inference at single-digit millisecond latency, or for training workloads of any meaningful size, GPU infrastructure is the right platform. The XL v5 CPU inference case is specifically the set of production ML workloads where model size fits in 1TB, batch inference latency tolerances are in the hundreds of milliseconds, and the economics of dedicated CPU infrastructure compare favorably to GPU cloud pricing for the specific workload.

For organizations combining CPU inference on XL v5 with GPU training infrastructure elsewhere, the 40Gbps private networking per node handles the data pipeline between training and inference environments without bandwidth becoming a bottleneck.

High-Memory Kubernetes and Virtualization

A three-node XL v5 private cloud with 3TB of allocatable RAM is a substantial Kubernetes or virtualization platform for organizations that have genuinely outgrown the Large v5’s 1.5TB cluster total.

SaaS platforms running memory-intensive stateful workloads, in-memory caching layers at scale, or large numbers of tenant environments each with meaningful memory allocations are the right candidates. The hidden costs of managed Kubernetes compound at this memory scale: running 3TB of memory equivalent on EKS involves instance types and associated costs that make fixed-cost private cloud increasingly compelling.

For virtualization workloads migrating from VMware, the XL v5’s memory density handles consolidation ratios that require careful planning on smaller servers. Organizations running large numbers of VMs with significant per-VM memory allocations will find the XL v5 private cloud’s 3TB cluster total accommodating without the shared tenancy and licensing overhead that VMware at this scale involves.

Private Cloud vs Bare Metal for the XL v5

Choose the private cloud configuration when: You need HA and live migration across a three-node cluster. You’re running multiple workloads or tenant environments that benefit from OpenStack Project isolation. You want Ceph-backed distributed storage with 76.8TB of NVMe replicated across three nodes. You need the OpenStack API layer for infrastructure-as-code and Kubernetes integration. At $12,657.60 per month (monthly pricing, no term discount), the three-node cluster gives you 192 cores, 3TB RAM, and 76.8TB NVMe on dedicated hardware.

Choose bare metal when: You’re running a single high-performance workload that needs the full 1TB RAM and 25.6TB NVMe on one server without sharing with other services. You want maximum performance without hypervisor overhead. TDX workloads that require full hardware isolation and IPMI-level access are often better suited to bare metal than private cloud. You’re running your own hypervisor or container runtime and don’t need OpenStack.

Both configurations support Intel TDX. Since TDX requires full DIMM channel population and OpenMetal stocks 64GB RDIMMs across 16 slots, configurations start at 1TB, which the XL v5 satisfies at its base configuration. Both are currently available in Ashburn, VA. Additional data center locations are planned as v5 inventory expands.

Where the XL v5 Fits in the v5 Lineup

Step down to the Large v5 if your workloads fit within 512GB RAM per node and you don’t require TDX. The Large v5 handles production database clusters, Kubernetes, validator nodes, and CPU inference effectively at a lower price point. If memory capacity and TDX aren’t the binding constraints, the Large v5 is likely the right choice.

Step down to the Medium v5 if your workloads fit within 256GB RAM per node and you don’t need the higher core count or NVMe density of the larger configurations. The Medium v5 handles containerized databases, mid-scale Kubernetes, CI/CD infrastructure, and dev/staging environments well at the most accessible price point in the v5 lineup.

If your workloads need more than 1TB RAM per node on v5 hardware, the XL v5 can be configured to 2TB by populating its remaining 16 DIMM slots. Those slots ship empty and are expansion headroom, not a TDX gap. For workloads that can distribute state across nodes, scaling horizontally by adding more XL v5 nodes is often the better answer. Contact the team to discuss which approach fits your workload.

The XL v5 is the right server when 1TB RAM per node is either necessary for your memory footprint or required for TDX, you need the 64-core density for high-thread workloads, and the 25.6TB NVMe per server handles your storage requirements. For confidential computing use cases specifically, it’s the entry point in the v5 lineup where TDX is practical without additional cost.

Frequently Asked Questions

What is the OpenMetal XL v5 best for?

The XL v5 is best suited for Intel TDX confidential computing workloads, large in-memory analytics and database deployments, AI inference at scale using Intel AMX, and high-memory Kubernetes or virtualization environments. Its 1TB DDR5-6400 base configuration makes it the practical TDX platform in the v5 lineup, and its 25.6TB Micron 7500 MAX NVMe handles storage-intensive workloads that exceed what smaller configurations support.

Why is the XL v5 the right platform for Intel TDX?

Intel TDX requires all IMC channels to be fully populated at Slot 0. The XL v5 ships with 16x 64GB RDIMMs in Slot 0 of all 8 IMC channels per socket, satisfying that requirement at its 1TB base configuration. The remaining 16 DIMM slots are expansion headroom to 2TB, not a TDX gap.

How does the XL v5 compare to the XL v4?

The XL v4 is still available and a capable server. The v5 adds Intel TDX support (not available on v4), moves to DDR5-6400 from DDR5-4800 for faster memory bandwidth, upgrades storage to Micron 7500 MAX NVMe from the 7450 MAX, and moves to the Granite Rapids architecture on Intel 3 process. If your workloads are running well on XL v4 hardware, that’s a reasonable place to stay. The XL v5 makes sense when TDX is a requirement, faster memory bandwidth addresses a real bottleneck, or the NVMe performance improvement matters for your specific workload.

What is the difference between the XL v5 private cloud and bare metal configurations?

The private cloud is a three-server hyper-converged cluster running OpenStack and Ceph, providing HA, live migration, 3TB of distributed RAM, and 76.8TB of replicated NVMe storage. Starting at $12,657.60 per month (monthly pricing), it suits multi-workload, multi-tenant, and high-availability deployments. Bare metal is one or more individual servers with full root access, IPMI control, and no hypervisor overhead. For TDX workloads requiring complete hardware isolation, bare metal is often the better fit.

Can the XL v5 private cloud be expanded?

Yes. Additional XL v5 nodes can be added to an existing private cloud cluster in approximately 20 minutes. You can also mix server sizes within a cluster to add capacity as workload requirements evolve.


Ready to evaluate the XL v5 for your workloads? See full specs and pricing or configure a private cloud deployment. Contact the team to discuss whether the XL v5 or another v5 configuration is the right fit for your infrastructure.

Chat With Our Team

We’re available to answer questions and provide information.

Reach Out

Schedule a Consultation

Get a deeper assessment and discuss your unique requirements.

Schedule Consultation

Try It Out

Take a peek under the hood of our cloud platform or launch a trial.

Trial Options

 

 

 Read More on the OpenMetal Blog

Top 8 Reasons Companies Leave Public Cloud in 2026

Jul 06, 2026

A skimmable breakdown of the main business and technical drivers pushing companies from public cloud to hosted private cloud, covering cost control, compliance, performance, and operational control.

What HIPAA Requires from the Infrastructure Running Your Healthcare AI Workloads

Jul 02, 2026

Healthcare AI workloads carry the same HIPAA obligations as any system touching PHI. This article covers what the 2026 Security Rule update requires from AI infrastructure, why vector embeddings count as PHI, and how dedicated private cloud simplifies the compliance documentation burden.

What AI Startups Need to Plan for Before Their Cloud Credits Run Out

Jul 01, 2026

Hyperscaler credits are worth taking, but the architecture built during the subsidized period determines your real cost when billing starts. This covers the credit lifecycle, which decisions create long-term cost exposure, and when private infrastructure makes sense for AI startups in production.

How Nutanix and OpenMetal Compare as VMware Alternatives for Mid-Market IT Teams

Jun 29, 2026

Nutanix is a legitimate VMware alternative with real advantages. But its per-core subscription model has cost implications that compound at scale. This article compares both platforms honestly across pricing, operations, migration tooling, and use case fit.

Why MSPs Should Own Their Cloud Infrastructure Instead of Reselling It

Jun 26, 2026

Azure CSP resale margins are thin and getting thinner as Microsoft shifts incentives away from transaction volume. This article covers the commercial model for MSPs who own their infrastructure instead, how OpenStack multi-tenancy enables per-client isolation on shared hardware, and what the right client segment looks like.

How the H200 Is Built for Memory-Bound AI Workloads

Jun 24, 2026

The H200 is a memory upgrade on the Hopper architecture, not a new compute platform. This article covers why bandwidth matters as much as VRAM capacity, where the 141GB floor changes what fits on a single GPU, and how the NVL PCIe variant differs from the SXM5 for dedicated private infrastructure.

When Running Apache Spark and Delta Lake Without Databricks Makes Financial Sense

Jun 22, 2026

Databricks’ Standard tier is being retired, forcing Premium upgrades with higher DBU rates. This article covers how the DBU billing model works, what the open-source stack underneath Databricks looks like, what you give up by self-managing it, and when private cloud infrastructure changes the economics.

Why 96GB VRAM Changes the Economics of Private LLM Inference

Jun 19, 2026

The RTX PRO 6000’s 96GB VRAM fits 70B models at FP8 on a single card with real KV cache headroom. This article covers what that unlocks, how dedicated fixed-cost GPU infrastructure compares structurally to cloud rental, and where the H200 is the better choice.

When Managed Kubernetes Gets Expensive Enough to Justify Running Your Own

Jun 18, 2026

The control plane fee is the smallest part of your managed Kubernetes bill. This article breaks down what EKS, GKE, and AKS actually charge across egress, storage, cross-zone transfer, and multi-cluster overhead, and where self-managed on dedicated bare metal makes the math work better.

What DORA’s ICT Concentration Risk Requirements Mean for EU Financial Infrastructure

Jun 17, 2026

DORA has been in force since January 2025, and the third-party ICT risk requirements are where infrastructure decisions land hardest. This article breaks down what Articles 28–30 require, why hyperscaler concentration is now a documented regulatory problem, and how private cloud in the EU changes the risk picture.