Model migration method and apparatus

Abstract

The application relates to the technical field of data processing, and provides a model migration method and device. The method comprises the following steps: determining the hardware difference degree of a source device and a target device according to the difference degree of hardware configuration parameters of a same hardware configuration item between hardware configuration information of the source device and the target device, so as to obtain a migration parameter set corresponding to a model migration strategy from a target model deployed on the source device according to the model migration strategy corresponding to the hardware difference degree, and then transmit the migration parameter set to the target device, so that the target device deploys the target model according to the migration parameter set. The model migration method provided in the application can improve the migration efficiency of the model.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a model transfer method and apparatus. Background Technology

[0002] With the development of technology, more and more devices are deployed with models to assist in task processing and improve task efficiency. In order to reuse the general knowledge of a model trained on a source device to a target device, model transfer is usually required. This involves transferring the model parameters from the source device to the target device to save the training time of the model deployed on the target device and the computing resources of the target device.

[0003] In related technologies, model migration involves transferring all model parameters from the source device to the target device. However, this method requires transferring a large number of parameters. If applied to all model migration scenarios, and given the limited hardware resources of the target device, it can easily lead to a sharp increase in transmission latency or even migration failure, thus affecting the model migration efficiency. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in related technologies. To this end, this application proposes a model transfer method that can improve the transfer efficiency of models.

[0005] The model transfer method according to the first aspect of this application, applied to a source device, includes: The hardware difference between the source device and the target device is determined based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. Based on the hardware differences, determine the corresponding model migration strategy; According to the model migration strategy, obtain the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device; The migration parameter set is transmitted to the target device so that the target device deploys the target model according to the migration parameter set.

[0006] By determining the hardware differences between the source and target devices based on their hardware configuration information, and then using a model migration strategy corresponding to these differences, a migration parameter set corresponding to the migration strategy is obtained from the target model deployed on the source device and transmitted to the target device. This allows the target device to deploy the target model based on the migration parameter set. This approach flexibly selects the amount of parameters to be transmitted based on the hardware differences between the source and target devices, effectively reducing the risk of sudden increases in transmission latency or migration failures due to excessive parameter transmission when the target device's hardware resources are limited. Consequently, it reduces dependence on the target device's hardware resources and improves model migration efficiency.

[0007] According to one embodiment of this application, determining the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device includes: The system determines that the identity authentication of the target device has been successful and receives authentication information indicating that the target device has successfully authenticated the identity of the source device. Based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device, the system determines the hardware difference between the source device and the target device.

[0008] According to one embodiment of this application, determining the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device includes: Based on the hardware configuration information of the source device and the target device, the degree of difference of the hardware configuration item is determined for the same hardware configuration parameter. Based on the preset weights of each hardware configuration item, the degree of difference between each hardware configuration item is weighted to determine the degree of hardware difference between the source device and the target device.

[0009] According to one embodiment of this application, determining the corresponding model migration strategy based on the hardware differences includes: The corresponding migration score is determined by weighting the hardware differences, the obtained transmission load rate, and the latency ratio. Based on the migration score, the corresponding model migration strategy is determined; The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration, and the amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

[0010] According to one embodiment of this application, obtaining a migration parameter set corresponding to the model migration strategy from the target model deployed on the source device according to the model migration strategy includes: If the model migration strategy is determined to be a core parameter migration strategy, at least one target network layer is determined from each network layer based on the importance evaluation parameters of each network layer in the target model. The migration parameter set is obtained based on the parameters of each target network layer; The importance evaluation parameters include at least one of the following: the proportion of parameters in the network layer, the contribution of the network layer to the output accuracy of the target model, and the parameter update frequency of the network layer. The percentage of parameters in the network layer is determined based on the number of parameters in the network layer and the total number of parameters in the target model.

[0011] According to one embodiment of this application, determining at least one target network layer from the network layers based on the importance evaluation parameters of any network layer in the target model includes: The importance score of a network layer is determined based on the importance evaluation parameters of any network layer in the target model. Based on the importance score of each network layer, the target network layer is selected sequentially from the network layers in descending order of importance score, until the total number of parameters of each target network layer is within a preset range; The preset range is determined based on the total number of parameters of the target model and a preset ratio range, and the preset ratio range is positively correlated with the current available bandwidth.

[0012] According to one embodiment of this application, transmitting the migration parameter set to the target device includes: The migration parameter set is encrypted to obtain encrypted data; The encrypted data and a first hash digest generated from the migration parameter set are transmitted to the target device, and the first hash digest is registered with a third-party device to obtain a second hash digest stored in the third-party device. The target device then verifies the migration parameter set based on the comparison result between the first hash digest and the second hash digest and the third hash digest generated from the migration parameter set obtained from the encrypted data.

[0013] According to one embodiment of this application, it also includes: During the process of transmitting the migration parameter set to the target device, the received service requests are processed according to the service instance generated by the target model, the current processing status of the service requests is recorded, and the current processing status is synchronized to the target device. In response to a prompt message instructing the target device to complete model deployment based on the received migration parameter set, service requests received after the prompt message are forwarded to the target device for processing.

[0014] The model transfer method according to the first aspect of this application, applied to a target device, includes: Send the hardware configuration information of the target device to the source device so that the source device can determine the corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. Receive the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; Deploy the target model based on the migration parameter set; The source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, so as to determine the corresponding model migration strategy based on the hardware difference.

[0015] According to one embodiment of this application, sending the hardware configuration information of the target device to the source device includes: Once it is confirmed that the source device has passed authentication and authentication information indicating that the source device has passed authentication of the target device has been received, the hardware configuration information of the target device is sent to the source device.

[0016] According to one embodiment of this application, receiving the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy includes: Receive encrypted data and a first hash digest sent by the source device; The encrypted data is decrypted to obtain the plaintext parameters; The first hash digest and the second hash digest obtained from the third-party device are compared with the third hash digest generated in plaintext according to the parameters; If the first hash digest, the second hash digest, and the third hash digest are consistent, the plaintext of the parameters is determined to be the set of migration parameters obtained from the target model.

[0017] According to one embodiment of this application, deploying the target model based on the migration parameter set includes: Based on the hardware configuration information of the target device, the migration parameter set is adapted and converted to obtain a target migration parameter set adapted to the hardware configuration of the target device; Deploy the target model based on the target migration parameter set.

[0018] According to one embodiment of this application, the step of adapting and converting the migration parameter set based on the hardware configuration information of the target device to obtain a target migration parameter set adapted to the hardware configuration of the target device includes: Based on the computing resource parameters in the hardware configuration information of the target device, the migration parameter set is quantized and compressed to obtain a target migration parameter set adapted to the computing resource parameters.

[0019] According to one embodiment of this application, the step of adapting and converting the migration parameter set based on the hardware configuration information of the target device to generate target migration parameters adapted to the hardware configuration of the target device includes: Based on the hardware configuration information of the target device, determine the set of candidate operators adapted to the target device; Based on the candidate operator set, the original operators in the migration parameter set are replaced with functionally equivalent target operators in the candidate operator set to obtain the target migration parameter set.

[0020] According to one embodiment of this application, it also includes: During the process of receiving the migration parameter set, the current processing status of the service requests processed by the service instance generated by the source device according to the target model is received; Once the model deployment is completed based on the received migration parameter set, a corresponding prompt message is sent to the source device so that the source device responds to the prompt message and forwards any service requests received after the prompt message to the target device for processing.

[0021] The model transfer apparatus according to a third aspect embodiment of this application, applied to a source device, includes: The hardware difference identification module is used to determine the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. The migration strategy determination module is used to determine the corresponding model migration strategy based on the hardware differences. The migration parameter acquisition module is used to acquire a set of migration parameters corresponding to the model migration strategy from the target model deployed on the source device, according to the model migration strategy. The migration parameter transmission module is used to transmit the migration parameter set to the target device so that the target device can deploy the target model according to the migration parameter set.

[0022] The model transfer apparatus according to the fourth aspect of this application, applied to a target device, includes: The configuration information sending module is used to send the hardware configuration information of the target device to the source device, so that the source device can determine the corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. The migration parameter receiving module is used to receive the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; The target model deployment module is used to deploy the target model according to the migration parameter set; The source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, so as to determine the corresponding model migration strategy based on the hardware difference.

[0023] An electronic device according to a fifth aspect of this application includes a processor and a memory storing a computer program, wherein the processor executes the computer program to implement the model transfer method described in any of the above embodiments.

[0024] A computer-readable storage medium according to a sixth aspect of this application stores a computer program thereon, which, when executed by a processor, implements the model transfer method described in any of the above embodiments. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a first flowchart illustrating the model transfer method provided in an embodiment of this application; Figure 2 This is a second flowchart illustrating the model transfer method provided in an embodiment of this application. Figure 3 A schematic diagram of the third process of the model transfer method provided in the embodiments of this application; Figure 4 A schematic diagram of the fourth process of the model transfer method provided in the embodiments of this application; Figure 5 This is a first structural schematic diagram of the model transfer device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the second structure of the model transfer device provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0029] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0030] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0031] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0032] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), and similarly, "multiple items" refers to two or more (including two).

