A black box reasoning executor video memory recycling qualification control and handover confirmation method and system and a storage medium

Abstract

The application discloses a black box reasoning executor video memory recycling qualification control and handover confirmation method and system and a storage medium. The executor does not provide an atomic interface that can simultaneously prove that the in-transit call has terminated, the resources have been released, and the benefit request has obtained the target device resources. When it is determined that the video memory needs to be recycled, the independent scheduling system performs the following: obtains the residence fact of the current avatar of the bound instance, only when it is fresh and the avatar is consistent, the migration edge of the corresponding irreversible action is opened, the disqualification closes the edge, and the edge must be reopened by re-evidence; according to the evidence classification and qualification determination, it is confirmed that the in-transit call has stopped, and there is no legal migration to enter the release when a qualified stop fact is not formed; a reservation ticket of the bound benefit request is established before release and the quota is reserved, and the reservation ticket is updated or redeemed after release confirmation; only when the device-side landing receipt of the formed benefit request obtaining the resources of the target device is obtained, the completion is submitted. The application reduces the false release and the handover failure, and makes the completed nodes not be repeatedly executed and published.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology for artificial intelligence model inference services. Specifically, it relates to a method, system, and storage medium for a scheduling system independent of the inference executor to perform a recycling session on video memory resources, and to perform qualification control on irreversible actions during the recycling process, and to perform handover and placement confirmation on the amount of recycling and the benefit request, when the inference executor is a black-box inference executor—that is, an inference executor that does not provide an atomic completion interface that can simultaneously prove that "the in-transit call has been terminated, the instance resources have been released, and the benefit request has obtained the target device resources"—when the inference executor is a black-box inference executor—and does not provide an atomic completion interface that can simultaneously prove that "the in-transit call has been terminated, the instance resources have been released, and the benefit request has obtained the target device resources. Background Technology

[0002] 2.1 Definition of Application Scenarios and Recyclable Objects

[0003] Multi-stage inference tasks continuously occupy GPU memory throughout their lifecycle: during the execution of any node, its model execution instance resides in GPU memory, and during node switching, it usually remains resident to avoid overload. When the scheduling system has determined that GPU memory resources need to be freed up for a certain benefit request, the problem is not "who will be executed next" (queue reordering), but "whether the already allocated GPU memory can be safely reclaimed and actually handed over to the benefit request."

[0004] The operating environment in which this invention operates has a decisive characteristic: the scheduling system and the inference executor belong to different control entities. The scheduling system calls the executor through an application programming interface and lacks the instance-level fine-grained control capability uniformly guaranteed by the inference executor; even if the external scheduling entity can implement operating system-level process control, this control method still needs to be qualified according to the actual carrying capacity of the target process. The scheduling system also does not have access to the internal state of the executor (key-value cache, batch slot internal structure, scheduling queue); it can only obtain three types of observations: the state view exposed by the executor, the operating system process view, and device telemetry.

[0005] 2.2 Existing technical solutions and their disadvantages

[0006] Type 1: Recalculation-based preemption. The preempted task is terminated immediately, and all completed calculations are discarded. Recovery is fast, but completed and validated work is discarded, and intermediate results that have already been published will be published a second time after recalculation.

[0007] Type 2: Key-value cache swapping. Requires several gigabytes of data transfer and access to the internal data structures of the inference framework; it is not feasible to implement on a black-box execution side.

[0008] Type 3: Process-level / Driver-layer Transparent Checkpoints and Demand-Aware Preemption. This approach transparently generates checkpoints at the process or driver layer: it is independent of task structure, has a full-process state granularity, and requires privileges; the associated memory reservation is usually recorded in the form of anonymous quotas, and successful and failed preemption are delayed along the same path. Its costs and deployment constraints are not suitable for online inference services. Regarding the two points of concern in this invention: first, anonymous quotas do not point to any specific benefit request, therefore "whether the quota has been delivered to the request that initiated this reclamation" is not a judgment object of this approach; second, the delayed release along the same path does not distinguish between "delivered" and "not delivered," and the termination of reclamation does not include a confirmation step.

[0009] Type 4: General Workflow Resume from Breakpoint. Designed for fault recovery and migration, its triggering conditions are independent of video memory; its steps are typically stateless, eliminating the problem of "several GB of accelerator memory still being occupied between steps." Therefore, there is no "fixed before released" order constraint, no confirmation step for recycling actions, and no concept of resource ownership.

[0010] Type 5: Program-level inference scheduling. Preemption occurs at the scheduling layer (determining who will initiate the next call), without canceling memory residency, incurring overload costs, or involving the cancellation or cessation of in-transit calls.

[0011] Type Six: Eviction and Migration within the White-Box Inference Stack. Eviction or migration requests are synchronized at the iteration boundaries within the inference engine, with release and commit completed synchronously within the same control domain. This presupposes that the controller can access the engine; the premise of this invention is that it cannot.

[0012] 2.3 Five non-implying events

[0013] In the context of black-box reasoning, the following five events are five independent events that cannot be substituted for one another:

[0014] 1. The control plane declares the action successful; 2. The in-transit call actually stops; 3. The execution instance actually disappears from the executor's view; 4. The video memory is actually released; 5. The benefit request actually acquires resources on the target device.

[0015] This application has provided direct counterexamples of pairwise decoupling through its own experiments; see the detailed implementation for specific data:

[0016] Event 1 does not imply Events 2 and 4: An unload command is issued to a busy instance. The executor returns an HTTP 200 status code and declares "unloaded" within 13–44 ms, while all processes continue en route. The actual release time from the command issuance to the device side is 51.7–55.1 s, n=4 / 4 with zero counterexamples. The same phenomenon is reproduced again in the anti-protocol control group: the self-reported response time is 16.9–22.3 ms, and the device remains occupied for 17.8 / 20.2 / 21.6 s (n=3). In the ablation control experiment, the false success window was measured on two different platforms: 24.84 s on the first platform and 11.516 s / 10.99 s on the second platform—the window lengths differ, but the property of "self-reported success preceding state plane fulfillment" is consistent in both platforms (see Examples 3 and 8).

[0017] Event 1 does not imply Event 3: Even on the happiness path, at the same moment the unload self-report response (14.8 / 26.2 / 25.8ms) is issued, the executor's instance list still lists that instance, 3 / 3 (see Example 1 and Example 3).

[0018] Event 3 does not imply Event 4, and Event 4 does not imply Event 3: The model list interface of the executor can remain unchanged for a long time in the direction of "instance disappearance" - the video memory is released on the spot after the card-holding child process is killed, and the interface continues to report that the model is resident for ≥60 s (357–360 polls) thereafter (see Example 10).

[0019] Event 4 does not imply Event 5: Once the video memory is released, it can be obtained by any entity; the session in this application has a reconciliation between release and handover to detect situations where the executed party or a third party intercepts the video memory within the window (see Example 6).

[0020] The official documentation for a certain inference runtime states that readings from device telemetry tools cannot prove that an entity has been released. This statement corroborates the aforementioned experiment in this application: reconciliation of accounts is not a trivial step in this field.

[0021] 2.4 Required wording: "at least one type"

[0022] This application does not make general assertions such as "the black-box reasoning executor does not have any secure preemption means." The experiments in this application have found counterexamples: there is a type of execution direction that sends cancellation reasons to the client in-band (4 / 4 of them receive explicit termination events on the stream), and the cancellation certificate can be directly obtained by the cancelled party without any bypass telemetry; there is also an offloading method that can be directed, per instance, and has an upper bound on the release cost (busy path (+0.362…+1.185] s, n=4; idle path (+0.342…+0.852] s, n=3).

[0023] Therefore, this application uniformly adopts the qualifier: "At least one type of inference executor exists...". Accordingly, cancellation means and evidentiary channels are treated in this application as an evidence matrix for each executor and a choice of evidence source, and are not written as general premises.

[0024] 2.5 Differences between existing forms of related disclosed technologies and the present application in terms of technology

[0025] To clearly illustrate the technical problem to be solved by this invention and its technical solution, a list comparing various disclosed technical forms with the technical forms adopted in this invention is provided below. The table below only illustrates the objective differences in technical forms. Cache freshness gate in container orchestration If the cache lags behind the actual state, skip the current round of scheduling and back off to reorder, i.e., retry the same action; the object being determined is the state written by the user itself. When a fact loses its eligibility, the eligibility for the irreversible action is revoked or downgraded to an alternative action. A new edge must be opened for the current instance to be re-examined. The judgment object is the ledger of the external black-box executor, which is a time-based stale threshold. This "identity dimension" is a prerequisite unique to black-box objects: a normal request without optional parameters can replace a large context instance with a default instance without the scheduler's knowledge (residing 1552 → 1096 MiB, service continuity, normal response, no alarms; this application's actual test reproduced 2 / 2, see §3.2, Category 5); this prerequisite does not exist in white-box cache scenarios that read what they write. Pre-allocation and reservation binding in the field of cluster scheduling Once the preempted party vacates the credit limit, it is bound to the owner's reserved limit, and the write-off occurs during the accounting process; or the release and submission are completed simultaneously. Submission requires that the beneficiary request actually acquires resources on the target device and generates a receipt; release is not the final stage, sessions without a receipt are terminated with partial release / expiration / suspension and explicit repayment of the credit limit. Free space determination in the white-box reasoning stack The engine selects and discards evidence sources based on the scenario (such as the combination of video memory usage and kernel execution). The specific eligibility criteria are hardcoded: memory-based evidence is disqualified during stress periods; utilization-based evidence is disqualified under multi-instance concurrency; queuing circumstantial evidence requires parallel processing, with all slots occupied and end-to-end completion latency as the criterion; client-side stream termination alone is insufficient; and if the criteria are not met, the structure will not enter the release phase (forced by the state machine). Accelerator resource leases and reference counting Release of pre-occupancy upon expiration and non-renewal; three-state migration (pre-occupancy → confirmation → use); monitoring and feedback of access after page table entry-level leases and removal. In this invention, the lease agreement serves only as a supporting base; the feedback object is the side positioning of the beneficiary's equipment, not vibration or margin. Unloaded readback during a certain inference runtime After unloading, the remaining equipment capacity is read back at fixed intervals. Once the threshold is reached, the process proceeds; otherwise, it is unconditionally released after a timeout. Release confirmation is a three-tiered process, with the final outcome being a placement receipt; equipment readings within the distortion range are not eligible, and re-collection is only for auditing, not gatekeeping; submission conditions do not include a "timeout is considered completion" branch. Engine-in-engine expulsion and multi-stage dwell planning Synchronous eviction at iteration boundaries within the inference engine; using residency as a cost signal; dual-threshold allocation and release. This approach requires access to the engine's interior, which differs from the black-box premise of this invention. Demand-aware preemption and memory reservation Preemption is initiated based on demand awareness and memory is reserved with anonymous quotas; successful and failed preemption releases are delayed along the same path; checkpoints are generated transparently at the driver layer, independent of the task structure. The credit limit is bound to a reserved note for a named beneficiary request, and the final submission is confirmed by the device-side receipt of that beneficiary request; sessions without a receipt are terminated with partial release / expiration / suspension and the credit limit is explicitly returned; checkpoints are task node-level outputs, and are fixed before cancellation, with monotonically increasing sequence numbers and session identifiers. Provisional Reservation Agreements in the Field of Cross-Entity Transaction Processing The process involves four stages: provisional retention → term → confirmation → transaction completion; retention is a weak commitment that can be held by multiple parties simultaneously and expires after a certain period; confirmation involves the counterparty's response. The object of confirmation is the device-side fact that the benefit request holds resources on the target device, and this fact is independent of the four events: "control plane declaration of success," "in-transit call termination," "instance disappearance," and "memory release" (as tested in this application, see §2.3); release is not final, the validity of the ticket is limited to this scheduling domain, and cross-entity interception is detected by reconciliation before handover. Recovery of lost graphics devices in cloud interactive systems Insert a detection function into the instruction stream, replay the code, retrieve the receipt, and then perform a two-level judgment based on the receipt value before releasing and rebuilding. All held resources have a lifespan; once the lifespan is reached, they are released and the record is deleted. After rebuilding, perform a self-check to ensure all steps were successful; if unsuccessful, redo the process. The classification focuses on the probative value of the same source of evidence under different operating conditions; the judgment is based on the fact that "the in-transit call has indeed stopped"; the placement receipt is a prerequisite for submitting the retrieval session; the consequence of evidence losing its eligibility is the closure of the state transition edge for entry and release, requiring the acquisition of a new factual party for the current instantiation to reopen it; the object is the black-box reasoning executor. Preemption in the graphical command stream Pre-set arbitration check commands in the command flow, stop the current context only at points where it is safe to interrupt, and record breakpoint addresses for future recovery; the scheduler reads back hardware registers to infer the preemption point. The readback retrieves the fact of "whether the in-transit call has indeed stopped," and makes a qualification determination on that fact: such readings are disqualified under pressure intervals and multiple concurrent instances according to the aforementioned criteria; if they do not pass, the structure will not enter the release; the object is the interface surface of the black-box inference executor. Accelerator resources are reclaimed and redistributed based on their idle state. The system monitors the usage of accelerator resources allocated to the first workload. Once the idle condition is met, the resource is reassigned to the second workload in a waiting state. The idle condition is determined by an idle threshold, which can be the average usage over a period of time and can be zero. The second workload can be selected from the waiting queue based on priority, and the system can determine whether the first workload has run for its full tolerance period before reassignment. Reassignment removes the resource from the first workload and puts the first workload into a waiting state. The workload that was previously reclaimed is now in a waiting state, not terminated. This invention begins with the established state of "it has been determined that memory resources need to be reclaimed for a benefit request," and the determination of the reclamation requirement is not a characteristic step of this invention. The characteristic steps of this invention are: authorizing an irreversible reclamation action based on the fact that the current instance incarnate is bound to it and meets a preset freshness requirement; if this fact fails, the corresponding state transition edge is closed and must be reopened only after re-verification for the current incarnate; determining that the in-transit call has indeed stopped based on tiered and eligibility-conditional evidence; if a valid stop fact has not been formed, there is no legal state transition to enter the release state; and the binding of the reserved ticket and the formation of the benefit request device-side placement receipt constitute the same submission requirement; the absence of either one results in no submission completion. Release the memory of low-priority tasks and allocate it to high-priority tasks according to their priority. Determine the priority of multiple machine learning tasks executed by the graphics processing unit (GPU); when there is insufficient available GPU memory to allocate to a higher-priority task, release at least a portion of the GPU memory resources occupied by the lower-priority task and allocate the GPU memory resources to the higher-priority task. The credit line is bound to a reserved note for a named beneficiary request and retained in this dispatch domain before release. Upon release confirmation, it is updated or cashed out with the actual recovered credit line. Submission completion requires a receipt from the beneficiary request on the target device; both are two halves of the same submission requirement. Prior to release, two additional licensing conditions are established: authorization of factual qualifications and a stop-proof evidence threshold. Accelerators for other tasks are reduced and redistributed based on utility. When allocating accelerator resources, based on a utility assessment of reduction and task requests, one or more accelerators are selectively reduced to exclude them from execution of another neural network-related task. Then, based on the determined task performance improvement, these one or more accelerators are reassigned to the execution of the current task. The determining factors are the current resource utilization status and the estimated task performance improvement. This invention does not use performance improvement estimates or cost-benefit models as the basis for judgment; such estimates are only used as preconditions in this invention. Before reduction / release, this invention performs eligibility checks on the facts themselves (freshness and consistency with the instantiation) and conducts tiered verification to confirm whether in-transit calls have indeed stopped. After allocation, the device-side location confirmation of the benefit request is a necessary condition for completion.

