IOSage: Detecting HPC I/O Bottleneck Patterns to Guide LLM Recommendations

IOSage: Detecting HPC I/O Bottleneck Patterns to Guide LLM Recommendations Mahdi Banisharif∗ , Tabassum Mahmud∗ , Ahmad Tarraf† , Suren Byna‡ , Ali Jannesari∗ ∗ Iowa State University, USA, {msharif, tmahmud, jannesar}@iastate.edu † Technical University of Darmstadt, Germany, ahmad.tarraf@tu-darmstadt.de

arXiv:2610.36370v1 [cs.DC] 26 Oct 2026

‡ The Ohio State University, USA, byna.1@osu.edu

Existing tools follow three approaches. Rule-based tools such as Drishti [6] flag metrics that cross thresholds set by experts, and WisIO [7] maps metrics to bottlenecks with an extensible rule set. They are fast and their decisions are easy to trace, and their thresholds and rules are written by experts rather than learned from logs. Learned approaches such as AIIO [8] train models on Darshan counters and show which counters explain slow I/O, but they predict throughput, not which patterns are present, and they do not recommend changes. Tools built on large language models (LLMs), such as ION [9] and its successor IOAgent [5], which adds retrieval over 66 I/O papers, explain the I/O behavior in a Darshan log in natural language; in both, the LLM decides which patterns a log contains. On our labeled benchmark test runs (Section IV), most patterns that IOAgent’s diagnosis pipeline, run from its public code on the log alone, like the classifier, without its literature retrieval (IOAgent without retrieval below), reports with GPT-4o [10] are absent from the labels: its precision (the share of reported patterns that are present) is 0.218 under our mapping of its text to the labels. STELLAR [11] has LLM agents read Darshan counters, tune Lustre parameters for the workload, measure each attempt, and keep the rules they learn for later workloads; it tunes the file system for a workload, while IOSage decides which patterns the log of a finished job shows and recommends changes to the application’s I/O. Deciding which patterns a log shows needs a baseline of what is normal, and a single log does not contain one. A classifier trained on many labeled logs learns that baseline from data. IOSage therefore gives the pattern decision to a I. I NTRODUCTION classifier, used as a precision gate: it decides which patterns the Applications on high-performance computing (HPC) systems prompt names, and the LLM turns those patterns into concrete often use only a fraction of the available I/O bandwidth [1], changes (Fig. 1). Our method is this division of labor and its [2]. On Polaris at the Argonne Leadership Computing Facility measurement: removing each part in turn shows what it adds, (ALCF) [3], 131,151 of a collection of 1.40 million Darshan [4] on applications and on benchmark runs with known labels. logs meet our cleaning criteria (Section II), and in about 46% We label benchmark runs by the configuration that induces of them the IOSage classifier detects at least one bottleneck each pattern, so detection is not scored against a rule over pattern, such as small transfer sizes, random access on a parallel the counters the model reads, and keep part of them for file system, or independent instead of collective MPI-IO. These evaluation; the multi-label classifier trains on the rest together logs hold 97.8% of the I/O time Darshan records, summed with counter-derived labels of production logs, which receive over ranks. a lower weight (biquality weighting). In IOSage, the prompt Recognizing the patterns requires an I/O specialist who can names the registered patterns (those the classifier learns to read Darshan counters, reason about Lustre striping and MPI- detect) that the classifier finds in the log, with a card for each IO hints, and relate the counters to application code. Few from a knowledge base (KB) built from benchmark training application teams have such a specialist [5]. runs; the prompt also holds the job’s configuration files and Abstract—HPC applications often leave much of their parallel file system’s bandwidth unused, and turning their Darshan logs into concrete I/O fixes still requires a scarce I/O expert. Rulebased tools flag counters against thresholds set by experts, and in tools built on large language models (LLMs), such as ION and IOAgent, the LLM decides which bottlenecks a log contains. We present IOSage, in which a classifier trained on many labeled logs, not the LLM, makes that decision, since a single log gives an LLM no baseline for what is abnormal. The LLM receives the I/O bottleneck patterns the classifier detects, the job’s configuration files, per-file Darshan evidence, and for each pattern a card built from benchmark training runs, and writes recommended changes. Applied by hand and measured in repeated paired runs, the changes IOSage names speed up median total wall time 4.38× for an openPMD kernel (4.02× on a second storage tier) and 1.42× for hourly WRF restarts. For 5 of the 6 application scenarios with a helpful change, IOSage with Claude Sonnet 4 names the helpful change, including the change for 10-minute WRF restarts, where it speeds up median total wall time up to 1.93×; with GPT-4o and Llama 3.1 as well, the classifier and cards name more helpful changes than the LLM alone. On 78 benchmark test runs without a pattern, the LLM deciding alone proposes changes for 64; with the classifier, for 9. The classifier reaches 0.929 Micro-F1 on 488 labeled benchmark test runs (0.916 as the gate; 0.832 on the 158 from configurations and jobs outside training), above Drishti’s rules, WisIO, and IOAgent’s pipeline without its literature retrieval. On TraceBench’s nine expert-labeled traces from production systems, it has the highest precision of the tools compared (0.82), with 2 false positives against 12 for the keywordmapped LLM diagnoses shipped with TraceBench and 5 for Drishti, on the five issue labels that match registered patterns. Index Terms—parallel I/O, Darshan, I/O performance, machine learning, large language models

(a) Preparation

Knowledge base (KB)

Benchmark runs IOR, mdtest, DLIO, h5bench, HACC-IO, mpi4py programs labeled by run configuration

Polaris (ALCF) production logs labeled by Drishti's rules (b) Per-log analysis 1

Feature extraction per-run features from the POSIX, MPI-IO and STDIO counters

2

Classifier training one model per pattern; configuration labels outweigh rule labels

3

4

Input

Detect patterns

Pattern cards

Darshan log (+ configuration files)

Classifier inference Precision gate: patterns above a

one card per detected pattern

probability threshold

Pattern cards one per pattern, from training runs

5

LLM recommends changes Turns cards into a concrete change, or no change Reads the log summary, per-file evidence, configuration files

Outputs Recommended changes, or none

(c) Validation

Apply and measure

Audit

recommended change applied by hand; repeated paired runs with and without it

same work, equivalent outputs

Fig. 1. IOSage architecture. (a) Preparation: configuration-labeled benchmark runs and rule-labeled Polaris logs train one classifier per pattern; the training runs yield one pattern card per pattern (typical counter values and a change template). (b) Per-log analysis: the LLM’s prompt holds the detected patterns with their cards, the log’s summary and per-file evidence, and the job’s configuration files. (c) Validation: a recommended change is applied by hand and its wall-time effect measured. Grey: inputs and outputs; orange: computation; blue: stored products; dashed arrows: products of (a) used in (b).

per-file Darshan evidence. The configuration files and per-file IOSage names a helpful change for 5 of the 6 evaluated evidence let IOSage tailor a recommendation to an application scenarios that have one, the applied changes give 4.38× without reading its source code. for an openPMD [13] kernel and 1.42× to 1.93× for A card shows how a pattern is usually removed, not whether WRF restarts, and a change the LLM proposes alone slows a change helps a given application, so on applications the Nek5000. changes IOSage names are applied by hand and judged by Section II describes the I/O behavior on Polaris that motivates total wall time over repeated runs. the design, and Sections V and VI cover related work and Each card gives a pattern’s counter signature and a generic limitations. change template; the LLM turns that template into a concrete II. BACKGROUND AND M OTIVATION change for the application, such as switching the I/O library for WRF [12] restart files. This paper makes three contributions: A. What Darshan Logs Record • A learned pattern decision before the LLM’s recomDarshan [4] is deployed at several leadership facilities, mendations. A multi-label classifier selects the registered including ALCF, where it produced the logs we use. It patterns and their pattern cards, and the LLM uses these, writes one log per execution of an MPI application, and one per-file Darshan evidence, and the job’s configuration files log per process for non-MPI programs. For each file, the to propose changes (Section III); on 78 benchmark test runs POSIX module keeps operation counts, byte totals, access-size without a pattern, Claude Sonnet 4 proposes a change for 64 histograms, the four most frequent access sizes and strides, when deciding alone and for 9 within IOSage (Section IV-C). timestamps of the first and last operations, and cumulative • Configuration-labeled detection with production data. read, write, and metadata time. The MPI-IO module keeps Benchmark runs are labeled by the configuration that induces similar counters without strides or sequential-access counts, each pattern and combined with rule-labeled production logs and it separates independent from collective operations. The at a lower weight; the classifier reaches 0.929 Micro-F1 (the STDIO module keeps counts, bytes, timestamps, and times but harmonic mean of precision and recall pooled over all labels, no histograms or access sizes. from 0 to 1, higher better) on 488 labeled test runs, 0.916 These counters show how an application issued its I/O, as the gate, and 0.832 on the 158 from configurations and for example many small writes or independent MPI-IO on a jobs outside training (Section IV-D). shared file. They do not show why: the log holds no application • Measured outcomes on applications. We apply the changes semantics, no state of the storage system or of other jobs, and IOSage names by hand and compare repeated, paired runs only coarse timing within a file. Monitoring that captures only by total wall time (Section IV-B): with Claude Sonnet 4, the I/O interfaces cannot fully explain bottlenecks inside deeper

1.0

CDF of logs

0.8

flagged (60,114 logs) no registered pattern (71,037 logs)

0.6 0.4 0.2 0.0 10−6

10−5

10−4 10−3 10−2 10−1 Share of rank time spent in I/O

100

101

