You just built a zero-knowledge circuit. It works on your laptop. You push it to production, and suddenly your proof generation takes ten minutes instead of ten seconds. Or worse, your server melts. This isn't a code problem; it's a hardware mismatch. ZK proving hardware is the bottleneck that kills most Layer 2 scaling projects before they even hit mainnet.
Choosing the right infrastructure isn't about picking the fastest chip in a vacuum. It's about matching silicon to your specific proving system, workload size, and budget. As of late 2026, the landscape has split into three clear camps: general-purpose GPUs, specialized ASICs, and managed cloud networks. Each has trade-offs that can make or break your unit economics.
Why GPUs Still Rule the Roost
If you are starting today, you are almost certainly using a GPU. Specifically, an NVIDIA card running CUDA. Why? Because the ecosystem is mature, the drivers work (mostly), and every major zkVM like SP1, RISC Zero, or Halo2 has optimized CUDA kernels ready to go.
NVIDIA H100 and A100 datacenter GPUs remain the gold standard for serious production proving. They offer massive memory bandwidth, which matters more than raw core count for many ZK operations like Number-Theoretic Transforms (NTTs). But here’s the catch: adding more GPUs doesn’t always mean faster proofs. If your CPU can’t feed the GPUs fast enough, or if your PCIe topology creates bottlenecks, you’re just burning cash on idle silicon.
For developers, consumer-grade cards like the RTX 4090 or the newer RTX 5090 offer incredible performance per dollar. Succinct, the team behind SP1, reports that these consumer cards can achieve roughly 2 million prover-gas units per second per node. That’s fast. But they lack the error-correcting memory and reliability features of datacenter chips. For a testnet, a 4090 is perfect. For a bridge handling millions in assets, you want the stability of an A100 or H100.
The software stack matters as much as the metal. Libraries like Ingonyama’s ICICLE provide open-source CUDA acceleration for various proving systems. However, benchmarks vary wildly. A study from early 2026 showed that while CUDA had a 3.5x advantage over Triton for 32-bit arithmetic, that gap narrowed to just 1.37x for 256-bit fields. If your protocol uses large field elements, your "optimized" GPU setup might not be as optimized as you think.
The ASIC Promise: Efficiency vs. Flexibility
Application-Specific Integrated Circuits (ASICs) are the holy grail of hardware acceleration. By hardwiring the math-modular arithmetic, NTTs, Multi-Scalar Multiplication (MSM)-ASICs theoretically deliver 10-100x better efficiency than GPUs. Companies like Cysic have announced products like the C1 and ZKPro, claiming significant power savings and speedups.
But there’s a dark side to ASICs: rigidity. The blockchain world moves fast. Your protocol might switch from Plonk to STARKs, or change its recursion scheme. An ASIC designed for one specific polynomial commitment scheme becomes a very expensive brick when the standard shifts. Unlike a GPU, you can’t just flash new firmware to support a new algorithm. You need new silicon.
Academic research supports the potential. Papers like "SZKP" claim speedups of over 400x compared to CPUs. But these are modeled results, often ignoring the end-to-end overhead of witness generation and verification. In the real world, unless you have a stable, high-volume proving system that won’t change for years, an ASIC is a risky bet. The non-recurring engineering costs are huge, and supply chain delays are common.
| Feature | GPU (NVIDIA) | ASIC (e.g., Cysic) | Cloud/Managed |
|---|---|---|---|
| Flexibility | High (Software updates) | Low (Fixed logic) | High (Abstracted) |
| Cost Model | CapEx + Electricity | High CapEx | OpEx (Per proof/hour) |
| Maturity | Very High | Emerging | High |
| Best For | Dev, Mid-scale Prod | Stable, High-Volume | Bursty, Early Stage |
Cloud and Managed Provers: Buying Time
Not everyone wants to manage a rack of servers. Cloud providers like AWS, Google Cloud, and RunPod offer access to H100 clusters without the procurement headache. AWS P5 instances with H100s cost around $6.88 per GPU-hour. RunPod offers similar capacity for less, sometimes under $2 per hour, but with different isolation guarantees.
Then there are managed prover networks like Succinct’s Prover Network. These services abstract away the infrastructure entirely. You submit a proof request, and their cluster handles the rest. This is ideal for bursty workloads where your demand spikes unpredictably. Paying for idle GPUs at 3 AM is a waste; paying per proof ensures you only cover what you use.
However, cloud pricing includes a premium for convenience and elasticity. If you have steady, predictable load, owning hardware usually beats renting after 12-18 months. Also, consider data privacy. Sending sensitive execution traces to a third-party cloud requires trust in their security model.
FPGAs: The Middle Ground?
Field-Programmable Gate Arrays (FPGAs) sit between GPUs and ASICs. They offer custom pipelines with lower latency than GPUs but retain some programmability. However, the developer experience is painful. Writing HDL (Hardware Description Language) is far harder than writing CUDA kernels. Unless you have a dedicated hardware team, FPGAs are rarely worth the effort for general ZK proving today.
How to Choose: A Decision Framework
Stop looking at theoretical peak throughput. Look at your actual job-to-be-done.
- Are you developing or testing? Use a local RTX 4090 or 5090. It’s cheap, fast enough for iteration, and easy to debug.
- Do you have steady, high-volume traffic? Evaluate owned A100/H100 clusters or ASICs if your protocol is locked down. Calculate cost-per-proof including electricity and maintenance.
- Is your traffic spiky or unpredictable? Use cloud GPUs or managed prover networks. Avoid fixed capital expenditure until you know your baseline utilization.
- Is your protocol evolving rapidly? Stick to GPUs. The flexibility to update algorithms via software is worth the higher energy cost.
Remember, the bottleneck is rarely just compute. Witness generation-the process of creating the data that proves your computation-is often CPU-bound. Ensure your CPU specs match your GPU power. SP1 recommends at least 32 GB DDR5 RAM per GPU to avoid memory starvation.
The Bottom Line
There is no single "best" hardware for ZK proving. There is only the best hardware for your specific constraints. For most teams in 2026, GPUs remain the pragmatic choice due to their balance of performance, flexibility, and ecosystem support. ASICs are promising but premature for most use cases. Cloud options provide essential elasticity but punish sustained heavy loads with high OpEx.
Before buying any hardware, benchmark your exact circuits. Don’t trust vendor whitepapers. Measure end-to-end latency, including witness generation and verification. Only then will you know if you need a hammer, a scalpel, or a rented workshop.
Can I use AMD GPUs for ZK proving?
While technically possible, the ecosystem is heavily biased toward NVIDIA. Most major libraries like ICICLE and SP1 optimize for CUDA. Using AMD ROCm often requires extra porting effort and may result in slower performance due to less mature tooling. For production, stick with NVIDIA unless you have specific reasons otherwise.
How much VRAM do I need for ZK proving?
It depends on the circuit size, but 24 GB is the practical minimum for modern zkVMs like SP1. Larger circuits may require 40 GB or more. However, memory bandwidth is often a bigger constraint than capacity. Ensure your GPU has high bandwidth (e.g., HBM3 on H100s) rather than just focusing on total gigabytes.
Are ASICs worth it for small startups?
Generally, no. ASICs require long-term stability in your proving system to amortize the high upfront cost and development risk. Startups should prioritize flexibility. Use cloud GPUs or consumer hardware until your protocol and volume stabilize, likely after reaching significant mainnet usage.
What is the biggest hidden cost in GPU proving?
CPU orchestration and data movement. If your CPU cannot generate witnesses fast enough, your expensive GPUs sit idle. Additionally, PCIe bandwidth limits how quickly data moves between CPU and GPU. Upgrading your CPU and ensuring direct PCIe x16 connections per GPU is critical to maximizing ROI.
How does proof recursion affect hardware needs?
Recursion increases computational depth but reduces final proof size. It often benefits from parallelizable steps, making it well-suited for GPUs. However, deep recursion chains can increase memory pressure. Monitor VRAM usage closely when implementing recursive proving schemes, as out-of-memory errors are common during the aggregation phase.