Evolving HPC services to enable ML workloads on HPE Cray EX

Dino Conciatore; Elia Palme; Fawzi Mohamed; Henrique Mendon\c{c}a; Joost VandeVondele; Lukas Drescher; Maxime Martinasso; Miguel Gila; Nina Mujkanovic; Pim Witlox

REVIEW 2 major objections 6 minor 33 references

Evolving HPC services to enable ML workloads on HPE Cray EX

T0 review · 2 major / 6 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 This paper proposes a modular service layer—container environments, a GPU saturation scorer, observability, node vetting, a Kubernetes service plane, and tiered storage—so that a conventional HPC centre can serve the full ML lifecycle on…

desk verdict A useful, honest roadmap from CSCS on adapting HPC services for ML; the GPU saturation scorer is the weakest link because it is presented as a contribution without validation. read the letter →

arxiv 2507.01880 v1 pith:VQDYYAZQ submitted 2025-07-02 cs.DC cs.LG

Stefano Schuppli , Fawzi Mohamed , Henrique Mendonça , Nina Mujkanovic , Elia Palme , Dino Conciatore , Lukas Drescher , Miguel Gila

show 5 more authors

Pim Witlox Joost VandeVondele Maxime Martinasso Thomas C. Schulthess Torsten Hoefler

This is my paper

classification cs.DCcs.LG

keywords HPCmachinelearningworkloadscontainerenvironmentsGPUsaturationscorerobservabilitynodevettingKubernetesserviceplanetieredstorage

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 is an initial report from the team operating the Alps supercomputer, a 10,752-GPU Grace-Hopper system, on how they are extending conventional HPC services for machine-learning users. It argues that batch schedulers and parallel file systems alone do not fit the full ML lifecycle, and proposes six modular components: container-defined user environments, a GPU saturation scorer, infrastructure observability, node vetting with early abort, a Kubernetes service plane, and tiered storage. The authors ground each proposal in gaps observed since 2023 with the national AI community, and frame the whole suite as operationalizing expertise so that less experienced ML users can be productive on expensive hardware. If the proposals work as described, they would lower the barrier to using HPC for ML while keeping the system resilient and easier to operate for a publicly funded centre with limited staff.

What carries the argument

The central mechanism is the vCluster service architecture, software-defined clusters that group compute and data resources into per-community service platforms with declarative service definitions. Each of the six proposals is packaged as a service that runs on such a cluster, so the argument is that the same infrastructure serving traditional HPC can dynamically host ML-specific services. Within that suite, the paper singles out the GPU saturation scorer as a fundamental contribution: it wraps the GPU telemetry daemon's many metrics into a unique GPU group per distributed job and aggregates selected metrics into one score, with a performance model from prior work guiding the aggregation.

What would settle it

Run a set of training workloads with known, deliberately varied inefficiencies on the same node type, record the scorer's output and the actual iterations per second, and check whether the score ranks workloads the same way the measured throughput does; if two workloads with equal high scores differ markedly in realized speed, the aggregation is falsified.

Watch

Extended reading notes

Core claim

The paper's claim is that a conventional HPC centre can serve the ML community without abandoning HPC, by adding a deliberately modular service layer on top of software-defined clusters. Each component is a response to a documented pain point: an Environment Definition File lets users run jobs inside familiar container images without learning image building; a GPU saturation scorer turns GPU telemetry into a single digestible score so users are not fooled by the temporal utilization number; job-scoped observability dashboards correlate ranks, GPUs, network topology, and optional user metrics to expose stragglers; a node vetting and early abort system checks large allocations for dirty GPUs, high temperatures, or slow collectives before training starts; a hybrid Kubernetes service plane runs supporting and inference services on virtual machines plus HPC GPU nodes while keeping HPC nodes firewalled; and tiered storage combines fast tiers, object storage, parallel-file-system tuning, and compressed read-only filesystems to match the I/O phases of ML. The authors present this as a directional, ongoing exploration rather than a validated solution.