Fig. 2. Share of rank time in recorded I/O calls for the 131,151 cleaned Polaris logs: POSIX and STDIO read, write, and metadata time summed over processes, divided by processes times run time. Values above 1 occur when calls overlap (397 logs).

dataset coverage is a known error source of I/O models [18], so generalization to applications must be tested separately. 2) One log is not a baseline. An LLM that reads a Darshan log judges it alone, with neither the thresholds of a rule tool nor the distribution of logs on the system; in our evaluation, LLMs deciding alone report patterns absent from the labels and propose changes for runs without a pattern (Section IV). A classifier trained on many labeled logs learns from data which counter values mark each pattern. 3) A citation is not a measured effect. Whether a change helps can be shown only by running it, and on a shared parallel file system, run-to-run I/O noise [18] makes one run with and one without the change insufficient. III. D ESIGN

IOSage takes a Darshan log that the facility already collects; for an application, the user may also supply the run’s input configuration files. It works in detection and recommendation (Fig. 1b, steps 2 to 5) and validation (Fig. 1c), with a classifier layers of the I/O stack [14]. Tracers such as DFTracer [15] and pattern cards prepared once (Fig. 1a). In detection, a record events across layers, but they are opt-in and cannot classifier trained on the labels of Section III-B finds the be applied to existing log archives. Time-resolved behavior, bottleneck patterns of Section III-A in the log. The classifier such as periodic I/O phases [16], [17], is also largely invisible acts as a precision gate (Section III-C). In recommendation, in aggregate counters. The HEATMAP module records I/O each detected pattern selects its pattern card from a knowledge volume over time. IOSage does not use HEATMAP data. We base (KB, Section III-D) built from training runs only, and the therefore treat each bottleneck pattern as I/O behavior that the LLM writes changes from a prompt that names the patterns and counters of a Darshan log can show, not as a diagnosed cause. holds their cards, the log’s evidence, and the job’s configuration files (Section III-E). In validation, a recommended change is B. Production I/O on Polaris applied by hand and the application runs with and without it Our production data is the ALCF Polaris Darshan log (Section III-F). collection [3], which is publicly available and holds 1,397,216 anonymized logs from April 2024 to February 2026. Polaris A. Bottleneck Patterns has 560 HPE Apollo nodes, each with one AMD EPYC CPU IOSage detects the seven patterns of Table I, each a behavior and four NVIDIA A100 GPUs. Its Lustre file systems include that a known change can remove. These are the registered Eagle, with 160 object storage targets (OSTs), 40 metadata patterns of Section I; a log with none of them has no registered targets (MDTs), 100 PB of capacity, and 650 GB/s of peak pattern. A log can hold several at once, for example small bandwidth. Of all logs, only 2.9% record MPI-IO, and 46.4% random writes, so detection is multi-label. The changes act move less than 1 MB in total. on transfer sizes, access order, the I/O interface or library, file Cleaning keeps logs with POSIX records, at least 1 s of layout, striping, rank balance, and synchronization. Detection run time, at least 1 KB and one POSIX read or write, and is advisory: a pattern that the application needs, such as a non-negative Darshan timers, which leaves 131,151 logs. The required file per process, is reported like any other; for an Polaris cohort and the production training logs therefore hold application, the LLM sees the configuration files and may state no STDIO-only log; the gate still scores such a log at inference that no change is justified, and the user decides whether a (Section III-C). Logs with a registered pattern spend more of change fits the application (Table I, last column). A pattern their rank time in I/O (Fig. 2): 6,952 of the 60,114 flagged is defined by the configurations that induce it, not by a fixed logs spend at least 10%, and the median share is 0.83% for threshold: for access granularity, the classifier learns where flagged logs against 0.025% for the others. the counters separate IOR runs with 64 B to 16 KiB transfers from runs without a pattern, such as 4 MiB collective writes; C. Challenges for parallelism efficiency, the inducing configurations come 1) No ground truth in production logs. Production logs carry from one benchmark (Section IV-D). no pattern labels, so labels for them are computed from the log itself. Independent labels come from benchmark runs whose B. Labels and Training configuration induces the pattern: an IOR run with 64-byte Configuration labels. For preparation (Fig. 1a), we ran transfers carries the access granularity label because of its parameter sweeps of six benchmarks on Delta at the National configuration, not because of a threshold on the counters in Center for Supercomputing Applications (NCSA): IOR [20] and its log. Such labels describe benchmark behavior. Inadequate its metadata companion mdtest, DLIO [21] for deep-learning

TABLE I R EGISTERED BOTTLENECK PATTERNS , THE BENCHMARK CONFIGURATIONS WE RAN TO INDUCE EACH ONE , THE CHANGE TEMPLATE OF ITS PATTERN CARD , AND WHEN THE CHANGE DOES NOT APPLY

Pattern

Behavior

Inducing configurations

Card change template

access granularity

many small reads or writes

IOR with 64 B to 16 KiB transfers; DLIO with small records; h5bench with small blocks; HACC-IO with few particles per rank

increase the transfer size to at the small requests carry a least 1 MB; aggregate small negligible share of the I/O time writes; use collective I/O

metadata intensity

metadata time dominates

mdtest with 1,000 to 50,000 creates, cross-node stat, deep trees

reduce the file count; batch metadata operations; use shared files for small data

parallelism efficiency

unequal I/O across mpi4py programs in which balance I/O across ranks; use ranks rank 0 writes 2 to 20 times more collective I/O

one rank owns the data by design, such as configuration or log output

access pattern

nonsequential offsets

IOR random offsets on a shared file; DLIO with shuffled files

sort offsets; access sequentially; enable data sieving

the data layout fixes the order, or sieving would read far more than needed

interface choice

shared-file I/O without collective MPI-IO

IOR POSIX on a shared file; MPI-IO independent with collective buffering off; h5bench independent data

use collective calls (MPI_File_write_all); enable collective buffering

ranks write large disjoint blocks, where independent I/O performs as well

file strategy

too many files

IOR file per process with 64 to 256 ranks; mdtest with 100 to 5,000 files per rank; HACC-IO file per process

use shared files with collective downstream tools need one file MPI-IO, or HDF5 or per process ADIOS2 [19]

throughput utilization

synchronization or IOR with fsync after every striping that slows write; DLIO checkpoints; writes h5bench and HACC-IO on a single OST

remove unneeded fsync; choose the stripe count based on file size and workload

the files are required outputs, such as per-step files read by other tools

fsync guards durability, such as a checkpoint commit, or the file is too small to stripe

250

IOR mdtest DLIO

222 200

Runs

data loading, h5bench [22] for HDF5, the HACC-IO checkpoint kernel of HACC [23], and mpi4py rank-imbalance programs. Each run is labeled by the configuration that induces its patterns (Table I), not by its counters (Section II-C). Runs of efficient configurations, such as IOR with 4 MiB collective MPI-IO writes, are labeled as having no registered pattern. Fig. 3 shows the labels of the 689 runs by benchmark: metadata intensity comes from mdtest and parallelism efficiency from the mpi4py programs only, and every other label from at least two benchmarks. Part of the labeled runs is kept for evaluation, and the rest trains the classifier (Section IV). Production labels. Polaris logs are labeled by Drishti’s rules [6], applied with their published thresholds to the extracted counters, and our mapping of rule triggers to the seven patterns. We use the 91,807 logs of the earliest 70% of the 131,151 cleaned logs, ordered by job start time. These labels are plentiful, but they are fixed expert thresholds on the counters the classifier reads. For two patterns they also capture a symptom different from the benchmark construction: small shared-file accesses for file strategy, and a highest offset larger than the bytes moved for throughput utilization. This is why the configuration labels define the patterns and the production labels add scale.

When the change does not apply

mpi4py h5bench HACC-IO

150 111 100

93

93 71

50

66

81

42

0

n rn cy rn ce gy ity ity tio oi te te te en ar ns at at ci ra ch ul iza te i t l p p f n i n s e f i t c e ra e ss ed a tu fil m rfa ce at er sg pu te st lis ac ad i es h n e t i c l g l e ug re ac m ra ro pa no th

Fig. 3. Labels of the 689 configuration-labeled benchmark runs, by benchmark; a run can carry several labels.

Biquality weighting. Biquality learning [24] trains on a small trusted label set and a large untrusted one together. Each configuration-labeled training run receives a weight of w = 100

and each production log a weight of 1, so one benchmark run counts as much as 100 production logs, while the production logs add workload diversity. Section IV reports how the score changes with w. Classifier. The classifier has one XGBoost [25] model (gradientboosted decision trees) per label (binary relevance); tree ensembles still outperform deep networks on typical tabular data [26], and other learners can fill the same role (Section IV-D). An eighth model predicts no registered pattern; Section IV-D scores all eight label models at 0.5, while the gate uses the seven pattern models at a threshold τ (Section III-C). It reads 157 features computed from the POSIX, MPI-IO, and STDIO counters of a log: operation counts, bytes, access-size histograms, times, and derived ratios such as the share of small or sequential accesses. Each model has 500 trees of depth 6, learning rate 0.05, row and column subsampling 0.8, and a per-label positive-class weight. TreeSHAP [27] computes SHapley Additive exPlanations (SHAP), the contribution of each feature to one prediction, which show the features that drive each pattern (Section IV). C. Precision Gate For a new log (Fig. 1b, step 2), each of the seven pattern models gives a probability, and every pattern above τ = 0.3 is detected. We set τ before any evaluation, below the default of 0.5, so that a pattern with probability between τ and 0.5 is also named in the prompt. The gate sets which patterns and pattern cards the prompt contains (Section III-D); the LLM is called for every log. When no pattern is detected, the prompt states this, and the LLM may answer that no change is justified. The gate scores every log as collected, including STDIO-only logs (Section II-B). D. Knowledge Base of Pattern Cards

