← Results

Inference scaling

Scaling distributed plug-and-play inference

Understanding when distributed PnP reconstruction scales efficiently, and what eventually limits it.


Distributing an inverse-problem solver across many GPUs makes it possible to reconstruct images that would not fit on a single device. But using more GPUs does not automatically make the reconstruction proportionally faster. The computation must be divided between workers, overlapping image regions may be processed several times, and intermediate results must be exchanged and synchronized.

This study investigates how our distributed plug-and-play inference pipeline behaves as both the problem size and the number of GPUs increase.

Rather than only asking whether the implementation can run on many GPUs, we want to answer three practical questions:

  1. Can distributed inference preserve reconstruction quality while enabling larger reconstructions and reducing computation time?
  2. How efficiently does the reconstruction accelerate when more GPUs are added?
  3. When scaling eventually slows down, is the limitation caused by the computation itself or by communication and synchronization?

We first verify that distributed execution preserves the reconstruction trajectory. We then study how iteration time decreases as additional GPUs are added, before analyzing parallel efficiency and finally separating computation from communication to understand what limits scaling.

Experimental setting

Each plug-and-play iteration alternates between two main operations:

Both operations expose parallelism, but in different ways. The acquisition operators are distributed across workers, while the image passed to the denoiser is split into overlapping tiles. The overlap provides the spatial context needed by the neural network near tile boundaries, but it also introduces additional computation and data movement.

The strong-scaling experiment uses noisy multi-frame super-resolution problems with eight acquisition operators. We reconstruct RGB images with side lengths of 2048, 4096, and 8192 pixels on Tesla V100-SXM2 GPUs with 32 GB of memory, using four GPUs per node.

Distributed denoising uses an inner tile size of 448 × 448 pixels, surrounded by a 32-pixel halo on each side. Up to 32 tiles are processed in one batch. The full experiment configuration is available in benchmark_inference/configs/experiments/strong_scaling_inference.yml.

Timing values are averaged over iterations 3 to 10, after excluding the first two iterations to avoid initialization and warm-up effects. The quality comparison includes initialization (iteration 0) and every PnP iteration from 1 to 10. The 2048² and 4096² experiments include a non-distributed single-GPU reference. The 8192² image does not fit in the corresponding single-GPU configuration, so its scaling study starts from two GPUs.

Can distributed inference preserve quality and provide useful speedups?

Before evaluating performance, we first verify that distributing the reconstruction does not alter the optimization itself. Plug-and-play reconstruction alternates physics updates and learned denoising operations, so numerical differences introduced by distributed execution could, in principle, accumulate over successive iterations and lead to a different reconstruction.

To assess this, we compare the PSNR obtained at every iteration with the corresponding single-GPU reference reconstruction.

Figure

Distributed execution follows the reference reconstruction trajectory

Signed PSNR difference at every PnP iteration relative to the corresponding single-GPU reconstruction.

Loading interactive figure…

ΔPSNR is computed against the single-GPU reference at the same iteration. Only 2048² and 4096² are shown because 8192² has no feasible single-GPU reference.

