A method for unified management and migration adaptation of Xinchuang and heterogeneous computing resources

Abstract

The application discloses a method for unified management and migration adaptation of Xinchuang and heterogeneous computing resources. Source and target resources are uniformly managed by versioning capability records, and a portability contract is formed by static analysis and running tracking of the migrated workloads. The system divides the state according to files, CPU process memory, accelerator tensor, device queue and external session, and respectively adopts direct copy, format conversion, reconstruction or blocking strategy; the source format snapshot and the target recovery formula jointly constitute a traceable checkpoint. The target shadow instance is restored in the isolation domain and passes through the partition probe, and the entry controller completes the single-write switching by using the monotonic migration period and the barrier token. When the observation period occurs out-of-bound, the system only reverts after the reverse increment and external side effect are closed, otherwise the isolation is maintained.

Description

Technical Field

[0001] This invention relates to the field of unified modeling, workload migration, and switching verification technology for domestically developed and heterogeneous computing resources, specifically to a unified management and migration adaptation method for domestically developed and heterogeneous computing resources. Background Technology

[0002] The domestically developed computing environment and the existing computing power environment may use different instruction sets, operating system kernels, drivers, accelerator runtimes, and device management interfaces. Simply mapping the number of CPUs, memory, and accelerator cards to a unified resource cannot reflect the differences in system calls, ABIs, operators, and checkpoint formats.

[0003] Traditional migrations typically involve selecting a target first and then addressing compatibility issues. The runtime state, device memory, and external dependencies are all mixed in the same image, making it difficult to determine which states can be directly transferred, which need to be converted, and whether a rollback is possible in case of failure.

[0004] Common heterogeneous computing power management and migration solutions migrate workloads through unified labels, container images, or general checkpoints. They do not distinguish between runtime states that can be directly copied, require semantic conversion, require target reconstruction, and are not migratable. This can easily result in instances that appear to be started but are semantically inequivalent at the target end.

[0005] The source-side binary, runtime calls, and device state are not isomorphic to the target-side instruction set, system calls, and accelerator interfaces. Migrating solely in image format or virtual machine state will mix directly copyable data with states that must be converted, rebuilt, or blocked in the same recovery path, potentially resulting in double writes during entry point switching.

[0006] This invention binds resource capability versions, workload contracts, and state partitions, preserving source format snapshots and target recovery bases for different states. Shadow recovery, incremental closure, entry-stage barriers, and reverse incremental changes jointly define migration commit and rollback boundaries, preventing uncertain external states from being forcibly switched.

[0007] Before migration, the workload state is divided into convertible state, rebuildable state, and platform-inherent state. The target capability graph is used to bind the missing capabilities to verifiable alternative paths. Dual-format checkpoints simultaneously retain both the platform-neutral representation and the source platform recovery representation; if the target-side shadow recovery fails the state equivalence check, the source side can still continue running from the same checkpoint. Summary of the Invention

[0008] This invention addresses the problem of differences in instruction sets, runtime, and device state semantics between domestic IT innovation platforms and heterogeneous computing power, and solves how to classify and convert workload states, how to verify target recovery, and how to switch or roll back entry points without interrupting state consistency.

[0009] To address the migration boundary between domestically developed computing resources and heterogeneous computing power resources, the unified management and migration adaptation method includes the following steps: S101 (managing resources and extracting capability contracts), S102 (constructing a target capability map), S103 (dividing migration states), S104 (generating dual-format checkpoints), S105 (shadow restoration and verifying equivalence), S106 (freezing increments and switching entry points), and S107 (observing out-of-bounds errors and performing rollback).

[0010] This invention is constrained by resource management version and workload portability contract at both ends, and expands along state partitioning, dual-format checkpoints, shadow recovery, entry barriers, and observation rollback. The original processing details of each state are retained as follows.

[0011] Establish resource management records for source and target resources respectively. Each resource management record includes resource stability identifier, processor instruction set, byte order, kernel and system call version, application binary interface, runtime, accelerator capabilities, management interface, probe time interval, quality flag and capability map version.

[0012] Static analysis is performed on the executable files, image manifests, and dependency files of the workload to be migrated, and the workload is run and traced to extract instruction sets, system calls, application binary interfaces, dynamic libraries, accelerator operators, data states, and external dependencies, generating a workload portability contract that references the source resource management record version.

[0013] A target capability graph is constructed based on the target resource management record. The target capability graph uses capability and version range as nodes, and records the semantic differences, allowable errors and recovery steps between source capabilities and target capabilities using dependency edges, substitution edges or transformation edges.

[0014] Based on recovery semantics, the workload state is divided into file state, CPU process memory state, accelerator tensor state, device queue state, and external session state, and each state partition is marked as directly migrated, needs to be transformed, needs to be rebuilt, or is not migrated.

[0015] For directly migrated states, a content summary is generated; for states that need to be transformed, a source format snapshot, a transformation representation corresponding to the state category, and a target recovery recipe are generated simultaneously; for states that need to be rebuilt, a reconstruction description, reconstruction input, and completion boundary are generated; and for non-migratable states, migration blocking terms are generated.

[0016] Establish a baseline checkpoint and initiate incremental capture while the source instance continues to provide production traffic. Transfer the baseline checkpoint to the target isolation domain that does not receive production traffic. Restore the target shadow instance according to the direct copy, conversion recipe, or reconstruction description of each state partition. Select the necessary capability probes and workload equivalent probes based on the read / write set of each state partition.

[0017] After the static probe of the target shadow instance is closed, the new writes to the source instance are briefly frozen, the freeze sequence number is latched, all increments up to the freeze sequence number are emptied and transmitted, the increment sequence numbers are confirmed to be continuous and the digest chain is consistent on the target side, and the necessary probes affected by the increments are re-executed.

[0018] Create a monotonic migration period and an entry barrier token for the entry controller. First, make the source entry reject new production writes above the freeze sequence number and obtain barrier confirmation. Then, make the target entry active during the migration period. Prevent the source entry and target entry from accepting production writes simultaneously during the same migration period.

[0019] During the observation period, the target instance writes each variable state to the reverse incremental log with a monotonic sequence number.

[0020] When numerical errors, device status, or external session continuity exceed limits occur, new writes to the target are frozen. Only when the reverse incremental log is continuous, the source format snapshot is readable, and external side effects have been cleared or there is idempotent confirmation from the peer, are reverse increments applied sequentially to the source instance, and the source entry is restored at a higher migration period. Otherwise, the target entry is isolated and the source and target states are not released.

[0021] Furthermore, the resource management record also includes resource status, valid range of location aliases, agent launch generation, and most recent probe summary; the resource status changes between unregistered, discovered, verified capability, available, reserved, migrating, isolated, and decommissioned. During the migration period, the resource management record version with the verified capability or available status must be referenced. The management address or brand name is not used as the unique identity of the resource.