[0026] The first ten categories of disclosed practices in the table above all presuppose the ability to enter the executor's internal space or be in the same control domain as the executor. The last three categories in the table belong to the accelerator resource scheduling field, which implements reclamation and redistribution based on idle state, priority, or utility estimation. The decision factors are resource usage, task priority, or estimated performance improvement. This invention does not limit the above decision factors, nor does it use them as characteristic steps. The characteristic steps of this invention begin after "it has been determined that memory resources need to be reclaimed for a beneficial request". The subject of this invention is the black-box inference executor, whose triple constraints (no instance-level fine-grained control capability uniformly guaranteed by the inference executor, no internal state access, and observation distortion in critical intervals) are all supported by experiments in this application, see §3.1.

[0027] Background art cited literature (all are publicly published or published patent documents):

[0028] 1. Cache freshness gate in container orchestration: Kubernetes enhancement proposal KEP-5647 (v1.36 version text); see also KEP-2340. 2. Pre-allocation and reservation binding in cluster scheduling: Koordinator reservation pre-allocation link (v1.8 documentation, 2026-04-27); Llumnix's four-state transition handshake (pre-allocation → acknowledgment / abort → commit). 3. Idleness determination in white-box inference stack: SGLang's is_fully_idle idleness determination implementation. 4. Accelerator resource leases and reference counting: US 11,947,821 B2; CN 105528249 B. 5. Readback after unloading during inference runtime: Ollam's waitForVRAMRecovery (periodically reads back device availability after unloading, advances if threshold is met, and releases after timeout). 6. Engine-based eviction and multi-stage residency planning: CN 119248522 B; see also the publicly available research papers QLM and FATE. 7. Demand-aware preemption and memory reservation: SwapServeLLM (source code release date 2025-09-19, verified according to source code). 8. Provisional reservation protocol in cross-entity transaction processing: US 2002 / 0087366A1 (2002-07-04). 9. The statement at the end of §2.3 that "device telemetry readings cannot prove memory has been released": TensorRT-LLM official documentation. 10. Recovery of lost graphics devices in cloud interactive systems: CN 105740061 B (Priority date 2016-01-29); related files JP6715334B2 / WO2017129117A1 / KR102091961B1. 11. Preemption of graphics command streams: EP 3014437 A1 (Publication date 2016-05-04, Priority date 2013-06-29). 12. Reclaiming and redistributing accelerator resources based on idle status: US 2026 / 0064476 A1 (Publication date 2026-03-05, Application date 2024-09-04). 13. Release low-priority task memory and allocate it to high-priority tasks based on priority: US 12,292,821 B2 (Grant announcement date 2025-05-06, application date 2023-04-25). 14. Reduce and redistribute accelerators for other tasks based on utility: US 12,360,809 B2 (Grant announcement date 2025-07-15). Summary of the Invention

[0029] 3.1 The technical problem to be solved by this invention: triple constraint

[0030] In this scenario, the scheduling system is subject to three constraints simultaneously, which reinforce each other:

[0031] 1. Lack of instance-level fine-grained control capabilities uniformly guaranteed by the inference executor: Even if the external scheduler can implement operating system-level process control, the eligibility of this control method still needs to be judged according to the actual carrying capacity of the target process. When process termination is used as a release method, its availability depends on which instances reside within the target process—in our experimental tests, the same rule yielded different conclusions for different target processes on the same executor: when the root process is the target, it is not eligible because there are instances outside the release set within the process; however, it is eligible when the model's own runtime child process is the target (see Example 5). 2. No internal state access: The scheduling system cannot see the internal structure of the batch processing slots, the key-value cache, or the executor's internal scheduling queue. Whether "this call is still generating" can only be inferred from the external channel. 3. Observational distortion in critical intervals—this application quantifies each point in the experiment:

[0032] The capacity field reported by the executor is distorted under pressure: when the margin is tight, the reported residence capacity exceeds the actual measured capacity by 1988.1 MiB (48.0%), while the same report shows a deviation of only 299.1 MiB (7.2%) under no-load conditions.

[0033] The sign of this deviation flips with the state: the self-reported deviation under no-load conditions is 85.2–87.2 MiB less than the actual equipment measurement, while the deviation under pressure conditions is 1988.1 MiB more—even a conservative assumption cannot be made, and it can only be discarded as the basis for reconciliation.

[0034] The equipment differential was underreported in the excess area: the expected 2954 MiB of loading only contributed 2097.5 MiB of equipment differential, and the shared usage only made up 164.0 MiB, leaving a total shortfall of 692.5 MiB; at the same time, the only honest quantity was the committed quantity (+3053.5 MiB, whose total exceeded the physical capacity by 814.7 MiB).

[0035] The distortion of the absolute level does not manifest as variance: the same dwell set is 18371 / 20059 MiB at two stable levels, with a difference of 1688 MiB (card capacity 7.5%), while the range of the three samples within the same phase is always 0 (three groups, a total of 9 times, zero discreteness) - the conventional practice of "taking more samples to obtain stable values" cannot detect this distortion on this platform;

[0036] Device-level aggregated telemetry's determination of "call stopped" is ineffective under concurrency: under the condition that cancellation has indeed occurred, the global utilization rate gives 113 / 113 "still busy" (min 94%), with a false negative rate of 100%; however, the call-level status per slot at the same time is correctly distinguished (0 / 206 instances are judged as "stopped" for one instance, and 183 / 183 instances are judged as "still busy" for another).

[0037] Conversely, the state surface evidence at the call level showed no degradation under pressure: the determination delay was +0.085…+0.114s for the idle setting and +0.083…+0.150s for the pressure setting; the endpoint delays were indistinguishable within the sampling granularity; the 6 / 6 true positive and 2 / 2 negative control criteria were removed. Therefore, this invention does not assume that any observation remains valid under the aforementioned distortion conditions, but rather specifies the eligibility criteria for each channel.

[0038] 3.2 List of types of accounting-physical branching (seven categories, all obtained from experiments in this application)

[0039] Under the aforementioned triple constraints, the resident assumption held by the scheduling system will fork with the actual execution. This application lists the forking patterns that have been experimentally reproduced as follows: 1 The executing party shall vacate and evict the vehicle itself. Loading the second model triggers the executor to automatically evict the first: the net increment of the device level in the second loading is negative (−2750 / −2752 / −2752 MiB), the ledger still holds active leases and the belief residency is true; the detection delay (invariant caliber) is 0.658 / 0.889 / 0.779 s, detected on the first reconciliation (n=3; the scene caliber for the same batch is 1.312 / 1.771 / 1.582 s). The second platform file is rerun (n=2), and the detection (invariant caliber) is 0.012 / 0.011 s (the scene caliber for the same batch is 0.040 / 0.039 s). See Example 10. 2 Execution instance crash The child process running with the card is killed while the main process still responds, resulting in true memory release but no record in the ledger; detection (invariant caliber) 1.495 / 0.697 / 1.686 s (n=3); second platform file (same caliber) 0.528 / 0.527 s (same batch scenario caliber is 0.543 / 0.543 s, n=2). See Example 10. 3 The executor view does not converge in the "instance disappearance" direction. Under the same injection type as type 2, the executor model list interface reports that the model resides within ≥60 s (357–360 polls); single-source reconciliation will inevitably miss in this direction. This pattern is an observational inference of type 2, but its consequences are independent: it renders the most natural reconciliation method, "checking the list," ineffective in the crash direction. See Example 10. 4 Automatic unloading upon expiration / timeout of the residency lease Reconciliation is possible at the book expiration time: Actual lease expiration times are 29.993 / 29.995 / 29.997 s. All three channels (device level / executor view / process exit) fall within -0.38 to +0.81 s of the book expiration time, n=3. 5 Silent instance reconstruction triggered by request parameters Inconsistent parameters trigger runtime destruction and reconstruction, with the runtime process identifier changing each time (2 / 2 reproduction); the most dangerous is omission—a normal request without specifying this optional parameter replaces a large context instance with the default instance (residing 1552 → 1096 MiB), while service continuity remains intact, responses are normal, and there are no alarms. 6 Third-party loading and unloading The detection order of channels is reversed in both loading and unloading directions: during loading, the process list is the fastest (+0.54…+0.77 s), followed by device level (+1.27…+2.08 s), and the execution view is the slowest (+1.89…+2.34 s); during unloading, device level is the fastest. If only the execution view is polled, an external load will be detected 1.9–2.3 s later, by which time 3845 MiB of video memory will already be occupied. 7 Silently downgrade to non-target device The executor's device started and responded normally after two consecutive timeouts, while its capacity account showed 0B and its computing power backend showed CPU, with no errors reaching the client or scheduler; cross-validation showed the device was healthy. ⇒ "The executor claims to be running" and "The executor is running on the target device" must be treated as two separate things.

[0040] Explanation of detection latency caliber and grading: The detection latency for categories 1 and 2 in the table above has two calibers. They share the same endpoint (the time the record is detected) but different starting points—the invariant caliber is calculated from the moment the forked injection event is written to the event stream; the scenario caliber is calculated from the moment the action triggering the injection returns, starting earlier, so its value is always no less than the invariant caliber, making it more conservative. The difference between the two is the observation data retrieval pass between "injection action return" and "injection event written to disk": this pass involves process list enumeration on the first platform and kernel pseudo-filesystem on the second platform, hence the difference between the two calibers is also grading (approximately 0.65 s for category 1 on the first platform and approximately 0.03 s for the second platform). The table above and Example 11 in this specification consistently use the invariant caliber, with each platform labeled separately, and scenario caliber values ​​for the same batch provided for verification (cross-platform parallel entries must use the same caliber; otherwise, the data retrieval cost for that pass will be misinterpreted as a protocol difference). The two sets of values ​​are recorded separately, without merging across sets to obtain statistics, and without making any claims about the effect based on the ratio between the two sets.