View figure data
Image sideIterationGPUsReference GPUsPSNR (dB)Reference PSNR (dB)ΔPSNR (dB)
2,0480215.5731575.5731570
2,0481217.5044837.5044770.000006
2,0482219.4322959.4322760.000019
2,04832111.35582711.3557890.000038
2,04842113.27245513.2723790.000076
2,04852115.17803415.1778940.00014
2,04862117.06585917.0656150.000244
2,04872118.92520318.9247880.000416
2,04882120.73932620.7386210.000706
2,04892122.4831722.4819870.001183
2,048102124.12158824.1196590.001928
2,0480415.5731575.5731570
2,0481417.5044837.5044770.000006
2,0482419.4322959.4322760.000019
2,04834111.35582711.3557890.000038
2,04844113.27245513.2723790.000076
2,04854115.17803415.1778940.00014
2,04864117.06585917.0656150.000244
2,04874118.92520318.9247880.000416
2,04884120.73932620.7386210.000706
2,04894122.4831722.4819870.001183
2,048104124.12158824.1196590.001928
2,0480815.5731575.5731570
2,0481817.5044837.5044770.000006
2,0482819.4322959.4322760.000019
2,04838111.35582711.3557890.000038
2,04848113.27245513.2723790.000076
2,04858115.17803415.1778940.00014
2,04868117.06585917.0656150.000244
2,04878118.92520318.9247880.000416
2,04888120.73932620.7386210.000706
2,04898122.4831722.4819870.001183
2,048108124.12158824.1196590.001928
2,04801615.5731575.5731570
2,04811617.5044837.5044770.000006
2,04821619.4322959.4322760.000019
2,048316111.35582711.3557890.000038
2,048416113.27245513.2723790.000076
2,048516115.17803415.1778940.00014
2,048616117.06585917.0656150.000244
2,048716118.92520318.9247880.000416
2,048816120.73932620.7386210.000706
2,048916122.4831722.4819870.001183
2,0481016124.12158824.1196590.001928
2,04803215.5731575.5731570
2,04813217.5044837.5044770.000006
2,04823219.4322959.4322760.000019
2,048332111.35582711.3557890.000038
2,048432113.27245513.2723790.000076
2,048532115.17803415.1778940.00014
2,048632117.06585917.0656150.000244
2,048732118.92520318.9247880.000416
2,048832120.73932620.7386210.000706
2,048932122.4831722.4819870.001183
2,0481032124.12158824.1196590.001928
2,04806415.5731575.5731570
2,04816417.5044837.5044770.000006
2,04826419.4322959.4322760.000019
2,048364111.35582711.3557890.000038
2,048464113.27245513.2723790.000076
2,048564115.17803415.1778940.00014
2,048664117.06585917.0656150.000244
2,048764118.92520318.9247880.000416
2,048864120.73932620.7386210.000706
2,048964122.4831722.4819870.001183
2,0481064124.12158824.1196590.001928
4,0960215.574035.574030
4,0961217.5065117.5065060.000005
4,0962219.4357489.435740.000008
4,09632111.36121711.361218-0.000002
4,09642113.28023713.280254-0.000017
4,09652115.18886115.188903-0.000042
4,09662117.0807317.080812-0.000082
4,09672118.94556818.945696-0.000128
4,09682120.76715520.76733-0.000175
4,09692122.52098522.521181-0.000196
4,096102124.17243624.172585-0.000149
4,0960415.574035.574030
4,0961417.5065117.5065060.000005
4,0962419.4357479.435740.000007
4,09634111.36121611.361218-0.000003
4,09644113.28023713.280254-0.000017
4,09654115.18885815.188903-0.000045
4,09664117.08072917.080812-0.000084
4,09674118.94556418.945696-0.000132
4,09684120.76715120.76733-0.000179
4,09694122.52097922.521181-0.000202
4,096104124.17242224.172585-0.000162
4,0960815.574035.574030
4,0961817.5065117.5065060.000005
4,0962819.4357479.435740.000007
4,09638111.36121611.361218-0.000003
4,09648113.28023713.280254-0.000017
4,09658115.18885815.188903-0.000045
4,09668117.08072917.080812-0.000084
4,09678118.94556418.945696-0.000132
4,09688120.76715120.76733-0.000179
4,09698122.52097922.521181-0.000202
4,096108124.17242224.172585-0.000162
4,09601615.574035.574030
4,09611617.5065117.5065060.000005
4,09621619.4357479.435740.000007
4,096316111.36121611.361218-0.000003
4,096416113.28023713.280254-0.000017
4,096516115.18885815.188903-0.000045
4,096616117.08072917.080812-0.000084
4,096716118.94556418.945696-0.000132
4,096816120.76715120.76733-0.000179
4,096916122.52097922.521181-0.000202
4,0961016124.17242224.172585-0.000162
4,09603215.574035.574030
4,09613217.5065117.5065060.000005
4,09623219.4357479.435740.000007
4,096332111.36121611.361218-0.000003
4,096432113.28023713.280254-0.000017
4,096532115.18885815.188903-0.000045
4,096632117.08072917.080812-0.000084
4,096732118.94556418.945696-0.000132
4,096832120.76715120.76733-0.000179
4,096932122.52097922.521181-0.000202
4,0961032124.17242224.172585-0.000162
4,09606415.574035.574030
4,09616417.5065117.5065060.000005
4,09626419.4357479.435740.000007
4,096364111.36121611.361218-0.000003
4,096464113.28023713.280254-0.000017
4,096564115.18885815.188903-0.000045
4,096664117.08072917.080812-0.000084
4,096764118.94556418.945696-0.000132
4,096864120.76715120.76733-0.000179
4,096964122.52097922.521181-0.000202
4,0961064124.17242224.172585-0.000162

The reconstruction trajectories remain virtually identical across all tested GPU counts. The largest observed deviation is below 0.002 dB, several orders of magnitude smaller than the approximately 18.6 dB improvement achieved during the reconstruction itself. More importantly, these differences remain bounded throughout the optimization and show no tendency to accumulate over successive iterations.

