PaperlayerView exact revision on arXiv

Source-linked AI summary

Energy-efficient operation of neural operators for virtual sensing

Jason Yoo, Samrendra Roy, Souvik Chakraborty, Syed Bahauddin Alam

arXiv:2609.30580v1cs.LGcs.PF

TL;DR

Virtual sensing repeatedly reconstructs physical fields from changing observations, often on fixed geometry, making the operating cost of repeated spatial computation consequential. The paper compares reusable computation and standard freezing with graph replay across services and execution conditions. In the heat-exchanger study, savings over native graph replay rise from approximately 1% at 1 Hz to 20% at 40 Hz.

  • Problem

    Virtual sensing repeatedly reconstructs fields from changing observations on often-fixed geometry, raising the question of how shared spatial computation affects energy while retaining evaluated predictions.

    Source: §1.1 · p. 2, §2 · p. 8

  • Method

    The study compares trunk reuse and standard freezing with graph replay while holding checkpoints and evaluated outputs fixed, and measures complete service operation across operator structures and execution conditions.

    Source: §2 · p. 8

  • Results

    In the heat-exchanger study, standard freezing and explicit trunk reuse reduced energy relative to native graph replay by approximately 1% at 1 Hz and 20% at 40 Hz.

    Source: §2 · p. 8

  • Takeaways & Limitations

    For a specified field-update sequence, execution choice should account for reusable work, response requirements, and the lifetime over which preparation is amortised.

    Source: §2 · p. 8

    The comparisons use deterministic fixed-query models and finite input collections, and preserve the arrays’ existing physical-field errors rather than establishing broader application validity.

    Source: §2 · p. 8

Abstract

from arXiv · show

Virtual sensing repeatedly reconstructs physical fields from changing observations, often on a fixed geometry. We investigate how shared spatial computation reduces the energy of these updates while retaining the selected checkpoint and its evaluated predictions. In a heat-exchanger service, standard compiler freezing and explicit trunk reuse give similar operating energy reductions relative to graph replay: approximately 1% at one request per second and 20% at forty requests per second. In 15 W mode with fixed clocks, reuse with graph replay completes the same request sequence with 22.0 to 22.5% less energy than eager execution, including preparation and waiting. DeepONet and Fourier neural operator (FNO) controls distinguish the effects of reusable arithmetic and launch overhead. Preparation, artifact construction, and worker replacement add costs outside repeated inference. These results connect operator structure to operating energy and show how update frequency and execution lifetime govern the benefit of computation reuse in physical-field virtual sensing.

1 Results

The results show that reusing fixed spatial computation can reduce energy while preserving evaluated fields, but the realized benefit depends on service load, operator structure, and execution lifetime. Comparisons with graph replay, compiler freezing, and held outputs distinguish computation reuse from other ways of changing service execution.

1.1 Reusing a fixed spatial representation reduces inference energy

  • 108.7, 88.6, 43.0, and 25.8 mJ per request for eager, graph, reuse, and reuse with graph, respectively; reuse with graph reduced paired energy 76.2% relative to eager.All 16 saved output banks were byte-identical on the 310 cases before and after decoding; reuse with graph also reduced response time by 77.7%.Source: §1.1 · p. 2

1.2 Energy savings persist over complete service operation

  • 22.0–22.5% less energy from preparation through closure for reuse with graph than eager at 15 W fixed clocks and 60 Hz, with both completing all 7,200 arrivals.Savings depend on load and clock policy: at 60 Hz with automatic clocks, reuse with graph completed all 7,200 arrivals while eager completed fewer; fixing clocks increased reuse-with-graph total energy by 9.08–9.61%.Source: §1.2 · p. 4, Figure 2 · p. 5

1.3 The reusable work depends on operator structure

  • Adding trunk reuse to an already prepared graph service reduced paired request energy by 48.36% on Jetson, 41.84% on A2000, and 73.49% on RTX 5060 Ti.DeepONet reuse removes repeated trunk work while branches and contraction still process each input; FNO has no corresponding fixed trunk, and graph replay reduced response time 20–29% while median paired request-energy changes were below 3%.Source: §1.3 · p. 4

