Method for terminal loading model and related apparatus

Abstract

The application relates to a terminal loading model method and related devices. The method comprises the following steps: in response to a user switching event, determining a target user identifier corresponding to the user switching event, and obtaining a first model incremental parameter associated with the target user identifier; performing incremental optimization processing on a general base model pre-stored in the terminal by using the first model incremental parameter, obtaining a lightweight adaptive model associated with the target user identifier, and loading the lightweight adaptive model as a service model for responding to user demand; in the case of determining that a full model downloading condition is met, sending a second request to a server, and receiving a full adaptive model corresponding to the target user identifier returned by the server based on the second request; loading the full adaptive model, and switching the service model from the lightweight adaptive model to the full adaptive model. The method can meet the demand of quickly loading a personalized model, providing personalized services with low delay, and providing fine personalized services.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to a method and related apparatus for loading a terminal model, wherein the related apparatus includes: a terminal model loading device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the development of artificial intelligence (AI) technology, configuring personalized models (such as assisted driving models and personalized interaction models) for users on terminals (such as vehicles, smart terminals, and intelligent robots) has become an important direction for the development of AI and intelligent interaction technologies. However, many terminals may be used by different end users. For example, a vehicle may be driven by different drivers and carry different passengers. The level of detail in the personalized services provided will also affect the service experience. Therefore, there is a need to quickly load the personalized model corresponding to the new user when the terminal switches to a different user, so as to provide personalized services quickly and with refined detail. Summary of the Invention

[0003] Based on this, it is necessary to provide a method and related apparatus for a terminal loading model that facilitates the provision of personalized services with low latency and rapid delivery, as well as the provision of refined personalized services, in response to the aforementioned technical problems. The related apparatus includes: a terminal loading model device, an electronic device, a computer-readable storage medium, and a computer program product.

[0004] Firstly, this application provides a method for loading a terminal model, applied to a terminal, the method comprising:

[0005] In response to a user switching event, the target user identifier corresponding to the user switching event is determined, and the first model incremental parameter associated with the target user identifier is obtained;

[0006] The first model incremental parameters are used to perform incremental optimization on the general base model pre-stored in the terminal to obtain the lightweight adaptation model associated with the target user identifier, and the lightweight adaptation model is loaded as a service model to respond to user needs.

[0007] If the conditions for downloading the full model are met, a second request is sent to the server. The second request includes the target user identifier. The server returns the full-adapted model corresponding to the target user identifier based on the second request. The full-adapted model has the same model architecture as the lightweight adapted model.

[0008] Load the full-adaptation model, and switch the service model from the lightweight adaptation model to the full-adaptation model.

[0009] The terminal loading model method based on this embodiment, in the event of a user switching event, indicates that it is necessary to switch to the model associated with the target user identifier switched to by the user switching event, in order to provide personalized services to the user corresponding to the target user identifier. In this case, based on determining the target user identifier corresponding to the user switching event, the first model incremental parameter associated with the target user identifier is obtained, and the first model incremental parameter is used to perform incremental optimization processing on the general base model pre-stored in the terminal to obtain a lightweight adaptation model associated with the target user identifier. The lightweight adaptation model is then loaded as a service model to respond to user needs. Thus, a lightweight adaptation model is first generated and run based on the first model incremental parameter associated with the target user identifier, thereby enabling rapid generation and loading of the target user identifier. The system uses a lightweight, personalized adaptation model corresponding to each user identifier to meet the needs of low-latency, fast loading and use of the user's personalized model to provide personalized services. Furthermore, while using the lightweight adaptation model to provide personalized services, and provided the full model download condition is met, the terminal sends a second request to the server to obtain the full adaptation model corresponding to the target user identifier, loads the full adaptation model, and switches the service model from the lightweight adaptation model to the full adaptation model. This achieves the requirement of silently downloading the full adaptation model while using the lightweight adaptation model, and switching to the full adaptation model after downloading the full adaptation model to provide refined personalized services. This satisfies the needs of fast loading of personalized models for low-latency, fast provision of personalized services, and the provision of refined personalized services.

[0010] In some feasible embodiments, obtaining the first model incremental parameters associated with the target user identifier includes:

[0011] Send a first request to the server, the first request including the target user identifier;

[0012] The server receives a first response based on the first request, the first response including a first model incremental parameter corresponding to the target user identifier.

[0013] Accordingly, in the process of obtaining the first model incremental parameters associated with the target user identifier, a first request can be sent to the server to quickly obtain the first model incremental parameters associated with the target user identifier from the server. In this case, even if the terminal does not have the first model incremental parameters corresponding to the target user identifier pre-stored locally, since the first model incremental parameters are lightweight model parameters, the time to obtain the first model incremental parameters from the server will be short. Thus, a lightweight adaptation model can be quickly generated and loaded based on the first model incremental parameters, which can meet the needs of low-latency, fast, and personalized adaptation models to provide personalized services.

[0014] In some feasible embodiments, obtaining the first model incremental parameters associated with the target user identifier includes:

[0015] Based on the correspondence between user identifiers and model incremental parameters, the first model incremental parameter associated with the target user identifier is obtained from multiple model incremental parameters pre-stored in the terminal.

[0016] Accordingly, multiple user identifiers and model incremental parameters can be stored in the terminal. During the process of obtaining the first model incremental parameter associated with the target user identifier, the first model incremental parameter associated with the target user identifier can be obtained from the terminal. This allows the first model incremental parameter associated with the target user identifier to be obtained from multiple model incremental parameters pre-stored in the terminal, even when the network is poor. This enables the rapid generation and loading of a lightweight adaptation model based on the first model incremental parameter, which can meet the needs of low-latency, fast, and personalized adaptation models to provide personalized services.

[0017] In some feasible embodiments, upon determining that the conditions for downloading the full model are met, a second request is sent to the server, including:

[0018] Continuously acquire primary network status information and service operation information;

[0019] If the network is determined to be stable based on the first network status information, and if no high-priority services are running based on the service operation information, a second request is sent to the server.

[0020] Based on this embodiment, during the operation of the lightweight adaptation model, the terminal can continuously obtain the terminal status. When the terminal's network is stable and there are no high-priority services running, it indicates that the terminal is in a gap between service operations. Therefore, the terminal can send a second request to the server, so that the terminal can download the full adaptation model from the server during the gap between service operations. Thus, the full adaptation model can be downloaded silently from the server without affecting the terminal's service operation.

[0021] In some feasible embodiments, the service model is switched from a lightweight adaptation model to a full adaptation model, including:

[0022] During periods of downtime, switch the service model from a lightweight adaptation model to a full adaptation model.

[0023] Therefore, during business downtime, the loaded service model is switched from the lightweight adaptation model to the full adaptation model. That is, without affecting the terminal business, the loaded service model is switched from the lightweight adaptation model to the full adaptation model, thus achieving seamless switching of the adaptation model of the provided personalized server.

[0024] Secondly, this application also provides a method for loading a terminal model, applied to a server, the method comprising:

[0025] In response to receiving an acquisition instruction generated by the terminal based on a user switching event, the system determines the target user identifier corresponding to the user switching event, acquires the first model incremental parameter associated with the target user identifier, and sends the first model incremental parameter to the terminal.

[0026] In response to receiving a second request from the terminal, the second request including the target user identifier, the system obtains the full adaptation model associated with the target user identifier and sends the full adaptation model to the terminal.

