Benchmarking Inference Speed in LLMs
1. Key Metrics for Measuring Inference Speed
Key Metrics for Measuring Inference Speed
Latency
Latency measures the time taken for a single inference request to complete, typically from input submission to output generation. For autoregressive models like GPT-3, latency is dominated by sequential token generation, making it highly sensitive to context length. The relationship between latency (L) and sequence length (n) can be modeled as:
where tprefill is the initial processing time for the prompt and tdecode is the per-token generation time. Modern transformer architectures exhibit tdecode values ranging from 10ms to 100ms per token on high-end GPUs, depending on model size and optimization techniques.
Throughput
Throughput quantifies the number of inferences completed per unit time (typically tokens/second) under maximum load. Unlike latency, throughput benefits from batch processing due to parallelizable matrix operations in transformer attention layers. The theoretical upper bound for throughput (T) with optimal batching is:
where B is batch size. In practice, memory bandwidth and KV cache management impose constraints, causing throughput to plateau at large B. For example, NVIDIA's benchmarks show Llama 2-70B achieves 2,300 tokens/sec on eight H100 GPUs with continuous batching.
Memory Bandwidth Utilization
Inference speed is fundamentally limited by memory bandwidth (β) and arithmetic intensity (I). The roofline model predicts maximum achievable performance as:
where π is peak compute throughput. Large language models typically operate in the memory-bound regime due to their low arithmetic intensity (0.1-1 FLOP/byte). Techniques like quantization reduce memory bandwidth pressure by decreasing model weights from FP16 (2 bytes) to INT8 (1 byte) or INT4 (0.5 bytes).
Hardware-Specific Metrics
Modern accelerators introduce specialized metrics for LLM inference:
- Tokens/sec/Watt: Energy efficiency critical for edge deployment
- KV Cache Hit Rate: Measures effectiveness of attention caching strategies
- Context Utilization: Percentage of available context window actually used
NVIDIA's TensorRT-LLM reports these metrics through its benchmarking suite, enabling direct comparison across hardware platforms. For instance, the H100 GPU achieves 3× higher tokens/sec/Watt than A100 for Llama-2-13B through FP8 quantization and optimized attention kernels.
1.2 Factors Influencing Inference Latency
Inference latency in large language models (LLMs) is governed by a complex interplay of computational, architectural, and hardware-specific factors. Understanding these variables is critical for optimizing real-world deployment.
Model Architecture and Size
The transformer architecture introduces several latency-sensitive components:
- Attention mechanism complexity: The self-attention operation scales quadratically with sequence length (n). For a sequence of length n, the computational complexity is:
where d represents the hidden dimension size. This becomes particularly problematic for long-context models.
- Layer depth and width: Each additional transformer layer requires sequential computation during autoregressive generation, creating a linear dependency between layer count and latency.
Hardware Considerations
Modern accelerators exhibit different performance characteristics for key operations:
Key hardware factors include:
- Memory bandwidth: The primary bottleneck for large parameter models, as weights must be loaded from memory for each operation.
- Parallelism utilization: Tensor cores in GPUs can accelerate matrix multiplications when operations are properly batched.
Quantization and Precision
Reducing numerical precision from FP32 to INT8 typically provides:
However, this introduces:
- Quantization-dequantization overhead
- Potential accuracy degradation requiring careful calibration
Software Optimizations
Modern inference runtimes employ several acceleration techniques:
- Operator fusion: Combining multiple operations (e.g., attention projections) to reduce kernel launch overhead
- Memory planning: Optimizing tensor lifetimes to minimize allocation/deallocation costs
- Kernel auto-tuning: Selecting optimal CUDA/ROCm kernels for specific hardware configurations
Batch Processing Dynamics
Batch processing amortizes memory bandwidth costs but introduces new constraints:
where b is batch size and n is sequence length. The parallelizability depends on:
- Attention masking patterns
- Memory contention in shared compute units
Context Window Effects
Variable sequence lengths create unique challenges:
- KV cache management: The memory footprint grows as:
where h is heads, l is layers, and s is bytes per parameter. This directly impacts:
- Cache hit rates in memory hierarchy
- Prefetching effectiveness

