Continual Instruction Tuning for LLM-ased Management of Continuum Resources

arXiv:2611.10292v1 [cs.DC] 6 Nov 2026

Continual Instruction Tuning for LLM-based Management of Continuum Resources Lanpei Li∗

Antonino Vaccarella†

Institute of Information Science and Technologies “Alessandro Faedo”, National Research Council (ISTI-CNR) Pisa, Italy lanpeili@cnr.it

Institute of Information Science and Technologies “Alessandro Faedo”, National Research Council (ISTI-CNR) Pisa, Italy antoninovaccarella@cnr.it

Vincenzo Lomonaco

Massimo Coppola

Department of AI, Data and Decision Sciences LUISS University Rome, Italy vlomonaco@luiss.it

Institute of Information Science and Technologies “Alessandro Faedo”, National Research Council (ISTI-CNR) Pisa, Italy massimo.coppola@cnr.it

Abstract

Keywords

Large language models (LLMs) are increasingly explored for resource management across the Cloud–Edge continuum. However, embedding LLMs directly inside latency-sensitive control loops places inference latency, execution jitter, and hallucination risks on the critical path. This study argues for a different use of LLMs: a continually instruction-tuned intent compiler that runs once per management intent or declared context change, above a fast, deterministic tactical controller that handles all low-latency runtime actions. We formulate intent compilation as a continual instruction tuning problem, because management intents arrive sequentially and accumulate while infrastructure and workload contexts drift. Unlike recent LLM-based management frameworks, our design scores the model’s outputs by execution, so that catastrophic forgetting can be measured in the executed objective of the underlying controller. On a continuum simulator with a 2B backbone and parameter-efficient adapters, preliminary results show that naive sequential tuning forgets earlier intents in the executed objective, that replay of stored examples nearly prevents this forgetting, and that the tuned compact compiler performs on par with simpler translators while being more robust than a grammar parser to rephrased intents.

Cloud–Edge Continuum, Edge Computing, Large Language Models, Continual Learning, Continual Instruction Tuning, Catastrophic Forgetting, Intent-based Management, Resource Management

CCS Concepts • Computer systems organization → Cloud computing; ntier architectures; • Computing methodologies → Natural language processing; Simulation evaluation; Computational control theory; Artificial intelligence; • Software and its engineering → Cloud computing. ∗ Also with Department of Computer Science, University of Pisa. † Also with Department of Computer Science, University of Pisa.

This work is licensed under a Creative Commons Attribution 4.0 International License. IOT 2026, Newcastle Upon Tyne, England, United Kingdom © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-3095-5/2026/11 https://doi.org/10.1145/3860552.3860597

ACM Reference Format: Lanpei Li, Antonino Vaccarella, Vincenzo Lomonaco, and Massimo Coppola. 2026. Continual Instruction Tuning for LLM-based Management of Continuum Resources. In The 16th International Conference on the Internet of Things (IOT 2026), November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/ 3860552.3860597

1

Introduction

Resource orchestration within the Cloud–Edge continuum requires setting three interdependent control dimensions for distributed multi-stage applications: (i) horizontal elasticity, sizing worker pools over time; (ii) spatial placement, mapping pipeline stages across IoT, edge, and cloud nodes; and (iii) capacity allocation, splitting shared cores between pools. These decisions must satisfy strict Service-Level Objectives (SLOs) governing end-to-end latency and workflow completion while adhering to operational budgets, dynamic energy limits, network bandwidth constraints, and data residency policies. In operational multi-tenant systems, governance requirements are stated as high-level declarative agreements, which intent-based frameworks formulate as natural-language intents [6] (e.g., “maintain high-priority task deadline compliance above 95% while strictly prohibiting cloud offloading”). An intent declares what is wanted, not how to reach it [4]; today, systems engineers manually translate it into the low-level operational parameters of the infrastructure controllers [5]. Our research investigates whether instruction-tuned language models can perform this intent-to-configuration synthesis, and whether they can keep adapting as new kinds of intent arrive and the deployment context drifts, without catastrophic forgetting [10]: the Continual Instruction Tuning (CIT) paradigm, an instance of continual fine-tuning, one of the three directions in which continual learning remains essential in the era of foundation models [2]. A model that keeps learning is not a component tuned once and installed but a learning agent that must be designed for adaptation

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

from the start [12], so where it sits in the platform’s control matters as much as what it translates. We propose two nested control loops: an inner one reacting fast under a deterministic policy, and an outer one carrying the LLM’s semantic capabilities, active only when an intent is issued or a context change is declared. The tactical controller (an anticipatory autoscaler or a placement mixed-integer linear program, MILP) acts every epoch in milliseconds on platform state and discrete parameters (knobs) alone, while the intent compiler, an instruction-tuned model with a lightweight adapter, runs once per intent, reading the intent together with the current context, and emits a canonical intent and a vector of discrete knobs. A validator checks them before they take effect, and they then stay in force until the next intent or declared context change. Because the compiler is never on the per-epoch path, its answer latency never becomes the platform’s control latency, and its supervision arrives only as scarce, expensive labels from scored runs. Against recent LLM-based management systems, the design differs in three ways: the model is tuned on the platform it manages, not only prompted; its output is scored by execution, as its gap to a search reference, not as text; and that score is tracked as intents accumulate and contexts drift. Preliminary experiments on a continuum simulator with a 2B backbone support this design at reduced scale. Choosing the knobs matters: configurations found by search improve on the schema default by a median of 0.73 in objective value and make the controller act differently. Forgetting is real: tuned stage by stage without protection, the compiler loses 0.23–0.26 of the gain over the default on the intents it learned earlier when new kinds of intent arrive, and 0.67–0.70 under context drift, where the intent text gives no sign that the answer has changed. Forgetting can be reduced: replaying stored examples of earlier stages keeps forgetting at or below 0.07, and the resulting compiler is within 0.05 of one trained on all stages at once. At inference, the tuned compiler needs no simulator rollouts, which are full simulated episodes of the controller’s policy scored against the declared objective, and performs on par with a clause-type lookup, a grammar parser, and sixty rollouts of search, and better than retrieval and the zero-shot backbone. When the test intents are rephrased in wordings never seen in training, the compiler keeps most of its accuracy while the grammar parser cannot. Our contribution is threefold. We propose a two-loop architecture that keeps the tactical controller on the platform’s critical path and confines the LLM to an outer loop that runs once per intent. We formulate intent compilation as continual instruction tuning, scored by the executed gap, and test it on two streams that separate the arrival of new kinds of intent from context drift under recurring intents. Finally, we provide preliminary evidence that forgetting under this measure is real, that replay reduces it, and that a tuned compact model is worth its cost against simpler translators.

