Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Hybrid Quantum and Classical Workload Management with Graph-based Scheduling

T0 review · 3 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Gating classical workers until a remote quantum task nears the front of its vendor queue cuts idle node time by roughly 5x and costs by roughly 70x.

desk verdict Fluence is a real, useful scheduling contribution with an overstated abstract; the mechanism works, but the headline numbers shouldn't be taken at face value. read the letter →

arxiv 2607.09151 v2 pith:Q2NNWXRB submitted 2026-07-10 quant-ph cs.DC

Vanessa Sochat , Daniel Milroy This is my paper
classification quant-phcs.DC
keywords two-queueproblemhybridquantum-classicalworkloadsgangschedulinggraph-basedschedulerpluginbackendselectionworkeridletimequantumresourcemanagement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper addresses the two-queue problem that arises when hybrid quantum-classical workloads must wait in a vendor-owned queue that the classical scheduler cannot see or control. The authors build Fluence, a cloud-native scheduler plugin that models the remote quantum backend as a first-class resource in a graph-based scheduler, so a job requests quantum and classical resources together, all-or-nothing. A single producer pod submits the quantum task while the remaining workers are held behind scheduling gates until the task nears the front of the external queue. In experiments across simulators and real quantum devices, this gating reduces worker idle time by roughly 5x under short queues and by orders of magnitude when a queue stretched to hours, and attribute-based backend selection cuts mean per-run cost by roughly 70x and time-to-result from hours to under a minute. The authors claim this quantum-awareness can be added to a cloud-native scheduler without modifying user containers.

What carries the argument

The two-queue problem is the paper's central object: a workload manager must schedule resources against a second queue it neither controls nor fully observes. The mechanism that carries the argument is pairing the Fluxion graph-based scheduler's resource graph with Kubernetes scheduling gates: quantum backends are inserted into the graph as attributed resources at rack level; a job request is expressed as two all-or-nothing graph queries (quantum and classical) that must both succeed; and a webhook splits a Job into one producer and N-1 gated consumers, with a producer sidecar polling the vendor queue and ungating workers when the task reaches the front. Native gang scheduling provides the a

What would settle it

Run the same hybrid workload against a vendor device that goes offline for calibration after task submission, or whose reported queue depth is a poor predictor of time-to-start (e.g., a shallow queue with long-running jobs ahead), and measure consumer idle time; if gated workers are released early and idle anyway, the claimed 5x and orders-of-magnitude improvement collapses. A controlled mock vendor queue with injected noise in queue-depth reports would settle how much of the benefit depends on signal quality.

Watch

Extended reading notes

Core claim

The central claim is that the pathological behavior of allocating classical nodes and letting them sit idle while a quantum task waits in an external queue can be eliminated at the scheduling layer. The scheduler should treat the quantum backend as a first-class, attributed resource in its graph; submit the quantum work from a single producer; and keep the classical consumers gated until the quantum task is ready to run. Under node contention, atomic gang placement removes the wasted node-time from partial gang placement. Under external queue waits, the gating design reduces worker idle time by roughly 5x for short queues and by orders of magnitude for a real device queue that stretched to h

Load-bearing premise

The gating advantage rests on the producer sidecar being able to tell, from the vendor API, when the quantum task is close to actually running; the paper itself notes that queue depth is not a complete indicator of time-to-arrival, and if that signal is unreliable, or a device goes offline for calibration, workers are ungated at the wrong time and the idle-time advantage over the default scheduler may not hold outside the specific vendor conditions tested.

Editorial extensions

