Model migration method, system, electronic device, and computer storage medium

Abstract

The application relates to the field of artificial intelligence and hardware acceleration technology, in particular to a model migration method and system, an electronic device and a computer storage medium, the method comprising the following steps: determining a mapping operator and a replacement operator of a to-be-migrated model based on hardware characteristic description information of a target platform, wherein the to-be-migrated model is a model to be migrated to the target platform; obtaining a task type of a calculation task, determining a network structure based on the task type and the hardware characteristic description information, wherein the calculation task is a to-be-executed task input by the to-be-migrated model, and the network structure is used for adapting the to-be-migrated model to the target platform; and deploying the mapping operator and the replacement operator to the target platform through the network structure and the hardware characteristic description information, so as to obtain an executable model adapted to the target platform. The application solves the technical problem of insufficient operator adaptation caused by hardware architecture difference when a model is migrated to an NPU.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and hardware acceleration technology, and in particular to a model transfer method, system, electronic device and computer storage medium. Background Technology

[0002] With the deep application of artificial intelligence technology in the field of autonomous driving, the demand for real-time computing of deep learning models is becoming increasingly urgent. The NPU (Neural Processing Unit) has become the core hardware supporting autonomous driving perception tasks (such as drivable area recognition) due to its efficient parallel computing capabilities.

[0003] Currently, the mainstream approach in the industry is to develop and optimize deep learning models based on the CUDA (Compute Unified Device Architecture) platform, and then directly migrate the models to the NPU platform to run them in order to meet real-time requirements.

[0004] However, this direct migration method faces a key technical bottleneck: different NPU hardware architectures differ significantly, with their parallel computing units, memory pools, dedicated operators, and hierarchical scheduling architectures all differing from the CUDA platform. This makes it difficult to directly migrate model operators, and the operator execution efficiency cannot be fully utilized. This problem directly affects the real-time performance and reliability of autonomous driving perception tasks, and restricts the efficient deployment of deep learning models on the NPU platform. Therefore, it is urgent to solve the problem of insufficient operator adaptation due to hardware architecture differences when migrating models to NPUs. Summary of the Invention

[0005] The main purpose of this application is to provide a model migration method, system, electronic device and computer storage medium, which aims to solve the technical problem of insufficient operator adaptation caused by hardware architecture differences when migrating models to NPU.

[0006] To achieve the above objectives, this application provides a model transfer method, the model transfer method comprising: Based on the hardware characteristic description information of the target platform, the mapping operator and replacement operator of the model to be migrated are determined, wherein the model to be migrated is the model to be migrated to the target platform; The task type of the computing task is obtained, and the network structure is determined based on the task type and the hardware characteristic description information. The computing task is the task to be executed input to the model to be transferred, and the network structure is used to adapt the model to be transferred and the target platform. The mapping operator and the replacement operator are deployed to the target platform using the network structure and the hardware characteristic description information to obtain an executable model adapted to the target platform.

[0007] Furthermore, to achieve the above objectives, this application also provides a model transfer system, the model transfer system comprising: The operator determination module is used to determine the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform; A network customization block is used to determine the network structure based on the task type and the hardware characteristic description information, wherein the computing task is the task to be executed input to the model to be migrated, and the network structure is used to adapt the model to be migrated and the target platform; The model customization module is used to deploy the mapping operator and the replacement operator to the target platform using the network structure and the hardware characteristic description information, so as to obtain an executable model adapted to the target platform.

[0008] In addition, to achieve the above objectives, this application also provides an electronic device, which includes a memory, a processor, and a model migration program stored in the memory and executable on the processor. When the model migration program is executed by the processor, it implements the steps of the above-described model migration method.

[0009] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing a model migration program, which, when executed by a processor, implements the steps of the model migration method described above.

[0010] This application provides a model migration method. Based on the hardware characteristic description information of the target platform, this application performs operator analysis on the model to be migrated, identifies operators that can be directly mapped and operators that must be replaced. Addressing the operator incompatibility issue caused by differences in platform hardware architecture, this method achieves accurate identification and classification at the operator level, laying the foundation for subsequent adaptation. Combining the task type of the computational task to be executed with the hardware characteristic description information, an adapted network structure is generated, solving the problem that the structure of the model to be migrated cannot match the characteristics of the target platform. Through task-driven structure selection, this method ensures that the model framework can fully utilize the hardware potential of the target platform. Based on the determined network structure and hardware characteristic description information, operators are deployed to the target platform, generating an executable model adapted to the target platform. This ensures that the model to be migrated fits the hardware resource configuration of the target platform, laying the foundation for efficient operation and ensuring that the model to be migrated can be executed correctly and efficiently on the target platform. Compared to related solutions that directly migrate the CUDA platform model to the NPU, this application achieves targeted adaptation and optimization from operator recognition and structural adaptation to final deployment through the above method. It overcomes the operator compatibility barriers and performance bottlenecks caused by differences in hardware architecture, and provides an efficient and reliable NPU deployment foundation for real-time perception tasks in fields such as autonomous driving. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating an embodiment of the model transfer method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the model transfer method in this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the model transfer method of this application; Figure 4 This is a schematic diagram of the module structure of the model migration system according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the model migration method in the embodiments of this application.

[0012] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0013] It should be understood that the first embodiment described herein is merely used to explain the technical solution of this application and is not intended to limit this application.