[0022] Furthermore, the workload portability contract covers unexecuted paths through static analysis and records actual call signatures and parameter ranges through runtime tracing; unresolved dynamic add-ins are stored as explicit unknown fields and a probe is generated to be executed before the target isolation domain is started. The corresponding state partition is marked as non-portable before the probe passes.

[0023] Furthermore, the migration or reconstruction descriptions corresponding to the state categories include: for CPU process memory states, the transformation representation records the integer bit width, byte order, alignment, reference relationships, and relocatable fields of objects or page segments; for accelerator tensor states, the transformation representation records element type, precision, shape, stride, layout, content summary, and object dependencies; for device queue states, the reconstruction description does not copy the native queue pointer that cannot be confirmed at the target runtime, but records the confirmed completion boundary, replayable request description, and reconstruction order; for external session states, the reconstruction description records the peer stability identifier, protocol phase, confirmed transaction boundary, and reconnection token, but does not copy non-transferable connection handles.

[0024] Furthermore, when a state partition contains active transactions whose completion boundaries cannot be confirmed, unexplained native handles, or a lack of corresponding capabilities on the target side, the state partition is marked as non-migratable. Only when the corresponding incomplete transactions are cleared before freezing and completion confirmation is obtained from the other end, or when an equivalent state is re-established on the target side based on a verified reconstruction token and passed through the corresponding probe, will a new partition version be generated and the state partition be remarked as needing reconstruction. The same non-migratable state will not be directly interpreted as a convertible state.

[0025] Furthermore, the required probe set is determined by the read / write set of the affected state partitions and includes at least the following: for file states, perform content block digest, metadata, permissions, and executability probes; for CPU process memory states, perform system call return and data digest probes; for accelerator tensor states, perform key operator response structure, tensor shape, and numerical error probes; for device queue states, perform device enumeration, request submission, and completion boundary probes; for external session states, perform reconnection, sequence number continuation, and transaction acknowledgment probes; a probe closure digest is formed only when all required probes for the affected state partitions have been passed.

[0026] Furthermore, the entry switch preparation record should include at least the workload identifier, contract version, source checkpoint summary, freeze sequence number, target maximum consecutive sequence number, probe closure summary, migration period, and rollback point. The entry controller will only switch when the above fields are consistent with the target confirmation. When the interface times out and the external status is unclear, it will enter the unknown submission status and read the actual period of the source and target entry. Direct repeated switching is prohibited.

[0027] Corresponding to the aforementioned methods, this invention also discloses a system for managing and migrating heterogeneous computing power for domestic IT innovation. The system comprises a resource registration agent, a capability probe, a contract extractor, a state partitioner, a checkpoint converter, an incremental capturer, a target isolation domain, an equivalence verifier, an entry period barrier, a reverse incremental log, a rollback controller, and an entry controller. Each component is configured to perform the method described in any one of claims 1 to 7. The resource registration agent associates resource management records with resource stability identifiers. The state partitioner selects a direct copy, conversion, reconstruction, or blocking mode according to the state category. The entry period barrier first closes source entry writing before allowing target entry activity. The entry controller submits the migration period only after the incremental sequence number, probe closure digest, and barrier token are consistent. The rollback controller restores the source entry only when the reverse incremental log and external side effects confirm closure.

[0028] To perform the aforementioned processing, the present invention also discloses a migration control device, characterized in that it includes a processor, a memory, a source resource interface, a target resource interface, and an entry control interface, wherein the memory stores resource management records, workload portability contracts, source format snapshots, and target recovery recipes, and the processor implements the method described in any one of claims 1 to 7 when executing the stored program instructions.

[0029] The present invention also discloses a non-transitory computer-readable storage medium having program instructions stored thereon, characterized in that the program instructions, when executed by a processor, implement the method described in any one of claims 1 to 7.

[0030] State partitioning prevents non-migratable objects from being mistakenly treated as convertible objects, while source format snapshots, recovery recipes, and partition probes provide verifiable recovery data for each target state.

[0031] During the entry phase, the fence is submitted in the order of closing the source first and then opening the target; during the observation phase, the reverse increment is only used for rollback when both continuity and external side effects are closed, thereby avoiding double writes and incomplete reverse overwrites. Attached Figure Description

[0032] Figure 1 A flowchart for the migration, adaptation, and rollback of domestic IT innovation and heterogeneous computing resources.

[0033] Figure 2 Functional structure diagram of the system for managing and migrating domestic and heterogeneous computing resources.

[0034] Figure labeling: Resource management adapter 110, Capability contract extractor 120, Target capability graph builder 210, Migration state partitioner 220, Dual format checkpoint converter 230, Shadow recovery and equivalence checker 310, Entry switching and rollback controller 320. Detailed Implementation

[0035] The following sections explain resource management records, portability contracts, state partitioning, and entry point switching. All checkpoints, increments, and probe results on both the source and target sides reference the same migration period and contract version.

[0036] Resource management records must include at least the following: resource_id, boot_generation, processor_isa, endianness, kernel_version, syscall_set, abi_version, runtime_versions, accelerator_capabilities, management_endpoint, location_alias, probe_interval, quality_vector, capability_graph_version, and resource_state. The resource_id is generated by stable identification from hardware or trusted agents; the management address is only used as an alias with a valid range. The boot_generation is added upon agent restart, and late probes from older generations must not update current capabilities. A resource's state progresses from "discovered" to "capable" after capability verification, and then to "isolated" upon probe conflict or expiration of critical capabilities.

[0037] The contract extractor jointly parses executable headers, dynamic dependencies, image manifests, and device plugins, and records system calls, driver calls, operator names, parameter ranges, and external service accesses during a controlled observation period. Static items are used to cover unexecuted paths, while dynamic items are used to confirm actual usage frequency; objects that may be dynamically loaded but not resolved are written as UNKNOWN_DYNAMIC and a pre-boot probe is generated. Each capability item stores its source location, version, call signature, and applicable conditions; identical names cannot be automatically mapped to semantic equivalence.

[0038] CPU process memory translation is represented by objects or page segments, recording bit width, byte order, alignment, relative references, and fields requiring relocation. It does not guarantee that any native pointer can be directly translated. Accelerator tensor translation records element type, precision, shape, stride, layout, content summary, and dependency graph. File state is saved as a content block summary and metadata. Device queues use a reconstruction description, saving only confirmed completion boundaries, replayable descriptors, and reconstruction order, without copying native queue pointers that the target runtime cannot interpret. External sessions use a reconstruction description, saving only peer identity, protocol stage, confirmed sequence number, and reconnection token. Translation representations and reconstruction descriptions each have schema versions.

[0039] State partitions are defined by the minimum shared recovery dependencies. Read-only files are marked for direct migration; CPU objects containing byte order or references, and tensors requiring changes in precision or layout, are marked for conversion; accelerator queues, regenerable caches, and sessions recoverable by tokens are marked for reconstruction; active sessions that cannot be drained and for which the peer does not provide transaction acknowledgments are marked for non-migration. The target recovery recipe sequentially lists the input partition, the conversion program version, the target object creation order, reference repair, integrity verification, failure compensation, and the source snapshots required for rollback. If any step is unknown, the partition is stopped.

