arXiv:2606.18105v1 [cs.NI] 16 Jun 2026
OmniPlan: An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization Longlong Zhu
Jiashuo Yu
Zedi Chen
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Yuhan Wu
Zhifan Jiang
Yuchen Xian
College of Computer and Data Science Fuzhou University Fuzhou, Fujian, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Yimeng Liu
Jiajie Su
Shaopeng Zhou
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Xingyuan Li
Hongyan Liu
Xuan Liu
Zhejiang University Hangzhou, Zhejiang, China [email protected]
Fuzhou University Fuzhou, Fujian, China [email protected]
Yangzhou University Yangzhou, Jiangsu, China [email protected]
Dong Zhang
Chunming Wu
Xiang Chen∗
College of Computer and Data Science Fuzhou University Fuzhou, Fujian, China [email protected]
Zhejiang University Hangzhou, Zhejiang, China [email protected]
The State Key Laboratory of Blockchain and Data Security College of Computer Science and Technology Zhejiang University Hangzhou, Zhejiang, China [email protected]
Abstract Network planning optimization is a fundamental problem across diverse domains, including transportation systems, communication networks, and power grids. It requires simultaneous optimization of multiple competing objectives under complex constraints. Existing network planning optimization frameworks rely on mixed integer programming (MIP) solvers, heuristics, and deep reinforcement learning (DRL) models to compute planning decisions. However, they lack effective adaptability to diverse and dynamic user intents, thus leading to the trade-off between execution time and optimality. In this paper, we propose OmniPlan, an adaptive framework that achieves both timeliness and near-optimality in network planning optimization. To achieve the adaptability lacking in existing solutions, OmniPlan employs a large language model (LLM)-based interpreter to convert heterogeneous natural-language intents into a unified and quantifiable user-preference vector. Then it employs a
mixture-of-experts architecture that integrates MIP solvers, heuristics, and DRL models as specialized experts, where OmniPlan adapts to diverse intents by dynamically selecting timely and near-optimal experts. Finally, it incorporates a DRL-based expert configuration module that fine-tunes optimization objective weights to align planning decisions with user-specific preferences. We evaluate OmniPlan with a representative real-world workload, i.e., distributed machine learning (ML), where we leverage OmniPlan to offload a wide spectrum of ML inference tasks, e.g., decision trees, SVM, naive Bayes, XGBoost, and random forests, onto a network of hardware devices. Our experiments on a real-world testbed indicate that OmniPlan achieves near-optimal and low-execution-time offloading for real-world ML inference tasks, reducing latency by up to 97.8% and network device resource consumption by up to 11.5%.
Keywords ∗ Xiang Chen is the corresponding author.
Accepted by ACM KDD 2026.
Network Planning Optimization; Large Language Model; Mixtureof-experts; ML Inference Offloading
Longlong Zhu et al.
1
Introduction
Network planning optimization is fundamental to infrastructure systems, e.g., transportation networks, communication systems, and power grids [9, 14, 31, 37]. It requires simultaneous optimization of multiple competing objectives from the user intent, e.g., minimizing delay, maximizing throughput, and minimizing resource usage, under complex constraints. For example, in communication networks, operators need to deploy services across distributed network devices to minimize end-to-end latency while reducing resource usage, with respect to device resource capacity and link bandwidth constraints [7, 25]. To achieve near-optimal planning, existing network planning optimization frameworks typically leverage mixed integer programming (MIP) solvers, heuristics, and deep reinforcement learning (DRL) models to compute planning decisions. However, prior studies suffer from the trade-off between execution time and optimality, leading to either long execution time or significant optimality loss. (1) MIP-based approaches formulate network planning optimization as an MIP problem [12, 15, 18, 21, 32] and leverage off-the-shelf MIP solvers to compute optimal planning decisions. However, they suffer from a long execution time to search for new decisions when the input task changes due to the need to enumerate points within the large solution space. (2) Heuristic-based approaches [6, 7, 25] introduce dedicated heuristics for computing near-optimal planning decisions in polynomial time. However, they suffer from significant optimality loss when the input task changes since heuristics are designed for specific optimization tasks. (3) DRL model-based approaches achieve near-optimal network planning for different tasks [30, 43, 45]. Here, they meet the need of dynamically computing planning decisions for new incoming tasks via trained DRL agents with respect to the specific user intent. However, they suffer from significant optimality loss when user intent changes since they are typically built for specific user intents. Otherwise, they require time-consuming retraining or redesign to support new user intents. At the core, existing solutions fall short because they fail to adapt to changing user intents, facing the trade-off between execution time and optimality. In response, we observe that the powerful semantic understanding capability of large language models (LLMs) and the dynamic adaptability in handling heterogeneous tasks of the mixture-of-experts (MoE) architecture can offer an opportunity to address this trade-off. More precisely, LLMs exhibit strong semantic understanding capabilities [35, 44] that enable them to comprehend and reason about diverse user intents expressed in natural languages. Furthermore, MoE that combines multiple experts and selectively activates the most suitable experts for each input [27] has been widely applied across numerous applications, such as network planning optimization [9], natural language processing [19, 47], and multi-modal learning [29, 36, 41]. MoE shows exceptional adaptability to different optimization objectives and can activate suitable experts for specific input user intent. In this paper, we propose OmniPlan, an adaptive framework for timely and near-optimal network planning optimization. To address the lack of adaptability to diverse and dynamic intents, OmniPlan leverages LLMs to understand user intents, based on which it activates timely and near-optimal experts within the MoE architecture. More precisely, OmniPlan first interprets heterogeneous natural
language intents of network planning into a unified and quantifiable user preference vector via LLMs. Second, OmniPlan adapts to different intents by activating timely and near-optimal experts. It selectively activates fast DRL/heuristic-based experts that compute near-optimal planning decisions and optimal solver-based experts that are pre-configured for optimizing specific intents. Third, OmniPlan tailors planning decisions to the specific user intent by configuring weights of optimization objectives in the activated expert. Here, values within the preference vector cannot be directly applied as weights in solvers due to dimensional heterogeneity, so OmniPlan dynamically adjusts weights of optimization objectives via intent-aware DRL-based expert configurations. Contributions. We make the following contributions. • We propose OmniPlan, an adaptive framework for timely and near-optimal network planning optimization. It converts natural language intents into a quantifiable preference vector via LLMs. • We propose a dual-channel activation approach that activates fast DRL or heuristic experts for near-optimal planning and optimal MIP experts for a specific set of optimization objectives. • We develop a DRL-based expert configuration approach that dynamically adjusts weights within the activated experts, tailoring decisions to specific user intents. • We implement the OmniPlan prototype and evaluate it on a representative real-world workload, i.e., distributed ML, where we leverage OmniPlan to offload a wide spectrum of ML inference tasks [46] onto a network of hardware devices. The experimental results show that OmniPlan achieves near-optimal and low-execution-time offloading for real-world ML inference tasks, reducing network device resource consumption by up to 11.5% and latency by up to 97.8%.
2 Background and Motivation 2.1 Existing Works and Limitations Existing network planning works can be typed into three classes, including MIP solvers, heuristics, and DRL model-based solutions. MIP solvers-based solutions [3, 5, 12, 18, 26, 32, 38] formulate the network planning task as an MIP problem, preserving optimality at the cost of long execution time. They leverage MIP solvers like Gurobi [16] and CPLEX [8] to compute optimal planning decisions. For example, SPEED [25] formulates the resource allocation task in a communication system as an MIP problem, aiming at minimizing resource consumption and end-to-end latency. However, they consume high computational overhead for enumerating points within the large solution space, which leads to extensive execution time. Heuristics. Heuristic-based solutions [6, 7, 25] compute planning decisions in time, but suffer from optimality loss. They develop dedicated heuristic algorithms, such as greedy-based, rounding-based, and Bender’s decomposition-based algorithms, for specific planning tasks. Thus, they can obtain near-optimal planning decisions in polynomial time. For example, Hermes [6] develops a greedy-based task partitioning heuristic for minimizing coordination overhead across network nodes. However, heuristics are tailored for specific tasks, which results in optimality loss when user intents change. DRL models. DRL models cannot navigate the trade-off between execution time and decision quality when input tasks change. DRL models [30, 43, 45] are typically used for service orchestration. For
OmniPlan : An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization
example, Dapper [45] combines DRL and graph convolutional networks to compute near-optimal orchestration decisions in time. Here, we can leverage the adaptive learning capabilities of DRL models to meet the need of dynamically computing planning decisions for new incoming tasks with respect to a specific intent. However, they need to be retrained or even redesigned for different types of user intents; otherwise, they suffer from high optimality loss. In this case, the retraining or redesigning requires a high engineering cost since their performance depends on model designs, while constructing complex DRL models is labor-intensive [9, 35]. For example, deep neural networks (DNNs) contain thousands to billions of neurons, which require day-level tuning time [35].
2.2
Opportunities of LLMs and MoE
MoE is a neural network architecture that combines multiple experts with a gateway network to selectively activate the most appropriate experts for each input [27]. It offers significant advantages in terms of parameter and model scaling efficiency by activating only a subset of parameters for each inference [34, 42]. Thus, it has been widely applied across diverse domains, such as network planning optimization [9], natural language processing [19, 47], computer vision [13, 23, 39], and multi-modal learning [29, 36, 41]. Inspired by MoE’s successes, we explore its application in network planning optimization. It brings the opportunity to address the challenge of intent-adaptive near-optimal planning [9, 10]. In detail, it can integrate multiple specialized planning experts, each optimized for a specific task. It employs a gating network to selectively activate a few experts tailored for specific inputs. Thus, it allows for dynamic expert activation based on user intents. Moreover, LLMs offer a promising approach that achieves intentaware network planning thanks to their semantic understanding and timely decision-making capabilities [35, 44]. Compared to traditional planning approaches, LLMs can comprehend complex planning requirements expressed in natural languages, e.g., interpreting user intents and translating them into specific optimization objectives. This semantic understanding enables LLMs to dynamically adjust optimization priorities based on specific contexts and network dynamics, allowing them to achieve intent-aware planning. By combining LLMs with specialized experts via an MoE architecture, we can achieve both near-optimal and intent-aware network planning. In particular, such a combination allows us to avoid designing a new specialized DRL model or heuristic for each planning task or intent, which significantly reduces engineering costs while maintaining high-quality planning decisions. Furthermore, we integrate diverse types of planning experts, including but not limited to DRL-based models, and use the LLM as an orchestrator that interprets user intents and activates the most suitable expert(s) for the given planning context.
2.3
LLMs and MoE for Network Planning
Recent studies apply LLMs and MoE to network planning tasks. On the LLM side, they explore network service placement [24], traffic management [2, 20], and job scheduling [35]. On the MoE side, the MoE architecture is applied to LLM-assisted network planning applications. It enables reducing the need for task-specific model training [9] and deploying experts on resource-constrained network
infrastructures, such as access points, edge servers, and mobile devices [40]. These works address different aspects and can be integrated with OmniPlan in a complementary manner.
3
Overview
We propose OmniPlan to break the trade-off between execution time and optimality under heterogeneous intents. Key ideas. OmniPlan aims to achieve two goals: (1) G1: optimal or near-optimal and fast planning that achieves low execution time while maintaining solution quality, and (2) G2: intent-aware planning that computes near-optimal planning decisions under different user intents without redesigning and retraining. To achieve these goals, the key idea of OmniPlan is to leverage LLMs to understand user intents and activate suitable experts within the MoE architecture to achieve intent-adaptive planning. Here, LLMs understand a wide variety of natural language input user intents (achieving G2) and MoE dynamically activates suitable experts for given intents without redesigning and retraining (achieving G1). OmniPlan workflow. OmniPlan executes three major steps. Step#1: Intent translation. OmniPlan interprets heterogeneous input user intents described in natural language into a unified and quantifiable preference vector 𝑠 via LLMs, where 𝑠 is a normalized preference vector consisting of some optimization objectives. By 𝑠, OmniPlan captures optimization priorities within input intents. Step#2: Expert activation. OmniPlan activates suitable experts based on the interpreted vector 𝑠 and expert scores. For intents where the weight of a specific objective within 𝑠 exceeds the threshold 𝜏 (e.g., 𝜔 lat ≥ 0.9), OmniPlan only activates a DRL model or heuristic-based expert that computes near-optimal planning decisions in time. Otherwise, in addition to the selected expert for timely planning decisions, OmniPlan activates a solver-based expert that computes optimal planning decisions. Here, the speedup of OmniPlan comes from avoiding expensive solvers when a near-optimal heuristic suffices. We develop DRL model-based and heuristic-based experts for different categories of planning intents, including nodelevel, link-level, and network-wide intents. We also develop MIP solver-based experts with typical optimization objective configurations. For example, we can build an expert with a configuration that minimizes the weighted sum of resource overhead and latency, with optimized weights assigned to each objective. Step#3: Expert configuration. For the activated expert in Step#2, OmniPlan configures it to fit the user intent. More precisely, values within the preference vector cannot be directly applied as weights in solvers, because solvers cannot normalize performance metrics, and direct adoption distorts optimization outcomes as magnitude differences dominate user intent. Thus, OmniPlan employs an intentaware DRL-based expert configuration approach to tune weights within the optimization objectives in the activated solver-based expert. Here, OmniPlan develops an intent-aware scoring approach that maps the non-uniformly distributed intent space to a uniform scoring space, where OmniPlan quantifies the alignment between expert configurations and user intents. Then, the DRL agent integrates this intent-aware score into its state space and reward function to fine-tune optimization objective weights for achieving better performance for the input intent.
Longlong Zhu et al.
User
Expert Library
MIP Solvers
“First consider the data center power consumption, and deploy more MLs”
Gurobi CPLEX
Translate the natural language intent via LLMs
User Preference Vector s
Heuristics
DRL models
Greedy-based Algorithm min A(u, v)
R = λ1 · Coverage − λ2 · Hop − λ3 · Resource
Selection of Experts
0.3 * O1 0.7 * O2 Input s = {0.3, 0.7, 0, 0, 0, 0, 0}
Fast
Activate DRL or Heuristic-based Expert
Optimization Objectives O1: Min Resource Overheads
O2: Min Power Consumption
O3: Max Throughput
O4: Min Latency
O5: Min Inter-Switch Coordination Overheads
Optimal
Activate Solver-based Expert
System Context
RL-based Expert Configuration
rt+1
Environment Score Vec. s
s
Weight ω
ωt+1 = shift_softmax(ωt , lrt) action at = lrt
state St+1 = ⟨st +1⟩ reward rt
Agent ωt+1
The Configured Expert
O6: Min Number of Hop O7: Max the Coverage
Step#1: Intent Translation
The Activated Expert
Check s
Offloading Decisions
Step#2: Expert Activation
Step#3: Expert Configuration
Figure 1: The architecture of OmniPlan.
4
Intent Translation
Challenges. The network planning task needs to handle diverse optimization objectives arising from heterogeneous task requirements, such as minimizing latency for time-sensitive tasks and maximizing throughput for data-intensive tasks. Here, user intents may contain multiple objectives. For example, the intent of “offloading more tasks in a green data center” involves minimizing both hardware resource overhead and power consumption. Consequently, the user intent exhibits significant diversity since the objective combination is varied. Meanwhile, it is challenging to quantify user evaluations of varying degrees semantically and transform them into evaluation scores that are uniformly distributed between 0 and 1. For example, the model must differentiate the subtle nuances between semantically similar terms like “high” and “great”, while capturing the vast disparity between opposing terms such as “little” and “greatest”. Key ideas. To handle diverse user planning intents, we build three fundamental intent categories. Then, we use an LLM-powered intent translation layer to convert user natural language into standardized textual representations. Finally, we propose an intent-aware scoring approach that maps intents, which are non-uniformly distributed in the textual space, to a quantified scoring space. Fundamental intents identification. We summarized that most of the network planning intents can be decomposed into three fundamental intent classes. We identify these types of intents based on their optimization scope. (1) Node-level intents involve minimizing power consumption, resource consumption, and others. We formulate this class of intents as min 𝜔 pwr , and min 𝜔 res . (2) Link-level intents include maximizing end-to-end performance and reducing inter-device coordination overhead. This class is related to optimization objectives that minimize the inter-device overhead and maximize the end-to-end processing performance. We formulate this class of intents as max 𝜔 thr , 𝜔 lat , and min 𝜔 coor . (3) Networkwide intents refer to optimization objectives that involve minimizing the hop counts, maximizing the coverage rate, and others. We formulate these intents as min 𝜔 hop , and max 𝜔 cover Intents translation via LLMs. We formulate intent translation as a constrained API call to LLMs, where natural-language input 𝑢 is
mapped to standardized textual representations T . More precisely, we execute a domain-engineered prompt function P : U → T , i.e., P (𝑢) = 𝜏net + 𝑢 + 𝜏format
(1)
where 𝜏net = “As a network planning optimization expert, retain the description from the user regarding the following specific optimization objectives: power, device resources, throughput, latency, inter-device coordination overhead, hop count, coverage. If no specific requirement is provided, mark the corresponding optimization objective as 𝑑𝑒 𝑓 𝑎𝑢𝑙𝑡 = 0 ”. User intent: “𝑢”. 𝜏format = “Output formats: [T1, . . . , T7 ]”. Intent-aware scoring. It converts the standardized textual representations into scores, comprising four main steps: Step#1: Intent curve construction. We first define 𝐾 intent anchor points 𝑆 0, 𝑆 1, . . . , 𝑆𝐾 −1 that semantically and uniformly describe a gradual progression from “no demand” to “greatest demand”. For example, 𝑆 0 = “The user has no demand”, 𝑆 1 = “The user has a little demand”, and up to 𝑆 4 = “The user has the greatest demand”. By the pre-defined sentence-BERT model, we encode these anchors into vectors 𝑝 0, 𝑝 1, . . . , 𝑝 𝐾 −1 . Then, to capture the non-linear distribution of intents in high-dimensional space, we use cubic spline interpolation to construct a smooth curve L (𝜃 ) between anchor points, where 𝜃 ∈ [0, 𝐾 − 1] is the curve parameter that satisfies L (𝑖) = 𝑝𝑖 . Step#2: Intent curve mapping. To map the non-uniform intent curve to a uniform scoring space, we compute the arc-length be∫ 𝑖+1 tween adjacent anchor points 𝐿𝑖,𝑖+1 = 𝑖 ∥ 𝑑 L𝑑𝜃(𝜃 ) ∥𝑑𝜃 , and define 1 the arc-length weight for each segment as 𝜙𝑖,𝑖+1 = 𝐿𝑖,𝑖+1 . Here, regions with large semantic gaps (i.e., long arc-length) are normalized with smaller weights to ensure a uniform scoring progression. By this mapping, we obtain a uniform intent-aware scoring space. Step#3: Per-objective demand scoring. For each objective 𝑂𝑖 , given its standardized textual representations T𝑖 , we first compute its embedding vector 𝑝𝑢𝑖 = BERT(T𝑖 ). Then, we find the closest projection point on our intent curve L (𝜃 ), i.e., 𝜃 𝑖∗ = arg min𝜃 ∈ [0,𝐾 −1] ∥L (𝜃 )−𝑝𝑢𝑖 ∥. Finally, its score is calculated through
OmniPlan : An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization
Algorithm 1 Dual-channel Expert Activation
weighted arc-length integration, i.e., 1 score(T𝑖 ) = 𝐾 −1
∫ 𝜃∗ 𝑖
0
𝑑L (𝜃 ) 𝑑𝜃 𝜙 (𝜃 ) · 𝑑𝜃
(2)
which yields a per-objective score vector. These scores are then Í𝑀 𝜔𝑖 = 1, producing the final preference normalized to ensure 𝑖=1 weight vector 𝑠 ∈ R𝑀 , i.e., s = [𝜔 res, 𝜔 pwr, 𝜔 thr, 𝜔 lat, 𝜔 coor, 𝜔 hop, 𝜔 cover ]
(3)
Require: Intent score vector s, the set of heuristic or DRL model-based fast expert Efast , the MIP solver-based expert 𝐸 MIP , threshold 𝜏 Ensure: Activated expert set Eact 1: 𝐹𝑙𝑎𝑔high ← {𝜔𝑖 | 𝜔𝑖 ≥ 𝜏 } 2: if |𝐹𝑙𝑎𝑔high | = 1 then 3: 𝑖 ∗ ← the element with max value in s 4: Eact ← {𝐸𝑘 ∈ Efast | 𝑒𝑘,𝑖 ∗ = 1} 5: else 6: for each 𝐸𝑘 ∈ Efast do e ·s 7: Sim(𝐸𝑘 ) ← ∥e 𝑘∥·∥s∥ 𝑘
The vector s can be extended to contain more than 7 objectives. By translating input intents into the preference vector 𝑠, OmniPlan handles most of the heterogeneous or unknown input intents.
5
Expert Activation
Challenges. Given a user intent score vector s, we need to select appropriate experts under user intents. Here, network planning must adapt to dynamic user intents. However, heuristics and DRLbased solutions only handle predefined intent patterns, and MIP solver-based solutions are confined to fixed objective sets. Key ideas. We build experts for the above intents. Then, OmniPlan adapts to different intents by activating suitable experts. It automatically and selectively activates fast DRL/heuristic-based experts that compute near-optimal planning decisions and optimal solver-based experts that are pre-configured for specific intents. Expert specialization. For each intent class, we deploy specialized optimization experts, including MIP solvers, heuristics, and learning-based experts. The details are as follows. (1) MIP experts: MIP solver-based experts leverage MIP solvers for s-weighted planning optimization objectives, formulated as Í𝑀 min 𝑖=1 𝜔𝑖 · 𝐶𝑖 , where 𝑀 is the number of objectives and 𝐶𝑖 denotes the performance value of objective 𝑖. More precisely, these experts integrate solver interfaces, such as CPLEX [8] and Gurobi [16], along with decision variable generators and constraint compilers. They can provide optimal solutions for specific objectives. Note that we pre-configure some MIP solvers with typical planning optimization intents [5]. For example, we pre-configure an expert to jointly minimize resource overhead and latency, with equal weights assigned to both objectives, i.e., min 0.5 · 𝐶 res + 0.5 · 𝐶 lat , where 𝐶 res and 𝐶 lat denote the resource consumption and end-to-end latency. (2) Heuristic experts: We build heuristic-based experts for fast and near-optimal network planning. Here, we develop experts who minimize resource overheads for node-level intent. We also build experts to minimize latency or minimize inter-device coordination overheads for link-level intents. For node-level intents, we prioritize tasks with higher dependency levels and larger resource demands [25]. Let V be the set of tasks, ℓ (𝑣) the dependency level of task 𝑣, and 𝑟 (𝑣) its resource overheads. The optimization priority is defined as Priority(𝑣) = −𝑎 · ℓ (𝑣) − 𝑏 · 𝑟 (𝑣), where 𝑎, 𝑏 > 0 are tunable weights. Tasks are greedily placed on devices in descending order of Priority(𝑣), subject to devices’ resource constraints. For link-level intents, we aim to minimize the metadata exchanged between devices [6]. We partition the task set V into disjoint subsets {V1, . . . , V𝑘 }, each of which can be placed on an individual hardware device. Let 𝐴(𝑢, 𝑣) denote the volume of
8:
∗ ← arg max Sim(𝐸 ) 𝐸 fast 𝑘
9: 10:
Configure 𝐸 MIP with weights s ∗ ,𝐸 Eact ← {𝐸 fast MIP }
𝐸𝑘 ∈Efast
11: return Eact
inter-device metadata transferred from task 𝑢 to task 𝑣. We formuÍ late the optimization objective as min (𝑢,𝑣) ∈ Ecross 𝐴(𝑢, 𝑣), where Ecross ⊆ E is the set of edges across task subsets. (3) Learning-based experts: We build learning-based experts based on DRL models. We build DRL model-based experts for networkwide intent, including maximizing task coverage by selecting task coordination paths and minimizing the number of hops within tasks by selecting task-placed devices. By learning from historical optimal decisions from MIP solvers, these experts provide nearoptimal decisions while maintaining low execution time. For example, we formulate the planning as a Markov Decision Process (MDP), where the agent observes the current planning state 𝑠𝑡 and selects an action 𝑎𝑡 (e.g., placing a task or selecting a path). This DRL model-based expert receives a reward 𝑅𝑡 = 𝜆1 · Coverage𝑡 − 𝜆2 · Hop𝑡 − 𝜆3 · Resource𝑡 . It learns Í a policy 𝜋 (𝑎|𝑠) that maximizes expected return, i.e., max𝜋 E 𝑇𝑡=0 𝛾 𝑡 · 𝑅𝑡 . Expert profiling. Each expert 𝐸𝑘 maintains a static capability vector e𝑘 ∈ R𝑀 , where 𝑒𝑘,𝑖 ∈ [0, 1] indicates the expert’s capability on objective 𝑖. For MIP experts, e𝑘 equals their pre-configured objective weights. For heuristic and DRL experts, e𝑘 is set based on their design purpose (e.g., a latency-minimizing expert has 𝑒 lat = 1 with other entries set to 0). Expert activation. Given an intent score vector s and expert profiles, we compute the similarity between user intent and each expert e ·s as Sim(𝐸𝑘 ) = ∥e 𝑘∥ · ∥s∥ . Then, we apply a dual-channel expert activa𝑘 tion strategy. We summarize this activation process in Algorithm 1. More precisely, OmniPlan first takes a user intent s as inputs. If s exhibits a dominant objective (e.g., only one 𝜔𝑖 ≥ 𝜏, 𝜔𝑖 ∈ s), OmniPlan activates a single fast-response expert 𝐸 𝑓 𝑎𝑠𝑡 , i.e., heuristic or DRL-based expert, to compute near-optimal planning decisions in time (lines 1-4). Otherwise, to balance execution time and decision optimality, OmniPlan activates a fast expert 𝐸 𝑓 𝑎𝑠𝑡 based on the similarity Sim(𝐸𝑘 ) between the intent score vector and each expert, while activating an MIP solver-based optimal expert 𝐸𝑀𝐼 𝑃 , which is configured by weights in s (lines 5-11). In this case, OmniPlan can leverage the output decisions of a fast expert to initialize decision variables in the Gurobi-based MIP solver, so that OmniPlan can warm-start the MIP solver for lower execution time.
Longlong Zhu et al.
6
DRL-based Expert Configuration
Challenges. Existing configurations for network planning focus on single-objective or specific objective sets, suffering from low planning performance under different intents [7, 25]. A strawman approach is using values in the vector s directly as weights in solvers. However, since solvers cannot normalize performance metrics, directly applying distorts optimization outcomes as the magnitude differences of performance metrics dominate user intent. Key ideas. In response, we pre-configure some MIP solver-based experts based on existing studies [3–7, 46]. To further improve the offloading performance of pre-configured MIP solver-based experts under different user intents, we leverage DRL to configure the weights of optimization objectives within the activated expert. Here, we use the historical optimal offloading decisions from MIP solvers to train the DRL agent. DRL-based expert configuration. We design a DRL agent to configure the optimization objective weights of the activated expert, where we integrate the above intent-aware scoring approach for achieving better planning performance for the given user intent. State space. The state S𝑡 integrates the current weight configuration with the intent score, i.e., S𝑡 = ⟨s𝑡 ⟩
Intent User Intent #1
User Intent #2
User Intent #3
Method SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
Latency (ms) 327.0 4420.8 13495.0 949.0 294.4 327.0 4420.8 13495.0 949.0 420.6 327.0 4420.8 13495.0 949.0 382.0
SRAM 42.701% 43.376% 46.401% 43.100% 42.547% 42.701% 43.376% 46.401% 43.100% 42.512% 42.701% 43.376% 46.401% 43.100% 42.490%
Í𝑀 Í𝑀 where Δ̄ W𝑡 = 𝑖=1 W𝑡,𝑖 = 𝑖=1 𝜔𝑡,𝑖 · Δ𝑡,𝑖 is the intent-weighted improvement, I[HL_sign(𝑡) > 0] is an indicator function that equals Í 1 when the trend is positive, and 𝑐 𝑗 ∈𝐶 I[violate(𝑐 𝑗 )] is a penalty for any constraint violation.
(4)
where s𝑡 = [𝜔𝑡,1, . . . , 𝜔𝑡,𝑀 ] is the per-objective score vector. Action space. Given 𝑀 objectives, where 𝑀 = 7, the action 𝑎𝑡 represents a learning rate adjustment factor lr𝑡 ∈ [−4, 4] that modulates the weight distribution. Here, the new objective weights 𝜔𝑡 +1 are computed iteratively from the previous weights 𝜔𝑡 using a shift-softmax transformation, i.e., 𝜔𝑡 +1 = shift_softmax(𝜔𝑡 , lr𝑡 ), where shift-softmax is defined as: ( 𝑥 if ℎ = 0 shift_softmax(𝑥, ℎ) = (exp(ℎ·𝑥 ) −1) ·Í 𝑥 (5) Í otherwise (exp(ℎ·𝑥 ) −1) Reward function. Given a weight configuration 𝜔𝑡 , we compute the normalized improvement of each optimization objective 𝑂𝑖 at time step 𝑡, i.e., Δ𝑡,𝑖 = 𝑑𝑖 ·
Table 1: (Exp#1) Latency and SRAM consumption under WAN (Internet2) topology. The best results are boldfaced, and the second-best results are underlined.
Perf𝑡,𝑖 − Perf𝑡 −1,𝑖 |Perf𝑡 −1,𝑖 |
7.1 (6)
where Perf𝑡,𝑖 is the performance value of objective 𝑂𝑖 at time step 𝑡, and 𝑑𝑖 ∈ {+1, −1} is a directional factor that unifies the notion of “improvement” (e.g., 𝑑𝑖 = −1 for latency, 𝑑𝑖 = +1 for throughput). Then, we weight each objective’s improvement by its corresponding intent score, i.e., W𝑡,𝑖 = 𝜔𝑡,𝑖 · Δ𝑡,𝑖
(7)
Next, we assess the overall performance trend using the HodgesLehmann estimator [17], which robustly captures central tendency through pairwise averages. Let {W𝑡,1, . . . , W𝑡,𝑀 } be the intentweighted n improvement samples, we o compute 𝜇 = hl_sign(W𝑡 ) = W +W
𝑡,𝑖 𝑡,𝑗 median | 1 ≤ 𝑖 ≤ 𝑗 ≤ 𝑀 . Here, 𝜇 indicates the overall 2 trend, i.e., whether performance improves or degrades. Finally, we define the reward 𝑟𝑡 , i.e., ∑︁ 𝑟𝑡 = Δ̄ W (𝑡) · I[𝜇 > 0] − 𝛽 · I[violate(𝑐 𝑗 )] (8)
𝑐 𝑗 ∈𝐶
7
Case Study: ML Inference Offloading
We evaluate OmniPlan through a representative case study of ML inference offloading, where ML inference tasks are offloaded onto the network of high-performance computing (HPC) hardware, e.g., Intel Tofino-series ASICs, and NVIDIA data processing units (DPUs) to achieve real-time traffic analysis. This scenario exemplifies network planning optimization with multiple competing objectives (e.g., resource utilization, latency, and throughput) under complex constraints (e.g., device capacity and link bandwidth). Further, OmniPlan is a domain-agnostic framework that can be extended to other network planning domains such as SFC placement and traffic engineering (see §8).
Experimental Settings
Testbed. We built a testbed consisting of two 12.8 Tbps HPC hardware devices [1] and two servers. The testbed is organized in a sequential topology, with the two HPC hardware devices located in the middle. The left server and the right server run MoonGen-based [11] traffic senders and traffic receivers, respectively. These devices are connected via 100-Gbps links. In addition, we use another server as the control plane, running the OmniPlan prototype and all comparison solutions. This server is directly connected to the devices in our testbed. Further, we leverage Mininet [28] to model larger network topologies containing a cluster of HPC hardware. Input tasks. We build 5 types of ML inference tasks, i.e., Naive Bayes (NB), Decision Tree (DT), Random Forest (RF), SVM, and XGBoost (XGB). These tasks represent advanced ML inference workloads that require significant HPC hardware resources and need optimization when co-offloaded [46]. Topology. We select two types of real-world topologies: (1) WAN topologies from the Internet Topology Zoo [22]. We configure link bandwidth to 10 Gbps. (2) DC topologies, i.e., the Fat-Tree topology. We randomly set the link latency between 1 us and 10 us [7].
OmniPlan : An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization
User intents. We evaluate OmniPlan with three user intents: (1) U#1: “Offload some ML inference tasks with high service performance”; (2) U#2: “Offload some tasks with higher throughput”; (3) U#3: “In a data center, offload multiple ML tasks with low latency.” Baselines. We compare OmniPlan with three types of solutions: (1) MIP solver-based frameworks. We choose SPEED-OPT (SPD-O) [5], which formulates ML inference task offloading as a mixed integer program that minimizes the weighted sum of hardware device resource overhead and end-to-end latency via Gurobi [16]. It computes optimal solutions under a fixed objective. (2) Domain-specific heuristics. We combine the first-fit-by-level-and-size (FFLS) heuristic [21] and the NodeRank heuristic [25] for minimizing device resource consumption and end-to-end latency, and name it SPEEDHeu (SPD-H). We also choose Hermes (HMS) [6], which minimizes inter-device coordination overhead via a greedy heuristic. (3) DRLbased solutions. We choose Dapper [45] (DP), a DRL-based SFC deployment framework. We adapt it for ML inference task offloading to minimize latency. It learns a placement policy under a fixed objective and requires retraining for new intents. LLM methodology. We use GPT-4o (accessed through OpenAI’s APIs) to interpret user intents. User inputs are processed as natural language text prompts. We employ carefully engineered prompts within the Dify [33] platform to guide structured output generation. Experts. We build an MIP solver-based expert using Gurobi [16], with pre-configured weights for multiple optimization objectives. We also built two greedy-based heuristic experts that minimize inter-device coordination overhead and intra-device resource consumption, respectively. Additionally, we built two DRL model-based experts to minimize the number of hops and end-to-end latency. We evaluate OmniPlan from the following research questions: • RQ1: How does OmniPlan perform on resource consumption and end-to-end performance under different tasks, topologies, and user intents? • RQ2: How does OmniPlan perform on execution time under different topology scales? • RQ3: How sensitive is the expert configuration of OmniPlan to the number of epochs? • RQ4: How much do the key modules of OmniPlan, i.e., dynamic expert activation and weight configuration, contribute to the overall performance?
7.2
Comparison Experiments (RQ1)
(Exp#1) OmniPlan achieves high performance when input intents change. We evaluate the latency and device resource consumption. Table 1 shows the offloading performance of OmniPlan and comparison solutions under three user intents and a WAN topology. Across user intents, OmniPlan achieves high performance on latency and resource consumption since it adapts to heterogeneous intents. Compared to baselines, OmniPlan reduces the latency by up to 97.8% under a WAN (Internet2) topology. Furthermore, OmniPlan also achieves optimal SRAM resource consumption. (Exp#2) OmniPlan achieves low intra-device resource overheads. We quantify the intra-device overhead via SRAM resource consumption. More precisely, we vary the input topologies and task numbers. We fix user intent as “offloading more ML inference
Table 2: (Exp#2) SRAM resource (i.e., intra-device resource) overhead under different task numbers. The best results are boldfaced, and the second-best results are underlined. # of Tasks SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
20 14.1% 14.3% 15.3% 14.1% 13.9%
40 21.4% 21.9% 23.8% 23.0% 21.3%
60 42.7% 43.4% 46.4% 43.1% 42.6%
80 60.9% 61.9% 66.0% 62.3% 61.0%
100 71.9% 71.6% 76.3% 79.2% 74.0%
Table 3: (Exp#3) PHV resource (i.e., inter-device coordination) overhead under different task numbers. The best results are boldfaced, and the second-best results are underlined. # of Tasks SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
20 13.2% 13.6% 14.9% 13.8% 13.1%
40 25.0% 26.0% 28.6% 25.2% 25.0%
60 40.9% 42.0% 46.1% 41.6% 40.7%
80 53.2% 54.8% 60.0% 53.9% 53.1%
100 68.9% 69.3% 75.6% 72.7% 72.4%
Table 4: (Exp#4) Latency across topologies and input task numbers. The “T#1” represents the Abovenet topology, “T#2” is the Internet2 topology, and “T#3” is a small FatTree topology. “T#1” and “T#2” are WAN topologies. “T#3” is a DC topology. “N/A” means all tasks are deployed on a single device, where the inter-device latency can be negligible. The best results are boldfaced, and the second-best are underlined. Topo T#1 Lat. (ms)
T#2 Lat. (ms)
T#3 Lat. (us)
# of Tasks SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
20 N/A 1026.8 1147.0 N/A N/A 66.0 1133.6 2178.0 143.0 108.0 N/A 120.3 42.3 N/A N/A
40 11.6 2119.4 3480.0 N/A N/A 79.0 3045.2 6785.0 637.0 123.0 N/A 571.6 176.7 N/A N/A
60 N/A 2947.4 8250.0 N/A N/A 327.0 4420.8 13495 949.0 459.0 0.4 812.2 463.5 N/A N/A
80 N/A 3970.6 10884 619.0 N/A 782.0 6977.4 20816 2243.0 1371.0 N/A 1252.5 864.3 36.3 N/A
100 62.0 5033.6 16020 2089.0 N/A 2889.0 8741.2 29200 8361.0 4129.0 0.3 1922.5 1280.6 137.5 N/A
tasks.” Then, we measure the SRAM resource consumption of OmniPlan and baselines. In Table 2, OmniPlan consumes fewer SRAM resources, reducing SRAM resources by up to 6.6% since we build and activate experts for minimizing intra-device overhead. (Exp#3) OmniPlan achieves low inter-device coordination overheads. We quantify the inter-device overhead by measuring packet header vector (PHV) resource consumption. More precisely, we fix the user intent the same as Exp#2. Then, we measure the PHV resource consumption of OmniPlan and baselines. In Table 3, OmniPlan achieves near-optimal offloading, reducing PHV resource overhead by up to 11.5%. (Exp#4) OmniPlan achieves high end-to-end performance. We evaluate the end-to-end performance of OmniPlan and baselines. We measure the latency under different input task numbers and topologies. We fix the user intent as “offloading more ML inference tasks while preserving low latency.” Table 4 shows the latency
Longlong Zhu et al.
Table 5: (Exp#5) Performance on DL inference workloads. The best results are boldfaced, and the second-best results are underlined. Workload
Method
SRAM (%)
Thpt. (Gbps)
YOLO-v5s
SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
16.214 16.227 16.178 16.127 16.067
2 7 2 8 8
BERT-base
SPD-O [5] SPD-H [25] HMS [6] DP [45] OmniPlan
21.365 21.425 21.420 21.560 21.455
1 6 2 8 8
Table 6: (Exp#6) Execution time (s) with a varying number of hardware devices (HD). “Fast” means achieving fast offloading and “Opt.” means achieving optimal offloading. OmniPlan achieves fast offloading by activating DRL or heuristicbased experts and achieves optimal offloading by activating solver-based experts. The best results are boldfaced. Fast
Opt.
Method SPD-H [25] HMS [6] DP [45] OmniPlan SPD-O [5] OmniPlan
8 HD 0.026 0.013 4.519 0.013 170.4 78.3
16 HD 0.028 0.022 4.957 0.022 601.6 245.7
24 HD 0.029 0.028 4.633 0.028 602.5 379.0
32 HD 0.039 0.038 4.435 0.038 602.9 435.0
of OmniPlan and baselines. OmniPlan achieves the near-optimal latency across topologies and task numbers. (Exp#5) DL inference workloads. We evaluate OmniPlan on two additional DL inference workloads, i.e., YOLO-v5s and BERT-base, and measure SRAM resource consumption and throughput. Table 5 shows that OmniPlan achieves high throughput while maintaining competitive resource consumption on both workloads.
7.3
Execution Time (RQ2)
(Exp#6) OmniPlan achieves low execution time. We measure the execution time of OmniPlan against baselines under topologies with different device numbers. OmniPlan achieves fast offloading by activating DRL or heuristic-based experts and achieves optimal offloading by activating solver-based experts. Thus, we measure the two execution time of OmniPlan. Table 6 indicates that in the fast offloading stage, OmniPlan takes less than 0.1 seconds to compute the offloading decisions, which is competitive to existing fast offloading solutions [6, 25, 45]. In the optimal offloading stage, OmniPlan also takes a shorter execution time than SPD-O [5] in most of cases, reducing execution time by up to 59.2%.
7.4
Sensitivity to Epoch Number (RQ3)
(Exp#7) Impact of epoch number on DRL-based expert configuration. We take the user intent, i.e., “I want to maximize the bandwidth with the highest priority, and then minimize the latency and SRAM usage as possible”, Internet2 topology, and 60 tasks as input. In the 6th epoch, OmniPlan achieves optimal offloading. We measure the latency, throughput, and SRAM resource consumption
Table 7: (Exp#7) Performance of OmniPlan in different configuration epochs. In the 6th epoch, the expert weight configuration has achieved the optimum, and OmniPlan automatically stops at the 7th epoch. Expert weights configuring Epoch ID
0
SRAM 42.6% Latency (ms) 691 Thpt. (Gbps) 3.0
Optimum
1
2
3
4
5
6&7
42.4% 310 9.0
42.6% 310 9.0
42.5% 509 6.0
42.4% 255 7.0
42.8% 314 9.0
42.4% 258 9.0
Table 8: (Exp#8) Impact of dynamic expert configuration. Intent type 1 2 3
Method Human-expert OmniPlan Human-expert OmniPlan Human-expert OmniPlan
Lat. (ms) 358 310 329 310 404 223
Thpt. (Gbps) 6 9 7 9 5 7
SRAM (%) 42.636 42.395 42.656 42.401 42.608 42.564
Table 9: (Exp#9) Impact of dynamic optimization objective weights on latency, hardware SRAM resource consumption, and throughput (i.e., Thpt.). “Equal” indicates that three optimization objectives are equally weighted. “Latency” means the weight for minimizing latency is set to 50%, while the other two objectives are weighted at 25% each. “Throughput” and “Resource” use the same pattern. The best results are boldfaced, and the second-best results are underlined. Method Equal Latency Throughput Resource OmniPlan
Latency (ms) 883.5 319.2 361.8 502.8 310.0
SRAM 42.568% 42.478% 42.437% 42.591% 42.534%
Thpt. (Gbps) 2.1 3.0 4.0 6.0 6.0
of OmniPlan in each epoch. Table 7 illustrates that compared to the original expert weights, the expert configuration of OmniPlan improves throughput by 3× and reduces the latency, while maintaining low SRAM resource consumption. Moreover, OmniPlan achieves the optimal configuration in epoch 6, which means that OmniPlan only requires a few configuration epochs. We put the weight values of each epoch in our appendix.
7.5
Ablation Analysis (RQ4)
(Exp#8) Impact of dynamic expert configuration. We compare OmniPlan with human-expert-tuned baselines. We invite 3 graduate researchers with network optimization experience to manually tune MIP objective weights for three additional types of intents beyond U#1-U#3. Each is given the MIP formulation, Gurobi, Internet2 topology with 60 tasks, and intent descriptions, with up to 10 weight configurations per intent. We report the best result among the 3 researchers. In Table 8, OmniPlan outperforms baselines across intents and metrics thanks to the DRL-based configuration. (Exp#9) Impact of dynamic weights. We evaluate the impact of dynamic expert weights in OmniPlan. More precisely, we take these optimization objectives, including minimizing latency, maximizing throughput, and minimizing HPC hardware device resources. We build four static weighted-based strawman solutions using Gurobi [16], including (1) equal weights for all objectives, i.e., “Equal”, (2)
OmniPlan : An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization
Table 10: (Exp#10) Comparison of intent translation methods on 50 diverse intents. The best results are boldfaced. Method
Translation Acc.
Activation Acc.
72% 22% 78% 82%
86% 34% 70% 92%
Rule-based Template-based Fine-tuned classifier LLM-based (Ours)
Table 11: (Exp#11) Robustness of expert activation Intent type
# Paraphrases
Min Cos-Sim
Avg Cos-Sim
10 10 10
0.811 0.711 0.707
0.965 0.910 0.877
1 2 3
assigning 50% of the weight to an objective, with the remaining two objectives sharing the rest equally, i.e., “Latency”, “Throughput”, and “Resource”. We take the user intents, i.e., U#1 to U#3, as our inputs for each objective. In Table 9, compared with static weightedbased groups, OmniPlan achieves the lower latency, which matches user intent U#1, i.e., “offload some ML inference tasks, where I need a high service performance” better. Also, for another two metrics, our results show a similar trend. (Exp#10) LLM-based translation. We compare the LLM-based intent translation in OmniPlan with three baselines on 50 diverse intents covering all 7 objectives, i.e., rule-based keyword matching, template-based matching with 20 regex templates, and a fine-tuned BERT classifier trained on 100 labeled pairs. We evaluate intent translation accuracy and expert activation accuracy. In Table 10, OmniPlan achieves the highest translation and activation accuracy. (Exp#11) Robustness of expert activation. We evaluate the robustness of expert activation in OmniPlan across 5 WAN topologies and 2 DC topologies with 3 types of intent. OmniPlan activates the same fast expert for each intent across all 7 topologies. We further generate 10 paraphrases per intent, e.g., “minimize delay”, “fast response”, and “latency is critical”. OmniPlan activates the same expert for each intent across paraphrases. Table 11 reports the cosine similarity between paraphrased and original intent vectors. The gap between the selected and second-best expert > 0.15 in all cases.
8
Discussion
Fallback for out-of-scope intents. For intents that involve objectives outside the current 7-dimensional space, OmniPlan applies a three-step fallback procedure. First, it flags the out-of-scope objective and maps it to the semantically closest existing dimension. Second, it notifies the user and presents two options, i.e., proceeding with the approximate mapping or registering a custom expert for the new objective. Third, it executes the chosen option, where newly registered experts are persisted for future planning requests.
9
Limitations and Ethical Considerations
Limitations and future works. OmniPlan relies on LLMs for intent interpretation, which may introduce microsecond to seconds of latency from API calls and potential hallucination in understanding complex or ambiguous intents. In the future, we plan to mitigate hallucinations via structured output enforcement and semantic validation against predefined anchors, with automatic re-query for
non-conforming outputs. We also plan to replace the API-based LLMs with fine-tuned local LLMs to reduce latency. We plan to use multi-vector representations to support more complex intent. Ethical Considerations. (1) Data privacy. Datasets and topologies used in this work are publicly available and user intents are synthetic and do not involve real user data. (2) Potential misuse. While OmniPlan is designed for legitimate network optimization, automated planning tools could theoretically be adapted for malicious purposes, such as optimizing attack traffic distribution. We encourage operators deploying such systems to implement appropriate access controls and audit mechanisms. (3) Consent and bias. This work does not involve human subjects, personally identifiable information, or decisions about individuals. Therefore, concerns regarding consent and bias toward specific demographic groups are not applicable.
10
Conclusion
In this paper, we have proposed OmniPlan, an adaptive framework for timely and near-optimal network planning optimization. Its key idea is to leverage LLMs to understand user intents and activate suitable experts within the MoE architecture to achieve intentadaptive planning. We evaluate OmniPlan on a representative case study, i.e., distributed machine learning (ML), where we leverage it to offload a wide spectrum of ML inference tasks onto a network of hardware devices. Our experiments on a real-world testbed have clearly demonstrated that OmniPlan achieves near-optimal and low-execution-time offloading for real-world ML inference tasks.
Acknowledgments This work is supported by the National Key R&D Program of China (2024YFB2906503), the National Natural Science Foundation of China (Grant No. 62602005), the Science and Technology Program of Fujian Province (Grant No. 2025H6007), and the Zhejiang Xinmiao Talents Program (Grant No. 2026R401172).
References [1] Barefoot Network. Barefoot Tofino. 2025. https://www.barefootnetworks.com/ technology/#tofino. [2] Rajarshi Chattopadhyay and Chen-Khong Tham. 2022. Mixture of Experts based Model Integration for Traffic State Prediction. In 2022 IEEE 95th Vehicular Technology Conference:(VTC2022-Spring). IEEE, 1–7. [3] Xiang Chen, Qun Huang, Peiqiao Wang, Hongyan Liu, Yuxin Chen, Dong Zhang, Haifeng Zhou, and Chunming Wu. 2021. MTP: Avoiding control plane overload with measurement task placement. In IEEE INFOCOM. 1–10. [4] Xiang Chen, Qun Huang, Peiqiao Wang, Zili Meng, Hongyan Liu, Yuxin Chen, Dong Zhang, Haifeng Zhou, Boyang Zhou, and Chunming Wu. 2021. Lightnf: Simplifying network function offloading in programmable networks. In 2021 IEEE/ACM 29th International Symposium on Quality of Service (IWQOS). IEEE, 1–10. [5] Xiang Chen, Hongyan Liu, Qun Huang, Peiqiao Wang, Dong Zhang, Haifeng Zhou, and Chunming Wu. 2020. SPEED: Resource-Efficient and HighPerformance Deployment for Data Plane Programs. In IEEE ICNP. 1–12. [6] Xiang Chen, Hongyan Liu, Qingjiang Xiao, Qun Huang, Dong Zhang, Haifeng Zhou, Boyang Zhou, Chunming Wu, Xuan Liu, and Qiang Yang. 2024. Hermes: Low-Overhead Inter-Switch Coordination in Network-Wide Data Plane Program Deployment. IEEE/ACM Transactions on Networking (2024), 2842–2857. [7] Xiang Chen, Qingjiang Xiao, Hongyan Liu, Qun Huang, Dong Zhang, Xuan Liu, Longbing Hu, Haifeng Zhou, Chunming Wu, and Kui Ren. 2024. Eagle: Toward Scalable and Near-Optimal Network-Wide Sketch Deployment in Network Measurement. In ACM SIGCOMM. 291–310. [8] CPLEX. 2025. https://www.ibm.com/analytics/cplex-optimizer. [9] Hongyang Du, Guangyuan Liu, Yijing Lin, Dusit Niyato, Jiawen Kang, Zehui Xiong, and Dong In Kim. 2024. Mixture of experts for network optimization: A large language model-enabled approach. arXiv preprint arXiv:2402.09756 (2024).
Longlong Zhu et al.
[10] Hongyang Du, Ruichen Zhang, Dusit Niyato, Jiawen Kang, Zehui Xiong, Shuguang Cui, Xuemin Shen, and Dong In Kim. 2023. User-centric interactive AI for distributed diffusion model-based AI-generated content. arXiv preprint arXiv:2311.11094 (2023). [11] Paul Emmerich, Sebastian Gallenmüller, Daniel Raumer, Florian Wohlfart, and Georg Carle. 2015. MoonGen: A scriptable high-speed packet generator. In ACM IMC. 275–287. [12] Jiaqi Gao, Ennan Zhai, Hongqiang Harry Liu, Rui Miao, Yu Zhou, Bingchuan Tian, Chen Sun, Dennis Cai, Ming Zhang, and Minlan Yu. 2020. Lyra: A crossplatform language and compiler for data plane programming on heterogeneous asics. In ACM SIGCOMM. 435–450. [13] Sam Gross, Marc’Aurelio Ranzato, and Arthur Szlam. 2017. Hard mixtures of experts for large scale weakly supervised vision. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 6865–6873. [14] Yang Gu, Hengyu You, Jian Cao, Muran Yu, Haoran Fan, and Shiyou Qian. 2025. Large Language Models for Constructing and Optimizing Machine Learning Workflows: A Survey. ACM Trans. Softw. Eng. Methodol. (2025). [15] Arpit Gupta, Rob Harrison, Marco Canini, Nick Feamster, Jennifer Rexford, and Walter Willinger. 2018. Sonata: Query-driven streaming network telemetry. In ACM SIGCOMM. 357–371. [16] Gurobi Optimizer. 2025. http://www.gurobi.com. [17] Joseph L Hodges Jr and Erich L Lehmann. 2011. Estimates of location based on rank tests. In Selected works of EL Lehmann. Springer, 287–300. [18] Mary Hogan, Shir Landau-Feibish, Mina Tahmasbi Arashloo, Jennifer Rexford, and David Walker. 2022. Modular Switch Programming Under Resource Constraints. In USENIX NSDI. 1–15. [19] Wei Huang, Yue Liao, Jianhui Liu, Ruifei He, Haoru Tan, Shiming Zhang, Hongsheng Li, Si Liu, and Xiaojuan Qi. 2024. Mc-moe: Mixture compressor for mixtureof-experts llms gains more. arXiv preprint arXiv:2410.06270 (2024). [20] Wenzhao Jiang, Jindong Han, Hao Liu, Tao Tao, Naiqiang Tan, and Hui Xiong. 2024. Interpretable cascading mixture-of-experts for urban traffic congestion prediction. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 5206–5217. [21] Lavanya Jose, Lisa Yan, George Varghese, and Nick McKeown. 2015. Compiling Packet Programs to Reconfigurable Switches.. In USENIX NSDI. 103–115. [22] Simon Knight, Hung X Nguyen, Nickolas Falkner, Rhys Bowden, and Matthew Roughan. 2011. The internet topology zoo. IEEE Journal on Selected Areas in Communications 29, 9 (2011), 1765–1775. [23] Yuxuan Li, Xiang Li, Yunheng Li, Yicheng Zhang, Yimian Dai, Qibin Hou, MingMing Cheng, and Jian Yang. 2024. Sm3det: A unified model for multi-modal remote sensing object detection. arXiv preprint arXiv:2412.20665 (2024). [24] Yuanpeng Li, Zhen Xu, Zongwei Lv, Yannan Hu, Yong Cui, and Tong Yang. 2025. LLM-Sketch: Enhancing Network Sketches with LLM. arXiv preprint arXiv:2502.07495 (2025). [25] Hongyan Liu, Xiang Chen, Qun Huang, Guoqiang Sun, Peiqiao Wang, Dong Zhang, Chunming Wu, Xuan Liu, and Qiang Yang. 2024. Toward ResourceEfficient and High- Performance Program Deployment in Programmable Networks. IEEE/ACM Transactions on Networking (2024), 4270–4285. [26] Hongyan Liu, Xiang Chen, Qun Huang, Haifeng Zhou, Dong Zhang, and Chunming Wu. 2020. Sra: Switch resource aggregation for application offloading in programmable networks. In GLOBECOM 2020-2020 IEEE Global Communications Conference. IEEE, 1–6. [27] Saeed Masoudnia and Reza Ebrahimpour. 2014. Mixture of experts: a literature survey. Artificial Intelligence Review 42 (2014), 275–293. [28] Mininet. 2025. http://mininet.org/. [29] Basil Mustafa, Carlos Riquelme, Joan Puigcerver, Rodolphe Jenatton, and Neil Houlsby. 2022. Multimodal contrastive learning with limoe: the language-image mixture of experts. Advances in Neural Information Processing Systems 35 (2022), 9564–9576. [30] Jianing Pei, Peilin Hong, Kaiping Xue, and Defang Li. 2018. Efficiently embedding service function chains with dynamic virtual network function placement in geodistributed cloud system. IEEE Transactions on Parallel and Distributed Systems
30, 10 (2018), 2179–2192. [31] Jingqing Ruan, Yihong Chen, Bin Zhang, Zhiwei Xu, Tianpeng Bao, Guoqing Du, Shiwei Shi, Hangyu Mao, Ziyue Li, Xingyu Zeng, and Rui Zhao. 2023. TPTU: Large Language Model-based AI Agents for Task Planning and Tool Usage. arXiv:2308.03427 [cs.AI] https://arxiv.org/abs/2308.03427 [32] Nik Sultana, John Sonchack, Hans Giesen, Isaac Pedisich, Zhaoyang Han, Nishanth Shyamkumar, Shivani Burad, André DeHon, and Boon Thau Loo. 2021. Flightplan: Dataplane disaggregation and placement for p4 programs. In USENIX NSDI. 571–592. [33] LangGenius Team. 2023. Dify: The open platform for LLMOps and AI-native apps. https://github.com/langgenius/dify. Accessed: 2025-05-13. [34] Arpita Vats, Rahul Raja, Vinija Jain, and Aman Chadha. 2024. The Evolution of Mixture of Experts: A Survey from Basics to Breakthroughs. Preprints (August 2024). doi:10.20944/preprints202408.0583.v1 [35] Duo Wu, Xianda Wang, Yaqi Qiao, Zhi Wang, Junchen Jiang, Shuguang Cui, and Fangxin Wang. 2024. Netllm: Adapting large language models for networking. In Proceedings of the ACM SIGCOMM 2024 Conference. 661–678. [36] Yihan Wu, Yifan Peng, Yichen Lu, Xuankai Chang, Ruihua Song, and Shinji Watanabe. 2024. Robust Audiovisual Speech Recognition Models with Mixtureof-Experts. In 2024 IEEE Spoken Language Technology Workshop (SLT). IEEE, 43–48. [37] Minrui Xu, Hongyang Du, Dusit Niyato, Jiawen Kang, Zehui Xiong, Shiwen Mao, Zhu Han, Abbas Jamalipour, Dong In Kim, Xuemin Shen, Victor C. M. Leung, and H. Vincent Poor. 2024. Unleashing the Power of Edge-Cloud Generative AI in Mobile Networks: A Survey of AIGC Services. Commun. Surveys Tuts. 26, 2 (2024), 1127–1170. [38] Wenquan Xu et al. 2023. Clickinc: In-network computing as a service in heterogeneous programmable data-center networks. In ACM SIGCOMM. 798–815. [39] Xiang Xu, Lingdong Kong, Hui Shuai, Liang Pan, Ziwei Liu, and Qingshan Liu. 2025. LiMoE: Mixture of LiDAR Representation Learners from Automotive Scenes. arXiv preprint arXiv:2501.04004 (2025). [40] Yunting Xu, Jiacheng Wang, Ruichen Zhang, Changyuan Zhao, Dusit Niyato, Jiawen Kang, Zehui Xiong, Bo Qian, Haibo Zhou, Shiwen Mao, et al. 2025. Decentralization of Generative AI via Mixture of Experts for Wireless Networks: A Comprehensive Survey. arXiv preprint arXiv:2504.19660 (2025). [41] Zeyue Xue, Guanglu Song, Qiushan Guo, Boxiao Liu, Zhuofan Zong, Yu Liu, and Ping Luo. 2023. Raphael: Text-to-image generation via large mixture of diffusion paths. Advances in Neural Information Processing Systems 36 (2023), 41693–41706. [42] Seniha Esen Yuksel, Joseph N. Wilson, and Paul D. Gader. 2012. Twenty Years of Mixture of Experts. IEEE Transactions on Neural Networks and Learning Systems 23, 8 (2012), 1177–1193. [43] Songli Zhang, Weijia Jia, Zhiqing Tang, Jiong Lou, and Wei Zhao. 2022. Efficient instance reuse approach for service function chain placement in mobile edge computing. Computer Networks 211 (2022), 109010. [44] Susan Zhang, Stephen Roller, Naman Goyal, Mikel Artetxe, Moya Chen, Shuohui Chen, Christopher Dewan, Mona Diab, Xian Li, Xi Victoria Lin, et al. 2022. Opt: Open pre-trained transformer language models. arXiv preprint arXiv:2205.01068 (2022). [45] Xiaoquan Zhang, Lin Cui, Fung Po Tso, Zhetao Li, and Weijia Jia. 2023. Dapper: Deploying Service Function Chains in the Programmable Data Plane Via Deep Reinforcement Learning. IEEE Transactions on Services Computing 16, 4 (2023), 2532–2544. [46] Changgang Zheng, Haoyue Tang, Mingyuan Zang, Xinpeng Hong, Aosong Feng, Leandros Tassiulas, and Noa Zilberman. 2023. DINC: Toward Distributed In-Network Computing. Proc. ACM Netw. 1, CoNEXT3 (2023), 14:1–14:25. [47] Yan Zhuang, Zhenzhe Zheng, Fan Wu, and Guihai Chen. 2024. LiteMoE: Customizing On-device LLM Serving via Proxy Submodel Tuning. In Proceedings of the 22nd ACM Conference on Embedded Networked Sensor Systems. 521–534.
OmniPlan : An Adaptive Framework for Timely and Near-Optimal Network Planning Optimization
11 Appendix 11.1 Notation of Main Symbols Table 12 summarizes the notation of main symbols in this paper. Table 12: Notation of main symbols. Symbols of Intent Translation 𝑢 T s 𝑀 𝜏net 𝜏format 𝜔 res , 𝜔 pwr , 𝜔 thr , 𝜔 lat 𝜔 coor , 𝜔 hop , 𝜔 cover 𝐾 𝑆𝑖 p𝑖 𝜃 L (𝜃 ) 𝐿𝑖,𝑖+1 𝜙𝑖,𝑖+1
The user intents in natural language. The standardized textual representations. Preference vector of user. Number of optimization objectives. Domain prior in prompts. Output-format prior in prompts. Quantified value of user preference. Number of intent anchors. Intent anchor at level 𝑖. Embedding of 𝑆𝑖 via sentence-BERT. curve parameter Cubic-spline intent curve. Arc-length between anchors 𝑖 and 𝑖+1. Arc-length weight of segment (𝑖, 𝑖+1). Symbols of Expert Activation
𝐶𝑖 V ℓ (𝑣) 𝑟 (𝑣) 𝑎, 𝑏 𝐴(𝑢, 𝑣) Ecross 𝑅𝑡 𝜋 (𝑎 |𝑠 ) 𝐸𝑘 e𝑘 Sim(𝐸𝑘 ) 𝜏 𝐹𝑙𝑎𝑔high Efast 𝐸 MIP Eact
Performance value of objective 𝑖. Set of tasks. Dependency level of task 𝑣. Resource overheads of task 𝑣. Tunable weights for task priority. Volume of inter-metadata from task 𝑢 to 𝑣. Set of edges across task subsets. Reward received at step 𝑡 . Learned policy maximizing expected return. Expert 𝑘. Capability vector of expert 𝑘. Similarity between user intent and expert 𝑘. Threshold for activating a single expert. Set of objectives with weights exceeding 𝜏. Set of heuristic or DRL-based fast experts. MIP solver-based expert. Activated expert set. Symbols of Expert Configuration
S𝑡 𝑎𝑡 lr𝑡 Δ𝑡,𝑖 𝑑𝑖 Perf𝑡,𝑖 W𝑡,𝑖 𝜇 𝑟𝑡 Δ̄W𝑡 𝛽 𝐶 𝑐𝑗
11.2
State of the DRL agent at time step 𝑡 . Action selected at time step 𝑡 . Learning rate adjustment factor at time step 𝑡 . Normalized improvement of objective 𝑖. Directional factor for objective 𝑖. Performance value of objective 𝑖 at time step 𝑡 . Intent-weighted improvement sample of objective 𝑖 at time step 𝑡 . Overall performance trend indicator (HodgesLehmann estimator). Reward received at time step 𝑡 . Total intent-weighted improvement at step 𝑡 . Penalty coefficient for constraint violations. Set of constraints. Specific constraint in set 𝐶.
Design Details
Initial weight perturbation in expert configuration. When user intents contain conjunctions (e.g., “maximize bandwidth and
minimize latency”), the LLM often assigns identical semantic scores to multiple objectives, resulting in equal initial weights. In this case, since the shift-softmax function cannot differentiate identical values, we introduce small random perturbations to break symmetry: 𝜔 0 = 𝜔 init + 𝜖,
𝜖 ∼ U (−0.05, 0.05)
(9)
where 𝜔 init is the initial weight vector from intent-aware scoring. Recursive weight refinement in expert configuration. When weight adjustments become marginal (i.e., max𝑖 |𝜔𝑡 +1,𝑖 − 𝜔𝑡,𝑖 | < 𝜏 where 𝜏 = 0.01), the DRL agent enters a recursive refinement phase. In this case, shift-softmax cannot further differentiate objectives with identical or near-identical weights, which is a common scenario when LLMs assign equal scores to conjoined objectives in user intents. In response, we execute the recursive procedure that fixes the dominant weight corresponding to arg max𝑖 𝜔𝑡 and recursively optimizes the remaining weight subspace with renewed perturbations. We continually execute this process until all weights are sufficiently differentiated to achieve fine-grained alignment with user preferences.
11.3
More Experimental Results
(Exp#12) OmniPlan offloads more tasks. We evaluate the number of successfully offloaded tasks in OmniPlan and comparison solutions. More precisely, we randomly select 200 ML tasks. Then, we take these ML tasks as input and offload them into topologies with different hardware device numbers, ranging from 8 to 32 devices. Compared to HMS, OmniPlan offloads by up to 1.3× tasks. Figure 2 shows that OmniPlan can offload more ML tasks. (Exp#13) Weight changes during expert configuration. Table 13 shows the weights of optimization objectives in the activated experts. We can see that as the epoch number increases, OmniPlan fine-tunes these weights and achieves the optimal weight configuration in the sixth epoch.
11.4
More Discussion
Extend to more network planning scenarios. We can extend OmniPlan to many network planning scenarios, such as SFC placement, vehicle path scheduling, and traffic engineering, where we can define domain-specific optimization objectives, map them to the intent vector, and construct the corresponding experts. More precisely, since most network planning problems share common objectives, such as latency, throughput, and resource consumption, the existing intent vector structure can be reused with minor adaptations. For expert construction, existing approaches from the literature can be directly integrated as experts within OmniPlan. Generalizability of OmniPlan. OmniPlan is a general-purpose framework for intent-aware network planning optimization, where its architecture does not rely on domain-specific semantics. More precisely, the LLM-based intent translation operates purely on natural language and outputs a normalized preference vector encoding user priorities over optimization objectives. The MoE-based expert activation (i.e., Algorithm 1) selects experts based on cosine similarity between the preference vector and expert capability vectors, without interpreting the underlying domain meaning. Similarly, the DRL-based weight configuration adjusts objective weights based solely on performance feedback signals, where OmniPlan treats the
Longlong Zhu et al.
Table 13: (Exp#13) Weights of optimization objectives inside the activated expert change. Note that the weights of the other optimization objectives equal 0. Thus, we omit them. By the sixth epoch, the expert weight configuration has reached the optimum, where any weight changes will decrease the intent-aware score. We show weights from epochs 0 to 10, but in actual runs, OmniPlan will automatically stop at the seventh epoch. Expert weights configuring Epoch ID
# of Tasks
Weight of minimizing SRAMs Weight of minimizing latency Weight of maximizing throughput
100 95 50 25 0
SPD-O SPD-H HMS
DP OmniPlan
8
16
Achieved the optimal configuration
0
1
2
3
4
5
6
7
8
9
10
0.1775 0.1775 0.6450
0.2619 0.2619 0.4762
0.3020 0.3020 0.3959
0.3191 0.3191 0.3617
0.3136 0.3136 0.3727
0.3059 0.3059 0.3882
0.2210 0.3907 0.3882
0.2210 0.3907 0.3882
0.2210 0.3907 0.3882
0.2210 0.3907 0.3882
0.2210 0.3907 0.3882
(1) MAT assignment. Each MAT must be deployed on exactly one device, i.e., ∑︁ 𝑥 𝑣,𝑑 = 1, ∀𝑣 ∈ M (11) 24
# of HPC hardware devices
𝑑∈D
32
Figure 2: (Exp#12) Number of successfully offloaded tasks with a varying number of HPC hardware devices.
(2) Device resource capacity. The total resource consumption of all MATs deployed on a device must not exceed its capacity, i.e., ∑︁ 𝑟 𝑣(SRAM) · 𝑥 𝑣,𝑑 ≤ 𝑅𝑑(SRAM) , ∀𝑑 ∈ D (12) 𝑣∈M
optimization objectives as abstract dimensions. Therefore, these designs ensure that OmniPlan is domain-agnostic. Engineering effort. OmniPlan reduces engineering effort in three ways. First, existing optimization algorithms can be wrapped as experts via a standard interface. Second, the expert library is extensible since adding a new expert only requires registering a capability vector e𝑘 and its optimization logic. Third, DRL-based expert configuration automates weight tuning. In our prototype, the entire framework contains 4,105 lines of code, and the DRL configuration module converges within approximately 15 minutes.
11.5
MIP Formulation for ML Offloading
We present the complete MIP formulation used in our case study. Input and output. OmniPlan takes (1) a set of ML inference tasks, where each task is decomposed into multiple match-action tables (MATs), i.e., M, with dependency relations E, where 𝑒 = (𝑢, 𝑣) means 𝑣 needs the output of 𝑢, (2) a network topology containing device set D and link set L, with device resource capacities and link bandwidths, and (3) user intent weights {𝜔𝑖 } derived from the intent translation module as input. OmniPlan outputs (1) 𝑥 𝑣,𝑑 ∈ {0, 1}, where it equals 1 if MAT 𝑣 is deployed on device 𝑑, and 0 otherwise, (2) 𝑦𝑒,𝑙 ∈ {0, 1}, where it equals 1 if dependency edge 𝑒 uses link 𝑙 for inter-device communication, and 0 otherwise. Objective function. We formulate an optimization as: min
𝑀 ∑︁
𝜔 𝑖 · 𝐶𝑖
(10)
𝑖=1
where 𝑀 is the number of objectives, 𝜔𝑖 is the weight for objective 𝑖 derived from user intent and 𝐶𝑖 is its performance value. Constraints. We identify the following constraints.
∑︁
𝑟 𝑣(PHV) · 𝑥 𝑣,𝑑 ≤ 𝑅𝑑(PHV) ,
∀𝑑 ∈ D
(13)
𝑣∈M
where 𝑟 𝑣 and 𝑅𝑑 denote the SRAM/PHV requirement of MAT 𝑣 and capacity of device 𝑑, respectively. (3) Link bandwidth capacity. The total data transfer on a link must not exceed its bandwidth capacity, i.e., ∑︁ ˆ 𝑣) · 𝑦𝑒,𝑙 ≤ 𝐵𝑙 , ∀𝑙 ∈ L 𝐴(𝑢, (14) 𝑒=(𝑢,𝑣) ∈ E
ˆ 𝑣) denotes the data volume transferred from MAT 𝑢 to where 𝐴(𝑢, MAT 𝑣 along dependency edge 𝑒 = (𝑢, 𝑣), and 𝐵𝑙 is the bandwidth of link 𝑙. (4) Flow conservation. For each dependency edge, the routing path must form a valid path from the source device to the destination device, i.e., 1 if 𝑑 = src(𝑒) ∑︁ ∑︁ 𝑦𝑒,𝑙 − 𝑦𝑒,𝑙 = −1 if 𝑑 = dst(𝑒) ∀𝑒 ∈ E, ∀𝑑 ∈ D 𝑙 ∈𝛿 + (𝑑 ) 𝑙 ∈𝛿 − (𝑑 ) 0 otherwise (15) (5) MAT dependency. An ML inference task is decomposed into multiple MATs with data dependencies. If MAT 𝑢 is a predecessor of MAT 𝑣 (i.e., 𝑣 requires the output of 𝑢), they must be deployed on the same device or connected via a valid routing path. Furthermore, when deployed on the same device, 𝑢 must be placed in an earlier pipeline stage than 𝑣. Solver. Following established practices in network function offloading optimization [3, 6, 25, 46], we employ Gurobi [16] as the standard MILP solver to compute optimal deployment decisions.