[0014] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0015] The main solution of the first embodiment of this application is as follows: determining the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform; obtaining the task type of the computing task, determining the network structure based on the task type and the hardware characteristic description information, wherein the computing task is the task to be executed input to the model to be migrated, and the network structure is used to adapt the model to be migrated and the target platform; deploying the mapping operator and replacement operator to the target platform through the network structure and the hardware characteristic description information to obtain an executable model adapted to the target platform.

[0016] In the first embodiment, for ease of description, the following description uses the model transfer system as the execution subject.

[0017] Due to significant differences in existing NPU hardware architectures—including parallel computing units, memory pools, dedicated operators, and hierarchical scheduling architectures—comparing them to the CUDA platform, model operators are difficult to directly transfer, hindering the full utilization of operator execution efficiency. This issue directly impacts the real-time performance and reliability of autonomous driving perception tasks, restricting the efficient deployment of deep learning models on NPU platforms.

[0018] This application provides a solution that, based on the hardware characteristic description information of the target platform, performs operator analysis on the model to be migrated, identifies operators that can be directly mapped and those that must be replaced, and achieves accurate identification and classification at the operator level to address operator incompatibility issues caused by differences in platform hardware architecture, laying the foundation for subsequent adaptation. Combining the task type of the computational task to be executed with the hardware characteristic description information, an adapted network structure is generated, solving the problem that the structure of the model to be migrated cannot match the characteristics of the target platform. Through task-driven structure selection, it ensures that the model framework can fully utilize the hardware potential of the target platform. Based on the determined network structure and hardware characteristic description information, operators are deployed to the target platform, generating an executable model adapted to the target platform. This ensures that the model to be migrated fits the hardware resource configuration of the target platform, laying the foundation for efficient operation and ensuring that the model to be migrated can be executed correctly and efficiently on the target platform. Compared to related solutions that directly migrate the CUDA platform model to the NPU, this application achieves targeted adaptation and optimization from operator recognition and structural adaptation to final deployment through the above method. It overcomes the operator compatibility barriers and performance bottlenecks caused by differences in hardware architecture, and provides an efficient and reliable NPU deployment foundation for real-time perception tasks in fields such as autonomous driving.

[0019] It should be noted that the executing entity in the first embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, or other electronic device, or a system, application, or program capable of implementing the above functions. The first embodiment and the following embodiments will be described using a model transfer system as an example.

[0020] All actions involving the acquisition of signals, information, or data in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the owner of the relevant device.

[0021] Based on this, embodiments of this application provide a model transfer method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the model transfer method of this application.

[0022] In this embodiment, the model transfer method includes steps S01 to S03: Step S01: Determine the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform.

[0023] It's important to note that the target platform is the specific computing hardware environment where the model to be migrated is planned to be deployed and run; it represents the endpoint of the migration process. The model to be migrated is the initial deep learning model planned to be migrated from the original development platform (such as CUDA) to the target platform. It includes the complete network structure, weight parameters, and optimization instructions from the original platform, but its operators and structure may not be fully compatible with the hardware architecture of the target platform (e.g., the NPU platform). Hardware characteristic description information is a structured dataset that quantitatively describes the computing and storage capabilities of the target platform.

[0024] In one feasible implementation, steps S101 to S103 are included before the steps in step S01: Step S101: In the absence of hardware characteristic description information on the target platform, execute each test task through each unit and path in the target platform, and generate hardware performance description information of the target platform based on the execution status of each test task.

[0025] It should be noted that the test tasks are a series of pre-defined, standardized computational programs used to probe hardware performance. These programs stress-test and calibrate the performance of various computing and storage units on the target platform. For example, they might perform matrix multiplication and convolution operations on different sizes (e.g., 32x32, 128x128) to measure the peak computing power and efficiency of the computing units, or execute specific modes of memory read / write operations to measure the bandwidth and access latency of different storage tiers. Execution status refers to the quantified performance data collected after the test tasks run on the target platform, which may include the execution time, throughput characteristics, and storage access latency of each task. Hardware performance description information is a performance model dataset formed by structured organization and analysis of the execution status data, used to describe the inherent computing and storage capabilities of the target platform.

[0026] Additionally, it should be noted that the target platform can accept the migration of different models to be migrated. In each migration process, the structure or type of the model to be migrated can be the same or similar. By determining whether the target platform has reusable hardware feature description information, the hardware feature description information can be directly reused when the model to be migrated is migrated without regenerating it, thus improving processing efficiency.

[0027] Step S102: Determine the operator type of the platform operator in the target platform and obtain the operator characteristic description information. It should be noted that platform operators refer to basic computational operations that are natively supported by the target hardware platform and can be directly invoked and executed. Operator type is a classification identifier for operators, defining their mathematical semantics and invocation format. Operator characteristic description information is a collection of descriptive data about the characteristics of operators combined with hardware, formed after platform operator parsing. It mainly includes an operator support list and operator execution constraints. The operator support list includes operator types supported and unsupported by the target platform. Operator execution constraints record the execution details of supported operators on specific hardware. For example, the MatMul (Matrix Multiplication) operator is only supported on Vector Units and requires 8-byte alignment of the input matrix dimensions.

[0028] Step S103: Use the hardware performance description information and the operator characteristic description information as the hardware characteristic description information of the target platform.

[0029] It should be noted that the hardware characteristic description information is composed of hardware performance description information and operator characteristic description information, and is a comprehensive set of higher-level information.

