In this article

The OpenMetal Large v5 is built on dual Intel Xeon 6517P processors (Granite Rapids, Intel 3 process) with 512GB DDR5-6400 per server and 12.8TB of Micron 7500 MAX NVMe. This article covers the workloads it’s genuinely well-suited for, how the private cloud and bare metal configurations compare, where it fits in the v5 lineup relative to the Medium and XL, and when to step up or down.


The Large v5 is OpenMetal’s mid-tier Granite Rapids server, and the step up from the Medium v5 is substantial rather than incremental. Double the RAM, double the NVMe, a significantly higher base clock, and 92% more L3 cache per socket change the workload profile meaningfully. Where the Medium v5 excels at cache-sensitive workloads with moderate memory requirements, the Large v5 handles workloads where memory capacity and sustained single-threaded throughput are the binding constraints.

How the Large v5 Compares to the Large v4

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

The Xeon 6517P delivers a 14% higher base clock at 3.2GHz versus 2.8GHz on the 6526Y, reaching 4.2GHz max turbo. For workloads with single-threaded critical paths, database query planners, or real-time transaction processing, that base clock improvement translates directly to lower latency under sustained load.

Memory bandwidth: DDR5-6400 delivers approximately 819GB/s aggregate bandwidth per server, a 23% improvement over the Large v4’s DDR5-5200. Memory-bound workloads including state trie operations, vectorized compute, and large in-memory analytics benefit directly.

Storage: 2x 6.4TB Micron 7500 MAX NVMe per server at 1.1 million random read IOPS per drive. Boot/data isolation is maintained through dedicated 960GB NVMe boot drives in RAID 1, keeping OS I/O off the data drives entirely.

Power efficiency: 190W TDP per socket versus 225W on the Large v4. More performance at lower power draw per socket, which matters for deployments running sustained high-utilization workloads over long periods.

A three-node Large v5 private cloud cluster gives you 96 cores and 192 threads, 1.5TB of DDR5-6400 RAM, and 38.4TB of Micron 7500 MAX NVMe across the cluster, with 20Gbps private bandwidth per node and OpenStack and Ceph preconfigured on dedicated hardware.

What Workloads Is the Large v5 Best For?

Distributed Database Clusters at Production Scale

The Large v5 is a strong fit for production database infrastructure where the Medium v5’s 256GB per node creates memory pressure under real workloads.

PostgreSQL’s shared_buffers configuration is constrained by available RAM. On a Medium v5 node, a practical shared_buffers allocation leaves limited headroom for the OS, connection overhead, and other services running alongside the database. On a Large v5 node with 512GB, you can allocate 128GB or more to shared_buffers while maintaining comfortable headroom for everything else. For PostgreSQL clusters handling large datasets with high concurrent read workloads, that buffer pool size directly reduces disk I/O.

Elasticsearch and OpenSearch clusters benefit similarly. Index shards that fit in memory serve queries from the JVM heap without hitting NVMe. With 512GB per node and 12.8TB of Micron 7500 MAX NVMe for index storage, the Large v5 handles substantial index sizes while keeping hot data in memory.

ClickHouse is worth calling out specifically. It’s one of the fastest analytical database engines available and is highly sensitive to memory bandwidth. The Large v5’s 819GB/s aggregate memory bandwidth aligns well with ClickHouse’s vectorized query execution model. Teams running ClickHouse for real-time analytics, log aggregation, or time-series data on the Large v5 private cloud get Ceph-backed distributed storage with replication across nodes and no shared tenancy affecting query consistency.

For VMware refugees migrating database infrastructure, the Large v5 private cloud provides equivalent memory capacity to what most mid-market database hosts ran on VMware, without the licensing overhead or shared hardware.

Blockchain Validator Nodes and RPC Endpoints

The Large v5 spec page calls out blockchain infrastructure explicitly, and the hardware profile supports it well. The combination of 3.2GHz base clock, 12.8TB NVMe at 1.1M random read IOPS, and 512GB RAM maps directly to the requirements of production validator and archive node operations.

Proof-of-stake validator operations at production scale require consistent latency, large fast storage for chain state, and hardware isolation that guarantees your validator’s performance isn’t subject to what other tenants are doing. The Large v5 bare metal configuration delivers all three. Dedicated hardware means no noisy neighbor effects on NVMe or CPU during peak network activity. The 12.8TB NVMe handles full archive node requirements for most major networks. And the 3.2GHz base clock handles the parallel transaction validation requirements of high-throughput networks without throttling.

For operators running multiple validators or multi-chain infrastructure, the Large v5 private cloud provides the isolation mechanism through OpenStack Projects. Each validator operation runs in its own isolated project environment with dedicated networking and storage, without requiring separate physical servers for each chain.

Intel TDX support is available on the Large v5 with a RAM upgrade to 1TB. The same caveat from the Medium v5 applies here: RAM is currently one of the most expensive components in the supply chain, making the TDX upgrade cost-prohibitive for most deployments. For validator operators who specifically require hardware-level key isolation, the XL v5 ships with 1TB DDR5-6400 as its base configuration and is the practical platform for TDX workloads.