If this is right

  • All-or-nothing gang placement removes the wasted node-time from partially placed gangs: in the paper's contention experiment, accumulated wasted node time dropped from 737 node-seconds with the default scheduler to 18 with Fluence at gang size 4.
  • Gating classical consumers until the quantum task reaches the front of the vendor queue cuts worker idle time by roughly 5x under short queues and by orders of magnitude when a real device queue stretched to hours (a single 2.66-hour wait produced 19,160 node-seconds of idle time for the ungated gang).
  • Cost- and queue-aware backend selection pins the cheapest or shortest-queue device and reduces mean per-run cost by roughly 70x and time-to-result from hours to under a minute.
  • Users do not need to modify their containers to get this quantum-awareness; they request a quantum resource and the scheduler handles producer/consumer splitting, gating, and backend selection.
  • The same graph-modeling strategy applies to devices that are locally controlled or reliably reservable, not just remote vendor APIs; the paper says representation in the graph is the same, only the deployment differs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The gating primitive should generalize beyond quantum: any workload that blocks on an external queue (cloud GPUs, queued API services, data pipelines) could be modeled as a first-class resource with a producer sidecar polling that queue; nothing in the mechanism is quantum-specific.
  • The policy-based backend selection is currently a user-space plugin that keeps credentials local; moving it into the scheduler would require scoped credentials that can only query queue depth and cost, a trade-off the paper flags as a security concern but leaves open.
  • The full benefit for variational-loop and batch patterns depends on vendor support for priority sessions after the first call; on vendors without such sessions, the paper's results mainly establish the single-evaluation and fan-out patterns, so the 5x and orders-of-magnitude numbers should not be assumed to carry over to iterative algorithms.
  • An event-driven vendor API—a callback when a task reaches the front of the queue—would remove the polling dependence that is the design's weakest link; the paper proposes this as a vendor request, so it is a natural next step to test.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents Fluence, a Kubernetes scheduler plugin that uses the Fluxion graph scheduler to model remote quantum backends as first-class resources. It introduces a gating mechanism in which a producer pod submits a quantum task and consumer pods are held by scheduling gates until the task approaches the head of the vendor queue, addressing what the authors call the 'two-queue problem.' Three experiments are reported: (1) gang scheduling under node contention on a small cluster, showing that Fluence's atomic gang placement reduces wasted node-time compared to Kubernetes' default scheduler; (2) policy-based backend selection using a kubectl plugin to minimize cost or queue depth; and (3) quantum selection using AWS Braket simulators and real QPUs, measuring consumer idle time for gangs of size 2, 4, and 8. The abstract claims that gating reduces worker idle time by roughly 5x under short queues and by orders of magnitude for a long queue, and that cost-aware selection cuts mean per-run cost by roughly 70x.

Significance. If the results are robust, the work addresses a genuine and practically important problem: coordinating classical and quantum resources when the quantum device is behind an external, partially unobservable queue. The design is original in representing quantum backends in the Fluxion resource graph and in using native Kubernetes scheduling gates for synchronization. The paper includes open-source artifacts (Fluence and kubectl-fluence) and reproduces gang-scheduling experiments, which strengthens reproducibility. The qualitative findings—that gating always reduces idle time in the tested settings, and that atomic gang placement avoids partial-gang waste—are credible and supported by the presented data. However, the headline quantitative claims (5x/orders of magnitude, 70x cost reduction) are not well supported by the reported summary statistics and are partly self-referential, so the paper's publishable contribution currently rests on overstated numbers.

major comments (3)
  1. [Abstract and §3 (Quantum Selection), Fig. 6] The reported medians do not support the abstract's claim of 'roughly 5x' reduction in worker idle time under short device queues. For N=8 consumers, the default/Fluence medians are 74/62 s (dm1), 75/62 s (sv1), and 223/32 s (tn1), yielding ratios of about 1.19x, 1.20x, and 6.97x. The typical improvement is about 20%, not 5x. The 'orders of magnitude' claim rests entirely on a single 2.66-hour queue event, which, as §4.1 admits, 'by chance hit the default scheduler run.' No confidence intervals, per-run distributions, or N=4 values are provided. The authors should either present a full statistical picture (e.g., all runs, effect sizes, intervals) or revise the abstract and conclusion to state that gating consistently reduces idle time, with magnitude depending on queue conditions. This is load-bearing because the magnitude is the central advertised result.
  2. [§3 (Policy Selection), Fig. 5 and Abstract] The '72x cost reduction' and faster time-to-result from the min-cost and min-queue-depth policies are essentially by construction: the policy minimizes cost (or queue depth), and the comparison is against random selection, which sometimes picks expensive or deep-queue devices. This is not an independent validation of the policy's benefit; it is a demonstration that the selection mechanism can be implemented and behaves as specified. The abstract's phrasing 'cutting mean per-run cost by roughly 70x' overstates the significance. The authors should reframe this experiment as a mechanism demonstration and de-emphasize the absolute multiplier, or add a baseline that is not simply random (e.g., default fixed backend) and report the variability over the 10 runs.
  3. [§4.1 Limitations and Abstract] The paper explicitly acknowledges that the long 2-3 hour wait 'by chance hit the default scheduler run, and could have easily been allocated to Fluence.' While the argument that Fluence would have kept idle time near zero in that case is correct by design, it also means the observed 'orders of magnitude' advantage is not a stable property of the system but a consequence of which scheduler happened to receive the outlier. The authors should report the full queue-wait distribution and the idle-time result for each run, including what happens when a long wait occurs on a Fluence-scheduled gang, and discuss the robustness of the claimed advantage. As written, the strongest quantitative claim is unsupported by the aggregate statistics.