[0027] In the terminal loading model method of this embodiment, when the server receives an acquisition instruction generated and sent by the terminal based on a user switching event, it first determines the target user identifier corresponding to the user switching event, then obtains the first model incremental parameter associated with the target user identifier and sends it to the terminal. This helps the terminal to incrementally optimize the pre-stored general base model using the first model incremental parameter, obtain a lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model. This allows for the rapid generation and loading of a personalized lightweight adaptation model corresponding to the target user identifier, meeting the terminal's need for low-latency, fast loading and use of the user's personalized model to provide personalized services. Furthermore, during the process of the terminal using the lightweight adaptation model to provide personalized services, upon receiving a second request from the terminal, the server obtains the full adaptation model associated with the target user identifier and sends it to the terminal. This enables the terminal to switch the loaded and running service model from the lightweight adaptation model to the full adaptation model, meeting the need to switch to the full adaptation model to provide refined personalized services. Thus, the terminal's needs for rapid loading of personalized models to provide personalized services with low latency and refined personalized services can be met simultaneously.

[0028] In some feasible embodiments, obtaining the first model incremental parameter associated with the target user identifier includes:

[0029] Obtain the terminal's status information;

[0030] From the multiple model incremental parameters associated with the target user identifier, the parameter that matches the terminal state information is obtained as the first model incremental parameter, wherein the compression ratio of the first model incremental parameter relative to the full model parameters of the full-adaptation model is positively correlated with the terminal state reflected by the terminal state information.

[0031] Accordingly, the server can store multiple model incremental parameters associated with the target user identifier. By obtaining the terminal's terminal status information, the server selects the first model incremental parameter that matches the terminal status information from the multiple model incremental parameters associated with the target user identifier. This ensures that the first model incremental parameter returned by the server to the terminal matches the terminal status, thereby improving the terminal's business performance while enabling the terminal to quickly load personalized models and provide personalized services with low latency.

[0032] In some feasible embodiments, the terminal's terminal status information includes: the terminal's second network status information.

[0033] Accordingly, in the process of obtaining the first model incremental parameter that matches the terminal state information from multiple model incremental parameters associated with the target user identifier, the first model incremental parameter to be obtained is determined based on the terminal's second network state information. This allows for the rapid determination of the first model incremental parameter to be returned, and the determined first model incremental parameter matches the terminal's network state. In other words, the first model incremental parameter that matches the terminal's network state is sent to the terminal, which is beneficial for the terminal to generate and load personalized lightweight adaptation models, and provide personalized services quickly with low latency.

[0034] In some feasible embodiments, sending the full adaptation model to the terminal includes:

[0035] The full adaptation model is sent to the terminal by means of segmented breakpoint resume transmission.

[0036] Accordingly, when the server sends the full adaptation model to the terminal, it does so by transmitting the data in segments with interrupted transmission, which can improve the reliability of transmitting the full adaptation model.

[0037] In some feasible embodiments, the method further includes:

[0038] Obtain user profile data associated with the target user identifier;

[0039] The general base model is trained based on user profile data to obtain the full-scale adapted model corresponding to the target user identifier;

[0040] The model parameters of the fully adapted model are decomposed to obtain the general base parameters, personalized core parameters and low-frequency secondary parameters of the fully adapted model.

[0041] The personalized core parameters are compressed to obtain the incremental parameters of the model associated with the target user identifier.

[0042] Accordingly, the server can obtain user profile data associated with the target user identifier, and train the general base model based on the user profile data to obtain a full-fit model for the target user identifier. Based on the obtained full-fit model, the model parameters of the full-fit model are decomposed to extract personalized core parameters. These personalized core parameters are then compressed to obtain the model incremental parameters associated with the target user identifier. In other words, the obtained model incremental parameters are obtained only based on the compression of personalized core parameters and do not involve the general base parameters and low-frequency secondary parameters of the general base model. This enables lightweight transmission of personalized core parameters, as well as the generation and loading of a lightweight fit model based on them, while ensuring personalized services.

[0043] In some feasible embodiments, the personalized core parameters are compressed to obtain incremental model parameters associated with the target user identifier, including:

[0044] The personalized core parameters are sequentially processed by INT8 fixed-point quantization, sparse pruning, and low-rank decomposition of the parameter matrix to obtain the incremental parameters of the model associated with the target user identifier.

[0045] Therefore, by sequentially performing INT8 fixed-point quantization, sparse pruning, and low-rank decomposition of the parameter matrix on the personalized core parameters, the compression effect of the personalized core parameters can be effectively improved.

[0046] Thirdly, this application also provides a device for loading a terminal model, disposed on a terminal, the device comprising:

[0047] A lightweight parameter acquisition module is used to respond to a user switching event, determine the target user identifier corresponding to the user switching event, and acquire the first model incremental parameter associated with the target user identifier;

[0048] The lightweight model loading module is used to incrementally optimize the general base model pre-stored in the terminal using the first model incremental parameters, obtain the lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model as a service model for responding to user needs.

[0049] The full model acquisition module is used to send a second request to the server when it is determined that the conditions for downloading the full model are met. The second request includes the target user identifier, and the module receives the full adapted model corresponding to the target user identifier returned by the server based on the second request. The full adapted model has the same model architecture as the lightweight adapted model.

[0050] The full model loading module is used to load the full adaptation model and switch the service model from the lightweight adaptation model to the full adaptation model.

[0051] Fourthly, this application also provides a terminal loading model apparatus, disposed on a server, the apparatus comprising:

[0052] A lightweight model processing module is used to respond to a terminal's acquisition instruction generated based on a user switching event, which is sent by the terminal, to determine the target user identifier corresponding to the user switching event, acquire the first model incremental parameter associated with the target user identifier, and send the first model incremental parameter to the terminal.

[0053] The full model processing module is used to respond to receiving a second request sent by the terminal, the second request including the target user identifier, to obtain the full adaptation model associated with the target user identifier, and to send the full adaptation model to the terminal.

[0054] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the terminal loading model method of any of the above embodiments.

[0055] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the terminal loading model method of any of the above embodiments.

[0056] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the terminal loading model method of any of the above embodiments. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is an application environment diagram of a terminal loading model method in one embodiment;

[0059] Figure 2 This is a flowchart illustrating a method for loading a model on a terminal in one embodiment;

[0060] Figure 3This is a schematic diagram of the process for obtaining the first model incremental parameters in one embodiment;

[0061] Figure 4 This is a schematic diagram of the process of sending a second request to the server in one embodiment;

[0062] Figure 5 A flowchart illustrating the terminal loading model method in another embodiment;

[0063] Figure 6 This is a flowchart illustrating the process of obtaining the first model increment parameters in another embodiment;

[0064] Figure 7 This is a flowchart illustrating the process of obtaining incremental parameters of a model associated with a target user identifier based on user profile data in one embodiment.

[0065] Figure 8 This is a schematic diagram of the system architecture in a specific example;

[0066] Figure 9 This is a flowchart illustrating the two-way interaction between an in-vehicle terminal and a server in a specific example.

[0067] Figure 10 This is a schematic diagram of a device for a terminal loading model in one embodiment;

[0068] Figure 11 A schematic block diagram of a device for loading a terminal model in another embodiment;

[0069] Figure 12 This is a schematic block diagram of a computer device in one embodiment;