Production Kubernetes for Data-Intensive SaaS

The Large v5 private cloud is the right Kubernetes foundation for SaaS workloads that have outgrown the Medium v5’s per-node memory capacity.

A three-node Large v5 cluster gives Kubernetes 1.5TB of allocatable RAM across the cluster. For SaaS platforms running stateful workloads, in-memory caching layers, or multi-tenant architectures where each customer environment needs meaningful memory isolation, that headroom is the difference between a comfortable production environment and one that’s always running close to its limits.

The 38.4TB of Micron 7500 MAX NVMe across the cluster handles persistent volume requirements for data-intensive applications without storage becoming a bottleneck. Ceph-backed persistent volumes are replicated across all three nodes, giving you the storage redundancy that production Kubernetes requires without the complexity of managing a separate storage cluster.

For SaaS companies currently running EKS or GKE at this scale, the fixed-cost model is worth evaluating directly. A three-node Large v5 private cloud at $6,782.40 per month (monthly pricing, no term discount) provides 96 cores, 1.5TB RAM, and 38.4TB NVMe on dedicated hardware. Running equivalent capacity on EC2 with comparable specs, accounting for inter-AZ transfer, EBS volumes, NAT gateway fees, and EKS control plane costs, typically runs significantly higher than that number with variable billing that doesn’t reflect hardware costs accurately.

CPU-Based AI Inference

The Xeon 6517P includes Intel AMX (Advanced Matrix Extensions) for INT8 and BF16 matrix operations, AVX-512 with dual FMA units for vectorized floating-point compute, and Intel DL Boost for INT8 inferencing. For teams running lighter inference workloads that don’t justify GPU hardware, the Large v5 provides a practical CPU-based inference platform.

Use cases that fit this profile include text classification, named entity recognition, recommendation system inference, embedding generation for retrieval-augmented generation pipelines, and smaller fine-tuned language models where batch inference latency tolerances are in the hundreds of milliseconds rather than single digits. These workloads can serve production traffic on Large v5 bare metal without GPU infrastructure.

The honest constraint: for large language model inference at low latency, or for training workloads of any meaningful size, the Large v5 is not the right platform. Those workloads belong on GPU infrastructure. The CPU inference case for the Large v5 is specifically the set of production ML workloads that don’t require GPU throughput and are better served by dedicated high-frequency CPU cores with large cache.

Private Cloud vs Bare Metal for the Large v5

The same framework from the Medium v5 applies here, with a few Large v5-specific considerations.

Choose the private cloud configuration when: You need HA and live migration for database or application workloads. You’re running multiple services that benefit from OpenStack Project isolation. You want Ceph-backed distributed storage replicated across three nodes. You need the OpenStack API layer for infrastructure-as-code and Kubernetes integration. The three-node cluster’s 1.5TB of RAM and 38.4TB of NVMe gives you meaningful headroom for production multi-service deployments.

Choose bare metal when: You’re running a single high-performance workload like a validator node or dedicated database server that needs the full 512GB RAM and 12.8TB NVMe without sharing with other services. You want maximum performance without the hypervisor overhead of the OpenStack compute layer. You’re running Proxmox and prefer its management interface over OpenStack. You need full IPMI access and OS-level control.

Both configurations are available in Ashburn, VA. Additional data center locations are planned as v5 inventory expands.

Where the Large v5 Fits in the v5 Lineup

Step down to the Medium v5 if your workloads fit within 256GB RAM per node and you don’t need the higher base clock or double the NVMe. The Medium v5’s L3 cache profile handles containerized databases, mid-scale Kubernetes, and CI/CD infrastructure effectively at a lower price point.

Step up to the XL v5 if you need 1TB or more of RAM per node, you require Intel TDX as a base configuration rather than an upgrade, you’re running large-scale AI inference workloads that benefit from Intel AMX at 1TB memory footprints, or you’re consolidating very large virtualization deployments that require more than 512GB RAM per node.

The Large v5 is the right server for production workloads that have outgrown the Medium v5’s memory capacity and don’t yet require the XL v5’s 1TB RAM configuration. For most mid-market SaaS companies, database operators, and blockchain infrastructure teams working at production scale, it’s the most appropriate starting point in the v5 lineup.

Frequently Asked Questions

What is the OpenMetal Large v5 best for?

The Large v5 is best suited for production-scale distributed database clusters (PostgreSQL, Elasticsearch, ClickHouse), proof-of-stake validator and archive nodes, data-intensive Kubernetes deployments with high per-node memory requirements, and CPU-based AI inference workloads using Intel AMX. Its 512GB DDR5-6400 per node, 12.8TB Micron 7500 MAX NVMe, and 3.2GHz base clock address workloads where the Medium v5’s memory capacity and clock speed are the limiting factors.

How does the Large v5 compare to the Large v4?

The Large v4 is still available and a capable server. The v5 steps up with a 14% higher base clock (3.2GHz vs 2.8GHz), 23% faster memory bandwidth (DDR5-6400 vs DDR5-5200), and 15% lower TDP per socket (190W vs 225W). The processor moves from the Intel Xeon Gold 6526Y (Emerald Rapids, Intel 7 process) to the Intel Xeon 6517P (Granite Rapids, Intel 3 process). If your workloads are running well on Large v4 hardware, that’s a reasonable place to stay. The v5 makes sense when the specific improvements in clock speed, cache, or memory bandwidth address a real bottleneck in what you’re running.