These results indicate that the distributed implementation preserves the behavior of the original algorithm to numerical precision. Although small floating-point differences naturally arise from tiled execution and distributed reductions, they do not translate into any measurable degradation of the reconstruction quality.

Having established that distributed execution preserves the reconstruction trajectory, we can now evaluate its computational performance.

The figure below shows the average time spent in each stage of one steady-state plug-and-play iteration, separating the acquisition physics, learned denoising, and remaining distributed overhead.

Figure

Larger reconstructions continue to benefit from additional GPUs

Mean steady-state iteration time for three image sizes. Each stacked area separates the acquisition physics, learned denoising, and residual overhead. Each image size uses its own vertical scale.

Loading interactive figure…

Values are averaged over iterations 3–10. The single-GPU 2048² and 4096² runs evaluate the full image directly, while multi-GPU runs use overlapping tiles. The 8192² experiment starts from two GPUs because the corresponding single-GPU configuration is not feasible.

View figure data
Image sideGPUsExecutionTile workPhysics (s)Denoising (s)Overhead (s)Total (s)
2,0481non-distributed10.01680.87820.01640.9114
2,0482distributed1.5630.01090.66080.01650.6882
2,0484distributed1.5630.00590.37370.01620.3959
2,0488distributed1.5630.00650.21780.01650.2408
2,04816distributed1.5630.01290.11760.01630.1468
2,04832distributed1.5630.01230.06470.01620.0932
2,04864distributed1.5630.01330.06480.01590.094
4,0961non-distributed10.06273.53580.06173.6602
4,0962distributed1.5630.03992.81530.06182.917
4,0964distributed1.5630.02151.39090.06321.4756
4,0968distributed1.5630.02260.6740.06250.7591
4,09616distributed1.5630.05130.41090.06190.5241
4,09632distributed1.5630.05160.24990.06180.3633
4,09664distributed1.5630.05070.14960.06130.2617
8,1922distributed1.410.15639.17050.24019.5669
8,1924distributed1.410.08424.68980.24275.0167
8,1928distributed1.410.08552.40740.24672.7395
8,19216distributed1.410.18641.41450.24011.841
8,19232distributed1.410.19180.77360.24131.2067
8,19264distributed1.410.19630.49110.23990.9273

All three problem sizes benefit from additional GPUs, although the amount of acceleration naturally depends on the size of the reconstruction. The largest 8192² problem, which cannot be reconstructed in the corresponding single-GPU configuration, reaches sub-second iteration times on 64 GPUs while continuing to improve throughout the explored scaling range.

Smaller problems exhibit the expected saturation behavior. The 2048² reconstruction accelerates significantly as GPUs are added, but improvements become marginal beyond approximately 32 GPUs because each worker receives too little computation to fully amortize distributed overhead. Larger images, by contrast, maintain enough local work to keep additional GPUs productive.

Taken together, these two figures validate the distributed inference strategy. The implementation preserves the numerical behavior of the original plug-and-play algorithm while extending it to much larger images and substantially reducing reconstruction time as computational resources increase.

How efficiently are additional GPUs used?

The previous section showed that distributed execution reduces reconstruction time while preserving the reconstruction trajectory. A natural follow-up question is whether these speedups remain proportional to the amount of hardware used.

In an ideal strong-scaling experiment, doubling the number of GPUs would halve the runtime, and quadrupling the resources would make the computation four times faster. In practice, distributed execution always introduces some overhead, so the observed speedup gradually deviates from this ideal behavior.

To quantify this effect, we measure the parallel efficiency

Eabsolute(N)=TN0N0TNN,E_{\mathrm{absolute}}(N) = \frac{T_{N_0}N_0}{T_NN},

where (T_N) is the measured iteration time on (N) GPUs and the baseline configuration uses (N_0) GPUs. An efficiency of 100% corresponds to ideal strong scaling, while lower values indicate that additional GPUs provide progressively smaller reductions in runtime.

Figure

Parallel efficiency decreases once the local workload becomes too small

Efficiency relative to the smallest feasible GPU configuration for each image size. The dashed line represents ideal strong scaling.

Loading interactive figure…

The 2048² and 4096² curves use the non-distributed one-GPU run as their baseline. The 8192² curve uses two GPUs because the corresponding single-GPU configuration is not feasible.