1.4 Standard freezing and the cost of retaining execution

  • 18.7–18.8% energy reduction for manual reuse with graph and 18.5–18.6% for freezing with graph relative to native graph at 40 Hz over 30 s.Over 120 s, reductions for reuse with graph and freezing with graph rose from about 1% at 1 Hz to about 20% at 40 Hz; charging artifact construction changed the 10-second, 10-Hz freezing comparison from a 5.41% saving to a 20.01% increase.Source: §1.4 · p. 6, Figure 4 · p. 7

1.5 Retaining computation differs from holding an earlier field

  • Refreshing only once per 60 fuel-cell observations increased temperature RMSE for MIMONet from 0.03756 to 0.11279 °C and for ridge from 0.01120 to 0.11226 °C; the offline policies did not measure energy.During heat-exchanger worker recovery, all twelve replacement workers qualified against the archived target in 3.78–4.63 s, but 503 arrivals were unavailable and 66 exceeded the queue-age limit.Source: §1.5 · p. 8

2 Discussion

Operator structure determines which computation can be shared, while service policy and execution lifetime determine the resulting energy savings. The comparisons also distinguish computation reuse from changes in update availability and are scoped to deterministic, fixed-query models evaluated on finite input collections.

2 Discussion

  • Relative to native graph replay, standard freezing and explicit trunk reuse reduce operating energy by approximately 1% at 1 Hz and 20% at 40 Hz.The savings vary with request rate even for the same checkpoint and output fields.Source: §2 · p. 8
  • DeepONet reuses trunk arithmetic while FNO graph replay mainly reduces launch overhead; fixed clocks shorten heat-exchanger responses but increase RG service energy by approximately 9%.Execution selection must account for the intended request sequence, response times, and memory requirements.Source: §2 · p. 8
  • Frozen-artifact construction costs more than the savings in a 10 s episode but less than the savings in 120 and 600 s episodes.Construction is charged once per artifact, while preparation recurs at each worker start; an artifact can serve multiple worker lifetimes with fixed checkpoint, geometry, and configuration.Source: §2 · p. 8
  • Worker replacement affects delivery costs and unavailable updates, while holding both fuel-cell predictors for 60 observations nearly erases the fresh temperature predictor's accuracy advantage.Reuse evaluates new observations; reducing field-update frequency changes the physical information available to the consumer.Source: §2 · p. 8
  • The comparisons cover deterministic fixed-query models and device-local outputs from finite input collections, and support choosing execution by reusable work, response needs, and preparation lifetime.The heat-exchanger evaluation uses CFD, while the recorded fuel-cell sequence serves as a timing control with a more accurate ridge baseline.Source: §2 · p. 8

Methods

The methods hold models, references, and service interfaces fixed to compare execution choices, while measuring complete service operation and qualifying replacements against retained targets. Separate Darcy, framework, resource-history, and recorded-cadence experiments probe the scope and costs of reuse.

Heat-exchanger model and execution controls

  • The heat-exchanger controls retain the released checkpoint, native grid, preprocessing, and float32 configuration, while fixed-trunk reuse keeps the trunk tensor invariant and branches dynamic.The factorial compares eager, graph, reuse, and reuse with graph; its recorded MAXN_SUPER configuration differs from the later service configuration.Source: Heat-exchanger model and execution… · p. 9

Matched heat-exchanger service and operating changes

  • Service comparisons hold the checkpoint, input bank, decoder, and worker interface fixed, and account for warmup, arrivals, draining, and closure in complete-sequence energy contrasts.Equal-work contrasts require completion of the same offered sequence; preparation-to-closure excludes input-bank loading and inter-block cooling.Source: Matched heat-exchanger service and… · p. 9

Standard freezing and operating costs

  • The standard-freezing extension compares six heat-exchanger paths across request rates and durations, includes preparation in its energy interval, and measures artifact construction separately.Only completed equal-work conditions enter paired energy estimates; the extension acquired 115 of 126 planned blocks.Source: Standard freezing and operating costs · pp. 9–10

Energy, timing and statistical units

  • Energy is integrated from timestamped module-input power, while request-energy boundaries include interarrival idle and exclude preparation, auditing, and recovery in the paced Darcy cohort.Fresh processes or worker blocks—not requests, telemetry samples, or grid points—are the experimental units; reported ranges are observed ranges, not confidence intervals.Source: Energy, timing and statistical units · p. 10

