Rethinking Burst Buffer Optimization: Enabling Layout Heterogeneity via Hybrid Analysis and LLM Guidance Yuhan Cai1 , Huijun Wu1 , Zhuo Tang2 , Kehua Guo3 , Wenzhe Zhang1 , Zhenwei Wu1 , Zhouyang Jia1 , Ruibo Wang1 , and Yong Dong1 1 National University of Defense Technology, Changsha, Hunan, China 2 Hunan University, Changsha, Hunan, China
arXiv:2606.21852v1 [cs.DC] 20 Jun 2026
3 Central South University, Changsha, Hunan, China
Email: {caiyuhan, wuhuijun}@nudt.edu.cn
Abstract—Burst buffers (BBs) are essential for mitigating I/O bottlenecks in modern HPC systems. However, existing BB file systems often suffer from structural performance degradation due to fixed data layouts that fail to align with diverse application behaviors. While current machine-learning-based optimizations focus primarily on tuning storage stack parameters for a given layout, they offer diminishing returns when a fundamental mismatch exists between I/O patterns and the underlying data organization. Furthermore, these approaches typically incur prohibitive costs due to extensive training or intrusive profiling. To bridge this gap, we present Proteus, a semantic-aware BB system that treats data layout as a first-class optimization dimension. The core insight of Proteus is that application I/O intent can be reconstructed by synergetically combining static code structures with lightweight runtime signals. Through a hybrid pipeline and a single execution probe, Proteus extracts latent semantic cues to determine the optimal layout prior to production runs—eliminating the need for prior training or exhaustive profiling. Evaluation with representative HPC workloads shows that Proteus achieves 91.30% decision accuracy, delivering up to 3.24× and 2.9× speedups for write-intensive and metadata-intensive workloads, respectively. Index Terms—Burst buffer, Multi-mode layout, I/O semantics, LLM reasoning, HPC storage
I. I NTRODUCTION As high-performance computing (HPC) systems scale toward exascale, the I/O subsystem has increasingly become the dominant factor limiting end-to-end application efficiency [1], [2]. While compute capabilities continue to grow rapidly, storage systems advance at a much slower pace in terms of bandwidth, latency, and scalability, forcing applications to idle during I/O phases [3]. Burst buffers (BBs) [1], [4] have thus been widely adopted as intermediate storage layers to absorb transient I/O bursts and decouple applications from backend parallel file systems (PFS). Despite their effectiveness, most existing BB systems (e.g., GekkoFS [5], UnifyFS [6], CodepFS [7]) embed a critical yet often overlooked assumption: application I/O behaviors are semantically uniform. In practice, a BB must commit to a specific data and metadata layout, access path, and routing strategy at job startup, and this choice remains fixed through-
out execution. As a result, system performance is tightly bound to a single assumed I/O semantic. This rigidity becomes a fundamental limitation under heterogeneous and multi-phase HPC workloads. When an application’s actual I/O intent diverges from the assumed layout, the resulting performance degradation is structural rather than incidental. Such inefficiencies arise from inherent mismatches between application semantics and storage architecture, and therefore cannot be mitigated through parameter tuning or conventional runtime optimizations. These observations suggest that supporting multiple layout modes and selecting the appropriate one for each workload is essential for unlocking the full potential of burst buffer systems. The central challenge lies in accurately and efficiently identifying application I/O behavior prior to execution. Existing machine-learning (ML) based approaches face significant obstacles in production HPC environments. They rely on large volumes of historical I/O traces and continuous retraining, incurring substantial storage, computational, and operational overheads [8]. In addition, these approaches typically require repeated application executions to collect sufficient training data, while many production workloads run only a limited number of times, making such data collection impractical [9], [10]. Furthermore, they operate within a fixed architecture and are confined to tuning within a fixed BB data layout, leaving fundamental structural layout mismatches unresolved. To enable more practical and generalizable burst buffer optimization, we adopt a different perspective: performance depends on understanding the application’s I/O intent before execution. Such intent is primarily encoded in static artifacts (e.g., source code structure, I/O API usage, and job script configuration), and can be complemented by lightweight runtime signals to resolve behavioral ambiguities.We therefore propose a hybrid approach that combines static analysis, lightweight dynamic signals, and large language models (LLMs) to guide burst buffer optimization with minimal data and execution overhead. Based on this insight, we present Proteus, a semantic-aware burst buffer system that enables robust layout selection through
II. BACKGROUND AND M OTIVATION The performance challenge of burst buffers has shifted from whether acceleration is possible to under what conditions it can be achieved. In practice, performance varies widely across applications and I/O phases due to implicit assumptions about I/O semantics embedded in BB architectures. Data and metadata placement therefore define the performance envelope of a BB system, and any single static layout inevitably mismatches some workloads, creating performance ceilings that cannot be resolved through tuning. Multi-mode layouts are thus required to expand semantic coverage, raising two key questions: how to design such modes and how to select them before execution without runtime trial and error. A. Structural Limits of Burst Buffers Imposed by Data/Metadata Layout As computational performance scales, I/O bottlenecks increasingly constrain HPC workloads. Early studies on leadership-class systems revealed severe checkpoint and output bottlenecks, where backend parallel file systems cannot sustain application concurrency and burstiness [3]. Recent studies further show that I/O is not a marginal overhead: many HPC applications spend 15∼40% of their execution time performing I/O [11], and I/O interference under congestion can reduce application I/O throughput by up to 67% [12]. The problem
Impact of I/O Access Patterns (Seq vs Random)
103
101
AI (CosmoFlow) HPC (HACC)
103
104
102
Workload Behavior Statistics (AI vs Traditional HPC)
64,000 MB/s
Volume (GB) / Count (x100)
105 Bandwidth (MB/s) - Log Scale
hybrid intent inference. Proteus integrates three complementary components: (1) static intent extraction from source code and job scripts, (2) lightweight runtime profiling (e.g., a single execution probe via Darshan) to capture unambiguous dynamic behaviors, and (3) LLM-based semantic reasoning that jointly interprets these static and dynamic contexts in a zero-shot manner to generate the layout decision. Unlike prior work, Proteus avoids heavy runtime monitoring and does not require massive training data or repetitive parameter sweeps, while significantly improving decision accuracy. Architecturally, Proteus extends GekkoFS to support four data and metadata layout modes that span the burst buffer design space. Layout decisions are applied at the job level, avoiding costly online reconfiguration and data migration. This work makes the following contributions: • Architectural Contribution. We systematically identify and implement a multi-mode burst buffer system that unifies diverse data and metadata layouts within a single framework, enabling flexible adaptation to heterogeneous I/O semantics. • Methodological Contribution. We propose a hybrid intent inference framework that combines static analysis and lightweight runtime evidence with LLM-based semantic reasoning, significantly improving robustness while avoiding the overhead of heavy runtime profiling. • System Evaluation. Through extensive experiments on representative HPC workloads, we demonstrate that Proteus improves layout selection accuracy and achieves significant performance gains across diverse scenarios with minimal overhead.
64 MB/s
102 101 100 10 1
8 MB/s
Large Seq ReadSmall Random Write Small Access (JAG) (Optimized) (Unoptimized)
Read Volume Write Volume (GB) (GB)
File Count (x100)
Fig. 1: I/O heterogeneity across workloads [17]. (a) The significant bandwidth gap between sequential and random access; (b) Distinct I/O characteristics of AI versus HPC workloads. These variations show that no single static layout fits all scenarios.
is even more pronounced in large-scale AI workflows, where data I/O can consume up to 90% of total training time [13]. Burst buffers (BBs) have been widely deployed as an intermediate storage layer between compute nodes and parallel file systems [1], [14], leveraging node-local or near-node storage devices such as SSDs and NVRAM to absorb bursty traffic, decouple application I/O from backend contention, and improve throughput [1], [15]. Many BB designs have been proposed, often claiming performance advantages [4], [16]. However, their effectiveness is not determined by device bandwidth alone, but fundamentally depends on how data and metadata are placed, managed, and routed under different workload semantics. Even on identical hardware, I/O patterns show dramatically different performance (Figure 1). A BB’s data and metadata layout encodes assumptions about application I/O semantics. For example, GekkoFS uses a stateless distributed hashing scheme favoring concurrent, independent accesses but incurring overhead for global sequential scans [18]. In contrast, UnifyFS and HadaFS accelerate I/O through node-local writes, implicitly assuming write-dominant workloads with strong locality and limited cross-node access [6], [19]. When workloads involve frequent reads, sharing, or collective access, these assumptions can degrade performance. This demonstrates a fundamental reality: no single BB architecture is optimal across all I/O semantics, because its data and metadata layout determines which workloads it favors. More specifically, layout encodes several critical tradeoffs that shape these preferences. First, locality vs. sharing: extreme locality maximizes bandwidth but isolates data, hindering cross-node coordination; global sharing improves coordination but adds latency due to distributed locks or routing. Second, metadata coupling vs. scalability: colocating metadata with data enables low-latency access but can trigger RPC storms under complex cross-directory patterns; distributed metadata improves scalability but incurs coordination overhead. Finally, access aggregation strategy affects performance: direct paths minimize latency but may underutilize the network, whereas intermediate aggregation boosts throughput under high load at the cost of control
The Local Bandwidth Advantage (Write Workloads) 2.2x
Structural Impedance Mismatch (Read Workloads) 4.8x Faster
Node Local BB Global BB
10000 Read Throughput (MiB/s)
Throughput (MiB/s) - Log Scale
104
1.2x
12000
Node Local BB Global BB
103
102
101
8000 6000 4000 2000
Not Supported Fails
1.3x
IOR (Seq Write)
HACC (Checkpoint)
FIO (Rand Write)
0
N-N Read (IOR-FPP)
N-1 Read (IOR-Shared)
Fig. 2: Performance impact of layout selection. Node-local layouts excel at write-intensive checkpoints, while global layouts are required for read-heavy or shared-file workloads, illustrating the penalty of layout mismatch.
complexity [18], [20]. These trade-offs define the structural performance envelope of BB systems. Any fixed layout embeds assumptions about workload behavior, and deviations from these assumptions impose a structural performance ceiling. Parameter tuning or runtime optimization can barely overcome these limitations, as shown in Figure 2. To address this, Proteus adopts a multi-mode design with data layout as the primary axis of distinction. It provides four modes differing in data and metadata placement and access paths, allowing the BB to reshape its architecture prior to job execution based on semantic workload features. This approach establishes layout as central to performance optimization and lays the foundation for LLM-driven mode selection. B. Burst Buffer Layout Selection: Challenges and Opportunities As discussed above, the layout of a burst buffer (BB) directly determines the achievable performance ceiling, making it natural to adapt data and metadata placement based on application I/O patterns. In practice, however, realizing this strategy remains challenging. A common approach is to leverage dynamic instrumentation tools, such as Darshan or Recorder, to capture runtime I/O behavior and build performance models that guide configuration selection [21]–[23]. However, their applicability is limited in production HPC environments. Building reliable models requires substantial training data and repeated executions under varying configurations, incurring prohibitive profiling overhead and making them impractical for workloads with limited execution runs. Although historically difficult to exploit, recent studies have demonstrated that static analysis can effectively characterize performance-relevant I/O properties without requiring full execution [24]–[26]. This suggests that static information provides a lightweight and semantically rich foundation for understanding the logical structure of application I/O intent. However, comprehensive I/O characterization requires understanding not only the logical structure (e.g., concurrency,
access patterns) but also the execution intensity (e.g., exact read/write volumes, multi-phase durations). While static analysis provides accurate structural baseline, it struggles with edge cases involving dynamic loops or input-dependent I/O sizes (e.g., exact read/write volumes and multi-phase durations). Conversely, dynamic profiling captures these empirical metrics accurately but suffers from the severe overheads discussed earlier. To achieve both completeness and efficiency, we propose a mutually complementary hybrid approach. We combine the structural insights extracted from static artifacts with empirical evidence collected from lightweight runtime probes. This design effectively captures both dimensions of I/O behavior to disambiguate uncertain cases, while introducing minimal optimization tax. Recent advances [27], [28] in large language models (LLMs) further enable effective integration of these heterogeneous signals. In Proteus, the LLM serves as a semantic reasoning engine that jointly interprets static artifacts and lightweight runtime evidence, mapping inferred I/O intent to structured layout modes. This hybrid design enables robust and efficient layout selection across diverse workloads, achieving improved decision quality without incurring significant runtime overhead. III. S YSTEM D ESIGN A. System Overview Proteus is designed to address the structural mismatch between application I/O intent and rigid storage layouts. As illustrated in Figure 3, the framework operates at the job submission stage, leveraging both static application artifacts and lightweight runtime signals to determine an appropriate burst buffer configuration. The design goal is to achieve accurate and robust layout orchestration with minimal runtime overhead. The workflow consists of three primary phases: 1) Hybrid intent extraction. This phase captures the application’s I/O behavior by combining two complementary sources: static artifacts (e.g., source code and job scripts) and lightweight runtime signals collected from a single execution probe. The outputs of both sources are consolidated into a unified structured profile (i.e., the hybrid context). 2) LLM-based semantic reasoning. Operating on the extracted hybrid context, the decision core leverages an LLM guided by storage domain knowledge. The LLM semantically correlates the application’s I/O characteristics with the architectural trade-offs of different layouts to select the optimal layout mode. 3) Multi-mode layout activation. Based on the inferred decision, the system activates the selected layout mode prior to job execution. By instantiating routing rules and placement policies, the system ensures that the application operates within an optimized storage configuration from the outset, without requiring runtime reconfiguration.
Src2.c header. h Src1.c
</ >
> IOR –w -nodes=10
Application Code
Job Scripts
Run 1-2 times info
.exe
</ >
.darshan
read(), write() MPI_File_open() MPI_File_write() MPI_File_read() ......
LD_PRELOAD Intercept
Darshan Profiling
Source Code
LLM-based Reasoner
CN
Mode1: Node-Local
Select
I/O Intent Features
"decision": Hint2.md
Mode Knowledge
Application Reference
l Mode 1-4 l Features ….
"confidence":
l lOR/mdtest l Parameter ….
HYBRID STATIC–DYNAMIC ANALYSIS
CN
CN
0.85
"reasoning":
Hash
N-1 write to a shared file
Mode3: Distributed Hash
Runtime info
(pid, file, offset, size, op_type) MPI,POSIX READ,WRITE...
CN
Mode2: Centralized Meta
mode 3
Hint1.md
CN
CN
App docs, Mode theory, Experiments…
LLM DECISION CORE
Local write Global read
Mode4: Hybrid
MULTI-MODE EXECUTION
Fig. 3: The system performs hybrid I/O intent extraction from static artifacts and lightweight runtime signals, uses LLMs to select the optimal burst buffer layout, and instantiates the underlying storage architecture prior to execution.
B. Multi-Mode Burst Buffer Architecture In high-performance computing environments, achieving layout diversity through hardware customization or specialized interconnect topologies is both cost-prohibitive and inherently non-portable. The core design principle of Proteus is therefore to implement multiple storage layouts on top of a single physical architecture. By introducing a logic-defined and configurable routing layer, Proteus enables the system to adapt its storage architecture at job granularity, without requiring physical data migration or hardware reconfiguration. To characterize the structural alignment between application I/O semantics and burst buffer layouts, we analyze representative systems, including Cray DataWarp, BeeGFS, GekkoFS, UnifyFS, and HadaFS, as concrete instantiations of distinct points in a shared design space. This analysis reveals three fundamental and often conflicting dimensions: (1) locality versus sharing, (2) data–metadata coupling, and (3) namespace consistency guarantees. Based on these observations, Proteus adopts a multi-mode layout design that systematically spans this space through four complementary modes, covering workloads from isolated N –N checkpointing to shared N –1 access patterns. Rather than restricting optimization to parameter tuning within a single layout, Proteus exposes multiple fundamentally different layout strategies, enabling dynamic layout selection based on the specific I/O semantics of each workload. To realize this design, Proteus abstracts complex storage layouts into a logical composition of three core routing functions. I/O requests are intercepted at the client-side layer, where a mode-specific routing table determines the destination host H before entering the distributed storage stack:
•
Data placement function: fdata (path, chunk id) → Hi ,
determining the storage node responsible for each data chunk. • File metadata function: fmeta f (path) → Hi , •
determining the owner node for file-level metadata. Directory metadata function: fmeta d (path) → {Hid , . . . },
determining the scope of directory-level metadata management. Routing decisions are implemented using high-efficiency function pointers, maintaining constant O(1) lookup complexity and negligible overhead compared to network and storage latencies. By specializing the routing function triplet ⟨fdata , fmeta f , fmeta d ⟩, Proteus realizes distinct architectural templates without modifying the storage backend or introducing separate execution engines. Each mode corresponds to a structured operating point in the burst buffer design space, obtained through explicit trade-offs among locality, sharing, data–metadata coupling, and consistency. a) Mode 1 (Node-Local Storage): Mode 1 represents the extreme end of the locality spectrum, prioritizing nodelocal access over global visibility. All routing functions are deterministically mapped to the local node: fdata = fmeta f = fmeta d → localhost. At the logical level, this eliminates all remote routing and effectively bypasses the RPC protocol stack. Operations such
as forward_write are resolved as local synchronous calls, preserving strictly local data and metadata ownership. This design removes network contention and metadata coordination entirely, making it well-suited for large-scale independent N – N write workloads, such as checkpoint phases in tightly coupled simulations. Systems such as Cray DataWarp’s private mode [29] exemplify this design point, though Mode 1 in Proteus is derived as a general architectural extreme rather than a system-specific optimization. b) Mode 2 (Centralized Metadata).: Mode 2 occupies the opposite end of the sharing dimension by enforcing a globally consistent namespace through centralized metadata management. A configurable subset of nodes, denoted as Smd is designated as metadata servers and controlled by the parameter metadata_server_ratio. The file metadata routing function is redirected to this subset according to fmeta f (path) → str_hash(path) mod |Smd |, while data placement remains distributed across all storage nodes. By decoupling data distribution from metadata ownership, Mode 2 provides a strongly consistent global view of the namespace, significantly reducing path resolution overheads in N –1 shared access patterns and metadata-intensive workloads. This mode corresponds to a design point commonly observed in global file systems such as BeeGFS [30], but is here generalized as a controllable architectural choice within a unified routing framework. c) Mode 3 (Distributed Hashing): Mode 3 targets scalability by fully decentralizing both data and metadata routing. All routing functions are implemented using consistent hashing, yielding deterministic and coordination-free placement decisions. During forward_write, block-level hashing is applied as fdata (path,chunk id) → str_hash(path∥chunk id) mod N. uniformly distributing data across the cluster. This design minimizes metadata hotspots and enables near-linear scalability under high concurrency, at the cost of weaker namespace semantics and limited locality guarantees. Mode 3 serves as the load-balancing baseline in Proteus, providing robust parallel throughput for unstructured or random I/O workloads. Distributed file systems such as GekkoFS [5] illustrate this design point, which in Proteus is realized purely through routing specialization rather than a dedicated execution path. d) Mode 4 (Hybrid).: Mode 4 explores an asymmetric routing strategy that decouples write-time locality from readtime global accessibility. During the write phase, the data routing function is forced to resolve to the local node via a cached mapping: fdata (path) → pathhost_[path]. This preserves node-local write bandwidth and avoids network contention. In contrast, file metadata routing remains globally distributed using hashing: fmeta f (path) → str_hash(path) mod N.
Mode-Knowledge.md
Application-Reference.md
IOR: App Semantic Knowledge
......
Mode 1: System Architectural
......
Fig. 4: Examples of the domain knowledge base, encompassing application-level I/O semantics and mode-level architectural knowledge.
Metadata entries record an explicit data_location_rank field, enabling transparent redirection during subsequent crossnode reads. This hybrid design targets multi-phase workflows characterized by private data generation followed by collective analysis, capturing a common pattern in modern HPC and data-driven pipelines. Systems such as HadaFS [19] exemplify this asymmetric design point, which Proteus generalizes within its routing-based abstraction. By realizing layout diversity through logic-defined routing, Proteus decouples layout policies from the underlying protocol implementation. Routing rules explicitly dictate synchronization (e.g., triggering global coordination in Mode 2, or bypassing it via node-local paths in Mode 1). This enables seamless switching across diverse storage architectures without modifying the backend mechanisms. C. Hybrid Intent Inference Pipeline While the multi-mode architecture defined in Section III-B establishes the structural potential for optimization, unlocking this potential requires a precise decision mechanism. As discussed in Section II-B, traditional “optimize-by-running” approaches suffer from high cost, poor generalization, and cold-start limitations in HPC environments. To accurately select the optimal layout, Proteus must understand the application’s true I/O intent. Crucially, static and dynamic signals provide complementary dimensions of I/O behavior: static artifacts (e.g., source code and job scripts) reveal the logical I/O topology and concurrency structures, whereas lightweight runtime profiles supply empirical execution metrics (e.g., read/write ratios and metadata intensity). Therefore, Proteus captures both dimensions by combining compiler-based static extraction with lightweight runtime profiling, forming a comprehensive hybrid context. Operating on this unified representation, the LLM reasoning engine infers key I/O characteristics and maps them to an appropriate layout
mode. Based on this design, layout selection is performed through a structured pipeline: a) Context Extraction: Proteus extracts a compact hybrid context to support burst-buffer layout selection. This stage focuses on gathering evidence directly relevant to data and metadata placement by combining static analysis with lightweight runtime profiling. On the static side, the static extractor analyzes both source code and job scripts. From source code, Proteus identifies I/O call sites, file-name construction patterns, MPI rank usage, collective I/O operations, and rank-dependent control flow. These signals help distinguish common access topologies. For example, rank-indexed file names indicate a file-per-process N–N pattern, whereas multiple ranks accessing the same path with collective MPI-IO suggests an N–1 shared-file pattern. From job scripts, Proteus recovers launch parameters, process counts, benchmark options, file paths, transfer sizes, and sharing flags, because many HPC applications expose their I/O behavior through execution-time configuration. On the dynamic side, Proteus performs a lightweight Darshan-based probe run to compensate for potential insufficiencies in the static context. Importantly, this probe is not used to search over candidate layouts or tune the system through repeated execution. Instead, it collects only behavioral summaries such as read/write ratio, dominant request size, metadata intensity, access regularity, and shared-file activity. Finally, Proteus combines source-derived hints, scriptderived parameters, and runtime summaries into a structured hybrid context that records evidence across layout-relevant dimensions, including access topology, file sharing, request granularity, metadata pressure and collective I/O usage (Figure 5). b) Knowledge-Augmented LLM Reasoning: To guide the LLM’s reasoning, Proteus maintains a domain knowledge base covering two categories of information: (1) application-level semantics and (2) mode-level descriptions, as illustrated in Figure 4. The former captures I/O behaviors of common middleware and benchmarks, while the latter defines the architectural strengths and trade-offs of each Proteus layout. By providing summarized application patterns and layout tradeoffs, LLMs are equipped with decision-critical guidelines for accurate layout selection. c) LLM-Driven Layout Selection: Given the hybrid context and the domain knowledge, Proteus performs layout selection through structured reasoning over explicit I/O features. As illustrated in Figure 6, the model consumes a structured prompt that unifies the outputs of the previous steps: the extracted hybrid context and the domain knowledge. Unlike traditional machine learning models that merely fit decision boundaries from data without semantic constraints, making them highly dependent on data quality and scale, LLMs have internalized vast amounts of code, system documentation, and academic research [31], [32]. This inherent knowledge implicitly bridges the reasoning link from application I/O patterns to system design features and their matching relations. Essentially, using the LLM fundamentally eliminates the need
Hybrid Context // Script-derived "bench_params": { "-a": "POSIX", "-b": "128m", "-t": "4m", "-o": "shared_file" ... }, // Source-derived "static_features": { "access_pattern": "strided", "topology_hint": "N-1", "collective_io": true ... }, // Runtime (Darshan) "runtime_stats": { "posix_bytes_written": "5.2GB", "posix_bytes_read": "128MB", "posix_meta_ops": 24, "posix_seq_access_ratio": 0.87 ... },
Fig. 5: Hybrid context combining script, source, and runtime (Darshan) features.
for massive training data while introducing an explicit chain of reasoning. Specifically, the prompt explicitly enforces a stepby-step derivation path, requiring the LLM to sequentially analyze critical dimensions: concurrency topology (isolated vs. shared), resource intensity (metadata vs. bandwidth), I/O direction, and phase behavior. This structured reasoning prevents model hallucination and ensures that the decision is grounded in a transparent understanding of the workload’s I/O physics rather than empirical correlation. This structured output encompasses the selected mode, a confidence score, and a justification. Upon parsing, the system backend utilizes this decision to pre-provision the optimal storage layout, thereby enabling the multi-mode layout activation engine detailed in Section III-B to instantiate the appropriate configuration prior to job launch. To ensure system stability and prevent catastrophic execution errors (e.g., stranded local data if Mode 1 is mistakenly applied to a shared-read phase), Proteus employs a fallback strategy. The system activates specialized architectural modes only when the LLM generates a high-confidence semantic match. In cases of behavioral ambiguity or low confidence scores, Proteus defaults to the robust Mode 3 (Distributed Hashing) as a fail-safe baseline. IV. E VALUATION A. Experimental Setup Experiments are conducted on the Tianhe Exascale Prototype Upgrade System [33], utilizing a unified prototype that extends GekkoFS v0.9.2 [5] to support the four layout modes defined in Section III-B. To characterize the performance trade-offs and optimal use cases of each mode, we
Prompt Template You are an HPC I/O architecture expert. Your task is to analyze the provided hybrid JSON context and map it to the most suitable GekkoFS architecture mode. ### Knowledge Base {MODE_INFO} ### Application Context {APP_INFO}
TABLE I: Workload configurations for evaluation. We cover an extensive set of workload scenarios across representative HPC applications, spanning diverse I/O patterns (N-N vs. N1) and intensity levels. App
ID
Semantics & I/O Pattern
IOR
Test-A Test-B Test-C Test-D
N-N Write: Indep. file-per-process, Seq. N-1 Read: Shared file, collision-heavy. Meta-Heavy: Small segmented R/W. Mixed: Segmented dynamic R/W access.
FIO
Test-A Test-C Test-D Test-E*
N-N Write: Checkpoint simulation. AI/Meta: Massive small files, Rand access. Hybrid: N-1 Write + Rand Read (30%). Shared R/W: Read ratios 10%, 50%, 90%.
HACC
Test-A Test-B Test-C
N-1 Write: Large-scale checkpointing. N-1 Read: Global analysis/restart. Latency: Small meta ops sensitivity.
MAD
Test-A Test-B Test-C
N-1 Write: Collective I/O coordination. N-N Write: Unique stream throughput. Small I/O: Mixed data & metadata.
MDTEST
Test-A Test-B Test-C Test-D
Indep. Meta: File-per-process (Unique Dir). Shared Meta: N-1 Dir contention. Deep Tree: Recursive, namespace stress. 2-Phase: Create then Stat (Cache test).
S3D
Test-A Test-B Test-C
N-N Write: Checkpoint burst. Global Read: Restart pattern. Small I/O: Latency-sensitive.
### Hybrid Context (Static + Runtime) {CONTEXTUAL_SUMMARY} ### Reasoning Requirements 1. Analyze topology: isolated (N-N) vs shared (N-1). 2. Analyze intensity: metadata vs bandwidth. 3. Analyze direction: read-dominant vs write-dominant. 4. Analyze phase behavior across execution. ### Reasoning Strategy Perform step-by-step reasoning over the provided context and avoid unsupported assumptions. ### Mode Selection Task Select the layout mode that best matches the workload characteristics. Constraint: Select exactly one from [Mode 1, Mode 2, Mode 3, Mode 4]. ### Output (JSON Only) { "selected_mode": "Mode X", "confidence_score": 0.0-1.0, "io_topology": "N-N or N-1", "primary_reason": "Step-by-step reasoning", "risk_analysis": "Potential trade-offs" }
Fig. 6: Prompt template for hybrid intent inference.
evaluate four classes of workloads: (1) IOR [34], representing large-scale sequential checkpoint/restart I/O dominated by bandwidth and locality; (2) FIO [35], capturing small-file random I/O highly sensitive to tail latency and QoS stability; (3) MDTest [36], testing metadata-intensive operations governed by namespace visibility and coordination logic; and (4) Production Kernels (HACC [37], S3D [38], MADbench2 [39] ), covering multi-phase I/O and mixed access patterns. This covers traditional HPC simulations, metadata storms, and modern distributed deep learning checkpoints, and the comprehensive workload matrix is shown in Table I. To ensure robust evaluation, we scale each base scenario across multiple configurations, varying node counts (8, 16, 32), I/O block sizes. We configure sequential bandwidth benchmarks with 4 MiB transfer sizes, while FIO random-I/O experiments use 4 KiB requests; page caches are flushed prior to read operations to measure true hardware behavior. B. Microbenchmarks: Validating Multi-Mode Layouts We evaluate Proteus’s four layout modes to systematically explore their performance envelopes and validate our central hypothesis: BB performance fundamentally depends on aligning layout assumptions with application I/O semantics. By quantifying performance degradation in mismatched scenarios, we demonstrate multi-mode adaptation is strictly required to surpass monolithic performance ceilings.
a) Bandwidth Analysis in Checkpoint/Restart: Sequential I/O highlights the structural tension between write-phase locality and read-phase global visibility. In Fig. 7, Mode 1 and Mode 4 dominate the checkpoint phase. At 64 nodes, Mode 1 achieves 35 GiB/s, demonstrating near-ideal linear scalability by strictly confining I/O traffic to node-local tiers, thus eliminating network coordination for independent N – N writes. However, this physical isolation becomes a severe liability during restart, as stranded local data incurs massive cross-node penalties. Conversely, Mode 4 (Hybrid) sustains 17.5 GiB/s by combining local writes with globally visible metadata. This proves monolithic layouts cannot satisfy multiphase requirements, necessitating composite routing logic like Mode 4. b) Scalability of Random I/O: Random I/O analysis (Fig. 8, 9) exposes deep trade-offs among peak IOPS, scalability, and QoS stability. Mode 1’s write performance collapses to 164 IOPS under 90% read ratios at 32 nodes, confirming that excessive locality severely penalizes shared random access. While Mode 4 achieves high IOPS in small clusters, it exhibits severe performance jitter at 32 nodes. Conversely, Mode 2 maintains the lowest standard deviation and the most stable tail latency, demonstrating the value of centralized arbitration for latency-sensitive semantics. Mode 3 delivers the best scaling read performance, reaching 1272 IOPS in high-read scenarios. This divergence confirms that architectural stability and peak random-I/O performance are not always aligned, requiring precise mode matching before execution.
Mode 2 (Central)
Mode 3 (Dist.)
Read Performance (Restart)
25
12.5
20
10.0
15
7.5
10
5.0
5
2.5
0
8 Nodes
32 Nodes
0.0
64 Nodes
Write
15.0
Mode 1
Mode 2
64 Nodes
Mode 3 Mode 4 Random Read IOPS
Read IOPS Read IOPS Read IOPS
Write IOPS Write IOPS
Write IOPS
8 Nodes 16 Nodes 32 Nodes
8 Nodes 16 Nodes 32 Nodes
1200 1000 800 600 400 200 0 8 Nodes 16 Nodes 32 Nodes 2500 2000 1500 1000 500 0 8 Nodes 16 Nodes 32 Nodes
90% Read
300 250 200 150 100 50 0
8 Nodes 16 Nodes 32 Nodes
Tail Latency Stdev
Fig. 8: Random I/O scalability measured by IOPS (FIO). Performance comparison across varying read ratios and cluster sizes. Mode 3 provides the most consistent scalability for random access patterns.
c) Metadata Operation Performance: Metadata performance relies heavily on namespace organization. As Fig. 10 shows, Mode 4 excels in file creation and stat operations via hybrid buffering. However, Mode 2 dominates remove operations and matches Mode 4 in reads, as its centralized metadata subset minimizes distributed locking overhead and accelerates traversals. Conversely, Mode 1 suffers a structural collapse in global tasks, highlighting the catastrophic penalty of physical isolation under shared assumptions. This mismatch confirms layout placement strictly dictates efficiency for namespaceintensive workloads. d) Validation on Production Kernels and Structural Stability: Evaluation on representative kernels (Fig. 11) confirms no single mode is universally optimal: S3D-IO (write-heavy) aligns with Mode 4; MADbench2 (multi-phase) benefits from Mode 3’s decentralized balance; and HACC-IO achieves max-
Tail Latency Stdev
Tail Latency
Mode 2
Stdev
Mode 4 90% Read
Stdev
Stdev
IOPS
Tail Latency Stdev
IOPS
Tail Latency
IOPS
Tail Latency
Mode 2
Mode 3 50% Read
Tail Latency
Mode 4 90% Read Stdev
IOPS
Tail Latency Stdev
IOPS
IOPS
Tail Latency
Stdev
IOPS
Tail Latency Stdev
IOPS
Tail Latency Stdev
(b) 16 Nodes
10% Read
IOPS
Tail Latency
Mode 3 50% Read
IOPS
Tail Latency Stdev
IOPS
IOPS
Stdev
50% Read
1200 1000 800 600 400 200 0
250 200 150 100 50 0 8 Nodes 16 Nodes 32 Nodes
Stdev
(a) 8 Nodes
10% Read
10% Read
2000 1500 1000 500 0
Mode 4 90% Read
IOPS
IOPS
Tail Latency
32 Nodes
Fig. 7: Throughput for checkpoint (write) and restart (read). Mode 1 maximizes write bandwidth via node-local isolation, while Mode 4 balances write performance with the global visibility required for restart operations.
Random Write IOPS
IOPS
Tail Latency Stdev
8 Nodes
Mode 3 50% Read
Stdev
Read
30
Mode 2
Stdev
Write
17.5
Read
35
10% Read
Write
Aggregate Throughput (GiB/s)
Write Performance (Checkpoint)
Mode 4 (Hybrid)
Read
Mode 1 (Local)
IOPS
Tail Latency Stdev
IOPS
Tail Latency
IOPS
Tail Latency
(c) 32 Nodes
Fig. 9: QoS and tail latency analysis. Radar plots show that Mode 2 offers the most stable latency for small I/O, while Mode 3 achieves higher aggregate IOPS at scale.
imal stability under Mode 2. These end-to-end results confirm that synthetic architectural constraints persist in complex production loads. C. Accuracy of LLM Intent Inference a) Inference Accuracy Comparison: We measure decision accuracy against an oracle baseline, defined as the empirically optimal mode determined by exhaustive execution across all layout configurations. As shown in Table II, Proteus outperforms raditional machine-learning baselines (XGBoost). Despite leveraging historical execution traces and statistical modeling, this MLbased approach still struggles to generalize to complex or unseen multi-phase I/O patterns. In contrast, by leveraging semantic reasoning, Proteus significantly improves layout selection accuracy, reaching an optimal accuracy of 91.30%. Across different LLMs, higher-capacity models consistently achieve better performance. These results indicate that layout
File Stat
TABLE II: Comparison of mode selection accuracy.
Mode 1 (Local) Mode 2 Mode 3 Mode 4
File Read
HACC-IO Bandwidth Read
Mode 4
S3D-IO Bandwidth
0
10 20 30 40 50 60 70 Bandwidth (GB/s)
MADbench2 Execution Time (s) (Heatmap: Darker = Slower) 0.85
1.11
1.54
Mixed Read
6.81
2.36
7.32
Pure Write
14.12
14.20
13.32
Mixed Write
2.27
3.59
1.15
Mode 2
Mode 3
Mode 4
14 12 10 8 6 4
Write 0 100 200 300 400 500 600 700 Bandwidth (MB/s)
91.30% 86.96% 73.91% 73.91% 52.17%
Configuration
Accuracy
Proteus (Full Pipeline)
91.30%
Context Ablation w/o Runtime (Static Only)
86.96%
Knowledge Ablation w/o App-Ref w/o Mode-Know
82.60% 65.20%
Time (s)
Write
73.91% 91.30%
TABLE III: Ablation study on intent inference components.
Pure Read
Read
XGBoost Proteus (Ours)
Qwen3-235B Gemini-2.5-Flash DeepSeek-R1 GPT-4o Qwen3-32B
Fig. 10: Metadata performance comparison. Mode 2 excels at remove operations due to centralized coordination, while Mode 4 achieves high create throughput via local buffering. Mode 3
Accuracy
Proteus with Different LLMs
File Create
File Remove
Mode 2
Method
2
Fig. 11: End-to-end performance on HPC kernels. Different kernels prefer different modes, validating the necessity of multi-mode adaptation over a fixed layout.
selection requires non-trivial reasoning over multiple interacting I/O features rather than simple pattern matching. We adopt Qwen3-235B as the default model for analysis. b) Ablation Study on Domain Knowledge: To quantify the contribution of different design choices in Proteus, we conduct an ablation study evaluating the impact of the hybrid context and the domain knowledge (Table III). First, for context extraction, removing lightweight runtime signals (w/o Runtime) and relying solely on static inference drops the accuracy to 86.96%. This confirms that while static artifacts provide a robust baseline, runtime execution evidence is essential to resolve complex semantic ambiguities. Second, for domain knowledge, removing mode architectural descriptions (w/o Mode-Know) leads to the most significant degradation (dropping to 65.20%), indicating that understanding the structural trade-offs of the storage backend is the critical factor for correct layout mapping. Furthermore, removing application-level semantic guidelines (w/o App-Ref) reduces accuracy to 82.60%, highlighting the importance of crosslayer reasoning in bridging application behaviors with storage systems. c) Cost Analysis: In Proteus, the end-to-end decision pipeline consists of static extraction, a single execution probe, LLM inference, and mode activation. Specifically, when evaluated using Qwen3-235B, the LLM inference phase accounts for the majority of the system-intrinsic overhead, taking 33.0 s (with a 95th percentile of 51.3 s), and each decision request
consumes ∼9.4k input tokens and generates ∼1.1k output tokens. Table IV compares this overhead against traditional blackbox ML tuning paradigms. ML methods suffer from severe cold-start problems, typically requiring 102 –103 offline training executions and 10–100 full profiling runs prior to deployment. In contrast, by relying on execution probes and a single inference call, Proteus avoids exhaustive parameter sweeps and the hundreds of repeated full-length runs required by traditional ML. Consequently, this optimization tax is negligible over typical HPC jobs, preserving high deployment practicality in production environments. D. End-to-End Performance Evaluation a) Overall Performance Speedup: Each benchmark contains multiple subtests (e.g., IOR-A/B/C/D), as listed in Table I. Together, these extensive scenarios comprehensively cover file-per-process (N –N ), shared-file (N –1), metadataintensive, and mixed phases, spanning write-dominated, readdominated, and hybrid HPC I/O behaviors. Figure 13 shows that Proteus achieves clear gains on bottlenecked cases and remains near baseline on already well-aligned cases. It reaches 3.24× (IOR-A), 2.93× (mdtest-A), and 2.89× (mdtest-C), while maintaining robust gains of 1.15×–1.23× on sharedaccess kernels such as S3D and HACC-B. b) Comparison with Parameter Tuning and State-of-theArt Burst Buffers: We compare Proteus against three representative baselines: (1) OPRAEL [40], a state-of-the-art auto-tuning framework that utilizes an ensemble of machine learning models (e.g., Random Forest, XGBoost) to search for optimal storage configurations over GekkoFS; (2) UnifyFS, a node-local write-optimized burst buffer; and (3) CodepFS, a pattern-aware distributed burst buffer. For a fair comparison, UnifyFS and CodepFS were deployed using their officially recommended configurations and best practices.
TABLE IV: Cost comparison across optimization paradigms. Metric
Black-box ML
Proteus (Ours)
Offline training cost Pre-execution profiling Decision latency Feature source Search space
102 –103 runs
0 1–2 probes ∼48.5 s Hybrid (Static + Probes) Structural layout