SimOps 101: GPU vs. CPU for Simulation Workloads

In November 2024, Ansys, NVIDIA, and the Texas Advanced Computing Center ran a 2.4-billion-cell automotive aerodynamics simulation on 320 NVIDIA GH200 Grace Hopper Superchips. The result: a 110x speedup over a CPU-based run using 2,048 cores, with the equivalent performance of approximately 225,000 CPU cores. A simulation that previously took nearly a month completed in just over six hours [1].

That number is striking. But it also raises an immediate question: if GPUs are that much faster, why does anyone still use CPUs for simulation?

The answer is that the 110x figure applies to a specific type of problem, at a specific scale, with a specific solver. Change any of those variables and the picture changes. GPU acceleration is not a universal upgrade. It is a tool that works extraordinarily well in some conditions and poorly in others.

This guide explains the architectural difference between CPUs and GPUs, maps those differences to simulation workload types, puts a dollar figure on the 110x result, and gives you a practical framework for deciding which hardware is right for your use case.

The Architecture Difference: Why It Matters for Simulation

Understanding why GPUs and CPUs perform differently requires a brief look at what makes them architecturally distinct.

A modern high-end CPU typically has between 16 and 128 cores. Each core is designed to handle complex, sequential tasks: branching logic, memory management, inter-process communication, operating system functions. CPU cores run at high clock speeds, typically 3 to 5 GHz, and are optimized for low-latency execution of diverse instruction streams. They are generalists, built to handle whatever the software throws at them efficiently.

A modern HPC GPU, such as the NVIDIA H100, has thousands of smaller cores running at lower clock speeds. Unlike CPU cores, which allocate processing time to multiple tasks sequentially, all GPU cores simultaneously execute the same mathematical instructions on different datasets. GPUs are specialists: extraordinarily fast at performing the same floating-point operation across millions of data points simultaneously, but limited in their ability to handle complex branching logic or sequential dependencies.

For simulation, this distinction maps directly to solver structure. If your solver is doing the same arithmetic operation across millions of mesh cells in parallel, a GPU accelerates it dramatically. If your solver has complex sequential dependencies, branching conditions, or tight inter-process communication between iterations, the GPU's architecture provides less benefit and the overhead of managing the GPU can actually slow things down.

Where GPUs Win: Massively Parallel Simulation Workloads

CFD: The Primary Beneficiary

Computational Fluid Dynamics is the simulation discipline that benefits most from GPU acceleration. The core computational kernel in CFD solvers, solving the discretized Navier-Stokes equations across a mesh, is inherently parallel: millions of cells, each requiring the same set of floating-point operations per solver iteration.

The benchmark results reflect this. Simcenter STAR-CCM+ 2022.1 showed a 20x speedup on NVIDIA A100 GPUs compared to CPU-only execution, and Ansys Fluent 2022 showed a 33x speedup on NVIDIA A100 GPUs [3]. By 2024, those numbers had grown further: 10x faster runtimes are common when comparing GPU solvers to 100-core CPU setups, with energy consumption reduced by 88 to 93% and total cost of ownership cut by approximately 50% [5].

A concrete example illustrates the scale of the shift. Running a full-wheel 360-degree compressor simulation with a mesh size of approximately 500 million cells used to be a calculation you might consider running a couple of times per year, requiring solve times of weeks or months. Now, utilizing the parallel performance of GPU hardware and the latest capabilities in the Fluent GPU solver, you can get results within the working hours of a single day [4].

GPU-accelerated CFD is particularly advantageous at large cell counts. Below roughly 10 to 20 million cells, the overhead of loading data to GPU memory can outweigh the speedup. Above that threshold, the acceleration compounds with model size.

Explicit FEA: Crash and Impact Simulation

Finite element analysis covers a wide range of physics, and GPU acceleration does not apply uniformly. Explicit FEA solvers, which are used for crash simulation, impact analysis, and fast transient dynamics, are well-suited to GPU acceleration. The time-stepping scheme in explicit solvers updates all elements simultaneously at each timestep, which maps directly to the GPU's parallel architecture.

A single GPU can yield solve speeds equivalent to over 400 CPU cores and reduce total energy consumption by 67% [6]. In explicit dynamics on well-structured meshes, GPU acceleration delivers some of the highest speedup ratios in the simulation domain.

Parametric Design Studies and Surrogate Model Training