Retained targets, qualification and runtime checks

  • Workers are qualified against retained device-local targets, with byte identity used for the primary service comparisons and live guards checking exposed settings and dependencies.Witness agreement is distinct from preservation over the full input domain because private runtime state is not mechanically verified; failed requests are not automatically replayed.Source: Retained targets, qualification and… · pp. 10–11

Darcy execution and physical-error controls

  • Darcy DeepONet and FNO experiments compare reuse paths under device-local configurations, checking complete outputs and separately auditing decoded physical predictions.The 72-block study compares five DeepONet paths and three FNO paths; the serving interval excludes scientific preprocessing and physical decoding.Source: Darcy execution and physical-error… · p. 11

Comparison with an established serving framework

  • Ray Serve and OpCert share the RG backend, target, witnesses, and guards; paired blocks compare their service operation and replacement after tracked mutation.Each driver offers 7,200 requests over 120 seconds with one replica and one outstanding request.Source: Comparison with an established serving… · p. 12

Numerical alternatives and their scope; Resource-history and profiling controls

Data availability

Study data and related assets have different availability routes.

Data availability

  • During peer review, figure data, retained output arrays, execution records, and profiling traces are available to editors and reviewers from the corresponding author on request.Public deposition is planned upon acceptance.Source: Data availability · p. 12
  • The original MIMONet checkpoint and heat-exchanger simulation data are available through the archived data and code release, and measured fuel-cell data are deposited by the University of Seville.The Well datasets and released checkpoints are available through the original project.Source: Data availability · p. 13

Code availability

The authors describe access to the implementation materials and planned public release.

Code availability

  • OpCert, experiment code, and analysis scripts are available to editors and reviewers from the corresponding author on request during peer review.Public code release is planned upon acceptance.Source: Code availability · p. 13

Funding statement

The study reports support from the National Science Foundation.

Funding statement

Supplementary Information

The supplement documents the comparison boundaries, reference checks, and execution conditions behind the heat-exchanger measurements. It reports continuous-inference costs while distinguishing preserved local predictions from cross-platform numerical differences.

Supplementary Information

  • Module-energy comparisons use different input/output boundaries and timing intervals, with waiting included and idle power not subtracted.Continuous inference includes preparation and closure, while other comparisons may include warmup and arrival horizons or exclude decoding and post-block comparison.Source: Supplementary Information · p. 19
  • Repeated power readings and integration checks do not establish sensor-calibration uncertainty, and requests or field locations are not additional replicates.Paired summaries report medians and observed ranges rather than confidence intervals.Source: Supplementary Information · p. 19

Supplementary Note 1. Heat-exchanger execution costs and source comparison

Reference and physical-output comparison

  • All four Jetson arms produced mutually byte-identical saved output banks, but failed byte identity against the workstation source reference on all 310 cases.The table compares mean relative L2 errors, maximum field differences, and the largest per-case error increase; the two software stacks can contribute numerical differences.Source: Reference and physical-output comparison · p. 20, Table 1 · p. 20

Continuous-inference costs and device configuration

  • Trunk reuse retains 16,289,792 bytes of local features while removing approximately 3.132 GFLOP of dense trunk computation per request.The benchmark cycles through 310 inputs with one outstanding request and includes complete CPU preprocessing and physical-output materialisation.Source: Continuous-inference costs and device… · pp. 20–21
  • The continuous-inference results use a retained engineering-board configuration, not a confirmed 15 W mode; short blocks do not establish thermal steady state or absence of throttling.The 15 W command returned a GPU-context reboot requirement, and no reboot or mode change occurred.Source: Continuous-inference costs and device… · pp. 20–21
  • Median block mean module power was 16.58, 19.80, 12.80 and 17.51 W for E, G, R and RG, respectively; lower RG energy per request did not mean lower average power.The continuous-inference paths preserve the evaluated local outputs, and the benchmark uses the recorded Jetson configuration.Source: Table 2 · p. 20, Continuous-inference costs and device… · p. 21

Supplementary Note 2. Heat-exchanger service energy and execution controls