2

Related work

Human operators can declare structured requirements — intentbased networking supplies a vocabulary and lifecycle [4], and elasticity SLOs are first-class objects in dedicated controllers [11] — but in such controllers the mapping from declared objective to configuration is fixed by hand, not learned from open-ended input.

Li et al.

Transforming an intent into a concrete configuration with an LLM is an active line of research. Policies and configurations are generated from natural language [6], with accuracy that depends on the task, the model, and the prompt [14]. Intent-driven controllers now reach the compute continuum [1], and agent compilers for radio infrastructure separate timescales in a way similar to ours: an LLM on a second-to-minute scale above a millisecond-scale control loop [17]. Among these LLM-based intent-to-configuration systems, some already screen the output before it acts, through an intent contract [3], a constraint check over a verifiable intermediate representation [17], or an LLM check and a digital-twin test [6]; elsewhere it is applied as returned [1]. All of them use an LLM whose weights stay fixed once deployed, from GPT-4o down to a 4B instruct model; where there is a gate, it only ever validates one output at a time—the configuration just returned. We instead continually tune a compact adapter offline, so our gate must also decide whether a candidate adapter may replace the active one, admitting it only if it still performs on the intents the active adapter already learned. A recent taxonomy [13] classifies six systems by whether execution feedback returns to the LLM after agents act. None of these systems uses execution outcomes to update the LLM’s weights. Continual learning studies how a model can learn from a sequence of tasks over time without losing what it has already learned; the risk is catastrophic forgetting: learning a new task degrades performance on what was learned before [10].

3

Problem formulation

From an engineering viewpoint, when an LLM is placed in a controller’s feedback loop, its properties create a dependency cycle. The size and type of the model dictate its capabilities, but also how fast it can answer and its hardware needs. The model latency is a lower bound on the control latency of the whole system, and control latency dictates how quickly the system can react and how often the model can learn from feedback, thus limiting its overall control capability. We break this cycle by giving the model a different job: it produces a configuration once per intent and steps aside while a fast, deterministic controller acts at every epoch under it. Its feedback is late and mediated, the measured outcome of a whole run rather than a per-epoch reward, and because intents keep arriving, these outcomes accumulate as a stream of labelled examples; learning from that stream without losing earlier competence is the continual instruction tuning problem.

3.1

Platform, controller, and knobs

We define a continuum platform with four layers (space, IoT, edge, cloud), where space and IoT nodes host the data sources, and edge and cloud are the compute layers. Applications are directed acyclic graphs (DAGs) of pipeline stages. Time advances in control epochs (one second by default). At epoch 𝑒 the platform exposes a state 𝑠𝑒 : the current placement, the per-stage queues and their ages, and the workers of each pool. A tactical controller 𝜋𝜽 , parameterised by a vector 𝜽 ∈ Θ, maps 𝑠𝑒 to a feasible action 𝑎𝑒 : a placement of stages on nodes and a size for each worker pool. When pools share nodes, their sizes split the common core budget. The controller executes deterministically at each epoch and applies only actions

Continual Instruction Tuning for LLM-based Management of Continuum Resources

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

the platform can carry out: pool sizes stay within their floors and caps, and a placement that would exceed a node’s capacity is never applied; the controller falls back to one that fits, at worst the current placement. In our experiments 𝜋𝜽 is an anticipatory autoscaler that pre-warms and drains pools around scheduled bursts on the elastic and two-pool variants of Section 5.1, and a MILP that places stages under capacity, residency, link, and energy constraints on the placement variant; Section 5.2 lists their knobs. The controller is conventional software: it is never trained or modified, and the only thing the compiler changes is 𝜽 . Each entry of 𝜽 is a knob that a human engineer would set when translating a service-level agreement: an objective weight, a per-class deadline, a scaling target, a pre-warm lead time (how early workers start before a burst), a pool floor or cap, a layer price weight, a residency rule, or a hard cap on data crossing into the cloud or on energy. Every knob is discrete, with three to five allowed values, so Θ is a finite set. The list of knobs with their types, sets of allowed values, and defaults is the schema; it establishes Θ and the serialisation of 𝜽 . With the clause grammar of Section 3.2, the schema forms the complete target language of the compiler.

we call its value the objective value of 𝜽 in context 𝑐 for intent 𝜄 with canonical intent 𝜅. It builds on the completion-aware score of ContinuumBench [8]: each soft clause in 𝜅 sets an objective weight, each hard clause introduces a violation penalty, and every other term keeps its default weight. If the controller cannot execute a rollout, that rollout receives a fixed, negative floor score. This score is evaluated by rolling out policy 𝜋𝜽 in context 𝑐 over a full episode and averaging across simulator seeds. Fixed and free knobs. Knobs are split by whether they define what the intent wants or how the controller achieves it. A knob is fixed if it defines the target goal: the fixed knobs are the objective’s weights, set by soft clauses, and its per-class deadlines, set by latency clauses, with defaults for any term the intent omits. Allowing the compiler to choose these would let it choose the very objective it is scored against. Conversely, a knob is free if it governs operational mechanisms. An intent never names a pre-warm lead or a layer price weight, so the compiler must infer such knobs from the intent and the deployment context together. Only the residency and link clauses set a free knob directly; other caps and floors are met through free knobs the compiler chooses. Accordingly, we partition the parameters as 𝜽 = (𝜽 fix, 𝜽 free ), with 𝜽 fix = ℎ(𝜅) set by the canonical intent.

