InfraGraph: Graph-Based Infrastructure Modeling

• InfraGraph is a graph-based abstraction for modeling infrastructure, capturing physical components and interconnections with typed nodes and edges.
• It unifies hardware details, such as on-chip routers, network links, and vulnerabilities, into a single, reusable graph format across various domains.
• The approach enhances reproducibility and domain-specific reasoning by transforming raw data into operational graphs driven by explicit heuristics and performance metrics.

InfraGraph is a graph-centric infrastructure abstraction whose meaning varies by research context. In "ASTRA-sim 3.0: Next-Level Distributed Machine Learning Simulations via High-Fidelity GPU and Infrastructure Modeling," it denotes a graph-based, backend-agnostic schema for representing the complete physical layout of a distributed-ML cluster, from per-GPU on-chip routers and memory controllers to off-node switches and links (Won et al., 9 Jun 2026). In "A graph generation pipeline for critical infrastructures based on heuristics, images and depth data," the term appears in an InfraGraph-like pipeline that converts multi-view RGB–depth images into a relational graph $G=(V,E)$ whose nodes represent physical assets and whose edges model pairwise connections (Diessner et al., 8 Dec 2025). In "Graphene: Infrastructure Security Posture Analysis with AI-generated Attack Graphs," the name is used for a holistic, end-to-end platform for automated infrastructure security posture analysis built around AI-generated attack graphs (Jin et al., 2023). This suggests that InfraGraph is best understood not as a single universal formalism, but as a recurring label for graph-based infrastructure modeling across simulation, perception, and security analysis.

1. ASTRA-sim 3.0 definition and rationale

Within ASTRA-sim 3.0, InfraGraph is introduced to capture the complete physical layout of a distributed-ML cluster through a single, attributed directed graph that serves as the sole source of truth for every network-backend translator. The formal definition is

$G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$

where $V$ is the set of vertices representing uniquely identified hardware components, $E \subseteq V \times V$ is the set of directed edges representing physical links, $\tau_V$ and $\tau_E$ are type maps for nodes and edges, and $\Pi_V$ and $\Pi_E$ assign attribute dictionaries to nodes and edges. Example node types include $$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$, and example edge types include $\{pcie, noc, ethernet, infiniband\}$. Node attributes may include bandwidth_max, latency, device_instance_id, component_id, and port_index, while edge attributes may include link_bandwidth, link_latency, flit_size, encoding overhead, and optionally congestion parameters (Won et al., 9 Jun 2026).

The motivation for this representation is explicitly tied to limitations of earlier ASTRA-sim releases. Before InfraGraph, each backend—the analytical "Simple" model, ns-3, or htsim—required its own manual topology description. Those descriptions did not capture on-chip detail alongside off-node links, forced users to relearn three formats when swapping backends, and prevented sharing or reproducing published experiments because prose descriptions such as "two-tier fat-tree" did not specify per-link latencies, switch-port numbering, or exact wiring. InfraGraph addresses these gaps by being fully programmable, enabling reuse via blueprints, capturing per-component attributes at both NoC and scale-out levels, and feeding every ASTRA-sim backend translator from the same graph so that performance differences arise from model fidelity rather than input mismatches (Won et al., 9 Jun 2026).

In this setting, InfraGraph is not merely a topology file format. It is the infrastructure description layer through which ASTRA-sim 3.0 connects cache-line-granularity GPU modeling, NoC-level modeling, and backend-specific network simulation.

2. Schema, primitives, and graph expansion