[0030] For example, in the initialization phase of the model migration process, the existence of reusable hardware characteristic description information on the target platform is first checked. If not, a hardware characteristic detection and analysis process is executed: a series of pre-defined test tasks are run on the target platform (e.g., an NPU platform). These test tasks cover different computational scales and types, such as matrix multiplication and convolution tests for CubeUnits (tensor computation units), and read / write latency and bandwidth tests for Vector Units and storage levels (e.g., on-chip memory). By executing these test tasks, hardware performance description information can be collected and generated, which quantitatively records key performance parameters such as execution time, throughput characteristics, and storage access latency of each computational unit for test tasks of different scales. At the same time, by parsing the target platform's driver API (Application Programming Interface) or firmware information, a list of platform operator types natively supported by the platform and the execution constraints of each operator are obtained, forming operator characteristic description information. Finally, the hardware performance description information and the operator characteristic description information are merged to form a complete target platform hardware characteristic description information that can be reused for subsequent migration tasks.

[0031] In one feasible implementation, step S01 includes step S011: Step S011: Based on the operator characteristic description information in the hardware characteristic description information, the mapping operator and the replacement operator are selected from the model operators of the model to be transferred. The mapping operator is the operator in each model operator that matches the operator type of the platform operator, and the replacement operator is the operator in each model operator that does not match the operator type of the platform operator.

[0032] It should be noted that model operators refer to the computational nodes contained in the model to be transferred. Each node represents a specific mathematical operation and is a component of the model's functionality.

[0033] For example, after obtaining the hardware characteristic description information, the computation graph of the model to be transferred is traversed and parsed, and each model operator is checked in turn. For each model operator, its operator type is matched with the operator support list in the operator characteristic description information. For example, if a "Conv2D (two-dimensional convolutional layer)" operator in the model matches the "Conv2D" type in the list, and its parameters (such as convolutional kernel size and stride) meet the constraints of the target platform, then the operator is selected as a mapping operator. Conversely, if the model operator in the model to be transferred does not have a corresponding item in the operator support list, then the operator is selected as a replacement operator.

[0034] Understandably, step S01 analyzes and distinguishes between directly mappable operators and operators that need to be replaced in the model to be migrated based on the hardware characteristic description information of the target platform. In response to the problem in the prior art that operators are difficult to migrate directly due to the mismatch between the operator sets of NPU and CUDA platform, it achieves accurate identification and classification of operator granularity, clarifies the components in the model that are friendly to the target platform and incompatible, provides clear input for subsequent targeted processing, and avoids operator execution errors or anomalies caused by blind migration.

[0035] Step S02: Obtain the task type of the computation task, and determine the network structure based on the task type and hardware characteristic description information. The computation task is the task to be executed as input to the model to be transferred, and the network structure is used to adapt the model to be transferred and the target platform.

[0036] It should be noted that mapping operators are operator types in the model to be transferred that are completely matched with the operators supported by the target platform. Replacement operators are operators in the model to be transferred that are not supported by the target platform. The computational task, also known as the task to be executed, is the specific artificial intelligence problem that the model to be transferred needs to solve. It can be an autonomous driving perception task, such as navigable area recognition, or other types of tasks, which will not be elaborated on here.

[0037] Additionally, it should be noted that the task type of a computation task can be obtained by parsing the task's configuration file. Specifically, the system pre-defines a task type registry, which associates general perception task categories (such as image classification, object detection, semantic segmentation, instance segmentation, etc.) with a series of feature descriptors (such as output data structure, evaluation metrics, and typical application scenarios). When a computation task starts, the system reads the task's configuration file, retrieves the feature descriptors from it, and matches them with the task type registry to determine the task type.

[0038] Additionally, it should be noted that the system has a pre-set task-network matching library, which stores the mapping relationship between basic networks for task types. Therefore, after obtaining the task type, the corresponding basic network can also be obtained. For example, image recognition tasks are suitable for applying CNN (Convolutional Neural Network), and text recognition tasks are suitable for applying Transformer, etc.

[0039] In one feasible implementation, step S02, the step of determining the network structure based on task type and hardware characteristic description information, includes steps S021-S023: Step S021: Use the base network corresponding to the task type as the initial network of the model to be transferred.

[0040] It should be noted that the base network is a predefined, general neural network architecture template that matches a specific task type. The initial network refers to the initial instance formed when the selected base network is used as a blueprint and applied to the specific model to be transferred. It carries the topology of the base network but has not yet been optimized for hardware parameters.

[0041] Step S022: Determine the parallelism, memory capacity constraints, and unit characteristics of each computing unit in the target platform based on the hardware characteristic description information.

[0042] It should be noted that parallelism refers to the quantitative representation of the ability of computing units in a target platform to execute computing tasks simultaneously, such as the number of computing units, their organization, and the depth of parallel execution in the pipeline. Memory capacity constraints refer to the limitations of the target platform's on-chip memory pool or cache levels on the total amount of data that can reside simultaneously. Unit characteristics refer to the optimized support characteristics of a computing unit for different computing modes or data types. For example, a certain NPU's Cube Unit has specialized circuit optimizations and the highest instruction throughput for 3x3 convolution kernels, while its efficiency is relatively low for 5x5 convolutions. This characteristic determines which computing configuration can achieve peak performance on that unit.