[0041] Another example of a real-world, live sample (uncontrolled experiment, recorded factually): After the execution agent process was terminated by an external watchdog, its self-initiated execution side also ceased to exist. However, the two running child processes were adopted by the system, continuing to occupy a total of approximately 9.1 GB of memory without any management side (each child process held 4574 MiB; the device level reading at this location was 9152 MiB, differing from the sum of the two processes' holdings by 4 MiB. This difference is on the same order of magnitude as the device's idle capacity, and this manual does not attribute this difference to anything). This event matches the definition of orphan residency item by item, but there is no injection time, no reconciliation data, and no sample size; therefore, it is only recorded as a phenomenon and not cited as experimental data.

[0042] 3.3 Four technical problems arising therefrom

[0043] 1. The issue of the statute of limitations and identity of evidence: The fact that "the instance still exists and can be uninstalled" may no longer hold true at the moment it is used to authorize the uninstallation action—because the instance has been rebuilt, crashed and restarted, or the operating conditions affecting the eligibility of the evidence have changed during this period. The issue is not "whether to refresh outdated records," but "whether this fact is still qualified to authorize this specific irreversible action." 2. The issue of stopping confirmation: Under conditions of no internal state access and distortion in some observation channels during critical intervals, how to determine if an in-transit call has indeed stopped, and make this determination a permissible condition for the release action rather than a suggestive check. 3. The issue of handover finality: Memory release is not the end point of reclamation. The released amount may be intercepted by entities outside the current scheduling domain, or it may be wasted due to the failure of a benefit request to load it. The constituent elements of "successful reclamation" should be anchored to the side of the benefit request, not the side being reclaimed. 4. Work preservation problem of victimized tasks: If preemption comes at the cost of discarding completed work, then nodes that have been completed and passed verification will be re-executed, and semantic nodes that have been published externally will be published a second time. In workflows with external side effects, this is a duplicate side effect, not "taking a little more time".

[0044] 3.4 Terminology Model Execution Instance The runtime entity occupying GPU memory on the inference execution side, with (model, runtime configuration) as the key. Instantiation A specific instance of execution exists: (Instance key, Avatar identifier = Execution process identifier carrying this instance). Evidence and eligibility are bound to the avatar; a change in avatar means all evidence under that avatar loses its authorization eligibility. Nodes / Node gaps / In-transit calls Node = execution unit in a directed acyclic graph of task flow; Node gap = state where a node has been completed but the next node call has not yet been initiated (no calls in transit); Call in transit = inference calls that have been issued but not yet terminated. checkpoint A persistent snapshot of the node set and its output has been completed, with monotonically increasing sequence numbers and session identifiers. cutting edge The set of startable nodes after dependency closure recalculation lease The scheduler grants a task the right to use a specific execution instance, with a time-limited and time-driven heartbeat renewal; the lease expires if the holder becomes unreachable. ledger Persistent lease tables, reserved invoice tables, instance tags, residency assumptions and aging, session tables and pre-write logs Accounts receivable aging The time since the most recent successful reconciliation for a certain instance Reconciliation The process of bringing the ledger to the reality of the executing party; its evidence is itself graded and has eligibility criteria. Reserved invoices The book limit is bound to (benefit request, required amount, and bill maturity); its validity is limited to this scheduling domain. Release set The set of instances where the activity leases are zeroed after the minimum necessary subset of the victim task is revoked. Irreversible action Cancel execution of calls, unload / release, external content publishing, and allow loading. Reclaim the session (hereinafter referred to as the session) A managed process from the moment "resource reclamation has been identified as necessary" until submission for completion or explicit termination. Placement confirmation The scheduling system confirms the fact that "the requested resource has been acquired by the target device" based on device-side measurements, and records this confirmation as a record in the session ledger. A placement receipt must contain at least one device-side observation that directly characterizes the resource acquisition status of the target device; the executor's state view, inference latency, etc., only serve as auxiliary confirmation, unless the state view itself explicitly states the actual placement of the target device. Specific criteria for its formation are detailed in the latter half of Feature (c) in §3.6. pressure range The state where the available video memory of the device at the target time is lower than the product of the requested benefit amount and a preset coefficient; this coefficient and the determination method are obtained according to the parameter determination method described in §3.8. The non-pressure zone (also known as the non-saturation zone) is the state not within the pressure zone. Page Change History (Xiang) A continuous period of time is calculated from the most recent instance where the committed quantity of the device exceeded its physical capacity, or the most recent change in its dwell set; whether two readings cross phase is determined by whether a step occurs in the committed quantity channel reading. Preemptive inefficiency The percentage of sessions where irreversible releases have been implemented but no confirmation receipt has been generated, out of the total number of sessions following this protocol's path. Black box reasoning executor Inference executors that do not provide an atomic completion interface that can simultaneously prove that "the in-transit call has been terminated + the instance resource has been released + the beneficiary request has acquired the target device resource"

[0045] 3.5 Core Chain of Technical Solution

[0046] Resource recovery has been determined → Does the current situation qualify for authorization of the corresponding irreversible action? → In-transit calls must form a valid stop fact → before release is allowed → After release, the resource is handed over to the beneficiary request → Only when the beneficiary request obtains the device-side receipt of the target device resource is the submission complete.

[0047] Each link in this chain corresponds to a technical problem in §3.3, and each link is supported by empirical tests in this application. The starting point of the chain is the established state of "resource reclamation has been determined to be necessary": the triggering judgment of reclamation demand, the estimation of target resource quantity and safety margin, the profit judgment of whether to preempt, and the entry and placement determination are all merely preconditions and are not characteristic steps of this invention. In the implementation of this invention, the determination of reclamation demand, target resource quantity, and safety margin can all be obtained by any available resource estimation method, and the specific method of obtaining them does not affect the execution of each characteristic step of this invention; therefore, this invention does not limit them.

[0048] 3.6 Technical Descriptions of Each Feature

[0049] Feature (a) Factual Qualification Authorization

[0050] What it does: For the execution instance involved in the candidate victim task, obtain the actual residency fact of its current instance incarnation (the incarnation identifier consisting of the instance key and the process identifier of the execution side carrying the instance); only when the fact satisfies the preset freshness and its bound incarnation is consistent with the current incarnation, will the irreversible reclamation action authorized by the fact be opened for the instance. When the fact loses freshness, or the incarnation changes, or the operating conditions affecting the eligibility of the fact change, the state transition edge of the irreversible action is closed, and the edge is reopened only after obtaining the new fact for the current instance incarnation.

[0051] What problem is being solved: Question 1 in §3.3. The key point is "authorization semantics" rather than "maintaining semantics"—not "refreshing old accounts," but rather "the fact used to authorize an irreversible action loses its eligibility ⇒ the state transition edge of that action closes ⇒ new evidence is obtained for the current incarnation ⇒ only then does the edge reopen." The transition edges of each irreversible action are independent of each other, and eligibility is re-established for each action: cancellation is performed on both the execution call and unloading / releasing processes, with each incarnation's consistency determining the opening condition for its transition edge; allowing loading is not allowed if, before handover, reconciliation reveals that the quota has been occupied by a subject outside this scheduling domain.

[0052] Actual test results: In the ablation control experiment, the avatar gate knockout arm (only avatar verification is turned off, and the aging gate is refreshed as usual) reproduced the characteristic error I1×5 ("Irreversible release was authorized with evidence of a different avatar: runtime identifier at the time of evidence collection ≠ runtime identifier at the time of action") on the deterministic carriers of two platform files, with I4 = 0; under the same injection, the final state of the fully open control was explicit termination, unloading was not issued, and I1 = 0. On the real machine carrier, this arm I1×2 was 0 for fully open (see Example 8). This comparison directly shows that "refreshing the aging gate once before the action" cannot prevent avatar drift - the aging gate and the avatar gate are two gates, not two statements about the same gate. The performance in another direction is shown in Example 4, item 05: the pre-write log has recorded the unloading intention, the instance disappears, the recovery party cannot get the avatar (judged as unavailable) ⇒ no release is authorized, converges to explicit termination and returns the ticket.

[0053] A detailed description of the scope of implementation: In the reference implementation of this application, the avatar gate is actually enforced on the two irreversible actions of canceling the call and unloading; the pre-interception of the third irreversible action "allowing loading" is handled by the third party interception detected during the pre-handover reconciliation, rather than the avatar verification; the avatar verification on the crash recovery leg is only recorded and does not close the migration edge (this leg itself does not generate new irreversible actions). This specification does not describe the three places as the same gate.

[0054] Feature (b) Stop Evidence Gate