Load-bearing premise

The GPU saturation scorer's advice is only as trustworthy as the assumption that a small set of telemetry metrics, combined into one score with weights the paper does not derive, orders workloads by true efficiency; no validation in the paper shows a higher score means faster training.

Editorial extensions

If this is right

Container-defined environments lower the HPC entry barrier for ML users who already work with containers, while keeping vendor-tuned performance through injected hooks.
A simple GPU saturation score gives users a first-order check of whether their GPUs are truly loaded, so they can investigate before launching deep profiling.
Job-scoped observability dashboards let users spot stragglers and network-placement problems they would otherwise only notice after lost training time.
Vetting nodes before large runs reduces the chance that a single unhealthy GPU ruins an expensive distributed training job.
A Kubernetes-based service plane lets teams run experiment tracking and inference services next to HPC training, with a path to port deployments elsewhere.

Reading between the lines

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

The real test the paper leaves open is whether these services measurably reduce time-to-productivity or improve achieved throughput; the authors report design rationale and early use, not controlled measurements.
The same pattern of operationalizing expert debugging could be applied beyond ML, for example to MPI communication faults or file-system anomalies, since the observability and vetting components are largely workload-agnostic.
If the service plane matures, the boundary between HPC and cloud for ML will blur further: training on the batch scheduler, lifecycle services on Kubernetes, with storage tiering as the bridge; the paper gestures at this convergence without claiming it.
A natural next validation for the scorer is a public benchmark correlating its output with time-per-iteration across a few model architectures, which would settle whether the aggregation weights are sound.

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.

Desk Editor's Note

read the letter

This is a practice paper from the CSCS operations team, not a research preprint with empirical claims. Read it for what it is: a concrete, candid account of how one major HPC center is adapting its services for the ML community. The value is in the specific integration into Alps — the Environment Definition File, the Node Vetting Protocol, the hybrid Kubernetes service plane design, and the tiered storage strategy. Individually these ideas have precedents, but the paper gives enough concrete detail (listings, component diagrams, security discussion) to be a useful reference for other centers doing similar work.

The paper is honest about its status: it repeatedly says this is an initial investigation and directional steps, not a final answer. That self-awareness makes the one overclaim stand out. Section 3.2.3 calls the aggregation of DCGM metrics into a saturation score the "fundamental contribution," but no weights or derivation are given, and no validation shows that a higher score corresponds to faster training. Figure 2 even demonstrates that changing the weights changes the output. The authors do say in 3.2.4 that a performance model should be derived, so they know it is unfinished. For a tool aimed at novice users who might take the score at face value, this needs calibration before it should be trusted. That is a real soft spot, but not fatal for a roadmap paper. The other soft spots are minor: Figure 6 attributes a training throughput drop to asynchronous checkpointing based on one illustrative observation, and the claim that DCGM was the most suitable base tool relies on an "analysis" that is not shown.

Overall, the paper does not oversell itself. It is a well-structured engineering proposal with clear motivations, and the citation pattern is appropriate — the self-citations to vClusters, EMOI, and uenv are background, not load-bearing derivations. The reader's UNVERDICTED label is fair if you demand empirical claims, but for a practitioner venue like CUG this is exactly the kind of paper that deserves referee time. I would send it to peer review and accept it with minor revisions, mainly asking the authors to tone down the "fundamental contribution" language or add a pilot validation of the scorer. If I were running an HPC service team, I would read this paper and steal some of its ideas.

Referee Report

2 major / 6 minor

Summary. The paper reports on CSCS's ongoing effort to adapt the Alps Research Infrastructure (HPE Cray EX, 10,752 GH200 GPUs) to ML workloads. It catalogs seven areas of work: container-based user environments with Environment Definition Files, a GPU saturation scorer built on DCGM, an observability stack for job-scoped telemetry, a node vetting and early abort system, a hybrid Kubernetes service plane for supporting and inference services, a multi-tier storage strategy, and security practices. Each section motivates the component, describes its design, states ongoing or future work, and maps it back to the challenges identified in Section 2. The paper is explicitly positioned as an initial investigation and acknowledges the absence of a comprehensive framework for rigorously evaluating user needs and solution options.