3.2

Intents, contexts, and the declared objective

Intent and grammar. The LLM reads an intent and a context, and produces an intermediate form that a human can audit before the parameters take effect. An intent 𝜄 is a natural-language sentence or short paragraph stating what the platform should achieve. Its canonical intent 𝜅 is a list of typed clauses, each with its parameters. The clause types (Table 1) are latency (a deadline for one class of tasks), priority (one class guaranteed an on-time rate, the other served best effort), budget (priced capacity, as a cost weight or a hard cap on the share used), energy (a weight or a cap on mean dynamic power), residency (which layers may run stages), link (a cap on the data that may cross into the cloud), and throughput (a floor on the fraction of tasks completed). For example, a sentence such as “at most 64 MB may cross into the cloud during the run” is one link clause. A soft clause states a preference (e.g., over cost or energy) and scales its relative priority via an objective weight; a hard clause (e.g., a cap, floor, or residency rule) represents a mandatory constraint whose violation yields an infeasible output rather than a suboptimal one. These clause types, in the nine forms of Table 1 and each with a fixed set of parameter values, make up the intent grammar; each intent family fixes which clauses its intents combine, and a family is admitted only when the clause it adds can bind. Finally, clauses are stated at the level at which a platform is managed, and the choice of nodes is left to the controller: cost is defined per layer, residency names layers, and energy is a single platform-wide total of dynamic power. Context. An intent alone is insufficient, as the same high-level specification requires different parameter configurations across different platforms. We therefore pair the intent with a deployment context 𝑐, a structured snapshot of the system at the moment an intent is issued. It encompasses the application DAG, layer capacities and pricing, workload intensity and arrival profiles, and a one-line summary of a baseline rollout under default parameters. Declared objective. The declared objective 𝐽𝜄 (𝜽 ; 𝑐) evaluates the executed score of a rollout against the criteria specified in 𝜅;

3.3

Intent compilation as a supervised task

The free knobs encode quantitative values unlikely to appear in a general pretraining corpus, such as how long before a burst the worker pools must be pre-warmed, or how heavily the placement should weigh edge against cloud prices. Without observing actual rollouts, a model can only guess these values. Large hosted models might guess better, at a monetary cost, with an external dependency, and with operational data leaving the platform. We therefore fine-tune a compact, local model to predict the free knobs. Because there is no analytical ground truth for them, the label comes from a search process. An intent compiler is a function 𝑓𝜙 : (𝜄, 𝑐) ↦→ (b 𝜅, b 𝜽 ),

(1)

implemented as a pretrained LLM backbone, kept frozen (its weights are never updated), plus a lightweight trainable adapter 𝜙, a form of parameter-efficient fine-tuning (PEFT). A downstream validator 𝑉 first verifies syntactic correctness, accepting the output only if it conforms to the target schema and every knob falls within its permitted domain. Operational hard constraints encoded in b 𝜽 (e.g., residency rules, link budgets, and energy caps) are enforced by the controller, which flags the configuration as infeasible if the platform cannot satisfy them. The end-to-end execution contract is: 𝑓𝜙

𝑉

rollout

(𝜄, 𝑐) −−→ (b 𝜅, b 𝜽) − → 𝜋b𝜽 −−−−−→ 𝐽𝜄 (b 𝜽 ; 𝑐).

(2)

Reference labels. In offline training mode (see Section 4.1) the supervisory target for the compiler is the best configuration discovered by bounded search on the simulator: 𝜽 ★ (𝜄, 𝑐) ≈ arg

max

𝜽 ∈Θ, 𝜽 fix =ℎ (𝜅 )

𝐽𝜄 (𝜽 ; 𝑐),

(3)

where a greedy search changes one or two free knobs at a time, and a few finalists are re-scored on additional seeds. Because a single reference label costs a search of one to two thousand rollout

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

Li et al.

Table 1: The eight intent families and their clauses (• required, ◦ optional), grouped by the scenario variant defined in Section 5.1. Intent clause type and its forms

Family

latency

priority

latency (deadline classes)

class first

budget

energy

cost weight

capacity cap

Elastic variant: deciding how many workers to run over time budget-elastic low bill-elastic low

• ◦

•

Placement variant: deciding where stages run layer-placement high, low link-placement high, low residency-placement high, low

• • •

energy weight

power cap

residency

link

throughput

allowed layers

link budget

completion floor

◦

◦

•

Two-pool variant: deciding how a shared core budget is split between pools priority-two-pool high, low • ◦ budget-two-pool high, low • bill-two-pool high, low •

• ◦

•

Note: budget and energy each have a soft (weight) and a hard (cap) form; an empty entry means the clause is not yet used in experiments, not disallowed by the grammar.

evaluations, most of them served from a cache shared across the labels of one context, labels are expensive and scarce. Training objective. We cast compilation in a standard instructionfollowing format: the instruction is the intent text 𝜄, the input is the serialised context 𝑐, and the supervisory target is the serialised pair (𝜅, 𝜽 ★free ). Fixed knobs are excluded from generation because they are deterministically derived via 𝜽 fix = ℎ(𝜅). The adapter is trained with the usual token-level cross-entropy on the target. Measuring a compiled configuration. We score the output by what happens when it is executed, since two different parameter vectors can be operationally equivalent and a near-identical one can be infeasible. The executed gap we measure is defined as 𝑔(b 𝜽 ; 𝜄, 𝑐) =