[0070] Figure 13 This is a schematic block diagram of an electronic device in one embodiment. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0072] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0073] It should be noted that all information and data involved in this application (including but not limited to data used for analysis, stored data, and displayed data) are authorized by the user or fully authorized by all parties, and the acquisition, transmission, storage, use, and processing of the relevant data comply with the relevant provisions of national laws and regulations. Users can refuse content pushed to them or conveniently refuse content pushes. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, and their purpose is merely to illustrate the feasibility of implementing the technical solution of this application, but does not mean that the applicant has already used or necessarily used such a solution.

[0074] In terminals that provide personalized services by loading user-specific models, the speed at which the personalized model of the switched or new user is loaded and run, as well as the level of detail in the services provided by the loaded personalized model, directly impacts the user experience of the personalized services offered by the terminal. In related technologies, lightweight personalized models are typically stored on the terminal. However, lightweight models struggle to provide detailed personalized services. Storing the full models of each user directly on the terminal can consume significant storage space, especially with a large number of registered users. Another approach involves downloading the full user model from a server for loading and running. However, this method places high demands on the terminal's network performance. If the terminal's network is poor, and the full model data is typically large, it may be impossible to quickly obtain the full user model from the server, thus hindering the timely activation of the user's personalized model to provide personalized services, severely impacting the user experience.

[0075] Research has revealed that in the initial stages of personalized services on a user's device, and as a core requirement, rapid response to user instructions is paramount. Therefore, the quick activation of the personalized model directly impacts the user experience. Consequently, for a user's full-scale adapted model, its parameters can be compressed to generate incremental model parameters. When switching devices to different users, a lightweight adapted model can be generated based on these incremental parameters and loaded and run immediately to provide personalized services quickly and with low latency. Once the full-scale model download condition is met, the user's full-scale adapted model is downloaded from the server. After downloading, the loaded and running model is switched from the user's lightweight adapted model to the full-scale adapted model to meet the needs of refined personalized services. This approach satisfies the requirements for rapidly loading personalized models for low-latency and high-speed personalized services, as well as the need for refined personalized services.

[0076] Accordingly, embodiments of this application provide an identity recognition method that can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Terminal 102 can identify or obtain the user identifier of the user requiring service. When a user switching event occurs, it uses the first model incremental parameters associated with the target user identifier after the switch to incrementally optimize the pre-stored general base model using the first model incremental parameters, obtaining a lightweight adaptation model associated with the target user identifier. This lightweight adaptation model is then loaded as a service model to respond to user needs, ensuring low-latency and rapid provision of personalized services. If the conditions for downloading the full model are met, the full adaptation model corresponding to the target user identifier is downloaded from server 104, and the loaded service model is switched from the lightweight adaptation model to the full adaptation model to meet the needs of refined personalized services. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0077] In one exemplary embodiment, such as Figure 2 As shown, a method for loading a terminal model is provided, which is then applied to... Figure 1 Taking terminal 102 as an example, the explanation includes the following steps 201 to 204. Wherein:

[0078] Step 201: In response to a user switching event, determine the target user identifier corresponding to the user switching event, and obtain the first model incremental parameter associated with the target user identifier.