[0043] Step S023: Adjust the number of network layers in the initial network based on parallelism, adjust the number of channel nodes in each network layer in the initial network based on memory capacity constraints, and adjust the convolution kernel size of the initial network based on unit characteristics to obtain the network structure.

[0044] It's important to clarify that the number of network layers refers to the total number of adjustable layers with computational transformation capabilities in the initial network (such as the number of convolutional layers and fully connected layers), while a network layer refers to any specific layer in the initial network. The number of channels refers to the number of channels in the feature map of a network layer, also known as the network width. It determines the number of network layer parameters and the amount of output data. Adjusting the number of channels controls the memory usage and computational load of each layer to meet the memory capacity constraints of the target platform. The kernel size refers to the spatial size of the filters in a convolutional layer (such as 3x3, 5x5). Different kernel sizes directly affect computational complexity, receptive field, and the execution efficiency of specific computational units. Adjusting the kernel size aims to align it with the optimal execution characteristics of the computational units. The network structure refers to the final network form determined after adjusting various parameters. It not only retains the functional topology of the basic network but also adapts to the computing power, memory, and unit characteristics of the target hardware platform in terms of the number of layers, width, and kernel size. For example, a variant of SegNet, SegNet is a deep convolutional neural network (CNN) architecture.

[0045] It is understandable that step S02, by obtaining the task type of the computing task and determining the appropriate network structure based on this type and hardware characteristic description information, solves the problem that the static and general model architecture in the prior art cannot fully utilize specific NPU computing units and is limited by their memory pool capacity. Through the collaborative design of task orientation and hardware constraints, the determined network structure functionally meets the task requirements and matches the parallel computing characteristics and storage resource boundaries of the target platform, laying a structural foundation for achieving efficient execution.

[0046] Step S03: Deploy the mapping operator and the replacement operator to the target platform using the network structure and hardware characteristic description information to obtain an executable model adapted to the target platform.

[0047] It should be noted that task type is an abstract classification of the technical category to which the computational task belongs. For example, traversable region recognition belongs to the image semantic segmentation task type. Network structure is the model skeleton obtained by parametrically adjusting the basic network architecture paradigm to adapt to the target platform. The executable model is the final product that can be directly loaded and efficiently run on the target NPU. It is not simply a format conversion file, but a deeply customized model instance that includes the adapted network structure, optimized weights, execution code optimized for the target platform's instruction set, deployment configuration files, the mapping relationship between tasks and computational units, memory allocation schemes, and scheduling strategies.

[0048] For example, taking the autonomous driving passable area recognition task as an example, the operators (including mapping operators and replacement operators) in each layer of the network structure are analyzed. Based on the computing unit performance data in the hardware characteristic description information of the target NPU platform (such as the Cube Unit having the best throughput for 3x3 convolution) and the list of natively supported operators, the standard Conv2D operators in the network structure are directly mapped and bound to the Cube Unit for execution, and the MatMul operator is bound to the Vector Unit. For operators in the structure that are not directly supported by the platform (i.e., replacement operators), alternative designs can be made according to the principle of "functional equivalence first, execution continuity first". For example, the replacement operator is Swish, and Swish is defined as x The sigmoid(x) function is an S-shaped function that maps any real number to the interval (0,1). It can be equivalently replaced by a combination of operators supported by the target NPU platform: the sigmoid operator and a multiplication operator (which can be implemented by vector multiplication in the Vector Unit) to reconstruct the function. At the same time, in order to reduce the transfer of intermediate data between storage levels, the replaced sigmoid operator and multiplication operation can be scheduled and coordinated with the preceding Conv2D operator to be executed near the same computing unit, thereby avoiding the introduction of significant additional memory access overhead and scheduling latency.

[0049] Understandably, step S03 comprehensively utilizes the determined network structure and hardware characteristic description information to deploy the mapping operator and replacement operator to the target platform, generating the final executable model. This overcomes the shortcomings of existing technologies that only perform simple format conversion or interface encapsulation without achieving deep adaptation of the underlying execution logic. It ensures that each operator can be executed in an optimized manner on the most suitable computing unit, enabling the generated executable model to fully utilize the hardware computing power of the NPU and ultimately improve the real-time performance and reliability of autonomous driving perception tasks.

[0050] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The model transfer method also includes steps S11 to S13: Step S11: During the execution of the computing task, the task feature vector of the computing task and the resource status vector of the target platform are acquired in real time.

[0051] It should be noted that the task feature vector is a structured and quantified mathematical representation of the computational requirements of a computing task. It is a multi-dimensional vector whose dimensions encode the key performance characteristics of the task. For example, for a passable area identification task, this vector may contain quantified values ​​for the following dimensions: the total number of floating-point operations required by the task (reflecting computational complexity), the total amount of data to be read from and written to memory during task execution (reflecting memory bandwidth requirements), and the maximum allowed end-to-end processing latency (reflecting real-time constraints). The resource status vector is a dynamic snapshot of the current internal resource usage and load status of the target platform. It is also a multi-dimensional vector, generated in real time through the platform monitoring interface. For example, for a passable area identification task, this vector may contain quantified values ​​for the following dimensions: the current utilization percentage of each computing unit (such as multiple Cube Units and Vector Units), the utilization and bandwidth usage of memory at all levels (such as on-chip cache and memory pool), and the current power consumption of the computing unit.

[0052] Step S12: Based on the task feature vector and resource state vector, the computation task is assigned to the computation unit in the executable model and executed.

