Pith. sign in

REVIEW 3 major objections 5 minor 28 references

Alps, a versatile research infrastructure

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

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

Pith's one-line read The paper claims that a supercomputer whose every resource is a network endpoint can host many independent, custom software-defined clusters without virtualization.

desk verdict New material is the operational model, not the vCluster; a candid experience report with real gaps in quantitative evidence on isolation. read the letter →

arxiv 2507.02404 v1 pith:23A4LL5E submitted 2025-07-03 cs.DC

Maxime Martinasso , Mark Klein , Thomas C. Schulthess This is my paper · ORCID
classification cs.DC
keywords high-performancecomputingcloudsoftware-definedclustervSlingshotnetworkmulti-tenantHPCGitOpsresearchinfrastructure
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

Traditional high-performance computers are delivered as one vertically integrated stack: a single vendor image, one batch scheduler, one set of libraries, and upgrades that force every user to rebuild. The paper argues that this model breaks down when different scientific communities need different software stacks, schedulers, and access patterns. Its remedy, the Alps infrastructure, is built on a simple principle: every resource is an endpoint in a global high-speed network, and resources are grouped into independent clusters. Those clusters, called vClusters, are defined by versioned human-readable recipes, deployed through automated pipelines, and immutable once running. If this works, a single shared HPC machine can host independent cloud-like platforms for numerical weather prediction, AI, and general science without virtualization.

What carries the argument

The load-bearing object is the vCluster, a software-defined cluster composed of a resource plane (compute nodes plus a vService orchestrator) and a service plane (a Kubernetes cluster for daemons like the Slurm controller). Isolation comes from network segregation with VLANs and PKEYs enforced at the switch level on the Slingshot interconnect, letting node groups behave like independent tenants. Declarative Git manifests, integration and production pipelines, and a tool called Manta that abstracts the underlying management plane make the cluster immutable and reproducible; user environments are delivered by uenv for building one's own stack and by container engines like Enroot and Podman for bringing one's own stack.

What would settle it

Run two production vClusters side by side on the same hardware, one executing a bandwidth-sensitive MPI job and one generating heavy broadcast traffic, and measure the first job's throughput and latency against a dedicated-machine baseline; any measurable degradation attributable to tenant contention, or any successful cross-tenant network access attempt, would invalidate the paper's core isolation claim.

Watch

Extended reading notes

Core claim

The central claim is that the usual reason for virtualization in cloud computing—isolation between tenants—can be achieved in HPC by network-level segregation instead. On Alps, compute nodes, GPUs, and storage are network endpoints managed by a control plane, and nodes are labeled and grouped into vClusters. A vCluster is a software-defined cluster whose entire configuration lives in Git manifests listing vServices, each pinned to a repository and version; an integration pipeline tests a temporary miniature version of the cluster, and a production pipeline then deploys it. The authors report that 16 vClusters run this way, with about 10 to 20 services per cluster, and that platforms built on them serve production weather forecasting, AI training on about 1,300 GH200 nodes, and other communities. The result they are trying to establish is that composability and independent service evolution can be delivered on shared HPC hardware without a performance penalty from virtualization.

Load-bearing premise

The load-bearing premise is that network-level segregation, using VLANs and PKEYs enforced at the switch, keeps independent clusters isolated and fast enough that virtualization is unnecessary; if cross-tenant traffic leaks or slows down, the promised cloud versatility without virtualization collapses.

Editorial extensions

If this is right

  • A vCluster can be updated by changing a Git manifest and running the integration pipeline first, making rolling updates without full-machine downtime the normal path.
  • Each scientific community can run its own scheduler, its own programming environment, and its own system-level configuration on the same physical machine, which was previously near-impossible.
  • Because recipes are versioned and pipelines are automated, a platform can be replicated or recovered on another hardware site, as illustrated by the weather platform's disaster-recovery setup.
  • Operational staffing shifts from system administration to software engineering, with end-to-end ownership by cross-functional teams.
  • The same vCluster model can be offered as open source and adopted by other centres, turning one site's infrastructure into a community asset.

