Geekbench’s ML benchmark is better than its CPU score — but not sufficient Geekbench 6 added an ML benchmark subtest that runs inference operations on CPU and GPU. This is more relevant to AI than the general compute subtests because it exercises the instruction types — matrix multiply-accumulate, activation functions — that AI frameworks actually use. It is, in that narrow sense, a real improvement over reading a CPU score and squinting at it sideways. But it remains insufficient for production AI hardware decisions, and the reasons it falls short are structural rather than incidental. The structural gap between any standardised score and a production AI workload is the same gap why benchmarks fail to match real AI workloads covers in general form. Geekbench ML is a useful case study because it sits close enough to AI to look adequate, and that closeness is what makes its limits worth naming explicitly. What the Geekbench ML benchmark actually tests Geekbench ML runs a fixed set of small inference tasks across CPU, GPU (via Metal, OpenCL, or DirectML), and dedicated neural processors such as Apple’s Neural Engine or Qualcomm’s NPU. The tasks themselves are bounded — they run quickly, they fit comfortably in memory on any modern device, and they exercise a known mix of operations. Task Operation type Hardware exercised Edge-size object detection INT8 inference NPU, GPU INT8 units Background removal Segmentation GPU Style transfer CNN inference GPU Portrait segmentation Small CNN CPU/GPU These are reasonable proxies for device-class AI capability — the kind a phone or laptop runs locally. They are not proxies for serving infrastructure. The instruction mix overlaps with production AI; the workload shape does not. Why is the Geekbench ML score insufficient for production AI hardware decisions? Four mismatches matter, and they compound. None of them are bugs in Geekbench — they are properties of what a portable, comparable benchmark can reasonably measure. Model size mismatch. Geekbench ML models are edge-inference networks, on the order of a few hundred MB at most. Production AI workloads — 7B–70B parameter LLMs, high-resolution diffusion models, large vision transformers — have fundamentally different compute and memory profiles. A device that handles edge inference well tells you almost nothing about how the same silicon behaves when its memory subsystem is saturated by a large model’s weights and KV cache. Fixed single-stream inference. Geekbench runs one inference at a time. Production serving at scale lives or dies on throughput under concurrent load — typically in the range of 10–100 concurrent requests per accelerator, depending on model size and target latency. Concurrency changes everything: queue depth, batching behaviour, memory pressure, scheduler contention. A single-stream number cannot extrapolate to a multi-stream regime, because the bottleneck shifts. No framework stack. Geekbench runs models close to the metal. Production workloads run through PyTorch or TensorFlow, served by vLLM, TGI, or Triton, with kernel selection, graph optimisation, and dispatch overhead that the benchmark deliberately avoids. The overhead is not noise — for many real models it dominates. Short duration, no thermal steady state. A Geekbench run takes minutes. Sustained throughput under load — the operationally relevant measure for any inference cluster — is governed by thermal and power-limit behaviour that only emerges over longer windows. In our experience working on GPU-accelerated inference deployments, the ratio between burst and sustained throughput typically lands somewhere between 0.75 and 0.95 depending on cooling adequacy (observed pattern across deployments, not a benchmarked rate). Hardware that sustains below 0.8 has a thermal design problem that will reduce effective capacity in production, and a short-duration benchmark is structurally blind to it. When the Geekbench ML score is still worth reading The score is not useless. It has a real, narrow set of jobs it does well: Comparing consumer devices — laptops, workstations, phones — for basic on-device AI inference capability. A fast first-pass filter to eliminate obviously underpowered hardware before deeper evaluation. Tracking generational change within a vendor’s line, particularly Apple Silicon, where Neural Engine efficiency improvements show up clearly. What it cannot do: Compare discrete GPUs for LLM serving. Justify hardware procurement for training infrastructure. Predict production throughput under concurrent load. Knowing which side of that line you are on is most of the work. What does a workload-anchored AI benchmark actually look like? Four properties matter, and Geekbench measures none of them: sustained throughput rather than burst, production-representative batch sizes, production-representative model architectures, and memory bandwidth behaviour under load. MLPerf comes closest — it is at least standardised and audited — but its fixed model configurations and submission-optimised results make it better for comparing vendor claims than for predicting your workload’s performance. A practical AI benchmark for hardware evaluation runs your actual model, at your actual batch size, through your actual data pipeline, for at least 30 minutes. That is enough to capture thermal steady state, observe whether the memory subsystem is saturating, and see whether the framework overhead lines up with what you expect. For the engagements where we run this evaluation ourselves, we use a three-test sequence: Test Duration What it measures Burst inference ~2 min Peak throughput (the regime Geekbench measures) Sustained inference ~30 min Thermal throttling and power-limit impacts Memory bandwidth saturation ~5 min The memory-wall ceiling under load The sustain ratio — sustained divided by burst — is the single most informative number that falls out of this sequence, and it is exactly the number Geekbench cannot produce. From Geekbench scores to hardware decisions The most defensible way to use Geekbench in an AI evaluation context is as an anomaly detector. If a system with known-good hardware scores 30% below the expected range for its specification, something is misconfigured — not a workload problem, a system-health problem. Common causes we have diagnosed through Geekbench anomalies include BIOS power management capping CPU boost frequency, RAM running below its rated speed because XMP profiles were never enabled, and thermal throttling from improperly mounted CPU coolers. These are real, recurring failure modes, and a five-minute Geekbench run catches them. For the actual AI hardware decision, we supplement Geekbench with targeted micro-benchmarks: bandwidthTest from the CUDA samples for GPU memory throughput, p2pBandwidthLatencyTest for multi-GPU communication, and a batch inference timing script that measures inferences per second at the target batch size. Combined with a Geekbench score for general system health, this gives a complete picture in roughly 45 minutes — and the framing matters more than the timing. The Geekbench score is a sanity check; the targeted measurements are the answer. LynxBench AI treats spec-metric benchmarks like Geekbench as describing one operating point of one synthetic workload, not the AI workload behaviour of the silicon under test. Programmable-workload performance varies with software stack, precision, and batch shape in ways a single score cannot represent. The question to put to any Geekbench-derived AI hardware ranking is whether it was validated against a workload-anchored measurement — or whether it is being asked to do a job it was never designed for. Before that score becomes the ranking that informs a purchase, did a workload-anchored measurement at the same precision regime and operating point sit alongside it as the right metric for this workload, or is the synthetic score being asked to stand in for a deployment-relevant signal it cannot produce?