When engineering teams need to run hundreds or thousands of simulation variants, whether for design of experiments, sensitivity analysis, or training AI surrogate models, GPU resources can process multiple jobs simultaneously or accelerate individual runs to compress the total wall-clock time dramatically. This is increasingly central to AI-augmented simulation workflows where large training datasets of CFD or FEA results are required.

Where CPUs Still Lead: Sequential and Complex Workloads

Implicit FEA: Static and Low-Frequency Structural Analysis

Implicit FEA solvers, which dominate static structural analysis, modal analysis, and steady-state thermal problems, are algorithmically different from their explicit counterparts. They solve a global system of equations simultaneously, requiring a matrix factorization step that involves complex sequential dependencies across the entire mesh. This global solve step is not easily parallelized across the massively parallel but lower-bandwidth architecture of a GPU.

For these workloads, high-core-count CPUs with large per-core cache and fast memory access remain the more efficient option. Adding GPUs to an implicit FEA job may improve the linear algebra step but typically delivers more modest overall speedup than in CFD or explicit dynamics.

Many HPC simulation workloads absolutely require FP64 floating-point precision for high-fidelity results in areas like weather and climate modeling, materials simulation, and turbulent airflow simulation. This matters because some GPU configurations optimize for lower precision to boost throughput for AI workloads. For simulation requiring double-precision FP64, engineers should verify hardware specifications: not all GPU configurations deliver the same FP64 performance.

Tightly Coupled Multi-Physics

Multi-physics simulations that couple fluid, structural, thermal, and electromagnetic solvers often involve tight inter-solver communication at each timestep, conditional logic, and irregular memory access patterns. CPUs remain the backbone of HPC clusters: they orchestrate workloads, handle system-level operations, and manage data pipelines. Their role is especially critical in cloud HPC, where efficient CPU utilization determines whether accelerators and storage can operate at peak performance.

In multi-physics workflows, CPUs typically manage the orchestration layer while GPUs accelerate the most parallelizable sub-solvers. The performance outcome depends heavily on how much of total runtime is spent in GPU-friendly kernels versus CPU-bound coordination.

Pre- and Post-Processing

Meshing, geometry repair, boundary condition setup, and results post-processing are largely CPU-bound tasks. They involve complex branching logic, file I/O, and user-interactive operations that do not map well to GPU parallelism. Many simulations, such as CFD or molecular dynamics, require heavy data preparation before GPU kernels can run. In practice, this means that even for GPU-accelerated solvers, a significant portion of total workflow time remains CPU-dependent.

The Precision Question: FP32 vs. FP64

One critical consideration that is often overlooked in GPU vs. CPU comparisons is floating-point precision.

Most AI and graphics workloads run at FP32 (single precision) or lower. GPU hardware has historically been optimized around these lower-precision use cases, which deliver higher throughput at lower power. Modern GPU architectures from NVIDIA and AMD have improved their FP64 (double precision) capabilities significantly, but the ratio varies by hardware generation and configuration.

Engineering simulation typically requires FP64 precision to maintain numerical accuracy across millions of iterations. For CFD and structural solvers, accumulated rounding error in FP32 can produce meaningfully different results at large mesh sizes. AMD's MI250X, used in the Frontier supercomputer at Oak Ridge National Laboratory, delivered a peak FP64 of 47.9 teraflops on vector units and 95.7 teraflops on tensor units, beating the NVIDIA Hopper H100/H200 by just under 43% in terms of peak FP64 performance [7].

When evaluating GPU hardware for simulation, verify the FP64 specification, not just the headline throughput figure, which often reflects FP16 or FP8 performance optimized for AI workloads.

The Hybrid Reality: CPU and GPU Together

Both CPUs and GPUs are essential for running an HPC system. Without a CPU, an HPC system cannot run. Without a GPU, the system cannot achieve optimal performance for parallel workloads. For most HPC applications, a hybrid approach that utilizes both is the optimal solution.

In a well-designed simulation HPC environment, the CPU manages the orchestration layer, handles pre- and post-processing, runs the sequential portions of the solver, and manages job scheduling and inter-node communication. The GPU handles the massively parallel solver kernels: the floating-point operations on the mesh, the matrix operations in the linear solver, and, increasingly, AI inference tasks embedded in simulation workflows.