[0033] The meanings of some specific terms used in the embodiments of this application are as follows: A source device refers to the device that provides the pre-trained target model during model transfer; it is the original deployment or training environment of the model. A source device can be an electronic device.

[0034] The target device refers to the device that receives and applies the parameters of the migrated model during the model migration process; that is, the environment in which the model ultimately needs to be deployed and execute tasks.

[0035] Hardware configuration information refers to hardware parameters used to describe the computing and transmission capabilities of a device, such as hardware architecture type, computing power, storage read / write speed, and storage space.

[0036] A network layer is a structural unit in a network model that can be independently removed, pruned, or compressed, and contains learnable parameters.

[0037] An operator is a fundamental computational unit in a deep learning model. It is the smallest operational unit that constitutes the model's computational graph and is used to perform specific mathematical operations, such as matrix multiplication, convolution, and activation functions. The underlying implementation is provided by deep learning frameworks (such as PyTorch and TensorFlow), and all inference computations in the model are completed by a combination of a series of operators.

[0038] The model transfer method and apparatus provided in this application will be described in detail and explained below through several specific embodiments.

[0039] With the development of technology, more and more devices, such as IoT terminals, edge computing nodes, and mobile embedded devices, are typically equipped with models to assist in task processing and improve task efficiency. To reuse the general knowledge acquired by a model trained on a source device in a target device, model transfer is usually required. This involves transferring the model parameters from the source device to the target device, enabling the target device to reuse the feature extraction capabilities and inference logic learned by the source device. This saves training time for the model deployed on the target device and reduces the target device's computing resources.

[0040] In related technologies, a common model transfer method is full parameter transfer, where all model parameters are completely transferred from the source device to the target device. While this method can completely copy the trained model from the source device to the target device, it requires transferring a large number of parameters, placing high demands on the hardware resources of the target device. If full parameter transfer is applied to all model transfer scenarios, it can easily cause a sharp increase in transmission latency or even transfer failure when the target device has limited hardware resources, thus affecting the model transfer efficiency.

[0041] Therefore, this application embodiment determines the hardware difference between the source device and the target device based on their hardware configuration information. Then, according to the model migration strategy corresponding to the hardware difference, it obtains a migration parameter set corresponding to the model migration strategy deployed on the source device and transmits it to the target device, enabling the target device to deploy the target model based on the migration parameter set. This allows for flexible selection of the number of parameters to be transmitted based on the hardware differences between the source and target devices, effectively reducing the risk of sudden increases in transmission latency or migration failure due to excessively large transmission parameters when the target device's hardware resources are limited. This reduces dependence on the target device's hardware resources and improves model migration efficiency.

[0042] The model transfer method disclosed in this application can be applied to both source and target devices. Both the source and target devices can be electronic devices. These electronic devices can be mobile terminals, desktop terminals, vehicle-mounted terminals, or servers, etc. The server can be a standalone server or a server cluster composed of multiple servers. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence sampling point devices.

[0043] According to some embodiments of this application, this application provides a model migration method, which can be applied to the aforementioned source device and target device to realize the migration of model parameters of a network model. For example... Figure 1 As shown, the model transfer method provided in this embodiment includes: S101, The target device sends its hardware configuration information to the source device; S102, the source device determines the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the source device and the target device. S103, the source device determines the corresponding model migration strategy based on the degree of hardware difference; S104, The source device obtains the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device according to the model migration strategy; S105, The source device transmits the migration parameter set to the target device; S106, The target device deploys the target model based on the received migration parameter set.

[0044] In some embodiments, when model migration is required, the source device may send a hardware configuration information query request to the target device. In response to the hardware configuration information query request, the target device sends its hardware configuration information to the source device. This hardware configuration information may be the computing power of the target device's GPU and / or NPU, or the target device's memory capacity, storage read / write speed, etc., or the target device's hardware architecture type, such as ARM Cortex-A78, Qualcomm Snapdragon 8 Gen 3, Apple A17 Pro, etc.

[0045] Based on the hardware configuration information obtained from the target device, the source device can calculate the degree of difference in the hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. For example, the configuration information of the target device obtained by the source device includes the CPU computing power F_tgt of the target device. Based on the CPU computing power F_src of the source device and the CPU computing power F_tgt of the target device, the degree of difference of the hardware configuration item of CPU computing power can be obtained as: |F_src-F_tgt|, |F_src-F_tgt| / F_src, or max(0,(F_src-F_tgt) / F_src). Alternatively, if the configuration information of the target device obtained by the source device includes the target device's memory capacity M_tgt, then based on the source device's memory capacity M_src and the target device's memory capacity M_tgt, the difference in the hardware configuration item of memory capacity can be obtained as: |M_src-M_tgt|, |M_src-M_tgt| / M_src, or max(0,(M_src-M_tgt) / M_src). Alternatively, if the configuration information of the target device obtained by the source device includes the target device's storage speed S_tgt, then based on the source device's storage speed S_src and the target device's storage speed S_tgt, the difference in the hardware configuration item of storage speed can be obtained as: |S_src-S_tgt|, |S_src-S_tgt| / S_src, or max(0,(S_src-S_tgt) / S_src).

[0046] The hardware differences between the source and target devices can be determined based on the differences in hardware configuration items. For example, the difference in a specific hardware configuration item between the source and target devices, such as the difference in CPU computing power, can be selected as the hardware difference between the source and target devices. Alternatively, the average of the differences in all hardware configuration items between the source and target devices can be used as the hardware difference between the source and target devices.

[0047] In some embodiments, the source device may pre-record different hardware differences and different model migration strategies. For example, a hardware difference less than or equal to a first preset threshold indicates a small hardware difference between the source and target devices, and the corresponding model migration strategy is a full migration strategy that performs a full migration of all model parameters for the target model deployed on the source device; a hardware difference greater than the first preset threshold and less than or equal to a second preset threshold indicates a moderate hardware difference between the source and target devices, and the corresponding model migration strategy is a core parameter migration strategy that performs a core model parameter migration for the target model deployed on the source device; a hardware difference greater than the second preset threshold indicates a large hardware difference between the source and target devices, and the corresponding model migration strategy is an incremental parameter migration strategy that performs an incremental parameter migration for the target model deployed on the source device.

[0048] The target model is a neural network model, such as ResNet or MobileNet for image classification, YOLO for object detection, or BERT or GPT for natural language processing. The first and second preset thresholds can be set according to the actual situation.

[0049] Full model parameter migration refers to the complete transfer and deployment of all model parameters of the target model from the source device to the target device. Core model parameter migration refers to the transfer and deployment of the more important core parameters of the target model from the source device to the target device. Incremental parameter migration refers to migrating only the incremental parameters of the target model in the source device. Incremental parameters are the model parameters in the target model deployed on the source device that are different from the currently deployed model on the target device.

[0050] Once the source device determines the hardware differences between the source device and the target device, it can determine the corresponding model migration strategy based on the hardware differences. Then, based on the model migration strategy, it can obtain the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device.

[0051] As one possible implementation, if the model migration strategy is determined to be a full migration strategy based on the hardware differences, then all model parameters of the target model are obtained to form a migration parameter set. This could involve extracting all model parameters of the target model, including the weights, biases, normalized parameters, model structure description files, and model configuration information for all network layers, to form the migration parameter set. The normalized parameters may include the mean and variance of BatchNorm, and the model structure description file may include network layer types and connection relationships.

[0052] As another possible implementation, if the model migration strategy is determined to be a core parameter migration strategy based on the hardware differences, then the core parameters of the target model are obtained from all model parameters of the target model to form a migration parameter set. For example, the model parameters of the target model can be sorted by importance, and the most important parameters (e.g., the top 60%-80%) can be selected as the core parameters. These core parameters are then combined with the normalized parameters of the target model, the model structure description file, and the model version information to form the migration parameter set.

[0053] As another possible implementation, if the model migration strategy is determined to be an incremental parameter migration strategy based on the hardware differences, then the incremental parameters of the target model are obtained from all model parameters of the target model to form a migration parameter set. For example, the source device maintains version records of the target model, recording the changed network layer name, parameter tensor index, and change timestamp each time the target model's parameters are updated. When the incremental parameter migration strategy is triggered, the source device compares the target model with the models already deployed on the target device to determine the incremental parameters of the target model. Incremental parameters can be divided into three categories: weight updates (parameter values ​​change), structural changes (addition or deletion of network layers), and hyperparameter changes (learning rate, normalization parameters, etc.). If the incremental parameter type is a structural change, the parameters of the affected network layers need to be transmitted additionally. The incremental parameters are grouped and packaged by network layer, with each group containing the network layer identifier, parameter tensor data, and version number, generating an incremental migration package. The incremental migration packages and the parameters of the affected network layers are combined to form a migration parameter set. The size of this migration parameter set is usually much smaller than the total number of model parameters of the target model.