𝐽𝜄 (𝜽 ★; 𝑐) − 𝐽𝜄 (b 𝜽 ; 𝑐)
, ★ max 𝛿, 𝐽𝜄 (𝜽 ; 𝑐) − 𝐽𝜄 (𝜽 def ; 𝑐)

(4)

where 𝜽 def denotes the default configuration under the schema, and 𝛿 = 0.05 serves as a floor to stabilise the denominator when the default is near-optimal; the default’s own gap is then below 1. The gap is clipped to [0, 1]. Intuitively, a gap of 0 indicates performance matching the search reference 𝜽 ★, whereas a gap of 1 signifies performance no better than the default baseline; rejected or unparsable outputs are assigned a gap of 1. We define three scores for every example, which separate reading the intent from choosing the knobs. The parse score asks whether the intent was read correctly: it checks for an exact match between the predicted canonical intent b 𝜅 and the gold 𝜅. The solve score asks how good the knobs are assuming the intent is parsed correctly: it is the gap (4) obtained when the gold 𝜅 is supplied and only 𝜽 has to be produced. The end-to-end score is the gap of the full pipeline, parsing 𝜄 to 𝜅 and choosing 𝜽 together, and it is our final, long-term target.

3.4

Continual instruction tuning of the compiler

The compiler must also keep learning after deployment, for three reasons. First, new kinds of intent appear while the earlier ones stay in use. Second, prices, capacities, and workloads drift, so the best knobs 𝜽 ★ for an unchanged intent change although its text

does not. Third, every label costs a search, so new data arrive in small batches, and retraining on all past data at every update would exceed the platform’s compute and storage budget. Learning proceeds in 𝐾 stages. At stage 𝑘, the compiler receives a batch D𝑘 of labelled examples sampled from an intent–context distribution P𝑘 . The adapter 𝜙 is updated on D𝑘 , augmented by an optional replay memory M𝑘 storing at most 𝑚 examples per preceding stage: 𝜙𝑘 = 𝑈 (𝜙𝑘 −1, D𝑘 , M𝑘 ),

|M𝑘 | ≤ 𝑚 (𝑘 − 1),

(5)

where 𝑈 denotes the continual update rule under study, and 𝑚 the per-stage memory quota (𝑚 = 0 for memory-free methods). All other components—the LLM backbone, schema, validator, tactical controller, and evaluation pipeline—stay unchanged throughout. At test time, the compiler operates task-agnostically: it receives only (𝜄, 𝑐) with no stage identifier, and as in CIT benchmarks [15, 16], it is evaluated on every stage learned so far. A continual compiler can fail in two ways: it can perform poorly on the tasks it has been taught, and it can lose earlier competence while learning new ones. Let 𝑔𝑘,𝑗 be the mean end-to-end gap of 𝑓𝜙𝑘 on the held-out test set of stage 𝑗 ≤ 𝑘. We report the Average Í Gap (AG) after the last stage, AG = 𝐾1 𝐾𝑗=1 𝑔𝐾,𝑗 , the compiler’s competence over everything it has been taught, and
Executed Í Forgetting (F), 𝐹 = 𝐾 1−1 𝑗 <𝐾 𝑔𝐾,𝑗 − min𝑘 ≥ 𝑗 𝑔𝑘,𝑗 , the average growth of each earlier stage’s gap since its best value. Both AG and 𝐹 are measured in executed objective, not text similarity.

4

Architecture

Figure 1 shows the architecture that realises the execution contract (2). The high-frequency inner loop runs the tactical controller at every epoch with millisecond latency. The low-frequency intent compilation occurs in the outer loop, triggered either by a new intent or by a declared context change.

4.1

Operation modes

System operation is decoupled into two phases, online inference and offline adaptation. At inference time, on either trigger, the compiler reads the intent and the serialised context, then generates and emits b 𝜅 and b 𝜽.

Continual Instruction Tuning for LLM-based Management of Continuum Resources

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

OUTER LOOP · UPDATE ON NEW INTENT OR DECLARED CONTEXT CHANGE Rollout labeller greedy search over free knobs

Offline update batch new and retained labelled examples rollouts

Validation gate required fields, allowed values, retained-task test

LLM intent compiler continual instruction tuning (PEFT) later supervision

Continuum simulator workloads + IoT-edge-cloud continuum system executes actions; measures feasibility + objective value

accept + configure

runtime state feasible actions

Bounded tactical controller placement, scaling, allocation feasibility + fallback every epoch

INNER LOOP · UPDATE ON EVERY CONTROL EPOCH

Figure 1: The two nested control loops. Top: the outer loop, in which the compiler, tuned offline on the update batch, turns an intent and its context into (b 𝜅, b 𝜽 ) and the validation gate admits them to the tactical controller or rejects them. Bottom: the inner loop, in which the tactical controller acts at every epoch on the continuum simulator. Measured outcomes return only to the offline adapter update. Dashed arrows depict exchanges that happen only during offline label search. 𝜽 is written once into the If they are accepted by the validator 𝑉 , b controller’s configuration, and the inner loop runs from it at every epoch until the next event. No label is needed and no parameter search is performed (see Section 3.3 and Eq. (3)), so intent compilation needs no rollouts. On one NVIDIA A100 GPU, the 2B backbone takes about 0.6 s per intent when decoded in batches. Offline, the intents issued since the last update and their evaluated outcomes are collected; each new intent–context pair is labelled by the bounded search (3) on the simulator; the pairs form the next stage’s batch; a candidate adapter is tuned on it under the memory quota of (5), its outputs on retained intents and contexts are run through the controller, and it replaces the active adapter only if, on those examples, its mean gap exceeds that of the active adapter by at most 𝜖, with 𝜖 just above the gap’s noise across training seeds and decodings (up to 0.06). In our experiments every candidate is accepted, so that forgetting can be measured. The simulator is therefore used only offline, to produce labels and to test candidate adapters before they go live; at inference the compiler stands in for it. A label is only as good as the simulator’s match to the platform; in this study the simulator is also the platform, so that mismatch is not measured.