[0079] A user switching event refers to an event that triggers a change in the user's identity on a terminal. This could be an event that triggers the terminal to log out of a previously logged-in user account and log in to another user's account, or an event that registers and logs in to a new user on the terminal. Taking a vehicle as an example, a user switching event can be determined when the vehicle detects a new user boarding (e.g., the detected user's characteristics do not match the characteristics of stored users), or when a driver / passenger switching event is detected (e.g., the detected user is inconsistent with the currently logged-in or loaded user, or a user switching command is received). The specific method for identifying a new user boarding event or a driver / passenger switching event can be any feasible method from related technologies, and this application embodiment does not impose specific limitations. When the logged-in user changes, the user's personalized configuration needs to be switched synchronously. In this application embodiment, in response to a user switching event, the target user identifier corresponding to the user switching event can be determined, and the first model incremental parameter associated with the target user identifier can be obtained.

[0080] Among them, the target user identifier refers to the user identifier of the newly logged-in user, and the first model incremental parameter associated with the target user identifier refers to the model parameter obtained by compressing the personalized core parameters of the full-scale adaptation model associated with the target user identifier.

[0081] Step 202: Use the first model incremental parameters to perform incremental optimization on the general base model pre-stored in the terminal to obtain the lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model as a service model to respond to user needs.

[0082] Based on the obtained first model increment parameters, the general base model pre-stored in the terminal can be incrementally optimized to obtain a personalized adaptation model of the target user identifier. This adaptation model is determined by incremental adjustment based on the compressed first model increment parameters of the target user identifier. Therefore, the model obtained after incremental adjustment is a lightweight model, which is referred to as the lightweight adaptation model in this application embodiment.

[0083] Loading the lightweight adaptation model as a service model to respond to user needs refers to loading the model parameters of the lightweight adaptation model into the terminal memory and distributing them to various subsystems of the terminal to enter the exclusive state of the user corresponding to the target user identifier, thereby providing personalized services to the user corresponding to the target user identifier. The specific method of loading the lightweight adaptation model can adopt any feasible loading model method in related technologies, and this application embodiment does not impose specific limitations on it.

[0084] Step 203: If the conditions for downloading the full model are met, send a second request to the server. The second request includes the target user identifier. Receive the full-fit model corresponding to the target user identifier returned by the server based on the second request. The full-fit model has the same model architecture as the lightweight fit model.

[0085] The conditions for downloading the full model refer to the conditions under which the user's full model can be downloaded from the server. If the conditions for downloading the full model are met, it means that the terminal's current state allows it to download the user's full model from the server. Therefore, a second request can be sent to the server, requesting the download of the full model corresponding to the target user identifier.

[0086] The specific method for setting the conditions for full model download is not limited. In some examples, it can be determined based on at least one of the terminal's network status information and service operation information. For example, in some examples, the full model download condition can be determined if it is determined that no high-priority service is running based on the service operation information. In some examples, the full model download condition can be determined if it is determined that the network is stable based on the terminal's network status information. In other examples, the full model download condition can be determined if it is determined that the network is stable based on the network status information and that no high-priority service is running based on the service operation information.

[0087] Step 204: Load the full-adaptation model and switch the service model from the lightweight adaptation model to the full-adaptation model.

[0088] Based on the full-fit model downloaded from the server, the service model loaded on the terminal to respond to user needs can be switched from the lightweight fit model corresponding to the target user identifier to the full-fit model, thereby providing refined personalized services through the full-fit model.

[0089] The terminal loading model method based on this embodiment, in the event of a user switching event, indicates that it is necessary to switch to the model associated with the target user identifier switched to by the user switching event, in order to provide personalized services to the user corresponding to the target user identifier. In this case, based on determining the target user identifier corresponding to the user switching event, the first model incremental parameter associated with the target user identifier is obtained, and the first model incremental parameter is used to perform incremental optimization processing on the general base model pre-stored in the terminal to obtain a lightweight adaptation model associated with the target user identifier. The lightweight adaptation model is then loaded as a service model to respond to user needs. Thus, a lightweight adaptation model is first generated and run based on the first model incremental parameter associated with the target user identifier, thereby enabling rapid generation and loading of the target user identifier. The system uses a lightweight, personalized adaptation model corresponding to each user identifier to meet the needs of low-latency, fast loading and use of the user's personalized model to provide personalized services. Furthermore, while using the lightweight adaptation model to provide personalized services, and provided the full model download condition is met, the terminal sends a second request to the server to obtain the full adaptation model corresponding to the target user identifier, loads the full adaptation model, and switches the service model from the lightweight adaptation model to the full adaptation model. This achieves the requirement of silently downloading the full adaptation model while using the lightweight adaptation model, and switching to the full adaptation model after downloading the full adaptation model to provide refined personalized services. This satisfies the needs of fast loading of personalized models for low-latency, fast provision of personalized services, and the provision of refined personalized services.

[0090] There are no limitations on the method for obtaining the first model incremental parameters associated with the target user identifier. In some feasible embodiments, refer to Figure 3 As shown, obtaining the first model incremental parameters associated with the target user identifier may include:

[0091] Step 301: Send a first request to the server, the first request including the target user identifier.

[0092] The first request is a request to download the user's incremental model parameters from the server. In some embodiments, the first request may further include a first identifier to indicate to the server that the first request is a request to download the incremental model parameters. Correspondingly, in some embodiments, the aforementioned second request may include a second identifier to indicate to the server that the second request is a request to download the fully adapted model.

[0093] The specific information content of the first and second identifiers is not limited; they can be specific text or symbolic identifiers. This application does not impose specific limitations on the embodiments thereof.

[0094] Step 302: Receive the first response returned by the server based on the first request. The first response includes the first model incremental parameter corresponding to the target user identifier.

[0095] Upon receiving the first request, the server can obtain the first model incremental parameter associated with the target user identifier and return a first response to the terminal, thereby sending the first model incremental parameter associated with the target user identifier to the terminal. The terminal can obtain the first model incremental parameter based on the first response returned by the server.

[0096] Accordingly, in the process of obtaining the first model incremental parameter associated with the target user identifier corresponding to the switching event, a first request can be sent to the server to quickly obtain the first model incremental parameter associated with the target user identifier from the server. In this case, even if the terminal does not have the first model incremental parameter corresponding to the target user identifier pre-stored locally, since the first model incremental parameter is a lightweight model parameter, the time to obtain the first model incremental parameter from the server will be short. Thus, a lightweight adaptation model can be quickly generated and loaded based on the first model incremental parameter, which can meet the needs of low-latency, fast, and personalized adaptation models to provide personalized services.

[0097] In some feasible embodiments, obtaining the first model incremental parameter associated with the target user identifier may include:

[0098] Based on the correspondence between user identifiers and model incremental parameters, the first model incremental parameter associated with the target user identifier is obtained from multiple model incremental parameters pre-stored in the terminal.

[0099] The correspondence between user identifiers and model incremental parameters indicates which user identifier each stored model incremental parameter corresponds to. Therefore, based on the obtained target user identifier and this correspondence, the first model incremental parameter associated with the target user identifier can be found from multiple model incremental parameters pre-stored in the terminal.

[0100] The correspondence between user identifiers and model incremental parameters, as well as multiple model incremental parameters, can be pre-stored in the terminal's local memory or in the terminal's external memory. The method of storing the correspondence between user identifiers and model incremental parameters is not limited. In some examples, the correspondence can be stored as a list. In other examples, a mapping expression between user identifiers and model incremental parameter identifiers or addresses can be established. Based on the target user identifier, the identifier or address of the associated first model incremental parameter can be obtained using this mapping expression, and then the specific associated first model incremental parameter can be obtained based on the identifier or address of the first model incremental parameter. In other embodiments, the correspondence between user identifiers and model incremental parameters can be established and stored in other ways, as long as the correspondence between user identifiers and model incremental parameters can be achieved.

[0101] Accordingly, multiple user identifiers and model incremental parameters can be stored in the terminal. During the process of obtaining the first model incremental parameter associated with the target user identifier, the first model incremental parameter associated with the target user identifier can be obtained from the terminal. This allows the first model incremental parameter associated with the target user identifier to be obtained from multiple model incremental parameters pre-stored in the terminal, even when the network is poor. This enables the rapid generation and loading of a lightweight adaptation model based on the first model incremental parameter, which can meet the needs of low-latency, fast, and personalized adaptation models to provide personalized services.

[0102] In some feasible embodiments, the condition for full model download is determined to be met when network stability is determined based on network state information and no high-priority services are running based on the service operation information. (Refer to...) Figure 4 As shown, step 203 above, which involves sending a second request to the server after determining that the conditions for downloading the full model are met, may include:

[0103] Step 401: Continuously acquire the first network status information and service operation information.

[0104] During the process of using the lightweight adaptation model to provide personalized services, the terminal can continuously monitor and obtain the terminal's status, including but not limited to network status information and service status occupancy information, in order to continuously monitor whether the conditions for downloading the full model can be met and find the opportunity to download the full adaptation model from the server.

[0105] In this embodiment, the network status information monitored to assess whether the conditions for downloading the full model are met is referred to as the first network status information. The specific type of the first network status information is not limited, and includes, but is not limited to, parameters related to network stability, such as link availability information, packet loss rate, latency, and bit error rate. The method for obtaining the network status information can be any feasible method from related technologies, and this embodiment does not impose any restrictions.

[0106] Service operation information refers to information related to the services currently running on the terminal, including but not limited to information about running service processes, the running status of running services, the terminal resources occupied by running services, and the service priorities of each running service, but not limited to these. The method of obtaining service operation information can be any feasible method in related technologies, and this application embodiment does not impose specific limitations.

[0107] Step 402: If the network is stable based on the first network status information and there are no high-priority services running based on the service operation information, send a second request to the server.

[0108] If the network is determined to be stable based on the first network state information, and there are no high-priority services running based on the service operation information, it means that the current time slot is an idle time slot with stable network and no high-priority services running. Therefore, a second request can be sent to the server to request the download of the full adaptation model corresponding to the target user identifier from the server.

[0109] Based on this embodiment, during the operation of the lightweight adaptation model, the terminal can continuously obtain the terminal status. When the terminal's network is stable and there are no high-priority services running, it indicates that the terminal is in a gap between service operations. Therefore, the terminal can send a second request to the server, so that the terminal can download the full adaptation model from the server during the gap between service operations. Thus, the full adaptation model can be downloaded silently from the server without affecting the terminal's service operation.

[0110] In some feasible embodiments, the service model is switched from a lightweight adaptation model to a full adaptation model, including:

[0111] During periods of downtime, switch the service model from a lightweight adaptation model to a full adaptation model.

[0112] The idle period refers to the period during which a terminal is not processing any service requests; that is, the time window between the end of the last service and the arrival of the next new service. There are no restrictions on how the idle period is determined, such as when the number of other running processes besides the main process is 0, or when there are no currently executing service requests or service requests being queued for processing, etc., but it is not limited to these, as long as the idle period can be determined.

[0113] The specific method for switching the service model from the lightweight adaptation model to the full adaptation model is not limited. In some examples of this application, the service model can be switched from the lightweight adaptation model to the full adaptation model through hot switching. That is, the loaded and enabled model is switched from the lightweight adaptation model to the full adaptation model without interrupting the process. The specific hot switching method can be any feasible method in the related technology. This application does not impose any specific restrictions on this.

[0114] Therefore, during business downtime, the loaded service model is switched from the lightweight adaptation model to the full adaptation model. That is, without affecting the terminal business, the loaded service model is switched from the lightweight adaptation model to the full adaptation model, thus achieving seamless switching of the adaptation model of the provided personalized server.

[0115] refer to Figure 5 As shown, in one exemplary embodiment, a method for loading a terminal model is provided, which is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 501 to 504. Wherein:

[0116] Step 501: In response to receiving the acquisition instruction generated by the terminal based on the user switching event sent by the terminal, determine the target user identifier corresponding to the user switching event, acquire the first model incremental parameter associated with the target user identifier, and send the first model incremental parameter to the terminal.

[0117] When a terminal detects a user switching event, it can obtain the target user identifier corresponding to the user switching event and send an acquisition instruction to the server. In some examples, this acquisition instruction can be a first request as described in the above embodiments. The acquisition instruction may include the target user identifier. As mentioned above, the acquisition instruction may also include a first identifier to indicate to the server that the acquisition instruction is a request to download incremental model parameters.

[0118] Upon receiving an acquisition instruction, the server can extract the target user identifier from the acquisition instruction and then obtain the first model incremental parameter associated with the target user identifier.

[0119] The server may store a mapping between user identifiers and model incremental parameters. Based on this mapping, the server can retrieve the first model incremental parameter associated with the target user identifier from the stored model incremental parameters. The database storing the mapping between user identifiers and model incremental parameters may be a local database on the server or a dedicated database; this embodiment does not impose any limitations.

[0120] After obtaining the first model incremental parameters, the server can send the first model incremental parameters to the terminal. Upon receiving the first model incremental parameters, the terminal can use the first model incremental parameters to perform incremental optimization processing on the general base model pre-stored on the terminal, obtain a lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model as a service model to respond to user needs.

[0121] Step 502: In response to receiving a second request sent by the terminal, the second request including a target user identifier, obtain the full adaptation model associated with the target user identifier, and send the full adaptation model to the terminal.

[0122] If the conditions for downloading the full model are met, the terminal will send a second request to the server to request the download of the full adapted model for the target user identifier. As mentioned above, the second request includes the target user identifier, and may also include a second identifier to indicate to the server that the second request is a request to download incremental model parameters.

[0123] After receiving the second request, the server can extract the target user identifier from the second request, obtain the full adaptation model associated with the target user identifier, and send the full adaptation model to the terminal.

[0124] The server can store a mapping between user identifiers and full-fit models. Based on this mapping, the server can retrieve the full-fit model associated with the target user identifier from the full-fit models stored for each user. The database storing the mapping between user identifiers and full-fit models can be a local database on the server or a dedicated database; this embodiment does not impose any limitations.

[0125] The correspondence between user identifiers and model incremental parameters, as well as the correspondence between user identifiers and the fully adapted model, can be stored in different databases on the server or in the same database. When representing the correspondence between user identifiers and model incremental parameters, and the correspondence between user identifiers and the fully adapted model, in the case of using lists, different lists can be used to represent these correspondences separately, or the same table can be used to represent both correspondences simultaneously. This application does not impose specific limitations on the specific method used.

[0126] After the terminal receives the fully adapted model sent by the server, it can switch the loaded model from the lightweight adapted model to the fully adapted model, so that the terminal can provide personalized services to the target user based on the fully adapted model.

[0127] In the terminal loading model method of this embodiment, when the server receives an acquisition instruction generated and sent by the terminal based on a user switching event, it first determines the target user identifier corresponding to the user switching event, then obtains the first model incremental parameter associated with the target user identifier and sends it to the terminal. This helps the terminal to incrementally optimize the pre-stored general base model using the first model incremental parameter, obtain a lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model. This allows for the rapid generation and loading of a personalized lightweight adaptation model corresponding to the target user identifier, meeting the terminal's need for low-latency, fast loading and use of the user's personalized model to provide personalized services. Furthermore, during the process of the terminal using the lightweight adaptation model to provide personalized services, upon receiving a second request from the terminal, the server obtains the full adaptation model associated with the target user identifier and sends it to the terminal. This enables the terminal to switch the loaded and running service model from the lightweight adaptation model to the full adaptation model, meeting the need to switch to the full adaptation model to provide refined personalized services. Thus, the terminal's needs for rapid loading of personalized models to provide personalized services with low latency and refined personalized services can be met simultaneously.

[0128] For each user identifier, the server may store only one model incremental parameter for that user identifier, or it may store multiple model incremental parameters for that user identifier. Each model incremental parameter has a different compression ratio relative to the full model of the full adaptation model for that user identifier, so that a model incremental parameter can be selected from these multiple model incremental parameters and sent to the terminal as needed.

[0129] Accordingly, in some of the feasible embodiments, reference is made to Figure 6As shown, obtaining the first model incremental parameter associated with the target user identifier in step 502 above may include:

[0130] Step 601: Obtain the terminal status information.

[0131] Terminal status information reflects the terminal's state, enabling the evaluation and determination of which model increment parameter to send to the terminal from among multiple model increment parameters for the user. The specific type of terminal status information can be set based on actual needs.

[0132] Step 602: From the multiple model incremental parameters associated with the target user identifier, obtain the parameter that matches the terminal state information as the first model incremental parameter, wherein the compression ratio of the first model incremental parameter relative to the full model parameters of the full adaptation model is positively correlated with the terminal state reflected by the terminal state information.

[0133] Based on the obtained terminal status information, the first model increment parameter that best matches the terminal status information can be selected from multiple model increments associated with the target user identifier and sent to the terminal.

[0134] The compression ratio of the first model incremental parameter relative to the full model parameters of the fully adapted model is positively correlated with the terminal state reflected by the terminal state information. This means that the compression ratio of the selected or matched first model incremental parameter is consistent with the changing trend of the terminal state reflected by the terminal state information. For example, the better the terminal state reflected by the terminal state information, the higher the compression ratio of the matched first model incremental parameter; the worse the terminal state reflected by the terminal state information, the lower the compression ratio of the matched first model incremental parameter.

[0135] The terminal status reflected by terminal status information can be determined based on the impact of the terminal status information on the terminal or the terminal's performance under that status. For example, if terminal status information includes network status information, and network status information includes network bandwidth, then higher network bandwidth indicates a better terminal status, and vice versa. Similarly, if terminal status information includes memory usage, then lower memory usage indicates a better terminal status, and vice versa.

[0136] Accordingly, the server can store multiple model incremental parameters associated with the target user identifier. By obtaining the terminal's terminal status information, the server selects the first model incremental parameter that matches the terminal status information from the multiple model incremental parameters associated with the target user identifier. This ensures that the first model incremental parameter returned by the server to the terminal matches the terminal status, thereby improving the terminal's business performance while enabling the terminal to quickly load personalized models and provide personalized services with low latency.

[0137] Based on the example described above, the terminal can send a second request to the server when the first network status information determines that the network is stable and the service operation information determines that there are no high-priority services running. That is, the terminal will only send a second request to the server to request the full adaptation model when it is determined that the service is idle. Therefore, in the relevant examples of this application, the terminal status information includes the terminal's second network status information.

[0138] At this time, the server can obtain the second network status information of the terminal, and based on the second network status information, obtain the first model incremental parameter that matches the second network status information from multiple model incremental parameters. Among them, the compression ratios of multiple model incremental parameters relative to the full model parameters of the fully adapted model are different. The network status quality of the second network status information is positively correlated with the compression ratio corresponding to the matched first model incremental parameter.

[0139] In this scenario, when the server receives the second request from the terminal, it can determine that the terminal is currently in an idle state with relatively good terminal condition. Therefore, based solely on the terminal's second network state information, it can select the first model incremental parameter that matches the terminal's state information from among the multiple model incremental parameters associated with the target user identifier. In other words, it determines which of the multiple model incremental parameters to send to the terminal based solely on the terminal's network state, ensuring that the sent first model incremental parameter meets network transmission requirements. The higher the network quality of the second network state information, the higher the compression ratio of the matched first model incremental parameter. This allows the terminal to quickly generate and load lightweight adaptation models to rapidly enable personalized services, while also ensuring that the loaded lightweight adaptation model has relatively rich personalized model parameters (e.g., a lightweight adaptation model generated from the model incremental parameter with the lowest compression ratio), enabling more refined personalized services.

[0140] Accordingly, in the process of obtaining the first model incremental parameter that matches the terminal state information from multiple model incremental parameters associated with the target user identifier, the first model incremental parameter to be obtained is determined based on the terminal's second network state information. This allows for the rapid determination of the first model incremental parameter to be returned, and the determined first model incremental parameter matches the terminal's network state. In other words, the first model incremental parameter that matches the terminal's network state is sent to the terminal, which is beneficial for the terminal to generate and load personalized lightweight adaptation models, and provide personalized services quickly with low latency.

[0141] The method by which the server sends the full adaptation model to the terminal is not limited. In some feasible embodiments, sending the full adaptation model to the terminal includes: sending the full adaptation model to the terminal through a segmented breakpoint resume method.

[0142] Chunked resuming refers to dividing a large file into multiple smaller chunks (chunks) and sending each chunk over the network. If the network connection is interrupted or fails, only the incomplete chunks need to be retransmitted, thus achieving a resumeable transmission method. The specific chunked resuming method can employ any feasible method from related technologies; this application does not limit the specific network transmission method used.

[0143] Accordingly, when the server sends the full adaptation model to the terminal, it does so by transmitting the data in segments with interrupted transmission, which can improve the reliability of transmitting the full adaptation model.

[0144] The aforementioned fully adapted model for user identifiers and the incremental parameters of the model can be generated based on the user's personalized profile data. Accordingly, in some feasible embodiments, refer to... Figure 7 As shown, the method may also include:

[0145] Step 701: Obtain user profile data associated with the target user identifier.

[0146] In this embodiment, the acquired user profile data is relevant data that reflects the user's personalized characteristics. Taking an in-vehicle terminal as an example, the acquired user profile data may include, but is not limited to: voice tone characteristics, commonly used vehicle control commands, cabin seat and air conditioning preference configurations, frequently used navigation destinations, and entertainment service tags. It is understood that for other terminals, the acquired user profile data may also be other types of data.

[0147] In relevant examples, once the user is identified and their user identifier is obtained, the user profile data corresponding to that identifier can be acquired. Again, taking an in-vehicle terminal as an example, after a new user completes facial recognition, account login, or Bluetooth binding with the in-vehicle terminal upon first entering the vehicle, the in-vehicle terminal can collect multi-dimensional user profile data.

[0148] Step 702: Train the general base model based on user profile data to obtain the full-scale adapted model corresponding to the target user identifier.

[0149] A general-purpose base model refers to a model obtained by training it on large-scale general-purpose data (such as data from multiple different users), which has broad and general understanding and generation capabilities. The general-purpose base model can be pre-trained using large-scale general-purpose data, or it can be a pre-trained general-purpose base model used directly.

[0150] Based on the obtained general base model, the general base model can be trained using user profile data associated with the target user identifier to generate a differentiated, personalized model that better matches the characteristics of the user corresponding to the target user identifier. It is understood that the model obtained after training is the full model, i.e., a model containing all model parameters, referred to as the full-fit model in this embodiment.

[0151] The specific training method for training the general base model using user profile data associated with the target user identifier can be any possible training method in the relevant technology. This application embodiment does not limit the specific training method.

[0152] Step 703: Decompose the model parameters of the fully adapted model to obtain the general base parameters, personalized core parameters, and low-frequency secondary parameters of the fully adapted model.

[0153] Based on the obtained fully adapted model, the model parameters of the fully adapted model can be decomposed, and the general base parameters, personalized core parameters and low-frequency secondary parameters of the fully adapted model can be decomposed.

[0154] Among them, the general base parameters refer to the parameters related to the basic general capabilities of the model parameters in the fully adapted model. They are the carriers of the model's basic general capabilities, including but not limited to the backbone network parameters and the general inherent layer weights.

[0155] Personalized core parameters are those that determine the personalized output capability. They are gradient-sensitive and are key optimization parameters during the training of a general-based model based on user profile data. These include, but are not limited to, parameters that directly control the model's output. In some examples, these may include, but are not limited to, parameters related to multimodal mapping and multi-head attention processing (if any). Taking an in-vehicle terminal as an example, personalized core parameters in some examples may include, but are not limited to, user dialect voice adaptation layer weights, personal timbre feature embedding layer parameters, commonly used phrase preference weights, fixed scene service trigger threshold parameters, classification layer weights corresponding to user intent recognition, high-frequency interaction command mapping matrix, voice coding adaptive adaptation layer weights, and cabin cross-service scheduling correlation parameters.

[0156] Low-frequency secondary parameters are auxiliary-related parameters that typically cannot provide independent, personalized output capabilities and have small update amplitudes during training. In some examples, they may include, but are not limited to, parameters related to normalization, gradient stability correction, and bias terms. The specific methods for extracting general base parameters, personalized core parameters, and low-frequency secondary parameters from the full model can employ any available method in related technologies; this application does not impose specific limitations. Taking an in-vehicle terminal as an example, low-frequency secondary parameters in some examples may include, but are not limited to, niche entertainment scene adaptation weights, extremely low-frequency semantic command mapping weights, and secondary configuration parameters for personalized interface customization. Low-frequency secondary parameters are only retained within the full adaptation model and do not enter the subsequent compression process.

[0157] Step 704: Compress the personalized core parameters to obtain the incremental parameters of the model associated with the target user identifier.

[0158] Based on the extracted general base parameters, personalized core parameters, and low-frequency secondary parameters, the extracted personalized core parameters can be compressed to reduce the mention of personalized core parameters and obtain the incremental model parameters associated with the target user identifier.

[0159] The specific method for compressing personalized core parameters is not limited. In some feasible embodiments, it may include, but is not limited to, INT8 fixed-point quantization, sparse pruning, and low-rank decomposition of parameter matrices.

[0160] In some feasible embodiments, compressing the personalized core parameters to obtain incremental model parameters associated with the target user identifier may include:

[0161] The personalized core parameters are sequentially processed by INT8 fixed-point quantization, sparse pruning, and low-rank decomposition of the parameter matrix to obtain the incremental parameters of the model associated with the target user identifier.

[0162] Specifically, INT8 fixed-point quantization maps parameters to 8-bit integers to reduce the storage size of incremental model parameters. Sparse pruning sets parameter values ​​below a threshold to 0 in the parameter matrix corresponding to the personalized core parameters, significantly reducing redundancy and the storage size of incremental model parameters (UN). Therefore, by sequentially performing INT8 fixed-point quantization, sparse pruning, and low-rank parameter matrix decomposition on the personalized core parameters, the compression effect of the personalized core parameters can be effectively improved.

[0163] Based on this embodiment, the server can obtain user profile data associated with the target user identifier, and train a general base model based on the user profile data to obtain a full-fit model for the target user identifier. On the basis of the obtained full-fit model, the model parameters of the full-fit model are decomposed to extract personalized core parameters. The personalized core parameters are then compressed to obtain the model incremental parameters associated with the target user identifier. That is, the obtained model incremental parameters are only obtained based on the compression of personalized core parameters and do not involve the general base parameters and low-frequency secondary parameters of the general base model. This enables lightweight transmission of personalized core parameters and the generation and loading of lightweight fit models based on them, while ensuring personalized services.

[0164] Based on the embodiments described above, the following detailed explanation will be provided with reference to a specific example. In the following specific example, an in-vehicle terminal will be used as an example for illustration.

[0165] refer to Figure 8 As shown, this example may involve an in-vehicle terminal 801, a server 802, and a user profile database 803.

[0166] Among them, the vehicle terminal 801 has a local deployment of a general base model, which can realize the parsing of incremental parameters of the model, incremental optimization of the stored general base model based on the incremental parameters of the model to obtain a lightweight adaptation model, and real-time monitoring of the network status and operation status of the vehicle terminal 801, so as to send a second request to the server to download the full adaptation model at an appropriate time. It can realize the data transmission of the background fragmented interrupted resume, the seamless switching of the service model used to respond to user needs from the lightweight adaptation model to the full adaptation model, and the management of the entire life cycle of the model (seamless switching of the lightweight adaptation model and the full adaptation model).

[0167] User profile database 803 is used to store user profile data for each user, including but not limited to voice tone characteristics, daily interaction command habits, cockpit hardware configuration preferences, navigation and entertainment service preferences, driving behavior characteristics, etc. It can serve as the basis for generating exclusive full-scale adaptation models for different user identifiers and extracting personalized core parameters.

[0168] Server 802 stores a general base model, as well as full-adaptation models and incremental parameters for each user identifier. The full-adaptation models for each user identifier can be trained by server 802 or other servers. Server 802 can decompose the model parameters of each user's full-adaptation model to obtain general base parameters, personalized core parameters, and low-frequency secondary parameters. It also compresses the personalized core parameters to obtain associated incremental parameters. Server 802 can also send the corresponding incremental parameters or full-adaptation models to vehicle terminal 801 based on requests sent by vehicle terminal 801 (such as the first and second requests in the above embodiments).

[0169] Based on this, refer to Figure 9 As shown, in a specific example, the interaction process between the vehicle terminal 801 and the server 802 can be as follows.

[0170] In step 901, after detecting a new user boarding the vehicle or a user switching event where the driver or passenger switches, the vehicle terminal 801 obtains the identifier of the target user after the switch.

[0171] In step 902, the vehicle terminal 801 sends a first request to the server, which includes a target user identifier and a first identifier to indicate that the requested model incremental parameters are for the target user identifier.

[0172] In step 903, after receiving the first request, server 802 obtains the terminal status information of vehicle terminal 801, and based on the terminal status information, obtains a first model incremental parameter that matches the terminal status information from multiple model incremental parameters associated with the target user identifier. Taking the terminal network status information as the network bandwidth, and the network bandwidth being greater than the maximum preset network bandwidth threshold as an example, the model incremental parameter with the highest compression ratio can be used as the first model incremental parameter. Taking multiple model incremental parameters associated with the target user identifier, including model incremental parameters with compression ratios of 10%, 15%, and 20% respectively, as an example, the model incremental parameter with a compression ratio of 20% can be used as the first model incremental parameter.

[0173] In step 904, server 802 returns a first response to vehicle terminal 801, the first response including the first model increment parameter.

[0174] In step 905, the vehicle terminal 801 receives the first response, extracts the first model incremental parameters from the first response, and uses the first model incremental parameters to perform incremental optimization processing on the stored general base model to obtain a lightweight adaptation model associated with the target user identifier.

[0175] In step 906, the vehicle terminal 801 loads and enables the generated lightweight adaptation model as a service model to respond to user needs.

[0176] In step 907, during the process of using the lightweight adaptation model, the vehicle terminal 801 continuously acquires the first network status information and service operation information of the vehicle terminal, and determines whether the conditions for downloading the full model are met based on the first network status information and service operation information.

[0177] In step 908, when the vehicle terminal 801 determines that the conditions for downloading the full model are met based on the first network status information and the service operation information, for example, when the network is stable based on the first network status information and no high-priority service is running based on the service operation information, it sends a second request to the server. The second request includes a target user identifier and a second identifier to indicate that the requested model is the full adaptation model of the target user identifier.

[0178] In step 909, server 802 receives the second request and obtains the full adaptation model associated with the target user identifier.

[0179] In step 910, the server 802 sends the acquired full-adaptation model to the vehicle terminal 801 through a segmented breakpoint resume transmission method.

[0180] In step 911, after receiving the complete full-adaptation model, the vehicle terminal 801 continuously monitors the service status of the vehicle terminal and, during the service idle interval, switches the service model used to respond to user needs from the lightweight adaptation model to the full-adaptation model in the background, thereby switching to provide refined personalized services through the full-adaptation model.

[0181] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0182] Based on the same inventive concept, this application also provides an apparatus for implementing the terminal loading model method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations of one or more apparatus embodiments of the terminal loading model provided below can be found in the limitations of the terminal loading model method described above, and will not be repeated here.