[0054] Once the source device determines the migration parameter set, it can transmit the migration parameter set to the target device. The target device can then update the model parameters of the currently deployed model based on the migration parameter set. After the model parameters are updated, the model is loaded into the inference engine of the target device to complete the model deployment.

[0055] By determining the hardware differences between the source and target devices based on their hardware configuration information, and then using a model migration strategy corresponding to these differences, a migration parameter set corresponding to the migration strategy is obtained from the target model deployed on the source device and transmitted to the target device. This allows the target device to deploy the target model based on the migration parameter set. This approach flexibly selects the amount of parameters to be transmitted based on the hardware differences between the source and target devices, effectively reducing the risk of sudden increases in transmission latency or migration failures due to excessive parameter transmission when the target device's hardware resources are limited. Consequently, it reduces dependence on the target device's hardware resources and improves model migration efficiency.

[0056] To improve the security of model migration, the target device can be authenticated before migration. For example, the source device verifies the target device's legitimacy based on its identity information, allowing model migration to proceed only if the target device passes authentication. However, this authentication method only verifies the target device's identity, leaving it vulnerable to counterfeit source devices. This could result in the target device receiving malicious or tampered model parameters, compromising the security of model migration.

[0057] Therefore, in some embodiments, the target device sends its hardware configuration information to the source device, including: the target device confirming that the source device's identity authentication is successful, and receiving authentication information indicating that the source device's identity authentication of the target device is successful, and then sending the target device's hardware configuration information to the source device.

[0058] In some embodiments, the source device determines the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, including: the source device determining that the identity authentication of the target device is successful, and receiving authentication information indicating that the identity authentication of the source device by the target device is successful, and determining the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device.

[0059] As one possible implementation method, such as Figure 2 As shown, the method includes: S10, the source device sends the first authentication request of the source device to the target device.

[0060] The first authentication request includes the source device's device certificate and a challenge random number.

[0061] The source device's device certificate can be a device certificate issued by a third-party device. The third-party device is an authoritative authentication node independent of both the source and target devices, used to issue digital certificates to legitimate source and target devices to establish a foundation of trust. For example, the third-party device could be a Certificate Authority (CA) server used to issue and manage digital certificates.

[0062] S11, the target device verifies the validity of the source device's device certificate in the first authentication request.

[0063] Verifying the legitimacy of the source device's certificate can involve verifying the certificate chain, validity period, and revocation status of the source device's certificate. If the certificate chain is valid, the source device's certificate has not expired, and the source device's certificate is not revoked, then the source device's certificate can be considered legitimate.

[0064] S12, if the target device determines that the source device’s device certificate is valid, it encrypts the challenge random number in the first authentication request and returns an encrypted response.

[0065] The encryption of the challenge random number in the first authentication request can be achieved by using the public key of the source device to encrypt the challenge random number in the first authentication request.

[0066] S13, the source device determines that the encrypted response returned by the target device is accurate and passes the authentication of the target device.

[0067] One way to determine whether the encrypted response returned by the target device is accurate is to decrypt the encrypted response returned by the target device using the private key of the source device, thereby obtaining the challenge random number in the encrypted response. If the challenge random number in the encrypted response matches the challenge random number in the first authentication request sent by the source device, then the encrypted response returned by the target device can be determined to be accurate.

[0068] S14, the source device sends authentication information to the target device indicating that the target device's identity authentication has been successful.

[0069] S15, the target device sends a second authentication request to the source device.

[0070] The second authentication request includes the target device's device certificate and a challenge random number. The target device's device certificate can be a device certificate issued by a third-party device.

[0071] S16, The source device verifies the validity of the target device's device certificate in the second authentication request.

[0072] Verifying the legality of the target device's equipment certificate can involve verifying the certificate chain, validity period, and revocation status of the target device's equipment certificate to determine its legitimacy.

[0073] S17, if the source device determines that the target device’s device certificate is valid, it encrypts the challenge random number in the second authentication request and returns an encrypted response.

[0074] S18, the target device determines that the encrypted response returned by the source device is accurate and passes the authentication of the source device.

[0075] One way to determine whether the encrypted response returned by the source device is accurate is to decrypt the encrypted response returned by the source device using the target device's private key to obtain the challenge random number in the encrypted response. If the challenge random number in the encrypted response matches the challenge random number in the second authentication request sent by the target device, then the encrypted response returned by the source device can be determined to be accurate.

[0076] S19, the target device sends authentication information to the source device indicating that the source device's identity authentication has been successful.

[0077] S20, the target device confirms that the source device's identity authentication is successful and receives the authentication information indicating that the source device's identity authentication of the target device is successful, and sends the target device's hardware configuration information to the source device.

[0078] S21, the source device determines that the identity authentication of the target device is successful, and receives authentication information indicating that the target device has successfully authenticated the identity of the source device. Based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device, the source device determines the hardware difference between the source device and the target device.

[0079] For example, if the target device determines that the source device's identity authentication is successful and receives authentication information indicating that the source device's identity authentication of the target device is successful, or if the source device determines that the target device's identity authentication is successful and receives authentication information indicating that the target device's identity authentication of the source device is successful, it means that the two-way identity authentication between the target device and the source device is successful. At this time, the target device and the source device can negotiate to generate a session key, establish a TLS secure channel, and subsequently conduct data interaction based on the TLS secure channel to achieve model migration.

[0080] By performing two-way authentication on the source and target devices, model migration can only be performed after both devices have successfully completed the two-way authentication. This effectively reduces the possibility of spoofing of the source or target devices, thereby improving the security of model migration.

[0081] After the source device and the target device complete the identity authentication, the source device can determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, and then determine the corresponding model migration strategy to perform model migration based on the hardware difference.

[0082] Considering that the hardware configuration information may include hardware configuration parameters for multiple hardware configuration items, in order to improve the reliability of the obtained hardware differences and determine a more accurate model migration strategy to improve the efficiency and reliability of model migration, in some embodiments, the source device determines the hardware differences between the source device and the target device based on the hardware configuration information of the source device and the target device, including: Based on the hardware configuration information of the source device and the target device, determine the degree of difference of the hardware configuration item for the same hardware configuration item; Based on the preset weights of each hardware configuration item, the degree of difference between each hardware configuration item is weighted to determine the degree of hardware difference between the source device and the target device.

[0083] For example, taking CPU computing power as a hardware configuration item, based on the CPU computing power F_src of the source device and the CPU computing power F_tgt of the target device, the difference in CPU computing power as a hardware configuration item can be obtained as |F_src-F_tgt| / F_src. The same logic applies to other hardware configuration items.

[0084] For different hardware configuration items, their impact on model transfer efficiency can be determined in advance through a large number of experimental tests. Based on the impact of each hardware configuration item on model transfer efficiency, preset weights can be set for each hardware configuration item.

[0085] The source device can weight the differences between the source and target devices based on preset weights for each hardware configuration item. For example, if the hardware configuration items are CPU computing power, memory capacity, and storage speed, then the hardware difference D_hw between the source and target devices can be obtained as follows: D_hw=w1×|F_src-F_tgt| / F_src+w2×|M_src-M_tgt| / M_src+w3×|S_src-S_tgt| / S_src.

[0086] Where w1 represents the preset weight of CPU computing power, which can be set to 0.5; w2 represents the preset weight of memory capacity, which can be set to 0.3; and w3 represents the preset weight of storage speed, which can be set to 0.2.

[0087] As another possible implementation, the hardware difference can be determined based on the degree to which the source device is superior to the target device. For example, the hardware difference D_hw can be: D_hw=w1×max(0,(F_src-F_tgt) / F_src)+w2×max(0,(M_src-M_tgt) / M_src)+w3×max(0,(S_src-S_tgt) / S_src).

[0088] Once the hardware differences are determined, the corresponding model migration strategy can be determined based on the hardware differences to perform model migration.

[0089] By weighting the differences between the hardware configuration items in the hardware configuration information of the source and target devices, the hardware difference between the source and target devices is determined. This makes the determination of the hardware difference take into account the differences between multiple hardware configuration items between the source and target devices, improving the reliability of the obtained hardware difference. Based on the hardware difference, a more accurate model migration strategy can be determined to improve the efficiency and reliability of model migration.

