Someone posts a hashcat hash-rate table, reads the top row, and concludes that GPU will be the fastest for their model. It is the wrong inference. Hashcat tells you a lot about the silicon and the driver stack, and almost nothing about where time goes in your inference path. That gap matters because “hashcat gpu benchmarks” is a query people reach for precisely when they are trying to size hardware for something that has nothing to do with password cracking. A hash rate is a clean, single number — it is tempting to treat it as a proxy for GPU compute in general. But a benchmark is only a signal about what it stresses, and hashcat stresses a very specific thing: integer and hash-function throughput bound by how fast the device can push data through its execution units and memory subsystem, under a kernel profile the tool controls end to end. Read for what it measures, a hashcat run is a genuinely useful sanity check on raw hardware capability and driver health. Read as a stand-in for your workload, it becomes a misleading proxy — because the thing that actually governs your deployment latency is almost never the thing hashcat is exercising. What do hashcat benchmarks actually measure? Hashcat is a password-recovery tool. Its benchmark mode runs each supported hash algorithm — MD5, SHA-256, bcrypt, NTLM, WPA, and dozens more — as a tight GPU kernel and reports how many candidate hashes per second the device sustains. The -b mode cycles through the algorithms and prints a rate per mode, typically in H/s, kH/s, MH/s, or GH/s depending on how cheap the hash is to compute. Underneath, hashcat compiles OpenCL (and increasingly CUDA/HIP) kernels tuned for the device, launches enough work-items to saturate every compute unit, and keeps the pipeline full. What it is measuring, in practical terms, is three things braided together: Raw integer and bitwise throughput — hash functions are dominated by integer ops, rotates, XORs, and modular arithmetic, not floating-point matrix math. Memory bandwidth and cache behaviour — for memory-hard algorithms like bcrypt or scrypt, the rate is gated by how fast the device can move state through its memory hierarchy, not by ALU count. Driver and runtime health — whether the OpenCL/CUDA stack is installed correctly, the device is clocked properly, thermals hold, and the kernel actually compiled for that architecture. That last point is the underrated one. A hashcat benchmark that comes back at a fraction of the expected rate for a known SKU is often the first visible symptom of a broken or mismatched driver stack — a missing ICD, a stale CUDA runtime, a card thermal-throttling. In that role it earns its keep. If you are still standing up the toolchain, our walkthrough on getting the OpenCL runtime and SDK in place for a portable compute path covers the same stack hashcat leans on. What a hashcat number does not contain: floating-point throughput at the precisions your model uses (FP16, BF16, FP8, INT8), tensor-core utilisation, attention-kernel behaviour, interpreter overhead in a Python serving loop, or the cost of marshalling data on and off the device. None of those are exercised by a hash kernel. How do hashcat numbers compare across common SKUs? Comparative hash rates are informative as a raw-capability ranking — they track roughly with a device’s integer throughput and memory bandwidth, which is why a data-centre card generally outruns a consumer card, and a newer generation outruns an older one. The table below is illustrative of how to read such a comparison, not a set of quoted figures for any specific driver version. How to read a cross-SKU hashcat table Column What it tells you What it does not tell you Fast-hash rate (e.g. MD5, NTLM) Peak integer/bitwise throughput; ALU-bound headroom FP16/BF16 tensor throughput for your model Memory-hard rate (bcrypt, scrypt) Effective memory-bandwidth and cache pressure Whether your model is memory- or compute-bound Rate vs published SKU baseline Driver/stack health — is the card performing to spec? Whether the runtime is tuned for your inference kernel Relative ranking across SKUs Raw-capability ordering (usually holds direction) The magnitude of speedup on your actual workload The direction of the ranking usually survives the jump to a real workload — a card that is meaningfully faster at hashcat is rarely slower at inference. What does not survive is the magnitude. A card that is 3× faster on MD5 might be 1.4× faster on your transformer decode step, because your step is gated by memory bandwidth at long context length, or by kernel-launch overhead at small batch, not by integer ALU count. This is the same trap we describe in reading Blender benchmarks as a GPU baseline: a synthetic score establishes an ordering, not a transfer function to your path. Why don’t hashcat benchmarks predict inference performance? Because a benchmark predicts a workload only to the extent the two share a bottleneck. Hashcat is bottlenecked on integer throughput and, for some algorithms, memory bandwidth, under a kernel the tool hand-tunes. A typical inference path is bottlenecked somewhere entirely different, and where depends on the model shape: Attention-heavy LLM decode is often memory-bandwidth-bound at long context — closer to hashcat’s memory-hard modes than its fast-hash modes, but still not the same access pattern. Small-batch, latency-sensitive serving is frequently dominated by kernel-launch overhead and Python interpreter cost in the serving loop, which no hash kernel touches. Vision and convolutional models lean on tensor cores and FP16/INT8 throughput — a dimension hashcat never exercises. IO-bound pipelines spend their time marshalling data across PCIe or waiting on a data feed, so the GPU’s peak anything is irrelevant. There is a broader version of this argument that applies to any single-number GPU metric — we lay it out in what gigaflops mean for inference latency, where peak FLOPS and observed latency routinely diverge for exactly these reasons. The point that carries across both: a synthetic throughput figure is a property of the silicon and the kernel that produced it, not a property of your workload. Treating the two as interchangeable is how teams over-index on the wrong card and then discover the speedup they paid for never materialised. In our experience across porting and runtime-fit work, the bottleneck teams assume from a benchmark and the bottleneck a profiler finds on the real path disagree more often than they agree — an observed pattern, not a benchmarked rate, but a consistent one. That disagreement is the entire reason profiling before porting exists as a discipline. When is a hashcat run actually the right tool? It has three legitimate jobs, and staying inside them is what keeps the signal honest: Driver/stack health check. Run hashcat -b on a freshly provisioned node; compare the fast-hash rate against the known baseline for that SKU. A large shortfall means the OpenCL/CUDA stack, clocks, or thermals are wrong — fix that before you profile anything else. Raw-capability sanity signal. When you are comparing candidate GPUs at the coarsest level — “is this card in the right class at all?” — hashcat gives a fast, reproducible integer/bandwidth ordering that is hard to fake. Reproducibility baseline. Because hashcat controls its own kernels, its numbers are stable across runs, which makes it a decent canary for detecting when a driver update or thermal regression has quietly degraded a machine. Outside those jobs, it should feed a decision, never make one. A grounded hashcat read belongs alongside the profiled runtime-fit verdict in a port decision — as one input to the [inference cost-cut pack](Inference Cost-Cut Pack), which attributes where time is actually spent before any engineering effort is committed. The TechnoLynx GPU practice treats a synthetic benchmark as a hardware-fit signal, not a workload verdict; the two are combined, never confused. What should you profile on your own path instead? The honest answer to “will this GPU be fast for me” comes from profiling your own inference path, not from a hash rate. What to capture: Where time goes — a per-stage breakdown across preprocessing, host-to-device transfer, model compute, and postprocessing. This is the single most decision-relevant artefact, and it is what our guide on profiling the Python inference path before a C++ or WASM port walks through end to end. Achieved vs peak throughput at your model’s precision — FP16/BF16/FP8/INT8, not integer hash ops. Kernel-launch and interpreter overhead at your real batch size and concurrency. Memory-bandwidth pressure at your real context length or resolution, where LLM decode and large-image vision paths tend to bind. IO and data-feed timing — whether the GPU is starved waiting on a data source. The porting and performance-assessment methodology that produces this baseline is where a synthetic hashcat figure gets replaced by workload-specific attribution; it is the same profiling discipline that underpins our R&D consulting on performance assessment work, which starts from measured path behaviour rather than a leaderboard number. FAQ What should you know about hashcat gpu benchmarks in practice? Hashcat’s benchmark mode (hashcat -b) runs each supported hash algorithm as a tuned GPU kernel and reports sustained candidate hashes per second per algorithm. In practice it means you get a clean, reproducible number that reflects the device’s integer/bitwise throughput and, for memory-hard hashes, its memory bandwidth — a signal about the silicon and driver stack, not about your model. What exactly do hashcat benchmarks measure — raw hash throughput, memory bandwidth, or something else? Three things braided together: raw integer and bitwise throughput (hash functions are integer-dominated, not floating-point), memory bandwidth and cache behaviour for memory-hard algorithms like bcrypt, and driver/runtime health — whether the stack compiled and the card is clocked and cooled correctly. It does not measure FP16/BF16 tensor throughput, attention kernels, interpreter overhead, or IO marshalling. How do hashcat GPU numbers compare across common SKUs, and how should I read the table? Compare the fast-hash rate for ALU-bound headroom, the memory-hard rate for effective bandwidth, and the rate against a published SKU baseline as a driver-health check. The relative ranking across SKUs usually holds direction — a faster card is rarely slower at inference — but the magnitude of the gap does not transfer to your workload, because your bottleneck is likely different. Why don’t hashcat benchmarks predict my inference or compute workload performance? Because a benchmark predicts a workload only where the two share a bottleneck, and they usually don’t. Hashcat is integer/bandwidth-bound under a hand-tuned kernel; your path may be gated by kernel-launch and interpreter overhead at small batch, tensor-core FP16/INT8 throughput, memory bandwidth at long context, or IO — none of which a hash kernel exercises. When is a hashcat run a useful driver/stack-health or GPU-capability sanity check? When you run it on a freshly provisioned node and compare the fast-hash rate against the known baseline for that SKU: a large shortfall exposes a broken OpenCL/CUDA stack, wrong clocks, or thermal throttling. It is also a solid reproducibility canary for detecting when a driver update or thermal regression has quietly degraded a machine. What should I profile on my own path instead of relying on a synthetic benchmark? Capture where time goes across preprocessing, host-to-device transfer, model compute, and postprocessing; achieved-versus-peak throughput at your model’s actual precision; kernel-launch and interpreter overhead at your real batch size; memory-bandwidth pressure at your real context length; and IO/data-feed timing. That per-stage attribution — not a hash rate — is what tells you whether a given GPU will be fast for your workload. If you take one thing from a hashcat table into a port decision, let it be the ranking and the driver-health check — and let the profiler answer the only question that governs your latency: where, on your own path, the time actually goes.