4.2

Validation gate and adapter updates

The validator 𝑉 rejects an invalid output instead of repairing it: snapping an invalid value to the nearest allowed one would silently replace a wrong answer with another one, whereas rejection keeps the last accepted configuration active and makes the failure visible. The gate catches only what it encodes: a constraint the schema omits, or a poor but feasible b 𝜽 , passes it. In our experiments, only the adapter (IA3 [9], which learns vectors that rescale the backbone’s inner activations) is trained on each

arriving batch, as in (5). It is a small fraction of a per cent of the backbone’s parameters, so an update is a small file and a rollback is a file swap.

5 Experimental setup 5.1 Benchmark substrate Experiments are conducted on ContinuumBench [8], a discretetime simulator modelling distributed stream-processing workflows and Earth-observation pipelines deployed across the four layers of Section 3.1. Workloads are task streams with Poisson arrivals whose rate is either constant or follows a schedule of rate segments over time; in our experiments, capacity is priced per layer and energy is metered per node. The experiments use its Earthobservation pipeline, fed by a space stream and an IoT stream, on three scenario configuration variants; in two of them the IoT stream arrives in short periodic bursts, and the scheduled burst is what the anticipatory autoscaler pre-warms for. Each variant’s base configuration fixes the application, infrastructure, and workload so that one control lever decides the outcome. The elastic variant exercises scaling: a bottleneck pool must be sized over time against the bursts, and each new worker takes 8 s to start. The placement variant exercises where stages run: a DAG needing 32 cores must be split across a 24-core cloud node and two 12-core edge nodes, with a 150 ms, 40 Mbps link between edge and cloud, so it fits on neither side alone. The two-pool variant exercises allocation: two pools share the 44 cores of the edge and cloud nodes and room for one worker on the space node, too little for both at peak.

5.2

Tactical controllers and their knobs

The thirteen free knobs are the settings of the two controllers of Section 3.1. The placement MILP maps stages to nodes; its five

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

Li et al.

knobs are the edge and cloud layer price weights, the residency rule, the link budget, and the energy cap. The anticipatory autoscaler sizes each worker pool at every epoch: it pre-warms a pool ahead of a scheduled burst, holds it for a drain time, and falls back to queue-driven scaling for load the schedule did not predict; its eight knobs are the pre-warm lead and targets, the drain time, the pool floors and cap, and the reactive queue target. The six fixed knobs set the per-class deadlines and the objective’s weights, and the cost and energy weights also enter the MILP objective. The schema has nineteen knobs in all.

families (budget-elastic, layer-placement, link-placement, prioritytwo-pool) under one setting, so Stream II also has eight stages, and 𝐹 averages over seven earlier stages in both streams. Each stage draws its contexts, and hence its test set, from its own setting only. The search reference 𝜽 ★ (𝜄, 𝑐) therefore changes while the wording of 𝜄 does not, so the compiler must read the change off the context. No function of 𝜄 alone can identify the stage, and we call such stages instruction-inseparable. Stage orders. Since forgetting is sensitive to stage ordering, we evaluate each stream under two orderings, Order A and Order B. In Stream I, Order A alternates across variants, so consecutive families share few knobs. Order B groups families by variant, letting consecutive stages compete over the same knobs with conflicting targets. In Stream II, which evaluates the families under two context settings, Order A introduces all families in the first setting before the second (creating a single context drift event), whereas Order B alternates settings family by family (continuous drift). Each update rule is evaluated over all four combinations, with results reported as the range across the two orders.

5.3

Intent and instruction design

We instantiated each of the nine clause forms of Table 1 with handwritten sentence templates and expanded them with a large language model into paraphrases, giving 104 training wordings (37 templates and 67 paraphrases) and 38 held-out rewordings. To keep the test wordings distinct from the training ones, a word-overlap filter keeps the Jaccard similarity between each held-out phrasing and every training sentence below 0.5. Wordings are short sentences that state a class, a limit, or a location. To test robustness to rewording, each test intent is evaluated under both training and held-out wordings. The clauses form the eight intent families of Table 1, each a combination of clauses on one variant. Every family carries a latency clause because a deadline is what every other clause trades against, and each adds one clause type or one conflict on a variant where it changes the outcome, so the eight families are eight distinct things to learn.

5.4

Input streams

Between learning stages the distribution of intent–context pairs shifts, and it can shift on either side: in the intents that are issued, or in the contexts they are issued for. Text benchmarks for continual instruction tuning typically employ an input stream in which every stage brings a new task with new instructions [15, 16]. Such a stream cannot separate retention from recognition: a classifier that recognises the task from the instruction text can route each input to the right adapter and never have to forget. It also cannot say anything about the case in which the instructions stay the same while the right answer changes. We therefore define two distinct input streams and keep these two kinds of changes apart while testing. Stream I: intent accumulation. Each of its eight learning stages introduces one new intent family, while each variant’s contexts are drawn from the same ranges of prices, capacities, and workloads at every stage. The intents of the earlier families remain in use, and the compiler is tested on them. Because most families differ in their clauses, the instruction text mostly identifies the stage. We call such stages instruction-separable. Stream II: context drift under recurring intents. Here the intents recur but the deployment changes: the same families return while the ranges from which their contexts are drawn shift between stages, which we call context drift. Contexts come from two context settings: the first makes the edge smaller and cheaper and the cloud more expensive than the second does. Prices differ by a factor of two to four between them. Each stage is one of four

5.5

Models and methods