[0090] To further improve the efficiency and reliability of model migration, in some embodiments, a corresponding model migration strategy is determined based on the degree of hardware differences, including: The corresponding migration score is determined by weighting the hardware differences, the obtained transmission load rate, and the latency ratio. Based on the transfer score, determine the corresponding model transfer strategy; The transmission load rate is determined by the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration. The amount of data that can be transmitted within the budget duration is determined by the current available bandwidth and the budget duration. The latency ratio is determined based on the ratio of the current transmission latency to the maximum allowable transmission latency.

[0091] In some embodiments, the source device can determine the amount of data it can transmit within the budgeted time period as B × TransferTimeBudget, based on its current available bandwidth B and a preset budgeted time period TransferTimeBudget. Then, based on the total number of parameters ModelSize of the target model and the amount of data the source device can transmit within the budgeted time period, the source device's transmission load rate is determined as: ModelSize × 8 / (B × TransferTimeBudget). Here, the unit of the current available bandwidth B is Mbps, the unit of the budgeted time period TransferTimeBudget is seconds, and the unit of the total number of parameters ModelSize is MB. The budgeted time period is the maximum duration allowed by the source device to transmit model parameters of the target model to the target device.

[0092] Simultaneously, the source device can determine its latency ratio as RTT / RTT_threshold based on the current transmission delay (RTT) detected by the source device and the maximum allowable transmission delay (RTT_threshold) of the source device. The units for the current transmission delay (RTT) and the maximum transmission delay (RTT_threshold) are milliseconds.

[0093] Based on the obtained hardware difference D_hw, transmission load rate ModelSize×8 / (B×TransferTimeBudget), and latency ratio RTT / RTT_threshold, the corresponding migration score S_level can be obtained as follows: S_level=α×D_hw+β×(ModelSize×8 / (B×TransferTimeBudget))+γ×(RTT / RTT_threshold) Where α represents the preset weight corresponding to hardware differences, β represents the preset weight corresponding to transmission load rate, and γ represents the preset weight corresponding to latency ratio. The specific values ​​of α, β, and γ can be set according to actual conditions, such as 0.4, 0.35, and 0.25 respectively.

[0094] Alternatively, based on the obtained hardware difference degree D_hw, transmission load rate ModelSize×8 / (B×TransferTimeBudget), and latency ratio RTT / RTT_threshold, the hardware difference degree, transmission load rate, and latency ratio can be normalized to obtain the normalized hardware difference degree f(D_hw), normalized transmission load rate g(L), and normalized latency ratio h(R). Here, f(), g(), and h() are monotonically increasing normalization functions used to map the corresponding indicators to the [0,1] interval. The normalization function can be the sigmoid function, etc.

[0095] Based on the normalized hardware difference f(D_hw), the normalized transmission load rate g(L), and the normalized latency ratio h(R), the corresponding migration score S_level can be obtained as follows: S_level=α×f(D_hw)+β×g(L)+γ×h(R) The obtained migration score S_level can be compared with a first threshold T1 and a second threshold T2. The first threshold T1 and the second threshold T2 can be determined based on extensive experimental testing. For example, T1 could be 0.3 and T2 0.7. If S_level ≤ T1, it indicates that the hardware differences between the source and target devices are small and the network conditions are good. In this case, the corresponding model migration strategy is a full migration strategy that performs a full migration of all model parameters for the target model deployed on the source device. If T1 < S_level ≤ T2, it indicates that the hardware differences between the source and target devices are moderate or the network conditions are average. In this case, the corresponding model migration strategy is a core parameter migration strategy that performs a core model parameter migration for the target model deployed on the source device. If T2 < S_level, it indicates that the hardware differences between the source and target devices are large or the network conditions are poor. In this case, the corresponding model migration strategy is an incremental parameter migration strategy that performs incremental parameter migration for the target model deployed on the source device.

[0096] By weighting hardware differences, transmission load rate, and latency ratio, a corresponding migration score is determined. Based on the migration score, the corresponding model migration strategy is determined. This allows for comprehensive decision-making by combining static equipment capabilities with real-time network transmission status and link quality, avoiding the one-sidedness of judging by a single indicator. This makes the selection of model migration strategy more accurate and reasonable, thereby further improving the efficiency and reliability of model migration.

[0097] To further improve the efficiency and reliability of model migration, in some embodiments, according to the model migration strategy, a migration parameter set corresponding to the model migration strategy is obtained from the target model deployed on the source device, including: Given that the model transfer strategy is determined to be the core parameter transfer strategy, the parameters are evaluated based on the importance of each network layer in the target model, and at least one target network layer is determined from each network layer. Based on the parameters of each target network layer, the transfer parameter set is obtained; The importance assessment parameters include at least one of the following: the proportion of network layer parameters, the contribution of network layer to the output accuracy of the target model, and the parameter update frequency of network layer. The percentage of parameters in a network layer is determined based on the total number of parameters in the network layer and the total number of parameters in the target model.

[0098] In some embodiments, the source device may pre-determine the importance evaluation parameters for each network layer of the target model. The importance evaluation parameters for each network layer are determined in the same way.

[0099] For example, the parameter ratio of a network layer can be obtained based on the parameter count of that network layer relative to the total number of parameters in the target model. The parameter ratio of each network layer can then be used as an importance assessment parameter for that network layer.

[0100] Alternatively, by performing layer-by-layer ablation experiments or gradient sensitivity analysis on a specific network layer, the percentage decrease in the target model's output accuracy after removing that network layer can be obtained as the contribution of that network layer to the target model's output accuracy. Here, the target model's output accuracy is between 0 and 1, and the percentage decrease is the difference in output accuracy before and after removing the network layer, ranging from [0,1]. The contribution of each network layer to the target model's output accuracy is then used as an importance evaluation parameter for each network layer.

[0101] Alternatively, record the parameter update frequency of each network layer, and normalize the parameter update frequency of each network layer to obtain the importance evaluation parameters of each network layer.

[0102] In some embodiments, after determining the importance evaluation parameters for each network layer, the network layer whose importance evaluation parameters are greater than or equal to a preset evaluation threshold can be identified as the target network layer. The preset evaluation threshold can be set according to actual conditions, and different preset evaluation thresholds correspond to different importance evaluation parameters. For example, if the importance evaluation parameter is the percentage of parameter quantity, the preset evaluation threshold is the percentage of parameter quantity threshold; if the importance evaluation parameter is the contribution, the preset evaluation threshold is the contribution threshold; if the importance evaluation parameter is the parameter update frequency, the preset evaluation threshold is the frequency threshold. Alternatively, if the importance evaluation parameters include the percentage of parameter quantity, the contribution, and the parameter update frequency, the preset evaluation threshold includes the percentage of parameter quantity threshold, the contribution threshold, and the frequency threshold. In this case, when the percentage of parameter quantity, the contribution, and the parameter update frequency of a certain network layer are greater than or equal to the percentage of parameter quantity threshold, the contribution threshold, and the frequency threshold, respectively, that network layer can be identified as the target network layer.

[0103] Alternatively, in some embodiments, at least one target network layer is determined from the network layers based on the importance evaluation parameters of any network layer in the target model, including: The importance score of a network layer is determined based on the importance evaluation parameters of any network layer in the target model. Based on the importance score of each network layer, target network layers are selected sequentially from the network layers in descending order of importance score until the total number of parameters of each target network layer is within the preset range. The preset range is determined based on the total number of parameters of the target model and the preset ratio range, and the preset ratio range is positively correlated with the current available bandwidth.

[0104] In some embodiments, for any network layer's importance evaluation parameter, the various parameters of that importance evaluation parameter can be weighted to obtain the network layer's importance score. For example, if the importance evaluation parameter's parameters are the parameter proportion P_layer, the contribution to the target model's output accuracy C_layer, and the normalized parameter update frequency U_layer, then the importance score I_layer of that network layer can be obtained as follows: I_layer=λ1×P_layer+λ2×C_layer+λ3×U_layer Wherein, λ1 represents the preset weight corresponding to the percentage of parameters, λ2 represents the preset weight corresponding to the contribution, and λ3 represents the preset weight corresponding to the parameter update frequency. The specific values ​​of λ1, λ2, and λ3 can be set according to the actual situation.

[0105] If the importance assessment parameters of a network layer contain only a single parameter item, such as only the percentage of parameters, contribution, or parameter update frequency, then the value of that parameter item is used as the importance score of that network layer.

[0106] After determining the importance score of each network layer, target network layers can be selected sequentially from the network layers according to their importance scores, from highest to lowest. After each target network layer is selected, the total number of parameters for that target network layer is calculated. If the total number of parameters for the current target network layer is within a preset range, the selection of target network layers is stopped. Thus, the top K target network layers can be extracted based on their importance scores.

[0107] The boundary value of the preset range can be the product of the total number of parameters of the target model and the boundary value of the preset proportion range. For example, if the preset proportion range is 60%-80% and the total number of parameters of the target model is ModelSize, then the preset range is 60%×ModelSize-80%×ModelSize.

