(Source: servethehome)Arm has faced a challenging period in the enterprise sector. NVIDIA is vigorously promoting Arm CPUs in the AI application field as part of its overall strategy to build full-stack systems similar to IBM mainframes. In the Internet of Things (IoT) sector, Arm has performed exceptionally well. However, in the mainstream server market, the adoption rate of Arm by enterprises remains relatively low. There are many reasons for this, and they are starkly different from those in hyperscale servers.In enterprises, Arm still lacks the key features that drive adoption:
- 1. Installed base compatibility
- 2. Hardware availability
- 3. Equivalent functionality to cloud options
- 4. Software support
- 5. Licensing support
Installed base compatibilityStarting with these points, let’s look at the installed base. Enterprises primarily run x86 compute clusters, which is no secret. In fact, if you look at the installed base, you’ll find that most servers run Intel Xeon processors. AMD EPYC is likely to surpass Intel Xeon in key metrics between 2025 and 2027, but from the perspective of installed base, Xeon processors remain king and will continue to do so for the next few years.When it comes to installed base compatibility, this will be crucial in 2025. We will delve deeper into this later, but it is great to be able to not worry about compatibility. Nowadays, many Arm server promotions look like unauthorized cloud-native applications that can be converted to Arm. I often use the nginx web server as an example here. If you are hosting in containers rather than virtual machines, then the migration is not that bad. Or better said, the more time you spend on architecture-agnostic application architecture, the easier it is to incorporate Arm into your installed base. Of course, this requires effort in an environment that already runs x86 servers, so the question is, why expend that effort? Especially when the end result is having to run two different architectures.A few years ago, Arm servers were once replaced by Intel Xeon due to energy efficiency, especially after Intel’s manufacturing advantage was taken over by TSMC. AMD EPYC, using the same advanced manufacturing technology as TSMC, limits the power gains that can be achieved by switching to Arm. It must be remembered that in modern CPUs, the majority of the chip area is not the compute cores, and there are differences between vendors. Aside from relatively small power gains, the challenge is that the context of these power gains is becoming a rounding error. If you save 10-50W on mainstream 1-1.2kW x86 compute servers, does that mean significant gains if x86 compute servers perform better?In the context of today’s AI GPU compute servers, which far exceed 10kW in power, the situation is entirely different. Considering the power gap with AMD EPYC, it is fair to say that even compared to Intel with E cores, the situation is different. Any power savings in CPU compute compared to the emerging AI power demands are negligible. The AMD Instinct MI325X we are evaluating has a power limit of 1kW per accelerator, but there are additional cooling requirements beyond that. In other words, the claim that switching to Arm (or even general E cores) saves compute power has failed because switching to an efficient architecture to run web servers means that for every 8-12 converted 2U compute server racks to a different architecture, one 8 GPU server will be installed.Today, all parties are striving to meet AI demands. In the context of converting so many servers to more efficient, optimized Arm/E cores to improve the power of a single GPU server, it makes no sense to disrupt the status quo of the existing customer base. Essentially, the biggest reason to disrupt the existing customer base—power consumption—has been offset by the efficiency improvements of x86 vendors, and this difference has become a trivial error in the hot topic of AI construction today. We have previously reported on this issue, but a slightly humorous version is: Intel’s E cores aim to narrow the application capability range of Intel cores to reduce power consumption similar to Arm, and this idea has essentially stagnated around 2024/2025 as the industry no longer argues over the trivial improvements in traditional data center power consumption.Hardware availabilityEven if you are excited about the prospect of saving power in the rounding error in the AI context, deploying Arm servers is a challenge to turn that vision into reality.Currently, almost all vendors offer NVIDIA Grace servers. These servers have a dual CPU module with a core count limited to 144, and users must choose between low-capacity fixed memory with high bandwidth or high-capacity fixed memory with low bandwidth. Most mainstream vendors sell NVIDIA Arm solutions, but NVIDIA is currently not focused on supporting these solutions in enterprise-grade general workloads. Additionally, as the NVIDIA Grace Arm Neoverse V2 cores begin to age, in most cases, it is better to choose Intel or AMD solutions with a higher core count on a per-node basis.Aside from purchasing outdated architectures like the Grace CPU that are not designed for general workloads, enterprises have very limited choices for modern Arm CPUs. AmpereOne may be the best option currently, but trying to find servers from Dell, Lenovo, or HPE is not easy. The difficulty is not just in finding hardware; will your sales representative prioritize selling AmpereOne servers? Probably not. From the perspective of top server vendors, the only real choice is Supermicro, such as the Supermicro MegaDC ARS-211M-NR we have evaluated. However, if you want different CPU configurations and so on, you will still encounter difficulties.It is worth mentioning that we have evaluated the HPE ProLiant RL300 Gen11. It uses the older DDR4 Ampere Altra (Max) processors and is a single-socket platform. It is a perfectly acceptable HPE ProLiant server, but it has flopped in the market. The reason is that it is difficult to convince users to accept the incompatibility of existing servers and the lack of broad choices (such as dual-socket ProLiant Arm servers). It was paired with the previous generation Arm processors and ultimately failed.From an enterprise perspective, there is usually a primary IT vendor relationship, and if that vendor does not have Arm, then the project cannot proceed at all.Equivalent functionality to cloud optionsHybrid multicloud is a hot topic today and will continue to be so. The idea of having on-premises infrastructure to reduce costs and then obtaining additional capacity and functionality from cloud providers will become increasingly important. With the introduction of new AI capabilities, leveraging multiple cloud providers will become crucial. At the same time, even these AI applications, if chosen for on-premises deployment (or actually chosen for hosted), can have a payback period of less than 12 months.However, achieving feature parity is indeed a very tricky topic. Amazon has its own Graviton chips, but they are only available on its cloud platform. Companies like Oracle have their own Ampere Altra and AmpereOne instances. Other providers mix Ampere Altra and custom Arm processors. The functionality of each solution is very different. If you have heavy floating-point applications, these are not the design optimization points of Ampere. If you want to have simple features that many are accustomed to, such as nested virtualization, then you certainly do not want to run on the Ampere Altra (Max) platform.Cloud service providers claim these chips are cheaper, but this somewhat sidesteps the way hyperscale enterprises negotiate pricing. Hyperscale customers are very savvy; they can leverage die area, build models that include yield and die manufacturing costs, plus packaging and other costs, to ultimately arrive at the production cost of the chip. They then give the die supplier a certain profit margin, which is the price they pay for the chips. Compared to the high list prices and steep discounts in enterprise sales, it is not hard to imagine why hyperscale enterprises often get favorable pricing. On the other hand, when building these models, the only difference may ultimately be the profit margin of the chip itself compared to the margins they accept from other suppliers.In fact, the discounts we see on Arm processors in hyperscale cloud pricing serve another purpose. The pricing of cloud instances does not just include the chip price. Instead, cloud providers know that each instance has an additional rate associated with other services. If a compute instance is used to build a web application in the cloud, it typically adds storage, backup storage, cloud egress bandwidth, and so on. Therefore, obtaining a compute instance means that the cloud provider can sell more services around that instance.This brings another benefit to cloud providers. Since there is no real enterprise hardware to return instances, there is essentially no legitimate way to download instance images and run them on locally purchased servers from major vendors. If you are using x86, this is not a big deal, as there are many options that can run locally. Cloud providers know this, so Arm has become a proposal for a California hotel. In fact, if you are running on AWS Graviton, you may be able to run images on AmpereOne or Altra (Max) instances, but performance will differ, and you may need to spend time analyzing it. This is different from x86, where you can directly purchase the generation of servers that the cloud provider is running (or a newer generation).To some extent, the situation on the x86 side is similar because with the new Intel E core CPUs, if your FP workload is heavy, then migrating from P core instances to E core instances, your applications may still run, but performance may vary significantly. STH readers may raise a warning here, as Intel also has two types of P cores in Xeon 6, namely Xeon 6700P and 6900P (and Xeon 6 SoC), along with another P core that does not support AVX-512. At the same time, you can purchase servers that include all these options, so the situation is slightly different.Software supportFrom a software perspective, the world is divided into “cloud-native” and many licensed software packages. In April 2016, when Arm servers were compatible with the original Cavium ThunderX (now Marvell) servers, we began evaluating them. If you had asked me in 2016, I would have said I thought Arm would become mainstream in the next decade. In the software world, there are two powerful and distinct categories: cloud-native and enterprise-grade.In the cloud-native aspect, if you want to run WordPress on the Arm application stack, it is really easy now. In fact, with the development of container technology and the maturity of these applications on Arm, things have become very easy. On the other hand, in the enterprise space, this push is still not enough. This makes some sense.If enterprises cannot purchase Arm servers, they cannot deploy them. Without an Arm installed base, existing applications cannot run on Arm. Due to the lack of solutions for Arm servers in the short term and the absence of an installed base, there is a lack of significant momentum behind it.This is a vicious cycle. If you are an independent software vendor (ISV) considering which architectures to support, x86 is a must because it occupies the mainstream of the market. Beyond that, aside from IoT and edge computing use cases, it is hard to get excited about porting and supporting software on Arm or RISC-V. Conversely, if low-yield, hard-to-obtain platforms are easy to port and support, IBM POWER would likely occupy the second position in the market as it is a well-known architecture with a stable, willing-to-spend customer base. Nevertheless, there are still many enterprise software libraries in the market that ISVs do not support POWER. Arm has an advantage in yield over POWER, but there are also some hard-to-ignore similarities between the two.This vicious cycle is truly unacceptable. If there is no software support beyond cloud-native applications, why would I ask server OEMs to produce and sell Arm servers? If these servers are not deployed, why would independent software developers (ISVs) care about supporting Arm? The answer may be vendor lock-in by cloud providers or NVIDIA’s strong promotion of full-stack solutions like IBM Z. In any case, after nearly a decade of using Arm servers, listening to feedback from OEMs and market customers, and observing various dynamics, I am increasingly skeptical that this cycle can self-correct, as the reduction in web service power consumption may bring some benefits.Licensing is difficultThis brings me to my most important point, which is licensing. Arm server vendors are happy to talk about cloud-native applications because they typically do not need to pay licensing fees. Even when they do, many of these businesses operate based on supported nodes or similar mechanisms.However, suppose you are an enterprise and, like many enterprises, have Microsoft Windows Server. Suppose you can obtain a supported Arm version of Windows Server for on-premises deployment. Then you need to obtain a license. Currently, this is licensed per core. For products licensed per physical core (such as those we discussed in our recent virtualization article), features like SMT and maximum performance per core work better. If you pay per core, most people would strongly prefer a core with performance as good as two or more low-power cores.This issue is not limited to Microsoft’s licensing. Take VMware as an example. Over two years ago, we demonstrated VMware ESXio running on AMD Pensando DPU. While this is a supported model, running VMware on Arm is still just a flash in the pan. Nick wrote an article for STH in 2020 about running VMware on Raspberry Pi. In 2021, Tom Fenton and I published a book about running VMware ESXi on Arm and Raspberry Pi (see: Running ESXi on Raspberry Pi). As of June 2025, when I write this, good luck trying to run VMware on Arm servers for production use. Given the changes in licensing from Broadcom and VMware, and considering the costs, it is hard to have any desire to run VMware on Arm.Due to the lack of effective licensing compatibility with Arm hardware in the market for basic low-level components, high-level applications are also similarly unsuitable. If the speed per core is not the fastest, would you be willing to license CFD software per core? Even licensing per socket, x86 architecture is still favored because AMD EPYC 9005 Turin has 192 cores and 384 threads. For ISVs, they need to create different licensing schemes around per-core performance to make it more attractive. This is undoubtedly a dangerous situation when hyperscale compute providers offer a range of products from old Ampere Altra Arm cores to new custom cores.If you do have core or socket licensing for applications running on servers, the next challenge arises: how will you handle it? Will you use the same license for lower-performing socket or core Arm processors, or for higher-performing socket and core EPYC processors (which in some cases also include Xeon processors)? Worse yet, if you are running licensed applications on VMware ESXi, you must figure out the licensing tiers and how to place workloads between x86 and Arm servers. If you have not experienced the licensing nightmare, then after reading and thinking about this, I sincerely apologize if you encounter such a nightmare.From these five aspects, deploying Arm servers in enterprises in 2025 is very challenging. This leads us to a conclusion.