The ASTRA-sim 3.0 schema is built from a small set of primitives. componentInst describes an internal hardware block of a device, and each componentInst becomes a unique vertex $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$0. Examples include gpu.cu.0, gpu.noc.[router](https://www.emergentmind.com/topics/router).5, gpu.hbm.channel.3, and server.nic.port.2. linkInst is a named, parameterized connection container; each linkInst yields one or more edges and has attributes such as bandwidth, latency, encoding_factor, and flit_size. deviceInst is a subgraph template composed of componentInst vertices and internal linkInst edges. The "DGX-style host" blueprint, for example, defines 8 GPUs, each with 32 CUs, 16 HBM channels, a 2D $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$1 NoC, and 4 I/O ports, together with one PCIe root-complex with 16 lanes to each GPU and a dual-ported NIC. instanceInst binds a deviceInst blueprint to a concrete name, and infraInst is the top-level container that links instanceInsts via inter-device linkInsts (Won et al., 9 Jun 2026).

Once expanded, each vertex has a hierarchical identifier of the form

$G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$2

and each edge is represented as

$G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$3

with all attributes attached. A minimal example is a two-GPU peer-to-peer link in which fully qualified graph expansion yields four vertices—gpu0.cu.0, gpu0.hbm.0, gpu1.cu.0, and gpu1.hbm.0—and three edges: (gpu0.cu.0→gpu0.hbm.0, noc@512 GB/s,5 ns), (gpu1.cu.0→gpu1.hbm.0, noc@512 GB/s,5 ns), and (gpu0.hbm.0→gpu1.hbm.0, pcie@64 GB/s,100 ns). The corresponding adjacency matrix of edge latencies $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$4, where $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$5, encodes $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$6 ns intra-GPU NoC traversal and $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$7 ns inter-GPU PCIe latency for the populated entries (Won et al., 9 Jun 2026).

The significance of these primitives is that they allow one representation to span on-chip micro-architecture, host-level composition, and cluster-level interconnect. In ASTRA-sim 3.0, this unification is the mechanism by which GPU internals and scale-out communication are described in a common formal object.

3. Integration into distributed-ML simulation

ASTRA-sim’s network front end accepts a single InfraGraph file in JSON or as a serialized Python object. The frontend parses InfraGraph and expands all deviceInst and linkInst templates into the fully qualified graph. Translator modules for each backend then walk the graph to emit backend-specific configuration. The "Simple" model groups nodes into dimensions for collective $G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$8–$G = (V, E, \tau_V, \tau_E, \Pi_V, \Pi_E),$9 modeling and uses per-edge bandwidth and latency in its event-driven equations. The ns-3 translator assigns node IDs and link IDs and sets per-link data rates and delays. The htsim translator infers fat-tree levels from topology and populates router and switch abstractions. ASTRA-sim’s GPU model, the new "GPUModel," then co-simulates each cache-line-sized wave-front request over the per-component queues and NoC and through the off-chip fabric instantiated by the chosen translator (Won et al., 9 Jun 2026).

The paper presents a Clos-fabric ring AllReduce case study to validate expressiveness and cross-backend consistency. The workload is a ring AllReduce of $V$0 MiB per GPU on eight GPUs connected through a two-layer Clos. The leaf layer contains 8 leaf switches, each with 8 downlinks to GPUs and 4 uplinks to aggregation switches. The aggregation layer contains 4 switches, each with 8 downlinks to leaves and 4 uplinks to core, with core omitted at this small scale. Using InfraGraph’s SingleTierFabric and ClosFabric blueprints with per-link annotations of $V$1 Gb/s and $V$2 ns, ASTRA-sim 3.0 with ns-3 produced an achieved bus bandwidth of $V$3 Gb/s, a ring AllReduce completion time of $V$4 $V$5s, and a minimum packet FCT of $V$6 $V$7s, compared with standalone $V$8 $V$9s, with no drops (Won et al., 9 Jun 2026).

The reported interpretation is also explicit. The experiment underlines the ease of describing a real-world two-layer Clos in approximately 15 lines of DSL, the ability to swap from ns-3 to the $E \subseteq V \times V$0–$E \subseteq V \times V$1 "Simple" model without rewriting topology, and quantitative validation that the chosen link rates, latencies, and forging of on-chip contention accurately reflect expected end-to-end performance. In ASTRA-sim 3.0, InfraGraph is therefore both a representation and a reproducibility mechanism.

4. InfraGraph-like graph construction from RGB–depth data

A distinct use of the term appears in a graph generation pipeline for critical infrastructures based on heuristics, images, and depth data. Here the pipeline converts multi-view RGB–depth images into a relational graph $E \subseteq V \times V$2 in which nodes represent physical assets such as pipes, pumps, tanks, valves, and sprinklers, and edges model their pairwise connections. The pipeline has five principal stages: RGB–Depth Acquisition, Object Detection & Pose/Segmentation, Cross-Image Instance Matching, Heuristic-Based Relation Inference, and Graph Construction & Refinement. The hardware is a stereo RGB camera producing synchronized $E \subseteq V \times V$3 pairs at $E \subseteq V \times V$4 with $E \subseteq V \times V$5, and the output per frame $E \subseteq V \times V$6 is an RGB image $E \subseteq V \times V$7, a depth map $E \subseteq V \times V$8, and a camera pose $E \subseteq V \times V$9 (Diessner et al., 8 Dec 2025).

The detection stage separates non-pipe and pipe objects. Non-pipe objects use YOLOv8-Pose with the largest backbone pre-trained on COCO and output a bounding box, class $\tau_V$0, confidence $\tau_V$1, and keypoints $\tau_V$2, with $\tau_V$3 for tank and $\tau_V$4 for pump or valve. Training uses a dataset of 526 images, comprising 280 real and 246 synthetic images, with Adam, $\tau_V$5, for 150 epochs. Pipe objects use YOLOv8-InstanceSeg with the largest backbone pre-trained on COCO, outputting a bounding box, class $\tau_V$6 pipe, confidence $\tau_V$7, and mask $\tau_V$8. Training uses 1030 images, comprising 280 real and 750 synthetic images, with Adam, $\tau_V$9, for 200 epochs. Both models use random horizontal flip, scale jitter of $\tau_E$0, hue/saturation/exposure of $\tau_E$1, batch size 16, and validation that monitors $\tau_E$2 for detection and mask AP for segmentation (Diessner et al., 8 Dec 2025).

Cross-image matching combines geometric projection and clustering. For non-pipe detections $\tau_E$3 and $\tau_E$4, all pairwise 3D distances $\tau_E$5 between projected voxels are computed, and detections are merged if

$\tau_E$6

For pipes, each mask is projected into 3D via the pinhole model and depth, cleaned via DBSCAN with statistical outlier removal, and matched across views by 2D overlap after reprojection and by 3D validation with cluster separation at least 10 cm. Relation inference then computes endpoints for each merged instance. For non-pipe objects, endpoints are averages of keypoints with outliers beyond $\tau_E$7 discarded. For pipes, endpoint computation depends on whether the fitted minimum-area rotated bounding box is "straight" or "non-straight." Initial edges are formed by sorting unordered endpoint pairs by Euclidean distance and adding an edge when the distance is within graph_connections_max_distance and neither endpoint is already linked twice, followed by rule-based pruning under degree, isolation, and cycle constraints (Diessner et al., 8 Dec 2025).

The graph representation is explicit: nodes $\tau_E$8 have attributes class(v_k) in $\tau_E$9Pump, Tank, Valve, StraightPipe, BentPipe, Reducer, PipeCrossing$\Pi_V$0 and 3D centroid location; edges $\Pi_V$1 are undirected with weight $\Pi_V$2; storage is as an adjacency list plus attribute dictionary, for example JSON; and graph-theoretic notation includes an adjacency matrix $\Pi_V$3 and degree vector $\Pi_V$4 (Diessner et al., 8 Dec 2025).

5. Security-posture InfraGraph and AI-generated attack graphs

A third usage describes InfraGraph as a holistic, end-to-end platform for automated infrastructure security posture analysis. Drawing on the Graphene architecture, the pipeline consists of five major modules—asset discovery, vulnerability mapping, attack graph construction, exploitability evaluation, and scoring—tied together by an orchestration layer. Inputs include network topology, device types, operating systems, and installed software versions. The system queries the National Vulnerability Database for matching CVEs through CPE entries, performs NER extraction with a fine-tuned transformer encoder such as RoBERTa plus a transition-based or finite-state-transducer decoder, and tags six entity types in each CVE description: affected product, vulnerability type, root cause, impact, attacker type, and attack vector. These entities are packed into attack-graph node ports as preconditions, postconditions, inputs, and outputs (Jin et al., 2023).

Attack-graph construction creates one node per CVE, a root attacker node, and one or more sink CWE nodes. Edges are added from the attacker to every CVE, from $\Pi_V$5 to $\Pi_V$6 when postconditions$\Pi_V$7 semantically match preconditions$\Pi_V$8 above a threshold $\Pi_V$9, and from each CVE to its associated CWE node or nodes. Matching is performed in a security-domain embedding space using CBOW and Skip-Gram models trained on a corpus of more than 60K or 62K security documents, with cosine similarity as edge weight and $\Pi_E$0 to prune spurious edges while preserving realistic multi-step chains. InfraGraph can also extract subgraphs for hardware, system, network, cryptography, and optionally machine-learning layers (Jin et al., 2023).

The scoring model is recursive and layer-aware. For an edge $\Pi_E$1 with source node $\Pi_E$2,

$\Pi_E$3

taken over incoming edges $\Pi_E$4. For an edge $\Pi_E$5 with sink node $\Pi_E$6,

$\Pi_E$7

taken over outgoing edges $\Pi_E$8. Edge risk is

$\Pi_E$9

Path exploitability may be written as

$$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$0

or as a sum of log-probabilities, and an overall security score may be defined as

$$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$1

or through a weighted sum over top-$$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$2 paths. Cross-layer dependencies are represented both structurally, through inter-layer edges, and parametrically, through layer-specific scoring functions and criticality weightings (Jin et al., 2023).

The reported evaluation includes a representative edge-cluster case study with Jetson Nano servers, TP-Link switches, Raspberry Pi endpoints, and OpenSSL. In that setting, InfraGraph identified 99 relevant CVEs and built a cumulative graph of 100 nodes—1 attacker, 80 CVEs, and 19 CWE sinks—and approximately 27,300 simple attack paths. The paper reports NER inference at 0.023 s/CVE, embedding lookup and edge building at 0.0017 s/pair, graph assembly plus exploit, impact, and risk scoring at 0.02 s, and full risk analysis at 1.19 s. Layer-wise risk scores normalized to $$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$3 are reported for cumulative, network, hardware/system, machine-learning, and cryptography views, and CVE-2020-15206, CVE-2020-5215, and CVE-2021-29540 are flagged as top-critical because each appears in the minimum vertex cover of size 50 vulnerabilities whose patching would break all attack paths (Jin et al., 2023).

6. Comparative interpretation across domains

Across the cited works, InfraGraph denotes three different graph objects. In ASTRA-sim 3.0, it is a directed, attributed infrastructure graph spanning on-chip and scale-out communication components, designed for backend translation and simulation fidelity (Won et al., 9 Jun 2026). In the RGB–depth pipeline, it is a relational graph over detected physical assets, produced through photogrammetry, 3D reconstruction, and heuristic relation inference, with undirected weighted edges and rule-based refinement (Diessner et al., 8 Dec 2025). In the security-posture platform, it is a directed attack graph over vulnerabilities, attacker states, and CWE sinks, enriched by semantic matching and recursive exploitability and impact scoring (Jin et al., 2023).

These differences are substantial. The ASTRA-sim formalism emphasizes hardware composition, typed links such as PCIe, NoC, Ethernet, and InfiniBand, and backend-agnostic reproducibility. The photogrammetry pipeline emphasizes acquisition, detection, segmentation, instance matching, endpoint estimation, and rule-based graph cleaning, with explainability tied to explicit heuristics rather than relational GNNs. The security platform emphasizes CVE ingestion, NER, embedding-based semantic linking, graph-database orchestration, and multi-layer risk scoring. The graph semantics therefore differ at the level of node ontology, edge directionality, weighting, and downstream computation.

At the same time, the three usages share a recognizable family resemblance. All treat infrastructure as a graph $$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$4; all attach semantics to vertices and edges rather than using an untyped connectivity graph; and all use the graph as an operational intermediate representation rather than as a purely descriptive artifact. In one case the graph drives collective communication and GPU co-simulation, in another it supports digital-twin-like reconstruction of hydraulic systems, and in the third it supports attack-path generation and security scoring. A plausible implication is that "InfraGraph" functions in current literature as a graph-native interface between raw infrastructure data and domain-specific reasoning engines.

7. Research significance and limitations of the label

The principal research significance of the ASTRA-sim 3.0 version of InfraGraph lies in standardization and reproducibility. By unifying every hardware component and link into one portable graph and making every backend consume the same graph, it removes ad hoc per-simulator topology formats and makes backend comparisons less sensitive to input mismatches (Won et al., 9 Jun 2026). The significance of the photogrammetry-based pipeline lies in combining cost-effective RGB–depth acquisition, deep-learning detectors, 3D reconstruction, and transparent heuristics to generate relational graphs for critical infrastructures, with edge decisions traceable to explicit rules and thresholds (Diessner et al., 8 Dec 2025). The significance of the security-posture platform lies in full automation of CVE discovery and semantic parsing, a domain-specific embedding space for cross-vulnerability matching, and a recursive scoring model that propagates exploitability and impact along directed attack graphs (Jin et al., 2023).

The main limitation of the term is terminological rather than methodological. The literature does not present a single cross-domain InfraGraph standard encompassing all three uses. Instead, one paper introduces a backend-agnostic schema for distributed-ML infrastructure, another describes an InfraGraph-like graph-generation pipeline for critical infrastructures, and a third uses the name for an AI-driven security analysis platform. This suggests that any technical discussion of InfraGraph should be anchored to its domain context: simulation, physical infrastructure reconstruction, or cybersecurity.

For researchers, the term is therefore most precise when accompanied by the underlying graph model and task. In ASTRA-sim 3.0, that means the directed attributed graph $$\{cpu, gpu\_cu, gpu\_hbm\_channel, nic\_port, asic\_port\}$$5; in photogrammetric reconstruction, the relational graph with class-labelled assets and weighted undirected edges; and in security analysis, the attack graph with CVE nodes, semantic edges, and recursive risk scores.