Reading between the lines

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

  • If the network-isolation premise holds, the next plausible step is federated multi-site vClusters, where the same recipe deploys an identical cluster on several physically separated machines and on cloud providers.
  • The greatest unrecognized risk may be operational, not technical: layered abstractions make runtime debugging harder, and the paper itself notes that troubleshooting automation failures is still difficult; a production incident in one vCluster could expose how much cross-cluster interference remains.
  • A testable extension would be to quantify the performance cost of PKEY and VLAN segregation under adversarial traffic patterns, since the paper asserts isolation capability but offers no benchmark comparing segregated and dedicated networks.
  • The economics are not yet settled: the paper notes that small community-specific vClusters are expensive to maintain without reuse, so the model's long-term viability depends on cross-domain standardization, not just automation.
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 describes the architecture, operational model, and current deployment of CSCS's Alps HPC infrastructure. The central claim is that by treating every resource as a network endpoint and grouping resources into versioned, GitOps-defined vClusters, a single heterogeneous HPC system can host multiple independent scientific platforms with cloud-like flexibility and composability, without relying on virtualization. The authors describe the three-layer vCluster abstraction (Infrastructure as Code, Service Management, User Environments), the organizational restructuring into cross-functional Working Structures, and the current platforms (MeteoSwiss NWP, PSI, user lab, Swiss AI, EXCLAIM, and several under development). The paper also discusses operational experience, automation, and the trade-off between versatility and complexity, and it commits to open-sourcing the vCluster technology.

Significance. If the vCluster claims hold, the paper describes an important and broadly reusable operational blueprint for converged HPC/cloud infrastructure: 16 vClusters, roughly 900 merge requests, heterogeneous nodes including the first large-scale GH200 deployment, and production SLAs for time-critical weather prediction are nontrivial evidence of feasibility. The paper is also honest about the costs of versatility, explicitly acknowledging in Section 7 the cognitive load, coordination overhead, and maintenance expense of small vClusters. Its main weakness is that the load-bearing assertions about isolation, performance, and manageable operational complexity are supported by architecture description and anecdote rather than by measurements, leaving the reader unable to verify that the no-virtualization approach delivers what the paper promises.

major comments (3)
  1. [Sec. 4.1.2] The claim that vClusters provide independent, isolated platforms without virtualization rests on the assertion in Section 4.1.2 that network segregation using VLANs and PKEYs 'ensuring network isolation of the booted nodes.' This is a reachability-isolation claim, not a performance-isolation or security claim. No measurements or arguments are given that a tenant saturating the shared Slingshot fabric cannot perturb latency or bandwidth in another vCluster. This matters directly for the paper's strongest use case: Section 6.1 describes MeteoSwiss running time-critical NWP under strict SLAs on the same infrastructure as the 1,300-GH200 Swiss AI platform described in Section 6.4. The authors should provide (a) cross-vCluster MPI latency/bandwidth measurements under controlled background traffic, and (b) a test showing that a misconfigured or compromised vCluster cannot reach another partition. Without such evidence, the 'no virtualization needed' conclusion is unsupported.
  2. [Secs. 3.3, 5, and 7.1] The paper's operational objectives include 'reducing engineering costs' (Section 3.3) and the organizational narrative in Section 5 presents the Working Structures model as the answer to increased operational complexity, yet no quantitative evidence is provided: there is no baseline staffing comparison with the Piz Daint era, no person-hours per platform, no deployment-time metrics, and no incident or downtime statistics. Section 7.1 explicitly concedes that 'smaller or community-specific vClusters can be expensive to maintain unless there is reuse across domains or automation reaches a sufficient level of maturity.' As an experience report this is candid, but the claim that vCluster technology manages complexity without disproportionate growth in engineering staff remains an unmeasured assertion. The authors should add even a small set of operational metrics (e.g., release cadence, mean time to deploy a new vCluster, number of incidents per platform per quarter) to support the central cost-complexity trade-off.
  3. [Sec. 7.3] The paper highlights rolling updates and 'zero-downtime updates' as a major benefit over traditional HPC operations, stating that new services can be deployed 'without taking the HPC system offline or blocking user access.' No data are provided on actual update durations, user-visible interruptions, or rollback success rates. Since this is one of the paper's most concrete advantages over the monolithic model criticized in Section 2.3, the authors should report at least representative examples of update timelines and rollback incidents, or explicitly label this claim as an aspiration. Without such data, the comparison in Section 7.3 between Alps and the historical downtime-heavy model is not yet substantiated.