[0040] The equivalence verifier generates a probe matrix based on the read set, write set, and external side effects of each partition. For CPU partitions, it verifies the system call return type, key memory object summary, and output protocol fields; for tensor partitions, it verifies the shape, layout, finite value state, and numerical tolerances given by the contract; for device queues, it verifies the enumeration results, commit identifier, completion boundary, and error semantics; and for external sessions, it verifies the reconnection identity, peer acknowledgment number, and uncommitted transaction handling. In addition to passing bits, the probe results also store the input summary, observations, tolerance source, and target capability node; if any affected partition lacks the necessary probes, the overall state remains one where the shadow has been restored but not equivalent.

[0041] The cost of a candidate migration scheme r can be written as Cost(r) = C_move(r) + C_convert(r) + C_rebuild(r) + P_risk(r)·L_rollback, where each term references the same contract and resource capability graph version. This formula only sorts schemes that meet the hard constraints; if there are non-migratable partitions, missing necessary probes, unreserved target capacity, or unreadable source format snapshots, the scheme is directly judged as infeasible. The units, sources, and applicable state categories of conversion cost, recovery cost, and allowable error are saved with the scheme and cannot be offset by brand similarity.

[0042] The migration main state chain is as follows: Pending Analysis, Partitioned, Baseline Checkpoint Prepared, Incremental Capture in Progress, Shadow Recovery in Progress, Static Probe Verification in Progress, Final Freeze, Incremental Drain, Dynamic Probe Re-verification, Switching Preparation, Switched, and Observation. After the baseline checkpoint is established, the source instance resumes production writes, and writes are allocated by the incremental capturer using `write_seq`. Final freeze only blocks new writes after the freeze sequence number. The target only enters switching preparation after confirming the maximum consecutive sequence number and digest chain up to the freeze sequence number. If any hard constraint is not met, the branch enters blocking; if the entry operation result is unknown, it enters "Commit Unknown" and reads the actual entry period of the source and target, as well as the barrier token; if the observation goes out of bounds and the reverse log is closed, it enters "Rollbacked"; if the log or external side effects are not closed, it enters "Isolation". The entry switch request uses the workload identifier, checkpoint digest, migration period, and action number to form an idempotent key. When the commit is unknown, generating new action numbers to bypass the query is prohibited.

[0043] The source entry point remains unchanged when there are unresolved dynamic add-ins, changes in the target capability map version, gaps in the incremental sequence number, out-of-bounds numerical errors, inconsistent device queue completion boundaries, or failure to obtain peer confirmation from the external session. Before the entry point switch, irreversible external side effects must be cleared and peer completion boundaries obtained, or the external transaction identifier must be registered as a queryable, deduplicatable idempotent key; otherwise, the corresponding state is marked as non-migratable from the beginning. After the switch, each item's write is first written to the reverse log using before_digest, after_data, write_mask, write_seq, and group_commit, and then confirmed externally for completion. When the observation period exceeds the boundary, the target write is frozen first. Only when the log is continuous, the group commit is closed, and the source snapshot is readable, is the write replayed in sequence and the source entry point restored at a higher time. If any condition is not met, isolation is implemented. The source format snapshot and source instance must not be reclaimed before the observation period is closed.

[0044] Taking the migration of inference services from one instruction set and accelerator runtime to a domestically developed processor and another accelerator as an example: the resource agent registers the instruction set, ABI, runtime, and operator parameter ranges on both sides; the contract extractor marks read-only model files as directly migrated, device tensors with layouts as requiring conversion, device queues as requiring reconstruction, and active transactions without peer confirmation as non-migrateable. The target isolation domain restores files and tensors according to the recipe, re-establishes queues, and executes system calls, key operators, data digests, and session continuity probes. Only when the blocking transactions have been cleared and all necessary probes are closed does the controller synchronize continuous increments after the freeze point and switch the entry point.

[0045] Figure 1 The system uses a dual-path approach, encompassing both the source and target sides, to demonstrate capability contracts, state partitioning, dual-format checkpoints, shadow recovery, incremental commits, entry switching, and observation rollback. Figure 2 This shows the connections between the source resource, migration adaptation layer, target isolation domain, and ingress controller.

[0046] See Figure 1 The source side first forms a capability contract and divides the migration status. The dual-format checkpoints are the basis for target recovery and source-side rollback retention, respectively. The target shadow instance only receives the increment and entry period after passing the equivalence verification. If the observation goes out of bounds, the source instance is recovered along the independent rollback branch.

[0047] Figure 1 This corresponds to one migration request. After step S107 completes the backswing, entry isolation, or observation period confirmation, the current migration attempt terminates; subsequent migrations must be triggered by a new request and a new migration period, and step S107 is not drawn as an unconditional loop returning to step S101.

[0048] Each step shares the migration capability contract and checkpoint records, but does not share unconfirmed intermediate states. The processor first verifies the workload identifier, source state period, and target capability version, and then checks the source snapshot period, shadow verification period, entry commit period, and observation rollback period; the activity pointer is only updated after all writes are completed, and conflicting, late, or insufficiently evidenced records must not be concatenated with results from other periods.

[0049] In step S101, the system completes resource management and extracts capability contracts. It uniformly registers source-side CPUs, GPUs, drivers, runtimes, and external dependencies; static analysis covers unexecuted paths, runtime tracing confirms actual usage, and unresolved dynamic add-ins remain unknown while a pre-startup probe is established. The judgment that "non-transferable states must not be disguised as convertible" is limited to frozen snapshots, and unknown operands are not padded with default values.

[0050] Step S102 involves constructing the target capability graph. This involves verifying the target capabilities using actual interface probes, establishing capability substitution edges, and registering semantic differences, conversion costs, and permissible errors. Before publishing the results of this stage, it is also necessary to verify that "conversion rules must be bound to the source target version"; if verification cannot be performed from the current snapshot, the results remain in a pending verification state and point to the most recent stable version.

[0051] After proceeding to step S103, the system completes the migration state partitioning. Based on minimum shared dependencies, the states are divided into replicable, convertible, require rebuilding, and non-migratable partitions; partitions that depend on convertible or non-migratable capabilities are treated as non-migratable. In this stage, "shadow instances are not written into formal external side effects" is used as a substantive threshold; if the threshold is not met, only conflict items, scope of impact, and evidentiary gaps are registered.

[0052] Step S104 is used to generate a dual-format checkpoint. A snapshot of the source format is preserved for rollback, and an intermediate representation recording byte order, precision, tensor layout, and handle semantics is generated; the external session only saves the reconstruction token. The output is available for the next step only if "equivalent probes cover critical input / output and resource semantics" is true in the current period; otherwise, the active version remains unchanged.