[0055] What to do: For victimized instances where calls are in transit, after cancellation measures are implemented, confirm that the call has indeed stopped based on evidence classification and eligibility criteria. The eligibility criteria will be clearly defined. EA Status Facts The call-level handle / slot disappears from the executor task view; the executor process disappears; a termination event appears in the executor log. The verifiable state-level facts from a third party are considered authoritative; their availability is determined by the evidence matrix of each executing party, serving as a source of evidence without requiring necessary technical features. EB corroborating evidence ① Cancel the interface confirmation response The execution party must have offline probing of the cancellation semantics for this version, verified with state plane dual evidence; self-reporting does not qualify for authoritative status. ② Equipment utilization rate / power decreased Not eligible when multiple instances execute concurrently; same-origin instances share a single vote. ③ Memory growth stops Not eligible within the memory stress range ④ Activity signals of non-device channels (executioner's own status view, queuing status) Queuing circumstantial evidence is only valid when all parallel processing slots are occupied, and it is based on end-to-end completion delay, without considering the first-word delay. EC Weak Evidence Client-generated stream termination A single act does not constitute a cessation of fact.

[0056] Judgment Rules: ≥1 EA or ≥1 qualified EB + 1 independent channel from different data sources confirming and continuously confirming for a preset duration ⇒ judged as stopped; evidence from the same source is not counted repeatedly; insufficient or contradictory evidence ⇒ judged as undeterminable, and conservatively handled as not stopped. If no valid stop is established, the session does not have a legitimate state transition to release.

[0057] What problem does it solve? Question 2 in §3.3. There are two key points: First, the eligibility criteria are specific, hard-to-write statements, not a higher-level expression like "determining the validity of evidence based on operating conditions"; second, the determination result directly determines the legality of the state transition, and is a permitting condition rather than a suggestive check.

[0058] Actual measured support:

[0059] Each eligibility criterion is supported by experiments in this application: concurrency disqualifies utilization (false negative 100%, 113 / 113); stress disqualifies memory-based evidence (self-reported bias 48.0%, device differential underreporting 29%, absolute level difference of 1688 MiB between two page transition phases) – see §3.1, point 3.

[0060] Queuing evidence requires that all parallel processing slots be occupied, and end-to-end completion latency, not first-term latency, must be used: This application tested the same executor on two platform profiles—when only 1 of the 4 slots was occupied, the end-to-end latency was indistinguishable from idle latency (0.4227 s vs. 0.2816–0.3320 s for idle latency); when all 4 slots were full, the end-to-end latency was 19.0891 s (approximately 65 × 10⁻⁶). The first-term latency for a request queued for 19.089 s on the same platform profile was still 0.0031 s, and the first-term latency for a request queued for 35.02 s on another platform profile was still 0.0226 s. The first-term latency in both profiles was indistinguishable from the idle state (this data is from the offline detection of cancellation capability and queuing behavior in this application, see Example 11). This should not be read as "tested once for each of the two executors," but rather as a reproduction of the same executor on two platform profiles.

[0061] "Structured non-entry release" has a direct experiment: Stop the scenario of insufficient evidence 9 / 9 All structured non-entry release, the unloading instruction count is 0, the ticket time limit is exhausted and the ticket is explicitly terminated and returned (n=9, see Example 2).

[0062] The stop evidence gate knockout arm (release before stop verification) of the ablation control experiment generates I6×5 on each of the two platform files' deterministic carriers (5 / 5), and I6×2 on the real device carrier (0 for full opening); the same document also has direct physical evidence generated in transit that was interrupted on the spot (reading interrupted, no termination mark), while the same field of the full opening control shows that the interruption was caused by the cancellation of this protocol itself and occurred after the stop verification was passed - the two forms can be separated and cannot be mixed (see Example 8).

[0063] Feature (c) Binding handover and equipment side placement finalization (two halves of the same constituent element)

[0064] This feature consists of two halves that define each other's validity boundaries: a reserved ticket only becomes a completed submission when its corresponding placement receipt is generated, and the placement receipt only has submission validity when its corresponding reserved ticket is first bound and a quota is reserved; if only one half is present, this feature is incomplete, and the session does not enter the completed submission state. The two halves are described below, and empirical evidence of this indivisible relationship is given at the end.

[0065] (c) First half: Release and binding handover

[0066] What to do: Before the release is implemented, a reserved bill bound to the benefit request is established and the corresponding quota is reserved in this scheduling domain; after the release is confirmed, the bill is updated or cashed with the actual recovered quota, and no other requests in this scheduling domain are accepted to occupy the corresponding quota during the validity period of the bill.

[0067] What problem does it solve? The first half of Question 3 in §3.3—binding the "resources to be freed up" with the "request to use them" on the books first, narrowing the interception scope. The order is binding first, then releasing: the creation of the bill and the reservation of the quota occur before the irreversible release; after the release is confirmed, only the step of "updating or redeeming with the actual recovered quota" is performed. If the reverse is true, releasing first and then binding, there is a window between the completion of the release and the effective binding, during which other requests within this scheduling domain can legally occupy the quota. The reference implementation of this application does not leave this window in its structure.

[0068] Scope of application for the effect description: The validity of the negotiable instrument is limited to this scheduling domain. Interception across control entities (self-loading by the executor, loading by a third party) of negotiable instruments is uncontrollable—this instruction manual accurately records this point, which is discovered through a preliminary reconciliation before handover and included in the preemption inefficiency categorization. This instruction manual does not make assertions such as "the recovered amount is necessarily obtained by the stated beneficiary request."

[0069] Actual test results show that after release, the third-party interception scenario was detected during the pre-handover reconciliation and transferred to partial release / explicit termination, and the preemption was recorded as invalid (n=9, see Example 6); in the effect comparison experiment, the total number of invalid preemptions for the three groups following the protocol path in the three rounds was 0, and all tickets were cashed (see Example 12).

[0070] (c) The latter half: Equipment side placement finale

[0071] What to do: The session will be marked as completed only when the benefit request actually obtains resources on the target device and a device-side placement receipt is generated; if the receipt is not generated, the session will be terminated by partial release, expiration or termination, the credit limit will be explicitly returned or downgraded and re-evaluated, and no completion processing will be performed.

[0072] What problem is being solved: The latter half of Question 3 in §3.3. Releasing video memory is not the end goal.

[0073] Conditions for forming a placement confirmation receipt: The receipt is an acknowledgment record written into the session ledger by the scheduling system. Forming this receipt requires at least one device-side observation that directly characterizes the resource acquisition status of the target device; executor status views, inference latency, etc., are only used for auxiliary confirmation, unless the status view itself explicitly states the actual placement of the target device.

[0074] Necessary main routes (equipment-side observation, at least one):

[0075] For example, after the beneficiary instance is loaded, the difference between the amount used on the target device side and the expected number of times the instance is used is compared (actual measurement in this application: loading footprint 3866 MiB, device usage increased from 2 MiB to 3868 MiB, ratio 1.00).

[0076] For example, retrieve the computing process view of the target device to verify that the process hosting the benefiting instance already holds a corresponding amount of resources on the device;

[0077] For example, use any other available device side-view measurement provided by the operating environment that can directly characterize the resource acquisition status on the target device.

[0078] Supporting confirmation (not constituting a receipt on its own):

[0079] This instance appears in the executor status view;

[0080] Its inference latency is on the order of the device side (the measured latency in this application is 390.7–537.1 ms, which is comparable to the latency when downgraded to a non-target device, see §3.2 Class 7).

[0081] Exception: When the execution-side status view itself clearly indicates the actual location of the instance on the target device (e.g., directly indicating the target device it occupies and the amount of resources on it), the view reading is treated as a device-side observation and can constitute a main path independently.

[0082] The receipt is generated and written to the session ledger if any of the above-mentioned necessary main criteria are met; auxiliary confirmation items are only used to strengthen the determination, and the receipt is not generated if the auxiliary confirmation item is met alone. The direct reason for this layering is two negative facts obtained from the experiments of this application: the executor's self-report and the state view can continue to report and remain stationary even after the instance has disappeared (§3.2 Type 3), and can also respond normally when the executor claims to be running but is actually degraded to a non-target device (§3.2 Type 7) - neither of them can characterize the resource acquisition status on the target device.

[0083] Handling of expired bills: If the session does not generate a receipt within the bill's time limit, it will expire and the amount will be explicitly returned, without being processed as completed submission; the submission conditions of this invention do not include a "timeout is considered completion" branch.

[0084] The technical basis for this constituent element is as follows: In a reservation agreement within the same control domain, the release and accounting of resources are closed within the same control domain, therefore, "confirming the counterparty's response" is sufficient to support the submission; however, on the black-box executor side, once the video memory is released, it can be obtained by any entity—Event 4 does not imply Event 5 (§2.3, actual test in this application). One approach disclosed in this field is to read back the remaining equipment capacity at fixed intervals after unloading, advance when a threshold is reached, and unconditionally release after a timeout, with the confirmation object remaining on the reclaimed side; the confirmation object of the provisional reservation agreement is the counterparty's response, which is also not the equipment on the beneficiary side. This invention places the constituent elements of the submission on the beneficiary's device. In fact, two experimental tests in this application support the necessity of this setting: First, the third-party interception scenario (n=9, all to partial release / explicit termination, see Example 6) shows that this risk is not theoretical; Second, the ablation control of the finalization gate (after turning off this necessary condition, 5 / 5 of the two platform files' deterministic carriers and 2 / 2 of the real devices generate violations of "session submitted but no finalization criterion," while the full-on control is all zero, see Example 8) shows that this condition cannot be replaced by any reading on the reclaimed side. No matter how many times the reading on the release side is sampled or how strict the threshold is set, it cannot prove that the quota has been handed over to the beneficiary requester—this point is further reinforced by the distortion test in point 3 of §3.1 (absolute level distortion does not manifest as variance, and the range of the three samples within the same phase is always 0).

[0085] Actual measured support:

[0086] In the ablation control experiment, the final gate knockout arm (release and submission) generates I2×5 ("session submitted but no landing criterion") in each of the two platform files' deterministic carriers (5 / 5), and I2×2 for the real machine carrier is 0 for all open; the final state of the all open control under the same sham successful injection is explicit termination, with I1 / I2 / I6 all zero (see Example 8).

[0087] Unloading self-report successful scenario (n=3): Self-report response 3.443 / 3.482 / 18.030 ms, the executor at the same time as the self-report still lists instance 3 / 3, the preliminary criterion and the absolute level criterion both fail (drop 0 MiB < conservative lower bound 2692.2MiB) ⇒ switch to partial release → explicit termination, ticket return, victim compensation leg node-by-node verification 100%, loss 0 (see Example 3).

[0088] Happiness path comparison (n=3, same device, only one extra-domain subject difference): After the landing is settled, the leader and level pass through, the landing criterion ratio is 1.00, the inference delay is 390.7–537.1 ms, and 3 / 3 submission is completed (see Example 1 and Example 3).

[0089] Actual measurements confirm that the two halves are inseparable.

[0090] In this application's experiment, all cases where "the ticket has been established and released, but the placement receipt has not been formed" do not proceed to submission: In the unloading self-report success scenario (n=3), partial release is performed → explicit termination and ticket return (see Example 3); in the third-party interception scenario (n=9), after detection by pre-handover reconciliation, partial release / explicit termination is also performed (see Example 6). The reverse ablation check (turning off the placement termination half, only retaining ticket binding and release) generates a violation of "session submitted but no placement criterion" on both platforms (5 / 5 for deterministic carriers and 2 / 2 for real devices), while the full-on check results in zero violations (see Example 8). That is, when only the first half is present and the second half is missing, this feature does not produce the submission completion effect in the state machine of this invention; both halves together constitute a complete submission requirement.

[0091] 3.7 Positioning of Subordinate Technical Solutions

[0092] Checkpoint Freezing and Compensation (Claim 2): Resolves Question 4 of §3.3. Practical support is shown in Examples 8 and 12 (repeated outgoing 0 vs. 100, three rounds of 300 / 300). The "fixing before cancellation" order constraint of this feature is further confirmed by the implementation layer: structurally, this protocol binds "cancellation before execution call" after checkpoint freezing. If freezing is not performed literally, cancellation cannot be sent at all—to construct a control group without checkpoints, the experimental driving layer can only invalidate the checkpoint persistence while retaining the freezing action itself. That is, "fixing before release" in this protocol is not an optional sequence, but a structural constraint.

[0093] Avatar Disqualification Rules (Claim 3): The three sources of avatar changes and "re-establishing eligibility through sub-actions" are written in accordance with the following: the condition that the avatar consistency determination is used as the migration edge for each of the two execution calls and unloading / releasing is cancelled; loading is not allowed if the quota has been occupied by an entity outside the scheduling domain after reconciliation before handover.

[0094] Release confirmation ladder (claim 4): Preliminary criterion → Absolute level criterion (with eligibility conditions) → Final result based on placement confirmation.

[0095] The leading criterion is the earlier of two sources: either the instance disappears from the executor's state view, or the process on the executor side carrying the instance disappears from the device's computed process view. The reason for choosing two sources is a negative fact observed in actual testing: the executor's model list interface reports the model's presence within ≥60 seconds (357–360 polls) in the instance crash direction, and single-source reconciliation will inevitably miss in this direction (see Example 10). The unidirectional implication between the two is taken—"process complete ⇒ instance absent"—only used to determine absence; the reverse is not true (the process still existing does not imply the instance still existing). The cost of this approach is recorded as follows: each subsequent retrieval of the executor's view involves an additional process list pass, approximately 0.6 seconds, which has been cached with a 0.4-second lifespan.

[0096] Eligibility criteria for absolute level criteria: Only valid within the non-pressure zone (non-saturation zone) and the same phase of the page change history; two absolute level readings before and after release must fall within the same phase to be subtracted, and two readings across phases cannot be subtracted or used as release criteria.

[0097] This qualification requirement cannot be replaced by "taking multiple stable values": In actual testing, the same resident set showed values ​​of 18371 / 20059 MiB at two stable levels, a difference of 1688 MiB (7.5% of card capacity). Furthermore, the range of three samples within the same phase was consistently 0 (a total of nine samples across three groups, zero discreteness) – distortion does not manifest as variance, but rather as level jumps dependent on page history. Repeated sampling cannot detect this distortion on this platform. Therefore, repeated sampling of the memory is only for auditing purposes and not for gate operation.

[0098] Unloading method eligibility determination (claim 5): Eligibility is determined for each target process individually, not for the entire executor. Practical support: On the same executor, the guardian root process is deemed ineligible (an instance outside the release set exists within the process), while child processes during model runtime are deemed eligible (see Example 5) – this rule has discriminative power and does not universally reject any executor. The data selection for each of the three parallel eligibility conditions in this rule is explained in the isolation description of Example 5.

[0099] Outgoing atomicity (claim 6): Published at the node level; if cancellation occurs, the node that has not yet completed its outgoing content has no content. This configuration is supported by actual testing in this application (publishing gating, see §3.10 Bearing Condition C4(a)); the outgoing atomicity under per-token direct deployment is described as an optional implementation in Examples 9-5, without specific experiments.

[0100] Method for determining parameters (claim 7): see §3.8.

[0101] 3.8 Parameter Determination Method

[0102] Parameters involving time thresholds and retry counts can be determined based on the actual delay of the corresponding control action, the observation channel update cycle, or the service time limit; for parameters that have not been numerically calibrated, this specification does not limit their numerical range. Resource margin parameters are obtained in this invention by any available resource estimation method and are not included in the determination methods in this section.

[0103] This manual provides two practical examples of this statement:

[0104] 1. Determined based on the actual delay of the corresponding control action: An unload command is issued to an idle instance of a certain executor. The measured control surface response is 4.8 ms, the device level returns to its position in 0.135 s, and the instance self-view disappears in 0.266 s. Based on this, the release and settling wait value for this carrier is taken as 0.5 s (= 1.88 times the measured upper limit). 2. Determined based on the observation channel update cycle: In the ablation control experiment, one instance was invalidated because the freshness threshold was set to 0.2 s—this value is less than the time taken for a single reconciliation. Therefore, the aging gate consistently fails to pass, and the session cannot proceed. From this, the measured lower limit of this threshold is derived: the preset freshness must be greater than the actual time taken for the carrier's previous reconciliation; otherwise, the gate will never be satisfied in practice. Therefore, this parameter for this carrier is changed to 2.0 s. This example is a direct implementation of "determined based on the observation channel update cycle": the lower limit of the threshold is determined by the data acquisition time of the observation channel itself, rather than by empirical values.

[0105] Both of the above values ​​are derived from actual measurements on this carrier and are not intended to limit the range of values.

[0106] 3.9 Organization of cancellation measures (details of implementation of characteristic (b))

[0107] The cancellation methods are organized in an upgrade chain in the order of "methods that do not disrupt the production channel": explicit interface cancellation → task handle cancellation → connection termination (finally, and only when offline detection confirms that the executor is disconnected). The availability of the first two levels varies depending on the executor: on the carrier of this application's experiment, only the third level (connection termination) is available; the first two levels were not obtained on this test file (see Example 11); therefore, this upgrade chain is implemented according to the evidence matrix for each executor and the choice of one method. If a certain level is unavailable, it directly proceeds to the next level, and each level is not considered a necessary technical feature. After each level is implemented, a stop verification is performed, but no further upgrades are made. After the upgrade chain is exhausted, a downgrade path is entered, and its branches depend on whether the production channel is still intact:

[0108] Channel preservation degradation: If the production channel is not destroyed, continue to wait for the current node to reach the boundary naturally. Its output is then added to the checkpoint after verification (the checkpoint number is incremented).

[0109] Emptying downgrade: When the production channel is broken (connection termination has been implemented), it only waits for resources to be released, the current node's output cannot be collected, and the frontier remains at the frozen point.

[0110] The carrying conditions are clearly stated: Executors with only one cancellation method, "connection termination," do not have channel preservation degradation. The three executors tested in this application fall into this category in this test file (see Example 11).

[0111] Capability cancellation detection: Executed offline in a controlled, unloaded environment, using dual-evidence from the state plane; results are cached and expired according to (executor, version, platform, stress level, concurrency level); conclusions not verified in a certain level are treated with the most conservative approach. Detection and online verification do not share the same observation to eliminate circular dependencies.

[0112] 3.10 Load-bearing conditions (applicable premises)

[0113] The four items in this section are applicable prerequisites for the implementation of this invention.

[0114] C1 Node Integrity: The task flow uses nodes as the smallest unit that can be fixed and published.

[0115] C2 Level 3 Contract Verification and Transitivity Fallback: Node output contract / edge fragment contract / combined input contract after all predecessors are complete; transitivity fallback based on dependency-closed cooperation when verification fails. This item is a component of the compensation path in this invention. Its effectiveness has positive samples in the experiments of this application: in the effect control experiment of 1500 pieces, the only data that failed was due to the real flow being truncated by the execution side due to this verification (see Example 11).

[0116] C3 can be started without a device: The victim task does not depend on any residual device state when it resumes from the checkpoint.

[0117] C4 Outbound Atomicity (Two Branches): (a) Publish Gated (Default) – The node's content is only published after it has been completed and verified. If cancelled, the incomplete node will inevitably have no published content; (b) Token-by-Token Direct Deployment (Optional Implementation, see Example 9-5). Deployment where neither branch is feasible is not within the carrying conditions.

[0118] 3.11 Concurrency and Persistence (Engineering Prerequisites)

[0119] Concurrency within the scheduling system is handled using conventional methods: each instance session is serialized (an execution instance belongs to at most one ongoing session at any given time); lease granting and admission are performed using the same atomic ledger write; the session table contains the owner identifier, owner lease term, and ownership generation number; takeover requires the owner lease term to expire and the ownership generation number to be incremented; all ledger writes carry the ownership generation number and are performed by comparison and exchange, with older generations being rejected. The "ownership generation number" specifically refers to the generation of session ownership and is unrelated to the instantiation identifier; the two should not be used interchangeably.

[0120] The residual risk is recorded as follows: the inability to reject unload and cancel calls issued by the executor by ownership generation number is mitigated by mandatory pre-takeover reconciliation and idempotency determination of actions (re-verification of instance existence and lease count before unload). This specification does not claim that the residual risk has been eliminated.

[0121] 3.12 System Composition

[0122] The core module mirrors claim 1 in each step: Qualification Authorizer (step (a): obtain the residency facts of the current avatar, determine the freshness and consistency with the avatar, and open / close the migration edge of the corresponding irreversible action), Stop Verifier (step (b): evidence collection, classification, qualification determination, and the determination result as the permission condition for releasing migration), Handover Binding Device and Placement Confirmer (both jointly execute step (c): the former is responsible for binding and exclusivity of the recovery quota and the reserved ticket for the benefit request, and the latter is responsible for receiving the placement receipt on the benefit request device side and determining the session final state; since the two halves of step (c) constitute the same submission requirement, the outputs of both must be satisfied together to produce the final state of "submission completed").

[0123] Supporting modules: Session ledger and pre-write log, reconciliation tool, cancel upgrade chain executor, uninstallation method eligibility determiner, checkpoint solidification and recovery tool, and release water level manager.

[0124] 3.13 Beneficial Effects

[0125] 1. The sequence of irreversible actions eliminates the conditions for a true failure: the condition for a false unloading success is "unloading a busy instance," while the error-free unloading invariant of this invention prohibits this at the means selection layer ⇒ the failure is structurally unreachable within the protocol (see Example 3). This effect and "criteria interception" are two parallel effects, supported by three sets of data respectively, and cannot be combined. 2. The eligibility of the unloading means is determined one by one according to the target process, thus having discriminative power: the guardian root process on the same executor is deemed unqualified, while the child process during model runtime is deemed qualified (see Example 5). 3. The convergence point of crash recovery is determined by the protocol sequence, not by platform coincidence: each of the five crash state points converges to a specific final state, and whether the executor survives after the crash is point-by-point identical on both platform files (see Example 4). 4. The three gates cannot be substituted for each other: each gate is knocked out with errors, and the error types are different; all three are open for comparison with zero violations (see Example 8). 5. Reduced waiting time for high-priority requests and preservation of completed work for affected tasks: In the effect comparison experiment of this application, the end-to-end latency P50 of high-priority requests in the full group of this invention is 6.276 s, and 12.174 s in the non-preemption group; the P50 of affected task work degradation is 7.699 s in this invention, and 11.589 s for kill and recalculation; the number of duplicate outgoing nodes is always 0 / 100 in this invention, and 100 / 100 in both the kill and recalculation and only cancellation without checkpoints groups. The caliber limitations, applicable boundaries and adverse conclusions of the above values ​​are described in Example Twelve, and no assumptions are made beyond this test configuration. Attached Figure Description

[0126] Figure 1. Two-level state machine of session and victim slot: the aggregation relationship between slot sub-state (selected → frozen → waiting / cancelling → stopped → released, any point can cause slot failure) and session state (initial → ready → release verification → handover → submission completed / partial release / expired / aborted), and the revocable pre-gate of each irreversible action.

[0127] Figure 2. Schematic diagram of aging threshold and irreversible action eligibility migration: This diagram illustrates the opening and closing relationship between the state migration edges of factual eligibility and irreversible actions—"Fact valid ⇒ corresponding irreversible action migration edge open; Fact loses freshness or its bound incarnation changes or the operating conditions affecting eligibility change ⇒ this edge closes; Re-verification / reconciliation / pre-handover review for the current incarnation ⇒ this edge reopens." This diagram illustrates the opening and closing of migration edges. The four columns from left to right represent the state of the same edge under different eligibility conditions, and do not represent a cyclical process.

[0128] Figure 3. Cessation of evidence classification and eligibility determination: EA / EB / EC three-level evidence sources, their respective eligibility clauses (pressure interval disqualifies memory-type evidence, concurrency disqualifies utilization evidence, queued circumstantial evidence requires parallel processing slots to be occupied and end-to-end completion delay as the criterion, client flow termination alone is insufficient), same-source no duplicate vote counting, and "undeterminable ⇒ structural non-entry release" sealing edge.

[0129] Figure 4. Handover and placement final sequence: Release implementation → Release confirmation ladder (leading criteria → absolute level criteria [with eligibility conditions]) → Light reconciliation before handover → Bill redemption → Beneficiary request loading → Equipment side placement receipt → Submission completion; and each failure edge (partial release / expiration / explicit return of quota or downgrade re-judgment).

[0130] Figure 5 shows the revocable pre-gates for each irreversible action: the revocable pre-gates and post-confirmations for each of the four irreversible actions of execution call, unloading / release, allowing loading (handover), and external content publication are executed step by step as shown in Figure 1.

[0131] Figure 6 Failed Outbound Edges: The triggering conditions, session destinations, and accounting treatments when no device-side placement receipt is generated are shown in Figure 4 as an expansion of each failed outbound edge.

[0132] Figure labeling: 500 Scheduling System | 510 Qualification Authorizer | 520 Stop Verifier | 530 Handover Binder | 540 Placement Confirmer | 550 Session Ledger and Pre-Write Log | 560 Reconciler | 570 Cancel Upgrade Chain Executor | 580 Unload Method Qualification Judge | 590 Checkpoint Fixing and Restoration Unit | 600 Black Box Inference Executor | 610 Model Execution Instance | 620 Target Device | 700 Benefit Request | 710 Reserved Ticket | 720 Placement Receipt | 800 Victim Task | 810 Node | 820 Checkpoint. Detailed Implementation

[0133] Numerical Property Declaration: The data in each embodiment of this chapter are derived from the experiments conducted by this application itself, and do not reference any prior applications or third-party experimental data. Every numerical value appearing in this chapter is labeled with its property—measured values ​​refer to the actual measurement results of the experiments conducted by this application itself; constructed values ​​refer to values ​​artificially set by the experimental driving layer to construct controls or inject faults. Neither type of numerical value is written as a limitation on its numerical range.

[0134] Experimental environment: First platform configuration = RTX 2080 Ti 22 GB (WDDM) / NVIDIA driver 610.47 / Python 3.10.11; Second platform configuration = Ubuntu 26.04 LTS / kernel 7.0.0-28-generic / NVIDIA driver 580.173.02 / Python 3.14.4 / same RTX 2080 Ti 22528 MiB (with another graphics card on the same machine). The carriers included three real inference execution machines and one deterministic carrier capable of scriptable fault injection. The specific products and versions mentioned above are merely the specific carriers used in the experiments of this application and do not constitute a limitation on the scope of this invention.

[0135] Reproduction Notes: The second platform environment with dual cards must simultaneously pin the device UUID and the visible device variable; otherwise, the executing process may be enumerated to a non-target card and fail to start (this application's experiment encountered the same root cause twice).

[0136] Example 1 (Happiness Path): Full-chain submission completed

[0137] Once a benefit request arrives and is confirmed to require recovery, the session progresses through nine states: Initial → Prepared → Frozen → Cancelling → Stopped → Releasing → Release Verification → Handover → Submission Completed; the final state of the ticket is Cashed, the victim task recovery verification is successful, and the number of lost nodes is 0.

[0138] First platform files: 2 llama.cpp carriers and 3 Ollam carriers, all submitted successfully with 0 invariant violations (tested value).

[0139] Second platform file rerun: 3 items in llama.cpp and 3 items in Ollama, all six items were processed to complete nine states, and all invoices were honored (actual values). The physical evidence of the actual placement of the beneficiary request is the dual evidence of equipment level difference and the executor's self-report: loading footprint 3866MiB (equipment used 2 → 3868 MiB), within view, and placed on the target equipment; protocol timeout llama.cpp 6.014 / 6.083 / 6.208 s, Ollama 9.701 / 9.611 / 10.015 s (actual values).

[0140] Example 2 (Insufficient Evidence to Stop): Structural Non-Entry Release

[0141] Deducting the evidence of cessation prevents the cessation verification from forming a valid fact. All 9 structured events do not enter the release: the unloading instruction count is 0, the session loops within the cancellation upgrade chain and downgrade path until the ticket time limit is exhausted, then it is explicitly terminated, and the credit limit is returned (actual value, n=9).

[0142] This embodiment is a direct manifestation of feature (b)'s last sentence, "There is no legal state transition to release when a qualified stopping fact has not been formed": it did not go to release and then back, but rather there was no such edge at all.

[0143] Example 3 (Successful Unloading): Criterion Interception + Anti-Protocol Comparison + Order Elimination

[0144] This example consists of three sets of data, each answering one question:

[0145] 1. Can the criteria be blocked (n=3, session file): Unload self-report response 200 / 3.443 · 3.482 · 18.030 ms, the executor still lists the instance 3 / 3 at the same time as the self-report; the leading criterion fails (the view is still there and the process on the executor side carrying the instance is alive - neither source indicates absence), the absolute level criterion fails (drop 0 MiB < conservative lower bound 2692.2 MiB) ⇒ partial release → explicit termination, ticket return; victim compensation leg is normal, node-by-node verification 100%, loss 0 (measured value). The method of deriving the conservative lower bound: based on the expected resident amount of the instance to be released, subtract the amount of retention that the executor usually does not fall back after release, multiply by a conservative coefficient less than 1, and round to obtain the lower bound value of the carrier; this coefficient and the amount of retention are both obtained on this carrier according to the parameter determination method described in §3.8. 2692.2 MiB is a measured derived value of this carrier and is not intended to limit the numerical range; the specific value of this lower bound depends on the carrier and is not limited in this specification. The form adopted in this invention is: the absolute level criterion can only be used when its eligibility conditions are met, and it is not considered the final release confirmation. 2. Is the blocked device a real fault (n=3, reverse protocol comparison, intentionally not going through the session, only measuring the criterion): self-reported response 16.9–22.3 ms, while the generation continues to run, and the device is still occupied for 17.8 / 20.2 / 21.6 s, and the three "if submitted according to self-report" judgments are all no (measured value). 3. Can the protocol sequence itself eliminate the conditions for the occurrence of the fault: the same command is issued to the idle instance, and the executor releases the device within 0.135 s (measured value). The condition for this false success is "unloading the busy instance", but the invariant of this invention prohibits this practice at the means selection layer ⇒ the failure is structurally unreachable within the protocol.

[0146] ⇒ The sequence of actions in this invention eliminates a type of true fault based on its occurrence conditions. This effect is parallel to "criteria interception" and cannot be stated together.

[0147] Example 4 (Collapse Recovery): Each of the five state points converges to a valid final state.

[0148] The scheduling process is hard-killed at each of the five state points: ready, frozen, canceled, released, and handover. After restarting, convergence is achieved by writing the pre-log and forcing reconciliation. preparation (null) Abort (with zero irreversible cost) yes freeze (null) abort yes Cancellation in progress (null) abort yes Releasing Cancel Intent ×3 Overdue (credit limit explicitly repaid) yes During the handover Cancel Intent ×3 + Uninstall Intent Expired no

[0149] All five instance markers were cleared after the ledger was rebuilt, suspended leases were revived, all notes were returned, and the aging threshold was 0 (measured value). Session ownership generations incremented from 1 to 2 for each item, meaning the comparison and exchange took effect.

[0150] Cross-platform consistency: The five rows in the table above are identical point-by-point in both the first and second platform versions—not only are the final state distributions the same, but each state point also converges to the same final state, and whether the executor survives after a crash is identical in both versions (actual measured values). The co-occurrence of "the executor will inevitably not survive after a crash during handover" in both versions is determined by the protocol order (the uninstallation intention had already been written to the pre-log and sent before this point), and is not a platform coincidence.

[0151] The most challenging aspect (item 5): Before the uninstallation intent is written, the logs and instances disappear, and the restorer cannot obtain the avatar (determined as unavailable) ⇒ No release is authorized, converges to expiration, and the ticket is returned. This is the performance of the avatar gate in the "unavailable evidence" direction, which complements the performance of the avatar gate knockout arm in the ablation control experiment in the "inconsistent evidence" direction.

[0152] Example 5 (Multi-model co-process): The eligibility of unloading methods is determined one by one according to the target process.

[0153] Two models (4098 MiB + 13623 MiB, measured values) reside simultaneously within the daemon process, but the release set contains only one of them. The same eligibility rule yields different conclusions for the two targets: Guardian root process Both models are in Unqualified: A model execution instance outside the release set exists in the process memory. The model has its own runtime subprocess. Only release the model within the set Eligible: All instances within the target process belong to the allowed release set.

[0154] The session then switched to a model-level unloading method to complete the release and submission; each item was verified without joint liability – the other model remained active throughout, its lease was active, and the task holding it was not suspended (actual value, n=2).

[0155] The isolation settings and load conditions for this data retrieval are recorded accurately:

[0156] 1. This data retrieval isolates the "attribution of instances within the target process" branch, setting the "protected instance" condition to null—meaning this dual-target table directly supports the first of three parallel eligibility conditions (all execution instances within the target process belong to the allowed release set), rather than a combination of the three. 2. The victim task is intentionally placed in a node gap (zero cancellation cost): This carrier leaves only one channel for evidence of utilization rate that fails to meet concurrency conditions and is reconcilable, allowing for dual-instance residency. If it is placed in an in-transit call, the structural verification is stopped and deemed undecidable; this situation is covered by Implementation Example 2 (structural processes do not enter release, n=9). Therefore, the "no in-transit call" branch cannot be directly retrieved on this carrier. 3. The statement "no other active leases exist" is indirectly supported in this example: the item-by-item verification above, "the other model is fully resident, its lease remains active, and the task holding it is not suspended," is a direct observation of "the target process cannot be released if there are other active leases in its memory"—in this example, the active lease is one of the reasons why the guardian root process is deemed ineligible.

[0157] ⇒ This rule has discriminative power. Therefore, this invention describes the qualification as a judgment on the target process, rather than a judgment on the executor as a whole. Of the three branches mentioned above, the first branch has direct empirical testing, the third branch has indirect support, and the second branch is structurally impossible to obtain data on this carrier. This specification records these facts as they are and does not make a statement that all three branches have been empirically tested.

[0158] Example 6 (Partial Release Destination): Benefit Loading Failure and Third-Party Interception

[0159] Third-party interception after release: Light reconciliation before handover detects new resident set ⇒ Transfer to partial release / explicit termination and record preemption invalid (deterministic carrier n=9, all explicit termination, violation 0, measured value).

[0160] Benefit request loading failed: partial release ⇒ downgrade and re-judgment based on actual available amount or explicit termination, credit limit explicitly returned (deterministic carrier n=9, all explicit termination, 0 violations, actual value).

[0161] Example 7 (Checkpoint Failure After Session Abort): Restore to only take the latest valid snapshot

[0162] After the session is terminated, the victim task continues to execute and is then triggered to restore: the restoration shall always take the latest valid snapshot of the task; the replaced snapshot shall not be used as the restoration basis (deterministic carrier n=9, all terminated, 0 violations, measured value).

[0163] Example 8 (Ablation Control): The three gates are not three unrelated conventional safety measures.

[0164] Criterion (two-way): After a door is knocked down, its characteristic error must appear (positive), and after it is fully opened, it must not appear under the same injection (negative). Only when both criteria are met is the arm considered to have passed. A. Evidence eligibility / Age of accounts receivable Old and alienated evidence is authorized as usual. I1 > 0 and I4 > 0 I1×5 + I4×25 = 0 for all open —(Exclusive to deterministic carriers) A′ Incarnation Gate Only the avatar verification is checked; the account age gate is refreshed as usual. I1 > 0 and I4 = 0 I1×5 for all open 0 I1×2 for all open 0 B. Stop Evidence Gate Release without proof of cessation I6 > 0 I6×5 to all open 0 I6×2 for all open 0 C position at the endgame gate Release is submission I2 > 0 I2×5 to all open 0 I2×2 for all open 0

[0165] (All values ​​above are actual measurements. The second platform file has a total of 47 items, 51 violations, and 5 invalidations in this batch; the final state distribution of deterministic carriers and the decomposition of invariant violations are the same in each frame of both platform files, indicating that the ablation effect comes from the opening and closing of the gates and is unrelated to the operating system, runtime version, or driver.)

[0166] Explanation of table header format: The "Real Device Carrier" column in the table above represents the data for the second platform (n=2). The real device carrier data for the first platform is incomplete: there is only one positive real device for the C-arm (positioning final gate) in this platform, and the entire negative control is missing. The bidirectional criterion for the C-arm real device is closed on the second platform (see conclusion 3 below). This manual does not read this column as 2 / 2 for both platform platforms.

[0167] Three conclusions:

[0168] 1. Each arm knocks out only its own type of invariant—A′ only I1, B only I6, and C only I2, with no crosstalk between the three types; all three open checks result in zero violations. If the three gates are interchangeable, knocking out any gate should be blocked by the other two without generating a violation; in practice, knocking out each gate results in errors for each gate, and the error types are different. 2. A and A′ must be stated separately: A bypasses the aging gate and avatar verification together, with the signature being I1 + I4 (old evidence is allowed); A′ only disables avatar verification, while the aging gate is refreshed as usual, with the signature being only I1 and I4 consistently 0. "Refreshing once before the action" cannot prevent avatar drift; the deterministic carriers of the two platform files each reproduce 5 / 5. When citing this batch of data for argumentation, arm A must simultaneously raise I1 and I4; otherwise, A and A′ are indistinguishable in the text. 3. The negative control of the C arm has been closed: Under the same unloading sham success injection, the release confirmation interception self-reported success, the final state is explicit termination, and all three types of invariants are zero - which constitutes a complete control with the "commit complete + I2 violation" of the knockout file (actual value).

[0169] Example 9 (Optional implementation method; no specific experiments were conducted, the description is based on the functional description, and no quantitative effect is stated)

[0170] The following branches are optional embodiments of the present invention. No specific experiments have been conducted on them in this application, therefore no quantitative effects are described, nor are any definitive assertions regarding reliability made:

[0171] 1. Multiple Victims and Slot Expansion: When release is insufficient, expand to a maximum of one victim slot within the ticket's time limit according to victim priority; irreversible actions are not implemented before the new slot's freeze is completed (the gate is slot-level, not global sequence); a unique quota for the entire session, i.e., the maximum number of slots = initial selection + 1. If still insufficient, the ticket is downgraded and re-judged based on the actual available amount; released quotas are not returned to the public pool and are prioritized for the same ticket; benefit requests are satisfied through other methods or queued. 2. Reconciliation Infeasible Branch: If the list interface is unavailable / timeout / returns outdated information, and circumstantial evidence is unqualified, reconciliation is deemed infeasible—the session is terminated if no irreversible action has been taken; existing freezes remain in the current state until reconciliation is restored or the ticket's time limit expires. Continuing to proceed without an known aging is not permitted. 3. Lease semantics for long nodes: For instances with in-transit calls, their leases do not expire due to timeout (the lease semantics is "reclaimed upon holder's loss of contact," the criterion being heartbeat disconnection rather than node incompleteness); expiration-triggered reclamation also requires reconciliation before proceeding with regular reclamation, without bypassing the various gates of this invention. 4. Retry upper bound and backoff: Sessions with the same combination of (beneficial request, victim task) are subject to an upper bound on the number of retries and backoff constraints; after multiple consecutive expirations, the beneficial request is redirected. 5. Outgoing atomicity under per-token direct deployment: Publish watermark per-token persistence + cancellation point truncation + semantically continuing generation from the truncation point after recovery (no guarantee of consistency with the original generation); under this branch, "exactly once" is weakened to "non-repetition, explicit annotation at the breakpoint." Deployments where neither branch is feasible are not within the carrying conditions of this invention. 6. Quota Handling and Backoff under Partial Release Conditions: When the quota obtained from a single release is insufficient to meet the demand of a benefit request, the victim slots can be expanded within the ticket's expiration period according to the victim priority order. The total number of expanded victim slots has a unique quota throughout the entire session (i.e., the upper limit of the total number of slots = initial selection + 1). The newly expanded slots will not implement their irreversible actions before their freezing is completed (this gate is at the slot level, not the global time sequence). If it is still insufficient after expansion, the reserved tickets will be downgraded and re-judged according to the actual available amount. The released quota will not be returned to the public pool and will be prioritized for the same ticket. The benefit request will be satisfied by other methods or queued. Sessions with the same combination of (benefit request, victim task) are subject to the upper limit of the number of retries and backoff constraints. After multiple consecutive expirations, the benefit request will be rerouted.

[0172] Example 10 (Detection of Account-Based Forks and Handling of Phantom Leases)

[0173] This embodiment corresponds to categories 1 and 2 of the list in §3.2, and is the data-taking aspect of the claim of "authorization of irreversible actions by reconciliation conclusions".

[0174] (a) Self-eviction by the executor: Exceeding the limit by setting the residency cap, loading a second model triggers the executor to evict the first model (this triggering method is a constructed value: the card capacity will not naturally exceed the limit by loading two small models; exceeding the limit by setting the residency cap is a reproducible and pathologically sound approach). After triggering, the executor's residency set only contains the second model, while the ledger still holds the active lease and the belief residency is true ⇒ the phantom lease is established. The cleanest evidence is that the net increase in device level for the second loading is negative: loading a model of approximately 1.1 GB actually reduces the total device occupancy by approximately 2.75 GB (−2750 / −2752 / −2752 MiB, measured values). Detection latency (invariant caliber) is 0.658 / 0.889 / 0.779 s, detected on the first reconciliation; the phantom lease is marked as invalid, the victim task follows the compensation leg, and each node is verified 100%, with 0 missing (n=3). The second platform file was run again with n=2, and the detection (with the same invariant caliber) was 0.012 / 0.011 s (the caliber for the same batch of scenarios was 0.040 / 0.039 s).

[0175] (b) Execution instance crash: Killing the runtime child process holding video memory (identified by the device computing process list, and explicitly excluding the executor's main process) reproduces the situation where "the execution-side instance is gone but the ledger is unaware," not that the entire execution side is killed. The main process still responds after being killed, and the video memory is truly released; detection (invariant caliber) 1.495 / 0.697 / 1.686s (actual values, n=3); second platform file (same caliber) 0.528 / 0.527s (the same batch of scenarios has a caliber of 0.543 / 0.543s; n=2, four rounds of reconciliation).

[0176] (c) A negative fact and the resulting multi-source reconciliation: The first run of this item produced the only violation in the fault injection matrix batch, and it was a genuine problem—the first 3 / 3 of the time, the actual convergence violation was detected because the executor's model list interface continuously reported that the model was resident for ≥60 s (357–360 polls) in the crash direction during runtime. Therefore, actual convergence must take the "executor process liveness" path together, and take the one-way implication of "process death ⇒ instance death" (only used to detect absence). The last 3 / 3 of the time detected within 0.697–1.686 s (measured value). The cost of this approach is also recorded: thereafter, each time the executor view is retrieved, it takes one more pass of the process list (about 0.6 s, already cached with a 0.4 s lifespan).

[0177] (d) Direct reading verification of lease accounts (not dependent on event text): Direct reading of the ledger for four items in two scenarios shows that the lease before injection is converted to invalid, and a new active lease is created after the compensation leg is approved; the four items are restored and verified, and the missing items are empty. The number of interceptions of the aging gate in this block is 0 and the number of violations of the account-to-actual convergence is 0, that is, there is no "aging gate is approved but the actual aging exceeds the limit" release (measured value) in this block - which is exactly the contrast with the I4×25 characteristic signature of the A-arm knockout file in the ablation control experiment.

[0178] Example 11 (Conditions and adverse facts, as recorded)

[0179] The availability level of the cancellation upgrade chain varies depending on the deployment: the three executors tested in this application did not achieve the explicit cancellation interface and task handle cancellation levels in this test file; the actual availability level in this file is only "connection termination". This application also compared graceful termination signals and forced termination signals in one of the executors. The consequences of the two for in-transit calls are the same (both are connection reset and truncation, without termination marker), only the log traces are different; the other two did not make this comparison, so this conclusion is limited to this executor and no general statement is made for the three. Therefore, "channel preservation degradation (continue to wait for natural termination and collect output)" is not available in this file, only "emptying degradation (wait only for resources to be released, and the output of the current node cannot be collected)" (this set of conclusions is taken from the offline detection of cancellation capability in this application, and both platform files have been executed; this specification records the carrying conditions as is, and does not make any assertions on executors other than this test file based on them).

[0180] Offline detection data for queuing circumstantial evidence (cited in §3.6 Feature(b)): For the same executor on two platform profiles, when only one of the four slots is occupied, the end-to-end latency is indistinguishable from idle latency (0.4227 s vs. 0.2816–0.3320 s for idle latency). When all four slots are full, the end-to-end latency is 19.0891 s. The latency for the first word of a request queued for 19.089 s on the same platform profile is still 0.0031 s, while on another platform profile, the latency for the first word of a request queued for 35.02 s is still 0.0226 s (measured value). Therefore, queuing circumstantial evidence is only valid when all parallel processing slots are occupied, and the end-to-end completion latency, rather than the first word latency, must be used as the criterion.

[0181] The cost of stopping the verification round is recorded as follows: median total round duration llama.cpp 1310.5 ms (623.9 ms for view, 101.8 ms for running conditions, and 584.7 ms for evidence retrieval), Ollama 801.4 ms (measured value). To eliminate the defect that "conditions and evidence read the executor's state at two different moments," the two view retrievals were merged, reducing the delay from cancellation to decision from 2170.1 ms to 1260.3 / 1362.7 ms (measured value).

[0182] Reconciliation requires multiple sources: If the model list interface of a certain executor does not update for ≥60 seconds in the direction of a runtime crash, single-source reconciliation will inevitably miss it; and it is detected 0.697–1.686 seconds after process survival (actual measured value). This defect is a true violation found by the fault injection matrix itself (before the fix, 3 / 3 were judged as I4 violations), and the protocol text was written correctly before the implementation.

[0183] Contract validation blocked a positive sample that was actually truncated: The only data point out of 1500 in the effect control experiment was invalidated because of occasional flow truncation on the execution side (the node only output 20 words and the termination marker was missing), which was correctly rejected by the level 3 contract validation (measured value). This data point was counted as invalid in the sample size and was not retried or re-run.

[0184] Example 12 (Five sets of control experiments and effect data)

[0185] Calibration limitation (mandatory in this embodiment): The values ​​in this embodiment are taken from the effect control experiment, and the request form is one request = one independent preemption scenario (sequential initiation, non-concurrent, all execution parties between the components start and stop, and the device level is reset to the baseline). This caliber cannot measure the tail delay under concurrent queuing conditions. The inter-group comparison is based on round-2 (five groups of simultaneous staggered time periods); the value in parentheses is round-3, used to indicate repeatability. The victim form is a 2-node sequential directed acyclic graph (node ​​1 is a fixed length of 800 words, node 2 is 1200 words, both are constructed values), and the beneficiary request arrives 1.5 s (constructed value) after node 2 is initiated.

[0186] (a) The main table of five control groups (round-2, n=100 for each group, measured values) G1 This invention in its entirety 6.276 s 7.699 s 0 / 100 All submissions completed G2 No preemption (high priority queue will complete naturally). 12.174 s 0.0 s (no interference base) 0 / 100 Do not follow the protocol path G3 kill recalculation 2.998 s 11.589 s 1 time / item, 100 / 100 Do not follow the protocol path G4 only cancels checkpoints (comparison construction). 6.266 s 14.813 s 1 time / item, 100 / 100 All submissions completed G5 waits only, does not cancel (a branch of the protocol itself) 12.842 s −0.006 s 0 / 100 All submissions completed

[0187] G4's property declaration: G4 is a construct for checkpoint persistence failure, not the natural pattern of this protocol. Structurally, this protocol binds "cancellation before execution" after checkpoint freezing—literally, if "freezing is not performed," cancellation cannot be sent at all, and the group will not fetch data. The only way to test these two components separately is to invalidate checkpoint persistence while the freezing action still occurs (the test-driven layer overrides the checkpoint write, not writing to the ledger, leaving only one record). Therefore, all references to G4 should be read in this property and not as "the behavior of this protocol under a certain configuration." Its 100 violations are constructive, representing the data fetching itself for this group, not protocol failure. Supporting positive argument: This protocol structurally disallows cancellation without checkpoints—this is contradicted by the implementation constraints of this group.

[0188] (II) Effects of each item

[0189] 1. Waiting time for high-priority requests: 6.276 s for this invention versus 12.174 s for no preemption, 5.898 s faster, 1.94 times faster (round-3: 6.267 vs 12.131, 5.864 s faster, 1.936 times faster) (measured values). Limited scope, not for generalization: In this batch, the benefit request arrives 1.5 s after the last node of the victim task is initiated, and the waiting time for the no-preemption group is only the remaining portion of that node—this is the most advantageous configuration for the no-preemption group. The waiting time for the no-preemption group depends on the remaining workload of the victim task, while the latency of this invention is independent of the remaining workload of the victim task (only including cancellation, stop verification, release, and loading). Therefore, this difference is a lower bound, not a typical value; any multiples cited here must specify the arrival point. This batch only measured one arrival point and makes no assumptions about its variation with the remaining workload.

[0190] 2. The cost of correctness is recorded as follows: This invention takes 6.276 s compared to the 2.998 s of kill recalculation, meaning this invention takes an extra 3.278 s (round-3: 3.269 s). Decomposition (all based on P50, each item taking its own value from G1 within this group): Beneficial instance loading 2821.4 ms, release 124.3 ms, handover window 488.5 ms, the remaining approximately 2.84 s for canceling the upgrade chain and stopping verification (evidence retrieval, heterogeneous audit, aging gate, and avatar verification). Compared to the 9.9 ms handover window of kill recalculation—kill recalculation is fast because it doesn't verify anything (actual measured value). Note on the scope of this decomposition: The loading time column is of the same magnitude in the five groups of round-2 (2810.7–2821.6 ms), but the same magnitude does not mean interchangeable, therefore this decomposition always takes the 2821.4 ms of G1 itself, without taking the value of any control group. This decomposition only applies to round-2: in round-3, the column is no longer consistent across the five groups (G1 / G4 / G5 return to approximately 2630 ms), the data retrieval path has not yet been unified, and it has been listed as an item to be investigated (see item 3 of this embodiment (IV)).

[0191] 3. Deterioration of the affected task: Killing and recalculating takes 11.589 s compared to the present invention's 7.699 s (work caliber, base = no interference reference 17.763 s). The present invention deteriorates 3.89 s less and redoes 3074 fewer characters (round-3: 3.919 s / 2960 characters) (actual measured value). Both sides must be clarified: both groups lose the progress within the preempted nodes (this reference implementation does not migrate key-value caches, so progress within nodes is not guaranteed); the difference lies entirely in completed nodes—the present invention only re-executes the leading edge after recovery from the node boundary checkpoint and passing node-by-node verification, while killing and recalculating discards completed and verified nodes. In this embodiment, the difference in the affected task between the two schemes mainly corresponds to the re-execution cost of completed nodes; as the reusable amount of completed work increases, this difference may further increase. This batch only measured the prefix length, did not scan the prefix, and does not make any functional inferences. Conversely, when the cost of redoing the prefix is ​​less than the protocol overhead of this invention compared to kill recalculation (3.278 s in Clause 2), kill recalculation is not disadvantageous on the victim task side—this intersection is explained here, not just the advantageous side.

[0192] 4. "Exactly Once" Outbound: Killing recalculation and "Cancel Only Without Checkpoint" repeatedly publishes completed nodes (1 time / item), with 100 / 100 items in each of the three rounds; Invention, No Preemption, and Wait Only Without Cancellation are always 0 (actual value). The victim task is recalculated from zero ⇒ Semantic nodes that have already been published are published a second time. In workflows with external side effects, this is a duplicate side effect. The attribution has been verified separately: The high-priority sides of G4 and G1 are identical word for word (same cancellation escalation chain, same stop verification, same release and handover), the only difference is whether the victim task side has a snapshot to rely on; the result is 0 / 100 for G1 and 100 / 100 for G4 ⇒ Anti-duplicate outbound is attributed to checkpoint, not to cancellation; Cancellation itself has never prevented duplicate publication (300 / 300 in three rounds).

[0193] 5. Consistency across the five resource account groups: The actual bytes released in the five groups of round-2 are all 2970.0 MiB, with the minimum / median / maximum values ​​all being 2970.0 MiB – all five paths ultimately freed up the video memory. The difference between groups is not "whether it has been freed up yet," but rather "how it was freed up" and "whether any work was destroyed before freeing up" (actual measured values).

[0194] 6. The preemption invalidity rate is 0: there were a total of 0 times in the three rounds of the three groups following the protocol path, the final state of the session was always "submission completed", all tickets were cashed, and the high-priority service and the victim task were both fully completed (actual value).

[0195] 7. Checkpoint cost: Solidification time P50 9.8 ms; relative high-optimal path P50 approximately 0.16% (9.8 ms ÷ 6.276 s = 0.156%; round-3 is 10.0 ms ÷ 6.267 s = 0.160%); at the resolution of this experiment, no stable reduction in high-optimal latency was observed after removing checkpoints (three rounds G1 − G4 are +0.010 / +0.003 / −0.029 s, sign unstable) (measured values). This column must be read distributedly, and single values ​​are not allowed: For round-2, G1 has a minimum of 9.3 ms / P50 9.8 / P95 10.7 / a maximum of 11.5 ms; G5 was independently measured with P50 of 9.7 / a maximum of 26.8 ms; for round-3, G1 has a maximum of 51.8 ms (single outlier, retained accurately). The volume is P50 3035 bytes. This column must also be read distributedly (the term → character ratio varies with content). The checkpoint in this reference implementation is node-level output (text), not a key-value cache. Therefore, the number of bytes in this table is not comparable to the key-value cache volume, and the two should not be directly compared.

[0196] 8. The complementary roles of checkpoint restoration and timely cessation:

[0197] In this test configuration, after disabling checkpoint persistence but retaining the remaining cancellation, stop verification, release, and handover paths, the latency of high-priority requests is essentially equivalent to the full protocol, while the victimized task experiences re-execution from zero and repeated deployments. On the other hand, simply waiting for the current call to end naturally can preserve the victimized task's work, but it does not achieve the high-priority latency benefits of this configuration. These results indicate that in this embodiment, checkpoint recovery and timely stopping mechanisms have complementary effects.

[0198] The three rows of measured data supporting this statement are rows G1 / G4 / G5 in the main table (I). All of the above are observations under this test configuration, and no selection relationship is inferred from them for other configurations or carriers.

[0199] 9. Adverse conclusion recorded as fact (G5 counterexample): The design expectation was that "the high-optimal latency of the waiting-only-no-cancellation group is between that of the present invention and the no-preemption group." Actual measurements did not verify this—the latency for this group was 12.688 / 12.842 / 12.866 s over three rounds, while the latency for the no-preemption group was 11.84 / 12.174 / 12.131 s. This group consistently had higher latency than the no-preemption group, with differences of 0.848 / 0.668 / 0.735 s over three rounds, or approximately 0.67–0.85 s (measured values). The root cause lies in the carrier, not the implementation: the affected task is a 2-node directed acyclic graph, with preemption landing on the last node. Therefore, "waiting for the current node to finish naturally" and "waiting for the entire task to complete" are the same thing, with identical waiting time. After the group finishes waiting, it still needs to go through a release confirmation and handover process (handover window 488.7 ms + release 124.3 ms + placement verification), the difference of 0.668 s being the overhead of this protocol. For this expectation to hold, the carrier must have ≥3 nodes and preemption must land on a non-last node—this application has not conducted this experiment, therefore no claims are made regarding its effectiveness. Similarly, the value of "the delay benefit of cancellation relative to waiting = 6.566 s (three-round range 0.047 s)" varies with the arrival point; this batch did not scan the arrival points and therefore does not generalize.

[0200] (III) The achievement of correctness criteria (three-state criteria)

[0201] This invention uses seven measurable invariants as correctness criteria. Each criterion has a one-sentence definition (corresponding one-to-one with the implementation-side criteria): I1 Uninstalled without error There is no "irreversible release authorized by evidence of disqualification"—that is, the residency fact used to authorize this release must have the same bound avatar as the actual avatar at the time of the action, and the account age must not exceed the preset freshness. I2 handover valid When a session is set to "submission complete," a device-side placement receipt for the benefit request must have been generated; there cannot be a session that is "submitted but without placement fulfillment criteria." I3 Bounded Termination Each session reaches one of the four final states within the ticket's time limit: submission complete, partial release, expiration, or termination. There are no suspended states. I4 Accounts and physical assets convergence The residency assumptions recorded in the ledger converge with the actual implementation within the preset time limit; there is no release of "accounts aged beyond the aging threshold" or "accounts actually aging beyond the limit," nor are there any undetected phantom leases. I5 external atomicity Nodes that have been completed and published will not be published a second time; incomplete nodes will not have any published content. No data was generated after I6 stopped. Once the verification is determined to have stopped, the in-transit call will no longer generate new content. I7 Victim Mission Undamaged After the affected task resumes from the latest valid checkpoint, nodes that have been completed and passed verification will not be re-executed. Each node will pass verification, and the number of lost nodes will be 0.

[0202] Explanation of the criteria: The "0" in the violation count includes both "judged and zero violations" and "there is nothing to judge". Therefore, each invariant has three states: violation > 0 ⇒ fail; violation = 0 and the rule has a data entry surface ⇒ pass; violation = 0 and the rule has no data entry surface ⇒ cannot be judged.

[0203] Batch-by-batch three-state counting (number of judgment cells = number of valid items × 7 invariant formulas): Fault Injection Matrix (First Platform File) 96 672 564 0 108（16.1%） Four carriers, seven types of faults + two types of bifurcation self-tests Rerunning the matrix key items (second platform file) 15 105 78 0 27（25.7%） Happiness Path, Five Points of Collapse Recovery, Two Types of Bifurcation Detection Ablation control (second platform file) 47 329 298 31 0 The characteristic signature of the knockout arm is not passed; all three open controls are zero. Ablation control (Platform 1 file) 53 371 331 30 10 Same as above; the data retrieved from the actual C-arm in this document is incomplete (see the table header description in Example 8). Effect comparison (round-2) 500 3500 2000 100 1400 Five groups × 100 requests; I5 constructed without passing 100 cells is a G4 comparison construction, see (I) property declaration. Results Comparison (Full Batch) 1499 (Initiated 1500, invalidated 1) — — — — Five groups × 100 requests × 3 rounds

[0204] Four ways to read it:

[0205] 1. The full set of this invention is the only configuration where all seven invariants have data retrieval surfaces and zero violations (all 700 cells in round-2 and round-3 pass). It can be written as "All seven invariants under this invention configuration have passed and there are no violations". 2. "Violation 0" in the no-preemption group and kill-recalculation group does not endorse correctness: these two groups do not follow the protocol path and do not generate corresponding events, so six are judged as undecidable; only the outgoing atomicity is truly judged, and the semantically repeated outgoing happens to fall outside the data retrieval surface of this clause (killing recalculation means rerunning from zero with a different task instance, and the two releases belong to two different task identifiers, so judging "exactly once" by task grouping cannot be judged). Therefore, its "0" means "no event that can be judged as a violation", and should never be interpreted as "killing recalculation is also safe". 3. G4's "victim task is not damaged" is undecidable rather than passed: no checkpoint ⇒ restore baseline snapshot is empty ⇒ criterion has nothing to compare with. Under the old standard, the completed nodes were actually discarded and reworked (9181 characters were re-executed compared to 6135 characters in this invention). The invariant "0" is only meaningful when there is a data retrieval surface. 4. The "violation 0" of the fault injection matrix and the matrix key item rerun of the two batches must also be read in three states: 16.1% and 25.7% of the judgment cells in these two batches are judged as undecidable, and their "total violations 0" is not equal to "all seven are judged". There are two typical cases without a data retrieval surface - the crash recovery leg does not generate a victim task recovery comparison benchmark, and its "victim task undamaged" item has nothing to compare with; the scenario that does not involve in-transit calls does not generate a generation event, and its "no generation after stopping" item has no event to judge. This specification only records "all judged cells passed, no cell failed" for these two batches, and does not record "all seven are judged".

[0206] (iv) The applicable boundaries of the effect (not just reporting the favorable side)

[0207] 1. The values ​​in this embodiment are derived from a single independent preemption scenario and cannot measure tail latency under concurrent queuing conditions; this invention does not claim any effect in the direction of concurrent tail latency. 2. The inter-group difference in high-priority latency depends on the arrival point of the benefit request; only one arrival point was measured in this batch. The inter-group difference in the deterioration of the victim task depends on the length of the completed prefix; only one prefix length was measured in this batch. Neither is inferred in functional form, and the intersection point has been explained in Section (II) 3. 3. The group order within the round is fixed in the three rounds of this batch, and the position effect is confused with the group, which has been listed as a known limitation; the loading time of the benefit instance has an overall difference of about 200 ms between different rounds, and the data retrieval path has not yet been unified, which has been listed as an item to be investigated. The above two items do not affect any inter-group conclusions in this embodiment (the conclusion is always taken from the round where the time is intersected), but are recorded as such. 4. This reference implementation does not migrate the key-value cache, and the progress within the node cannot be guaranteed; the difference in the deterioration of the victim task in this embodiment all comes from the completed node layer. 5. The idle base value of the device under test increased from 2 MiB to 4 MiB midway through one round. The cause is undetermined and has been listed as an item to be investigated. Its impact only affects the "Release Actual Bytes" column, and has been verified item by item (the sum of the base value and the released bytes is constant, that is, the actual occupancy of the executor remains unchanged). The latency and degradation columns are not affected.

Claims

1. A method for a video memory reclamation session executed by a scheduling system independent of the inference executor, wherein the inference executor is a black-box inference executor—that does not provide an atomic completion interface that can simultaneously prove that an in-transit call has been terminated, instance resources have been released, and the benefit request has acquired the target device resources; The method is executed under the condition that the scheduling system has determined that video memory resources need to be reclaimed for a beneficial request, characterized in that... include: (a) Fact Qualification Authorization: For the execution instance involved in the candidate victim task, obtain the actual residency fact bound to its current instance incarnation. The instance incarnation is composed of an instance key and the process identifier of the execution side carrying the instance. Only when the fact satisfies the preset freshness and its bound incarnation is consistent with the current incarnation, the irreversible recycling action authorized by the fact is opened for the instance. When the fact loses freshness, or the incarnation changes, or the operating conditions affecting the qualification of the fact change, the state transition edge of the irreversible action is closed, and the edge is reopened only after obtaining the new fact for the current instance incarnation. (b) Stop Evidence Gate: For victimized instances with in-transit calls, after cancellation measures are implemented, the in-transit call is confirmed to have stopped according to evidence classification and eligibility determination, wherein: call-level termination facts from the executor's state plane are authoritative; device memory-related evidence is not eligible within the memory pressure range; device utilization-related evidence is not eligible when multiple instances are executed concurrently; queuing circumstantial evidence is only eligible when all parallel processing slots are occupied and is determined by end-to-end completion delay; client flow termination alone does not constitute a stop fact; and is determined according to the following rules: if confirmed by at least one of the aforementioned authoritative facts, or by at least one eligible circumstantial evidence and an independent channel from another different data source for a continuously preset confirmation duration, it is determined to have stopped; evidence from the same data source is not counted repeatedly; if the evidence is insufficient or contradictory, it is determined to be undeterminable and processed as not stopped; if a qualified stop fact is not formed, the session does not have a legitimate state transition to release; (c) Binding Handover and Equipment-Side Placement Finalization: Before the release, a reserved ticket bound to the benefit request is established and a corresponding quota is reserved in this scheduling domain; after the release is confirmed, the ticket is updated or cashed with the actual recovered quota, and no other requests in this scheduling domain are accepted for the corresponding quota during the ticket's validity period; furthermore, the session is only marked as completed when the benefit request actually obtains resources on the target equipment and forms an equipment-side placement receipt, and the placement receipt is a confirmation made by the scheduling system based on equipment-side observation measurements and serves as a confirmation. A record is written to the session ledger; if the receipt is not generated, the session is terminated by partial release, expiration, or suspension, and the credit limit is explicitly returned or downgraded for reassessment, without submission completion processing; wherein, the binding of the reserved bill and the formation of the placement receipt constitute two halves of the same submission requirement, and the absence of either will result in no submission completion - if the bill is only established and cashed without generating the receipt, it does not constitute the completion of this step; if the bill is released directly without first establishing and retaining it, the receipt generated thereafter also does not constitute the completion of this step.

2. The method according to claim 1, characterized in that, Before cancellation, the output of the completed nodes of the affected task is solidified into checkpoints with monotonically increasing sequence numbers and session identifiers and persisted. If the session is not committed to completion, the affected task is resumed from the latest valid checkpoint. Completed and published nodes are not re-executed or republished.

3. The method according to claim 1, characterized in that, The changes in the avatar include execution instance reconstruction, execution process crash restart, and silent reconstruction triggered by request parameters; in the irreversible recycling action, the condition for opening the state transition edge of each of the execution call and unloading / release steps is cancelled, based on the consistency judgment of the avatar; loading is not allowed if the quota is found to be occupied by a subject outside this scheduling domain before the handover is checked by reconciliation.

4. The method according to claim 1, characterized in that, Release confirmation includes a leading criterion and an absolute level criterion for device usage. The leading criterion is either the disappearance of the instance from the executor's status view or the disappearance of the executor-side process carrying the instance from the device's calculation process view, whichever comes first. The disappearance of the process and the absence of the instance are unidirectionally implied and are only used to determine absence. The absolute level criterion is only eligible in non-pressure intervals and within the same page transition phase. The two absolute level readings before and after release must fall within the same page transition phase to be subtracted. Release confirmation does not end with the device reading but with the placement receipt mentioned in step (c) of claim 1.

5. The method according to claim 1, characterized in that, When process termination is used as a release method, it is only eligible if all execution instances within the target process belong to the set of allowed releases and there are no other active leases, in-transit calls, or protected instances; the eligibility is determined one by one for each target process.

6. The method according to claim 1, characterized in that, Externally visible effects are published at the node level; when cancellation occurs, the unfinished node has no published content.

7. The method according to claim 1, characterized in that, The parameters involving time thresholds and the number of retries are determined based on the actual delay of the corresponding control action, the update cycle of the observation channel, or the service time limit.

8. A video memory reclamation session system, characterized in that, It includes a qualification authenticator, a stop verifier, a handover binding device, and a placement confirmation device; the qualification authenticator is configured to perform step (a) of the method of claim 1, the stop verifier is configured to perform step (b) of the method of claim 1, and the handover binding device and the placement confirmation device are jointly configured to perform step (c) of the method of claim 1.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method of any one of claims 1 to 7.

Images