Detected: access granularity (0.9998); all other patterns below 0.01. Card: access granularity: increase the transfer size; aggregate small writes; use collective I/O. Per-file evidence: each restart file written by one rank, 2.8 GB in 857 writes, 200 of them at most 1 MiB. Configuration: namelist.input (105 lines), among them io_form_restart = 2, io_form_history = 2. Explanation (abridged; the share is over the whole log): “68.17% of I/O operations being small (<1MB transfers) . . . WRF is using serial NetCDF . . . where one rank gathers data and writes through POSIX.” First: io_form_restart = 2 → io_form_restart = 11. Second: io_form_history = 2 → io_form_history = 11. Fig. 4. IOSage on a WRF run that writes restart files every 10 simulated minutes: prompt contents and Claude Sonnet 4’s output (abridged).

for a change for each detected pattern with code before and after, and the card it follows. For an application (the application prompt), the prompt also holds per-file evidence from the log (the largest files with their bytes, operations, ranks, share of small writes, and independent and collective MPI-IO writes) and the supplied configuration files. Its instructions ask for the smallest correct change at the level of a configuration setting, the I/O library, or the code; the card it follows or “none” for each change; no invented settings or speedups; and a statement when no change is justified. The LLM returns JSON with a diagnosis field and ranked recommendations, each with the pattern it addresses, code or settings before and after, and its citation. We query Claude Sonnet 4 [28], GPT-4o, and Llama 3.1 70B [29] at temperature 0 through OpenRouter, a single API for several LLM vendors. Example. Fig. 4 shows IOSage on a WRF run that writes restart files every 10 simulated minutes. The classifier detects only access granularity, and the prompt holds its card, the perfile evidence, and WRF’s namelist.input. The card offers generic changes, such as aggregating small writes. From the evidence that one rank writes each restart file through POSIX and the setting io_form_restart = 2, Claude Sonnet 4 ranks first switching the restart files from serial netCDF to parallel netCDF (PnetCDF) [30]; Table II gives its measured effect.

The KB (step 3) holds one card per registered pattern, built from the configuration-labeled training runs only. A card holds the pattern’s behavior, the median of each of its key counters over the training runs that show it, where the key counters are the five features with the largest mean absolute SHAP value for the pattern’s model on the training runs (Section IV-D F. Validation by Measured Wall Time shows the same analysis on the test runs), the location of the For an application (Fig. 1c), we apply each change of Table II inducing I/O call in one such run’s benchmark source, and by hand and run the application 11 times with and 11 without it, the change template of Table I with code before and after. in round-robin order so that file-system drift affects both. Each The prompt receives the card of each detected pattern. Cards run without the change pairs with the run with it that follows, describe patterns, not applications: they show what a pattern so the speedup is the median of the 11 pair ratios; the interval looks like in counters and how it is usually removed, and the from the 3rd to the 9th sorted ratio covers the true median ratio LLM derives the concrete change from the log and the job’s with a nominal 93.5% probability for independent, identically configuration. IOSage uses each LLM as released, with the distributed pairs, whatever the shape of their distribution [31], same cards for every model; a new pattern adds a card. [32]. An audit checks that both versions do the same work and produce equivalent outputs. A recommendation counts when it E. Recommendation names the applied setting, and at which position (Section IV). The prompt (step 4) holds the detected patterns with their probabilities, a summary of up to nine nonzero values of the IV. E VALUATION log (for example run time, average write size, and the share of small accesses), and the cards of the detected patterns. For We evaluate IOSage on three questions: do its recoma benchmark log (the benchmark prompt), the instructions ask mendations name changes that speed up real applications

(Section IV-B), does the classifier make the LLM’s recommendations more precise (Section IV-C), and how well does the classifier detect patterns against independent labels (Sections IV-D and IV-E)? Section IV-F applies the classifier to the Polaris logs. A. Setup and Metrics Platform. All runs use NCSA Delta CPU nodes, each with two 64-core AMD EPYC 7763 processors and 256 GB of memory. Applications run on one to four nodes (4 to 256 MPI ranks). They write to /work/hdd, a Lustre file system on 12 disk OSTs, except the flash-tier rows, which write to /work/nvme, 96 flash OSTs of the same file system. Total wall time is the elapsed time of the application launch (srun). We use Darshan 3.4.6, WRF 4.8.0 with PnetCDF 1.12.3, LAMMPS of 29 Aug 2024, and openPMD-api 0.15.1. The LLMs are queried at temperature 0, once per log and setting; temperature 0 does not make API outputs fully deterministic, so on the application cases with the classifier each model ran four times with a fresh cache, and the benchmark-run counts are one sample each. Data. The 689 configuration-labeled benchmark runs are split into 201 training and 488 test runs by iterative stratification [33], which balances the labels across the split; the test runs cover all six benchmarks. Most runs are kept for testing because the production logs supply most of the training data. The 488 test logs come from 422 jobs: some jobs write several logs, such as the write and read phases of an h5bench job, and these can fall on both sides of the split. Of the 488 test runs, 158 come from configurations and jobs outside training, and 330 share a configuration or a job with a training run; Section IV-D scores both. The pattern cards are built from the 201 training runs only. Metrics. Recall is the share of present patterns that are reported, complementing precision and Micro-F1 (Section I); MacroF1 averages the F1 values of the seven patterns and of “no registered pattern”. All range from 0 to 1, with higher better. Speedups and their intervals follow Section III-F; an interval that includes 1 means no significant change, and one entirely below 1 means slower. B. Recommendations on Real Applications Measured changes. Table II lists the audited changes. WRF writes two kinds of output: restart files, from which a run can resume, and history files, the forecast fields; our scenarios write each once per simulated hour (hourly) or every 10 simulated minutes (10-min) during a one-hour simulation. The measured changes speed up the openPMD kernel (h5bench’s openPMD write kernel, not among the labeled runs: 128 ranks write 10.7 GB to one HDF5 file) 4.38× (collective instead of independent HDF5 [34] transfers), WaComM++ [35] 1.95× (no processed copy of each hourly input file), and WRF 1.42× to 1.93× (parallel netCDF restart files). The 10-minute restart change also helps at four nodes and on the flash tier, by less (1.19× and 1.34×), and parallel netCDF history output speeds up WRF’s default settings 1.17× and the 10-minute history 1.13×. Three changes give no gain in total wall time: the

TABLE II M EASURED CHANGES ON REAL APPLICATIONS . WALL TIME : MEDIAN OF 11 RUNS . S PEEDUP : MEDIAN OF THE 11 PAIR RATIOS , WITH ITS 3 RD TO 9 TH RATIO AS A 93.5% INTERVAL (S ECTION III-F) Application

Change

and scenario

Wall time (s)

Speedup

Write

without with median [3rd, 9th]

step

76.0 16.6 4.38 [2.41, 5.35] 66.1 16.1 4.02 [3.68, 4.80] 59.1 30.3 1.95 [1.47, 2.62] 48.4 33.9 1.42 [1.37, 1.50] 94.8 49.3 1.93 [1.83, 1.99] 114.1 95.5 1.19 [1.13, 1.32] 93.7 73.8 1.34 [1.13, 1.61] 45.0 38.8 1.17 [1.12, 1.22] 52.9 48.7 1.13 [1.03, 1.14]

4.94 5.32 n/a 2.09 3.26 1.83 2.42 5.18 1.44

No significant change: interval includes 1 WRF history, hourly PnetCDF history 39.3 38.6 0.99 [0.93, 1.08] LAMMPS per-rank dumps 6.7 6.3 1.05 [0.98, 1.24]

1.82 2.22

Slower: interval below 1 Nek5000 one shared file

n/a

Faster: interval above 1 openPMD kernel HDF5 collective on flash tier WaComM++ no input copy WRF restart, hourly PnetCDF restart WRF restart, 10-min PnetCDF restart on 4 nodes on flash tier WRF history, defaulta PnetCDF history WRF history, 10-min PnetCDF history

30.2 33.5 0.95 [0.88, 0.99]

Indented rows: the change of the row above on four nodes or on the flash tier. Hourly: one output per simulated hour; 10-min: six. a As distributed with WRF’s continental-US (CONUS) benchmark case (compressed netCDF-4 history). Write step: speedup of the targeted output step by the application’s own timer; n/a: no such timer.

hourly history change and two that check IOSage’s no-change answers, the shared file an LLM alone proposes for Nek5000, which is slower, and one LAMMPS dump file per rank (both below). All series pass the audit: both versions do the same work and produce equivalent outputs. The targeted output step speeds up more than the total, up to 5.32× for openPMD on the flash tier and 5.18× for WRF’s default history; the hourly and 10-minute history steps speed up 1.82× [1.29, 2.34] and 1.44× [1.14, 1.57], but total wall time gains only for the 10minute output. The restart write is faster in all six WRF restart series, the four of Table II and two repeat-day series (1.76× to 3.26×), across three days, two node counts, and two storage tiers; repeated on another day, total wall time gains 1.17× [1.13, 1.30] for the 10-minute restart and shows no significant change for the hourly one (1.18× [0.64, 1.40]). We use the application’s timer because Darshan’s time inside I/O calls does not fall for the WRF changes: serial netCDF gathers each field to rank 0 through MPI before writing, outside I/O calls. Recommendations are scored against total wall time; the write-step column shows where the time goes. Scoring. We use applications whose I/O changes we can build, run, and audit. We give IOSage the log of the version without the change for the 8 scenarios on /work/hdd in Table II (without the 4-node and flash-tier repeats and LAMMPS, below) and score whether its recommendations name the change we applied, and at which position; 6 of them, from three applications, have a helpful change (openPMD, WaComM++, WRF hourly and 10-minute restart, default history, and 10minute history). A recommendation names the change when it contains the applied setting or its keyword, for example io_form_restart = 11, checked by a regular expression