[0183] In one exemplary embodiment, such as Figure 10 As shown, a device for loading a model on a terminal is provided. This device can be deployed on a terminal 102 and includes: a lightweight parameter acquisition module 1001, a lightweight model loading module 1002, a full model acquisition module 1003, and a full model loading module 1004, wherein:

[0184] The lightweight parameter acquisition module 1001 is used to respond to a user switching event, determine the target user identifier corresponding to the user switching event, and acquire the first model incremental parameter associated with the target user identifier;

[0185] The lightweight model loading module 1002 is used to perform incremental optimization processing on the general base model pre-stored in the terminal using the first model incremental parameters, to obtain the lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model as a service model for responding to user needs.

[0186] The full model acquisition module 1003 is used to send a second request to the server when it is determined that the conditions for downloading the full model are met. The second request includes the target user identifier, and the module receives the full adaptation model corresponding to the target user identifier returned by the server based on the second request. The full adaptation model has the same model architecture as the lightweight adaptation model.

[0187] The full model loading module 1004 is used to load the full adaptation model and switch the service model from the lightweight adaptation model to the full adaptation model.

[0188] In some feasible embodiments, the lightweight parameter acquisition module 1001 is used to send a first request to the server, the first request including a target user identifier; and receive a first response returned by the server based on the first request, the first response including a first model incremental parameter corresponding to the target user identifier.