minor comments (5)
  1. [Sec. 4.2.1] The manuscript states that 'during the past two years' the teams generated approximately 900 merge requests, and that 16 vClusters are currently operating, but it does not give the observation period for the 16-vCluster count or the distribution of merge requests over time; please clarify the dates and the criteria for counting a vCluster as 'operating.'
  2. [Sec. 5.1 and Fig. 5] Figure 5 reports 'approximately 100 engineers' in the Engineering Quadrant, while Section 5.1 states that two legacy teams each had roughly 20 engineers; the reader cannot infer whether the new model uses more or fewer engineers, so an explicit headcount comparison would strengthen the operational-cost discussion.
  3. [Sec. 4.1.2] Reference [13] for PKEYs is an IP over InfiniBand RFC; for the Slingshot-specific claim, the paper should cite Slingshot documentation or a measurement study rather than relying on the InfiniBand RFC.
  4. [Sec. 8] Section 8 refers to 'the Material Clouds platform' while Section 6.6 uses 'Materials Cloud'; please make the naming consistent.
  5. [Sec. 7.4] The paper commits to providing the vCluster technology as open-source software and forming a consortium, but no repository, license, or planned release timeline is given; adding a reference would make the sustainability claim more concrete and verifiable.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Alps is a descriptive systems/experience report with no fitted parameters, derived predictions, or equations that reduce to inputs.

full rationale

This paper is a systems and operations description, not a derivation. It presents the Alps infrastructure, the vCluster architecture, and CSCS's organizational transformation, supported by deployed artifacts: the HPL benchmark of 434 PFlops, the Top500 ranking, the table of current node composition, the count of 16 operating vClusters, the roughly 900 merge requests, and the example platform deployments (MeteoSwiss, PSI, Swiss AI, EXCLAIM). These are externally observable facts about a running system rather than conclusions derived from assumptions. The self-citations to the authors' prior vCluster papers [1, 17] are contextual references to the same technology being described, not load-bearing evidence for a mathematical or empirical claim, and no uniqueness theorem or fitted parameter is imported from them. The central premise that VLAN/PKEY segregation provides necessary network isolation is asserted rather than measured, but this is an empirical validation gap, not a circularity: the paper does not define isolation in terms of its own conclusion, nor does it rename the asserted premise as a prediction. The paper explicitly acknowledges limitations such as increased operational complexity, hidden costs of automation, and sustainability concerns in Sections 7.1, 7.2, and 7.4, which further supports that the authors are reporting experience rather than presenting a self-justifying derivation. No circular step can be exhibited from the text, so the appropriate score is 0.

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

The paper's central claims rest on the availability and correctness of several external technologies (Slingshot network isolation, CSM/OpenCHAMI, Nomad, Kubernetes, Cloud-init, ReFrame) and on the assumption that organizational restructuring can absorb the added operational complexity. None of these are established quantitatively in the paper, though they are reasonable domain assumptions.

