Geekbench scores and AI performance are weakly correlated Geekbench is a widely used benchmark that produces a single number representing a device’s compute throughput across a suite of standardized tasks. It is reliable for what it measures — integer and floating-point computation on standardized kernels, memory performance, and CPU branch prediction. It does not measure what AI workloads actually require, and the score-to-deployment translation has no published transfer function. The score is useful for comparing devices within Geekbench’s task profile. It is not useful for predicting whether a machine will handle your AI inference or training workload at acceptable performance. The distinction matters because procurement decisions get made on the strength of a single composite number, and that number was never engineered to answer the AI question. Buyers who treat it as an AI proxy are reading hardware specs through a benchmark that, by design, ignores most of what determines AI throughput in production. That gap — between a clean, headline-friendly score and the messy behaviour of a real model under load — is the same gap that breaks every attempt to read AI performance off a spec sheet. We see it constantly in hardware comparisons where the Geekbench score is treated as evidence; in our experience, the relationship between that score and observed AI throughput on the same machine is closer to coincidence than causation for any non-trivial model. What does Geekbench actually measure? Geekbench’s test suite is composed of several distinct subtests, each with its own scope and limitations: Category What is tested CPU performance Integer and FP operations on standardized kernels Memory performance Bandwidth and latency on standard access patterns GPU (Compute) OpenCL/Metal compute on standardized tasks ML score (newer versions) A subset of inference tasks on CPU/GPU The CPU and memory subtests reflect the workload profile of consumer applications — image processing, compression, HTML parsing, PDF rendering. The GPU compute test reflects general GPU compute using OpenCL or Metal, not AI-specific operations like attention, large matrix multiplications, or tensor operations at the sizes AI workloads use. The newer ML subtest runs inference on a small set of models at fixed batch sizes, which is closer but still far from the workload an AI deployment actually runs. This is not a flaw in Geekbench. It is a scope choice. The benchmark was designed for cross-platform device comparison across consumer and prosumer use cases, and it does that job well. Why don’t Geekbench scores predict AI performance? There are four structural reasons, and each of them traces back to the same underlying point: AI performance is an execution property of a running system, not a static property of the hardware, so a benchmark designed around small standardized kernels cannot capture it. FLOPS at the wrong scale. Geekbench’s computation kernels are small relative to AI model operations. A transformer attention operation processes matrices of shape [batch × seq_len × d_model] with sequence lengths in the thousands and model dimensions in the thousands; Geekbench’s kernels are orders of magnitude smaller. The hardware behaviour at those two scales is genuinely different — cache occupancy, Tensor Core utilisation, kernel launch amortisation, and memory access patterns all change. Wrong memory access pattern. AI workloads are typically memory-bandwidth-bound rather than compute-bound, particularly for inference. Geekbench’s memory tests use standard access patterns that don’t reflect the large contiguous tensor reads, KV-cache traversals, and weight-streaming behaviour that dominate transformer inference. A GPU with strong Geekbench memory numbers can still bottleneck on HBM bandwidth at realistic model sizes. No sustained load. Geekbench runs burst workloads measured in seconds. AI training and high-throughput inference run for hours at sustained load. Thermal throttling, power-budget shaping, and clock-frequency drift that appear after ten minutes or more of continuous load are simply not visible in a five-minute benchmark. A GPU that scores well on a thirty-second inference test may throttle significantly during a four-hour training run. No framework overhead. Real AI workload performance includes CUDA driver overhead, PyTorch or TensorFlow dispatch, kernel launch costs, NCCL collective operations in multi-GPU settings, and the latency of bouncing tensors between Python and the runtime. Geekbench’s native code paths don’t see any of this, and on workloads where these costs add up — short sequences, small batch sizes, inference-style serving — the gap between benchmark and reality widens further. Can Geekbench predict AI training performance? Geekbench’s ML Benchmark subtest measures inference performance on a small set of models (MobileNet, ResNet) at fixed batch sizes. It does not measure training performance, and extrapolating from its inference results to training performance is unreliable. Training performance depends on factors that Geekbench does not test: gradient computation throughput, memory capacity for activations and optimizer state, inter-GPU communication bandwidth (for distributed training using NCCL collectives), and sustained throughput under thermal load over hours rather than seconds. These factors interact — a GPU with enough HBM for the model but insufficient bandwidth for the optimizer state will appear fast for a few iterations and then stall. The ML Benchmark’s model selection also limits its predictive value. MobileNet and ResNet are convolutional architectures designed for efficiency on edge devices. Modern AI training increasingly involves transformer architectures where attention mechanism performance — determined by memory bandwidth, FlashAttention-style fused kernels, and Tensor Core utilisation — dominates. A GPU’s MobileNet inference score has low correlation with its GPT-style training throughput, which is an observed pattern across the comparisons we have run, not a benchmarked transfer function. We do use Geekbench in one specific scenario: comparing Apple Silicon machines for local development suitability. Since Geekbench runs on macOS and tests both CPU and GPU compute, it provides a rough comparison across Apple Silicon generations (M1 vs M2 vs M3). For this narrow use case, the relative scores are informative even if the absolute numbers do not predict production training performance on Linux GPU infrastructure. What should you run instead? The structural reasons Geekbench can’t predict AI performance are the same reasons no general-purpose benchmark can — a point we develop in more detail in why spec-sheet benchmarking fails for AI. The practical alternatives are workload-specific: For LLM inference: Run the actual model at the target context length and batch size using the serving framework you will use in production (vLLM, TensorRT-LLM, or Triton Inference Server). Measure tokens per second under realistic concurrency, not single-request latency. For training throughput: MLCommons MLPerf Training benchmarks at the relevant model size, with the caveat that MLPerf reference models may not match your architecture. For dissimilar workloads, only running the actual training script provides reliable data. For vision inference: MLPerf Inference results for ResNet-50 and RetinaNet provide reasonable predictions for similar architectures, but not for custom backbones or detection heads. For hardware selection: Benchmark under your specific workload, not any standardized proxy. The cost of a few hours of benchmarking is negligible compared to the cost of misallocating a GPU fleet. We maintain a library of benchmark scripts for common workload types: LLM inference (vLLM throughput at multiple batch sizes), vision inference (TorchServe latency), and training throughput (single-GPU and multi-GPU step timing). These scripts run in fifteen to thirty minutes each and cover three deployment scenarios that stress different hardware characteristics — single-request latency (interactive use), batch throughput (offline processing), and concurrent-request testing (production serving with multiple simultaneous users). A system that performs well on one may underperform on another, which is why running all three matters more than any single composite score. LynxBench AI treats general-purpose CPU/GPU scores like Geekbench as orthogonal to AI-workload performance, not as proxies for it. The Geekbench micro-kernels are not the workload an AI deployment runs, and the methodology cannot defend a translation that wasn’t built into the benchmark in the first place. For any Geekbench-based AI hardware claim you intend to act on: was a workload-bound AI benchmark run alongside the score under the same precision regime and operating point, or was a general-purpose score promoted into an AI prediction the methodology cannot defend?