Significance. The paper's value is as a system and experience report from a major HPC center that is actively evolving its production infrastructure for ML users. If the described tools deliver what is claimed, they would plausibly reduce onboarding burden, improve workload insight, and increase resilience for ML training on Alps, and the modular decomposition (EDF, scorer, observability, vetting, service plane, storage) offers a useful template for peer institutions. Strengths include the concrete production context, the reuse of established building blocks (DCGM, EMOI, RKE2, ArgoCD, Ceph), and the candid statement of limitations. However, the paper contains no quantitative validation: no adoption metrics, throughput measurements, or reliability comparisons, and the component labeled the 'fundamental contribution' has no derived weights and no calibration against achieved performance. The significance of the proposals is therefore conditional on the next round of validation or on an explicit reframing as a position paper.

major comments (2)

[§3.2.3–§3.2.4, Figure 2] The paper describes the 'meaningful aggregation of carefully selected metrics' as the fundamental contribution of the GPU saturation scorer, but it gives no derivation of the aggregation weights and states in §3.2.4 that a performance model should be derived as future work. Figure 2's own caption observes that placing more weight on memory or compute produces differing plots, so the score is not fixed by the data. Because the tool targets users who cannot interpret raw DCGM metrics, an uncalibrated score could reinforce the stable-high-utilization misconception identified in §3.2.1. To support the central productivity claim, the paper should validate the score (e.g., show that known code regressions lower it and that it correlates with end-to-end iteration time) or reframe the scorer as an illustrative prototype and drop the 'fundamental contribution' claim.
[§3.6.3, Figure 6] The claim that asynchronous checkpointing causes consistent temporary training-throughput drops is supported only by a single qualitative illustration. No workload, system state, number of runs, or measurement procedure is reported, and the text itself says only that the figure 'illustrates an example of such situation.' As presented, the observation cannot distinguish a systematic checkpointing effect from noise or contention. Support it with a small controlled measurement (throughput traces with and without asynchronous checkpointing) or explicitly label it as an anecdotal motivation rather than evidence.

minor comments (6)

[§3.2.1] The sentence 'In 2011, the second fastest and three of the top ten supercomputers were GPU-powered' should read 'the second-fastest supercomputer and three of the top ten supercomputers'.
[Listing 1 / §3.1.3] The token 'au th or iz e_s sh _k ey' appears to be a corrupted rendering of the key name, and the pointer to 'Line 12' does not match the SSH annotation shown on lines 14–16.
[Listing 3 / §3.4.2] The example threshold 'max_temp: 30 # (celsius)' is far below normal GPU operating temperatures; even as an illustrative value it should be accompanied by a comment explaining that it is a deliberately strict example.
[Figure 6 / §3.6.3] Figure 6 has no axis labels and no description of the workload or system configuration; please add them so the plot can be interpreted.
[§3.2.2] The sentence 'our analysis of different possible approaches identified DCGM as the most suitable base tool candidate' is not backed by any presented analysis; either cite a technical report or describe the comparison criteria.
[References / §3.2.3] Reference [12] is an agenda URL with no stable DOI; if a technical report or proceedings version exists, citing it would make the dependency on the performance model verifiable.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is a systems proposal with no fitted derivation, and the unvalidated GPU saturation scorer is an evidence gap rather than a circular step.

full rationale