View figure data
Image sideGPUsSpeedupEfficiency (%)Tile work
2,048111001
2,04821.3266.21.563
2,04842.357.61.563
2,04883.7847.31.563
2,048166.2138.81.563
2,048329.7830.61.563
2,048649.6915.11.563
4,096111001
4,09621.2562.71.563
4,09642.48621.563
4,09684.8260.31.563
4,096166.9843.61.563
4,0963210.0731.51.563
4,0966413.9921.91.563
8,192211001.41
8,19241.9195.41.41
8,19283.4987.31.41
8,192165.2651.41
8,192327.9349.51.41
8,1926410.3232.21.41

The expected trend immediately appears: larger images remain efficient over a much wider range of GPU counts than smaller ones.

For the 2048² reconstruction, efficiency decreases rapidly as the image is divided among more workers. Although runtime continues to improve up to around 32 GPUs, each additional GPU contributes progressively less because the local amount of work becomes too small to fully amortize communication and synchronization costs.

The 4096² reconstruction remains efficient over a larger range, while the 8192² reconstruction continues to scale well throughout the experiment. These results reinforce the main observation from the timing measurements: the usefulness of additional GPUs is primarily determined by the amount of work assigned to each worker.

At first sight, however, the initial efficiency values may appear surprisingly low. For example, the 4096² reconstruction reaches only about 63% efficiency when moving from one GPU to two GPUs. This apparent loss is largely explained by an important difference between the reference and distributed executions.

Accounting for the work introduced by overlapping tiles

The distributed denoiser operates on overlapping image tiles. Each tile is extended with a halo before being processed so that the neural network has sufficient spatial context near tile boundaries.

As a result, the distributed implementation evaluates more pixels than are present in the original image. Neighboring tiles process overlapping regions multiple times before their central regions are cropped and stitched back together.

This additional computation is an intrinsic consequence of the tiling strategy, not of inefficient parallel execution. The first transition from a single-GPU reconstruction to distributed inference therefore combines two effects:

  1. the efficiency of distributing the computation across multiple GPUs;
  2. the additional work introduced by overlapping tile halos.

To separate these effects, we also report a work-normalized efficiency

Ework(N)=Eabsolute(N)WNWN0,E_{\mathrm{work}}(N) = E_{\mathrm{absolute}}(N) \frac{W_N}{W_{N_0}},

where (W_N) denotes the amount of halo-padded image data processed by the denoiser relative to the useful image area.

This normalization does not assume that inference time is perfectly proportional to the number of pixels. Rather, it removes the known increase in work introduced purely by the tiling geometry.

Figure

Most of the apparent initial efficiency loss comes from additional tile work

Parallel efficiency after accounting for the additional pixels processed in overlapping tile halos.

Loading interactive figure…

For the 8192² experiment, the baseline and all larger configurations use the same tiling geometry, so absolute and work-normalized efficiencies are identical.

View figure data
Image sideGPUsAbsolute (%)Normalized (%)Useful pixels (%)
2,0481100100100
2,048266.2103.564
2,048457.689.964
2,048847.373.964
2,0481638.860.664
2,0483230.647.764
2,0486415.123.764
4,0961100100100
4,096262.79864
4,09646296.964
4,096860.394.264
4,0961643.668.264
4,0963231.549.264
4,0966421.934.164
8,192210010070.9
8,192495.495.470.9
8,192887.387.370.9
8,19216656570.9
8,1923249.549.570.9
8,1926432.232.270.9

The normalized curves reveal that most of the apparent efficiency loss at low GPU counts is simply the cost of processing overlapping halos. For the 4096² problem, the two-GPU efficiency increases from 62.7% to nearly 98% after normalization, showing that the distributed implementation itself remains close to ideal.

The same effect is observed for the 2048² reconstruction, where the normalized efficiency slightly exceeds 100%. This should not be interpreted as superlinear scaling of the overall algorithm. Rather, it indicates that a simple pixel-count correction cannot perfectly model every implementation detail, such as differences in neural-network batching, GPU occupancy, or kernel selection.

As the GPU count continues to increase, both the absolute and normalized curves decrease together. At this stage, halo computation is no longer the dominant factor. Instead, each worker receives progressively less useful computation, making communication, synchronization, and load imbalance increasingly important.

These experiments deliberately keep the tiling parameters fixed so that GPU scaling can be studied in isolation. In the following benchmark studies, we investigate how tile size and workload distribution can themselves be optimized to extend the range over which distributed inference scales efficiently.

Where does the remaining overhead come from?

The efficiency analysis shows that scaling eventually becomes less effective as the number of GPUs increases. This naturally raises the next question: what is actually limiting performance?

One possibility is that the computations themselves stop scaling. Another is that communication and synchronization progressively dominate the execution as less work remains on each GPU.

To distinguish between these effects, we profiled a second set of experiments using the PyTorch profiler, separating CUDA kernels performing useful computation from those associated with distributed communication.