[0053] After completing the previous stage, step S105 completes shadow restoration and verifies equivalence. In the target isolation domain that does not receive production traffic, the instance is restored, and startup, device enumeration, key operators, data read / write, and external dependencies are verified sequentially. Differences are then mapped back to capability nodes and conversion rules. The judgment of "using the same migration period and checkpoint for switching and rollback" is limited to frozen snapshots, and unknown operands are not padded with default values.

[0054] Then proceed to step S106, where the system freezes the increment and switches the entry point. The variable state is briefly frozen and the increment is transmitted. After the target confirms the increment period, the entry controller atomically switches over; the source instance remains isolated and recoverable.

[0055] In step S107, the system completes the observation out-of-bounds check and performs a rollback. During the observation period, the functional, state, and performance boundaries are compared; if an out-of-bounds checkpoint occurs, the source format checkpoint is restored and the entry point is switched back; the source-side recoverable state is released only after the observation period passes.

[0056] The results of each stage are linked through the parent version summary and the input summary. If evidence is withdrawn, the period expires, or the input changes, the processor recalculates the affected portion along the dependency index, without modifying the remaining confirmed records. If any publication threshold is not met, no migration entry switch or external session takeover is initiated; instead, the reason for failure, affected objects, supplementary evidence entry point, and secure recovery point are retained. When publishing the results, the applicable period, evidence path, and unresolved boundaries are recorded together.

[0057] Furthermore, the workload portability contract is extracted through a combination of static analysis and runtime tracing, and a pre-launch probe is set for unresolved dynamic add-ins.

[0058] Furthermore, the alternative edges of the target capability graph record the semantic differences, transformation costs, and permissible errors between the source capability and the target capability.

[0059] Furthermore, the state partition includes at least files, process memory, device state, and external sessions, and is marked as directly migrated, transformed, rebuilt, or non-migratable, respectively.

[0060] Furthermore, the dual-format checkpoint simultaneously saves a snapshot of the source format and an architecture-neutral representation containing byte order, precision, layout, or handle semantics.

[0061] Furthermore, shadow recovery does not receive production traffic and executes the necessary equivalent probes covering the entire affected state partition read / write set in device enumeration, key operators, data read / write, and external dependencies.

[0062] Furthermore, before submitting the migration, the increment after the freeze point is transmitted according to the written sequence number, and the entry point is switched only after the target confirms the continuous sequence number and digest.

[0063] This embodiment uses a workload portability contract as the data carrier throughout the processing chain, and saves records according to version and processing period. Specifically, workload requirements are expressed as platform-independent portable contracts, source states are partitioned according to semantics and architecture dependencies, and dual-format checkpoints are formed containing source snapshots, architecture-neutral representations corresponding to state categories, and recovery recipes. The target end switches or rolls back according to the migration period after verification through capability graph constraint mapping and shadow recovery probes. In this specification, "confirmed" means that there is direct technical observation or mutually independent indirect observation and the input digest is consistent; "unknown" means that there is insufficient existing evidence to make a negative judgment.

[0064] During implementation, the input end receives source resources and runtime status, workload capacity requirements, target capability graph, and state architecture dependency markers, respectively. Interface requests carry object stability identifiers, expected versions, calling permissions, and idempotent keys, while responses carry the actual version, collection time interval, quality flags, and content summary. Data from cache, mirrors, or inference sources is stored directly from the source; unobtainable fields use explicit unknown values, and missing items remain in an unknown state, not replaced by zero values ​​or expired records.

[0065] The parameters, thresholds, and weights used for calculations are fixed along with the workload's portable contract version. Thresholds can be determined by the equipment specifications, the quantile of the field-calibrated sample, the upper bound of historical normal window fluctuations, and the task latency budget or risk budget; parameters should not be changed within the same processing period. If the sample size is insufficient or the denominator is zero, the calculation result is marked as incalculable, and unspecified empirical constants must not be used instead.

[0066] After receiving the workload portability contract, the control node first performs checks on field types, object existence, version continuity, permission scope, and integrity digests. Then, it calls the generation of the portable workload contract to switch or roll back the corresponding processor according to the schedule. Each processor only appends the output fields of this step, and the upstream input remains read-only. When rules or topology need to be modified, the next version is generated, and the set of affected objects is retrieved from the dependency index.

[0067] Adjacent steps exchange data via structured objects. The previous step outputs a state migration partition or dual-format checkpoint, which is then written to the parent version field. The next step re-verifies that the parent version is still the current valid version before generating the switch or rollback record. If a discrepancy occurs in the digest after the transformation, only the branches that depend on the failed interface are frozen; other unrelated branches remain in the confirmed state.

[0068] Candidate processing first performs hard constraint filtering, then sorts within the feasible set: The first layer establishes a hard constraint feasible set based on the following: non-transferable states must not be disguised as transferable, transformation rules must be bound to the source and target versions, and shadow instances must not be written into formal external side effects; the second layer sorts only within the feasible set based on risk, latency, resource consumption, or evidence completeness. If the feasible set is empty, conflicting constraints and gaps are returned, without relaxing safety conditions.

[0069] Upon entering the commit phase, the system rereads the shadow recovery observations and the current workload portable contract header version, comparing them with the input digests saved during the preparation phase. Committing is allowed if the digests match; if the digest changes but does not affect the current dependent branches, confirmed outputs are reused; if a digest change hits a dependency index, only the affected branches are recalculated, and unaffected branches are not rolled back entirely.

[0070] The final switch or rollback record is published through the results interface, which simultaneously returns the status, applicable period, input summary, evidence path, and unresolved boundaries. The caller can only perform subsequent irreversible actions when the status is confirmed and the applicable period is still valid; candidate, unknown, and contradictory results are only used for diagnosis, supplementary evidence, or manual review.

[0071] The workload portability contract is a structured record that runs through the processing chain of this invention, and includes at least the workload identifier, instruction set requirements, system call set, ABI constraints, acceleration operator set, data and state partitions, external dependencies, target capability graph, transformation rules, equivalent probes, migration period, and fallback point. The state partitions are marked as directly migrateable, require transformation, require reconstruction, or are not migrateable; each marker is associated with detection evidence and the target capability path.

[0072] The nodes in the target capability graph of the resource management record version represent the callable capabilities and version ranges, the edges represent dependency, substitution or conversion relationships, and the brand and architecture name are treated as attributes rather than matching conclusions.

[0073] Equivalent probes verify external behaviors that are meaningful to the workload, including numerical tolerance, device visibility, data digests, or protocol responses, without substituting process liveness.

[0074] The system deploys read-only probes and migration agents in both the source and target environments, connecting to the orchestrator, image repository, checkpoint storage, and accelerator runtime. The migration agent transmits state partitions and their summaries via an encrypted channel.

[0075] In step S101, the source-side CPU, GPU, driver, runtime, and external dependencies are uniformly registered; static analysis covers unexecuted paths, runtime tracing confirms actual usage, unresolved dynamic loads remain unknown, and a pre-startup probe is established.