[0189] In some feasible embodiments, the lightweight parameter acquisition module 1001 is used to search for and obtain the first model incremental parameter associated with the target user identifier from a plurality of model incremental parameters pre-stored in the terminal based on the correspondence between the user identifier and the model incremental parameters.

[0190] In some feasible embodiments, the full model acquisition module 1003 is used to continuously acquire first network status information and service operation information; when it is determined that the network is stable based on the first network status information and that there are no high-priority services running based on the service operation information, a second request is sent to the server.

[0191] In some feasible embodiments, the full model loading module 1004 is used to switch the service model from the lightweight adaptation model to the full adaptation model during business downtime.

[0192] In one exemplary embodiment, such as Figure 11 As shown, a device for loading a terminal model is provided. This device can be deployed on a server 104 and includes: a lightweight model processing module 1101 and a full model processing module 1102, wherein:

[0193] The lightweight model processing module 1101 is used to respond to receiving an acquisition instruction generated by the terminal based on a user switching event sent by the terminal, determine the target user identifier corresponding to the user switching event, acquire the first model incremental parameter associated with the target user identifier, and send the first model incremental parameter to the terminal.

[0194] The full model processing module 1102 is used to respond to receiving a second request sent by the terminal, the second request including the target user identifier, to obtain the full adaptation model associated with the target user identifier, and to send the full adaptation model to the terminal.