The NVIDIA GH200 Grace Hopper Superchip, used in the Ansys/TACC benchmark, exemplifies this direction: it tightly integrates a high-performance ARM-based CPU with an H100 GPU on a single package, connected by NVLink-C2C with 900 GB/s of memory bandwidth [2]. This architecture minimizes the data transfer latency between CPU and GPU that historically limited GPU acceleration efficiency for tightly coupled solvers.

What the 110x Speedup Means in Dollars

Speed is only half of the story. To see what the Ansys/TACC result means for a simulation budget, we can map both hardware configurations from that benchmark onto public cloud on-demand rates.

The short version: running the 2.4-billion-cell aerodynamics case on GH200 superchips costs roughly $3,800 to $23,000 in compute. The equivalent CPU run costs roughly $51,600 to $115,000.

	GPU Superchip Run	Traditional CPU Run
Hardware	320 × NVIDIA GH200 Grace Hopper Superchips	2,048 high-performance CPU cores (~22 nodes at 96 cores each)
Wall-clock time	~6 hours	~720 hours (about 30 days)
Compute consumed	1,920 superchip-hours	1,474,560 core-hours
Lower-cost cloud tier	$3,820 to $4,400	$51,600 to $73,700
Enterprise cloud tier (AWS, Azure, Google Cloud)	$15,360 to $23,040	$73,700 to $115,000 (including HPC storage and networking)

The GPU Run: 320 GH200 Superchips for 6 Hours

Each GH200 pairs an Arm-based Grace CPU with a Hopper GPU over the 900 GB/s NVLink-C2C interconnect described above, backed by up to 4 TB/s of HBM memory bandwidth per chip. For multi-billion-cell CFD meshes, this largely removes the CPU-to-GPU data transfer bottleneck.

Lower-cost tier. On specialized GPU cloud providers such as Lambda or Vultr, GH200 on-demand pricing sits at roughly $1.99 to $2.29 per chip-hour. Running 320 chips for 6 hours comes to $3,820.80 to $4,396.80.

Enterprise tier. On hyperscalers that provide full InfiniBand networking topologies and enterprise compliance agreements, rates typically range from $8.00 to $12.00 per chip-hour, for a total of $15,360 to $23,040.

The CPU Run: 2,048 Cores for About 30 Days

Sustaining 2,048 physical cores for a month requires roughly 22 dedicated HPC nodes. AWS Hpc6a instances, for example, provide 96 physical AMD EPYC cores per node.

Core compute. Compute-optimized HPC capacity typically costs $0.035 to $0.05 per core-hour. Across nearly 1.5 million core-hours, the baseline bill lands between $51,600 and $73,700.

Multi-node infrastructure. A six-hour GPU job and a month-long, 22-node CPU job carry very different overhead. Keeping that many nodes connected over a low-latency fabric for 30 days, while high-resolution aerodynamic iterations continuously write checkpoint files to a high-throughput parallel file system (such as Amazon FSx for Lustre), adds substantial storage and networking cost. At enterprise rates, the all-in bill for the month can exceed $115,000.

Reading These Numbers Carefully

A few caveats keep this comparison honest:

• These are list prices. Reserved instances, spot capacity, and negotiated enterprise agreements can shift both columns significantly.

• Software licensing is excluded. For commercial solvers, license costs often rival or exceed hardware costs, and GPU and CPU runs are licensed differently. Check how your vendor counts GPUs before modeling total cost.

• The CPU baseline is a benchmark reference point. Real CPU runtimes depend on the cluster, interconnect, and solver settings, so treat the 720-hour figure as indicative rather than exact.

• Time has value of its own. A six-hour turnaround means an engineering team can evaluate several design iterations in the time a CPU cluster would deliver a fraction of one. For many organizations, that gain in iteration speed matters more than the compute savings.

Even with those caveats, the gap is wide enough to matter: for large, GPU-friendly CFD problems, faster and cheaper are no longer a trade-off.

A Decision Framework

Rather than asking "GPU or CPU?" in the abstract, frame the question around your specific workload characteristics.

Solver type. Explicit solvers (crash FEA, transient CFD) are the strongest GPU use case. Implicit solvers (static FEA, steady-state thermal) benefit less from GPU acceleration and may be better served by high-core-count CPUs.

Model size. GPU acceleration scales with model size. Below roughly 10 to 20 million cells or elements, overhead can reduce or eliminate the advantage. Above that threshold, the speedup typically grows with model complexity.