1.3 Hardware and Software Stack Considerations
The inference speed of large language models (LLMs) is heavily influenced by the underlying hardware and software stack. Optimizing these components requires a deep understanding of computational bottlenecks, memory hierarchies, and parallel processing capabilities.
Hardware Considerations
Modern LLM inference relies on three primary hardware configurations:
- GPUs (NVIDIA A100/H100, AMD MI300X): Optimized for matrix operations with high memory bandwidth (2 TB/s on H100) and tensor cores for mixed-precision computation.
- TPUs (Google v4/v5e): Custom-designed for transformer architectures with systolic array matrix multipliers and high-speed interconnects.
- CPU-based Systems (Intel Sapphire Rapids, AMD Genoa): Useful for smaller models with advanced instruction sets (AMX, AVX-512) and large memory capacity.
The theoretical peak throughput can be calculated for each device type. For GPUs with tensor cores:
Where precision factors are 2 for FP16, 4 for INT8, and 8 for INT4 quantization. Memory bandwidth limitations create a roof for achievable performance:
Software Optimization Techniques
The software stack introduces several optimization layers:
- Kernel Fusion: Combining multiple operations (e.g., attention + projection) into single CUDA/ROCm kernels to reduce memory transfers.
- Quantization: Using 8-bit (FP8/INT8) or 4-bit (NF4/INT4) weights with quantization-aware training.
- Operator Optimization: Hand-tuned assembly kernels for common operations (e.g., FlashAttention for scaled dot-product attention).
The total latency breakdown follows:
Framework-Specific Optimizations
Different inference frameworks employ distinct optimization strategies:
| Framework | Key Features | Best Use Case |
|---|---|---|
| TensorRT-LLM | Kernel auto-tuning, in-flight batching | NVIDIA GPUs with dynamic workloads |
| vLLM | PagedAttention, continuous batching | High-throughput serving |
| ONNX Runtime | Hardware-agnostic graph optimizations | Cross-platform deployment |
The choice of framework impacts achievable throughput through:
- Memory allocation strategies (pre-allocated vs. dynamic)
- Parallel execution models (async vs. synchronous)
- Kernel scheduling algorithms
System-Level Bottlenecks
Real-world performance often deviates from theoretical peaks due to:
- PCIe Bottlenecks: x16 Gen4 provides 32 GB/s bidirectional bandwidth, insufficient for multi-GPU inference without NVLink.
- Thermal Throttling: Sustained high utilization triggers frequency scaling on air-cooled systems.
- NUMA Effects: Multi-socket CPU systems show latency spikes for non-local memory accesses.
The effective memory bandwidth accounting for these factors becomes:
Where penalties include contention (0.1-0.3), NUMA effects (0.05-0.2), and thermal throttling (0-0.15).