[0195] In some feasible embodiments, the lightweight model processing module 1101 is used to obtain a parameter that matches the terminal state information from multiple model incremental parameters associated with the target user identifier as the first model incremental parameter, wherein the compression ratio of the first model incremental parameter relative to the full model parameters of the full-adaptation model is positively correlated with the terminal state reflected by the terminal state information.

[0196] In some feasible embodiments, the terminal's terminal status information includes: the terminal's second network status information.

[0197] In some feasible embodiments, the full model processing module 1102 is used to send the full adaptation model to the terminal by means of segmented breakpoint resume transmission.

[0198] In some feasible embodiments, the apparatus further includes: a model generation and processing module, used to acquire user profile data associated with the target user identifier; train a general base model based on the user profile data to obtain a full-fit model corresponding to the target user identifier; decompose the model parameters of the full-fit model to obtain the general base parameters, personalized core parameters, and low-frequency secondary parameters of the full-fit model; and compress the personalized core parameters to obtain the model incremental parameters associated with the target user identifier.

[0199] In some feasible embodiments, the model generation and processing module is used to sequentially perform INT8 fixed-point quantization, sparse pruning, and low-rank decomposition of the parameter matrix on the personalized core parameters to obtain the incremental parameters of the model associated with the target user identifier.

[0200] Each module in the aforementioned terminal loading model device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0201] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 12As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as user profile data, full-fit models corresponding to each identifier, and incremental model parameters. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for loading a terminal model.