assumptions (5)
  • domain assumption The Slingshot network supports switch-level isolation via PKEYs and VLANs without significant performance cost.
    Invoked in Section 4.1.2 to support resource segregation between vClusters; performance implications are not measured in the paper.
  • domain assumption The HPE Cray System Management (CSM) and OpenCHAMI provide APIs for labeling and managing compute nodes at scale.
    Section 4.1.1 relies on these control planes to group nodes into vClusters; the paper cites vendor documentation but does not verify this capability.
  • domain assumption The vService orchestrator (Nomad) and Kubernetes can reliably manage service lifecycles across HPC nodes.
    Sections 4.2.2 and 4.2.3 assume these tools work reliably in an HPC context; the paper reports operational experience but no quantitative reliability data.
  • domain assumption Cloud-init can reliably bootstrap nodes with the required vService orchestrator clients.
    Section 4.2.2 depends on Cloud-init for node initialization.
  • ad hoc to paper The organizational model (Working Structures, SAFe, end-to-end responsibility) can manage the increased operational complexity without disproportionate growth in engineering staff.
    Section 5 asserts this management model works, but the paper provides no staffing or cost comparison against the traditional model.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Alps, a versatile research infrastructure." pith.science (2026). https://pith.science/paper/23A4LL5E

@misc{pith2026250702404,
  author       = {Pith},
  title        = {Pith review of: Alps, a versatile research infrastructure},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/23A4LL5E}},
  note         = {Machine review of arXiv:2507.02404}
}
read the original abstract

The Swiss National Supercomputing Centre (CSCS) has a long-standing tradition of delivering top-tier high-performance computing systems, exemplified by the Piz Daint supercomputer. However, the increasing diversity of scientific needs has exposed limitations in traditional vertically integrated HPC architectures, which often lack flexibility and composability. To address these challenges, CSCS developed Alps, a next-generation HPC infrastructure designed with a transformative principle: resources operate as independent endpoints within a high-speed network. This architecture enables the creation of independent tenant-specific and platform-specific services, tailored to diverse scientific requirements. Alps incorporates heterogeneous hardware, including CPUs and GPUs, interconnected by a high-performance Slingshot network, and offers a modular storage system. A key innovation is the versatile software-defined cluster (vCluster) technology, which bridges cloud and HPC paradigms. By abstracting infrastructure, service management, and user environments into distinct layers, vClusters allow for customized platforms that support diverse workloads. Current platforms on Alps serve various scientific domains, including numerical weather prediction, and AI research.

Figures

Figures reproduced from arXiv: 2507.02404 by the authors.

