Why a Red Hat Engineer Ditched ARM64 for AMD Ryzen (Linux AI Builds)

Short answer: A recent Red Hat engineer's blog post that circulated the Linux forums this week argues x86-64 on modern AMD Ryzen still delivers a better developer experience than ARM64 for local AI work — because of PCIe headroom, driver maturity, and the ROCm/CUDA installer story. If you build one Linux workstation for both AI inference and general dev, Ryzen remains the pragmatic default.

The context

A Red Hat kernel engineer published a widely-shared post this week explaining why they moved their personal AI workstation from a top-tier ARM64 chassis back to AMD Ryzen. The post was not a benchmark comparison. It was a workflow autopsy: package availability, discrete-GPU support, PCIe lane count, and the day-to-day headaches of running llama.cpp, PyTorch, and a bunch of half-abandoned research repos on ARM.

This synthesis pulls together the argument, benchmarks it against public performance data, and lands on a practical build recommendation for anyone considering the same trade.

What the post actually argued

The core complaint about ARM64 for AI-workstation Linux was not raw compute. Apple silicon and modern ARM server chips are competitive on tokens-per-watt. The problems were downstream:

1. Driver and firmware maturity. Discrete GPUs plug into PCIe slots. On x86-64, that is a solved problem across every mainstream distribution. On ARM64, PCIe root complex support varies by vendor, and pairing a discrete NVIDIA or AMD GPU with an ARM64 SoC still hits kernel edge cases.
2. Package availability. dnf install rocm-hip or apt install nvidia-cuda-toolkit just works on x86-64 Fedora and Ubuntu. Same command on ARM64 either fails or pulls a stale version. For a Red Hat engineer using Fedora daily, that is a dealbreaker.
3. Research repo compatibility. Almost every ML paper's reference implementation targets x86-64 CUDA. ARM64 requires cross-compilation, missing wheels, or manual patches. Time-per-experiment doubles.
4. PCIe lane count. Consumer ARM64 desktops usually expose 4-8 PCIe Gen4 lanes to the primary slot. A Ryzen 7 5800X on AM4 exposes 16 lanes; AM5 exposes 24. That headroom matters when you add a discrete GPU, an NVMe for models, and a 10Gbe NIC.
5. Community critical mass. Every LocalLLaMA / r/hardware / r/buildapc thread assumes x86-64. Troubleshooting ARM64 issues is a lonelier road.

The counterpoint

ARM64 wins on watts. A Grace-based ARM64 desktop pulls ~50W idle vs. ~80W for a Ryzen 7 5800X. Over a year of 24×7 uptime for a home lab, that is a meaningful electricity delta.

ARM64 also wins on integrated memory bandwidth in the unified-memory variants (Apple M-series, Grace) — see the Ryzen AI Halo vs. DGX Spark analysis for the LLM implications.

The post's argument is not "ARM64 is bad." It is "ARM64 is not yet worth the workflow tax for a developer who also runs mainstream Linux tools and pairs discrete GPUs." That is a specific claim, and it is defensible.

Key takeaways

• Package parity is the top ARM64 blocker. Missing CUDA/ROCm wheels dominate the pain.
• PCIe lane count favors x86-64 desktops. Discrete-GPU builds are simpler on Ryzen.
• Watts favor ARM64 at idle. Meaningful only for always-on rigs.
• Fedora/RHEL polish is a Red Hat engineer's daily driver. ARM64 support ships but is behind x86-64.
• The recommendation: Ryzen 5000-series AM4 or 7000/9000-series AM5 for a Linux AI workstation in 2026.

Package availability, in detail

Take PyTorch as the test case. On Fedora 42 x86-64:

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

Works out of the box. Every CUDA 12.4 wheel is prebuilt.

On Fedora 42 aarch64, the CUDA index does not host aarch64 wheels for the same version. You either fall back to CPU-only wheels or build from source, which requires a working CUDA aarch64 toolkit that itself is only supported on specific ARM64 platforms (Grace, Jetson). For everything else, no dice.