The backbone is Gemma-2B-it [7] with IA3 on all decoder blocks (Adam, learning rate 10−4 , batch 16). Two update rules are studied: plain sequential tuning of the adapter, with no protection against forgetting, and standard experience replay under the memory quota of (5), caching 50 exemplars per earlier stage and adding them to every later stage’s training data. As an upper bound, the joint ceiling trains one adapter on all stages of a stream at once, with about the same total number of optimiser steps as the whole sequential run. Separately from the update rules, the tuned compiler itself is compared against other ways of turning an intent and a context into 𝜽 . These translation baselines (see Table 3) use the same schema and the same rollout scoring as the compiler, and they fall into four groups, each answering one question. Group 1 is the floor: the schema default. Group 2 is given the correct canonical intent, so its gap is the solve score; it asks whether choosing the knobs needs a generative model once the parse is known. A clause-type lookup returns one stored 𝜽 per intent family and combination of clause types, and ignores the context. A regression head predicts each free knob from the frozen backbone’s embedding of the prompt (intent text and context), taking the canonical intent and fixed knobs from the gold parse. Search at inference runs a greedy single-knob search on the simulator at test time, with a budget of 10, 30, or 60 rollouts. Group 3 is given only the intent text and the context and runs no rollouts, so its gap is the end-to-end score. The zero-shot backbone tests whether tuning is needed at all. A grammar parser plus rules matches the text against the training wordings and then applies the lookup, and retrieval returns the label of the most similar training example; both test whether a tuned model is needed. The joint ceiling and the replay-tuned compiler are the tuned models. Group 4 starts from the replay-tuned compiler’s output and spends sixty rollouts of search; it asks whether search can replace or complement the compiler. Parse + search from the default keeps only the compiler’s parse, resets the free knobs to the schema defaults, and searches from there. Answer + search from that answer starts the search at the full configuration the compiler emitted.

Continual Instruction Tuning for LLM-based Management of Continuum Resources

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

Table 2: Preliminary results on the 2B backbone (eight stages per stream, two orders; lower is better).

Table 3: The tuned compiler against the translation baselines on the Stream I test set. Each entry is the mean gap (4) over the test intents (lower is better).

Stream I Method

AG

Stream II 𝐹

AG

𝐹

Sequential IA3 Replay (50/stage)

0.51–0.53 0.29–0.33

0.23–0.26 0.03

0.74–0.75 0.17–0.18

0.67–0.70 0.06–0.07

Clause-type lookup Retrieval Joint ceiling

0.31 0.41 0.28

– – –

∗ ∗ 0.15

– – –

Each stream is run in both stage orders. A range gives the two per-order values. (–) denotes an inapplicable metric; (∗) not evaluated on that stream’s test set.

5.6

Success criteria

The experiments test four criteria: The knobs matter: the search reference 𝜽 ★ must substantially outperform the schema default 𝜽 def in objective value and induce distinct controller behaviour (e.g., different placements or worker counts); if default parameters perform competitively, compilation provides no practical benefit. Compiling is not a lookup: the tuned compiler must achieve a lower gap than the two model-free shortcuts, the clause-type lookup and retrieval, on contexts unseen during training; if a shortcut suffices, the mapping is trivial and no model is needed. Forgetting is real: when the compiler is tuned stage after stage with no protection against forgetting, its forgetting 𝐹 must erode a clear share of the improvement that the search reference offers over the default. Forgetting can be reduced: at least one update rule must cut 𝐹 substantially below that of unprotected tuning.

6

Preliminary experimental results

We ran the protocol of Section 5 on one backbone, with all 60 contexts per stage (36/12/12 train/validation/test) and three training seeds for every trained model except the Stream II joint ceiling and the regression head, which have one. In deployment the validator rejects an invalid output (Section 4.2). For measurement, rejection would score every invalid output at gap 1 and hide how close it came to a usable answer. When scoring, we therefore repair it (unknown knobs dropped, values outside the allowed set snapped to the nearest allowed value, missing knobs set to their defaults) and execute the result: repair is a scoring convention, not part of the system. Repair can only lower a gap, so the gaps reported below are lower bounds on what the deployed validator would charge, most of all for sequential tuning, whose outputs are invalid far more often than replay’s. Table 2 reports the two update rules and Table 3 the translation baselines. Knobs drive performance, but simple lookups suffice on certain families. The first criterion holds: across six representative intents, one for each constraint that can bind (capacity, budget, energy, link, priority, residency), the parameters found by search improve on the default by a median of 0.73 in objective value, and the references of any two of these intents set different worker counts or placements, so the knobs change what the controller does, not only how a run is scored; choosing the knobs therefore matters.

Method

Rollouts

Seen

Reworded

0

0.93

0.93

Group 2: given the correct canonical intent (solve score) Clause-type lookup 0 Regression head (frozen embeddings) 0 Search at inference 60

0.31 0.29 0.29

– 0.41 –

Group 1: the floor Default 𝜽 (no knob chosen)

Group 3: given only the intent text and the context, no rollouts (end-to-end score) Zero-shot Gemma-2B-it 0 0.92 – Grammar parser + rules 0 0.31 0.84 Retrieval (intent + context) 0 0.41 – Joint ceiling 0 0.28 0.33 IA3 +Replay 0 0.29–0.33 0.37–0.38 Group 4: given only the intent text and the context, then sixty rollouts of search IA3 +Replay, parse + search from the default 60 0.62 – IA3 +Replay, answer + search from that answer 60 0.21 – Tuned models and Group 4: means over three training seeds; IA3 +Replay gives the two stage orders, as in Table 2, and Group 4 starts from Order A. Search at inference scores each candidate on one simulator seed, then re-scores its best candidate and the default on three (about six more rollouts); Group 4 scores every candidate on three. Seen: training wordings; Reworded: held-out paraphrases; (–) not evaluated.