minor comments (5)
  1. [§3 (Quantum Selection), Fig. 6] Figure 6's x-axis label 'compared to number of workers' is unclear; it appears to be the group size N (producer + consumers). Clarify the axis and state whether the reported idle time is total across consumers or mean per consumer.
  2. [§2.2 vs §3 (Policy Selection)] The text in §2.2 says the experiments use 'three simulators and three real quantum queues,' but the policy-selection section mentions 'three QPUs and two simulators.' This inconsistency should be reconciled.
  3. [§2.2 (Quantum Selection)] The paper defines consumer idle time as 'the sum of time over consumers that are running before they successfully retrieve a task identifier associated with a result,' but no explicit formula is given. A precise definition (e.g., including the time between pod start and gate removal) would improve reproducibility.
  4. [§1 (Introduction) and throughout] There are several typos and stylistic issues: 'persits' should be 'persists,' 'relaibly' should be 'reliably,' 'downtown' should be 'downtime,' and 'experiuments' should be 'experiments.' Also, the acknowledgment 'grateful for beaches and mountains, purple flowers' seems out of place for a technical paper.
  5. [§4.1 Limitations] The gating mechanism depends on the reliability of vendor queue-depth signals; the paper itself notes that 'queue depth cannot be a complete indicator of estimated time to arrival of a quantum job.' A brief discussion of how inaccurate or delayed queue-depth information would affect the gating benefit would strengthen the deployment guidance, even if the presented experiments use real Braket conditions.

Circularity Check

1 steps flagged · score 4.0 of 10

Cost-policy '70x reduction' restates the optimization objective; central gang and gating comparisons are real experiments

  1. self definitional [Section 2.2 'Policy Selection' and Section 3 'Policy Selection' (Figure 5); Abstract third contribution]
    "For this experiment, we will do 10 calls of using Fluence with and without the kubectl plugin, asking to minimize cost or queue depth, and demonstrate a lower mean cost and waiting time when using the plugin as opposed to choosing a backend at random. ... the min-cost policy pinned dm1 on all runs, resulting in a cost reduction of approximately 72x and eliminating variation."

    The evaluation metric (mean per-run cost) is exactly the variable the policy is asked to minimize. Selecting the cheapest backend and then reporting that the selected backend is cheaper than a random draw is entailed by the definition of minimization, not an independent empirical finding. The 72x figure is the gap between the cheapest device and the more expensive devices in the random baseline, so the 'prediction' reduces by construction to the policy's objective. The queue-depth portion is less forced because the paper itself notes queue depth is not a complete indicator of time-to-arrival, leaving that part with independent empirical content.

full rationale

The paper's central contributions are engineering demonstrations rather than derived predictions. The gang-scheduling comparison (Figure 4) is a genuine head-to-head measurement of Fluence's all-or-nothing placement versus the default scheduler on the same cluster, and the gating experiment (Figure 6) compares gated consumers against an ungated control group on real Braket queues. The direction of the gating effect is intended by design, but the magnitude is an empirical outcome, and the paper honestly reports variability, including the 2.66-hour queue that 'by chance hit the default scheduler run' (Section 4.1). The queue-depth policy result also retains empirical content because the paper disclaims queue depth as a complete predictor. The one clear reduction is the cost-policy experiment: the '70x cost reduction' is the optimizer's objective echoed back as a result, so it is not independent validation. Self-citations to the earlier Fluence work [15] are continuations backed by new experiments, not load-bearing circular proofs. Overall, the circularity is localized to the cost-policy framing; the main idle-time and gang-scheduling results are supported by real comparisons and are not by-construction reductions.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