The service and execution-control measurements compare fixed-target heat-exchanger updates under different power policies, reuse methods, and deployment durations. The results show that equal-work energy savings, recovery costs, and artifact-construction costs depend on operating conditions and service lifetime.

Power, clock policy and worker replacement

  • Preparation-to-closure energy reductions were 22.5289%, 22.0427% and 22.0126% for matched 7,200-request sequences at 15 W fixed clocks and 60 Hz.The paired ratios are summarized by their median; cross-mode comparisons and partially completed sequences are not pooled into the estimate.Source: Power, clock policy and worker… · pp. 21–22
  • Replacement through qualification took 3.779–3.850 s and 22.18–22.65 J after worker exit, or 4.565–4.630 s and 26.81–27.30 J after tracked mutation.Across 7,200 arrivals, 6,631 replies were returned, 503 were unavailable during recovery and 66 were queue refusals; the target was not regenerated.Source: Power, clock policy and worker… · p. 22

Compiler freezing of fixed-coordinate computation

  • Compiler freezing reduced the graph from twelve aten::linear operations to eight, and frozen and manually reused models matched eager output bytes on all 310 cases in three fresh processes.After five warmups, process-mean latency ranges were 0.680–0.682 ms for eager, 0.374–0.378 ms for manual reuse and 0.354–0.358 ms for compiler freezing.Source: Compiler freezing of fixed-coordinate… · p. 22

Request rate, service duration and preparation cost

  • The measurements use a fixed 15 W automatic-clock setting and device-local target; saved preflight banks matched all 310 normalized and decoded outputs byte for byte.The 90 blocks include six-path comparisons, rate–duration blocks and ready-idle controls, while the TensorRT candidate failed the byte criterion and was not evaluated for service energy.Source: Request rate, service duration and… · pp. 22, 24
  • The five artifact builds consumed 19.616–24.963 J and took 3.425–4.451 s; every saved artifact reproduced all 310 archived output fields byte for byte.The separately measured build interval includes imports, loading, CUDA initialization, tracing/checking, freezing and saving, but excludes interpreter startup and subsequent output audit.Source: Request rate, service duration and… · p. 23
  • Charging the median 19.793 J artifact-build cost changed FG savings relative to G to −2.50% at 1 Hz for 120 s and 17.68% at 40 Hz for 120 s.At 10 Hz, charged savings were −20.01% for 10 s, 3.62% for 120 s and 6.13% for 600 s; negative values denote increased energy.Source: Request rate, service duration and… · p. 23
  • At 10 Hz, measured paired savings were 4.096–4.277 J over 10 s, 42.502–43.045 J over 120 s and 208.706–213.614 J over 600 s.Every measured build exceeded every 10 s saving and was below every 120 s and 600 s saving; this sensitivity does not estimate a crossover time.Source: Request rate, service duration and… · p. 23
  • Darcy DeepONet showed a 16.98% G-to-RG paired reduction at 1 Hz, while FNO E-to-G changes were −0.14% at 1 Hz and 0.49% at 8 Hz.These are separate total-service costs; the Darcy 8 Hz extension was incomplete after an eager refusal and allocation-history guard stopped further acquisition.Source: Request rate, service duration and… · pp. 23–24, Table 6 · p. 24

Comparison with Ray Serve

The configured OpCert service completes the offered sequence, while Ray’s remaining arrivals exceed the dispatch-age limit; queueing accounts for most of Ray’s longer arrival-to-response interval. The comparisons also separate request-energy accounting, profiling evidence, and operational costs that fall outside repeated inference.

Comparison with Ray Serve

  • OpCert completes the offered sequence, whereas Ray’s remaining arrivals exceed the 100 ms dispatch-age limit, so the mean-power comparison covers unequal completed work.Queueing accounts for most of Ray’s longer arrival-to-response interval; all 37,765 returned digests and 1,860 saved output pairs matched the retained target.Source: Comparison with Ray Serve · p. 24, Table 7 · p. 25
  • The primary results describe these configured services, not the best achievable performance of either framework.A repeated pair followed an approximately six-second, 109.5 MiB evidence-copy operation during Ray acquisition; exact remote read boundaries were not logged.Source: Comparison with Ray Serve · pp. 24–25