With the classifier, Claude recommends no change in every setting and in all four runs. The same holds for LAMMPS and GROMACS. Deciding alone, the LLM proposes changes for the LAMMPS [37] molecular dynamics code and for Setting Claude GPT-4o Llama GROMACS [38]; for LAMMPS, all three models propose an MPI-IO dump style that the installed LAMMPS build does IOSage 5-6 (4) 4-5 (4) 3-4 (3) no cards 3 (2) 3 (2) 2 (1) not provide. With the classifier, every model recommends no no classifier 4 (3) 3 (2) 2 (2) change for both. To check whether no change is right for LLM alone 2 (1) 2 (1) 1 (0) LAMMPS, we measured the LAMMPS option of one dump IOSage (full prompt) in bold. file per rank (Table II). It speeds up the output step 2.22× (median of the pair ratios; medians 0.82 and 0.36 s), while total wall time shows no significant change (1.05× [0.98, 1.24]). per scenario; each change was applied by hand and run GROMACS, which moves only about 11 MB through STDIO, (Table II). We developed the application prompt on these series; was not measured. The LAMMPS log has only STDIO records, LAMMPS and GROMACS, below, ran with it unchanged, and GROMACS moves no POSIX data, and Nek5000 moves under a third application’s log was excluded because its run had a 1 KB through POSIX because it writes its field files through CPU-binding error. STDIO, while every training log has POSIX data. No pattern is Results. With pattern cards and the classifier, Claude names the detected in these logs, and IOSage with each LLM recommends helpful change for 5 of the 6 scenarios that have one and ranks no change. 4 of them first. For all five WRF scenarios, including the hourly Baselines and cost. Drishti (the drishti-io 0.8 package) [6] history, its first-ranked recommendation is the applied setting, recommends collective MPI-IO for the slow openPMD run. For whose effect Table II gives; for openPMD the applied change WRF, whose helpful change switches to parallel netCDF, and ranks second, and for Nek5000 it recommends no change, for WaComM++, whose helpful change drops a file copy, it where the change we applied was slower (0.95×). Table III advises switching to MPI-IO in general terms, without naming removes the cards, the classifier, or both. Every arm keeps the a setting. Drishti checks each log against fixed thresholds log summary, the per-file evidence, the configuration files, and and is not designed to compare versions; for openPMD and the instructions; “no classifier” names no pattern and holds all the two WRF restart pairs (hourly and 10-minute), it reports seven cards, “LLM alone” names no pattern and holds no card, more critical issues for the faster version than for the slower and with the classifier a log without a detected pattern receives one (5 against 3, 8 against 4, 7 against 4). With the same no card. IOSage names the most helpful changes with every three LLMs, IOAgent without retrieval [5], which reads only LLM. It also proposes no change for the three logs without a the log, names collective I/O for openPMD and none of the detected pattern (Nek5000, LAMMPS, and GROMACS), while WRF or WaComM++ changes. Where Drishti or IOAgent without the classifier every model proposes a change for all without retrieval names the change we applied, collective I/O three; Section IV-C shows the same on 78 benchmark runs for openPMD, its measured effect is the openPMD row of without a pattern. Two further arms, not in the table, remove Table II; their other advice for these logs names no setting to one input each: without the per-file evidence, Claude ranks the apply. IOAgent without retrieval makes 42.5 LLM calls per log helpful change first for 2 scenarios instead of 4; without the against one for IOSage, and with Claude Sonnet 4 costs about configuration files, GPT-4o names 3 instead of 5. $0.55 per log against $0.016 for IOSage with the benchmark For the hourly and 10-minute history scenarios, Claude prompt (list prices of $3 and $15 per million input and output ranks first the parallel netCDF history change; it speeds up tokens); the application prompt is two to four times longer. their output step (1.82× and 1.44×) and total wall time only Takeaway. IOSage with Claude Sonnet 4 names the parallel for the 10-minute output (Table II). The benchmark prompt of netCDF change for 10-minute WRF restarts from the log and Section III-E, which holds no per-file evidence or configuration the job’s configuration; there the change speeds up median files, leads every model to name only the openPMD change, total wall time up to 1.93×. On applications, IOSage names never first; for openPMD the classifier detects interface choice, more helpful changes than the LLM alone with every model the pattern its helpful change addresses. Over four fresh-cache (Claude 5 against 2). Where the classifier detects no pattern, as runs, Claude ranks 4 first every time, and one of the 12 runs, for Nek5000, LAMMPS, and GROMACS, IOSage with each Claude’s, names the WaComM++ change. LLM recommends no change, while every model deciding The LLM alone. Here the prompt holds no detected pattern alone proposes one, and the one such change we measured, a and no pattern card; it keeps the log summary, the per-file shared file for Nek5000, is slower. Section IV-C measures this evidence, and the configuration files. Claude and GPT-4o then on benchmark runs with known labels. name 2 of 6, and Llama 1. The classifier on logs without a pattern. For the Nek5000 [36] C. Recommendations on Benchmark Runs fluid solver, every model deciding alone recommends a change. On the 78 test runs without a pattern, the detected patterns Claude’s is to consolidate the 32 files of each output step into and their cards set whether the LLM proposes a change. This one shared file, which we measured at 0.95×, a slowdown. comparison uses the application prompt, which on benchmark TABLE III H ELPFUL CHANGES NAMED ON THE 6 APPLICATION SCENARIOS ( RANKED FIRST IN PARENTHESES ), BY SETTING AND LLM; ONE RUN PER CELL , AND THE IOS AGE ROW GIVES THE RANGE OVER FOUR RUNS

runs holds the log summary and no configuration files. Both arms receive the same instructions, which allow the answer that no change is justified, and differ only in the detected patterns and pattern cards. Deciding alone, Claude Sonnet 4 recommends a change on 64 of these runs; each proposed change requires review and, if implemented, repeated runs to establish its benefit (Section III-F). With the classifier, Claude proposes a change on 9; the classifier wrongly flags 7 of these, all DLIO runs, and on the other 2 no pattern is detected. Where a pattern exists, the gate’s cost is the patterns it does not pass to the LLM: at τ = 0.3 its recall over the eight labels is 91.8% on the 488 test runs, with precision 0.914. On all 488 test runs with the benchmark prompt (Section III-E), 0.895 to 0.906 of each model’s recommendations name a pattern the run has (pattern agreement; mean over runs with at least one recommendation; explicit no-change entries count as none); the effect of the changes is measured in Section IV-B. GPT-4o and Llama make about one recommendation per run (1.04) and Claude 1.4, and each model proposes a change on the same 7 no-pattern runs, the runs the classifier wrongly flags. A second setting lists all seven patterns as detected and asks for a change for each, which shows what the LLM does when the prompt asserts every pattern. Claude’s share then falls from 0.895 to 0.203, its recommendations per run rise from 1.4 to 3.7, and it proposes a change on all 77 no-pattern runs whose output parses. With the classifier, every recommendation on a run with a detected pattern follows that pattern’s card. Llama’s output does not parse for 8 runs, 7 of them without a pattern, and Claude’s for 1 in the second setting. D. Detection Table IV compares the classifier with rule-based tools and an LLM tool on the 488 test runs. The classifier reaches 0.929 Micro-F1 against the configuration labels (mean over five seeds, standard deviation 0.003; 95% bootstrap interval [0.912, 0.948] for seed 42); Section IV-E tests it against expert labels. On the 158 test runs from configurations and jobs outside training, it reaches 0.832 Micro-F1 (standard deviation 0.009 over five seeds), against 0.972 on the 330 runs that share a configuration or a job with training. Drishti’s rules, applied with their published thresholds to the extracted counters and mapped to the patterns they signal (Section III-B), reach 0.364; they label the production training logs, so the classifier improves on its own weak labels [39]. For file strategy and throughput utilization the rules capture a different symptom (Section III-B), and Drishti scores 0 on file strategy. WisIO’s rules [7] cover four of the seven patterns; over all seven, where the other three count as misses, it reaches 0.311. IOAgent without retrieval with GPT-4o, which like the classifier receives the target Darshan log at inference (a separate GPT-4o call maps its diagnoses to the label set), reaches 0.331 (recall 0.688, precision 0.218), at 258 s per log. Two trivial baselines stay far below the classifier: per-pattern thresholds that flag a pattern when one of one to three related features passes its 90th percentile over the production training logs (its 10th

TABLE IV D ETECTION ON THE BENCHMARK TEST RUNS : ALL EIGHT LABEL MODELS AT A THRESHOLD OF 0.5 ( THE GATE , SEVEN PATTERN MODELS AT τ = 0.3, SCORES 0.916) Method

Micro-F1

Macro-F1

Hamming

Subset

IOSage classifier 0.929±0.003 0.929±0.004 0.019±0.001 0.878±0.006 no production logs 0.909±0.001 0.904±0.001 0.026±<0.001 0.852±0.003 Other learners, same data Random forest 0.916±0.003 0.917±0.005 0.023±0.001 0.850±0.008 MLP 0.881±0.004 0.884±0.006 0.033±0.001 0.814±0.005 Drishti rules WisIOa IOAgent, no retrieval

0.364 0.311 0.331

0.285 0.211 0.284

0.227 0.310 0.376

0.283 0.018 0.052

Trivial baselines 90th percentile Majority class

0.285 0.151

0.201 0.034

0.252 0.225

0.055 0.160

Subset: share of runs with every label right; Hamming: share of wrong label decisions, lower better; the other metrics range from 0 to 1, higher better. Trained models: mean ± standard deviation over five training seeds on one split; best value per column in bold. a WisIO covers four of the seven patterns (access granularity, metadata intensity, parallelism efficiency, access pattern); the other three count as misses. On those four patterns, Micro-F1 is 0.931 for IOSage, 0.447 for Drishti, 0.425 for IOAgent without retrieval (GPT-4o), and 0.373 for WisIO.

for features where low values mark the pattern, such as the sequential-access ratios), and the majority value of each label in those logs. On the four patterns every tool reports, IOSage reaches 0.931 Micro-F1, against at most 0.447 (Table IV). Per pattern, the classifier’s F1 is 0.89 to 0.98 on these four, while the best tool on each reaches 0.55 (Drishti and IOAgent without retrieval, access granularity), 0.44 (Drishti, metadata intensity), 0.45 (IOAgent without retrieval, parallelism efficiency), and 0.33 (Drishti, access pattern). A one-sided paired bootstrap test (seed 42) finds the classifier’s lead over Drishti significant (p < 0.001). Training choices. Training on the 201 benchmark runs alone gives 0.909; the biquality weighting adds 2.0 points. On the same data, a random forest with the same weighting reaches 0.916 and a multilayer perceptron (MLP) with standardized inputs and the same weighting 0.881; tree ensembles lead on this tabular data, as expected [26]. With one seed, Micro-F1 rises from 0.886 at w = 1 to between 0.918 and 0.932 for w from 10 to 500, with 0.931 at w = 100; every w from 10 to 500 beats training on the benchmark runs alone. Used as the gate (seven pattern models at τ , no pattern when none fires), the classifier reaches 0.916 at τ = 0.3 and 0.911 to 0.917 for τ from 0.15 to 0.5. Per pattern. Per-pattern F1 ranges from 0.81 for throughput utilization to 1.00 for file strategy (seed 42). Fig. 5 shows the counter features that carry each pattern’s score: metadata time for metadata intensity, the sequential-access ratios for access pattern, process and file counts for file strategy, the unaligned-request count and the count of the most common access size for access granularity, and file misalignment and the fastest rank’s I/O time for interface choice, the counters a practitioner checks by hand. For access granularity, interface choice, and throughput utilization the top feature also varies