[0076] In step S102, the target capability is verified with an actual interface probe, a capability substitution edge is established, and semantic differences, conversion costs, and allowable errors are registered.

[0077] In step S103, the state is divided into replicable, convertible, rebuilt, and non-migratable partitions according to the minimum shared dependency; partitions that depend on convertible and non-migratable capabilities are treated as non-migratable.

[0078] In step S104, a snapshot of the source format is retained for rollback, and an intermediate representation is generated that records the byte order, precision, tensor layout, and handle semantics; the external session only saves the reconstruction token.

[0079] In step S105, the instance is restored in the target isolation domain that does not receive production traffic. The startup, device enumeration, key operators, data read and write, and external dependencies are verified in sequence, and the differences are mapped back to the capability nodes and conversion rules.

[0080] In step S106, the variable state is briefly frozen and the increment is transmitted. After the target confirms the increment period, the ingress controller atomically switches over; the source instance remains isolated and recoverable.

[0081] In step S107, the functional, state, and performance boundaries are compared during the observation period; if an out-of-bounds error occurs, the source format checkpoint is restored and the entry point is reverted; the source-side recoverable state is released only after the observation period is passed.

[0082] Cost(r)=Cmove(r)+Cconvert(r)+Crebuild(r)+Prisk(r)·Lrollback

[0083] In the formula, r represents the migration scheme, and each term represents the cost of direct transfer, format conversion, target reconstruction, and failure rollback, respectively; the scheme is invalid when the non-migratable partition is not isolated or reconstructed.

[0084] Dynamic behaviors in capability contracts are recorded through call signatures with parameter ranges, such as operator name, input precision, layout, and allowable error; targets that only support capabilities with the same name but different parameter ranges should not be directly judged as compatible.

[0085] Incremental migration uses the migration period and the write sequence number as a correlation, and the maximum consecutive sequence number of the target confirmation constitutes the commit point; when there is a gap in the sequence number, the source is retained as an active instance.

[0086] Example 2 illustrates the migration of an inference service running on an x86 processor and calling a dedicated acceleration interface to an ARM processor and another type of accelerator. The migration goal is not to ensure identical binary bytes, but to maintain the semantics of outbound requests, the range of critical numerical errors, and session continuity.

[0087] The workload portability contract consists of static and dynamic items. Static items extract instruction sets, byte order, ABIs, dynamic libraries, and device plugins from executables and images; dynamic items extract actual usage paths from system calls, driver calls, and operator traces. Libraries that are not observed during the observation period but can be dynamically loaded are set up as pre-boot probes.

[0088] The nodes in the target capability graph represent processors, kernel interfaces, runtimes, operator implementations, and external services; alternative edges record the semantic mapping between the source and target capabilities, allowable errors, transformation steps, and recovery costs. Target capabilities that are only similar in name but lack an interface contract do not have definite alternative edges established.

[0089] State partitioning is based on recovery semantics. Read-only model files can be migrated directly; process memory containing pointers and byte order needs to be converted; accelerator queue state is usually rebuilt at target runtime; uncommitted transactions with external databases that cannot obtain confirmation from the peer are marked as non-migratable and require to be emptied before freezing.

[0090] The dual-format checkpoint preserves a snapshot of the original pages or objects for the partition to be converted, while generating an architecture-neutral representation. The intermediate representation explicitly specifies the integer bit width, byte order, floating-point precision, tensor layout, handle type, and object references; the target recovery recipe specifies the order in which the target object is built from the intermediate representation and the verification method.

[0091] The shadow recovery domain is isolated from the production entry point. Capability probes verify device enumeration, memory allocation, and the executable nature of key operators; workload equivalence probes compare response structures, key fields, and numerical errors against fixed inputs and verify external dependency calls. Results are invalidated if the input summary used by any probe does not match the checkpoint.

[0092] Before the switch, writes generated by the source instance after the freeze point are transmitted in monotonic sequence. After the target instance confirms that the sequence from the freeze point to the last sequence number is continuous and the digest chain is consistent, the controller generates a new migration period and switches the entry point; late old period requests are still completed by the source instance or forwarded by session mapping, and are not mixed with the new period results.

[0093] If numerical errors exceed limits or external sessions become discontinuous during the switchover observation period, the entry point is restored to the source instance, and reversible increments generated during the target period are either replayed or discarded according to the reverse recipe. Source format snapshots must not be reclaimed before the end of the observation period to ensure that conversion errors do not cause rollbacks to depend on the same erroneous intermediate representation.

[0094] The unified management layer displays resource status references the target capability graph version and migration period. When a resource interface is upgraded, only the alternative edges and state partitions affected by that interface are re-verified; irrelevant file summaries and external service evidence continue to be reused to narrow the scope of adaptation.

[0095] In terms of data organization, each workload portability contract includes at least an instruction set, ABI, operators, state partitions, source format snapshots, intermediate representations, recovery recipes, and probe summaries. Business identity and database auto-incrementing primary keys are stored separately; business identity is determined by workload identifiers, checkpoint summaries, and migration periods, while auto-incrementing primary keys are only used for physical location. Updates use append-only versions, with the previous version recording its termination reason and remaining readable, thus enabling differentiation between object changes, repeated data collection, and reprocessing of the same object.

[0096] In terms of state control, workload portability contracts can be in the following states: pending analysis, direct migration, requiring transformation, requiring reconstruction, non-migratable, shadow restored, switched, and rolled back. Each transformation is triggered by a specific event, and the transformation record contains the states before and after the transformation, the trigger field, and the rejection reason. The recovery procedure only replays confirmed transformations and does not infer intermediate states from the final field values; this allows for different handling of execution interruptions, late messages, and partial successes.

[0097] For migration entry point switching and external session takeover, the system first generates a preparation record containing the expected write set and compensation entry, and then calls the execution interface. Commit is only confirmed when the object identities of the execution receipt, independent observation, and preparation record match. If the interface times out and the external state is unclear, it is marked as an unclear commit, and the external observation is read first; actions with side effects are not immediately repeated.

[0098] In terms of concurrent processing, the idempotent index is a hash of the workload identifier, checkpoint digest, normalized encoding of the migration period, and action number. When the same index is reached again, if the input digest is the same, the already confirmed output reference is returned; if the digests are different, an idempotent conflict is registered and overwriting is rejected. In multi-processor contention, a unique writer is determined through conditional write or comparison exchange, and the processor that does not obtain the write right becomes the result reader.

[0099] All time-related fields are registered as intervals, which cover the source freeze interval, shadow verification interval, entry switching point, and observation period. Two intervals are only allowed to be used in the same calculation if they still intersect after considering clock errors and the source period has not been reset. When the interval uncertainty exceeds the rule's allowed value, the system expands the set of records to be verified instead of shortening the interval; late records are written to their original period without modifying the currently published conclusion.