[0108] In some embodiments, the source device may pre-record the correspondence between different bandwidths and different preset ratio ranges. After determining the current available bandwidth of the source device, the corresponding preset ratio range can be determined based on the current available bandwidth of the source device. The preset ratio range is positively correlated with the current available bandwidth of the source device; that is, the higher the current available bandwidth of the source device, the larger the boundary value of the corresponding preset ratio range.

[0109] After determining each target network layer, the parameters of each target network layer, the normalized parameters of the target model, the model structure description file, and the model version information can be combined into a migration parameter set and transmitted to the target device.

[0110] When the model transfer strategy is based on the core parameter transfer strategy, by evaluating parameters according to the importance of each network layer in the target model, at least one target network layer is determined from each network layer. A transfer parameter set is then formed based on the parameters of each target network layer. This reduces data transmission volume while maintaining the integrity of the internal structure and the independence of the functions of the transferred network layer, avoiding problems such as damage to the intra-layer structure or significant decrease in accuracy caused by parameter pruning. This allows for obtaining model output accuracy as close as possible to full transfer with minimal transmission cost, even under conditions of limited target device resources or general network conditions, thereby improving the efficiency and reliability of model transfer.

[0111] To further improve the reliability of model transfer, in some embodiments, such as Figure 3 As shown, the method includes: S201, the source device encrypts the migration parameter set to obtain encrypted data; S202, The source device transmits encrypted data and a first hash digest generated by the migration parameter set to the target device; S203, the source device registers the first hash digest with the third-party device and obtains the second hash digest stored in the third-party device; S204, The third-party device sends the second hash digest to the target device; S205, the target device decrypts the encrypted data to obtain the plaintext parameters; S206, the target device compares the first hash digest and the second hash digest obtained from the third-party device with the third hash digest generated based on the parameter plaintext. If the first hash digest, the second hash digest and the third hash digest are consistent, the parameter plaintext is determined to be the migration parameter set obtained from the target model.

[0112] In some embodiments, after determining the migration parameter set, the source device can use the target device's public key to perform asymmetric encryption on the migration parameter set to obtain encrypted data. If the migration parameter set is large, such as exceeding a preset data size, a hybrid encryption scheme can be used. For example, the target device's public key can be used to encrypt a randomly generated symmetric session key, and then this session key can be used to perform symmetric encryption on the migration parameter set, thus balancing security and transmission efficiency. The target device's public key can be obtained from its device certificate, which can be sent from the target device to the source device.

[0113] Furthermore, the source device can calculate a hash digest of the migration parameter set, such as using SHA-256, and use this hash digest as the first hash digest generated from the migration parameter set. After obtaining the first hash digest, the source device's private key can be used to digitally sign the first hash digest to generate an integrity certificate.

[0114] After the source device obtains the encrypted data and the first hash digest, it can send the encrypted data and the first hash digest to the target device via a TLS secure channel. In addition to sending the encrypted data and the first hash digest to the target device, the source device can also send the encrypted session key and digital signature to the target device via the TLS secure channel.

[0115] Meanwhile, after obtaining the first hash digest, the source device registers the first hash digest with the hash registry center of the third-party device. The first hash digest registered with the third-party device is the second hash digest stored on the third-party device, which is used by the target device for comparison during subsequent verification.

[0116] When a third-party device receives a hash digest retrieval request from a target device, it can send its stored second hash digest to the target device, or synchronize the second hash digest to the target device after completing the storage of the second hash digest.

[0117] After receiving encrypted data and a first hash digest from the source device, the target device can decrypt the encrypted data using its own private key to obtain the plaintext parameters within the encrypted data. Alternatively, it can decrypt the session key using its own private key, and then use the session key to decrypt the encrypted data to obtain the plaintext parameters. For the obtained plaintext parameters, the target device can calculate a hash digest of the plaintext parameters and use the calculated hash digest as the third hash digest.

[0118] The target device can cross-validate the first hash digest received from the source device, the second hash digest received from the third-party device, and the third hash digest generated from the plaintext of the calculated parameters. If any of the three hash digests is inconsistent, it is determined that the transmission process has been tampered with, triggering a retransmission or terminating the process. If all three hash digests are consistent, the transmission process is considered normal, and the target device can then identify the plaintext of the parameters as the migration parameter set obtained from the target model, and deploy the target model based on the migration parameter set. This cross-validation of the three hash digests effectively verifies whether the parameters received by the target device have been tampered with or accidentally damaged during transmission, ensuring that the model parameters deployed on the target device are completely consistent with those sent by the source device. This prevents the model from malfunctioning or developing security vulnerabilities due to malicious injection or transmission errors, thereby further improving the reliability of model migration.

[0119] In some embodiments, after the target device performs cross-validation of the parameter plaintext using a three-way hash digest, it can also verify whether the dimension (shape) and data type (dtype) of the parameter tensors of each network layer are consistent with expectations, based on the model structure description file in the parameter plaintext. For example, it checks whether the number of rows and columns of the weight matrix of any network layer matches the input and output dimensions of that network layer, whether the length of the bias vector of any network layer matches the output dimension, and whether the number of channels of the normalized parameters of any network layer matches the number of channels of the feature map. If the dimensions are inconsistent, the model structure is deemed corrupted, triggering a retransmission of the transfer parameter set or terminating the process; otherwise, the parameter plaintext is identified as the transfer parameter set obtained from the target model, and the target model is deployed based on this transfer parameter set.

[0120] During the deployment of the target model on the target device based on the transfer parameter set, the transfer parameter set can be loaded into the inference engine. Inference can be performed using a preset standard test input set, such as sequentially inputting the standard test input set into the inference engine and then comparing the output with the expected output provided by the source device. The comparison results can include the cosine similarity of the output vectors (threshold ≥ 0.995) and the maximum absolute error of each classification probability (threshold ≤ 0.01). If any comparison result does not meet the corresponding threshold requirement, the transfer parameter set is deemed abnormal, triggering a retransmission of the transfer parameter set or terminating the process.

[0121] To reduce the impact of model migration on service requests that require processing by the target model, in some embodiments, such as Figure 4 As shown, the method also includes: S107, During the process of transmitting the migration parameter set from the source device to the target device, the source device processes the received service requests based on the service instances generated by the target model and records the current processing status of the service requests. S108, The source device synchronizes its current processing status to the target device; S109, the target device determines that it has completed the model deployment based on the received migration parameter set and sends the corresponding prompt information to the source device; S110, in response to the prompt message, the source device forwards any service requests received after the prompt message to the target device for processing.

[0122] In some embodiments, before performing model migration, such as before transferring the migration parameter set, the source device may maintain in memory the currently serving service instance generated based on the target model, and the migration instance generated based on the migration parameter set. The migration instance is a snapshot of the state of the service instance at a certain point in time. The migration process is based on the migration instance and does not affect the service instance from continuing to process user requests.

[0123] In some embodiments, before model migration, the source device receives service requests and processes them through service instances. During the transmission of migration parameter sets to the target device, the source device can continue processing ongoing service requests through service instances. New service requests received during this process are also processed by invoking service instances, and the current processing status of each service request is recorded to ensure that processing can be resumed even if a routing switch occurs later. Simultaneously, the recorded current processing status of service requests is synchronized to the target device, enabling the target device to seamlessly connect related service requests based on the synchronized processing status, avoiding duplicate processing or service interruptions due to missing status information. The current processing status includes the service request's request ID, authentication token, processing progress, and intermediate results.

[0124] The target device deploys the model based on the received migration parameter set. If the target model completes deployment, it sends a corresponding notification message to the source device. Upon receiving this notification message, the source device confirms that the model migration is complete. In response, it generates a drain flag and forwards any new service requests received after the drain flag takes effect to the target device for processing.

[0125] After confirming the model migration is complete, the source device can continue processing the remaining service requests through the service instance. Once all remaining service requests have been processed, it sends a notification signal to the target device. The target device responds to this notification signal and officially takes over the service provision from the source device.

[0126] For example, consider processing a user authentication request. Before model migration, if the source device receives an authentication request from a user, such as facial recognition authentication, it processes the request through its service instance, extracts facial features, compares them with the user model, and returns the authentication result. At this point, all requests are handled by the source device. During the transmission of the migration parameter set to the target device, the source device's service instance continues to process received authentication requests, while newly arriving authentication requests are also processed by the source device. For authentication requests currently being processed, their current processing status is recorded and synchronized to the target device. After completing model deployment based on the received migration parameter set, the target device sends a corresponding prompt to the source device. In response to this prompt, the source device generates a clear flag and forwards any new authentication requests received after the clear flag takes effect to the target device for processing. When a user initiates a new authentication request, this request is routed to the target device. The target device uses the newly loaded target model to process the authentication request, extracts and compares facial features, and returns the authentication result. Thus, the service switch from the source device to the target device is completed without the user's awareness.