Requests and measurement interval

  • The CPU-to-CPU service sends complete input tensors to a worker and returns independently owned complete outputs, with only one request in flight.Arrival-to-response includes scheduled-arrival delay; dispatch-to-response spans input encoding through receipt of the complete encoded CPU response.Source: Requests and measurement interval · p. 25

Costs and paired comparisons

  • Paired contrasts use group-matched medians and observed ranges, and are not assumed additive; the arm-median ratio need not equal the median paired ratio.Request energy is integrated interval energy divided by completed requests; response latency is the block median.Source: Costs and paired comparisons · pp. 25–26

Output comparisons and energy accounting

  • Request-energy intervals include idle periods and observed co-use, so small paired differences are not attributed solely to execution strategy.The 20 ms host polling trace is diagnostic; request energy uses cumulative NVML counters on discrete GPUs and integrated module-input power on Jetson.Source: Output comparisons and energy accounting · p. 26
  • Preparation and qualification costs are reported separately from request energy, while earlier 45-block records are not additional replicates of the 72-block comparison.Construction-to-readiness includes each strategy’s construction and qualification schedule; failed admission, retirement, and recovery energy are outside request-energy blocks.Source: Table 8 · p. 26, Output comparisons and energy accounting · p. 27

Supplementary Note 4. Computation and service-path profiling

  • With equal transfer volume of 2,835,856 bytes per request, reuse’s GPU graph-interval sum was 20.32 times shorter than graph replay’s, while parent intervals differed by 3.19 times.The profiling supports less repeated GPU computation while retaining transport and host-service work; overlapping trace categories are not an exclusive latency decomposition.Source: Table 10 · p. 27, Supplementary Note 4. Computation and… · p. 28
  • Cross-process trace selection recovers worker CUDA activity inside the parent’s measured interval without treating overlapping waits, copies, and execution as disjoint costs.The trace-selection procedure uses common-clock timestamps and distinguishes eager kernel-duration sums from graph replay intervals.Source: Supplementary Note 4. Computation and… · pp. 27–28

Supplementary Note 5. Physical decoding and prediction error

The supplementary analyses assess physical-field preservation, operator coverage, and prepared-input reuse under distinct interfaces and cohorts. They report strong numerical agreement in audited cases, while identifying accuracy, configuration, and measurement boundaries that limit interpretation.

Supplementary Note 5. Physical decoding and prediction error

  • Across 80 Darcy comparisons, complete outputs agreed with their references before and after decoding, while relative L2 reports mean error against truth on each model’s native grid.The audit covers checked eager, empirical-pass graph GH, and fixed-trunk reuse; timed G0, ET, and GT arms were not separately decoded.Source: Supplementary Note 5. Physical… · p. 28, Table 11 · p. 28

Accuracy limits of the shear-flow history control

  • On the two served shear-flow windows, every channel was worse than persistence under the decoder, so this checkpoint supports numerical-history tests rather than a favorable accuracy claim.The available artifacts do not fully resolve the checkpoint’s training/export contract, including direct-state versus delta-target choice.Source: Accuracy limits of the shear-flow… · p. 28

Admission across operator families

  • Among 42 operator-configuration cells, 29 selected graphs comprised 20 of 32 Jetson cells and nine of ten RTX 5060 Ti cells; compiler candidates were attempted only in nine workstation cells and all differed or were unavailable.Across 88 candidate records, 65 agreed, 16 differed, three failed, and four were unavailable; the table distinguishes unrepeatable references and unsuccessful constructions.Source: Admission across operator families · p. 29, Table 12 · p. 29
  • In the separately profiled Poseidon-B case, both compiler modes repeated and agreed with each other, yet 60,376 of 65,536 elements differed from eager.The experiment does not evaluate whether that difference is physically acceptable.Source: Admission across operator families · p. 29

Supervision and prepared-input device comparisons

  • The prepared-input supervision control matched all 864 saved fields, with median paired latency increases of 1.16%, 1.37%, and 1.19% on RTX 5060 Ti, Jetson, and A2000, respectively.No energy block was recorded for this control; the separate seven-device replication supports portability of prepared-input execution components, not a paced-service estimate.Source: Supervision and prepared-input device… · p. 30, Table 13 · p. 30