[0100] This embodiment requires configuration of parameters including allowable numerical error, incremental transmission window, probe timeout, and switching observation period. Parameter values ​​are derived from device specifications, offline calibration, or prior stable operating samples. At the start of processing, the parameter values, units, source summary, and applicable objects are written to a read-only parameter snapshot. Specific values ​​can be changed during implementation, but parameter items corresponding to security commits, version consistency, or integrity checks must not be deleted.

[0101] In the event of an interruption or partial failure, the recovery process is limited to: restoring the source entry point and preserving the original semantics using a snapshot in the source format, while handling the target increment according to the reverse recipe. Each rollback request has its own independent action number, and upon successful execution, a recovery observation and a post-recovery summary are appended; if a step cannot be recovered, subsequent compensation dependent on that step is discontinued, on-site evidence is preserved, and the object is placed in an isolated state to prevent null values ​​from masquerading as recovery completion.

[0102] One deployment of the system comprises a source workload agent, a target capability probe, a checkpoint converter, a shadow recovery domain, and an ingress controller. Control messages are structured messages with length and version numbers; the receiver checks each required field, enumeration range, and checksum. Older versions of the receiver can ignore unknown optional fields, but must reject and return the supported mode version when encountering unknown required fields.

[0103] This study compares downtime reinstallation, single-format checkpointing, and dual-format shadow recovery for workloads that include local state, rebuildable cache, device context, and external sessions. It records source-side pause times, target-side recovery failures, differences in native and platform-independent state summaries, inconsistencies in equivalence probes, and source-side state continuity after rollback.

[0104] After a power outage or restart, the recovery process first reads the most recent complete checkpoint, then scans subsequent preparation and confirmation records. Only workload portability contracts that have been verified and confirmed are entered into the active index; objects with only preparation records are determined to be continued, compensated, or isolated based on external observations. The scan results are written to a new recovery period without altering the sequence numbers before the interruption, thus preserving the causal boundaries required for incident analysis.

[0105] When instruction sets, ABIs, operators, state partitions, source format snapshots, intermediate representations, recovery recipes, and probe digests are provided by different interfaces, the adaptation layer simultaneously registers and saves the original and normalized values, units, source versions, and transformation rules. Fields that fail to normalize remain unknown with a reason code and are not converted to zero. If multiple sources provide conflicting results for the same field, a workload portability contract candidate set is formed according to the pre-configured evidence level, and the step using the field determines whether to re-collect or stop submission.

[0106] When candidate results for workload portability contracts have the same priority, the processor sequentially checks the satisfaction of hard constraints, the completeness of evidence, the recovery cost, and the stability flag. The last item is only used to determine the order and does not change the technical feasibility. Each component used for sorting retains its original value, so that the same selection is obtained when replaying under the same input, and it can explain which constraint among allowable numerical error, incremental transfer window, probe timeout, and switching observation period was excluded.

[0107] Before writing to the persistent directory, the instruction set, ABI, operators, state partitions, source format snapshots, intermediate representations, recovery recipes, and probe digests are arranged by field number. Numerical values ​​are uniformly specified in units, and enumerated values ​​are written to the mode version. Then, the content digest is calculated. Strings are only subjected to protocol-defined whitespace and encoding normalization; resource names are not fuzzy merged. In this way, the same workload portability contract can produce the same digest on different processing nodes, and two objects with only the same display name will not be mistaken for the same object.

[0108] The version identifier is calculated as follows. Let the normalized business key be K, the processing period be E, the input digest be D, and the parameter snapshot digest be P. Then the version identifier can be H(K∥E∥D∥P), where H is the collision-resistant hash function selected by the system, and the connector includes the field length. K corresponds to the workload identifier, checkpoint digest, and migration period. In addition to comparing the version identifier, the reading end also compares E and the pattern version item by item to prevent accidental digest reuse under different encoding rules.

[0109] The quality field is expressed as a vector and includes at least four components: source authenticity, temporal integrity, field integrity, and cross-component consistency. Steps using a particular field declare the required components and minimum quality levels; low-quality flags not using a field do not block irrelevant branches. When performing partial updates to the workload portability contract, only outputs dependent on the changed components are recalculated; other confirmed outputs retain the original evidence references without copying the original content.

[0110] When the interface returns only some fields, the system first determines whether the gap is relevant based on the read set of subsequent actions. If the missing field is not in the read set, processing can continue, but the gap flag is retained in the output. If the field is involved in the migration entry switch and external session takeover release judgment, the branch is stopped and a supplementary acquisition request is generated. The supplementary acquisition result must include the original workload identifier, checkpoint summary, migration period, and new source summary. After confirmation, only the branch waiting for that field is awakened to avoid unconditionally rerunning the entire process.

[0111] A transaction catalog is established around the workload portability contract, with preparation, external call, observation confirmation, and compensation records numbered separately. A preparation entry must at least store the calling interface, target object, expected write set, pre-execution summary, request idempotent key, and timeout; a confirmation entry stores the receipt summary and independent observations. When a receipt is lost but the observation shows the target state has changed, the catalog confirms it as executed and continues the confirmation phase, rather than calling the interface again; if the observation is also uncertain, the commit remains unclear, and the recovery process handles it, without directly resending the migration entry switch or external session takeover.

[0112] The processing queue uses business objects as sharding keys, not message sources. Only one writer is allowed at any given time for the same workload identifier, checkpoint summary, and migration period; different objects can be processed concurrently. Once the queue reaches its capacity limit, the entry point prioritizes acknowledgment messages, rollback messages, and evidence re-collection results. Regular duplicate samples can be merged into a single record with a count. Merging only applies to samples that have not yet been consumed and have the same pattern version, and cannot cross source freeze intervals, shadow verification intervals, entry point switching points, or observation period boundaries.

[0113] To check for abnormal paths, injection scenarios include message duplication, message out-of-order delivery, processor restart after preparation, interface execution timeout, mode version switching, and one source distortion. An input snapshot is saved before each injection, and after injection, it is checked for erroneous commits, unfounded state transitions, or unassociated isolated records. For the recovery source entry point, the original semantics are preserved using the source format snapshot. The target increment is processed according to the reverse recipe, and the process is interrupted again during compensation to verify that the recovery procedure can continue from the confirmation point of the compensation action itself without re-executing the already completed reverse action.

[0114] Boundary condition verification sets up three types of objects: a baseline object with all evidence complete, an object exactly located at the rule boundary, and an object missing only one key field. Boundary values ​​are taken as the lower bound, upper bound, and adjacent representable values ​​of the allowed values, respectively; for count or fixed-point fields, overflow, wraparound, and reset are also tested. The results cannot only compare the final success or failure, but also compare whether the state of the workload portability contract, the reasons for rejection, and the evidence references are consistent with the expectations item by item.

[0115] For all interfaces involving access control, the least privilege credential is used. The credential itself is not written into the workload portability contract; only an irreversible credential reference summary, permission scope, and audit number are recorded. When the executing entity is not authorized to complete the migration entry switch or external session takeover, the process terminates during the preparation phase, and permission errors are not misjudged as target object failures. Audit records and business records are associated with the same object key and processing period, but access is controlled separately. When exporting implementation data, a stable anonymous identifier is used to replace the real asset identifier.