ROCm is similar. AMD's official ROCm wheels list x86-64 support for RDNA2/3/4 and CDNA. aarch64 support exists for select MI-series server chips only. A MSI RTX 3060 12GB paired with an ARM64 desktop is not a supported configuration on either vendor.

PCIe headroom for AI workstations

An AI workstation typically wants:

• 1× discrete GPU (16 PCIe Gen4 lanes)
• 1-2× NVMe (4 Gen4 lanes each) for model storage
• 1× 10GbE NIC (4 Gen3 lanes) for RAG index sync
• 1× extra NVMe for scratch (4 Gen4 lanes)

That is 24-28 PCIe Gen4 equivalent lanes. AM4 with a Ryzen 7 5800X delivers 24 usable lanes to add-in cards (16 GPU + 4 NVMe + 4 chipset). AM5 with a Ryzen 7 9700X delivers 28 direct lanes. Both handle the workload with room.

Consumer ARM64 desktops rarely expose more than 8-12 lanes to add-in cards. The workstation-class ARM64 platforms exist (NVIDIA Grace, Ampere Altra) but land in $2K+ motherboard territory. That is a different market.

Kernel and driver notes

Fedora 42 kernel 6.11 shipped with mainline support for the RDNA 3.5 GPU in the AMD Ryzen AI Halo, plus stable NVIDIA proprietary + open-kernel-module hybrid support for Ada and Blackwell cards. Both were tested first on x86-64. ARM64 support tends to trail by 1-2 kernel releases for anything discrete-GPU related.

RHEL 10 hits the same pattern. Red Hat's certified hardware list is heavily x86-64-weighted; ARM64 server certifications are growing but workstation ARM64 is not the focus.

Per Fedora's release notes, the on-the-fly firmware updates via fwupd also work more reliably on x86-64 workstation vendors.

Real-world build: Ryzen Linux AI workstation for 2026

Base config (~$900):

• CPU: AMD Ryzen 7 5800X, 8c/16t Zen 3, ~$180
• Alternate: AMD Ryzen 7 5700X for lower TDP at similar performance
• GPU: MSI GeForce RTX 3060 Ventus 3X 12G, ~$300
• RAM: 2×16GB DDR4-3200 dual-channel, ~$70
• Storage: Samsung 970 EVO Plus 250GB boot + 2TB NVMe scratch, ~$180
• Board: B550, ~$120
• PSU + case: 750W 80+ Gold + mid tower, ~$150

This build runs Fedora 42 out of the box. dnf install cuda-toolkit-12-4 works. pip install torch --index-url .../whl/cu124 works. llama.cpp compiles clean. Every research repo you clone from GitHub with a requirements.txt runs first try.

The equivalent ARM64 build does not exist at this price point for the same workflow. You either pay 3× for a Grace workstation or accept package-management pain on a consumer ARM64 desktop.

When you should still choose ARM64

• Always-on server where watts × 24 × 365 dominates the TCO. Ampere Altra Max at 128 cores idle draws less than a Ryzen 7.
• Apple-only shop. M-series unified memory is genuinely excellent for LLM inference within the Apple ecosystem, and the workflow story on macOS is completely different — see llama.cpp Metal.
• You have a Grace-class chassis for AI-specific work. That is what NVIDIA sells DGX Spark for.

For everyone else running a mixed Linux workstation, Ryzen still wins in 2026.

Bottom line

The Red Hat engineer's post is a workflow report, not a religious argument. If your daily Linux desktop must also run PyTorch, CUDA, ROCm, and half the arXiv papers of the month, x86-64 on a mid-range Ryzen chip is the low-friction choice. ARM64 will get there — it is closer every kernel release — but it is not there yet for discrete-GPU AI work on a consumer budget.

Related guides

• AMD Ryzen AI Halo vs. NVIDIA DGX Spark
• AMD Ryzen AI Halo open-source Linux stack
• Does dual-channel RAM matter for local LLM inference?
• Best GPU for running Llama 70B locally in 2026

Citations and sources

• Phoronix — AMD Ryzen AI Halo Linux review
• Fedora Project — Fedora 42 release notes
• PyTorch — CUDA install guide

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.