{"id":"09758e2d-d5c2-4d1f-b06a-5e5ce00fdecf","arxiv_id":"2505.01184","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Qdislib is a distributed open-source library that cuts quantum circuits into subcircuits and executes them across CPUs, GPUs, and QPUs, with a new FindCut algorithm that often finds fewer cuts than IBM's CKT.","lead":"The authors built Qdislib, a software library that splits large quantum circuits into smaller pieces and runs those pieces in parallel on CPUs, GPUs, and quantum processors inside a supercomputer infrastructure. It is a proof of concept for stitching quantum computers and classical HPC clusters into a single workflow.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"No correctness validation of the cut/reconstruct pipeline: the performance claims in Figures 6–13 are only meaningful if reconstructed expectation values match the uncut circuit, and no such comparison is reported.","rationale":"Reading in good faith: this is a systems paper, and its contribution is the integration of circuit cutting with PyCOMPSs across CPUs, GPUs, and QPUs. The engineering evidence is real: an open-source repository, benchmarks on MareNostrum 5, and hybrid runs involving local and cloud quantum hardware. However, the abstract's claim of enabling scalable quantum-classical workflows presupposes that cut-and-reconstruct produces correct results. The reader identified this as the weakest assumption, and I agree. Section III-B states equivalence as a design guarantee rather than demonstrating it, and Section IV contains no ground-truth comparison. Because gate-cutting reconstruction has Monte Carlo/quasi-probability structure, finite shots produce statistical error and potential bias if the implementations of the 6^K subcircuits or reconstruction coefficients are wrong. Without correctness validation, the scaling curves are timing data for an unverified computation. The proposed test directly settles the issue: compare reconstructed expectation values with exact statevector results for small instances, repeated enough to separate bias from sampling noise. This does not justify changing the CONDITIONAL verdict; it reinforces it.","tokens_in":16854,"tokens_out":3099,"duration_ms":33285,"concrete_test":"Run a small HEA circuit (e.g., 10 qubits, 2 gate cuts, one row of Table I) and a small random circuit (e.g., 30 qubits, 3 cuts) through the full Qdislib pipeline at 1024 shots, repeating each experiment at least 20 times. Compare the reconstructed mean ⟨Z⊗n⟩ against the exact value from Qiskit-Aer statevector simulation of the uncut circuit. The pipeline passes only if the mean estimated value falls within the 95% confidence interval of the sampling distribution and no systematic bias exceeds the estimated standard error. Repeat for a wire-cut example (e.g., an 8-qubit circuit with 1 wire cut) to cover the other advertised mode. If bias appears, the reported speedups cannot be interpreted as correct distributed execution.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that Qdislib enables scalable hybrid execution via circuit cutting. For that claim to hold, the reconstructed expectation value ⟨Z⊗n⟩ must statistically equal the value from the original uncut circuit. The paper asserts this in Section III-B ('This process ensures that the results of the cut procedure are equivalent to the behavior of the original circuit') but never tests it. All benchmarks in Section IV report only execution times; no experiment compares the reconstructed expectation value with a direct simulation of the uncut circuit, with or without the same shot count. Because gate cutting is quasi-probabilistic (Section II-B) and reconstruction uses finite-shot estimates amplified by quasi-probability coefficients, an implementation error in the DAG conversion, gate decomposition, subcircuit generation, or reconstruction formula would produce a biased or systematically wrong result without changing any reported timing. The speedups in Figure 7 and the hybrid times in Table I are then not evidence for the advertised capability. The absence of repeats and error bars makes it impossible to distinguish such bias from sampling noise. The paper also claims wire cutting support but only benchmarks gate cutting, so wire-cutting equivalence is even less supported. This is not a criticism of the engineering; the missing piece is a correctness test that would validate the whole pipeline.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces Qdislib, an open-source distributed circuit-cutting library built on PyCOMPSs for hybrid quantum-classical HPC workflows. The library represents circuits as DAGs, supports both wire and gate cutting, offers an automatic cut-finding function (FindCut) based on graph partitioning heuristics, and can dispatch subcircuits to CPUs, GPUs, local QPUs, and cloud QPUs. The evaluation benchmarks hardware-efficient ansatz and random circuits on MareNostrum 5, reporting execution times, speedups, CPU/GPU comparisons, hybrid executions, and a comparison with IBM CKT for cut selection.","tokens_in":17065,"tokens_out":3413,"duration_ms":37824,"significance":"If the central claims hold, Qdislib would be a useful open-source contribution: it demonstrates that circuit cutting can be orchestrated by a task-based runtime across heterogeneous classical and quantum backends, and its near-ideal scaling results on a 96-qubit HEA circuit are concrete evidence for the practicality of distributed circuit cutting. The paper explicitly builds on established quasi-probability reconstruction formulas from known references rather than deriving new theory, and it ships an open-source implementation with a reproducibility link. However, the significance is conditional on the correctness of the cut/reconstruct pipeline, and the current manuscript provides no direct correctness validation; all benchmark evidence is timing-based. The paper also relies on single-run measurements and an under-specified loss function, so the performance and cut-quality claims need strengthening before the central contribution can be accepted.","major_comments":[{"comment":"The manuscript asserts in Section III-B that the cut-and-reconstruct process 'ensures that the results of the cut procedure are equivalent to the behavior of the original circuit,' but it reports no experiment that compares the reconstructed expectation value of the Z-tensor observable with the value obtained from the uncut circuit. All benchmarks in Section IV report execution times only. Because gate cutting is quasi-probabilistic and reconstruction uses finite-shot estimates amplified by quasi-probability coefficients, an implementation error in the DAG conversion, gate decomposition, subcircuit generation, or reconstruction formula would produce systematically wrong results without changing any reported timing. This is load-bearing: the speedups in Figures 7 and 9 and the hybrid times in Table I are only evidence for the advertised capability if the computed expectation values are correct. Please add correctness experiments for representative circuits and cut configurations, comparing reconstructed expectation values against direct simulation of the uncut circuit with the same shot count, and report the resulting statistical error.","section":"Section III-B and Section IV"},{"comment":"The performance claims, including the headline 54.4x speedup on 64 nodes in Figure 7, are based on what appear to be single executions without repeats or error bars. Circuit simulation runtimes, PyCOMPSs scheduling, QPU queue times, and cloud network latency can all vary significantly between runs, and the absence of repeated measurements makes it impossible to distinguish genuine scalability from runtime variance or one-off system effects. Please report at least multiple independent runs with mean and standard deviation (or median and range), and clearly define what is included in each timing, especially for QPU and cloud executions where queueing and communication overhead are part of the measured time.","section":"Section IV and Figure 7"},{"comment":"The loss function in Eq. (2) has free weights alpha, beta, and gamma, and the default values are described only as producing 'a well-balanced cut.' The three terms 'min cuts,' 'max comp,' and 'min qubits' are not formally defined, and no normalization or scaling is specified, so the loss landscape and the comparison between gate cutting and wire cutting are not reproducible. This matters for the FindCut evaluation in Figure 11: the claim that Qdislib is faster than IBM CKT and finds fewer cuts is not supported without a precise statement of the weights, the search space, the termination criteria, and the methodology used for the IBM CKT comparison. Please specify the default weights, provide the definition of each loss term, and describe the controlled conditions under which the timings and cut counts in Figure 11 were obtained.","section":"Section III-C, Eq. (2), and Figure 11"}],"minor_comments":[{"comment":"The evaluation explicitly tests only gate cutting, despite the paper claiming support for wire cutting. Since wire-cutting reconstruction is a separate code path with different subcircuit generation and reconstruction formulas, at least a small correctness and performance sanity check for wire cutting should be included, or the manuscript should state more clearly that wire cutting is implemented but not benchmarked.","section":"Section IV"},{"comment":"The random circuits replace the original fSim gates with CZ gates and drop the 'supremacy' part of the name, but the text still says 'Google quantum supremacy circuit' is used. This is acceptable as a stated simplification, but the terminology should be tightened so that readers do not conflate the simplified circuits with the original supremacy circuits.","section":"Section IV-D"},{"comment":"The header of Table I appears garbled in the provided text ('Qubits Cuts CPUs GPUs QPU Cloud QPU Time ncores ngpus nqubits nqubits (s)'). The units and column meanings should be made explicit and the table reformatted.","section":"Table I"},{"comment":"The wire-cutting resource count is described as 'eight pairs of subcircuits,' but the text later correctly states that the overhead scales as 8^k. The phrasing should be clarified to avoid implying that only eight total subcircuits are needed per cut.","section":"Section II-B"},{"comment":"There are several typographical issues, including 'quantun,' 'Haddamard,' 'Hibert,' 'Kernigham Lin,' and 'This is is.' A careful proofreading pass is needed.","section":"Throughout"},{"comment":"The caption and text for Figure 8 say that the depth-68 circuit requires 'two cuts to isolate subcircuits cleanly' for each of the four cuts, but the resulting subcircuit sizes are stated without derivation. Please explain how the number of effective cuts is counted for the deeper circuit.","section":"Section IV-C, Figure 8"},{"comment":"In Figure 13, the QPU cloud execution times are shown as flat lines without any indication of queue time, calibration time, or number of shots used. Since these are single points, the apparent 'convergence' with CPU/GPU lines should be interpreted cautiously, and the text should state what is included in these times.","section":"Section IV-E"},{"comment":"The open-source repository is cited in a footnote, but no version, commit hash, or dependency manifest is provided. For a systems paper whose claims rest on software behavior, please provide a stable release identifier and instructions for reproducing the main benchmark figures.","section":"Reproducibility"}],"recommendation":"major_revision","confidential_remarks":"The missing correctness validation is the key issue and is fixable within the manuscript's scope: adding a direct comparison of reconstructed expectation values against uncut-circuit values, together with repeated timing measurements, would convert a potentially useful but unverified systems demo into a substantiated contribution. The paper is otherwise in scope for a journal that accepts systems/software contributions, though the novelty relative to existing cutting libraries and scheduling approaches is moderate and should be articulated more crisply after the corrections."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: the paper is a legitimate systems contribution—Qdislib is an open-source distributed circuit-cutting library that really runs on CPUs, GPUs, a local QPU, and a cloud QPU under one PyCOMPSs workflow. The scaling benchmark for the 96-qubit HEA (54.4x on 64 nodes) is the kind of result that matters to the hybrid HPC-quantum crowd. But the evaluation has a load-bearing gap: no test that the reconstructed expectation value equals the uncut circuit's expectation value. The authors assert it in Section III-B, but never show it. For a quasi-probabilistic gate-cutting pipeline, an implementation error would silence the outputs and not change any timings. So the speedup numbers, as impressive as they look, are only evidence for the advertised capability if correctness is checked.\n\nWhat's actually new: Qdislib itself, and the FindCut algorithm that runs four graph partitioners in parallel and picks the best through a loss function. The comparison with IBM CKT, showing fewer cuts and lower execution time on random circuits, is a concrete, useful data point. The hybrid execution across Ona and IBM Cloud, with the double-port-forwarding workaround, is real engineering, and the authors deserve credit for the integration.\n\nSoft spots, in proportion: (1) The missing correctness check is the big one. It's fixable—just run a few circuits at, say, 10–20 qubits, compare the reconstructed <Z⊗n> with a noiseless direct simulation, together with shot-noise error bars. (2) No repetitions or error bars anywhere in the benchmarks, so the timing comparisons are single-run evidence. (3) Although they claim wire cutting support, they only benchmark gate cutting and justify it in a paragraph. That's fine, but the wire-cutting code paths remain unverified. (4) Minor: the loss function weights α, β, γ are free and their default values aren't given; not important for the scaling claim, but it makes FindCut harder to reproduce precisely.\n\nThe citation pattern is fine—they use the published cutting formulas from Peng et al. and Mitarai & Fujii, and they cite FitCut and Atlas, the two closest prior works. No overclaiming of novelty beyond the software and the FindCut heuristic.\n\nOverall: I'd send it to a serious referee, not desk-reject it. The systems contribution is real and the missing correctness check is an eminently addressable revision, not a fatal flaw. This is a paper for the HPC-quantum systems community, and it would be read with interest. For what it's worth, I'd ask the authors to add a correctness section and run-to-run statistics before I'd fully trust the numbers.","headline":"A credible systems paper on a distributed circuit-cutting library that needs a correctness validation of the reconstructed results before its performance numbers can be fully trusted.","tokens_in":17615,"tokens_out":2321,"would_cite":true,"duration_ms":22660,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Quantum circuit cutting can be distributed across CPUs, GPUs, and QPUs at near-ideal scale, reaching a 54.4x speedup on 64 nodes.","keywords":["quantum circuit cutting","hybrid quantum-classical computing","high-performance computing","distributed task-based programming","graph representation of quantum circuits","wire cutting","gate cutting","circuit partitioning"],"falsifier":"Run a circuit such as the 96-qubit hardware-efficient ansatz uncut on a statevector simulator to obtain the exact expectation value of Z⊗n, then run Qdislib's cut workflow on the same circuit with the same shot count and compare the reconstructed value; any disagreement beyond sampling error would show the pipeline is biased.","tokens_in":16647,"feed_emoji":"⚛️","tokens_out":8788,"duration_ms":80825,"temperature":0.7,"pith_summary":"Qdislib is a distributed quantum circuit cutting library that splits large circuits into smaller subcircuits, executes them in parallel on CPUs, GPUs, local quantum processors, and cloud quantum processors, and reconstructs the original expectation value from the pieces. The paper's central claim is that this makes circuit cutting a practical primitive for hybrid quantum-classical high-performance computing: a 96-qubit hardware-efficient circuit with four cuts reaches a 54.4x speedup on 64 nodes, and the library's automatic cut finder finds fewer cuts in less time than the standard Qiskit cutting addon. The authors further claim that cut subcircuits are equivalent to the original circuit, so the resulting expectation value matches what the uncut circuit would produce. If these claims hold, circuit cutting becomes a way to extend both classical simulation and small quantum hardware to circuits larger than any single device can hold.","feed_headline":"Circuit cutting scales to 64 nodes with 54.4x speedup","feed_subtitle":"Qdislib splits a 96-qubit circuit and runs the pieces across CPUs, GPUs, and quantum chips in parallel.","key_machinery":"The central object is the directed acyclic graph (DAG) representation of the quantum circuit, which gives Qdislib a software-agnostic handle for cutting, partitioning, and reassembly. On top of that graph sit two cutting mechanisms: wire cutting, which splits a qubit wire and reconstructs the observable with Pauli eigenstate preparations and 8^k combinations, and gate cutting, which decomposes a two-qubit gate into local operations with intermediate measurements and 6^k combinations. The graph also feeds the FindCut algorithm, which runs several graph partitioners (Kernighan-Lin, Girvan-Newman, spectral decomposition, and METIS) and scores their cuts with a loss function that trades number of cuts, number of resulting components, and subcircuit qubit count. The final load-bearing piece is the task-based runtime PyCOMPSs, which schedules the generated subcircuits across CPUs, GPUs, and quantum processors and collects the results for reconstruction. This combination is what the paper argues turns circuit cutting from a theoretical decomposition into a scalable hybrid execution model.","core_discovery":"The discovery being argued for is that circuit cutting can be engineered into a distributed, hardware-agnostic workflow without sacrificing correctness or scalability. Qdislib converts a quantum circuit into a directed acyclic graph, lets the user mark or automatically find wire cuts and gate cuts, generates all 8^k wire-cut or 6^k gate-cut subcircuit instances, and dispatches them through a task-based runtime to whatever classical or quantum backends are available. The reconstruction of the expectation value uses the quasi-probability coefficients from gate cutting and the Pauli-basis reconstruction from wire cutting. On the benchmarks presented, the library is said to scale almost linearly with nodes for a 96-qubit hardware-efficient ansatz and to outperform the Qiskit cutting addon in cut count and time on random circuits. The paper also claims successful hybrid execution with subcircuits simultaneously on CPUs, GPUs, a local 5-qubit processor, and a cloud quantum processor.","pith_inferences":["A direct fidelity check—comparing reconstructed expectation values with values from the uncut circuit at the same shot count—would establish whether the reported speedups produce unbiased outputs, and is the natural next experiment.","Since subcircuit count grows as 6^k or 8^k, cutting pays off only when each subcircuit is expensive enough to amortize the reconstruction; the paper's 32-qubit results already hint that extra cuts can hurt small circuits, and the same trade-off should sharpen on slower backends.","The DAG-based scheduling model is not tied to cutting; the same runtime could schedule variational algorithms or error-mitigation jobs, deciding online which parts run classically and which on quantum hardware."],"forward_implications":["A 96-qubit hardware-efficient circuit cut into four fragments simulates with near-ideal parallel speedup, so the practical limit of noise-free classical emulation rises as HPC nodes are added.","Circuits too large for any available quantum chip can still be run by splitting them into fragments that fit small QPUs, at the cost of an exponential number of subcircuit executions and a classical reconstruction step.","A single hybrid job can place subcircuits on CPUs, GPUs, a local QPU, and a cloud QPU; the sequential service time of the quantum chips, not the classical side, sets the wall-clock floor.","Because FindCut returns fewer cuts than the standard Qiskit cutting addon on the random-circuit benchmark, the reconstruction overhead is lower for the same hardware constraint.","Releasing the library as open source means the scaling results and cut-finding behavior can be reproduced and extended to other simulators and devices."],"supporting_citations":[{"why":"Supplies the PyCOMPSs task-based runtime that schedules and parallelizes subcircuit execution.","marker":"[9]"},{"why":"Defines the wire-cutting reconstruction formulas used to combine subcircuit expectation values.","marker":"[6]"},{"why":"Provides the quasi-probability gate decomposition used for gate cutting and its reconstruction coefficients.","marker":"[8]"},{"why":"Establishes the CutQC circuit-cutting approach that Qdislib extends to distributed HPC execution.","marker":"[7]"},{"why":"Provides the Qiskit circuit format, the Aer simulator backend, and the CKT addon used as the FindCut comparison baseline.","marker":"[18]"},{"why":"Provides the Qibo framework used for local QPU programming and the HEA circuit definition.","marker":"[19]"},{"why":"Supplies the random quantum circuit structure used in the second benchmark and in the FindCut comparison.","marker":"[25]"},{"why":"Gives the FitCut distributed cutting-and-scheduling baseline whose cut counts the FindCut results are compared against.","marker":"[29]"},{"why":"The Qiskit circuit-cutting addon whose CKT cut finder is the direct comparison for FindCut speed and cut count.","marker":"[37]"}],"fun_headline_variants":["Qdislib cuts 96-qubit circuits, runs pieces across CPUs, GPUs, QPUs","Distributed circuit cutting hits near-linear scaling on 64 nodes","Wire and gate cuts parallelized across heterogeneous HPC backends","Qdislib: circuit cutting for hybrid quantum-classical HPC at scale","From one circuit to thousands of jobs: Qdislib scales cutting"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The paper assumes, without an experimental check, that the full cut-and-reconstruction pipeline produces expectation values identical to the original uncut circuit.","fun_headline_variants_meta":{"raw":{"variants":["Qdislib cuts 96-qubit circuits, runs pieces across CPUs, GPUs, QPUs","Distributed circuit cutting hits near-linear scaling on 64 nodes","Wire and gate cuts parallelized across heterogeneous HPC backends","Qdislib: circuit cutting for hybrid quantum-classical HPC at scale","From one circuit to thousands of jobs: Qdislib scales cutting"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000235,"raw_usage":{"total_tokens":1490,"prompt_tokens":922,"completion_tokens":568,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":538,"completion_tokens_details":{"reasoning_tokens":469}},"tokens_in":538,"tokens_out":568,"duration_ms":5135,"temperature":1.0,"reasoning_tokens":469,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:23:47.441164+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a circuit such as the 96-qubit hardware-efficient ansatz uncut on a statevector simulator to obtain the exact expectation value of Z⊗n, then run Qdislib's cut workflow on the same circuit with the same shot count and compare the reconstructed value; any disagreement beyond sampling error would show the pipeline is biased.","supporting_citations":[{"cited_title":"Pycompss: Parallel computational workflows in python","cited_arxiv_id":null,"evidence_quote":"Supplies the PyCOMPSs task-based runtime that schedules and parallelizes subcircuit execution."},{"cited_title":"Simulating large quantum circuits on a small quantum computer","cited_arxiv_id":null,"evidence_quote":"Defines the wire-cutting reconstruction formulas used to combine subcircuit expectation values."},{"cited_title":"Constructing a virtual two-qubit gate by sampling single-qubit operations","cited_arxiv_id":null,"evidence_quote":"Provides the quasi-probability gate decomposition used for gate cutting and its reconstruction coefficients."},{"cited_title":"Cutqc: using small quantum computers for large quantum circuit evaluations","cited_arxiv_id":null,"evidence_quote":"Establishes the CutQC circuit-cutting approach that Qdislib extends to distributed HPC execution."},{"cited_title":"Qibo: a framework for quantum sim- ulation with hardware acceleration","cited_arxiv_id":null,"evidence_quote":"Provides the Qibo framework used for local QPU programming and the HEA circuit definition."},{"cited_title":"Scalable circuit cutting and scheduling in a resource-constrained and distributed quantum system","cited_arxiv_id":null,"evidence_quote":"Gives the FitCut distributed cutting-and-scheduling baseline whose cut counts the FindCut results are compared against."},{"cited_title":"Bra ´nczyk, Almudena Carrera Vazquez, Daniel J","cited_arxiv_id":null,"evidence_quote":"The Qiskit circuit-cutting addon whose CKT cut finder is the direct comparison for FindCut speed and cut count."}],"review_version":1}