[0053] For example, taking the task of real-time navigable area identification by an autonomous vehicle as an example, the task feature vector of the current image frame is analyzed, which contains high computational complexity and strict real-time constraints. At the same time, the monitoring interface collects the resource status vector of the target platform, showing that Cube Unit A is under high load while Cube Unit B has low utilization. Based on the above vector analysis, it is determined that the convolution calculation subtask in the current task can be split. Therefore, the batch of tasks is dynamically allocated to the Cube Unit B with lower load for execution and configured with higher execution priority. After the task completes the calculation on Cube Unit B, the result is sent back to the unified memory pool for subsequent processing. At the same time, the vector status continues to be monitored to provide a basis for the next round of scheduling.

[0054] Additionally, it should be noted that the allocation strategy for computing tasks is a custom scheduling logic, which can be implemented based on existing scheduling ideas, but is not limited to a specific algorithm form, and will not be elaborated on here.

[0055] Step S13: If the executable model is under resource constraints, perform a fusion operation on each operator in the executable model, or perform a compression operation on the executable model.

[0056] It should be noted that fusion operation optimizes performance by changing the execution organization of the corresponding computation graph on the hardware without altering the mathematical function of the executable model. The core is to merge multiple consecutive, data-dependent basic operators in the computation graph into a single composite operator kernel. For example, in a CNN model, convolution, batch normalization, and activation functions (Conv, BN, ReLU) often appear sequentially. The fusion operation replaces these three independent operator calls with a single "Conv-BN-ReLU" fusion kernel, completing all calculations consecutively on a single computational unit. This avoids the overhead of writing intermediate results back to main memory and then reading them again, thus significantly reducing memory access latency and bandwidth pressure.

[0057] For example, when performing a fusion operation, it is necessary to first parse the computation graph of the executable model, identify the continuous operator sequences that conform to the preset fusion pattern, such as the "convolution-batch normalization-activation function" pattern in a convolutional neural network. Based on the hardware characteristic description information of the target platform, a benefit and constraint analysis is performed on each identified fusion operation, and the expected reduction in memory usage (such as intermediate data memory access counts and kernel startup overhead) of the executable model after fusion is quantitatively evaluated. If the reduction in memory usage is higher than the preset data amount, the benefit of the fusion operation is determined to be significant, and it is verified whether the fused executable model meets the preset hardware limitations. For example, the number of registers in the computing unit, the size of shared memory, etc. After confirming that the benefits of the fusion operation are significant and that the fused executable model meets the preset hardware constraints (i.e., meets the constraints), the computational logic of multiple operators is merged into a single composite operator, and the code template or just-in-time compilation technology pre-built for the target platform is called to generate the corresponding optimized kernel code. At the same time, the computation graph structure is adjusted, and the original series of independent operator nodes are replaced with the composite operator node. In the generated kernel code, the registers of the computing unit or the on-chip cache are used first to temporarily store intermediate computation results based on the hardware characteristic description information, thereby minimizing the frequency of access to global memory and the amount of data moved.

[0058] Additionally, it should be noted that compression operations reduce the computational, storage, and bandwidth requirements of the executable model by decreasing the number of parameters or the computational precision of the executable model itself. For example, when memory resources are continuously strained, the strength of the quantization strategy can be dynamically increased, such as switching the activation values ​​of some layers in the model from INT8 (8-bit Integer) quantization to the more aggressive INT4 (4-bit Integer) representation, in order to reduce memory usage and bandwidth consumption. Conversely, if a decrease in precision is detected, the quantization bit width can be dynamically rolled back.

[0059] Additionally, it should be noted that resource constraints in executable models include memory bottlenecks and scheduling conflicts. Memory bottlenecks refer to the phenomenon where system performance is limited due to insufficient memory resources or inefficient access. Scheduling conflicts refer to performance degradation or task delays caused by resource contention or inappropriate scheduling strategies during resource allocation in a multi-tasking or multi-threaded environment.

[0060] For example, a memory bottleneck can be triggered by the following conditions, and the existence of a memory bottleneck is determined when any at least one of them is met: 1. Memory bandwidth saturation ≥ 85%, where memory bandwidth saturation can be calculated by dividing the actual memory bandwidth by the theoretical peak bandwidth; 2. If a task's idle computing unit time due to waiting for data loading exceeds 30%, it will lead to memory capacity pressure. 3. If the available memory capacity is less than 15% of the total capacity, it will lead to frequent memory paging. 4. Poor caching efficiency, such as L1 / L2 cache hit rate <70%, where L1 is the Level 1 cache and L2 is the Level 2 cache, or memory access latency exceeding 200% of the average. 4. Memory access pattern issues, such as cross-NUMA (Non-Uniform Memory Access) node access ratio >40%, or memory access locality score <0.3.

[0061] Scheduling conflicts can be triggered by the following conditions, and a scheduling conflict is determined to exist if any at least one of them is met: 1. Resource contention, such as when the same computing unit is requested by more than 3 tasks, or when the waiting queue length for critical resources is greater than 5. Critical resources can be HBM (High Bandwidth Memory). 2. Dependency violation, such as a task being unable to start due to a prerequisite dependency, with a delay greater than 20% of the deadline, which can easily lead to the risk of data dependency loops; 3. Real-time performance violation, such as delays exceeding 150% of the SLA (Service Level Agreement) requirement, in which case the estimated task completion time is greater than the deadline (considering the worst-case scenario). 4. Uneven load, such as computing unit utilization standard deviation > 25%, or high priority task waiting time > low priority task execution time.

