zkVM Trilogy (Part II): Accelerating zkVM: GPU, FPGA and ASIC — A Revisit

Mar 3, 2026

Who this post is for: Hardware engineers, infrastructure operators, and technical decision-makers evaluating the GPU / FPGA / ASIC trade-off for ZKP proving workloads. This post presents quantitative benchmark results from our Venus project and revisits conclusions from our earlier blog on ZK hardware acceleration. For the architectural philosophy behind the graph-first approach, see zkVM Trilogy (Part I).

A note on measurement methodology: Throughout this post, GPU numbers are measured wall-clock times from real proving runs, while FPGA numbers are estimated runtimes derived from HLS synthesis latency cycles divided by achieved frequency. We clearly label each data point accordingly. Direct comparison should be interpreted with this caveat in mind.

Introduction

A few years ago, we published our perspective on ZK Hardware Acceleration: The Past, the Present and the Future, where we argued that:

• FPGA has the same performance-per-watt level as GPU, but cannot compete with GPU on the performance-per-dollar metric.
• ASIC outperforms FPGA and GPU on both metrics, but takes longer to get to market.

Since then, the landscape has evolved significantly. We have built Venus, a compute-backend extension and specialization on top of ZisK, moving from a backend-abstracted proving runtime (HAL mode) toward a graph-first execution model. In this post, we revisit our original conclusions through the lens of Venus, grounding them in concrete, quantitative results. We examine GPU-level optimizations, FPGA prototyping outcomes, and what they collectively imply for the strategic path toward ASIC-class zk acceleration.

GPU Results: Venus Optimizations Improved ProofMan Performance

The GPU optimization campaign (four rounds) achieved the stated target: more than 9% improvement against Zisk v0.15 across all tested workloads.

The best production configuration is obtained with configuration: OPT_LEVEL=1 observed on RTX 5090, with all proofs passed verification in the reported campaign:

Comparison Results on RTX 5090

The largest contributors were not only micro-tuning, but correctness and execution-path quality:

• Critical bug fixes in hashing and grid sizing (including out-of-bounds behavior and kernel sizing).
• Cleanup/removal of unstable or non-beneficial kernel paths.
• Compiler-level improvements (-O3, --use_fast_math).
• Occupancy and launch tuning for hot kernels (for example, Poseidon2 TPB and launch-bounds adjustments).

An important result is that high optimization levels were not consistently better. OPT_LEVEL=1 provided the best balance of speedup consistency and operational risk.

These GPU results already demonstrate early benefits of the graph-first approach. By integrating cudaGraph into critical execution paths, we replaced the original kernel call patterns with captured and replayed graph instances. This reduced CPU-side launch overhead and host-device synchronization jitter, particularly in iterative proving phases like sumcheck rounds. Future graph-level optimizations -- including cross-kernel data placement and multi-GPU scheduling -- will build on this foundation.

FPGA Results: Architectural Validation, Not Yet Performance-Winning

In our original blog, we noted that:

a single FPGA chip cannot compete with a single GPU

on performance-per-dollar, and that FPGA is roughly at the same level as GPU on performance-per-watt. Our new Venus FPGA results quantitatively confirm and refine this assessment.

FPGA data comes from HLS synthesis and runtime estimation of proof_test_kernel, with strict separation between measured GPU prove wall-clock and estimated FPGA runtime from synthesized latency cycles and Fmax.

Target-device choice is intentional:

• VU47P is included because AWS F2 instances are based on this chip class.
• VH1782 is included because it maps to the latest AMD V80 accelerator-card target discussed in this hardware track.

Based on these two devices, we obtain the following results:

FPGA vs. GPU Performance

More details on FPGA implementation can be found in the following table:

FPGA Implementation Details

Reported estimated runtime is derived from: estimated_time = latency_cycles / frequency. This low-frequency range (74 to 98 MHz) is the dominant limiter in the current prototype.

GPU vs FPGA: Current Reality