This paper is a proposal and experience report describing HPC service components; it contains no fitted parameters, no equations, and no derivation claimed from first principles. The GPU saturation scorer in Section 3.2 is presented as a tool design, and the paper explicitly states in Section 3.2.4 that 'A performance model should be derived from these metrics', so no fitted weights are derived and then relabeled as a prediction. The reference to Ferrari et al. [12] for 'performance modeling' is a pointer to related work; although one author overlaps (Nina Mujkanovic), the paper's central claims about service enhancements do not rest on that citation, and the scorer's utility is argued from observed user pain points rather than from the model's output. Self-citations to vClusters [1,19], uenv [8], and EMOI [4] describe prior CSCS infrastructure used as context, not as proof of the present proposals. The absence of calibration of the saturation score against training throughput is a real evidence gap and an unsupported load-bearing assumption, but it is not circularity under the definitions used here: no quantity is defined in terms of the quantity it is used to predict, and no fitted input is called a prediction. Therefore no circular step can be quoted with a specific reduction, and the honest finding is no significant circularity.

Assumptions & free parameters 2 free parameters · 4 assumptions · 4 invented entities

The proposed service enhancements introduce several new artifacts (EDF, saturation scorer, vetting protocol, Kubernetes service plane) whose effectiveness is not benchmarked. The only free parameters are example thresholds in the vetting protocol and the unstated aggregation weights in the saturation score model.

free parameters (2)

GPU saturation score aggregation weights
Section 3.2.3/Figure 2: 'Placing more weight on memory or compute data may produce differing plots'; the default weights are not published or justified.
Node vetting thresholds = max_temp: 30 C, min_bandwidth: 90 GB/s (example)
Listing 3 gives example tolerances for GPU temperature and NCCL bandwidth; selection criteria for these thresholds are not given.

assumptions (4)

domain assumption DCGM is a valid and low-overhead source for GPU performance metrics.
Section 3.2.2 states 'our analysis identified DCGM as the most suitable base tool candidate' but the analysis is not shown.
domain assumption A small number of aggregated metrics can guide non-expert users to optimize GPU usage.
Section 3.2.3 and Figure 2 assume the aggregate score is informative; no evidence provided.
domain assumption ML users require container-based environments and Kubernetes-style deployment to be productive.
Section 3.1.1 and 3.5.2 treat this as given from vendor trends and community practices.
domain assumption Parallel file systems are inadequate for the small random reads in ML data loading.
Section 3.6.1 makes this claim qualitatively; no benchmark of Lustre on Alps is given.

invented entities (4)

Environment Definition File (EDF)
purpose: TOML file that wraps container configuration for job submission
Introduced in Section 3.1.3; no user study or evaluation of its usability.
GPU saturation scorer
purpose: CLI tool that aggregates DCGM metrics into a single efficiency score
Section 3.2; screenshots only, no validation against end-to-end training time.
Node Vetting Protocol
purpose: YAML test suites to check allocated nodes before large jobs
Section 3.4.2; no false-positive rate or overhead measurement.
Hybrid Kubernetes service plane
purpose: Deploy inference and support services on VMs plus HPC nodes
Section 3.5; architecture diagram but no deployment or workload measurements.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Evolving HPC services to enable ML workloads on HPE Cray EX." pith.science (2026). https://pith.science/paper/VQDYYAZQ

@misc{pith2026250701880,
  author       = {Pith},
  title        = {Pith review of: Evolving HPC services to enable ML workloads on HPE Cray EX},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VQDYYAZQ}},
  note         = {Machine review of arXiv:2507.01880}
}

read the original abstract