POSIX_F_META_TIME POSIX_FILE_NOT_ALIGNED seq_write_ratio STDIO_FLUSHES seq_read_ratio file_misalign_ratio num_files time_imbalance nprocs POSIX_ACCESS1_COUNT POSIX_F_FASTEST_RANK_TIME POSIX_READS POSIX_WRITES POSIX_ACCESS4_ACCESS POSIX_OPENS 0

2

4

6

Mean |SHAP| value access granularity metadata intensity parallelism efficiency

access pattern interface choice

file strategy throughput utilization

Fig. 5. Mean absolute SHAP value of the top counter features per pattern on the 488 test runs (TreeSHAP on the reported classifier); each bar segment is one pattern.

with the inducing configuration, so Sections IV-B and IV-E test the classifier outside the benchmarks, where it finds all 7 labeled access granularity issues on TraceBench with no false detection and 1 of 4 interface choice issues (throughput utilization has no TraceBench label). Per benchmark. Leaving one benchmark out of training (seed 42) lowers the score on its runs for every benchmark: to between 0.26 and 0.64 for HACC-IO, mdtest, h5bench, and IOR, from 0.41 to 0.33 for DLIO, and to 0 for the mpi4py programs. The classifier thus needs labeled runs of each kind of workload.

choice on three traces, access pattern on two, and metadata intensity and parallelism efficiency on one each. Only one miss (interface choice on the SW4 seismic code, probability 0.29) lies near τ ; the other six score below 0.02. We accept the lower recall because a false positive turns into a proposed change (Sections IV-B and IV-C). With τ as set in Section III-C, any τ from 0.25 down to 0.10 would also catch the SW4 miss without a new false positive; below 0.10 false positives grow. The file strategy and throughput utilization detections, which have no exact TraceBench label, are not scored for any tool. With misaligned requests scored, as misses for the classifier and as labels for the tools that report them, F1 is 0.55 for the classifier, 0.57 for the LLM diagnoses, and 0.74 for Drishti. F. Facility Study and Overhead On the 131,151 cleaned Polaris logs, including the 91,807 rule-labeled training logs, 45.8% show at least one registered pattern (Fig. 2); the most common are access granularity (30.8%), throughput utilization (20.5%), and access pattern (5.2%), and each other pattern flags under 2%. The throughput utilization and file strategy shares can include the productionlabel symptoms of Section III-B. The flagged logs hold 97.8% of the I/O time Darshan records, summed over ranks, and 81.6% of all rank time. Among the 12,446 logs that spend at least 10% of rank time in I/O, 55.9% show a pattern, and among the 4,916 logs of jobs with more than 128 processes, 83.7% do. Among logs in which Darshan dropped no file records and that move at least 100 GB through POSIX, those with a registered pattern reach a median Darshan job bandwidth of 1.2 GiB/s, against 2.8 GiB/s for the others (1.3 against 2.1 GiB/s from 1 GB). For one IOR log, the medians of feature extraction (10 runs) and inference (100 runs) sum to 41 ms, and one LLM call in the application setting takes 3 to 16 s with each LLM.

E. Real-Application Traces The public TraceBench release [5] groups nine traces as real-application traces (applications, I/O kernels, and IOR and h5bench runs), labeled by I/O experts; their logs come from five production systems (Cori, Perlmutter, Summit, Crusher, and Theta, by their mount tables), and the other 26 (9 singleissue programs and 17 runs of IO500, a standard storage benchmark suite) come from test clusters, so we score the nine. We score the five patterns that have an exact TraceBench label (access granularity, metadata intensity, parallelism efficiency, access pattern, interface choice); misaligned requests, which no registered pattern covers, are not scored. We map the LLM diagnoses shipped with TraceBench (ION) to patterns by keywords, with negations and dismissed issues removed, and use the Drishti outputs shipped with TraceBench. The classifier reports 2 false positives against 12 for the LLM diagnoses and 5 for Drishti, and finds 9 true issues against 8 and 10; 7 of its 9 true detections are access granularity, and both false positives are metadata intensity. Its precision (0.82) is the highest of the three; its F1 (0.67) matches Drishti’s (0.65), a difference smaller than one detection, and exceeds the LLM diagnoses (0.44); its recall (0.56) is above the LLM diagnoses (0.50) and below Drishti (0.63). The classifier’s 7 misses are interface

V. R ELATED W ORK Rule-based diagnosis and categorization. Drishti [6] flags Darshan metrics that cross expert thresholds and attaches a recommendation to each trigger. WisIO [7] computes metrics over file, process and time views of a trace and maps them to bottlenecks and causes with an extensible rule set. Ather et al. [40] add HDF5-level metrics and source-code context to Darshan data. MOSAIC [41] segments Darshan traces with set thresholds and assigns each job several temporal, periodic and metadata categories, to inform job scheduling. Each pattern in these tools is a rule that an expert writes and tunes. Learned models. Among the learned models surveyed by Peng et al. [42], Madhyastha and Reed [43] train a neural network on access-pattern benchmarks, and Bez et al. [44] detect file layout and access spatiality with decision trees, random forests and neural networks. Both classify the access pattern while the application runs, to set file-system policy or an I/O scheduler parameter. Gauge [45] clusters the jobs of one system and fits a model per cluster to explain throughput, and Bang et al. [46] cluster workloads without labels. AIIO [8] predicts a job’s I/O bandwidth and explains the prediction with SHAP, and BLG-Tuning [47] predicts I/O time. IOSage also learns

from benchmark runs, but it assigns several bottleneck patterns at once to the Darshan log of a finished job, each tied to known changes, and adds rule-labeled production logs at a lower weight. The expert-labeled traces of TraceBench [5] serve as our external test set (Section IV-E). LLM-based tools. In ION and IOAgent (Section I), the LLM decides which patterns a log shows; ION reports no quantitative detection metric, and IOAgent evaluates its diagnoses with expert labels and an LLM judge, while we score detection with standard multi-label metrics against configuration labels. Metis [48] has LLM agents characterize the HDF5 I/O functions themselves. RCACopilot [49] retrieves past cloud incidents for an LLM, and KORAL [50] guides an LLM with knowledge graphs of solid-state drive telemetry and literature; in both, the LLM decides the root-cause category or the diagnosis. In PGTune [51], an LLM generates storage configurations first, and a learned predictor then ranks them; in IOSage, the classifier acts before the LLM, on what the prompt names. I/O tuning. TunIO [52] tunes I/O-stack parameters for an extracted I/O kernel with repeated runs. TOTO [53] and CARAT [54] set Lustre stripe counts or client request and cache parameters at run time, and GLANCED-IO [55] tunes deep-learning data pipelines by greedy search on data subsets. These tuners act while the workload runs or over repeated or reduced runs; IOSage reads the log a job already produced and recommends changes to the application’s I/O. Positioning. IOSage differs from this work in who chooses the patterns an LLM works on and in what the LLM draws on. A trained classifier decides which patterns the prompt names, and the LLM turns them into changes (Section IV-C). The LLM draws only on pattern cards built from benchmark training runs and on the target job’s own log and configuration. STELLAR [11] is the closest LLM system for HPC I/O that measures changes: it reruns the application to tune Lustre parameters, and its learned rules carry over from benchmarks to unseen applications. It answers which file-system settings suit a workload; IOSage answers which patterns a finished job’s log shows and which change suits the application that wrote it (Section IV-B); the two are complementary. VI. L IMITATIONS What a detection covers. IOSage reports only the seven registered patterns and recommends known changes rather than new optimizations; adding a pattern takes a new benchmark sweep, a change template, and retraining, and finding the root cause of a slowdown inside application code is outside its scope. The prompt names neither unregistered patterns, such as misaligned requests (labeled on six of the nine TraceBench production-system traces), nor patterns the classifier misses. Section IV-E also gives a score that counts misaligned requests as misses. IOSage’s features summarize a whole log without the HEATMAP time series, so it cannot tell which phase or rank shows a pattern. Different causes can also give the same detection: the classifier detects only access granularity in the WRF and WaComM++ logs, whose helpful changes switch