The second criterion holds only on some families. The clause-type lookup reaches a mean gap of 0.31 on Stream I when given the correct canonical intent, close to the 0.28 of the joint ceiling, the best the tuned compiler reaches here. The 0.31 is a mean over eight families, whose gaps range from 0.08 to 0.60. On the budget-elastic and budget-two-pool families, the lookup’s gap is only 0.08 and 0.17, so one stored vector per combination of clause types already serves well there. On the priority-two-pool and layer-placement families, the lookup loses 0.45 and 0.60 of the improvement that the search reference offers over the default: for these intents the best free knobs change with the prices and capacities of the context, a stored vector cannot follow them, and a model that reads the context is needed. The tuned compiler is on par with the strongest baselines, and ahead of the parser on rewordings. Table 3 suggests that the compiler’s advantage lies in parsing the intent, not in choosing the knobs. Given the correct canonical intent, a regression head on frozen embeddings comes close to the joint ceiling (0.29 against 0.28), so it chooses the free knobs about as well as the compiler. On rewordings, however, the head’s free knobs follow the embedding of an unseen wording, and its gap rises to 0.41, against 0.37–0.38 for the replay compiler and 0.33 for the joint ceiling, which parse the text themselves. Furthermore, inference-time search replaces the compiler only at a cost of sixty rollouts per intent: even with the correct canonical intent, it needs all sixty to match what the compiler achieves with none; started instead from the compiler’s parse with the free knobs at their defaults, and scoring each candidate on three seeds, search stays worse than the compiler at every budget (0.80, 0.71, and 0.62 at ten, thirty, and sixty rollouts). Nevertheless, compilation and search are complementary: warm-starting the same search from the compiler’s prediction achieves a gap of 0.21 at sixty rollouts, surpassing both the joint ceiling (0.28) and

IOT 2026, November 17–20, 2026, Newcastle Upon Tyne, England, United Kingdom

the lookup (0.31). Finally, the zero-shot backbone fails at the task (0.92, close to the default). Sequential tuning forgets in the executed objective; replay nearly eliminates forgetting. The third and fourth criteria hold (Table 2). When the adapter is tuned stage after stage with no protection, it forgets on both streams, and far more on Stream II, where the forgetting measure 𝐹 is about three times that on Stream I. On Stream I, its average gap after the final stage (0.51–0.53) is no better than retrieval (0.41), which copies the label of the most similar training example. Output inspection shows two kinds of error on earlier families: the model drops canonical clauses and invents out-of-schema knob names. Both are small changes to the output text; only the rollout reveals their cost, as a missing clause or knob can change what the controller does. Replay limits forgetting to 𝐹 ≤ 0.07 across all entries, with AG within 0.05 of the joint ceiling.

7

Conclusion and future work

Our results suggest that large language models can manage continuum platforms at a high level without occupying the fast loop. Formulated as a continually instruction-tuned intent compiler coupled with a deterministic tactical controller, our architecture is auditable and lightweight: an intent is stated in natural language, a compact model compiles it once, off the per-epoch path, and the tactical controller executes it, with a validation gate between the two so that no output of the model reaches the platform without being checked. Our preliminary findings indicate that catastrophic forgetting is pronounced in executed objectives, that experience replay largely remedies it at the cost of memory overhead for stored exemplars, and that a tuned compact compiler performs on par with simpler translators while being more robust than a grammar parser to rephrased intents. Limitations. Our preliminary evaluation is small-scale and simulation only, relying on a synthetic intent grammar. The supervision labels are heuristic (best-found via search), not globally optimal. Furthermore, the experiments are limited to a single 2B backbone, two stage orderings, and experience replay as the only anti-forgetting mechanism reported here. Future work. First, investigating replay-free continual instruction tuning would enable deployment on platforms that are privacysensitive or resource-constrained and prohibited from retaining past data. Second, testing larger LLM backbones will clarify whether the compact model’s advantages in intent parsing persist at scale, and will quantify the resulting trade-offs in inference latency and edge deployability. Finally, transitioning to a physical testbed platform represents the most significant shift. By replacing simulated rollouts with measured outcomes, it also offers a cheaper source of reference labels: the traces of a manually tuned controller record which parameters served which intents in which contexts, and could replace the search if they prove good enough references.

Acknowledgments This research was partially supported by the FIS2 Grant from the Italian Ministry of University and Research (Grant ID: FIS202303382). We acknowledge ISCRA for awarding this project access to the LEONARDO supercomputer, owned by the EuroHPC Joint Undertaking, hosted by CINECA (Italy).

Li et al.