The 2D experiment uses the same 4096² multi-frame super-resolution problem as the previous sections, while the 3D experiment reconstructs a simulated 512³ volume. Both experiments were executed on Tesla V100 GPUs using up to 64 GPUs.

The reported quantities are diagnostics extracted from the profiler rather than a decomposition of the total iteration time. Compute and communication can overlap, and synchronization outside the measured sections is reported independently.

Figure

Computation continues to scale while communication becomes increasingly visible

Top: compute speedup relative to the smallest distributed configuration. Bottom: CUDA time attributed to computation and communication.

Loading interactive figure…

Measurements are averaged over steady-state iterations after excluding the initial warm-up. The 2D distributed baseline uses one GPU, while the 3D baseline uses two GPUs.

View figure data
ProblemGPUsNodesModeCompute (s)Comm. (s)Comm. share (%)
2D 4096x409611non-distributed3.658300
2D 4096x409611distributed4.434500
2D 4096x409621distributed2.27250.02751.2
2D 4096x409641distributed1.12780.02772.4
2D 4096x409682distributed0.56050.04277.1
2D 4096x4096164distributed0.28580.084522.8
2D 4096x4096328distributed0.14880.081235.3
2D 4096x40966416distributed0.08160.081850.1
3D 512x512x51221distributed86.07350.89441
3D 512x512x51241distributed43.05191.53023.4
3D 512x512x51282distributed21.26060.86213.9
3D 512x512x512164distributed10.6670.65975.8
3D 512x512x512328distributed5.35410.41617.2
3D 512x512x5126416distributed2.77530.21927.3

The first observation is reassuring: the compute kernels themselves continue to scale almost ideally throughout the experiments.

For the 2D reconstruction, the compute portion accelerates by a factor of 54.4 between one and 64 GPUs, close to the ideal speedup of 64. The 3D experiment is even closer to ideal, reaching a 31× acceleration between two and 64 GPUs, compared with the theoretical value of 32.

This confirms that the computational building blocks of the distributed solver remain highly scalable. The decreasing end-to-end efficiency observed in the previous section is therefore not caused by the computation itself becoming inefficient.

The second observation is that communication gradually occupies a larger fraction of the execution.

This does not necessarily mean that communication becomes dramatically more expensive. Instead, useful computation is reduced much faster than communication. As the local workload assigned to each GPU decreases, the fixed cost of exchanging halo regions and synchronizing workers represents an increasing fraction of the remaining iteration time.

The effect is clearly visible for the 2D problem. Communication accounts for only a small portion of the CUDA activity at low GPU counts, but approaches half of the profiled execution at 64 GPUs as the compute kernels become extremely short.

The 3D experiment behaves differently. Although the absolute communication time is larger because considerably more data must be exchanged, each GPU also performs substantially more local computation. Communication therefore remains a relatively small fraction of the execution, allowing the reconstruction to maintain excellent scaling even at the largest GPU counts.

Together with the previous efficiency measurements, these results indicate that the current implementation is fundamentally compute-efficient. The main scaling limitations appear once communication, synchronization, and other distributed overheads become comparable to the shrinking amount of useful work performed by each GPU.

Future analyses will investigate these communication patterns in greater detail, including which collective operations dominate execution and how their cost depends on the reconstruction algorithm and hardware configuration.

Conclusions

This study demonstrates that distributed plug-and-play inference can scale to much larger reconstruction problems without sacrificing either numerical correctness or computational efficiency.

First, distributing the computation preserves the reconstruction trajectory. Where a direct comparison is possible, the distributed implementation follows the same optimization path as the single-GPU reference, with only negligible floating-point differences introduced by tiled execution and distributed reductions.

Second, the implementation delivers substantial speedups while extending the range of solvable problems. The largest 8192² reconstruction, which cannot be executed in the reference single-GPU configuration, reaches sub-second iterations on 64 GPUs, demonstrating that distributed execution is both a scalability and an enabling technology.

Finally, the experiments reveal what ultimately governs distributed performance. Scaling is not determined solely by the number of GPUs, but by the amount of useful computation assigned to each worker. When the local workload remains sufficiently large, the distributed implementation achieves near-ideal scaling. As the workload per GPU decreases, communication, synchronization, and other fixed overheads naturally become an increasing fraction of the execution time.

Taken together, these results validate the overall distributed inference strategy implemented in the benchmark. They also motivate the next stage of the analysis: understanding how tiling strategies, workload balancing, and communication patterns can be optimized to extend this efficient scaling regime to even larger systems.