What is the difference between the Large 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, distributed storage, and OpenStack Project isolation. Starting at $6,782.40 per month (monthly pricing), it gives you 96 cores, 1.5TB RAM, and 38.4TB NVMe across the cluster. Bare metal is one or more individual servers with full root access and IPMI, no hypervisor overhead, suited for single-purpose workloads or deployments where you’re running your own hypervisor.

Does the Large v5 support Intel TDX?

Not practically at its base configuration. Intel TDX requires Slot 0 on every IMC channel to be populated. The Large v5 ships with 8 DIMMs installed, which leaves half its IMC channels without a DIMM in Slot 0. Satisfying the TDX requirement means populating those remaining channels with 64GB RDIMMs, bringing the server to 1TB. The current cost of that upgrade makes it cost-prohibitive for most deployments. If TDX is a requirement, the XL v5 ships with all IMC channels populated at 1TB DDR5-6400 as its standard configuration and is the right platform for confidential computing workloads.

How does a three-node Large v5 private cloud compare to equivalent AWS capacity?

A three-node Large v5 private cloud provides 96 dedicated cores, 1.5TB RAM, and 38.4TB NVMe at a fixed monthly price with no per-VM fees, no inter-node traffic charges, and no EBS storage billing. Equivalent capacity on EC2 across comparable instance types, when all associated costs are included, typically runs significantly higher with variable billing. The Medium v5 vs AWS i4i comparison page covers the structural differences in tenancy model and billing that apply across the v5 lineup.


Ready to evaluate the Large v5 for your workloads? See full specs and pricing or configure a private cloud deployment. Contact the team to discuss whether the Large 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

Provisioning Bare Metal Through an API Without Opening a Ticket

Oct 02, 2026

The OpenMetal Central public API covers the full bare metal lifecycle: inventory checks, orders with deployment configurations and saved SSH keys, provisioning status, scaling, power control, and decommissioning, with a sandbox for testing before you touch production.

Managing Bare Metal VLANs and IP Blocks as Code

Sep 29, 2026

OpenMetal Central lets you create, assign, and tear down VLANs and IP blocks through the public API. This walks through the object model, a scripted private network between an application cluster and a database cluster, and the rules that prevent accidental deletions.

How to Run Bare Metal Servers That Boot Entirely From Memory

Sep 28, 2026

OpenMetal bare metal can now boot an OS entirely into memory from a kernel and initramfs you host, then configure itself through cloud-init and a node-local metadata service. This covers how it works, image requirements, and where it fits.

Why Growing Businesses Self-Host Odoo ERP on Dedicated Bare Metal

Sep 23, 2026

As Odoo deployments grow in users and modules, shared cloud hosting and managed platforms hit performance and cost ceilings. This article covers why dedicated bare metal changes the picture, how to size hardware against Odoo’s actual resource model, and when to split the application and database onto separate servers.

Running Windows Server and Hyper-V on Dedicated Bare Metal

Sep 22, 2026

OpenMetal bare metal servers support custom OS installs via IPMI, including Windows Server. This article covers the installation path, edition selection and core licensing on dedicated hardware, Hyper-V setup for VM consolidation, and which hardware configurations suit different Windows workloads.

What Air-Gap Infrastructure Requirements Actually Mean for Private Cloud Deployments

Sep 21, 2026

When compliance teams ask for air-gapped infrastructure, they usually mean network isolation: workloads that can’t reach the internet and can’t be reached from it. This article explains the difference between true air-gap and network isolation, how OpenMetal’s private networking architecture enables isolated deployments, and where the honest boundaries are.

Self-Hosting Temporal Is a Postgres and Private Networking Decision Before Anything Else

Sep 17, 2026

How Temporal Cloud’s per-action billing model works and where it compounds, what the official Temporal documentation says self-hosted deployments require, the infrastructure stack a production cluster needs, and where OpenMetal’s bare metal fits into that.

What the EU AI Act’s Article 12 Requires From Your Log Infrastructure

Sep 14, 2026

What Article 12 of the EU AI Act actually requires, why the obligation is an infrastructure problem before it is a software problem, what compliant log storage needs to look like in practice, the current enforcement timeline, and how private cloud in the EU addresses the requirement.

A Technical Guide to Every CPU Generation in OpenMetal’s Lineup

Sep 04, 2026

The four distinct Intel Xeon generations running across OpenMetal’s bare metal and hosted private cloud lineup, what actually changes between them beyond core count, and which generation fits which kind of workload, including where confidential computing eligibility depends on generation and hardware configuration together.

Why Shared HPC Access Gets Unpredictable for Life Sciences Computing

Sep 02, 2026

We look at why shared, allocation-based HPC access becomes a real operational problem for life sciences computational research, what changes on dedicated infrastructure that you administer yourself, and how to structure a transition that scales up gradually rather than requiring a large upfront commitment.