[0127] In some embodiments, if the target device experiences an anomaly after model migration, such as a model inference error rate exceeding a threshold, a fault rollback can be triggered, switching the request route back to the source device. At this point, the source device resumes service and sends an alert to the administrator.

[0128] During the transmission of the migration parameter set to the target device, service requests are processed based on service instances generated from the target model on the source device. The current processing status of each service request is recorded and synchronized to the target device. After the target device completes model deployment, service requests received by the source device after the prompt message are forwarded to the target device for processing. This ensures that service request processing continues during model migration, preventing service interruptions. Once the target device completes model deployment, it can integrate the synchronized processing status to seamlessly connect related service requests, preventing duplicate processing or service gaps due to missing status information. This ensures the continuity and consistency of business processing throughout the entire model migration process.

[0129] To further improve the reliability of model transfer, in some embodiments, the target model is deployed based on a transfer parameter set, including: Based on the hardware configuration information of the target device, the migration parameter set is adapted and converted to obtain the target migration parameter set adapted to the hardware configuration of the target device; Deploy the target model based on the target migration parameter set.

[0130] In some embodiments, the hardware configuration information of the target device may include hardware architecture information and available memory capacity. Hardware architecture information may include the chip architecture type of the target device, such as ARM v8 / v9, x86-64, RISC-V, etc. The target device may have pre-recorded a target data format adapted to its hardware architecture information and / or available memory capacity. Upon receiving the migration parameter set, the received migration parameter set can be format-converted based on this target data format to obtain a target migration parameter set adapted to the target device's hardware architecture information and / or available memory capacity. For example, the format of the migration parameter set can be converted to NCHW or NHWC format to match the access mode of the target hardware.

[0131] Alternatively, in some embodiments, the migration parameter set is adapted and transformed according to the hardware configuration information of the target device to obtain a target migration parameter set adapted to the hardware configuration of the target device, including: Based on the computing resource parameters in the hardware configuration information of the target device, the migration parameter set is quantized and compressed to obtain the target migration parameter set adapted to the computing resource parameters.

[0132] Among them, the computing resource parameters can be the computing power of the target device's GPU and / or NPU.

[0133] As one possible implementation, the target device can pre-record quantization strategies corresponding to different computing resource parameters. Upon receiving the migration parameter set, it can perform quantization compression based on the quantization compression strategy corresponding to its computing resource parameters, converting high-precision floating-point parameters into low-precision or integer parameters to reduce model size and computational overhead, thereby adapting the received target migration parameter set to the computing resource constraints of the target device.

[0134] The quantization compression strategy includes using FP16 mixed-precision quantization for parameters of computationally intensive layers (such as convolutional layers and fully connected layers) in the transfer parameter set, and maintaining FP32 precision for parameters of precision-sensitive layers (such as normalization layers and the last classification layer) to obtain a target transfer parameter set adapted to the computational resource parameters; or using INT8 quantization compression for the transfer parameter set, and then using post-training quantization (PTQ) or quantization-aware training (QAT) methods to perform precision compensation calibration on the quantized transfer parameter set to obtain a target transfer parameter set adapted to the computational resource parameters of the target device.

[0135] As another possible implementation, the target device can compare its computing resource parameters with those of the source device. Based on the comparison result, a corresponding quantization compression strategy is determined, and the migration parameter set is quantized and compressed based on the quantization compression strategy to obtain the target migration parameter set.

[0136] For example, if the computational resource parameters of the target device are ≥ 80% of those of the source device, the transfer parameter set maintains FP32 precision and no quantization is required. If the computational resource parameters of the target device are between 40% and 80% of those of the source device, the parameters of computationally intensive layers (such as convolutional layers and fully connected layers) in the transfer parameter set are quantized using FP16 mixed precision, while the parameters of precision-sensitive layers (such as normalization layers and the last classification layer) maintain FP32 precision to obtain a target transfer parameter set adapted to the computational resource parameters. If the computational resource parameters of the target device are < 40% of those of the source device, the transfer parameter set is quantized and compressed using INT8, and then precision compensation calibration is performed on the quantized transfer parameter set using post-training quantization (PTQ) or quantization-aware training (QAT) methods to obtain a target transfer parameter set adapted to the computational resource parameters of the target device.

[0137] By quantizing and compressing the migration parameter set according to the computing resource parameters of the target device, the data precision and storage volume of the migration parameter set can be effectively reduced, thereby reducing the computational overhead and memory usage of the model during inference. This enables models that could not run on target devices with limited computing power or memory to be successfully deployed and executed.

[0138] Alternatively, in some embodiments, the migration parameter set is adapted and transformed based on the hardware configuration information of the target device to generate target migration parameters adapted to the hardware configuration of the target device, including: Based on the hardware configuration information of the target device, determine the set of candidate operators that can be adapted to the target device; Based on the candidate operator set, the original operators in the transfer parameter set are replaced with the target operators that are functionally equivalent in the candidate operator set to obtain the target transfer parameter set.

[0139] In some embodiments, the target device may pre-record candidate operators that satisfy its hardware configuration information, and these candidate operators constitute a set of candidate operators adapted to the target device. For example, candidate operators may be BatchNorm, ReLU, LeakyReLU, and 2D convolution, etc.

[0140] Given the acquired migration parameter set, the target device can check whether all the original operators in the migration parameter set are consistent with a candidate operator in the candidate operator set. If the original operator is consistent with a candidate operator in the candidate operator set, it means that the original operator is compatible with the target device, and the original operator is not replaced. If the original operator is inconsistent with all candidate operators in the candidate operator set, then a candidate operator in the candidate operator set that is functionally equivalent to the original operator is selected as the target operator, and the original operator is replaced by the target operator. For example, if the original operator is GroupNorm, and there is no candidate operator GroupNorm in the candidate operator set, but there is a candidate operator BatchNorm in the candidate operator set, then BatchNorm can be selected as the target operator to replace the original operator GroupNorm. The same logic applies to other original operators.

[0141] When any current operator in the migration parameter set can find a consistent candidate operator in the candidate operator set, the operator replacement of the migration parameter set can be completed, thus obtaining the target migration parameter set.

[0142] By replacing the original operators in the migration parameter set with functionally equivalent target operators in the candidate operator set, hardware adaptation at the operator level is achieved. This ensures that all computational operations in the model can obtain native hardware-level acceleration support on the target device, avoiding runtime errors or efficiency losses caused by operator incompatibility. Thus, while ensuring the functional integrity of the target model, the inference efficiency of the target model on the target device is significantly improved.

[0143] In some embodiments, the obtained migration parameter set can be further subjected to quantization compression and operator replacement while performing format conversion to obtain the target migration parameter set, thereby making the obtained target migration parameter set more adaptable.

[0144] After obtaining the target migration parameter set, you can also record the strategy and parameter configuration for converting the migration parameter set into the target migration parameter set for reference in subsequent migrations.

[0145] By dynamically adjusting the migration parameter set based on the hardware configuration information of the target device during the model deployment phase, the same migration parameter set can be compatible with target devices with different hardware architectures. This removes the strong binding relationship between the model and specific hardware, thereby significantly improving the universality of model migration and the reliability of cross-platform deployment, and reducing the risk of deployment failure due to hardware differences.

[0146] Furthermore, in some embodiments, if the available memory of the target device is less than the preset memory amount during the deployment of the target model, model block loading can be adopted. The target model is grouped by layer, and only the network layers required for the current inference are loaded into memory at a time. After inference is completed, the memory is released and the next group of network layers is loaded. At the same time, weight sharing and parameter compression can also be adopted. The weights of similar layers are shared or low-rank decomposition is used to reduce the number of parameters, thereby improving the efficiency of the target device in running the target model.

[0147] To make the objectives, technical solutions, and advantages of this application clearer, one embodiment of this application will be clearly and completely described below. In some embodiments, the model transfer method includes: S301, the source device sends its first authentication request to the target device.

[0148] S302, The target device verifies the validity of the device certificate of the source device in the first authentication request.

[0149] S303, if the target device determines that the source device’s device certificate is valid, it encrypts the challenge random number in the first authentication request and returns an encrypted response.

[0150] S304, the source device determines that the encrypted response returned by the target device is accurate and passes the authentication of the target device.

[0151] S305, the source device sends authentication information to the target device indicating that the target device's identity authentication has been successful.

[0152] S306, The target device sends a second authentication request to the source device.

[0153] S307, The source device verifies the validity of the target device's device certificate in the second authentication request.

[0154] S308: If the source device determines that the target device's device certificate is valid, it encrypts the challenge random number in the second authentication request and returns an encrypted response.

[0155] S309, the target device determines that the encrypted response returned by the source device is accurate and passes the authentication of the source device.