Resolution and reuse mechanism

  • Across ten existing DeepONet checkpoints, Burgers supervised-graph/reuse latency ratios ranged from 1.20 to 2.83, while removed dense work across the resolution study ranged from 0.169 to 58.6 GFLOP per request.The Darcy comparison varies both checkpoint and sensor resolution, making the reuse benefits configuration-dependent rather than an isolated query-grid effect; no energy was measured.Source: Resolution and reuse mechanism · pp. 30–31, Table 14 · p. 30
  • Instrumented eager traces recorded 28 versus four dense matrix operations per request after fixed-trunk reuse, removing 58,622,815,232 dense-operation FLOPs while retaining six logical contractions.The retained trunk tables occupied 90,747,392 bytes; this quantifies a work-storage exchange for this checkpoint, not a batch-one GPU-service timing baseline.Source: Resolution and reuse mechanism · p. 31

Supplementary Note 7. Numerical references and comparison scope

This note defines numerical agreement relative to a retained, configuration- and boundary-specific reference, and distinguishes that agreement from physical validity. Its preservation argument relies on fixed numerical conditions, valid dependencies and storage ownership, and acknowledged checks that do not mechanically verify every condition.

Supplementary Note 7. Numerical references and comparison scope

  • A retained reference is scoped to the checkpoint, input specification, declared numerical configuration, and output boundary used to generate it; prediction accuracy, repeatability, reference agreement, and request completion are separate claims.Darcy and supporting-cohort references are device- and configuration-local, while the MIMONet continuous-inference comparison uses a common workstation target.Source: Supplementary Note 7. Numerical… · p. 31

Checkpoint, input and environment provenance

  • The paced Darcy service uses native-grid DeepONet and FNO checkpoints with positions 0–7 for qualification and positions 8–23 for serving.The declared environment includes float32 and device-specific numerical settings; unrecorded environment fields remain unspecified.Source: Checkpoint, input and environment… · pp. 31–32

Supplementary Note 8. Qualification and execution controls

  • Runtime qualification checks complete output bytes against a retained reference, while live guards inspect exposed settings, state, and resource conditions.A one-bit serialized-output mutation passed runtime checks but was detected by the external byte comparison.Source: Supplementary Note 8. Qualification… · p. 32
  • Preservation over an input domain requires deterministic matching arithmetic, invariant reused values, correct dependencies and storage ownership, and fixed numerical configuration.Hoisting is valid only for computations independent of changing inputs and mutable state; the implementation does not mechanically verify every condition.Source: Supplementary Note 8. Qualification… · p. 32

Deterministic components and retained-reference agreement

  • Empirical capture substitutes observed constructor or transfer values but does not discover arbitrary invariant arithmetic subgraphs, so dense trunk layers require explicit specialisation.FNO scratch-buffer reuse involves mutable storage and needs an overwrite and initialization argument; contents are not compared by runtime checks, leaving untracked in-place writes outside those checks.Source: Deterministic components and… · pp. 32–33

Explicit execution controls and mutable-storage audit

  • The FNO cached buffers changed between inputs despite unavailable version counters, making them mutable scratch storage rather than immutable reused values.The diagnostic did not enumerate private captured temporaries or protect against injected cache corruption; native G0 remains the measured alternative without scratch substitution.Source: Explicit execution controls and… · p. 33

Supplementary Note 9. Resource history and worker recovery

The resource-history tests separate continued execution from recovery after allocator and plan-cache changes. Their outcomes depend on worker and cache policy, and the tested caps do not establish physical memory requirements or general resistance to external memory pressure.

Supplementary Note 9. Resource history and worker recovery

  • Under the tested RTX history, dedicated-pool eager returned all 171 fields exactly, retained 370 MiB reserved and 75.624 MiB allocated, and required no restart.Graph replay was unnecessary for continuation in this history; the result does not imply a 320 MiB physical working set or zero tensor allocation.Source: Supplementary Note 9. Resource history… · pp. 33–34
  • On Jetson, the completed eager episode returned 15 exact fields and recovered in 5.610 s, but graph admission failed for allocation-retry history and later groups were not attempted.This is an incomplete extension, not a three-group comparison or minimum-memory estimate.Source: Supplementary Note 9. Resource history… · p. 34