[0062] In this embodiment, by collecting task feature vectors and platform resource status vectors in real time, quantitative perception of computing needs and precise monitoring of hardware status are achieved, solving the shortcoming that static deployment cannot adapt to runtime changes. Based on this, dynamic task allocation is performed to ensure that operators are continuously matched to the optimal computing unit, thereby maintaining the efficiency of operator execution without decay under high load. When resource shortage is detected, operator fusion or model compression operations are automatically triggered to alleviate the latency increase caused by memory bandwidth bottlenecks or computing resource contention. By optimizing the computation graph and model size in real time, the real-time performance and stability of task execution are guaranteed within hardware constraints.

[0063] In one feasible implementation, after obtaining the executable model adapted to the target platform in step S03, steps S031 to S033 are further included: Step S031: During the execution of the executable model, monitor the memory usage and inference latency of the executable model. If the memory usage increases or the inference latency increases, enhance the compression operation intensity of the executable model.

[0064] It should be noted that memory usage refers to the real-time storage capacity occupied by the executable model in the target platform's storage system, such as model weights, activation feature maps, and intermediate data. Inference latency refers to the computation time required for the executable model to process a single input data and generate an output; it is a key indicator for measuring real-time performance. Compression intensity is an adjustable parameter used to control the strength of compression techniques such as pruning rate, quantization bit width, or low-rank decomposition degree; for example, increasing weight quantization from INT8 to INT4.

[0065] Step S032: Monitor the perception accuracy of the executable model on the computation task. If the perception accuracy shows a downward trend, reduce the intensity of the compression operation of the executable model.

[0066] It should be noted that perception accuracy refers to the output accuracy of the executable model in computational tasks (such as navigable area identification), which can be quantified by metrics such as IoU (Intersection over Union) and accuracy.

[0067] Step S033: Perform a compression operation on the executable model based on the compression operation intensity, wherein the compression operation is used to reduce the resource consumption of the executable model.

[0068] For example, during the continuous operation of an autonomous vehicle in an urban road scenario, the system initially loads an executable model adapted to the NPU. When the vehicle enters a dense traffic area, the system detects that the executable model's memory usage rate increases from 70% to 85% due to processing more targets, and the inference latency increases accordingly. Therefore, the weight quantization strategy is enhanced from partial layer INT8 to full network INT8. At the same time, it detects that the model's recognition rate (perception accuracy) for small obstacles at a distance begins to decline, and it is inferred that this may be related to over-quantization. Therefore, the quantization strategy is automatically reverted to the key layer FP16 (Half Precision Floating Point, 16-bit floating point), and the remaining layers are in a mixed precision state of INT8.

[0069] Additionally, it should be noted that when memory usage increases, inference latency increases, and perception accuracy decreases simultaneously, a multi-objective collaborative decision-making process is triggered: First, it is assessed whether the perception accuracy is below a preset safety threshold. If it is below the preset safety threshold, instructions to reduce the intensity of compression operations are generated and executed to prioritize the functional effectiveness of the executable model. At the same time, the main sources of memory usage and inference latency are analyzed, and differentiated resource optimization strategies are initiated: for example, preset types of compression operations (such as selective channel pruning or non-uniform quantization) are enabled for non-core layers in the model, or the scheduling order of operators is adjusted to reduce peak memory usage, aiming to effectively alleviate memory resource pressure without exacerbating accuracy loss. When the perception accuracy is not lower than the preset safety threshold, instructions to enhance the compression operation intensity to a limited extent are generated and executed. Priority is given to network layers with high redundancy or little impact on the perception accuracy of the current task in the executable model, and small-amplitude, structured compression operations are performed, such as pruning specific channels or using low-bit-width quantization in non-critical layers. While performing such enhancement operations, auxiliary resource optimization strategies are launched in parallel, such as adjusting the execution timing of operators in the computation graph to smooth memory access peaks, or fusing operators with non-contiguous memory accesses to reduce scheduling overhead.

[0070] In this implementation, by monitoring memory usage and inference latency in real time and increasing compression intensity when these values ​​increase, the latency degradation caused by memory bandwidth bottlenecks or computing resource contention is alleviated, ensuring real-time performance. Simultaneously monitoring perception accuracy and reducing compression intensity when it decreases ensures that the model's functional effectiveness is not compromised by excessive compression. The compression operation performed based on this dynamic balancing mechanism can continuously optimize the model size and computational load according to the actual hardware operating status, thereby significantly reducing the model's occupation of the target platform's limited memory and computing resources while maintaining perception accuracy, and improving the long-term operational stability and efficiency of the deployed model.

[0071] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and second embodiments described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 The model transfer method also includes steps S21 to S24: Step S21: Collect the current running status of the executable model and determine whether the current running status is similar to the historical running status in the historical running data.

[0072] It should be noted that the current running state refers to the set of performance metrics exhibited by the executable model at any given moment on the target platform. This state is a multi-dimensional vector and may include overall model inference latency, utilization of each computing unit, on-chip memory usage, memory bandwidth utilization, and power consumption. Historical running data stores the historical running states collected during past system operations and the optimization strategies configured and validated under those states. Historical running states are essentially running state vectors recorded at a specific point in the past, stored within the historical running data.

