Executing large language models efficiently hinges on effectively translating their core computational operations onto the specific capabilities of the target hardware. While model compression techniques reduce theoretical complexity, achieving low latency and high throughput in practice requires understanding how fundamental operations like matrix multiplication (GEMM) and the attention mechanism interact with CPUs, GPUs, TPUs, and other specialized accelerators. This mapping is not merely about running code; it involves structuring computations to exploit the parallelism, memory hierarchy, and specialized execution units inherent in each architecture.

The dominant computations within transformer-based LLMs are dense matrix multiplications, found in feed-forward networks and attention projections, and the attention mechanism itself, which involves several matrix multiplications along with element-wise operations and data permutations. The efficiency of these operations dictates overall inference performance.

Central Processing Units (CPUs)

Modern multi-core CPUs offer parallelism through multiple independent cores and instruction-level parallelism via Single Instruction, Multiple Data (SIMD) vector units (e.g., AVX2, AVX-512). Mapping LLM operations onto CPUs involves:

Multi-threading: Distributing computation, such as slices of matrix multiplications or parallel processing of elements in a batch, across available CPU cores. Libraries like OpenMP or threading frameworks handle this distribution.
Vectorization (SIMD): Utilizing vector instructions to perform the same operation on multiple data elements simultaneously (e.g., multiplying or adding 8, 16, or even more floating-point numbers in a single instruction). Compilers attempt auto-vectorization, but optimal performance often requires intrinsics or specialized libraries like Intel's MKL or OpenBLAS, which contain highly optimized GEMM routines leveraging AVX.

However, CPUs typically face limitations for large-scale LLMs:

Lower Parallelism: Compared to GPUs or TPUs, CPUs have far fewer parallel execution units.
Memory Bandwidth: While CPU caches are sophisticated, the main memory bandwidth can become a significant bottleneck when dealing with the massive weight matrices and activations of LLMs, especially for GEMM operations which have a high computational intensity but also require substantial data movement.
GEMM Scaling: The performance of matrix multiplication on CPUs scales well with matrix size up to a point, but eventually becomes limited by cache sizes and memory bandwidth, particularly for the large hidden dimensions common in LLMs.

CPUs remain relevant for smaller models, specific deployment scenarios (e.g., edge devices where power or cost constraints preclude dedicated accelerators), or tasks where latency for small batches is prioritized over maximum throughput.

Graphics Processing Units (GPUs)

GPUs are the primary workhorses for training and inference of large deep learning models due to their massively parallel architecture, designed initially for graphics rendering but exceptionally well-suited for the types of computations prevalent in neural networks. Key aspects of mapping LLM operations to GPUs include:

Massive Parallelism (SIMT): GPUs contain thousands of simple cores (CUDA cores in NVIDIA terminology, organized into Streaming Multiprocessors or SMs) that execute instructions in a Single Instruction, Multiple Thread (SIMT) fashion. This allows enormous batches of identical operations (like those in GEMM or element-wise layers) to be executed concurrently.
High Memory Bandwidth: GPUs are equipped with high-bandwidth memory (HBM), providing significantly more memory throughput than typical CPU main memory. This is essential for feeding the vast number of compute units and handling the large intermediate activation tensors in LLMs.
Specialized Units (Tensor Cores): Modern NVIDIA GPUs include Tensor Cores designed to accelerate specific types of matrix multiply-accumulate (MMA) operations, particularly for mixed-precision formats like FP16, BF16, and INT8. Mapping GEMM operations to Tensor Cores can yield substantial performance gains over standard FP32 CUDA core execution. Libraries like cuBLAS (for GEMM) and cuDNN (for other NN operations like convolutions, though less central to Transformers) automatically leverage Tensor Cores when appropriate data types are used.
Attention Mapping: The self-attention mechanism, involving query-key dot products, softmax, and value aggregation, presents unique challenges. While composed of GEMMs and element-wise operations, the intermediate steps and data dependencies require careful implementation. Naive implementations can be memory-bandwidth bound due to reading and writing large intermediate attention score matrices. Optimized kernels, such as FlashAttention, restructure the computation to reduce the amount of data transferred to and from HBM, often fusing multiple steps and leveraging on-chip SRAM (shared memory) more effectively.

Mapping computations involves partitioning the work (e.g., matrix tiles in GEMM) across SMs and thread blocks, managing data movement between HBM and the SM's local memory resources (registers, shared memory), and coordinating execution using frameworks like CUDA or OpenCL.

Tensor Processing Units (TPUs)