Resource-history service at a different cap

  • In the separate 304 MiB cap test, graph returned all six restricted requests per RTX group without replacement, whereas eager recorded three resource refusals and recovery took 1.781–1.789 s.On Jetson, eager recovered in 5.942 s and graph admission failed, leaving later groups unattempted.Source: Resource-history service at a… · p. 34
  • The 304 MiB cap does not evict allocations retained during preparation, so continued graph execution does not establish a 304 MiB physical working set or immunity to external pressure.Refusals indicate allocation-failure history, not numerical corruption; replacement workers must qualify against the original reference.Source: Resource-history service at a… · p. 34
  • In A→B→A→C→A input-history probes, all 15 requests matched their targets and later returns to A remained correct, testing input association and storage reuse on those five requests.B and C modify branch payload channels, not the trunk grid, so the probes do not establish support for arbitrary new query grids or physical geometries.Source: Resource-history service at a… · pp. 34–35

Allocator-cap mechanism and interpretation

  • At the profiled Rayleigh–Bénard convolution, the higher-cap plan used 37,914,640 bytes of workspace, while at 0.20 GiB eleven candidate workspace allocations were refused before a zero-workspace plan executed.Across eight test windows the cap changed 97.2–99.9% of output elements; window 120 had relative L2 2.526 × 10^-4 while both predictions had one-step VRMSE 0.0242. Pool release alone does not clear the cached plan; disabling plan caching restored targets in tested cases.Source: Allocator-cap mechanism and… · pp. 35–36

Requalification against the persisted target

The controls test whether outputs remain tied to a persisted target under resource changes and runtime transitions, and define alternative numerical criteria for admission. They also show that candidate eligibility depends on the selected predicate and that recovery can preserve the target while interrupting service.

Requalification against the persisted target

  • The resource-history control found eager execution failed requalification after memory restoration, whereas captured execution refused a request-path allocation and then requalified in the same process.All 24 released outputs matched the pre-intervention reference; the later unsupervised eager calls differed in 524,014 of 524,288 elements.Source: Requalification against the persisted… · p. 36

External occupancy bounds the resource-history interpretation

  • On RTX 5060 Ti, fresh workers completed all trials unchanged at 1,024 and 640 MiB, but all three workers failed their first inference at 448 MiB.The occupancy trials did not reproduce numerical changes, and do not estimate their frequency under ordinary co-tenancy.Source: External occupancy bounds the… · p. 37

Supplementary Note 10. Alternative numerical criteria and recovery controls

  • The Darcy transition controls hold each checkpoint, numerical configuration and 24-input bank fixed, with eight qualification witnesses and 16 evaluation inputs.Fresh processes evaluate each input twice, and references must be finite and byte-repeatable.Source: Supplementary Note 10. Alternative… · p. 37

Numerical predicates and their interpretation

  • The alternative field predicate requires field and gradient ratios no greater than η = 0.01 on every witness, while the flux predicate constrains one section rather than full conservation.Integration can cancel local differences and differentiation can amplify small-scale changes, so field, gradient and flux criteria are not interchangeable.Source: Numerical predicates and their… · pp. 37–38

Candidate outcomes and live admission

  • Both compiled models differed from eager on every evaluation input, while native FNO graph replay and DeepONet fixed-trunk execution preserved all evaluated bytes on three devices.The A2000 FNO failed one qualification and one evaluation input under Efield; its maximum evaluation gradient ratio was 0.0101013 against the 0.01 boundary.Source: Candidate outcomes and live admission · p. 38
  • After weight mutation, withholding recovery caused all three post-fault attempts to be refused, while a periodic-check control returned 16 outputs that all differed from the retained answers.These were mechanism controls run once per model, without latency or energy attribution.Source: Candidate outcomes and live admission · pp. 39–40
  • TensorRT fixed-trunk DeepONet returned a 6.79 ms median response and 0.888 J request energy, versus 5.42 ms and 0.866 J for byte-qualified PyTorch fixed-trunk graph execution on Jetson.The live gate refused Ebit and admitted Enum; field and flux checks passed offline, but were not implemented as live gates.Source: Candidate outcomes and live admission · p. 40
  • The exported qualification-record schema consolidates checkpoint, interface, configuration, retained corpus, predicate, evidence, monitored conditions and recovery policy, but original services did not consume the manifests.Validation checks records and archived events without rerunning inference.Source: Candidate outcomes and live admission · p. 40