[0073] Step S22: If the current running state matches the historical running state, adjust the executable model based on the operator scheduling method, resource allocation strategy, and model compression configuration in the historical running data.

[0074] It should be noted that the operator scheduling method is a specific scheme for allocating and binding each computational operator in the executable model to a specific computational unit (such as a Cube Unit or Vector Unit) on the target platform, as well as priority rules that determine the execution order of each operator. The resource allocation strategy is the data layout planning performed in the memory hierarchy of the target platform to support the execution of the executable model. This includes the physical memory address space allocated to each layer's feature map and weights, caching strategies, and triggering conditions for task migration between different computational units. The model compression configuration is a combination of a series of compression algorithms and their strength parameters applied to the executable model. This may include the global network weight pruning rate, the target bit width for weight quantization in each layer, whether activation value quantization is enabled and its bit width, and whether low-rank decomposition is performed on specific convolutional layers and the size of its rank.

[0075] Step S23: When the current running state does not match the historical running state, evaluate the impact of the change in the current running state on the executable model.

[0076] For example, when it is determined that the current operating state does not match the historical operating state, the key quantitative indicators of the current operating state are first extracted, including the overall model inference latency, utilization of each computing unit, memory usage, and power consumption data. These key quantitative indicators are then compared with their corresponding preset performance health ranges. If one or more key indicators continuously deviate from their preset performance health ranges (for example, latency exceeds the tolerance limit for three consecutive monitoring cycles, or computing unit utilization remains below the efficiency limit), it is determined that the change has a negative impact on the execution efficiency or resource utilization efficiency of the executable model.

[0077] Step S24: When the current running state has a negative impact on the executable model, optimize and adjust the operator scheduling method, resource allocation strategy and model compression configuration of the executable model, and take the running state before and after the adjustment as the historical running state, and take the historical running state and the corresponding operator scheduling method, resource allocation strategy and model compression configuration as historical running data.

[0078] It should be noted that negative impacts refer to situations where changes in the current operating state (such as continuously increasing latency, memory usage approaching the limit, or severely uneven utilization of computing units) cause the executable model to fail to meet preset performance targets (such as real-time requirements) or threaten the stable operation of the system (such as being on the verge of memory overflow).

[0079] For example, the current running status is collected and compared with records in the historical running database. When a highly similar historical status is found (e.g., the proportion of the same indicator in the performance indicator set reaches a preset proportion), the optimized configuration (including operator scheduling, resource allocation and compression strategies) that has been verified and effective in that historical status is directly loaded and applied, thereby avoiding repeated trial optimizations and quickly stabilizing performance. If a new running status is encountered, its potential impact is evaluated. When it is determined to be a negative impact (such as increased latency or decreased accuracy), the strategy optimization engine is triggered to re-search and adjust the scheduling, allocation and compression configurations. After the adjustment is completed, the complete experience of this "new status-new strategy-new effect" is stored as a new record in the historical database to realize the continuous expansion of the knowledge base.

[0080] For example, in autonomous driving scenarios, when a vehicle first enters a city road at night from a daytime highway, the system considers it a "mismatch" state. The assessment finds that the inference latency has increased, and then the system automatically adjusts the task priority and quantization strategy. After successful optimization, this "city road at night" state and its corresponding strategy are stored, and can be quickly recalled when encountering similar scenarios in the future. This enables the system to have the ability to autonomously adapt to various scenarios and maintain performance robustness in long-term operation.

[0081] In this implementation, experience-driven dynamic adaptation is achieved by collecting and comparing the running status in real time. When the current status is similar to the historical status, the verified operator scheduling, resource allocation and compression configuration are directly applied, avoiding the overhead of repeated optimization caused by differences in the target platform hardware and improving the adjustment efficiency. When the status is mismatched and evaluated as a negative impact, the model configuration is automatically optimized and historical data is updated, so that the model can continuously adapt to the dynamic running environment of the target platform. This effectively alleviates the fluctuation of operator execution efficiency and performance degradation caused by differences in hardware architecture and enhances the stability and reliability of the model in long-term operation.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the model transfer method of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0083] This application also provides a model transfer system; please refer to [link / reference]. Figure 4 The model transfer system includes: The operator determination module 10 is used to determine the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform. The network customization module 20 is used to determine the network structure based on the task type and hardware characteristic description information. The computation task is the task to be executed as input to the model to be transferred, and the network structure is used to adapt the model to be transferred and the target platform. The model customization module 30 is used to deploy the mapping operator and the replacement operator to the target platform through network structure and hardware characteristic description information, so as to obtain an executable model adapted to the target platform.

[0084] The model migration system provided in this application, employing the model migration method described in the above embodiments, can solve the technical problem of insufficient operator adaptation caused by hardware architecture differences when migrating a model to an NPU. Compared with the prior art, the beneficial effects of the model migration system provided in this application are the same as those of the model migration method provided in the above embodiments, and other technical features of the model migration system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0085] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the model transfer method in Embodiment 1 above.

[0086] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, PADs (Portable Application Description: Tablet PCs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0087] like Figure 5As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0088] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0089] The electronic device provided in this application, employing the model migration method described in the above embodiments, can solve the technical problem of insufficient operator adaptation caused by hardware architecture differences during model migration to the NPU. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the model migration method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0090] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0091] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0092] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the model transfer method in the above embodiments.