Google's TPUs are Application-Specific Integrated Circuits (ASICs) designed explicitly to accelerate neural network computations, with a primary focus on large-scale matrix operations.

Matrix Multiply Unit (MXU): The core of a TPU is the MXU, which functions as a systolic array. Systolic arrays are highly efficient architectures for performing matrix multiplications. Data elements are rhythmically pumped through a grid of processing elements (PEs), each performing a multiply-accumulate operation. This design minimizes data movement from main memory (HBM, typically) once the initial operands are loaded, achieving very high computational throughput for dense matrix operations.
Mapping GEMM: GEMM operations map almost directly onto the MXU's capabilities. The large size of the MXU (e.g., 128x128) is well-suited to the dimensions commonly found in LLM layers.
Vector/Scalar Units: TPUs also include vector and scalar units to handle non-matrix operations like activation functions, normalizations, and element-wise computations. However, the performance balance is heavily tilted towards the MXU. Workloads that are not dominated by large, dense matrix multiplications might not utilize the TPU as effectively as those that are.
Software Ecosystem (XLA): TPUs are typically programmed via higher-level frameworks like TensorFlow or JAX, which use the XLA (Accelerated Linear Algebra) compiler. XLA compiles the computational graph, optimizing and fusing operations before generating low-level code specifically targeting the TPU's MXU and other units.

TPUs excel in scenarios involving massive matrix computations, characteristic of both training and large-batch inference for LLMs. Their specialized nature provides exceptional performance and power efficiency for these tasks.

Other Accelerators (NPUs, FPGAs, Custom ASICs)

Beyond general-purpose CPUs and GPUs/TPUs, a growing landscape of specialized accelerators exists:

Neural Processing Units (NPUs): Often found in mobile System-on-Chips (SoCs) or edge devices, NPUs are designed to accelerate common NN operations with high power efficiency. They may include specialized instruction sets or hardware blocks for tasks like INT8 matrix multiplication, specific activation functions, or even certain attention patterns. Mapping involves targeting these specific hardware features, often through dedicated vendor libraries and compilers (e.g., SNPE for Qualcomm, Core ML for Apple).
Field-Programmable Gate Arrays (FPGAs): FPGAs offer hardware reconfigurability. While development is more complex, they allow tailoring the hardware logic precisely to the LLM's computational graph. This can be advantageous for non-standard operations or achieving very low latency for specific model structures. Mapping involves hardware description languages (HDLs) like Verilog or VHDL, or higher-level synthesis tools.
Custom ASICs: Companies sometimes develop fully custom ASICs optimized for their specific LLM workloads (e.g., AWS Inferentia/Trainium, Google TPUs). These offer the highest potential performance and efficiency but lack flexibility and involve significant development costs. Mapping is tied to the specific architecture and its associated software stack.

These accelerators often prioritize specific aspects like power efficiency (NPUs), low latency (FPGAs), or maximum throughput for a narrow range of models (custom ASICs).

Comparative Analysis and Considerations

Choosing the right hardware and optimizing the mapping depends heavily on the specific LLM and deployment constraints.

Relative positioning of hardware types based on typical peak compute throughput and memory bandwidth relevant to large model inference. Exact values vary significantly by specific model and generation.

Key factors influencing mapping effectiveness include:

Arithmetic Intensity: Operations like GEMM are compute-bound if the hardware provides sufficient memory bandwidth. Attention can be memory-bandwidth-bound if not implemented carefully. The hardware choice must align with the bottlenecks of the specific model layers.
Data Types: Utilizing lower precision (FP16, BF16, INT8) is crucial for performance. Hardware units like Tensor Cores or specialized INT8 engines provide significant speedups, but the mapping must ensure data flows correctly through these units.
Batch Size: Larger batch sizes generally improve hardware utilization, especially on GPUs and TPUs, by amortizing kernel launch overheads and better saturating parallel units. However, latency requirements often restrict batch sizes in real-time applications.
Memory Capacity: LLMs require substantial memory. The mapping strategy must consider the available HBM or DRAM capacity, potentially involving techniques like model parallelism (discussed later) if a single accelerator's memory is insufficient.

Effective mapping isn't just about using the hardware; it's about structuring the LLM's computations to align optimally with the architecture's strengths, whether that's the massive parallelism of a GPU, the matrix-crunching power of a TPU, or the specialized efficiency of an NPU. Low-level libraries (cuBLAS, MKL, OneDNN) and compilers (XLA, TVM, TensorRT) play an indispensable role by implementing many of these optimized mappings, translating high-level model descriptions into efficient hardware-specific code.