References [1] Negin Akbari, John Grundy, Aamir Cheema, and Adel N. Toosi. 2025. IntentContinuum: Using LLMs to Support Intent-Based Computing Across the Compute Continuum. In 2025 IEEE International Conference on Web Services (ICWS). IEEE, Piscataway, NJ, USA, 573–583. doi:10.1109/ICWS67624.2025.00079 [2] Jack Bell, Luigi Quarantiello, Eric Nuertey Coleman, Lanpei Li, Malio Li, Mauro Madeddu, Elia Piccoli, and Vincenzo Lomonaco. 2025. The Future of Continual Learning in the Era of Foundation Models: Three Key Directions. In Proceedings of the Workshops at the Fourth International Conference on Hybrid Human-Artificial Intelligence (HHAI-WS 2025) (CEUR Workshop Proceedings, Vol. 4074). CEURWS.org, Aachen, Germany, 525–548. https://ceur-ws.org/Vol-4074/paper1013.pdf [3] Fransiscus Asisi Bimo, Chun-Kai Lai, Zhi-Yuan Yang, and Ray-Guang Cheng. 2026. Contract-based Agentic Intent Framework for Network Slicing in O-RAN. In IEEE INFOCOM 2026 – IEEE Conference on Computer Communications. IEEE, Piscataway, NJ, USA, 1–6. doi:10.1109/INFOCOM59046.2026.11571375 [4] Alexander Clemm, Laurent Ciavaglia, Lisandro Zambenedetti Granville, and Jeff Tantsura. 2022. Intent-Based Networking – Concepts and Definitions. RFC 9315. doi:10.17487/RFC9315 [5] Gabriela da Silva Machado, Gustavo Z. Bruno, Alexandre Huff, José Marcos Camara Brito, and Cristiano B. Both. 2026. ORION: Intent-Aware Orchestration in Open RAN for SLA-Driven Network Management. arXiv:2603.03667 [cs.NI] [6] Kristina Dzeparoska, Jieyu Lin, Ali Tizghadam, and Alberto Leon-Garcia. 2023. LLM-Based Policy Generation for Intent-Based Management of Applications. In 2023 19th International Conference on Network and Service Management (CNSM). IEEE, Piscataway, NJ, USA, 1–7. doi:10.23919/CNSM59352.2023.10327837 [7] Gemma Team. 2024. Gemma: Open Models Based on Gemini Research and Technology. arXiv:2403.08295 [cs.CL] [8] Lanpei Li, Antonino Vaccarella, Vincenzo Lomonaco, and Massimo Coppola. 2026. ContinuumBench: Benchmarking Joint Autoscaling and Placement Across Evaluation Regimes in the Cloud-Edge Continuum. In Euro-Par 2026: Parallel Processing Workshops (6th Workshop on Flexible Resource and Application Management on the Edge, FRAME 2026) (Lecture Notes in Computer Science). Springer, Cham, Switzerland. To appear. arXiv:2609.08946 [cs.DC] [9] Haokun Liu, Derek Tam, Mohammed Muqeeth, Jay Mohta, Tenghao Huang, Mohit Bansal, and Colin Raffel. 2022. Few-Shot Parameter-Efficient Fine-Tuning is Better and Cheaper than In-Context Learning. In Advances in Neural Information Processing Systems, Vol. 35. Curran Associates, Inc., Red Hook, NY, USA, 1950– 1965. doi:10.52202/068431-0142 [10] Yun Luo, Zhen Yang, Fandong Meng, Yafu Li, Jie Zhou, and Yue Zhang. 2025. An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Fine-Tuning. IEEE Transactions on Audio, Speech and Language Processing 33 (2025), 3776–3786. doi:10.1109/TASLPRO.2025.3606231 [11] Thomas Pusztai, Andrea Morichetta, Víctor Casamayor Pujol, Schahram Dustdar, Stefan Nastic, Xiaoning Ding, Deepak Vij, and Ying Xiong. 2021. A Novel Middleware for Efficiently Implementing Complex Cloud-Native SLOs. In 2021 IEEE 14th International Conference on Cloud Computing (CLOUD). IEEE, Piscataway, NJ, USA, 410–420. doi:10.1109/CLOUD53861.2021.00055 [12] Luigi Quarantiello, Lanpei Li, Ehsan Tavan, Irene Testa, Giacomo Carfì, Gerlando Gramaglia, Jack Bell, Daniele Malitesta, Pierre Averty, Eric Nuertey Coleman, and Vincenzo Lomonaco. 2026. Winter Is Over for Continual Learning: From Continual Representation Learning to Continual Learning Agents. In Proceedings of the AIxIA Discussion Papers 2026 (AIxIA-DP 2026) (CEUR Workshop Proceedings, Vol. 4270). CEUR-WS.org, Aachen, Germany, 6 pages. https://ceur-ws.org/Vol4270/short9.pdf [13] Antonino Vaccarella, Lanpei Li, Vincenzo Lomonaco, and Massimo Coppola. 2026. Smart Adaptive Computing Across the Continuum: LLMs in IoT-EdgeCloud Resource Management. In Euro-Par 2026: Parallel Processing Workshops (6th Workshop on Flexible Resource and Application Management on the Edge, FRAME 2026) (Lecture Notes in Computer Science). Springer, Cham, Switzerland. To appear. arXiv:2609.09348 [cs.DC] [14] Changjie Wang, Mariano Scazzariello, Alireza Farshin, Simone Ferlin, Dejan Kostić, and Marco Chiesa. 2024. NetConfEval: Can LLMs Facilitate Network Configuration? Proceedings of the ACM on Networking 2, CoNEXT2, Article 7 (June 2024), 25 pages. doi:10.1145/3656296 [15] Xiao Wang, Yuansen Zhang, Tianze Chen, Songyang Gao, Senjie Jin, Xianjun Yang, Zhiheng Xi, Rui Zheng, Yicheng Zou, Tao Gui, Qi Zhang, and Xuanjing Huang. 2023. TRACE: A Comprehensive Benchmark for Continual Learning in Large Language Models. arXiv:2310.06762 [cs.CL] [16] Zihan Zhang, Meng Fang, Ling Chen, and Mohammad-Reza Namazi-Rad. 2023. CITB: A Benchmark for Continual Instruction Tuning. In Findings of the Association for Computational Linguistics: EMNLP 2023. Association for Computational Linguistics, Singapore, 9443–9455. doi:10.18653/v1/2023.findings-emnlp.633 [17] Lijie Zheng, Xudong Zhong, Baoquan Ren, Xiangwu Gong, Xinghui Zhu, and Ji He. 2026. From Intent to Infrastructure: LLM-Driven Agent Compilers for ISAC Networks. arXiv:2607.16269 [eess.SP]

Related documents

• QAOA Inside ADMM: Subproblem Wins Do Not Become Decomposition Wins at Matched Budgets#1605226
• EmbodiedIntentBench: Benchmarking Intent-Driven Runtime Adaptation for Mobile Robotic Missions#1605227
• Reproducible LoRA Inference Through Deterministic Split-K Reduction#1605228
• FirstSwap: Pre-Consensus Trade Approvals for Decentralized Market Design#1605230
• PACE: Keeping the Right Tokens in the KV Cache Is Not Enough for Long-Horizon LLM Agents#1605231