[0093] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0094] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0095] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an electronic device, the model migration device: determines the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform; obtains the task type of the computation task, determines the network structure based on the task type and the hardware characteristic description information, wherein the computation task is the task to be executed input to the model to be migrated, and the network structure is used to adapt the model to be migrated and the target platform; and deploys the mapping operator and replacement operator to the target platform through the network structure and the hardware characteristic description information to obtain an executable model adapted to the target platform.

[0096] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0098] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0099] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described model migration method. This solves the technical problem of insufficient operator adaptation due to hardware architecture differences during model migration to the NPU. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the model migration method provided in the above embodiments, and will not be elaborated upon here.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the model transfer method described above.

[0101] The computer program product provided in this application can solve the technical problem of insufficient operator adaptation caused by hardware architecture differences when migrating models to NPUs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the model migration method provided in the above embodiments, and will not be repeated here.

[0102] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A model transfer method, characterized in that, The model transfer method includes: Based on the hardware characteristic description information of the target platform, the mapping operator and replacement operator of the model to be migrated are determined, wherein the model to be migrated is the model to be migrated to the target platform; The task type of the computing task is obtained, and the network structure is determined based on the task type and the hardware characteristic description information. The computing task is the task to be executed input to the model to be transferred, and the network structure is used to adapt the model to be transferred and the target platform. The mapping operator and the replacement operator are deployed to the target platform using the network structure and the hardware characteristic description information to obtain an executable model adapted to the target platform.

2. The model transfer method as described in claim 1, characterized in that, Before the step of determining the mapping operator and replacement operator of the model to be transferred based on the hardware characteristic description information of the target platform, the following steps are also included: In the absence of hardware characteristic description information on the target platform, each test task is executed through each unit and path in the target platform, and hardware performance description information of the target platform is generated based on the execution status of each test task. Determine the operator type of the platform operator in the target platform to obtain operator characteristic description information; The hardware performance description information and the operator characteristic description information are used as the hardware characteristic description information of the target platform.

3. The model transfer method as described in claim 2, characterized in that, The steps for determining the mapping operator and replacement operator of the model to be transferred based on the hardware characteristic description information of the target platform include: Based on the operator characteristic description information in the hardware characteristic description information, mapping operators and replacement operators are selected from each model operator of the model to be migrated. The mapping operator is the operator in each model operator that matches the operator type of the platform operator, and the replacement operator is the operator in each model operator that does not match the operator type of the platform operator.

4. The model transfer method as described in claim 1, characterized in that, The step of determining the network structure based on the task type and the hardware characteristic description information includes: The base network corresponding to the task type is used as the initial network of the model to be transferred; The parallelism, memory capacity constraints, and unit characteristics of each computing unit in the target platform are determined based on the hardware characteristic description information. The number of network layers in the initial network is adjusted based on the parallelism, the number of channel nodes in each network layer in the initial network is adjusted based on the memory capacity constraint, and the convolution kernel size of the initial network is adjusted based on the unit characteristics to obtain the network structure.

5. The model transfer method as described in claim 1, characterized in that, The model transfer method also includes: During the execution of the computing task, the task feature vector of the computing task and the resource status vector of the target platform are acquired in real time. Based on the task feature vector and the resource state vector, the computing task is assigned to the computing unit in the executable model and executed; If the executable model is experiencing resource constraints, a fusion operation is performed on each operator in the executable model, or a compression operation is performed on the executable model.

6. The model transfer method as described in claim 1, characterized in that, The step of obtaining an executable model adapted to the target platform further includes: During the execution of the executable model, the memory usage and inference latency of the executable model are monitored. If the memory usage increases or the inference latency increases, the compression operation intensity of the executable model is enhanced. Monitor the perception accuracy of the executable model on the computing task, and reduce the intensity of the compression operation of the executable model when the perception accuracy shows a downward trend; The executable model is compressed based on the compression operation intensity, wherein the compression operation is used to reduce the resource consumption of the executable model.

7. The model transfer method as described in claim 1, characterized in that, The model transfer method also includes: Collect the current running state of the executable model and determine whether the current running state is similar to the historical running state in the historical running data; If the current running state matches the historical running state, the executable model is adjusted based on the operator scheduling method, resource allocation strategy, and model compression configuration in the historical running data; If the current running state does not match the historical running state, evaluate the impact of the change in the current running state on the executable model; If the current running state has a negative impact on the executable model, the operator scheduling method, resource allocation strategy, and model compression configuration of the executable model are optimized and adjusted, and the running state before and after the adjustment is taken as the historical running state. The historical running state and the corresponding operator scheduling method, resource allocation strategy, and model compression configuration are taken as historical running data.

8. A model transfer system, characterized in that, The model transfer system includes: The operator determination module is used to determine the mapping operator and replacement operator of the model to be migrated based on the hardware characteristic description information of the target platform, wherein the model to be migrated is the model to be migrated to the target platform; A network customization block is used to determine the network structure based on the task type and the hardware characteristic description information, wherein the computing task is the task to be executed input to the model to be migrated, and the network structure is used to adapt the model to be migrated and the target platform; The model customization module is used to deploy the mapping operator and the replacement operator to the target platform using the network structure and the hardware characteristic description information, so as to obtain an executable model adapted to the target platform.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a model migration program stored in the memory that can be executed by the processor, wherein when the model migration program is executed by the processor, it implements the steps of the model migration method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer storage medium stores a model migration program, wherein when the model migration program is executed by a processor, it implements the steps of the model migration method as described in any one of claims 1 to 7.

Images