The Alps Research Infrastructure leverages GH200 technology at scale, featuring 10,752 GPUs. Accessing Alps provides a significant computational advantage for researchers in Artificial Intelligence (AI) and Machine Learning (ML). While Alps serves a broad range of scientific communities, traditional HPC services alone are not sufficient to meet the dynamic needs of the ML community. This paper presents an initial investigation into extending HPC service capabilities to better support ML workloads. We identify key challenges and gaps we have observed since the early-access phase (2023) of Alps by the Swiss AI community and propose several technological enhancements. These include a user environment designed to facilitate the adoption of HPC for ML workloads, balancing performance with flexibility; a utility for rapid performance screening of ML applications during development; observability capabilities and data products for inspecting ongoing large-scale ML workloads; a utility to simplify the vetting of allocated nodes for compute readiness; a service plane infrastructure to deploy various types of workloads, including support and inference services; and a storage infrastructure tailored to the specific needs of ML workloads. These enhancements aim to facilitate the execution of ML workloads on HPC systems, increase system usability and resilience, and better align with the needs of the ML community. We also discuss our current approach to security aspects. This paper concludes by placing these proposals in the broader context of changes in the communities served by HPC infrastructure like ours.

Figures

Figures reproduced from arXiv: 2507.01880 by the authors.