2. Designing Effective Benchmarking Experiments
2.1 Designing Effective Benchmarking Experiments
Accurate benchmarking of inference speed in large language models (LLMs) requires careful experimental design to isolate variables, minimize noise, and ensure reproducibility. The following principles guide robust benchmarking setups:
Controlled Hardware Environment
Hardware consistency is critical for meaningful comparisons. Benchmarking must occur on identical or standardized hardware configurations, with attention to:
- GPU/TPU specifications (architecture, memory bandwidth, CUDA cores)
- Memory hierarchy (VRAM capacity, cache sizes, system RAM)
- Thermal throttling prevention (fixed clock speeds, active cooling)
- Software drivers (CUDA/cuDNN versions, firmware updates)
The computational throughput of matrix operations scales with memory bandwidth according to:
Input Sequence Design
Token sequence characteristics significantly impact inference latency. A well-designed benchmark suite should include:
- Length variation (powers of 2 from 64 to 8192 tokens)
- Vocabulary distribution (Zipfian sampling matching real text)
- Batch size sweeps (1, 4, 16, 64 to test parallel efficiency)
- Attention pattern diversity (full, sparse, sliding window)
Measurement Protocol
Precise timing requires:
- Warm-up iterations (≥100 forward passes to stabilize caches)
- Clock synchronization (CUDA events for GPU timing)
- Statistical rigor (reporting mean ± 3σ across ≥1000 trials)
- Context separation (isolating prompt processing from generation)
The end-to-end latency for generating n tokens decomposes as:
Software Stack Control
Framework-specific optimizations can distort comparisons. Standardize:
- Precision modes (FP32, FP16, BF16, INT8 quantization)
- Kernel implementations (vanilla vs. FlashAttention-2)
- Graph optimizations (TorchScript, ONNX runtime, TensorRT)
- Memory management (fixed vs. dynamic allocation strategies)
Cross-Framework Validation
For architectural comparisons, implement identical models across frameworks (PyTorch, JAX, TensorFlow) while controlling for:
- Operator equivalence (same attention formulation)
- Parallelism strategy (tensor vs. pipeline vs. data parallelism)
- Memory layout (contiguous vs. strided access patterns)
The computational intensity I of a transformer layer relates hardware utilization to model parameters:
2.2 Standardized Benchmarking Frameworks
Standardized benchmarking frameworks provide reproducible methodologies for measuring inference speed across different hardware and software configurations. These frameworks eliminate variability introduced by ad-hoc testing procedures, ensuring fair comparisons between models. Key frameworks include MLPerf Inference, Hugging Face’s Transformers Benchmark, and NVIDIA’s TensorRT LLM Benchmark.
MLPerf Inference
MLPerf Inference is a widely adopted benchmark suite that evaluates latency and throughput under controlled conditions. It supports multiple scenarios:
- Single-stream latency: Measures response time for one input at a time.
- Multi-stream throughput: Evaluates parallel processing capacity.
- Offline batch processing: Tests maximum sustained throughput.
The benchmark reports results in queries per second (QPS) and tail latency (P99). For transformer-based models, MLPerf uses fixed input sequences and enforces strict reproducibility rules, such as:
Hugging Face Transformers Benchmark
Hugging Face’s benchmark focuses on real-world usability by testing models with dynamic input lengths and mixed precision (FP16/INT8). Key metrics include:
- Tokens/second: Normalized speed across variable sequence lengths.
- Memory footprint: Peak GPU memory consumption during inference.
The framework automates warm-up iterations and statistical aggregation to reduce measurement noise. For example, the effective throughput is computed as:
where N is the batch size, L is sequence length, and ti is the latency for the i-th sample.
NVIDIA TensorRT LLM Benchmark
TensorRT LLM provides hardware-specific optimizations for NVIDIA GPUs, including kernel fusion and memory-efficient attention. Its benchmark measures:
- End-to-end pipeline latency: Includes pre/post-processing.
- GPU utilization: SM occupancy and memory bandwidth.
The framework uses CUDA events for precise timing and supports quantized models. A critical optimization is the use of persistent thread blocks for attention layers, reducing overhead from:
Cross-Framework Comparison
Results across frameworks are not directly comparable due to differing configurations. MLPerf uses fixed workloads, while Hugging Face and TensorRT LLM allow dynamic inputs. For research, MLPerf provides stricter controls, whereas TensorRT LLM reflects production-grade optimizations.
2.3 Handling Variable Input Lengths and Batch Sizes
Transformer-based language models process input sequences in parallel, but their computational efficiency is highly sensitive to input length and batch size variations. The self-attention mechanism's quadratic complexity with respect to sequence length (O(n²)) makes dynamic length handling particularly challenging for real-time applications.
Dynamic Batching Strategies
Static batching pads all sequences to the maximum length in a batch, wasting computation on padding tokens. Dynamic batching groups sequences of similar lengths to minimize padding while maintaining parallel processing:
where B is batch size and L_i is sequence length. Advanced frameworks like NVIDIA's FasterTransformer implement:
- Bucket-based batching: Pre-defines length buckets (e.g., 32, 64, 128 tokens)
- Memory-aware batching: Dynamically adjusts batch size based on GPU memory constraints
- Iterative filling: Adds sequences to batches until hitting hardware limits
Kernel Optimization for Ragged Tensors
Modern inference engines use specialized kernels for processing uneven sequences:
Where dmodel is hidden dimension and dff is feed-forward dimension. Techniques include:
- Prefix-sum indexing: Stores sequence boundaries in CSR format
- Warp-level primitives: CUDA kernels that avoid thread divergence
- FlashAttention variants: Memory-efficient attention for mixed lengths
Memory Bandwidth Considerations
Variable-length processing exacerbates memory bandwidth bottlenecks. The effective bandwidth utilization follows:
Optimizations include:
- Tensor parallelism: Splits weight matrices across memory channels
- Selective activation offloading: Moves only necessary activations to HBM
- Block-sparse attention: Skips computation for padding regions
Real-World Performance Tradeoffs
Benchmarks on A100 GPUs with Llama-2-70B show:
| Strategy | Throughput (tokens/sec) | Latency (ms/token) |
|---|---|---|
| Static batching | 1,240 | 38 |
| Dynamic batching | 2,810 | 17 |
| Memory-optimized | 3,450 | 14 |
The optimal strategy depends on the latency-throughput requirements of the deployment scenario. Streaming applications favor dynamic batching, while batch processing benefits from memory-aware approaches.