[0202] In one exemplary embodiment, an electronic device is provided, the internal structure of which can be shown as follows: Figure 13 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a method for a terminal loading model. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0203] Those skilled in the art will understand that Figure 12 , 13The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0204] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the methods in the above embodiments.

[0205] In one embodiment, an in-vehicle terminal is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the methods in the above embodiments.

[0206] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0207] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0208] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0209] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0210] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for loading a terminal model, characterized in that, Applied to a terminal, the method includes: In response to a user switching event, the target user identifier corresponding to the user switching event is determined, and the first model incremental parameter associated with the target user identifier is obtained; The first model incremental parameters are used to perform incremental optimization on the general base model pre-stored in the terminal to obtain the lightweight adaptation model associated with the target user identifier, and the lightweight adaptation model is loaded as a service model to respond to user needs. If the conditions for downloading the full model are met, a second request is sent to the server. The second request includes the target user identifier. The server returns the full-adapted model corresponding to the target user identifier based on the second request. The full-adapted model has the same model architecture as the lightweight adapted model. Load the full-adaptation model, and switch the service model from the lightweight adaptation model to the full-adaptation model.

2. The method according to claim 1, characterized in that, The step of obtaining the first model incremental parameter associated with the target user identifier includes: Send a first request to the server, the first request including the target user identifier; Receive a first response returned by the server based on the first request, the first response including a first model incremental parameter corresponding to the target user identifier; or Based on the correspondence between user identifiers and model incremental parameters, the first model incremental parameter associated with the target user identifier is obtained from multiple model incremental parameters pre-stored in the terminal.

3. The method according to claim 1 or 2, characterized in that, The step of sending a second request to the server when it is determined that the conditions for downloading the full model are met includes: Continuously acquire primary network status information and service operation information; If the network is determined to be stable based on the first network status information, and if no high-priority services are running based on the service operation information, a second request is sent to the server. And / or, The step of switching the service model from the lightweight adaptation model to the full adaptation model includes: During periods of downtime, the service model is switched from the lightweight adaptation model to the full adaptation model.

4. A method for loading a terminal model, characterized in that, Applied to a server, the method includes: In response to receiving an acquisition instruction generated by the terminal based on a user switching event, the system determines the target user identifier corresponding to the user switching event, acquires the first model incremental parameter associated with the target user identifier, and sends the first model incremental parameter to the terminal. In response to receiving a second request from the terminal, the second request including the target user identifier, the system obtains the full adaptation model associated with the target user identifier and sends the full adaptation model to the terminal.

5. The method according to claim 4, characterized in that, The step of obtaining the first model incremental parameter associated with the target user identifier includes: Obtain the terminal status information of the terminal; From the multiple model incremental parameters associated with the target user identifier, the parameter that matches the terminal state information is obtained as the first model incremental parameter, wherein the compression ratio of the first model incremental parameter relative to the full model parameters of the full-adaptation model is positively correlated with the terminal state reflected by the terminal state information.

6. The method according to claim 5, characterized in that, The terminal status information of the terminal includes: the second network status information of the terminal.

7. The method according to claim 4, characterized in that, Sending the full adaptation model to the terminal includes: The full adaptation model is sent to the terminal by means of segmented breakpoint resume transmission.

8. The method according to any one of claims 4 to 7, characterized in that, The method further includes: Obtain user profile data associated with the target user identifier; The general base model is trained based on the user profile data to obtain the full-scale adaptation model corresponding to the target user identifier; The model parameters of the full-adaptation model are decomposed to obtain the general base parameters, personalized core parameters and low-frequency secondary parameters of the full-adaptation model. The personalized core parameters are compressed to obtain the model incremental parameters associated with the target user identifier.

9. A device for loading a terminal model, characterized in that, The device, located in a terminal, includes: A lightweight parameter acquisition module is used to respond to a user switching event, determine the target user identifier corresponding to the user switching event, and acquire the first model incremental parameter associated with the target user identifier; The lightweight model loading module is used to incrementally optimize the general base model pre-stored in the terminal using the first model incremental parameters, obtain the lightweight adaptation model associated with the target user identifier, and load the lightweight adaptation model as a service model for responding to user needs. The full model acquisition module is used to send a second request to the server when it is determined that the conditions for downloading the full model are met. The second request includes the target user identifier, and the module receives the full adapted model corresponding to the target user identifier returned by the server based on the second request. The full adapted model has the same model architecture as the lightweight adapted model. The full model loading module is used to load the full adaptation model and switch the service model from the lightweight adaptation model to the full adaptation model.

10. An apparatus for loading a terminal model, characterized in that, The device, located on a server, includes: A lightweight model processing module is used to respond to a terminal's acquisition instruction generated based on a user switching event, which is sent by the terminal, to determine the target user identifier corresponding to the user switching event, acquire the first model incremental parameter associated with the target user identifier, and send the first model incremental parameter to the terminal. The full model processing module is used to respond to receiving a second request sent by the terminal, the second request including the target user identifier, to obtain the full adaptation model associated with the target user identifier, and to send the full adaptation model to the terminal.

11. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

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

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images