[0116] Once the number of versions of a workload portability contract reaches the retention limit, consecutive versions that have been closed and exceeded the audit period can be compressed into checkpoints. Checkpoints retain the beginning and end states, a summary chain for each state transition, parameter versions, and the location of external evidence; the original large fields are transferred to content-addressable storage. Records still in a state of unclear commit, pending verification, or quarantine must not be compressed; versions with workload identifiers, checkpoint summaries, and migration period references must not be deleted until the last reference expires.

[0117] When reproducing this embodiment, the following sequence is followed: the ingress component in the source workload agent, target capability probe, checkpoint converter, shadow recovery domain, and ingress controller receives the object and establishes an input snapshot indexed by workload identifier, checkpoint summary, and migration period; the rule executor loads the read-only parameter snapshot and generates candidate results; the state controller selects confirmation, re-sampling, or isolation based on the current state and submission threshold; the confirmation result, along with evidence citations, is published to the next step. If a version change occurs midway, the current candidate is retained as the replaced record, and the new version continues from the first affected step without overwriting the old conclusion.

[0118] This application does not limit the specific brand of message bus, relational database, or processor. As long as the alternative implementation can maintain stable correlations between workload identifiers, checkpoint summaries, and migration periods, source freeze intervals, shadow verification intervals, entry switching points, and observation periods, atomic visibility of state transitions, and restore the source entry point while preserving the original semantics using source format snapshots, and handle the target increment in the order of recovery according to the reverse recipe, it can be implemented using shared memory, persistent queues, on-chip directories, or distributed logs. If the alternative implementation eliminates any of the above boundaries, equivalent consistency checks and evidence preservation mechanisms must be added; equivalence cannot be considered solely based on identical interface names.

[0119] Example 3 illustrates the migration of a task containing CPU processes, accelerator queues, and model weight caches from one instruction set and GPU runtime to another domestic IT innovation platform. The queue state cannot be directly recovered, but the weights can be converted through an intermediate representation. This example illustrates the input, state changes, and exception handling.

[0120] Take, for example, migrating an inference service that relies on the x86 instruction set and a GPU runtime to an environment with a domestically developed CPU and another type of accelerator.

[0121] Step 1: Static and runtime tracing extracts system calls, vector instructions, three key operators, and external object storage dependencies.

[0122] Step 2: The target capability map shows that the system call can be directly satisfied, the vector library needs to be replaced, the two operators have equivalent implementations, and one operator only supports different precisions.

[0123] Step 3: Mark the model file as directly migrated, the cache as rebuildable, the device memory tensor as transformed, and the active connection as non-migratable and requiring rebuilding.

[0124] Step 4: Generate source checkpoints and architecture-neutral tensor representations, and restore the target layout and precision transformation specified in the recipe.

[0125] Step 5: The shadow instance outputs a summary and a numerical tolerance probe to locate an operator error that has exceeded the limit and then selects another transformation rule.

[0126] Step 6: After incremental synchronization is completed, switch the entry point; if the drift exceeds the limit during the observation period, switch back according to the source checkpoint.

[0127] The following section explains anomaly recovery and degradation handling in conjunction with state boundaries.

[0128] (1) When a dynamic add-in cannot be resolved, the target shadow environment is required to perform a pre-launch probe. If the probe fails, the migration will not be submitted.

[0129] (2) Stop automatic migration and output blocking partition when the non-migratable external session cannot be safely rebuilt.

[0130] (3) The period when the target capability changes during the shadow verification period, the result is invalidated and the capability map is regenerated.

[0131] (4) When there is a gap in the incremental sequence number or the summary is inconsistent, the source activity status is maintained and the corresponding partition is retransmitted.

[0132] (1) The architecture-neutral representation corresponding to the state category can be a self-describing tensor, an object graph, or a key-value record with a pattern.

[0133] (2) Equivalent probes can compare precise summaries, numerical tolerances, protocol traces, or business invariants.

[0134] (3) Entry switching can be achieved through service discovery, load balancing or message partition ownership.

[0135] A corresponding system for unified management and migration adaptation of domestic and heterogeneous computing resources can be implemented in a modular manner.

[0136] 110 is a resource management adapter used for unified registration of domestic IT innovation and heterogeneous computing resources.

[0137] 120 is the capability contract extractor, used to form the interfaces and state semantics required for the workload.

[0138] 210 is the target capability graph builder, used to detect target interfaces and establish capability substitution relationships.

[0139] 220 is the migration state partitioner, used to distinguish between copied, transformed, rebuilt and non-migratable states.

[0140] 230 is a dual-format checkpoint converter used to generate both source format snapshots and intermediate representations simultaneously.

[0141] 310 is a shadow recovery and equivalence checker used to recover and verify the equivalence of critical functions in an isolated domain.

[0142] 320 is an entry switching and rollback controller, used to control incremental period confirmation, entry switching, and observation rollback.

[0143] The source-side contract and the target capability graph together determine the state partitioning and transformation recipe. The shadow recovery module maps the differences back to the capability path. Only after equivalence verification and incremental sequence closure does the submission module switch the migration period.

[0144] The deployment structure and interface implementation of this embodiment are described below.

[0145] The capability probe runs with minimal privileges and calculates a digest of the probe binary, output, and target software version.

[0146] Each checkpoint partition is encrypted and accompanied by a content digest. The target recovery device is authorized by the contract to read only the required partitions.

[0147] Construct scenarios involving differences in instruction sets, ABI versions, operator parameter ranges, missing dynamic libraries, incremental packet loss, and state drift after switching.

[0148] (1) Capacity coverage: Whether all workload requirements have direct, conversion, or rebuild paths;

[0149] (2) Error compatibility rate: The proportion of capabilities with the same name but different semantics that are judged to be compatible;

[0150] (3) State partition integrity: Whether all states obtain a unique transition category;

[0151] (4) Equivalent probe pass rate and differential positioning path length;

[0152] (5) Rollback point integrity: Whether the source instance can be restored to the continuous period before the commit after a failure.

[0153] The above method can be implemented collaboratively by a source workload agent, a target capability probe, a checkpoint converter, a shadow recovery domain, and an entry controller. The control logic indexes the workload portability contract according to the workload identifier, checkpoint summary, and migration period, and writes the source freeze interval, shadow verification interval, entry switching point and observation period, parameter version, and processing results into the same record chain. Software instructions are stored in a non-transitory computer-readable storage medium; processing requiring programmable logic can be executed by an FPGA, programmable switching device, or embedded controller. Data is exchanged between hardware and software through an interface with version and integrity verification.

[0154] Figure 2 Display modules 110 to 310 are connected to the source resource and the target isolation domain respectively. Module 320 independently controls the source and target entry points and does not use the shadow instance startup state to replace the entry point period confirmation.