3. Model Quantization and Pruning
Model Quantization and Pruning
Quantization: Reducing Precision for Efficiency
Quantization reduces the numerical precision of model parameters, typically from 32-bit floating-point (FP32) to 8-bit integers (INT8) or lower. The process involves mapping a continuous range of values to a discrete set, minimizing memory footprint and accelerating computation. For a weight tensor W with range [wmin, wmax], the quantized version Wq is computed as:
where s is the scaling factor and n is the target bit-width. Dequantization reconstructs the approximate original values:
Post-training quantization (PTQ) applies this transformation after training, while quantization-aware training (QAT) simulates quantization during training to preserve accuracy. Mixed-precision quantization dynamically allocates bit-widths per layer based on sensitivity analysis.
Pruning: Removing Redundant Parameters
Pruning eliminates less important weights or neurons, creating sparse models. The magnitude-based pruning criterion removes weights below a threshold θ:
Structured pruning removes entire channels or heads in transformer models, enabling hardware-friendly sparsity. The Lottery Ticket Hypothesis suggests that subnetworks capable of matching original performance exist within dense networks. Iterative pruning retrains the model after each sparsification step to recover accuracy.
Hardware Implications
Quantized models leverage integer arithmetic units (e.g., NVIDIA Tensor Cores) for 2-4× speedup over FP32. Sparse models require specialized kernels (e.g., CUDA Sparse Tensor Cores) to skip zero-valued computations. The FLOPs reduction ratio R for a pruned model with sparsity S is:
Modern compilers like TensorRT and TVM fuse quantization/dequantization ops and optimize kernel selection for target hardware.
Case Study: GPT-3 Optimization
Applying 8-bit quantization to GPT-3 (175B parameters) reduces memory usage from 700GB to 175GB. Combining 50% magnitude pruning with quantization achieves 10× inference speedup on A100 GPUs while retaining 98% of the original accuracy on benchmark tasks.
Trade-offs and Limitations
- Accuracy drop: Aggressive quantization below 8 bits or pruning beyond 80% sparsity often requires distillation or retraining.
- Hardware dependence: INT4 acceleration isn't universally supported; sparsity patterns must align with processor architectures.
- Dynamic range: Attention logits in transformers require careful quantization to preserve softmax probabilities.

3.2 Efficient Attention Mechanisms
Standard attention mechanisms in transformers exhibit quadratic complexity
Sparse Attention Variants
Sparse attention reduces computation by limiting the attention field through predefined patterns. The Longformer introduces dilated sliding windows with global tokens, achieving
where d is the embedding dimension. The first term accounts for local attention within windows, while the second handles optional global attention positions.
Low-Rank Approximation Methods
Linformer's key insight projects the n×d key and value matrices to k×d dimensions (k ≪ n) via learned projections. The modified attention score calculation becomes:
where Ei, Ej are projection matrices. This reduces memory usage from O(n^2) to O(nk) while maintaining 95% of original accuracy on benchmark tasks.
Memory-Centric Optimizations
FlashAttention exploits hardware memory hierarchy through:
- Tiling to fit blocks in SRAM
- Recomputation during backward passes to avoid storing intermediate matrices
- Fused kernel operations minimizing HBM accesses
The algorithm achieves 2-4× speedup on modern GPUs by reducing memory reads/writes from
Hybrid Approaches
Recent architectures like Sparse Sinkhorn Attention combine:
- Locality-sensitive hashing for bucket assignment
- Differentiable sorting operations
- Block-sparse matrix multiplication
This achieves O(n log n) complexity with < 1% accuracy drop on GLUE benchmarks compared to full attention, while enabling processing of 64k-token sequences on consumer hardware.

3.3 Hardware-Specific Optimizations
Optimizing inference speed in large language models (LLMs) requires hardware-aware strategies that exploit the underlying architecture of modern accelerators. The primary bottlenecks—memory bandwidth, compute throughput, and parallelism—must be addressed through a combination of low-level optimizations and hardware-specific techniques.
GPU-Specific Optimizations
Modern GPUs, such as NVIDIA's A100 and H100, leverage tensor cores for mixed-precision matrix operations. To maximize throughput:
- Kernel Fusion: Combine multiple operations (e.g., layer normalization followed by GeLU) into a single CUDA kernel to reduce global memory accesses.
- Memory Coalescing: Ensure contiguous memory access patterns to minimize cache misses. For example, transposing weight matrices to enable stride-1 accesses during matrix multiplication.
- Asynchronous Execution: Overlap computation with data transfers using CUDA streams, minimizing idle time.
Theoretical peak bandwidth is rarely achieved due to memory access patterns. For instance, the A100's 1555 GB/s bandwidth can drop to 30-40% utilization without proper coalescing.
TPU-Specific Optimizations
Google's TPUs employ systolic arrays optimized for large matrix multiplications. Key considerations include:
- Batching Strategies: TPUs achieve peak performance with large batch sizes (e.g., 1024+), requiring dynamic batching techniques for latency-sensitive applications.
- Weight Stationary Dataflow: Keep weight matrices stationary in the matrix multiply unit while streaming activations, reducing I/O pressure.
- MXU Utilization: The 128x128 matrix multiply unit requires 4x4 tiling for bfloat16 operations, necessitating padding for non-divisible dimensions.
Quantization and Sparsity
Reducing precision from FP32 to INT8 or INT4 via quantization can yield 2-4x speedups on supported hardware:
where s is the scaling factor and b is the bit-width. NVIDIA's TensorRT and AMD's ROCm implement dynamic quantization with calibration to minimize accuracy loss.
Structured sparsity (e.g., 2:4 pattern) enables additional speedups by skipping zero-valued computations:
- NVIDIA's Ampere architecture achieves 2x throughput for 50% sparsity by packing two 16-bit indices per 32-bit word.
- Requires retraining with magnitude pruning or L1 regularization to maintain accuracy.
Memory Hierarchy Optimization
Modern accelerators feature complex memory hierarchies (HBM, L2 cache, shared memory). Effective strategies include:
- Operator Tiling: Decompose large matrix multiplications into tiles that fit in L1 cache (e.g., 256x128 tiles for A100).
- Prefetching: Use CUDA graphs to pipeline memory transfers, hiding latency for subsequent layers.
- Register Blocking: Unroll inner loops to maximize register usage, reducing shared memory pressure.
The roofline model provides an analytical framework for identifying bottlenecks:
where π is peak compute and β is memory bandwidth. For a 7B parameter model with 0.1 FLOP/byte operational intensity, memory bandwidth typically limits performance.