Figure 1
Figure 1. The Alps research infrastructure, 2024. ABSTRACT The Swiss National Supercomputing Centre (CSCS) has a long￾standing tradition of delivering top-tier high-performance comput￾ing systems, exemplified by the Piz Daint supercomputer. However, the increasing diversity of scientific needs has exposed limitations in traditional vertically integrated HPC architectures, which often lack flexibility and composability. To add… view at source ↗
Figure 2
Figure 2. The vCluster technology employs a three-layer [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Example of the manifest for the vCluster Daint. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Visual representation of the integration testing and [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: The engineering quadrant consists of 11 teams, com [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Example of platforms running on the Alps infras [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 22 canonical work pages

  1. [1]

    Sadaf R Alam, Miguel Gila, Mark Klein, Maxime Martinasso, and Thomas C Schulthess. 2023. Versatile software-defined HPC and cloud clusters on Alps supercomputer for diverse workflows. The International Journal of High Performance Computing Applications, 37, 3-4, 288–305. eprint: https://doi.org/1 0.1177/10943420231167811. doi: 10.1177/10943420231167811

    doi:10.1177/10943420231167811 2023

  2. [2]

    Cruz, Alberto Madonna, and Kean Mariotti

    Lucas Benedicic, Felipe A. Cruz, Alberto Madonna, and Kean Mariotti. 2019. Sarus: highly scalable docker containers for HPC systems. In High Performance Computing. Michèle Weiland, Guido Juckeland, Sadaf Alam, and Heike Jagode, (Eds.) Springer International Publishing, Cham, 46–60. isbn: 978-3-030-34356-9. https://doi.org/10.1007/978-3-030-34356-9_5

    work page doi:10.1007/978-3-030-34356-9_5 2019

  3. [3]

    Schultess

    Mauro Bianco, Matthias Kraushaar, Roberto Aielli, Oliver Fuhrer, and Thomas C. Schultess. 2025. Redefining Weather Forecasting Systems: The Transition to ICON and Alps. In Proceedings of the Cray User Group Conference (CUG 2025) . To be published. Cray User Group. New Jersey, USA, (May 2025)

    work page 2025

  4. [4]

    Jonathan Coles, Benjamin Cumming, Theofilos-Ioannis Manitaras, Piccinali Jean-Guillaume, Simon Pintarelli, and Harmen Stoppels. 2023. Deploying Al- ternative User Environments on Alps. CUG 2023, 0, 0

    work page 2023

  5. [5]

    Cruz, Manuel Sopena Ballesteros, and Alejandro J

    Felipe A. Cruz, Manuel Sopena Ballesteros, and Alejandro J. Dabin. 2023. De- ploying Cloud-Native HPC Clusters on HPE Cray EX. In Proceedings of the Cray User Group (CUG) Conference . https://cug.org/proceedings/cug2023_proc eedings/includes/files/pap131s2-file1.pdf

    work page 2023

  6. [6]

    Cruz, Alejandro J

    Felipe A. Cruz, Alejandro J. Dabin, Juan P. Dorsch, Eirini Koutsaniti, and Nelson F. Lezcano. 2020. FirecREST: A RESTful API to HPC systems. en. In 2020 IEEE/ACM International Workshop on Interoperability of Supercomputing and Cloud Technologies (SuperCompCloud). IEEE, Piscataway, NJ, 21–26. isbn: 978-0-7381-1055-4. doi: 10.1109/SuperCompCloud51944.2020.00009

    work page arXiv 2020

  7. [7]

    Google. 2023. Cluster Toolkit. (accessed on 2 April 2025). https://cloud.google .com/cluster-toolkit/docs

    work page 2023

  8. [8]

    HashiCorp. 2023. Automate infrastructure on any cloud with Terraform. (ac- cessed on 14 January 2025). https://www.terraform.io

    work page 2023

Show all 28 references
  1. [9]

    HashiCorp. 2025. Nomad: a simple and flexible scheduler for clustered ap- plications. https://developer.hashicorp.com/nomad. Accessed: 2025-04-03. (2025)

    2025

  2. [10]

    Hewlett Packard Enterprise. 2023. Cray system management documentation. (accessed on 14 January 2025). https://cray-hpe.github.io/docs-csm/en-13/

    2023

  3. [11]

    IEEE. 2022. IEEE Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks. (2022). doi: 10.1109/IEEESTD.2022.10004498

    2022

  4. [12]

    Vasileios Karakasis et al. 2020. Enabling continuous testing of HPC systems using ReFrame. In Tools and Techniques for High Performance Computing (Com- munications in Computer and Information Science). HUST - Annual Workshop on HPC User Support Tools (Denver, Colorado, USA, No...

    2020 doi

  5. [13]

    Vivek Kashyap. 2006. IP over InfiniBand (IPoIB) Architecture. RFC 4392. (Apr. 2006). doi: 10.17487/RFC4392

    2006 doi

  6. [14]

    Canonical Ltd. 2025. Cloud-Init: the standard for cloud instance initialization. https://cloud-init.io/. Accessed: 2025-04-03. (2025)

    2025

  7. [15]

    Alberto Madonna and Tomas Aliaga. 2022. Libfabric-based injection solutions for portable containerized MPI applications. In 4th IEEE/ACM International Workshop on Containers and New Orchestration Paradigms for Isolated Environ- ments in HPC, CANOPIE-HPC@SC 2022, Dallas, TX, US...

    2022

  8. [16]

    Riccardo Di Maria et al. 2025. Infrastructure as a service with strong tenant separation on a supercomputer. InProceedings of the Cray User Group Conference (CUG 2025). To be published. Cray User Group. New Jersey, USA, (May 2025)

    2025

  9. [17]

    Cruz, Alberto Madonna, Manuel Sopena Ballesteros, Sadaf R

    Maxime Martinasso, Mark Klein, Benjamin Cumming, Miguel Gila, Felipe A. Cruz, Alberto Madonna, Manuel Sopena Ballesteros, Sadaf R. Alam, and Thomas C. Schulthess. 2024. Versatile software-defined cluster for HPC using cloud abstractions. Comput. Sci. Eng., 26, 3, 20–29. doi: 1...

    2024

  10. [18]

    Alam, and Christopher J

    Simon McIntosh-Smith, Sadaf R. Alam, and Christopher J. Woods. 2024. Isambard- AI: a leadership class supercomputer optimised specifically for Artificial Intel- ligence. CoRR, abs/2410.11199. arXiv: 2410.11199. doi: 10.48550/ARXIV.2410.11 199

    2024 doi arXiv

  11. [19]

    OpenCHAMI. 2023. OpenCHAMI: Composable, HPC System Management for cloud-like operations. (accessed on 14 January 2025). https://openchami.org

    2023

  12. [20]

    OpenStack foundation. 2017. The Crossroads of Cloud and HPC: OpenStack for Scientific Research: Exploring OpenStack cloud computing for scientific workloads . CreateSpace Independent Publishing Platform, Scotts Valley, California, US. https://object-storage-ca-ymq-1.vexxhost.n...

    2017

  13. [21]

    The Argo Project. 2025. Argo CD: declarative, GitOps continuous delivery for Kubernetes. https://argo-cd.readthedocs.io/. Accessed: 2025-04-03. (2025)

    2025

  14. [22]

    Scaled Agile, Inc. 2025. SAFe Program Increment (PI) Planning . Available at https://scaledagileframework.com/pi-planning/, Accessed: 2025-04-03

    2025

  15. [23]

    Schuppli et al

    S. Schuppli et al. 2025. Evolving HPC services to enable ML workloads on HPE Cray EX. In Proceedings of the Cray User Group Conference (CUG 2025) . To be published. Cray User Group. New Jersey, USA, (May 2025)

    2025

  16. [24]

    McMahon, Duncan Roweth, and Torsten Hoefler

    Daniele De Sensi, Salvatore Di Girolamo, Kim H. McMahon, Duncan Roweth, and Torsten Hoefler. 2020. An In-Depth Analysis of the Slingshot Interconnect. CoRR, abs/2008.08886. https://arxiv.org/abs/2008.08886 arXiv: 2008.08886

    2020 arXiv

  17. [25]

    EXCLAIM Project Team. 2025. EXCLAIM: Exascale Computing Platform for Cloud-Resolving Weather and Climate Models. https : / / exclaim . ethz . ch/. Accessed: 2025-04-05. (2025)

    2025

  18. [26]

    The Swiss National Supercomputing Centre. 2021. Alps research infrastructure. (accessed on 14 January 2025). https://www.cscs.ch/science/computer-science- hpc/2021/cscs-hewlett-packard-enterprise-and-nvidia-announce-worlds-m ost-powerful-ai-capable-supercomputer

    2021

  19. [27]

    The Swiss National Supercomputing Centre. 2023. Another CLI tools for Alps. (accessed on 14 January 2025). https://github.com/eth-cscs/manta

    2023

  20. [28]

    Naweiluo Zhou, Huan Zhou, and Dennis Hoppe. 2023. Containerization for high performance computing systems: survey and prospects. IEEE Transactions on Software Engineering, 49, 4, 2722–2740. https://doi.ieeecomputersociety.org /10.1109/TSE.2022.3229221

    2023

Pith tools

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