the I/O library and drop a file copy, respectively. The perfile evidence and configuration files lead Claude to the WRF changes, but with the classifier only one of 12 runs names the WaComM++ change. Generalization and scope. Micro-F1 falls to 0.832 on runs from configurations and jobs outside training and to between 0 and 0.64 on a benchmark left out of training; parallelism efficiency has configuration labels from one benchmark only, so we do not claim detection of rank imbalance in general (Section IV-D). Training logs come from two Lustre-based systems; on the four TraceBench traces that wrote mostly to GPFS, by their mount tables, the classifier finds 4 of the 5 labels we score, with no false positive, and other parallel file systems are untested. HDF5 and netCDF reach the classifier only through POSIX and MPI-IO counters, and the programming language does not enter the input. The logs of LAMMPS, GROMACS, and Nek5000 carry little or no POSIX data, so the gate’s effect on logs without a pattern is measured on the 78 of the 488 test runs that have no pattern (Section IV-C). The Polaris shares are detections without ground truth. Recommendation evidence. The application results (Section IV-B) rest on 8 scenarios, 6 with a helpful change, and we developed the application prompt on these series; the pattern cards come from six benchmarks. The changes were applied by hand, not by IOSage, and two first-ranked recommendations, source edits for openPMD and WaComM++, were not run; a cited change may not fit another code, and we did not measure saved expert effort. Measurement. All application measurements come from one Lustre file system on Delta at one to four nodes, and the gain of a change varies between its series: the 10-minute WRF restart change gives 1.93× in Table II and 1.17× on a repeat day (Section IV-B). Total wall time can hide a faster output step, as in the hourly WRF history scenario (Table II). VII. C ONCLUSION When a trained classifier, not the LLM, decides which I/O bottleneck patterns a Darshan log shows, the LLM proposes changes for far fewer runs that have no pattern: on 78 such benchmark test runs, Claude Sonnet 4 deciding alone proposes changes for 64, and with the classifier, for 9. In IOSage, the LLM turns the detected patterns into changes, drawing on pattern cards built from benchmark training runs and on the job’s own log and configuration. Configuration labels let detection be scored against independent ground truth, and paired runs judge each applied change by its total wall time. Code, models, and measurements will be released on acceptance. Next, we will apply recommendations automatically and run the remaining ones, map detected patterns to the source lines that issue the I/O, add per-rank and time-resolved features, compare Darshan counters with richer traces such as DFTracer for detection, and retrain the classifier on each facility’s logs.

ACKNOWLEDGMENTS This material is based upon work supported by the National Science Foundation under Award No. 2211982. This work used the Delta system at the National Center for Supercomputing Applications (award OAC 2005572) through allocation CIS240415 from the Advanced Cyberinfrastructure Coordination Ecosystem: Services & Support (ACCESS) program [56], which is supported by National Science Foundation grants #2138259, #2138286, #2138307, #2137603, and #2138296. R EFERENCES [1] H. Luu, M. Winslett, W. Gropp, R. B. Ross, P. H. Carns, K. Harms, Prabhat, S. Byna, and Y. Yao, “A multiplatform study of I/O behavior on petascale supercomputers,” in Proceedings of the 24th International Symposium on High-Performance Parallel and Distributed Computing, HPDC 2015, Portland, OR, USA, June 15-19, 2015, T. Kielmann, D. Hildebrand, and M. Taufer, Eds. ACM, 2015, pp. 33–44. [Online]. Available: https://doi.org/10.1145/2749246.2749269 [2] J. L. Bez, S. Byna, and S. Ibrahim, “I/O access patterns in HPC applications: A 360-degree survey,” ACM Comput. Surv., vol. 56, no. 2, pp. 46:1–46:41, 2024. [Online]. Available: https://doi.org/10.1145/3611007 [3] S. Snyder, Argonne Leadership Computing Facility, P. Carns, and W.-k. Liao, “ALCF Polaris Darshan log collection,” 2025. [Online]. Available: https://zenodo.org/doi/10.5281/zenodo.15052603 [4] S. Snyder, P. H. Carns, K. Harms, R. B. Ross, G. K. Lockwood, and N. J. Wright, “Modular HPC I/O characterization with Darshan,” in 5th Workshop on Extreme-Scale Programming Tools, ESPT@SC 2016, Salt Lake City, UT, USA, November 13, 2016. IEEE, 2016, pp. 9–17. [Online]. Available: https://doi.org/10.1109/ESPT.2016.006 [5] C. Egersdoerfer, A. Sareen, J. L. Bez, S. Byna, D. Xu, and D. Dai, “IOAgent: Democratizing trustworthy HPC I/O performance diagnosis capability via LLMs,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2025, Milano, Italy, June 3-7, 2025. IEEE, 2025, pp. 322–334. [Online]. Available: https://doi.org/10.1109/IPDPS64566.2025.00036 [6] J. L. Bez, H. Ather, and S. Byna, “Drishti: Guiding end-users in the I/O optimization journey,” in IEEE/ACM International Parallel Data Systems Workshop, PDSW@SC 2022, Dallas, TX, USA, November 13-18, 2022. IEEE, 2022, pp. 1–6. [Online]. Available: https://doi.org/10.1109/PDSW56643.2022.00006 [7] I. Yildirim, H. Devarajan, A. Kougkas, X. Sun, and K. Mohror, “WisIO: Automated I/O bottleneck detection with multi-perspective views for HPC workflows,” in Proceedings of the 39th ACM International Conference on Supercomputing, ICS 2025, Salt Lake City, UT, USA, June 8-11, 2025. ACM, 2025, pp. 749–763. [Online]. Available: https://doi.org/10.1145/3721145.3725742 [8] B. Dong, J. L. Bez, and S. Byna, “AIIO: using artificial intelligence for job-level and automatic I/O performance bottleneck diagnosis,” in Proceedings of the 32nd International Symposium on High-Performance Parallel and Distributed Computing, HPDC 2023, Orlando, FL, USA, June 16-23, 2023, A. R. Butt, N. Mi, and K. Chard, Eds. ACM, 2023, pp. 155–167. [Online]. Available: https://doi.org/10.1145/3588195.3592986 [9] C. Egersdoerfer, A. Sareen, J. L. Bez, S. Byna, and D. Dai, “ION: navigating the HPC I/O optimization journey using large language models,” in Proceedings of the 16th ACM Workshop on Hot Topics in Storage and File Systems, HotStorage 2024, Santa Clara, CA, USA, July 8-9, 2024. ACM, 2024, pp. 86–92. [Online]. Available: https://doi.org/10.1145/3655038.3665950 [10] OpenAI, “GPT-4o system card,” CoRR, vol. abs/2410.21276, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2410.21276 [11] C. Egersdoerfer, P. H. Carns, S. Snyder, R. B. Ross, and D. Dai, “STELLAR: storage tuning engine leveraging LLM autonomous reasoning for high performance parallel file systems,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC 2025, St. Louis, MO, USA, November 16-21, 2025. ACM, 2025, pp. 1252–1266. [Online]. Available: https://doi.org/10.1145/3712285.3759887