GPU times below are measured wall-clock; FPGA times are estimated from HLS synthesis (latency_cycles / Fmax). The comparison is directionally informative but not an apples-to-apples benchmark.

With GPU board power limit at 350W (reported RTX 3090 setting), energy per proof at 47.84 s is 4.651Wh. FPGA break-even power for equal energy/proof under current timing estimates:

• VU47P: about 49.88W;
• VH1782: about 41.38W.

At realistic 70W to 120W assumptions from the report, FPGA energy/proof is not clearly superior today. Therefore, neither pure performance nor performance-per-watt currently justifies replacing optimized GPU proving with this FPGA implementation.

Our original blog concluded that:

FPGA has the same performance-per-watt level as GPU, but cannot compete with GPU on the performance-per-dollar metric.

The Venus results largely confirm this, with an important nuance: the performance gap on a per-chip basis is larger than we initially estimated (7–8x rather than 2.5x), primarily because FPGA frequency ceilings for proving workloads are lower than anticipated. However, the strategic value of FPGA work has also become clearer, as explains in the following.

Saying “FPGA is slower today” does not mean “FPGA work is low value.” The current FPGA effort delivers critical architectural value:

• Validates that proving stages can be expressed as explicit computation-flow components.
• Forces precise interface contracts, memory layouts, and dependency boundaries.
• Provides concrete resource/frequency/bandwidth ceilings for hardware planning.
• De-risks the transition from software scheduler semantics to hardware pipeline semantics.

In short, FPGA is acting as a graph-to-hardware prototyping bridge.

ASIC and zk-Specialized Hardware Narrative

In our original blog, we wrote:

ASIC is unanimously believed to be the ideal hardware for ZKP

and identified three concerns: programmability, high cost, and time to market. We proposed an ISA-based architecture to address programmability.

The graph-first architecture provides an even stronger answer to the programmability concern. A graph-encoded prover makes ASIC planning much cleaner:

• Module decomposition is explicit (for example hash/NTT/Merkle/transcript/data-move blocks).
• Inter-module communication can be designed as first-class on-chip flow.
• Scheduler semantics can be hardened into deterministic control planes.
• Host round-trips can be reduced by moving more proving flow logic near compute.

Current FPGA frequency limits indicate where ASIC can create step-function improvements: higher clock targets, tighter memory fabrics, and fixed-function data paths for dominant kernels.

The graph abstraction serves as the unifying layer across the hardware evolution path:

• GPU (today): graph nodes map to kernels and async copies, captured and replayed through cudaGraph.
• FPGA (prototyping): graph nodes map to HLS modules and stream channels; dependencies map to dataflow edges and buffer interfaces.
• ASIC (future): graph partitions map to dedicated compute blocks and on-chip routing, with tighter control over latency, bandwidth, and protocol timing.

This is the key architectural insight: the same graph semantics naturally maps to different backends, and it is the execution contract that can survive hardware evolution.

Practical Conclusion

For Venus zkVM today:

• GPU remains the production performance path. Continue deploying GPU infrastructure with Venus-optimized configuration (OPT_LEVEL=1) to secure stable and compounding performance gains.
• Graph-first runtime evolution is strategic infrastructure. This architecture is not an abstraction exercise — it is the foundational layer that enables CUDA graph-level optimization today and hardware-native compilation tomorrow.
• FPGA results represent architectural validation, not the endpoint. They confirm the correctness of our hardware-compilation direction, even if they are not yet the ultimate performance target.
• Use FPGA learnings as quantitative guidance. The data provides concrete constraints and optimization signals for future ASIC or zk-dedicated accelerator design.

Our original thesis from several years ago still holds — but the execution path is now far more defined:

GPU dominates production today.

FPGA validates the hardware-compilation pathway.

Graph-first architecture is the bridge that makes an eventual ASIC transition both practical and principled.

This is no longer a hypothesis. It is an engineered roadmap.