**Figure 2.** The previous GPU Activity Time Series plots can [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** The proof of concept of a web interface meant for [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Components overview for the nodes vetting and [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: Hybrid Kubernetes service plane integrating virtu [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

**Figure 6.** Figure 6: While beneficial to the rapid resumption of training [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

33 extracted references · 24 canonical work pages

[1]

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

work page doi:10.1177/10943 2023
[2]

María Arsuaga-Ríos, Seppo S Heikkilä, Dirk Duellmann, René Meusel, Jakob Blomer, and Ben Couturier. 2015. Using S3 cloud storage with ROOT and CvmFS . Journal of Physics: Conference Series , 664, 2, (Dec. 2015), 022001. doi: 10.1088/1 742-6596/664/2/022001

doi:10.1088/1 2015
[3]

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

work page 2019
[4]

2024.EMOI: CSCS Extensible Monitoring and Observability Infrastructure

Massimo Benini, Jeff Hanson, Mathilde Gianolli, Jean-Guillaume Piccinali, Michele Brambilla, Gianna Marano, Gianni Mario Ricciardi, Monica Frisoni, and Dino Conciatore. 2024.EMOI: CSCS Extensible Monitoring and Observability Infrastructure. (2024). https://www.research-collection.ethz.ch/handle/20.500.1 1850/702519

work page 2024
[5]

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)

2025
[6]

Paul, and Ali R

Debasmita Biswas, Sarah Neuwirth, Arnab K. Paul, and Ali R. Butt. 2021.Bridg- ing Network and Parallel I/O Research for Improving Data-Intensive Distributed Applications. In2021 IEEE Workshop on Innovating the Network for Data-Intensive Science (INDIS), 50–56. doi: 10.1109/INDIS54524.2021.00011

work page arXiv 2021
[7]

Arthur Chiao. 2023. Understanding GPU Performance: Utilization vs. Saturation . (2023). http://arthurchiao.art/blog/understanding-gpu-performance

work page 2023
[8]

Jonathan Coles, Ben Cumming, Theofilos-Ioannis Manitaras, Jean-Guillaume Piccinali, Simon Pintarelli, and Harmen Stoppels. 2023. Deploying Alternative User Environments on Alps . (2023). https://cug.org/proceedings/cug2023_proce edings/includes/files/pap143s2-file1.pdf

work page 2023

Show all 33 references

[9]

Container Device Interface. 2020. Container Device Interface home page . Re- trieved Accessed: 2025-04-10 from https://github.com/cncf-tags/container-dev ice-interface

2020
[10]

Cruz and Alberto Madonna

Felipe A. Cruz and Alberto Madonna. 2024. Containers-first user environments on HPE Cray EX . In Proceedings of the Cray User Group Conference (CUG 2024) . Cray User Group. (May 2024)

2024
[11]

Cruz and Maxime Martinasso

Felipe A. Cruz and Maxime Martinasso. 2019. FirecREST: RESTful API on Cray XC systems. CoRR, abs/1911.13160. http://arxiv.org/abs/1911.13160 arXiv: 1911.13160

2019 arXiv
[12]

Marcel Ferrari and Nina Mujkanovic. [n. d.] Practical Performance Modeling for Large-Scale Distributed GPU Workloads . https://www.hpcadvisorycouncil.com /events/2025/swiss-conference/agenda.php. Accessed: 2025-04-10. ()

2025
[13]

Collette, Gregory L

Todd Gamblin, Matthew LeGendre, Michael R. Collette, Gregory L. Lee, Adam Moody, Bronis R. de Supinski, and Scott Futral. 2015. The Spack package man- ager: bringing order to HPC software chaos . In SC15: International Conference for High-Performance Computing, Networking, Sto...

2015 doi
[14]

Ziheng Jiang et al. 2024. MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs . (2024). https://arxiv.org/abs/2402.15627 arXiv: 2402.15627 [cs.LG]

2024 arXiv
[15]

Apostolos Kokolis et al. 2024. Revisiting Reliability in Large-Scale Machine Learning Research Clusters . (2024). https://arxiv.org/abs/2410.21680 arXiv: 2410.21680 [cs.DC]

2024 arXiv
[16]

Lockwood

Glenn K. Lockwood. [n. d.] LLM training without a parallel file system . https: //blog.glennklockwood.com/2025/02/llm-training-without-parallel-file.html. Accessed: 2025-04-09. ()

2025
[17]

Phillip Lougher. [n. d.] SquashFS - A compressed read-only filesystem for Linux . https://github.com/plougher/squashfs-tools. Accessed: 2025-04-09. ()

2025
[18]

Ryan Lucchese, Niki Birkner, Yaron Hagai, and Virginia Adams. 2024. A practi- tioner’s guide to testing and running large GPU clusters for training generative AI models. (2024). https://www.together.ai/blog/a-practitioners-guide-to-testi ng-and-running-large-gpu-clusters-for-t...

2024
[19]

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
[20]

Schulthess

Maxime Martinasso, Mark Klein, and Thomas C. Schulthess. 2025. Alps, a versatile research infrastructure. In Proceedings of the Cray User Group Conference (CUG 2025). To be published. Cray User Group. New Jersey, USA, (May 2025)

2025
[21]

Simon McIntosh-Smith. 2011. The GPU Computing Revolution . https://www.lm s.ac.uk/sites/default/files/files/reports/GPU-KT-report-screen.pdf

2011
[22]

2024.AMD now has more compute on the TOP500 than NVIDIA

Timothy Morgan. 2024.AMD now has more compute on the TOP500 than NVIDIA. (2024). https://www.nextplatform.com/2024/11/18/amd-now-has-more-com pute-on-the-top500-than-nvidia/

2024
[23]

Darren Ng, Andrew Lin, Arjun Kashyap, Guanpeng Li, and Xiaoyi Lu. 2024. NVMe-oPF: Designing Efficient Priority Schemes for NVMe-over-Fabrics with Multi-Tenancy Support. In 2024 IEEE International Parallel and Distributed Pro- cessing Symposium (IPDPS), 519–531. doi: 10.1109/IP...

2024
[24]

NVIDIA. [n. d.] DCGM Feature Overview. Accessed: 2025-04-10. (). https://docs .nvidia.com/datacenter/dcgm/latest/user-guide/feature-overview.html

2025
[25]

Team OLMo et al. 2024. 2 OLMo 2 Furious . (2024). https://arxiv.org/abs/2501.00 656 arXiv: 2501.00656 [cs.CL]

2024 arXiv
[26]

Open Container Initiative. 2022. Open Container Initiative home page. Retrieved Accessed: 2025-04-10 from https://www.opencontainers.org/

2022
[27]

Lucas Pasqualin, Less Wright, Iris Zhang, Chien-Chin Huang, Swaminathan Sundararaman, Saransh Gupta, and Raghu Ganti. 2024. Reducing Model Check- pointing Times by Over 10x with PyTorch Distributed Asynchronous Checkpoint- ing. (2024). https://pytorch.org/blog/reducing-checkpo...

2024
[28]

Anton Shilov. 2024. The BLOOM training chronicles . (2024). https://www.toms hardware.com/tech-industry/artificial-intelligence/faulty-nvidia-h100-gpus -and-hbm3-memory-caused-half-of-the-failures-during-llama-3-training-o ne-failure-every-three-hours-for-metas-16384-gpu-train...

2024
[29]

2024.Gemini: A Family of Highly Capable Multimodal Models

Gemini Team et al. 2024.Gemini: A Family of Highly Capable Multimodal Models. (2024). https://arxiv.org/abs/2312.11805 arXiv: 2312.11805 [cs.CL]

2024 arXiv
[30]

Imbue Team. 2024. From bare metal to a 70B model: infrastructure set-up and scripts. (2024). https://imbue.com/research/70b-infrastructure

2024
[31]

The PyTorch team. [n. d.] (prototype) Flight Recorder for Debugging Stuck Jobs . https://pytorch.org/tutorials/prototype/flight_recorder_tutorial.html. (). Retrieved 2025-04-09 from

2025
[32]

Ji Zhang, Yuanzhang Wang, Yangtao Wang, Ke Zhou, Schelter Sebastian, Ping Huang, Bin Cheng, and Yongguang Ji. 2020. Tier-Scrubbing: An Adaptive and Tiered Disk Scrubbing Scheme with Improved MTTD and Reduced Cost . In 2020 57th ACM/IEEE Design Automation Conference (DAC), 1–6....

2020
[33]

ETH Zurich and EPFL. 2023. Swiss AI Initiative . https://www.swiss- ai.org. Accessed: 2025-04-09. (2023)

2023

Pith tools

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

[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 super- computer for diverse workflows . The International Journal of High Performance Computing Applications, 37, 3-4, 288–305. eprint: https://doi.org/10.1177/10943 420231167811. doi: 10.1177/10943420231167811

work page doi:10.1177/10943 2023

[2] [2]

María Arsuaga-Ríos, Seppo S Heikkilä, Dirk Duellmann, René Meusel, Jakob Blomer, and Ben Couturier. 2015. Using S3 cloud storage with ROOT and CvmFS . Journal of Physics: Conference Series , 664, 2, (Dec. 2015), 022001. doi: 10.1088/1 742-6596/664/2/022001

doi:10.1088/1 2015

[3] [3]

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

work page 2019

[4] [4]

2024.EMOI: CSCS Extensible Monitoring and Observability Infrastructure

Massimo Benini, Jeff Hanson, Mathilde Gianolli, Jean-Guillaume Piccinali, Michele Brambilla, Gianna Marano, Gianni Mario Ricciardi, Monica Frisoni, and Dino Conciatore. 2024.EMOI: CSCS Extensible Monitoring and Observability Infrastructure. (2024). https://www.research-collection.ethz.ch/handle/20.500.1 1850/702519

work page 2024

[5] [5]

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)

2025

[6] [6]

Paul, and Ali R

Debasmita Biswas, Sarah Neuwirth, Arnab K. Paul, and Ali R. Butt. 2021.Bridg- ing Network and Parallel I/O Research for Improving Data-Intensive Distributed Applications. In2021 IEEE Workshop on Innovating the Network for Data-Intensive Science (INDIS), 50–56. doi: 10.1109/INDIS54524.2021.00011

work page arXiv 2021

[7] [7]

Arthur Chiao. 2023. Understanding GPU Performance: Utilization vs. Saturation . (2023). http://arthurchiao.art/blog/understanding-gpu-performance

work page 2023

[8] [8]

Jonathan Coles, Ben Cumming, Theofilos-Ioannis Manitaras, Jean-Guillaume Piccinali, Simon Pintarelli, and Harmen Stoppels. 2023. Deploying Alternative User Environments on Alps . (2023). https://cug.org/proceedings/cug2023_proce edings/includes/files/pap143s2-file1.pdf

work page 2023