[12] W. C. Skamarock, J. B. Klemp, J. Dudhia, D. O. Gill, Z. Liu, J. Berner, W. Wang, J. G. Powers, M. G. Duda, D. M. Barker, and X.-Y. Huang, “A description of the advanced research WRF model version 4,” NSF National Center for Atmospheric Research, Tech. Rep. NCAR/TN556+STR, 2019. [Online]. Available: https://doi.org/10.5065/1DFH-6P97 [13] F. Poeschel, J. E, W. F. Godoy, N. Podhorszki, S. Klasky, G. Eisenhauer, P. E. Davis, L. Wan, A. Gainaru, J. Gu, F. Koller, R. Widera, M. Bussmann, and A. Huebl, “Transitioning from file-based HPC workflows to streaming data pipelines with openPMD and ADIOS2,” in Driving Scientific and Engineering Discoveries Through the Integration of Experiment, Big Data, and Modeling and Simulation - 21st Smoky Mountains Computational Sciences and Engineering, SMC 2021, Virtual Event, October 18-20, 2021, Revised Selected Papers, ser. Communications in Computer and Information Science, J. Nichols, A. B. Maccabe, J. J. Nutaro, S. Pophale, P. Devineni, T. Ahearn, and B. Verastegui, Eds., vol. 1512. Springer, 2022, pp. 99–118. [Online]. Available: https://doi.org/10.1007/978-3-030-96498-6_6 [14] S. Neuwirth, H. Devarajan, C. Wang, and J. F. Lofstead, “XIO: toward eXplainable I/O for HPC systems,” in Proceedings of the 37th International Conference on Scalable Scientific Data Management, SSDBM 2025, Columbus, OH, USA, June 23-25, 2025, S. Byna, A. Kougkas, S. Neuwirth, V. Vishwanath, J. Boukhobza, A. Cuzzocrea, D. Dai, and J. Bez, Eds. ACM, 2025, pp. 23:1–23:6. [Online]. Available: https://doi.org/10.1145/3733723.3733741 [15] H. Devarajan, L. Pottier, K. Velusamy, H. Zheng, I. Yildirim, O. Kogiou, W. Yu, A. Kougkas, X. Sun, J. Yeom, and K. Mohror, “DFTracer: An analysis-friendly data flow tracer for AI-driven workflows,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage, and Analysis, SC 2024, Atlanta, GA, USA, November 17-22, 2024. IEEE, 2024, pp. 1–24. [Online]. Available: https://doi.org/10.1109/SC41406.2024.00023 [16] A. Tarraf, A. Bandet, F. Boito, G. Pallez, and F. Wolf, “Capturing periodic I/O using frequency techniques,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2024, San Francisco, CA, USA, May 27-31, 2024. IEEE, 2024, pp. 465–478. [Online]. Available: https://doi.org/10.1109/IPDPS57955.2024.00048 [17] F. Boito, L. Teylo, M. Popov, T. Jolivel, F. Tessier, J. Lüttgau, J. Monniot, A. Tarraf, A. R. Carneiro, and C. Osthoff, “A deep look into the temporal I/O behavior of HPC applications,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2025, Milano, Italy, June 3-7, 2025. IEEE, 2025, pp. 749–762. [Online]. Available: https://doi.org/10.1109/IPDPS64566.2025.00072 [18] M. Isakov, M. Currier, E. Del Rosario, S. Madireddy, P. Balaprakash, P. H. Carns, R. B. Ross, G. K. Lockwood, and M. A. Kinsy, “A taxonomy of error sources in HPC I/O machine learning models,” in SC22: International Conference for High Performance Computing, Networking, Storage and Analysis, Dallas, TX, USA, November 13-18, 2022, F. Wolf, S. Shende, C. Culhane, S. R. Alam, and H. Jagode, Eds. IEEE, 2022, pp. 16:1–16:14. [Online]. Available: https://doi.org/10.1109/SC41404.2022.00021 [19] W. F. Godoy, N. Podhorszki, R. Wang, C. Atkins, G. Eisenhauer, J. Gu, P. E. Davis, J. Choi, K. Germaschewski, K. A. Huck, A. Huebl, M. Kim, J. Kress, T. M. Kurç, Q. Liu, J. Logan, K. Mehta, G. Ostrouchov, M. Parashar, F. Poeschel, D. Pugmire, E. Suchyta, K. Takahashi, N. Thompson, S. Tsutsumi, L. Wan, M. Wolf, K. Wu, and S. Klasky, “ADIOS 2: The adaptable input output system. A framework for high-performance data management,” SoftwareX, vol. 12, p. 100561, 2020. [Online]. Available: https://doi.org/10.1016/j.softx.2020.100561 [20] H. Shan, K. Antypas, and J. Shalf, “Characterizing and predicting the I/O performance of HPC applications using a parameterized synthetic benchmark,” in Proceedings of the ACM/IEEE Conference on High Performance Computing, SC 2008, November 15-21, 2008, Austin, Texas, USA. IEEE/ACM, 2008, pp. 42:1–42:12. [Online]. Available: https://doi.org/10.1109/SC.2008.5222721 [21] H. Devarajan, H. Zheng, A. Kougkas, X. Sun, and V. Vishwanath, “DLIO: A data-centric benchmark for scientific deep learning applications,” in 21st IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing, CCGrid 2021, Melbourne, Australia, May 10-13, 2021, L. Lefèvre, S. Patterson, Y. C. Lee, H. Shen, S. Ilager, M. Goudarzi, A. N. Toosi, and R. Buyya, Eds. IEEE, 2021, pp. 81–91. [Online]. Available: https://doi.org/10.1109/CCGrid51090.2021.00018 [22] J. L. Bez, H. Tang, M. S. Breitenfeld, H. Zheng, W. Liao, K. Hou, Z. Huang, and S. Byna, “h5bench: A unified benchmark suite for evaluating HDF5 I/O performance on pre-exascale platforms,” Concurr.

Comput. Pract. Exp., vol. 36, no. 16, p. e8046, 2024. [Online]. Available: https://doi.org/10.1002/cpe.8046 [23] S. Habib, V. A. Morozov, N. Frontiere, H. Finkel, A. Pope, and K. Heitmann, “HACC: extreme scaling and performance across diverse architectures,” in International Conference for High Performance Computing, Networking, Storage and Analysis, SC’13, Denver, CO, USA - November 17 - 21, 2013, W. Gropp and S. Matsuoka, Eds. ACM, 2013, pp. 6:1–6:10. [Online]. Available: https://doi.org/10.1145/2503210.2504566 [24] P. Nodet, V. Lemaire, A. Bondu, and A. Cornuéjols, “Biquality learning: a framework to design algorithms dealing with closed-set distribution shifts,” Mach. Learn., vol. 112, no. 12, pp. 4663–4692, 2023. [Online]. Available: https://doi.org/10.1007/s10994-023-06372-3 [25] T. Chen and C. Guestrin, “XGBoost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, San Francisco, CA, USA, August 13-17, 2016, B. Krishnapuram, M. Shah, A. J. Smola, C. C. Aggarwal, D. Shen, and R. Rastogi, Eds. ACM, 2016, pp. 785–794. [Online]. Available: https://doi.org/10.1145/2939672.2939785 [26] L. Grinsztajn, E. Oyallon, and G. Varoquaux, “Why do tree-based models still outperform deep learning on typical tabular data?” in Advances in Neural Information Processing Systems 35: Annual Conference on Neural Information Processing Systems 2022, NeurIPS 2022, New Orleans, LA, USA, November 28 - December 9, 2022, S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh, Eds., 2022, pp. 507–520. [Online]. Available: https://doi.org/10.52202/068431-0037 [27] S. M. Lundberg, G. G. Erion, H. Chen, A. J. DeGrave, J. M. Prutkin, B. Nair, R. Katz, J. Himmelfarb, N. Bansal, and S. Lee, “From local explanations to global understanding with explainable AI for trees,” Nat. Mach. Intell., vol. 2, no. 1, pp. 56–67, 2020. [Online]. Available: https://doi.org/10.1038/s42256-019-0138-9 [28] Anthropic, “Claude,” https://www.anthropic.com/claude, 2026, accessed 2026-10-01. [29] Llama Team, “The Llama 3 herd of models,” CoRR, vol. abs/2407.21783, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2407.21783 [30] J. Li, W. Liao, A. N. Choudhary, R. B. Ross, R. Thakur, W. Gropp, R. Latham, A. R. Siegel, B. Gallagher, and M. Zingale, “Parallel netCDF: A high-performance scientific I/O interface,” in Proceedings of the ACM/IEEE SC2003 Conference on High Performance Networking and Computing, 15-21 November 2003, Phoenix, AZ, USA, CD-Rom. ACM, 2003, p. 39. [Online]. Available: https://doi.org/10.1145/1048935.1050189 [31] J. Le Boudec, Performance Evaluation of Computer and Communication Systems, ser. Computer and communication sciences. CRC Press, 2011. [Online]. Available: https://doi.org/10.1201/b16328 [32] T. Hoefler and R. Belli, “Scientific benchmarking of parallel computing systems: Twelve ways to tell the masses when reporting performance results,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC). ACM/IEEE, 2015, pp. 73:1–73:12. [Online]. Available: https://doi.org/10.1145/2807591.2807644 [33] K. Sechidis, G. Tsoumakas, and I. Vlahavas, “On the stratification of multi-label data,” in Proceedings of the European Conference on Machine Learning and Knowledge Discovery in Databases (ECML PKDD). Springer, 2011, pp. 145–158. [Online]. Available: https://doi.org/10.1007/978-3-642-23808-6_10 [34] M. Folk, G. Heber, Q. Koziol, E. Pourmal, and D. Robinson, “An overview of the HDF5 technology suite and its applications,” in Proceedings of the 2011 EDBT/ICDT Workshop on Array Databases, Uppsala, Sweden, March 25, 2011, P. Baumann, B. Howe, K. Orsborn, and S. Stefanova, Eds. ACM, 2011, pp. 36–47. [Online]. Available: https://doi.org/10.1145/1966895.1966900 [35] R. Montella, D. Di Luccio, C. G. De Vita, G. Mellone, M. Lapegna, G. Ortega López, L. Marcellino, E. Zambianchi, and G. Giunta, “A highly scalable high-performance Lagrangian transport and diffusion model for marine pollutants assessment,” in 31st Euromicro International Conference on Parallel, Distributed and Network-Based Processing, PDP 2023, Naples, Italy, March 1-3, 2023, R. Montella, J. G. Blas, and D. D’Agostino, Eds. IEEE, 2023, pp. 17–26. [Online]. Available: https://doi.org/10.1109/PDP59025.2023.00012 [36] N. Offermans, O. Marin, M. Schanen, J. Gong, P. F. Fischer, P. Schlatter, A. Obabko, A. Peplinski, M. Hutchinson, and E. Merzari, “On the strong scaling of the spectral element solver Nek5000 on petascale systems,” in Proceedings of the Exascale Applications and Software Conference 2016,