4. Benchmarking Popular LLMs (GPT, Llama, Mistral)
4.1 Benchmarking Popular LLMs (GPT, Llama, Mistral)
When benchmarking inference speed across large language models (LLMs), three key architectures dominate contemporary research and deployment: OpenAI's GPT family, Meta's Llama series, and Mistral AI's models. Each exhibits distinct computational characteristics that influence real-world performance.
Computational Complexity and Architectural Differences
The inference latency of transformer-based LLMs primarily depends on their attention mechanism scaling. For a model with n layers, h attention heads, and sequence length s, the time complexity of self-attention is:
where d represents the hidden dimension size. GPT-4 employs a mixture-of-experts architecture that dynamically routes computations, while Llama 2's grouped-query attention reduces memory bandwidth requirements. Mistral 7B achieves efficiency through sliding window attention with:
where w is the fixed window size (typically 4096 tokens).
Quantitative Benchmarking Methodology
Standardized benchmarking requires controlling for:
- Hardware consistency: Fixed GPU configuration (e.g., A100 80GB with NVLink)
- Precision: FP16 vs. INT8 quantization tradeoffs
- Batch size: Measuring both single-sequence and batched throughput
- Sequence length: From 512 to 8192 tokens to test attention scaling
The inference time T for a forward pass can be modeled as:
where k is the number of generated tokens, with prefill time dominated by matrix multiplications and decode time by memory bandwidth.
Empirical Performance Comparison
On an A100 GPU with FP16 precision and 2048-token sequences:
| Model | Params (B) | Prefill (ms) | Decode (ms/token) | Mem (GB) |
|---|---|---|---|---|
| GPT-4 | ~220 | 420 | 85 | 84 |
| Llama 2 70B | 70 | 380 | 62 | 48 |
| Mistral 7B | 7 | 110 | 18 | 14 |
The memory-bandwidth-bound nature of decoding becomes apparent when examining the relationship between model size and token generation speed. For the 70B parameter regime, the theoretical roofline for memory bandwidth (1555GB/s on A100) predicts:
which aligns with observed measurements when accounting for kernel launch overheads.
Optimization Techniques
Recent advances in inference optimization demonstrate significant speedups:
- FlashAttention-2: Reduces memory operations in attention by 4-6×
- PagedAttention: Enables non-contiguous memory allocation for variable-length sequences
- Tensor parallelism: Distributes model parameters across multiple GPUs with near-linear scaling
When applied to Llama 2 70B, these techniques can achieve:
yielding 150ms/token latency at scale. The optimal configuration depends on the specific deployment constraints, with smaller models like Mistral 7B benefiting more from quantization than architectural optimizations.
4.2 Real-World Deployment Scenarios
In production environments, LLM inference speed is constrained by hardware limitations, batch processing requirements, and latency-sensitive applications. The interplay between model architecture, quantization techniques, and hardware acceleration determines practical throughput. For instance, a 175B-parameter model like GPT-3 requires approximately 350GB of GPU memory in FP32 precision, making naive deployment infeasible for real-time applications.
Latency-Critical Applications
Chatbots and voice assistants demand sub-200ms response times to maintain conversational flow. This imposes strict constraints on autoregressive generation length and batch size. The end-to-end latency L for generating n tokens can be modeled as:
where tprefill is the initial prompt processing time and tdecode is the per-token generation time. Optimizing this tradeoff requires:
- Dynamic batching: Grouping requests with similar context lengths
- Continuous batching: Interleaving generation of new tokens across requests
- Speculative decoding: Predicting multiple tokens ahead with verification
Throughput-Optimized Scenarios
Batch processing applications like document summarization prioritize tokens/second over individual request latency. Here, the key metric becomes hardware utilization efficiency, measured by the ratio of achieved throughput to theoretical maximum:
Modern inference servers achieve 60-80% utilization through:
- PagedAttention: Managing non-contiguous memory for variable-length sequences
- Tensor parallelism: Distributing weight matrices across multiple GPUs
- KV cache optimization: Compressing attention key-value pairs by 4-8x
Edge Deployment Constraints
Mobile and embedded devices introduce additional challenges due to thermal limits and memory bandwidth. A quantized 7B-parameter model running on a smartphone GPU typically achieves 5-15 tokens/second, with performance bounded by:
where M is model size, B is memory bandwidth, and f is clock frequency. Practical deployments use:
- 4-bit quantization: Reducing model size by 75% with minimal accuracy loss
- Pruning: Removing 20-50% of attention heads with structured sparsity
- Operator fusion: Combining linear and activation layers to reduce memory traffic
Case Study: Large-Scale Search Augmentation
A major search engine deployed a 137B-parameter LLM for query understanding, requiring <1ms latency per token at 50k queries/second. Their solution combined:
- Weight streaming: Loading layers on-demand from SSD
- Pre-computed embeddings: Caching frequent query representations
- Hybrid CPU/GPU execution: Offloading embedding layers to CPUs
This achieved 0.8ms/token latency while maintaining 99.9% cache hit rate for frequent queries, demonstrating how architectural innovations can overcome theoretical hardware limits.
4.3 Trade-offs Between Speed and Accuracy
Quantifying the Pareto Frontier
The relationship between inference speed and model accuracy in LLMs is governed by a Pareto frontier, where improvements in one metric degrade the other. This trade-off arises from architectural choices, computational constraints, and statistical limits. For a transformer-based model with L layers, d attention heads, and hidden dimension h, the theoretical lower bound on latency for autoregressive generation can be expressed as:
where N is sequence length, tlayer is per-layer processing time, and C accounts for memory bandwidth constraints. Meanwhile, the perplexity (PP) degradation when applying quantization or pruning follows:
where ΔW and ΔA represent weight and activation quantization errors, with coefficients α, β empirically determined through neural tangent kernel analysis.
Architectural Levers for Optimization
Three primary techniques alter the speed-accuracy curve:
- Model Distillation: Teacher-student frameworks compress knowledge into smaller architectures, typically achieving 2-4× speedup with <5% accuracy drop when using attention-matching losses.
- Quantization: 8-bit integer quantization reduces memory bandwidth by 4× but introduces rounding error that accumulates nonlinearly across layers. Group-wise quantization (e.g., 4-bit with 64-value scaling groups) can preserve >99% of original accuracy.
- Early Exit: Dynamic depth networks like DeeBERT allow intermediate layer exits when confidence thresholds are met, reducing average inference cost by 30-60% on classification tasks.
Hardware-Aware Optimization
The optimal operating point depends on hardware characteristics. For NVIDIA A100 GPUs with 1,555 GB/s memory bandwidth, the compute-bound regime occurs when:
This suggests different optimization strategies for memory-bound versus compute-bound scenarios. TensorRT-LLM demonstrates this by achieving 3.1× faster inference than vanilla FP16 with INT8 quantization on memory-bound workloads, but only 1.8× improvement on compute-bound tasks.
Case Study: Mixture of Experts
Sparse MoE models like Switch Transformer exemplify the trade-off's nonlinear nature. With expert utilization k/N (where k is active experts per token), the speedup follows:
where c ≈ 0.1 represents routing overhead. At 64 experts with k=2, this achieves 8.9× speedup over dense models while maintaining 98.7% of the accuracy on multilingual benchmarks.