No fitted parameters. The experimental claims rest on domain assumptions about queue-signal reliability, baseline equivalence, and the representativeness of a single long queue event; none is independently established outside the paper's own measurements.

assumptions (5)
  • domain assumption AWS Braket queue depth/position can be polled and used as a reliable readiness signal for ungating workers.
    The gating mechanism in §2.1-2.2 depends on the producer sidecar polling until the task reaches the front; §3 admits queue depth is not a complete ETA indicator.
  • domain assumption A native Kubernetes PodGroup with hand-set device names/task IDs runs the same application equivalently to Fluence's gated gang.
    §2.2 states the default baseline mirrors producer/consumer roles by hand, 'ensuring that despite different scheduling, the application runs equivalently.' If not, idle-time comparisons are confounded.
  • domain assumption The 2.66-hour vendor queue is representative of typical conditions and its assignment to the default arm was not systematic.
    §4.1: the wait 'by chance hit the default scheduler run, and could have easily been allocated to Fluence.' The orders-of-magnitude headline depends on this event.
  • domain assumption Fluxion's match_allocate and constraint queries correctly model paired quantum+classical resources as all-or-nothing.
    Graph modeling in §2.1 relies on Fluxion RFCs [7,8]; correctness of the scheduler's central allocation depends on these semantics.
  • domain assumption The QAOA max-cut fan-out application is representative of hybrid quantum-classical workloads.
    All quantum idle-time results use one fan-out app (§2.2); variational and batch patterns are discussed but not benchmarked.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hybrid Quantum and Classical Workload Management with Graph-based Scheduling." pith.science (2026). https://pith.science/paper/Q2NNWXRB

@misc{pith2026260709151,
  author       = {Pith},
  title        = {Pith review of: Hybrid Quantum and Classical Workload Management with Graph-based Scheduling},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Q2NNWXRB}},
  note         = {Machine review of arXiv:2607.09151}
}
read the original abstract

High Performance Computing (HPC) centers are expanding to encompass resources that extend beyond traditional computing. By extending resources to quantum computing, hybrid quantum-classical workflows tackle complex optimization problems that have never before been possible. However, integrating quantum processing units (QPUs) into cloud-native and scientific workload managers presents a unique orchestration challenge: remote quantum devices introduce a second, external queue -- a two-queue problem -- alongside the queue owned by the traditional scheduler. In this work we present Fluence, a Kubernetes scheduler plugin backed by the Fluxion graph-based scheduler, that enables informed, gang-scheduled placement for quantum-classical workloads and custom resources. We evaluate Fluence across three scenarios using AWS Braket simulators and real QPUs. First, under node contention, Fluence's atomic gang placement all but eliminates the wasted node-time that a default scheduler accrues by partially placing gangs. Second, we introduce a synchronization primitive for the two-queue problem in which a single producer submits a shared quantum task while consumers remain scheduling-gated, reducing worker idle time by roughly 5x under short device queues and by orders of magnitude when a real device queue stretched to hours. Third, cost- and queue-aware backend selection pins the cheapest or shortest-queue device satisfying a workload, cutting mean per-run cost by roughly 70x and time-to-result from hours to under a minute. Together, these results show that quantum-awareness can be added to a cloud-native scheduler without modifying user containers.

Figures

Figures reproduced from arXiv: 2607.09151 by the authors.