[0155] The resource management and contract module 110 is used to extract instruction sets, system calls, ABIs, operators and external dependencies from executable files, runtime traces, image manifests and accelerator call records to form workload portability contracts.

[0156] The target capability graph module 210 is used to collect processors, kernels, runtimes, accelerators and management interfaces of domestic innovation and heterogeneous target resources, and to build a target capability graph with version and source.

[0157] The state partitioning module 220 is used to divide files, processes, memory, device states, and external sessions into partitions that can be directly migrated, need to be converted, need to be rebuilt, or are not migrated, based on the workload portability contract and target capability map.

[0158] The checkpoint conversion module 230 is used to generate source format snapshots, architecture-neutral representations corresponding to state categories, and target recovery recipes for partitions that need to be converted, and to generate content summaries for directly migrated partitions; and to generate blocking items for non-migrateable partitions, and to change the classification only after the transaction is emptied or the target is verifiable rebuilt, and to serve as migration blocking items.

[0159] The Shadow Recovery and Equivalence Verification Module 310 is used to recover each state partition in the target resource isolation domain, execute capability probes and workload equivalence probes, and locate incompatible capability paths based on output differences.

[0160] The entry switching and rollback module 320 is used to create a migration period and switch entries after the equivalent probe is closed, and to monitor state drift.

[0161] The electronic device includes a processor, memory, a communication interface, and a bus. The memory stores the program implementing the above steps, as well as the workload portability contract. When the processor executes the program, it first reads the valid version according to the workload identifier, checkpoint summary, and migration period, and then completes the calculation, verification, and status submission based on the allowable numerical error, incremental transfer window, probe timeout, and switching observation period. The communication interface is used to connect to the execution unit described in the embodiment; late or duplicate messages received by it are still processed according to the object period and idempotent key.

[0162] Resource brands, virtualization methods, or conversion components can change, but the control relationships for state classification, shadow verification, monotonic entry periods, and rollback after closure must be preserved and cannot be replaced by ordinary image copying.

Claims

1. A method for managing and adapting heterogeneous computing power in the context of domestic IT innovation, characterized in that... include: Step S101: Establish source resource versioning records and extract workload capability contracts through static analysis and runtime tracing; Step S102: Probe the target resource interface and construct the target capability graph; Step S103: Divide the workload state into direct migration, conversion required, reconstruction required, and non-migrationable partitions; Step S104: Generate source format snapshots, conversion representations, recovery recipes, and reconstruction boundaries or blocking items for each partition; Step S105: Restore shadow instances in the target isolation domain and execute the capabilities and equivalence probes corresponding to the partition read / write set; Step S106: After probe closure, freeze the source-end increment, verify the sequence number and digest chain, and switch the entry point during the monotonic migration period; Step S107: Record the reverse increment during the observation period. If the equivalence exceeds the boundary, the switchback will only be initiated after the source format snapshot, reverse increment, and external side effects are confirmed to be closed. Otherwise, the target entry point will be isolated and the source and target states will be retained.

2. The method as described in claim 1, characterized in that, Resource management records also include resource status, valid range of location aliases, agent startup generation, and most recent probe summary; resource status changes between unregistered, discovered, verified capability, available, reserved, migrating, isolated, and decommissioned. During migration, the resource management record version with a verified capability or available status must be referenced. Management address or brand name is not used as a unique identifier for a resource.

3. The method as described in claim 1, characterized in that, The workload portability contract covers unexecuted paths through static analysis and records actual call signatures and parameter ranges through runtime tracing; unresolved dynamic add-ins are stored as explicit unknown fields and a probe is generated to be executed before the target isolation domain is started. The corresponding state partition is marked as non-portable before the probe passes.

4. The method as described in claim 1, characterized in that, The migration or reconstruction descriptions corresponding to the state categories include: For CPU process memory states, the transformation representation records the integer bit width, byte order, alignment, reference relationships, and relocatable fields of objects or page segments; for accelerator tensor states, the transformation representation records element type, precision, shape, stride, layout, content summary, and object dependencies; for device queue states, the reconstruction description does not copy the native queue pointer that the target cannot confirm at runtime, but records confirmed completion boundaries, replayable request descriptions, and reconstruction order; for external session states, the reconstruction description records the peer stability identifier, protocol phase, confirmed transaction boundaries, and reconnection tokens, but does not copy non-transferable connection handles.

5. The method as described in claim 1, characterized in that, When a state partition contains active transactions whose completion boundaries cannot be confirmed, unexplained native handles, or a lack of corresponding capabilities on the target side, the state partition is marked as non-migratable. Only when the corresponding incomplete transactions are cleared before freezing and completion confirmation is obtained from the other end, or when an equivalent state is re-established on the target side based on a verified reconstruction token and passed through the corresponding probe, will a new partition version be generated and the state partition be remarked as needing reconstruction. The same non-migratable state will not be directly interpreted as a convertible state.

6. The method as described in claim 1, characterized in that, The required probe set is determined by the read / write set of the affected state partitions and includes at least the following: for file states, perform content block digest, metadata, permissions, and executability probes; for CPU process memory states, perform system call return and data digest probes; for accelerator tensor states, perform key operator response structure, tensor shape, and numerical error probes; for device queue states, perform device enumeration, request submission, and completion boundary probes; and for external session states, perform reconnection, sequence number continuation, and transaction acknowledgment probes. A probe closure digest is formed only when all required probes for the affected state partitions have been completed.

7. The method as described in claim 1, characterized in that, The entry switch preparation record should include at least the workload identifier, contract version, source checkpoint summary, freeze sequence number, target maximum consecutive sequence number, probe closure summary, migration period, and rollback point. The entry controller will only switch when the above fields are consistent with the target confirmation. When the interface times out and the external status is unclear, it will enter the unknown submission status and read the actual period of the source and target entry. Direct repeated switching is prohibited.

8. A system for managing and adapting heterogeneous computing power in the context of domestic IT innovation, characterized in that... The system includes a resource registration agent, capability probe, contract extractor, state partitioner, checkpoint converter, incremental capturer, target isolation domain, equivalence verifier, entry period barrier, reverse incremental log, rollback controller, and entry controller. Each component is configured to perform the method described in any one of claims 1 to 7. The resource registration agent associates resource management records with resource stability identifiers. The state partitioner selects a direct copy, conversion, reconstruction, or blocking mode according to the state category. The entry period barrier first closes source entry writing and then allows target entry activity. The entry controller submits the migration period only after the incremental sequence number, probe closure digest, and barrier token are consistent. The rollback controller restores the source entry only when the reverse incremental log and external side effects confirm closure.

9. A migration control device, characterized in that, The system includes a processor, a memory, a source resource interface, a target resource interface, and an entry control interface. The memory stores resource management records, workload portability contracts, source format snapshots, and target recovery recipes. When the processor executes the stored program instructions, it implements the method described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing program instructions thereon, characterized in that, When the program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images