Precision requirements. If your solver requires FP64, verify the FP64 specification of the GPU hardware. Some configurations deliver dramatically different FP64 vs. FP32 throughput.

Software support. Not all simulation solvers have GPU-native implementations. Verify that your specific solver version supports GPU acceleration for your physics setup before making hardware decisions. Compatibility and performance depend on simulation setup, model complexity, and hardware specifications and should be thoroughly tested.

Energy and cost efficiency. For high-volume simulation environments, energy consumption is a meaningful operational cost. GPU-accelerated runs deliver the same results at significantly lower energy consumption per simulation, with energy consumption reductions of 88 to 93% and total cost of ownership reductions of approximately 50% reported for CFD workloads compared to CPU-only configurations [5]. As the cost breakdown above shows, the cloud compute bill for a large CFD case can drop by an order of magnitude when the workload fits the GPU well.

Where GPU Simulation Is Heading

The Blackwell B200 GPU delivers a 30x increase in real-time AI inference throughput compared to the H100 in certain large-language model scenarios, and a system coupling NVIDIA's Grace CPU with Blackwell GPUs boasts 8 TB/s of memory bandwidth, accelerating data analytics queries 18x faster than top x86 CPUs and 6x faster than the H100 [8]. As these architectures mature into simulation workflows, the gap between CPU-only and GPU-accelerated simulation performance will continue to widen.

The trajectory is clear. In the coming years, GPU solvers have the potential to replace CPUs as the standard hardware for engineering simulation. That shift is already underway in CFD. Structural and multi-physics solvers are following the same path, with each software release expanding GPU-compatible physics and narrowing the feature gap with CPU-only counterparts.

For simulation teams, the practical implication is not that CPUs are obsolete. It is that GPU-readiness of your simulation software stack, and the operational practices needed to run GPU-accelerated workloads effectively, is becoming a core competency rather than a specialist concern.

Key Takeaways

GPUs deliver their largest advantage in massively parallel, floating-point-intensive solver kernels: large-scale CFD, explicit FEA, and parametric design studies at scale. CPUs remain essential for sequential solver logic, pre- and post-processing, job orchestration, and implicit FEA workloads. For large GPU-friendly cases, the savings are financial as well as temporal: at public cloud rates, the 2.4-billion-cell Ansys/TACC case costs roughly $3,800 to $23,000 on GPUs versus $51,600 to $115,000 on CPUs. FP64 precision matters for simulation accuracy; verify hardware specifications beyond headline throughput numbers. The optimal architecture for most simulation environments is hybrid: CPUs for orchestration and CPU-bound tasks, GPUs for parallel solver acceleration. GPU acceleration is software-dependent; verify solver support for your specific physics and model configuration before investing in hardware.

References

1. Ansys / Inside HPC. (2024). Ansys Reports 110x Fluent CFD Simulation Acceleration with NVIDIA GH200. insidehpc.com

2. Ansys. (2024). Reaching New HPC Heights With Ansys and NVIDIA. ansys.com

3. NVIDIA Developer Blog. (2022). The Computational Fluid Dynamics Revolution Driven by GPU Acceleration. developer.nvidia.com

4. Ansys. (2025). Unleashing the Full Power of GPUs for Ansys Fluent Software, Part 3. ansys.com

5. EDRMedeso. (2025). Accelerating CFD with GPUs: How Ansys Discovery and Fluent Unlock 10x Faster Simulations. edrmedeso.com

6. SimuTech / Exxact Corp. CPU vs GPU in Ansys Fluent: Exxact, SimuTech, & NVIDIA Collaboration. exxactcorp.com

7. Next Platform. (2025). Sizing Up Compute Engines For HPC Work At 64-Bit Precision. nextplatform.com

8. Server Simply. (2025). Next-Gen HPC & AI Infrastructure 2025: GPUs, CXL, Gen5 NVMe. serversimply.com

About SimOps

Software development was transformed when teams stopped treating infrastructure as an afterthought and started building shared practices around it. That's what DevOps did for code. SimOps is doing the same thing for simulation.

Simulation and HPC have long operated in silos: different tools, different teams, different workflows, with no shared language or common standards. SimOps exists to change that. We're building a framework and a community where simulation engineers, HPC specialists, and CAE teams can work from the same playbook, share best practices, and push the field forward together.

If that mission resonates with you, this series is a starting point. And the community is where the conversation continues.