[0156] S310, the target device sends authentication information to the source device indicating that the source device's identity authentication has been successful.

[0157] S311, the target device confirms that the source device's identity authentication is successful and receives the authentication information indicating that the source device's identity authentication of the target device is successful, and sends the target device's hardware configuration information to the source device.

[0158] S312, the source device determines that the identity authentication of the target device is successful, and receives authentication information indicating that the target device has successfully authenticated the identity of the source device. Based on the hardware configuration information of the source device and the target device, the difference of the hardware configuration item is determined according to the hardware configuration parameters of the same hardware configuration item.

[0159] S313, the source device weights the differences between each hardware configuration item according to the preset weights of each hardware configuration item, and determines the hardware differences between the source device and the target device.

[0160] S314, the source device weights the hardware difference, the obtained transmission load rate and the latency ratio to determine the corresponding migration score, and then determines the corresponding model migration strategy based on the migration score.

[0161] The transmission load rate is determined by the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budgeted time. The amount of data that can be transmitted within the budgeted time is determined by the current available bandwidth and the budgeted time. The latency ratio is determined by the ratio of the current transmission latency to the maximum allowable transmission latency.

[0162] S315, the source device obtains the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device according to the model migration strategy.

[0163] S316, the source device encrypts the migration parameter set to obtain encrypted data.

[0164] S317, the source device transmits encrypted data and a first hash digest generated from the migration parameter set to the target device.

[0165] S318, the source device registers the first hash digest with the third-party device and obtains the second hash digest stored in the third-party device.

[0166] S319, the third-party device sends the second hash digest to the target device.

[0167] S320: The target device decrypts the encrypted data to obtain the plaintext parameters.

[0168] S321, the target device compares the first hash digest and the second hash digest obtained from the third-party device with the third hash digest generated based on the parameter plaintext. If the first hash digest, the second hash digest and the third hash digest are consistent, the parameter plaintext is determined to be the migration parameter set obtained from the target model.

[0169] S322, the target device adapts and transforms the migration parameter set according to the target device's hardware configuration information to obtain a target migration parameter set adapted to the target device's hardware configuration.

[0170] The process of adapting and transforming the migration parameter set according to the hardware configuration information of the target device to obtain a target migration parameter set adapted to the hardware configuration of the target device includes: quantizing and compressing the migration parameter set according to the computing resource parameters in the hardware configuration information of the target device to obtain a target migration parameter set adapted to the computing resource parameters; and / or determining a set of candidate operators adapted to the target device according to the hardware configuration information of the target device, so as to replace the original operators in the migration parameter set with functionally equivalent target operators in the candidate operator set to obtain the target migration parameter set.

[0171] S323, The target device deploys the target model based on the target migration parameter set.

[0172] S324. During the process of transmitting the migration parameter set to the target device, the source device processes the received service requests based on the service instances generated by the target model and records the current processing status of the service requests.

[0173] S325, the source device synchronizes the current processing status to the target device.

[0174] S326, the target device determines that it has completed the model deployment based on the target migration parameter set and sends the corresponding prompt information to the source device.

[0175] S327, In response to the prompt message, the source device will forward any service requests received after the prompt message to the target device for processing.

[0176] Figure 5A first structural schematic diagram of a model migration apparatus provided in this application is shown. It should be understood that this apparatus corresponds to the method embodiments executed in the above embodiments and is capable of performing the steps involved in the aforementioned methods. The specific functions of this apparatus can be found in the description above; detailed descriptions are omitted here to avoid repetition. The apparatus includes at least one software function module that can be stored in a memory or embedded in the operating system (OS) of the apparatus in the form of software or firmware. Specifically, this apparatus is applied to a source device to implement model migration. The apparatus includes: a hardware difference identification module 410, used to determine the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device; a migration strategy determination module 420, used to determine a corresponding model migration strategy based on the hardware difference; a migration parameter acquisition module 430, used to acquire a migration parameter set corresponding to the model migration strategy from the target model deployed on the source device according to the model migration strategy; and a migration parameter transmission module 440, used to transmit the migration parameter set to the target device.

[0177] In one embodiment, the hardware difference recognition module 410 is further configured to: The system determines that the identity authentication of the target device has been successful and receives authentication information indicating that the target device has successfully authenticated the identity of the source device. Based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device, the system determines the hardware difference between the source device and the target device.

[0178] In one embodiment, the migration strategy determination module 420 is specifically used for: The corresponding migration score is determined by weighting the hardware differences, the obtained transmission load rate, and the latency ratio. Based on the migration score, the corresponding model migration strategy is determined; The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration, and the amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

[0179] In one embodiment, the migration parameter acquisition module 430 is specifically used for: If the model migration strategy is determined to be a core parameter migration strategy, at least one target network layer is determined from each network layer based on the importance evaluation parameters of each network layer in the target model. The migration parameter set is obtained based on the parameters of each target network layer; The importance evaluation parameters include at least one of the following: the proportion of parameters in the network layer, the contribution of the network layer to the output accuracy of the target model, and the parameter update frequency of the network layer. The percentage of parameters in the network layer is determined based on the number of parameters in the network layer and the total number of parameters in the target model.

[0180] In one embodiment, the migration parameter acquisition module 430 is specifically used for: The importance score of a network layer is determined based on the importance evaluation parameters of any network layer in the target model. Based on the importance score of each network layer, the target network layer is selected sequentially from the network layers in descending order of importance score, until the total number of parameters of each target network layer is within a preset range; The preset range is determined based on the total number of parameters of the target model and a preset ratio range, and the preset ratio range is positively correlated with the current available bandwidth.

[0181] In one embodiment, the migration parameter transmission module 440 is specifically used for: The migration parameter set is encrypted to obtain encrypted data; The encrypted data and a first hash digest generated from the migration parameter set are transmitted to the target device, and the first hash digest is registered with a third-party device to obtain a second hash digest stored in the third-party device. The target device then verifies the migration parameter set based on the comparison result between the first hash digest and the second hash digest and the third hash digest generated from the migration parameter set obtained from the encrypted data.

[0182] In one embodiment, the migration parameter transmission module 440 is further configured to: During the process of transmitting the migration parameter set to the target device, the received service requests are processed according to the service instance generated by the target model, the current processing status of the service requests is recorded, and the current processing status is synchronized to the target device. In response to a prompt message instructing the target device to complete model deployment based on the received migration parameter set, service requests received after the prompt message are forwarded to the target device for processing.

[0183] Figure 6A second structural schematic diagram of a model migration apparatus provided in this application is presented. It should be understood that this apparatus corresponds to the method embodiments executed in the above embodiments and is capable of performing the steps involved in the aforementioned methods. The specific functions of this apparatus can be found in the description above; detailed descriptions are omitted here to avoid repetition. The apparatus includes at least one software functional module that can be stored in memory or embedded in the operating system (OS) of the apparatus in the form of software or firmware. Specifically, this apparatus is applied to a target device for implementing model migration. The device includes: a configuration information sending module 510, used to send hardware configuration information of the target device to a source device, so that the source device determines a corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device; a migration parameter receiving module 520, used to receive a migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; and a target model deployment module 530, used to deploy the target model according to the migration parameter set; wherein, the source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, so as to determine the corresponding model migration strategy based on the hardware difference.

[0184] In one embodiment, the configuration information sending module 510 is further configured to: Once it is confirmed that the source device has passed authentication and authentication information indicating that the source device has passed authentication of the target device has been received, the hardware configuration information of the target device is sent to the source device.

[0185] In one embodiment, the migration parameter receiving module 520 is specifically used for: Receive encrypted data and a first hash digest sent by the source device; The encrypted data is decrypted to obtain the plaintext parameters; The first hash digest and the second hash digest obtained from the third-party device are compared with the third hash digest generated in plaintext according to the parameters; If the first hash digest, the second hash digest, and the third hash digest are consistent, the plaintext of the parameters is determined to be the set of migration parameters obtained from the target model.

[0186] In one embodiment, the target model deployment module 530 is specifically used for: Based on the hardware configuration information of the target device, the migration parameter set is adapted and converted to obtain a target migration parameter set adapted to the hardware configuration of the target device; Deploy the target model based on the target migration parameter set.

[0187] In one embodiment, the target model deployment module 530 is specifically used for: Based on the computing resource parameters in the hardware configuration information of the target device, the migration parameter set is quantized and compressed to obtain a target migration parameter set adapted to the computing resource parameters.

[0188] In one embodiment, the target model deployment module 530 is specifically used for: Based on the hardware configuration information of the target device, determine the set of candidate operators adapted to the target device; Based on the candidate operator set, the original operators in the migration parameter set are replaced with functionally equivalent target operators in the candidate operator set to obtain the target migration parameter set.