Supplementary Note 11. Field reconstruction, missed updates and recovery

This supplementary analysis evaluates spatial field reconstruction from a chronological fuel-cell record and compares delivery and held-field errors under service interruptions. It finds that held-field accuracy need not track freshness, while service recovery determines which fields reach the consumer.

Supplementary Note 11. Field reconstruction, missed updates and recovery

  • The chronological test uses 2,642 later observations from one fuel-cell experiment, reconstructing complete processed current and temperature fields from selected spatial measurements rather than forecasting in time.The temperature inputs draw on 65 native channels; the 292 excluded derived-grid locations are not independent withheld native sensors.Source: Supplementary Note 11. Field… · pp. 40–41
  • For the update-policy comparisons, Ridge is more accurate than the other fixed predictor in both channels, according to the cited passage.Source: Supplementary Note 11. Field… · p. 41

Observed-cadence serving and held-field assessment

  • OpCert missed observations 61–64 and Ray missed 61–67 in each replay, yet all 693 returned physical fields matched the frozen arrays.The repeated delivery sequences produced identical field-error scores; p95 response times were 15.98–16.48 ms for OpCert and 29.93–30.56 ms for Ray.Source: Supplementary Note 11. Field… · p. 42
  • For the recorded fuel-cell segment, three repeats per service delivered the same sequence; errors pooled 121 observation intervals and 292 withheld grid locations, while time and energy were observed ranges over three replays.Energy includes replacement and waiting but excludes initial preparation and shutdown. The consumer holds the latest field between replies.Source: Table 21 · p. 42
  • A held field can partly offset existing prediction error: OpCert current RMSE was marginally below the fresh-model RMSE, so freshness and measured-field accuracy were not monotonic on this sequence.The fresh-model RMSEs were 1.481550 mA/segment and 0.031686 °C.Source: Supplementary Note 11. Field… · p. 42

Refresh policies and observation-window energy

This section separates reuse of computation for fresh fields from holding an earlier field, then evaluates refresh policies and service energy over recorded observations. On this sequence, reduced update frequency changed temperature error substantially, while consumer-field error and energy depended on the delivered sequence and service implementation.

Refresh and age

  • A hold-last consumer's error combines fresh prediction error, implementation difference and change between earlier and current reference predictions; squared terms include cross terms.Thus reducing one component need not reduce measured-field error, and fixed-trunk reuse differs from holding an output.Source: Refresh policies and… · p. 43
  • Refresh policies supplied fresh predictions every k observations for k = 1, 2, 4, 7, 10, 20, 30 or 60, with intervening fields retained; k was not a strict wall-time period.The offline analysis used all 2,642 observations, while service replay assessed delivered fields without operating the fuel cell or a downstream controller.Source: Refresh policies and… · p. 43
  • At one update per 60 observations, MIMONet temperature RMSE increased from 0.03756 to 0.11279 °C, while segment-current RMSE changed from 0.001445 to 0.001453 A/segment.Ridge temperature RMSE increased from 0.01120 to 0.11226 °C, nearly erasing its fresh-predictor advantage; omitted updates had no associated power measurement.Source: Refresh policies and… · p. 43
  • For interruption origins in this one record, four rather than seven unavailable updates lowered MIMONet temperature error at 2,629 origins and segment-current error at 1,197.Shorter interruptions could either increase or decrease measurement error; no safe interruption duration or diagnostic threshold was inferred.Source: Refresh policies and… · p. 43

Observation-window energy

  • The fuel-cell replay integrated module energy from first arrival through 120.998 s, including waiting and replacement but excluding preparation, prechecking and shutdown.Six traces bracketed both boundaries; alternative left- and right-held sample integration differed by at most 0.0144 J, without resolving sensor calibration or loads outside telemetry.Source: Refresh policies and… · pp. 43–44
  • OpCert supplied three more updates while using 19.66–20.11 J less sampled module energy than Ray, with slightly lower held-temperature error and approximately unchanged segment-current error.Energy includes replacement and waiting over the common observation window, but excludes initial preparation and shutdown.Source: Refresh policies and… · p. 44
Loading 2609.30580v1…