Figure 1
Figure 1. The two queue problem Scheduling one workload manager’s resources against work waiting in a separate queue that is neither controlled nor completely observable by the workload manager. Given a dependency structure between the two systems, resources are required to wait in absence of intelligent co-scheduling. Kubernetes We choose Kubernetes as our workload management environment for this initial prototype due to the… view at source ↗
Figure 2
Figure 2. Hybrid modeling of classical and quantum resources in the Fluxion resource graph. A quantum device is modeled at the same level as a rack, and job requests for work correspond to a traversal in the graph. Constraints are used to limit search to a resource class. devices and tendency to have queues will have classical resources like GPUs idling for an unspecified amount of time. We introduce this problem of coordinat… view at source ↗
Figure 3
Figure 3. Hybrid quantum and classical application designs. The single evaluation (top), when a circuit is run and post-processed, forms a simple, single execution unit that is the basis for more complex designs. The variational design (second row) maps this unit into a cycle, receiving back results, and adjusting parameters to run again until convergence. The batch pattern (bottom left) runs many single evaluations in parall… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Gang scheduling for 18 gangs of varying sizes across 3 applications for each of fluence and the default-scheduler. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Policy aware selection. Requesting Fluence to select a minimum cost backend easily clusters all points around a trivial cost close to zero (top panel). Asking Fluence to select minimize queue depth leads to a faster end-to-end time to complete the work (bottom panel). …
Figure 6
Figure 6. Figure 6: Worker idle time across quantum simulators or devices, compared to number of workers. As expected, the idle time increases with [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

Review history (2 revisions) →

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Examining QRMI as a Unified Interface for Quantum-HPC Integration

    cs.ET 2026-07 conditional novelty 6.0 of 10

    QRMI's acquire-execute-release interface can be adapted to PBS, LSF, Grid Engine, Kubernetes, and partly Flux, with three reusable integration patterns.

Reference graph

Works this paper leans on

28 extracted references · cited by 1 Pith paper

  1. [1]

    Gang Scheduling

    2025. Gang Scheduling. https://kubernetes.io/docs/concepts/scheduling-eviction/ gang-scheduling/. Accessed: 2026-6-23

    2025

  2. [2]

    Ahn, Jim Garlick, Mark Grondona, Don Lipari, Becky Springmeyer, and Martin Schulz

    Dong H. Ahn, Jim Garlick, Mark Grondona, Don Lipari, Becky Springmeyer, and Martin Schulz. 2014. Flux: A Next-Generation Resource Management Framework for Large HPC Centers. In2014 43rd International Conference on Parallel Processing Workshops. 9–17. doi:10.1109/ICPPW.2014.15

    doi:10.1109/icppw.2014.15 2014

  3. [3]

    AWS. 2026. Amazon Braket Pricing. https://aws.amazon.com/braket/pricing/. Accessed: 2026-6-30

    2026

  4. [4]

    AWS. 2026. What is Amazon Braket? https://docs.aws.amazon.com/braket/latest/ developerguide/what-is-braket.html. Accessed: 2026-6-23

    2026

  5. [5]

    Utz Bacher, Mark Birmingham, Christopher D Carothers, Andrew Damin, Carlos D Gonzalez Calaza, Ashwin Kumar Karnad, Stefano Mensa, Matthieu Moreau, Aurelien Nober, Munetaka Ohtani, Max Rossmannek, Philippa Rubin, M Emre Sahin, Oscar Wallis, Amir Shehata, Iskandar Sitdikov, and Aleksander Wennersteen. 2025. Quantum resources in resource management systems.a...

    2025

  6. [6]

    M Cerezo, Andrew Arrasmith, Ryan Babbush, Simon C Benjamin, Suguru Endo, Keisuke Fujii, Jarrod R McClean, Kosuke Mitarai, Xiao Yuan, Lukasz Cincio, and Patrick J Coles. 2021. Variational quantum algorithms.Nat. Rev. Phys.3, 9 (Aug. 2021), 625–644

    2021

  7. [7]

    Flux Developers. 2025. 27/Flux Resource Allocation Protocol Version 1 — Flux doc- umentation. https://flux-framework.readthedocs.io/projects/flux-rfc/en/latest/ spec_27.html. Accessed: 2026-6-30

    2025

  8. [8]

    Flux Developers. 2025. 35/Constraint Query Syntax — Flux documentation. https: //flux-framework.readthedocs.io/projects/flux-rfc/en/latest/spec_35.html. Ac- cessed: 2026-6-24

    2025

Show all 28 references
  1. [9]

    Xiang Fang, Keyi Yin, Yuchen Zhu, Jixuan Ruan, Dean Tullsen, Zhiding Liang, Andrew Sornborger, Ang Li, Travis Humble, Yufei Ding, and Yunong Shi. 2025. CaliQEC: In-situ Qubit Calibration for Surface Code Quantum Error Correc- tion. InProceedings of the 52nd Annual Internationa...

    2025

  2. [10]

    Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. 2014. A quantum approxi- mate optimization algorithm.arXiv [quant-ph](Nov. 2014)

    2014

  3. [11]

    IBM. 2026. Introduction to Qiskit Runtime execution modes. https://quantum. cloud.ibm.com/docs/en/guides/execution-modes#session-mode. Accessed: 2026- 6-30. Hybrid Quantum and Classical Workload Management with Graph-based Scheduling CANOPIE Workshop, Nov 15-20, 2026, Chicago, IL

    2026

  4. [12]

    IBM. 2026. Maximum execution time for Qiskit Runtime workloads. https: //quantum.cloud.ibm.com/docs/en/guides/max-execution-time. Accessed: 2026- 6-30

    2026

  5. [13]

    IBM Quantum. 2026. IBM Quantum Platform. https://quantum.cloud.ibm.com/. Accessed: 2026-06-23

    2026

  6. [14]

    Daniel J Milroy, Claudia Misale, Giorgis Georgakoudis, Tonia Elengikal, Abhik Sarkar, Maurizio Drocco, Tapasya Patki, Jae-Seung Yeom, Carlos Eduardo Arango Gutierrez, Dong H Ahn, and Yoonho Park. 2022. One Step Closer to Converged Computing: Achieving Scalability with Cloud-Na...

    2022

  7. [15]

    Milroy, Carlos Eduardo Arango Gutier- rez, Stephen Herbein, Dong H

    Claudia Misale, Maurizio Drocco, Daniel J. Milroy, Carlos Eduardo Arango Gutier- rez, Stephen Herbein, Dong H. Ahn, and Yoonho Park. 2021. It’s a Scheduling Affair: GROMACS in the Cloud with the KubeFlux Scheduler. In2021 3rd Inter- national Workshop on Containers and New Orch...

    2021

  8. [16]

    Alberto Peruzzo, Jarrod McClean, Peter Shadbolt, Man-Hong Yung, Xiao-Qi Zhou, Peter J Love, Alán Aspuru-Guzik, and Jeremy L O’Brien. 2014. A variational eigenvalue solver on a photonic quantum processor.Nat. Commun.5, 1 (July 2014), 4213

    2014

  9. [17]

    John Preskill. 2018. Quantum computing in the NISQ era and beyond.arXiv [quant-ph](Jan. 2018)

    2018

  10. [18]

    qrmi Contributors. 2025. qiskit-community/qrmi

    2025

  11. [19]

    Scheduling Queue. 2024. Scheduling Framework. https://kubernetes.io/docs/ concepts/scheduling-eviction/scheduling-framework/. Accessed: 2024-2-10

    2024

  12. [20]

    Tom Scogland. 2025. flux-core·Discussion #5785

    2025

  13. [21]

    Jon Simon. 2026. Quantum Technologies. https://setr.stanford.edu/technology/ quantum-technologies/2026. Accessed: 2026-6-23

    2026

  14. [22]

    Vanessa Sochat. 2026. fluence: Kubernetes custom scheduler plugin using Flux Framework, with support for quantum devices

    2026

  15. [23]

    Vanessa Sochat. 2026. kubectl-fluence: A kubectl plugin for interacting with the Fluence scheduler. https://github.com/converged-computing/kubectl-fluence

    2026

  16. [24]

    Vanessa Sochat, Aldo Culquicondor, Antonio Ojea, and Daniel Milroy. 2024. The Flux Operator.F1000Res.13, 203 (March 2024), 203

    2024

  17. [25]

    Vanessa Sochat, Daniel Milroy, Abhik Sarkar, Aniruddha Marathe, and Tapasya Patki. 2025. Usability Evaluation of Cloud for HPC Applications. InProceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis (...

    2025 doi

  18. [26]

    Vlad Stirbu, Otso Kinanen, Majid Haghparast, and Tommi Mikkonen. 2024. Qu- bernetes: Towards a unified cloud-native execution platform for hybrid classic- quantum computing.arXiv [quant-ph](July 2024)

    2024

  19. [27]

    Mar Tejedor, Michele Grossi, Cenk Tüysüz, Ricardo Rocha, and Sofia Vallecorsa

  20. [2026]

    Kubernetes-Orchestrated Hybrid Quantum-Classical Workflows.arXiv [quant-ph](March 2026)

    2026

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.