[0189] In one embodiment, the target model deployment module 530 is further configured to: During the process of receiving the migration parameter set, the current processing status of the service requests processed by the service instance generated by the source device according to the target model is received; Once the model deployment is completed based on the received migration parameter set, a corresponding prompt message is sent to the source device so that the source device responds to the prompt message and forwards any service requests received after the prompt message to the target device for processing.

[0190] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7 As shown, the electronic device can be a source device or a target device, and may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840. The processor 810, communication interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call a computer program in the memory 830 to execute a model transfer method, such as including: Based on the differences in hardware configuration parameters of the same hardware configuration item between the source device and the target device, the hardware difference between the source device and the target device is determined; based on the hardware difference, a corresponding model migration strategy is determined; based on the model migration strategy, a migration parameter set corresponding to the model migration strategy is obtained from the target model deployed on the source device; the migration parameter set is transmitted to the target device so that the target device deploys the target model according to the migration parameter set.

[0191] Alternatively, the source device may send the hardware configuration information of the target device to the source device, so that the source device determines a corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device; receive a migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; and deploy the target model according to the migration parameter set; wherein the source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, so as to determine the corresponding model migration strategy based on the hardware difference.

[0192] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0193] On the other hand, this application also provides a storage medium, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the model transfer method provided in the above embodiments.

[0194] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0195] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0196] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A model transfer method, characterized in that, Applied to source devices, including: The hardware difference between the source device and the target device is determined based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. The hardware differences, the obtained transmission load rate, and the latency ratio are weighted to determine the corresponding migration score, and the corresponding model migration strategy is determined based on the migration score. According to the model migration strategy, obtain the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device; The migration parameter set is transmitted to the target device so that the target device deploys the target model according to the migration parameter set; The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration, and the amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

2. The model transfer method according to claim 1, characterized in that, The degree of difference in hardware configuration parameters of the same hardware configuration item between the source device and the target device, based on their hardware configuration information, includes: The system determines that the identity authentication of the target device has been successful and receives authentication information indicating that the target device has successfully authenticated the identity of the source device. Based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device, the system determines the hardware difference between the source device and the target device.

3. The model transfer method according to claim 1 or 2, characterized in that, The step of determining the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device includes: Based on the hardware configuration information of the source device and the target device, the degree of difference of the hardware configuration item is determined for the same hardware configuration parameter. Based on the preset weights of each hardware configuration item, the degree of difference between each hardware configuration item is weighted to determine the degree of hardware difference between the source device and the target device.

4. The model transfer method according to claim 1, characterized in that, The step of obtaining the migration parameter set corresponding to the model migration strategy from the target model deployed on the source device according to the model migration strategy includes: If the model migration strategy is determined to be a core parameter migration strategy, at least one target network layer is determined from each network layer based on the importance evaluation parameters of each network layer in the target model. The migration parameter set is obtained based on the parameters of each target network layer; The importance evaluation parameters include at least one of the following: the proportion of parameters in the network layer, the contribution of the network layer to the output accuracy of the target model, and the parameter update frequency of the network layer. The percentage of parameters in the network layer is determined based on the number of parameters in the network layer and the total number of parameters in the target model.

5. The model transfer method according to claim 4, characterized in that, The step of determining at least one target network layer from each of the network layers based on the importance evaluation parameters of any network layer in the target model includes: The importance score of a network layer is determined based on the importance evaluation parameters of any network layer in the target model. Based on the importance score of each network layer, the target network layer is selected sequentially from the network layers in descending order of importance score, until the total number of parameters of each target network layer is within a preset range; The preset range is determined based on the total number of parameters of the target model and a preset ratio range, and the preset ratio range is positively correlated with the current available bandwidth.

6. The model transfer method according to any one of claims 1-2 and 4-5, characterized in that, The transmission of the migration parameter set to the target device includes: The migration parameter set is encrypted to obtain encrypted data; The encrypted data and a first hash digest generated from the migration parameter set are transmitted to the target device, and the first hash digest is registered with a third-party device to obtain a second hash digest stored in the third-party device. The target device then verifies the migration parameter set based on the comparison result between the first hash digest and the second hash digest and the third hash digest generated from the migration parameter set obtained from the encrypted data.

7. The model transfer method according to any one of claims 1-2 and 4-5, characterized in that, Also includes: During the process of transmitting the migration parameter set to the target device, the received service requests are processed according to the service instance generated by the target model, the current processing status of the service requests is recorded, and the current processing status is synchronized to the target device. In response to a prompt message instructing the target device to complete model deployment based on the received migration parameter set, service requests received after the prompt message are forwarded to the target device for processing.

8. A model transfer method, characterized in that, Applied to target devices, including: Send the hardware configuration information of the target device to the source device so that the source device can determine the corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. Receive the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; Deploy the target model based on the migration parameter set; The source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, and to determine the corresponding model migration strategy based on the migration score obtained by weighting the hardware difference, the obtained transmission load rate and the latency ratio. The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration. The amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

9. The model transfer method according to claim 8, characterized in that, The step of sending the hardware configuration information of the target device to the source device includes: Once it is confirmed that the source device has passed authentication and authentication information indicating that the source device has passed authentication of the target device has been received, the hardware configuration information of the target device is sent to the source device.

10. The model transfer method according to claim 8, characterized in that, The step of receiving the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy includes: Receive encrypted data and a first hash digest sent by the source device; The encrypted data is decrypted to obtain the plaintext parameters; The first hash digest and the second hash digest obtained from the third-party device are compared with the third hash digest generated in plaintext according to the parameters; If the first hash digest, the second hash digest, and the third hash digest are consistent, the plaintext of the parameters is determined to be the set of migration parameters obtained from the target model.

11. The model transfer method according to any one of claims 8-10, characterized in that, Deploying the target model based on the migration parameter set includes: Based on the hardware configuration information of the target device, the migration parameter set is adapted and converted to obtain a target migration parameter set adapted to the hardware configuration of the target device; Deploy the target model based on the target migration parameter set.

12. The model transfer method according to claim 11, characterized in that, The step of adapting and converting the migration parameter set according to the hardware configuration information of the target device to obtain a target migration parameter set adapted to the hardware configuration of the target device includes: Based on the computing resource parameters in the hardware configuration information of the target device, the migration parameter set is quantized and compressed to obtain a target migration parameter set adapted to the computing resource parameters.

13. The model transfer method according to claim 11, characterized in that, The step of adapting and converting the migration parameter set according to the hardware configuration information of the target device to generate target migration parameters adapted to the hardware configuration of the target device includes: Based on the hardware configuration information of the target device, determine the set of candidate operators adapted to the target device; Based on the candidate operator set, the original operators in the migration parameter set are replaced with functionally equivalent target operators in the candidate operator set to obtain the target migration parameter set.

14. The model transfer method according to any one of claims 8-10, characterized in that, Also includes: During the process of receiving the migration parameter set, the current processing status of the service requests processed by the service instance generated by the source device according to the target model is received; Once the model deployment is completed based on the received migration parameter set, a corresponding prompt message is sent to the source device so that the source device responds to the prompt message and forwards any service requests received after the prompt message to the target device for processing.

15. A model transfer device, characterized in that, Applied to source devices, including: The hardware difference identification module is used to determine the hardware difference between the source device and the target device based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. The migration strategy determination module is used to weight the hardware difference, the obtained transmission load rate and the latency ratio to determine the corresponding migration score, and to determine the corresponding model migration strategy based on the migration score. The migration parameter acquisition module is used to acquire a set of migration parameters corresponding to the model migration strategy from the target model deployed on the source device, according to the model migration strategy. A migration parameter transmission module is used to transmit the migration parameter set to the target device, so that the target device can deploy the target model according to the migration parameter set; The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration, and the amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

16. A model transfer device, characterized in that, Applied to target devices, including: The configuration information sending module is used to send the hardware configuration information of the target device to the source device, so that the source device can determine the corresponding model migration strategy based on the difference in hardware configuration parameters of the same hardware configuration item between the hardware configuration information of the source device and the target device. The migration parameter receiving module is used to receive the migration parameter set obtained by the source device from the target model deployed on the source device according to the model migration strategy; The target model deployment module is used to deploy the target model according to the migration parameter set; The source device is used to determine the hardware difference between the source device and the target device based on the hardware configuration information of the source device and the target device, and to determine the corresponding model migration strategy based on the migration score obtained by weighting the hardware difference, the obtained transmission load rate and the latency ratio. The transmission load rate is determined based on the ratio of the total number of parameters of the target model to the amount of data that can be transmitted within the budget duration. The amount of data that can be transmitted within the budget duration is determined based on the current available bandwidth and the budget duration. The delay ratio is determined based on the ratio of the current transmission delay to the maximum allowable transmission delay.

17. An electronic device, characterized in that, It includes a processor and a memory storing a computer program, wherein the processor executes the computer program to implement the model transfer method according to any one of claims 1-14.

Images