5. Key Research Papers on LLM Inference
5.1 Key Research Papers on LLM Inference
- LLM-Inference-Bench: Inference Benchmarking of Large Language Models on ... — Benchmarking the performance of LLMs across diverse hardware platforms is crucial to understanding their scalability and throughput characteristics. We introduce LLM-Inference-Bench, a comprehensive benchmarking suite to evaluate the hardware inference performance of LLMs. ... Electronic ISBN: 979-8-3503-5554-3 Print on Demand(PoD) ISBN: ...
- PDF Efficient Distributed LLM Inference with Dynamic Partitioning — Currently, LLM inference engines such as vLLM [18], HuggingFace's TGI [13], and NVIDIA's TensorRT-LLM [23] make use of the approach proposed by Megatron-LM[30], which describes a specific model partitioning strategy to distribute tensor computation across GPUs. Our key observation is that inference with LLMs is uniquely different from other ...
- Papers with Code - LLM-Inference-Bench: Inference Benchmarking of Large ... — Stay informed on the latest trending ML papers with code, research developments, libraries, methods, and datasets. ... Benchmarking the performance of LLMs across diverse hardware platforms is crucial to understanding their scalability and throughput characteristics. We introduce LLM-Inference-Bench, a comprehensive benchmarking suite to ...
- PDF Outrageously Fast LLMs: Faster Inference and Fine-Tuning with ... — FLOPS required at inference. 3 Approach Our project is divided into two phases. First, we use MoEficationto convert the FFNs of a pretrained model into a mixture-of-experts, which increases inference speed but results in modest loss in performance on downstream tasks. Second, we utilize LoRA fine-tuning to recover model quality
- Introduction to LLM Inference Benchmarking — NVIDIA NIM for Large ... — Introduction to LLM Inference Benchmarking# The past few years have witnessed the rise in popularity of generative AI and Large Language Models (LLMs), as part of a broader AI revolution. As LLM-based applications are increasingly rolled out across enterprises, there is a strong and urgent need to benchmark and ensure the cost efficiency of ...
- PDF Understanding Performance Implications of LLM Inference on CPUs — B. LLM Inference LLM inference typically consists of two phases: the Prefill Phase and the Decode Phase, as shown in Figure3. During the prefill phase, the model processes all input prompts from the user and produces a new token used for initial input for the decode phase. This phase involves computing the hidden
- Benchmarking LLM Speed — NOTE: This document tries to avoid using the term "performance" since in ML research the term performance typically refers to measuring model quality/capabilities. This is a cheat sheet for running a simple benchmark on consumer hardware for LLM inference using the most popular end-user inferencing engine, llama.cpp and its included llama ...
- dmatora/LLM-inference-speed-benchmarks - GitHub — This repository contains benchmark data for various Large Language Models (LLM) based on their inference speeds measured in tokens per second. The benchmarks are performed across different hardware configurations using the prompt "Give me 1 line phrase". The data represents the performance of ...
- Understanding performance benchmarks for LLM inference — Similarly, inference providers want to focus on benchmarks where they do well. This guide will help you understand performance benchmarking for LLMs. You'll learn how to select metrics for your use case and what factors to keep in mind when comparing models and inference providers. Selecting benchmark methodology
- Large Language Model Performance Benchmarking on Mobile Platforms: A ... — In addition to those open-source LLM inference engines, mobile SoC vendors and manufacturers have also realized the importance of on-device LLM inference. Qualcomm, the vendor of Snapdragon SoCs, asserts that it can accelerate Llama-2 7B and Llama-3 8B models using the NPU on Snapdragon Gen2 and Gen3 platforms [ 36 ] .
5.2 Open-Source Benchmarking Tools
- Introduction to LLM Inference Benchmarking — NVIDIA NIM for Large ... — Standardized benchmarking of LLM performance can be done with many tools, including long-standing tools such as Locust and K6, along with new open-source tools that are specialized for LLMs such as NVIDIA GenAI-Perf and LLMPerf. These client-side tools offer specific metrics for LLM-based applications but are not consistent in how they define ...
- argonne-lcf/LLM-Inference-Bench - GitHub — Fund open source developers ... Please find our results dashboard to compare different LLMs, Inference Frameworks and Hardware for different batch sizes and input/output lengths here. 📌 Citation. If you find this repository useful, please consider citing our paper: @article{chitty2024llm, title={LLM-Inference-Bench: Inference Benchmarking of ...
- EchoSwift: An Inference Benchmarking and Configuration Discovery Tool ... — In the dynamic landscape of LLMs, the demand for efficient inference benchmarking is crucial. Organizations such as TPC and SPEC brought several industry standard benchmark [1][2][3][4]. This publication introduces EchoSwift [11], a comprehensive benchmarking framework designed to evaluate the real-time performance of LLMs in deployment scenarios.
- LLM Inference Benchmarking: Fundamental Concepts — To support developers with benchmarking inference performance, NVIDIA also offers GenAI-Perf, an open-source generative AI benchmarking tool. ... there are relevant LLM serving parameters that can affect the inference performance as well as the accuracy of the benchmark. Most LLMs have a special end-of-sequence (EOS) token, which signifies the ...
- Exploring LLMs Speed Benchmarks: Independent Analysis - Inferless — Dive into our comprehensive speed benchmark analysis of the latest Large Language Models (LLMs) including LLama, Mistral, and Gemma. Uncover key performance insights, speed comparisons, and practical recommendations for optimizing LLMs in your projects. Our independent, detailed review conducted on Azure's A100 GPUs offers invaluable data for developers, researchers, and AI enthusiasts aiming ...
- LLM-Inference-Bench: Inference Benchmarking of Large Language Models on ... — Large Language Models (LLMs) have propelled groundbreaking advancements across several domains and are commonly used for text generation applications. However, the computational demands of these complex models pose significant challenges, requiring efficient hardware acceleration. Benchmarking the performance of LLMs across diverse hardware platforms is crucial to understanding their ...
- Optimizing Inference Performance for "On-Prem" LLMs — In scenarios where these concerns prevent enterprises from launching and scaling LLMs in production, AI teams may choose to customize and deploy open source LLMs directly within their private environments. These LLMs are commonly referred to as "on-prem" LLMs. As a result, on-prem LLMs may offer a great deal of privacy and security over MaaS.
- LLM-Inference-Bench: Inference Benchmarking of Large Language Models on ... — llama.cpp is an open-source, high-performance portable inference framework for LLMs written in C/C++, a viable alternative to heavyweight frameworks. It stands out for its ability to run models efficiently on consumer-grade hardware, making LLM inference accessible to users without specialized equipment.
- LLM Benchmarks Explained: Significance, Metrics & Challenges — Need for dynamic benchmarking: Incorporating new benchmark speed running models that evolve in real-time could help maintain meaningful evaluations. The future of LLM benchmark comparison lies in developing adaptive benchmarks that update regularly, introduce novel challenges, and better reflect real-world AI deployment scenarios.
- Benchmarking Large Language Models (LLMs) - GitHub — Name - The name of the large language model (LLM), often hyperlinked to its source or documentation.; Size - The number of parameters the model has, typically represented in billions (b) or other units.; Context - The maximum number of tokens the model can consider from previous inputs in a conversation or text sequence.; MAX VRAM (Gb) - The maximum amount of Video RAM (in gigabytes) required ...
5.3 Recommended Books and Articles
- Benchmarking Speed and Memory of Quantized LLMs — Quantifying the benefits gained from quantization requires careful measurement of inference speed and memory consumption. While the previous section discussed evaluating model quality (like perplexity or task accuracy), here we focus on measuring the efficiency improvements, which are often the primary motivation for quantizing LLMs. Measuring Inference Speed Inference speed tells us how ...
- LLM-Inference-Bench: Inference Benchmarking of Large Language Models on ... — Benchmarking the performance of LLMs across diverse hardware platforms is crucial to understanding their scalability and throughput characteristics. We introduce LLM-Inference-Bench, a comprehensive benchmarking suite to evaluate the hardware inference performance of LLMs.
- LLM-Inference-Bench: Inference Benchmarking of Large Language Models on ... — Large Language Models (LLMs) have propelled groundbreaking advancements across several domains and are commonly used for text generation applications. However, the computational demands of these complex models pose significant challenges, requiring efficient hardware acceleration. Benchmarking the performance of LLMs across diverse hardware platforms is crucial to understanding their ...
- PDF Understanding Performance Implications of LLM Inference on CPUs — The identification of challenges for LLM inference and opportunities for acceleration using new CPU-based platforms. The first extensive performance characterization of LLM inference on the latest Intel CPUs. A comprehensive performance comparison of the latest CPUs with state-of-the-art GPUs for LLM inference with various LLMs and ...
- (PDF) LLM-Inference-Bench: Inference Benchmarking of Large Language ... — We introduce LLM-Inference-Bench, a comprehensive benchmarking suite to evaluate the hardware inference performance of LLMs.
- AMD GPU Performance for LLM Inference: A Deep Dive — AMD's MI300X GPU outperforms Nvidia's H100 in LLM inference benchmarks with its larger memory and higher bandwidth, impacting AI hardware performance and model capabilities.
- Reproducible Performance Metrics for LLM inference - Anyscale — Anyscale is releasing LLMPerf for benchmarking LLMs on current LLM offerings. See benchmarking results for Anyscale Endpoints vs Fireworks.ai.
- LLM Inference Performance Engineering: Best Practices — Learn best practices for optimizing LLM inference performance on Databricks, enhancing the efficiency of your machine learning models.
- How to benchmark and optimize LLM inference performance (for data ... — To get data scientists started, I compiled a list of the most used large language model (LLM) inference performance metrics and optimization techniques that NVIDIA, Databricks, Anyscale, and other ...
- Benchmarking Large Language Models (LLMs) - GitHub — About Comprehensive benchmarks and evaluations of Large Language Models (LLMs) with a focus on hardware usage, generation speed, and memory requirements.