Stockholm, Sweden, April 26-29, 2016. ACM, 2016, pp. 5:1–5:10. [Online]. Available: https://doi.org/10.1145/2938615.2938617 [37] A. P. Thompson, H. M. Aktulga, R. Berger, D. S. Bolintineanu, W. M. Brown, P. S. Crozier, P. J. in ’t Veld, A. Kohlmeyer, S. G. Moore, T. D. Nguyen, R. Shan, M. J. Stevens, J. Tranchida, C. Trott, and S. J. Plimpton, “LAMMPS - a flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales,” Comput. Phys. Commun., vol. 271, p. 108171, 2022. [Online]. Available: https://doi.org/10.1016/j.cpc.2021.108171 [38] M. J. Abraham, T. Murtola, R. Schulz, S. Páll, J. C. Smith, B. Hess, and E. Lindahl, “GROMACS: High performance molecular simulations through multi-level parallelism from laptops to supercomputers,” SoftwareX, vol. 1-2, pp. 19–25, 2015. [Online]. Available: https: //doi.org/10.1016/j.softx.2015.06.001 [39] A. Ratner, S. H. Bach, H. Ehrenberg, J. Fries, S. Wu, and C. Ré, “Snorkel: Rapid training data creation with weak supervision,” The VLDB Journal, vol. 29, no. 2–3, pp. 709–730, 2020. [Online]. Available: https://doi.org/10.1007/s00778-019-00552-1 [40] H. Ather, J. L. Bez, Y. Xia, and S. Byna, “Drilling down I/O bottlenecks with cross-layer I/O profile exploration,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2024, San Francisco, CA, USA, May 27-31, 2024. IEEE, 2024, pp. 532–543. [Online]. Available: https://doi.org/10.1109/IPDPS57955.2024.00053 [41] T. Jolivel, F. Tessier, J. Monniot, and G. Pallez, “Mosaic: Detection and categorization of I/O patterns in HPC applications,” in SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, Atlanta, GA, USA, November 17-22, 2024. IEEE, 2024, pp. 1311–1319. [Online]. Available: https://doi.org/10.1109/SCW63240.2024.00172 [42] J. Peng, L. Yang, H. Wu, W. Zhang, Z. Wu, W. Zhang, J. Li, Y. Dai, and Y. Dong, “A survey on machine learning-based HPC I/O analysis and optimization,” IEEE Trans. Parallel Distributed Syst., vol. 37, no. 3, pp. 618–632, 2026. [Online]. Available: https://doi.org/10.1109/TPDS.2025.3639682 [43] T. M. Madhyastha and D. A. Reed, “Learning to classify parallel Input/Output access patterns,” IEEE Trans. Parallel Distributed Syst., vol. 13, no. 8, pp. 802–813, 2002. [Online]. Available: https://doi.org/10.1109/TPDS.2002.1028437 [44] J. L. Bez, F. Z. Boito, R. Nou, A. Miranda, T. Cortes, and P. O. A. Navaux, “Detecting I/O access patterns of HPC workloads at runtime,” in 31st International Symposium on Computer Architecture and High Performance Computing, SBAC-PAD 2019, Campo Grande, Brazil, October 15-18, 2019. IEEE, 2019, pp. 80–87. [Online]. Available: https://doi.org/10.1109/SBAC-PAD.2019.00025 [45] M. Isakov, E. Del Rosario, S. Madireddy, P. Balaprakash, P. H. Carns, R. B. Ross, and M. A. Kinsy, “HPC I/O throughput bottleneck analysis with explainable local models,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC 2020, Virtual Event / Atlanta, Georgia, USA, November 9-19, 2020, C. Cuicchi, I. Qualters, and W. T. Kramer, Eds. IEEE/ACM, 2020, pp. 33:1–33:13. [Online]. Available: https://doi.org/10.1109/SC41405.2020.00037 [46] J. Bang, C. Kim, K. Wu, A. Sim, S. Byna, S. Kim, and H. Eom, “HPC workload characterization using feature selection and clustering,” in Proceedings of the 3rd International Workshop on Systems and Network Telemetry and Analytics (SNTA). ACM, 2020, pp. 33–40. [Online]. Available: https://doi.org/10.1145/3391812.3396270 [47] Z. Wang, C. Zhang, Y. Li, Y. Wu, Y. Wang, and X. Dong, “BLG-Tuning: Benchmark-based low-cost general-purpose I/O modeling and tuning,” ACM Transactions on Architecture and Code Optimization, vol. 23, no. 2, pp. 44:1–44:24, Jun. 2026. [Online]. Available: https://doi.org/10.1145/3806050 [48] K. Youssef, S. Neuwirth, N. Rajesh, and H. Devarajan, “Metis: Agentic knowledge synthesis for explainable I/O performance in HPC systems,” in Proceedings of the 35th International Symposium on High-Performance Parallel and Distributed Computing, HPDC 2026, Cleveland, OH, USA, July 13-16, 2026, S. Kuppannagari, M. Koyutürk, A. Goldman, and D. S. Nikolopoulos, Eds. ACM, 2026, pp. 817–826. [Online]. Available: https://doi.org/10.1145/3806645.3816129 [49] Y. Chen, H. Xie, M. Ma, Y. Kang, X. Gao, L. Shi, Y. Cao, X. Gao, H. Fan, M. Wen, J. Zeng, S. Ghosh, X. Zhang, C. Zhang, Q. Lin, S. Rajmohan, D. Zhang, and T. Xu, “Automatic root cause analysis via large language models for cloud incidents,” in Proceedings of the Nineteenth European Conference on Computer Systems, EuroSys 2024,

Athens, Greece, April 22-25, 2024. ACM, 2024, pp. 674–688. [Online]. Available: https://doi.org/10.1145/3627703.3629553 [50] M. Akewar, S. Madireddy, D. Luo, and J. Bhimani, “KORAL: knowledge graph guided LLM reasoning for SSD operational analysis,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2026, New Orleans, LA, USA, May 25-29, 2026. IEEE, 2026, pp. 996–1011. [Online]. Available: https: //doi.org/10.1109/IPDPS65963.2026.00085 [51] W. Zhang, C. Ma, H. Zhang, Y. Liu, P. Wang, X. Guo, F. Yang, and K. Zhou, “PG-Tune: Prediction-guided distributed storage system tuning without repeated online benchmarking,” in Proceedings of the 55th International Conference on Parallel Processing, ser. ICPP ’26. ACM, Sep. 2026, pp. 564–574. [Online]. Available: https://doi.org/10.1145/3832810.3832829 [52] N. Rajesh, K. Bateman, J. L. Bez, S. Byna, A. Kougkas, and X. Sun, “TunIO: An AI-powered framework for optimizing HPC I/O,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2024, San Francisco, CA, USA, May 2731, 2024. IEEE, 2024, pp. 494–505. [Online]. Available: https: //doi.org/10.1109/IPDPS57955.2024.00050 [53] F. Boito, L. Teylo, M. Popov, L. Aimi, A. Bandet, L. L. Pilla, and G. Pallez, “TOTO: Transparent I/O tuning for HPC applications,” in Proceedings of the 40th ACM International Conference on Supercomputing, ser. ICS ’26. ACM, Jul. 2026, pp. 301–313. [Online]. Available: https://doi.org/10.1145/3797905.3807867 [54] M. H. Rashid, N. R. Tallent, F. S. Bao, and D. Dai, “CARAT: client-side adaptive RPC and cache co-tuning for parallel file systems,” in IEEE International Parallel and Distributed Processing Symposium, IPDPS 2026, New Orleans, LA, USA, May 2529, 2026. IEEE, 2026, pp. 1343–1357. [Online]. Available: https://doi.org/10.1109/IPDPS65963.2026.00110 [55] R. A. O. Sinurat, W. Nixon, P. H. Carns, H. Zheng, S. Madireddy, S. Foreman, T. Arcomano, R. B. Ross, H. S. Gunawi, and H. Devarajan, “GLANCED-IO: taming I/O optimization for deep learning at scale,” in Proceedings of the 35th International Symposium on High-Performance Parallel and Distributed Computing, HPDC 2026, Cleveland, OH, USA, July 13-16, 2026, S. Kuppannagari, M. Koyutürk, A. Goldman, and D. S. Nikolopoulos, Eds. ACM, 2026, pp. 305–318. [Online]. Available: https://doi.org/10.1145/3806645.3807588 [56] T. J. Boerner, S. Deems, T. R. Furlani, S. L. Knuth, and J. Towns, “ACCESS: advancing innovation: NSF’s Advanced Cyberinfrastructure Coordination Ecosystem: Services & Support,” in Practice and Experience in Advanced Research Computing, PEARC 2023, Portland, OR, USA, July 23-27, 2023. ACM, 2023, pp. 173–176. [Online]. Available: https://doi.org/10.1145/3569951.3597559

Related documents

• IOSage: Detecting HPC I/O Bottleneck Patterns to Guide LLM Recommendations#1467694
• PATHA: Performance Analysis Tool for HPC Applications#611942
• Kaizen: Metamorphic Fuzzing and Differential Testing for LLM-Translated HPC Applications#1325212
• BuildBench: Benchmarking LLM Agents on Compiling Real-World Open-Source Software#1013446
• AutoPass: Evidence-Guided LLM Agents for Compiler Performance Tuning#290618