A cross-platform model migration method and device

Abstract

The application provides a cross-platform model migration method and device, and belongs to the field of artificial intelligence. The method provided by the application comprises: managing chip information configuration in a chip configuration subpage; adjusting a target model migration task in a model migration management subpage, determining a target tab based on a model corresponding to the target model migration task, executing the target model migration task and displaying the corresponding task progress in the target tab; determining pre-migration chip information corresponding to a pre-migration model completing the model migration task; generating an evaluation task of the pre-migration model based on the pre-migration chip information, and modifying the number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management subpage based on the result of the evaluation task. The cross-platform model migration method and device provided by the application can realize efficient, reliable and visual cross-platform migration of artificial intelligence models from Nvidia chips to domestic chips.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, in particular to a cross-platform model migration method and device. BACKGROUND

[0002] With the development of artificial intelligence technology, the demand for cross-platform migration of deep learning models from traditional NVIDIA GPU chips to domestic chips is increasingly urgent. The advantages of domestic chips in self-controllability, computing power density and energy efficiency are gradually emerging, becoming an important choice for model deployment in key industries. However, existing mature AI models are mostly developed based on NVIDIA CUDA ecology, relying on exclusive operator libraries and precision formats, and directly deploying them to domestic chips faces compatibility bottlenecks, requiring professional model migration technology for adaptation and optimization.

[0003] Current model cross-platform migration technology focuses on operator adaptation, parameter calibration and process automation. It replaces or disassembles incompatible CUDA operators through operator mapping tables, converts model precision using KL divergence calibration algorithms, and some tools support model reading-conversion-generation automation processes. However, the existing technology has obvious shortcomings. Chip information management is fragmented, and hardware parameters and driver environments need to be manually queried and sorted, and are not associated with migration tasks. Migration task control lacks an intuitive interface, and only command line output text progress is available, making it difficult for users to view key information and abnormal reasons in real time. Process parameters are mostly statically configured, and cannot be dynamically adjusted according to real-time chip performance. Batch-related tasks lack parameter inheritance and sorting mechanisms, resulting in low efficiency.

[0004] In addition, the migration effect evaluation of the existing technology is disconnected from the migration process, and needs to be manually executed and evaluated. The evaluation dimensions do not match the characteristics of domestic chips, resulting in a large deviation between the results and actual deployment. When the evaluated model does not meet the standards, there is no automated closed loop of evaluation, optimization and retry, and the management interface cannot update the task status in real time, making it difficult for users to quickly identify effective migration results. These problems make the existing technology unable to meet the needs of key industries for efficient, reliable and visual model migration of domestic chips, and an integrated solution covering the whole process is urgently needed. SUMMARY

[0005] Therefore, the present application provides a cross-platform model migration method and device to realize efficient, reliable and visual cross-platform migration of artificial intelligence models from NVIDIA chips to domestic chips.

[0006] Specifically, the present application is realized by the following technical solutions:

[0007] The first aspect of the present application provides a cross-platform model migration method, which comprises:

[0008] configuring chip information in a chip configuration sub-page;

[0009] The model migration management sub-page adjusts a target model migration task, determines a target tab based on a model corresponding to the target model migration task, executes the target model migration task, and displays a corresponding task progress in the target tab, wherein the model migration management sub-page displays a plurality of tabs, each tab displays a progress of a plurality of model migration tasks of a model, a display size of each tab is adaptively determined according to display content and a number of tabs, and the model migration task is a task of fine-tuning a model structure and parameters based on new samples;

[0010] The determination module is configured to determine pre-migration chip information corresponding to a pre-migration model that completes a model migration task.

[0011] The processing module is configured to generate an evaluation task of the pre-migration model based on the pre-migration chip information, and modify a number of displayed model migration tasks in a tab corresponding to the pre-migration model in the model migration management sub-page based on a result of the evaluation task.

[0012] The second aspect of the application provides a cross-platform model migration device, the device comprising a management module, an adjustment module, a determination module and a processing module.

[0013] The management module is configured to manage chip information configuration in a chip configuration sub-page.

[0014] The adjustment module is configured to adjust a target model migration task in a model migration management sub-page, determine a target tab based on a model corresponding to the target model migration task, execute the target model migration task, and display a corresponding task progress in the target tab, wherein the model migration management sub-page displays a plurality of tabs, each tab displays a progress of a plurality of model migration tasks of a model, a display size of each tab is adaptively determined according to display content and a number of tabs, and the model migration task is a task of fine-tuning a model structure and parameters based on new samples.

[0015] The determination module is configured to determine pre-migration chip information corresponding to a pre-migration model that completes a model migration task.

[0016] The processing module is configured to generate an evaluation task of the pre-migration model based on the pre-migration chip information, and modify a number of displayed model migration tasks in a tab corresponding to the pre-migration model in the model migration management sub-page based on a result of the evaluation task.

[0017] The cross-platform model migration method and device provided by the application provide a cross-platform model migration management method and platform, which can realize simultaneous management of complex multiple model migration tasks through interaction of a software interface, and provide a clustering display effect with a migration chip as a theme and a migration model as a theme, cross-platform, multi-migration task management based on underlying chip-model-migration progress as data support and platform migration capability as a basis. Specifically, by managing chip information configuration in a chip configuration sub-page and adjusting target model migration tasks in a model migration management sub-page, the structured control of chip hardware information and model migration tasks is realized, the chip configuration sub-page provides precise hardware basic data for migration tasks, and the model migration management sub-page is designed to have one-to-one correspondence between tabs and models and adaptive tab size, so that the progress of multiple migration tasks of a single model is clearly displayed, avoiding information clutter and improving the management efficiency of migration tasks, and facilitating users to quickly locate and operate target tasks. Through the design of determining a target tab based on a model corresponding to a target model migration task, executing the task and displaying the progress, directional execution and real-time monitoring of the migration task are realized. Users can intuitively obtain the task progress through the target tab without needing to filter information in a complex interface, so that the migration process can be tracked and controlled, and the complexity of task management is reduced. Through the design of determining pre-migration chip information, generating an evaluation task, and adjusting the number of task display bars of the tab based on the evaluation result, the verification of the migration effect and the synchronization of the interface state are realized, the evaluation task ensures the adaptability of the pre-migration model and the target chip, and invalid operations such as migration completion but model inapplicability are avoided, and the number of task display bars of the tab is adjusted according to the evaluation result, further enabling intuitive display of the interface display and the actual effect of the task. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 A flowchart of the cross-platform model migration method provided by the application embodiment one;

[0019] Figure 2 A structural schematic diagram of the cross-platform model migration device provided by the application embodiment two. DETAILED DESCRIPTION

[0020] The exemplary embodiments will be described in detail herein with reference to the drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the application.

[0021] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0022] It is to be understood that the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. It is to be further understood that the terms "comprise", "comprising", "comprises", "including", "includes" or "contain" or "containing" when used in this specification, specify the presence of stated features, integers, steps, operations, elements, or components but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof. It is to be understood that the terms "if' and "when" as used herein are interpreted as "if the probability is greater than zero that' or "when the probability is greater than zero that".

[0023] The following detailed embodiments are presented to provide a thorough understanding of the technical solutions of the present application.

[0024] Embodiment One

[0025] Figure 1 The flowchart of the cross-platform model migration method provided by the present application is shown in Figure 1. Please refer to Figure 1 The method provided by the present embodiment can include:

[0026] It should be noted that the method provided by the present embodiment is executed by a cross-platform model migration management platform. The platform is an integrated software system for the power and other key industries, which is used to realize the efficient, reliable and visual migration of artificial intelligence models from NVIDIA chip ecology to domestic chip ecology.

[0027] The platform mainly realizes the unified management of heterogeneous chip resources and the whole life cycle control of model migration tasks through two core interactive interfaces, chip configuration sub-page and model migration management sub-page. The core function is as follows: first, the fragmented hardware parameters and driver environment information of domestic chips are structured and managed through the chip configuration sub-page; then, in the model migration management sub-page, all migration tasks of the model are aggregated and displayed, and the user is provided with one-stop operation experience of task creation, execution monitoring, parameter adjustment and effect evaluation through visual tabs and interactive task bars; finally, through the automatic migration and evaluation pipeline in the background, the model after migration maintains high performance and high precision on domestic chips, meeting the deployment requirements of power grid and other business scenarios with high real-time requirements.

[0028] To realize the data linkage and consistent display between the two subpages, the platform bottom relies on a set of associated storage data structure, which takes chip, model, and migration task as the core entity and is organized through the preset association. Specifically, it includes a chip information table for storing static information of all configured chips, the primary key of which is chip ID, and the fields include at least chip model, manufacturer, hardware parameter JSON, driver version, and configuration status; a model information table for storing all original AI model metadata managed by the platform, the primary key of which is model ID, and the fields include model name, version, source framework type, network structure summary, etc.; and a migration task table as the core business table, which stores the dynamic information of each migration task, the primary key of which is task ID. This table is associated with the chip information table and the model information table through the foreign keys chip ID and model ID, thereby recording which model is to be migrated to which chip. Its fields also include task configuration JSON (storing precision requirements, BatchSize, etc.), execution status, progress percentage, creation time, and associated evaluation task ID.

[0029] Based on the above data structure, the front-end interface can query and list all migration tasks (from the migration task table) associated with the chip ID by clicking any chip tab in the chip configuration subpage. In the model migration management subpage, all tasks displayed in each model tab are obtained by querying the migration task table through the model ID. This two-way association ensures data homogeneity and display synchronization.

[0030] S101、In the chip configuration subpage, manage chip information configuration.

[0031] It should be noted that different chips (such as domestic chips and non-domestic chips) have different hardware parameters (such as the number of computing cores, memory bandwidth, etc.) and driver environments, which are the key basis for whether the model can run smoothly on the chip. To realize the migration of the model to a specific chip, the relevant information of the chip needs to be accurately obtained and managed first.

[0032] Among them, chip information can be automatically pulled from the official database provided by the chip manufacturer, or synchronized with the latest configuration of the chip through the interface with the chip management system. In addition to the above methods, chip identification information can be input by the user to create a new tab, analyze parameters, and other operations to manage chip information configuration in the chip configuration subpage (allowing users to actively participate in the initial configuration of chip information, ensuring the relevance and timeliness of the information).

[0033] Specifically, in the chip configuration subpage, chip information configuration is managed, including:

[0034] (1) Based on the chip identification information input by the user, a chip tab is newly created in the chip configuration sub-page. The chip configuration sub-page re-determines the display size of all display objects according to the size of the display space and the number of display objects.

[0035] It should be noted that the chip identification information is information used to uniquely identify a chip, which can include chip model, manufacturer name, serial number, etc., and can allow the system to quickly locate the corresponding chip; the chip tab is a configuration management interface of different chips in the chip configuration sub-page, presented in the form of a tab. Each tab corresponds to a chip, making it easy for users to switch between viewing and managing information for different chips.

[0036] Specifically, after receiving the chip identification information input by the user, the model migration management platform creates a new chip tab in the chip configuration sub-page. At the same time, the interface rendering module of the platform re-calculates and determines the display size of all display objects according to the size of the display space (such as the width and height limits of the page) of the current page and the number of objects to be displayed (including existing and newly added chip tabs, etc.), using an interface layout algorithm (such as an adaptive grid layout algorithm), to ensure that each object is displayed reasonably and does not overlap or appear incomplete.

[0037] For example, the user now wants to manage a chip with the model "Domestic Chip A100" and inputs the identification information of the chip (including the model "Domestic Chip A100", the manufacturer "a domestic chip company", etc.). After receiving the information, the model migration management platform creates a new tab labeled "Domestic Chip A100" in the chip configuration sub-page. At this time, there are already 3 chip tabs on the page, and the display space is relatively tight. The interface rendering module of the platform will re-calculate the display size of each tab (such as width and height) according to the width and height of the current page and the total of 4 tabs, so that the 4 tabs can be arranged neatly on the page and each can be clearly displayed, making it easy for the user to perform subsequent click operations.

[0038] It should be further noted that the chip configuration sub-page uses a top horizontal navigation bar layout, and all chip tabs are arranged horizontally in this bar. Each tab is a clickable interactive element and is displayed by default as a rectangular area with rounded corners, containing the chip model name. When the user clicks on any tab, the tab will be highlighted (such as a darker background color and a thicker border), and the main area of the page will display detailed configuration information for the chip.

[0039] During the tab creation process, the platform performs a background duplication verification, comparing the chip identification information input by the user with the existing chip configurations in the system, and also checks other chip tasks that are queuing for creation. If it finds completely duplicated chip information (the core identification of the chip model, manufacturer, etc. is completely consistent), it performs a merge process, does not create a new tab, but updates the existing chip tab with the new configuration information, and prompts the user that "the chip information has been updated"; if it is not duplicated, it normally creates a new chip tab.

[0040] After determining to create a new tab, the platform also determines its initial display content. Specifically, given a basic scaling ratio (such as 0.8), the available width of each tab is calculated according to the current total number of tabs and the display area width. If the calculated width is not enough to completely display the chip full model name, the semantic analysis technique is called to extract the core identification content from the chip full name, giving priority to retaining the chip series name, key model number, etc., and the suffix modifier (such as high-performance version) can be omitted. Finally, the filtered core content is used as the initial display text of the tab. In addition, the platform also supports the scenario of creating multiple chips in batches. When the user submits multiple chip configurations at once, the platform first performs duplication checking within the to-be-created queue, merges completely identical chip requests, and then compares them with the existing chip configurations in the system. Finally, only non-duplicated chips are created into new tabs, and information updates are performed for duplicated chips. After all processing is completed, the interface is refreshed and displayed uniformly.

[0041] It should be noted that in the model cross-platform migration scenario, there are multiple different chips (such as domestic chips and non-domestic chips) that need to be managed, and the display of different chip information needs to be adapted to the interface space. This step creates a chip tab by having the user input chip identification information, and adjusts the display size adaptively according to the display space and the number of objects, which can quickly establish a management portal for new chips while ensuring a reasonable layout of the interface, with all chip-related information clearly displayed for the user to configure and view chip information later.

[0042] (2) Trigger the configuration parsing script to parse the chip identification information to obtain the hardware parameters and driver version information of the chip.

[0043] It should be noted that the configuration parsing script is a pre-written program code that extracts chip-related key data from the input chip identification information; the hardware parameters refer to the number of computing cores, memory bandwidth, and other indicators that determine the performance of the chip, and the driver version information refers to the version of the driver program required for the chip to interact with the upper-layer software.

[0044] When the chip tab is newly created, the model migration management platform automatically triggers a configuration analysis script, which analyzes and processes the chip identification information input by the user (there is a problem that only the chip identification information cannot obtain the specific running parameters of the chip, and it is difficult to carry out model adaptation work, therefore, the configuration analysis script is used to analyze the chip identification information to obtain the hardware parameter and driver version information). For example, the user inputs the identification information of "domestic chip A100", which contains the content that the chip is produced by "certain domestic chip manufacturer", etc. After the configuration analysis script is triggered, it analyzes that this chip has how many computing cores, what is the memory bandwidth, and the driver version information.

[0045] (3) Generate a corresponding chip configuration information file based on the hardware parameters and driver version information.

[0046] It should be noted that the chip configuration information file is a file that integrates the hardware parameters and driver version information of the chip according to a specific format. After obtaining the hardware parameters and driver version information of the chip, the model migration management platform will integrate these information into a chip configuration information file according to the preset file format and specification. For example, the number of computing cores, memory bandwidth, and driver version information in the hardware parameters are written into a file in a specific format (such as XML, JSON format) according to a certain structure. In this way, the scattered hardware parameters and driver version information are integrated into a structured chip configuration information file, which facilitates the storage, loading and use of chip information in the future.

[0047] (4) Load the chip configuration information file to the chip configuration sub-page, and display the chip configuration state in the chip tab.

[0048] The chip configuration state refers to the display of whether the chip-related configuration is complete and can be used for model migration after the chip configuration information file is loaded, which allows users to intuitively understand the configuration of the chip.

[0049] Specifically, after generating the chip configuration information file, the model migration management platform loads the file into the chip configuration sub-page. At the same time, in the corresponding chip tab, the chip configuration state is displayed in the form of text, icons, etc., such as displaying the words "configuration completed" and "available for model migration", or using a green checkmark icon to represent the normal configuration state.

[0050] (5) When a chip tab is added to the chip configuration sub-page, the interface adjusts the font and tab size according to the number of tabs and display content.

[0051] Specifically, when a chip option tab is added in the chip configuration subpage, the interface rendering module of the model migration management platform will automatically adjust the size of the font and the size of the tab according to the number of the current tabs and the amount of display content in each tab. For example, when the number of tabs increases, the font size and the width of the tabs will be appropriately reduced so that all the tabs can be neatly arranged on the page. If a tab displays more content, its height and other sizes will also be adjusted accordingly to ensure that the content is fully displayed.

[0052] For example, the chip configuration subpage originally has 4 tabs, and now a "domestic chip B200" tab is added, becoming 5 tabs. At this time, the interface rendering module will detect the increase in the number of tabs and will appropriately reduce the width of each tab while adjusting the font from the original 14 to 12, so that the 5 tabs can be reasonably arranged within the width of the page, and the text in each tab can be clearly displayed. By dynamically adjusting the font and tab size, the rationality of the interface layout and the clarity of the display are always maintained, which improves the user experience and makes it easier for users to operate when managing multiple chip information.

[0053] S102、In the model migration management subpage, adjust the target model migration task, determine the target tab based on the model corresponding to the target model migration task, execute the target model migration task, and display the corresponding task progress in the target tab.

[0054] Among them, the model migration management subpage displays multiple tabs, each tab displays the progress of multiple model migration tasks of a model, and the display size of each tab is adaptively determined according to the display content and the number of tabs. The model migration task is a task of fine-tuning the model structure and parameters based on new samples.

[0055] It should be noted that the model migration management subpage is a special interface for managing various model migration tasks, and the page has multiple tabs, each tab corresponding to a specific model, used to centrally display the migration task progress of the model in different scenarios and for different chips, and the tab display size will be automatically adjusted according to the amount of display content and the number of tabs to ensure reasonable interface display. The model migration task is a fine adjustment of the model structure and parameters using new sample data. The new sample can provide data that is more suitable for actual application scenarios for the model. The model will fine-tune its structure (such as the connection method of network layers, the number of layers, etc.) and parameters (such as the weight values of each layer, etc.) according to these new samples, so that the model runs better on the target chip, such as improving inference speed and accuracy.

[0056] It should be noted that in order to enable the chip information and the model migration task information to be associated and work together, an associated storage mode needs to be established between the chip configuration sub-page and the model migration management sub-page. In the chip configuration sub-page, each chip tab not only displays the detailed information of the current chip, but also lists all the migration task progress related to the chip, and each migration task displays the execution status through specific marker information (such as labels, icons, etc. of different colors). In the model migration management sub-page, each task tab displays the target chip information related to the current migration task, as well as the execution progress and status of the task. Moreover, there is a preset association between the chip tab of the chip configuration sub-page and the task tab of the model migration management sub-page, and when a new chip or migration task is added, the related tab information is automatically refreshed and displayed in the corresponding page. In this way, the user can understand the migration task situation associated with the chip in the chip configuration sub-page, and can also clearly understand the chip information corresponding to the migration task in the model migration management sub-page, realizing the intercommunication of the chip and the migration task information, and facilitating the overall management.

[0057] After the core functions, tab design logic, and association mechanism of the model migration management sub-page are determined, the implementation of adjusting the target model migration task in the sub-page is described in detail, that is, the adjustment is completed through the process of user selecting a task, positioning a tab, executing the task, and displaying the key status. Specifically, the method for adjusting the target model migration task in the model migration management sub-page comprises:

[0058] (1) receiving a target model migration task selected by a user.

[0059] It should be noted that the target model migration task refers to a specific migration task selected by the user from the task list in the model migration management sub-page according to actual needs, which needs to be executed and monitored subsequently.

[0060] Specifically, the model migration management platform provides a task selection entry (such as a task list drop-down menu, a task card click selection function), and after the user selects a target model migration task through interface interaction (click, check, etc.), the platform receives and records the identification information (such as task ID, associated model name, target chip model) of the task in real time as the basis for subsequent operations.

[0061] (2) determining the corresponding target tab in the migration task management sub-page based on the model corresponding to the target model migration task.

[0062] It should be noted that because the tabs of the model migration management subpage correspond to the models one by one (each tab is exclusive to a model and displays all migration tasks of the model), the model associated with the target model migration task is the index of the target tab, and the model migration management platform can match the corresponding tab through the associated model name in the task identification information.

[0063] Specifically, after receiving the target model migration task selected by the user, the model migration management platform extracts the associated model name (such as extracting the power load prediction model from the power load prediction model → domestic chip B200 task) from the task identification information; then traverses all tabs in the model migration management subpage, matches the tab name (consistent with the model name) with the extracted model name, finally determines the corresponding target tab, and can prompt the user to locate the result through interface highlighting (such as tab border blue, background color deepening).

[0064] (3) Call the migration script to execute the target model migration task and collect task execution state data in real time.

[0065] It should be noted that the migration script is a pre-written program code set containing model migration full-process logic (such as model reading, operator adaptation, parameter fine-tuning), which can automatically perform migration operations according to task configuration; the task execution state data refers to key dynamic information generated during task execution, including task execution stage (model parsing, operator adaptation, parameter calibration, execution completion), execution progress percentage, real-time resource occupancy (CPU / memory usage), whether an exception occurs, etc.

[0066] After the model migration management platform determines the target tab, it will automatically call the corresponding migration script according to the configuration information of the target model migration task (such as associated model file path, target chip parameters); after the script is started, the model migration management platform will track the script running state in real time through the process monitoring module, collect task execution state data at a preset period (such as every 1 second), and temporarily store the data in the system cache to ensure the real-time and integrity of the data.

[0067] (4) Add a display area corresponding to the target model migration task in the target tab, and display the landmark information in the task execution state data in the display area.

[0068] It should be noted that the display area refers to an independent interface module (such as a task status card) newly added in the target tab and specially used to show key information of a single migration task; the landmark information refers to the core information (such as execution stage, progress percentage, exception prompt) that users are most concerned about, which is selected from the task execution state data, rather than all original data, which can ensure the simplicity and effectiveness of information display.

[0069] The model migration management platform automatically divides an independent display area in the target tab (such as adding a "task status card" below the tab, including fixed modules such as task name, current stage, progress bar, and exception prompt); then extracts the landmark information (such as "execution stage: parameter calibration", "progress: 70%") from the cached task execution status data, and displays it in a visual form (progress bar, text label, color identification: normal state green, abnormal state red) in this area, and refreshes the display content in real time with the state data update.

[0070] In this way, through the dedicated display area and landmark information display, the visualization and focusing of the task status are realized, allowing users to intuitively grasp the core progress of the task in the target tab without the need to view complex raw data, thereby improving operation efficiency and experience.

[0071] In addition, it should be noted that the model migration management subpage adjusts the target model migration task, including:

[0072] (1) receiving the chip performance parameters input by the user in the target tab.

[0073] It should be noted that the chip performance parameters refer to key indicators reflecting the computing power and resource limitations of the chip. Based on the model migration requirements in the power scenario, they mainly include the number of computing cores, memory bandwidth, single-precision floating-point computing power (FP32), half-precision floating-point computing power (FP16), and driver version compatibility. These parameters directly determine the resource allocation and adaptation strategy of the model migration process.

[0074] Specifically, in the target tab, the model migration management platform will set up a chip performance parameter input entry (such as a parameter form or a drop-down selection box), supporting manual input or selection of detected chip parameters (if the model migration management platform has obtained the chip parameters through the chip configuration subpage, an automatic filling option can be provided); after the user completes the input and submits, the model migration management platform will verify the validity of the parameter format, and after verification, receive and store these parameters as the basis for subsequent task configuration updates.

[0075] (2) Based on the chip performance parameters, locate the target model migration task associated with the chip, and update the execution configuration data of each target model migration task.

[0076] The model migration management platform can locate all migration tasks associated with the chip according to the chip identifier (such as the chip model "domestic chip B200") in the chip performance parameters through the association storage mechanism of the chip configuration sub-page and the model migration management sub-page; the execution configuration data is the core parameter of the migration task running, including resource allocation ratio (such as how many computing cores are occupied), precision calculation mode (such as using FP16 or FP32), data batch processing size (Batch Size), etc., which needs to be dynamically adjusted according to the chip performance.

[0077] In specific implementation, the model migration management platform extracts the chip identifier from the received chip performance parameters, and filters out all target model migration tasks (such as "power load prediction model → domestic chip B200" and "power equipment temperature monitoring model → domestic chip B200") associated with the chip through the mapping relationship (chip identifier → associated migration task list) of the association storage; then adjusts the execution configuration data of each task according to the chip performance parameters, for example, if the chip has strong half-precision floating point calculation capability, the precision mode in the configuration data is changed from single-precision floating point calculation capability to half-precision floating point calculation capability; if the memory bandwidth is high, the data batch processing size is adjusted from 32 to 64 to improve the data processing efficiency.

[0078] (3) The migration script adjusts the model migration process according to the updated configuration.

[0079] It should be noted that on the basis of the above introduction, the migration script also predefines the mapping rule of configuration parameters → process logic, which can automatically switch the process branch according to the updated execution configuration data; the model migration process adjustment mainly involves the logical change of the precision processing link, the resource scheduling link and the data processing link.

[0080] It should be noted that the migration script first reads the updated execution configuration data, extracts the key parameters (such as precision mode FP16, BatchSize 64, core occupancy ratio 80%), and matches them with the mapping rules of the preset configuration parameters → process logic in the script to determine the process modules that need to be adjusted. If the configuration parameter is "precision mode = FP16", the migration script calls the precision conversion submodule to convert the original model's FP32 weight parameters to FP16 format through numerical scaling algorithms (such as linear mapping method), and replace the model-dependent CUDAFP32 operator with the target chip-supported FP16 operator (such as replacing cuBLASFP32 matrix multiplication operator with BLAS-LTFP16 operator of domestic chip), to ensure that the calculation precision adapts to the chip capability; if the configuration parameter is "Batch Size = 64", the script modifies the batch reading logic of the data loading submodule, adjusts the original code segment that reads 32 samples at a time to read data in groups of 64 samples, and optimizes the data caching strategy (such as increasing the memory cache area to the storage capacity corresponding to 64 samples), to reduce the number of data IOs and improve processing efficiency; if the configuration parameter is "core occupancy ratio = 80%", the migration script applies for 80% of the computing core resources of the target chip through the system resource calling interface (such as the device management API of domestic chip), and sets a resource exclusive lock to avoid other tasks from occupying the allocated cores; at the same time, the number of task thread pools is adjusted to bind the number of threads to the number of allocated cores (such as 64 cores corresponding to 64 threads), to achieve precise matching of resources and tasks.

[0081] Further, after completing the adjustment of each module process, the task script calls the self-checking submodule to perform syntax checking (such as whether there are syntax errors in operator replacement) and resource compatibility checking (such as whether the number of allocated cores exceeds the total number of chip cores) on the adjusted process; after passing the verification, the script starts the model migration process adjusted according to the new configuration, and performs subsequent steps such as model parsing, operator adaptation, and parameter calibration according to the new configuration.

[0082] (4) Update the flag information in the target tab and the corresponding migration task display bar synchronously.

[0083] It should be noted that the flag information refers to the visual identifier for intuitively displaying the configuration adjustment results and the current state of the migration task, including configuration update status (such as configuration updated label), precision mode identifier (such as FP16 icon), resource occupancy identifier (such as "80% core occupancy" text), and task status (such as pending execution (configuration updated), execution (adapt to new configuration)), which are displayed synchronously in the title bar of the target tab and the display bar of the corresponding task.

[0084] In a specific implementation, after completing the task configuration update and script flow adjustment, the model migration management platform automatically generates corresponding flag information and triggers the interface refresh mechanism. Specifically, a temporary prompt label (such as "Configuration updated, 2 tasks adapted in total") is added to the title bar of the target tab, which is hidden automatically after a certain period of time (such as 5 seconds). In the display bar of each associated task, a configuration information area is added or updated to display key adjustment results such as "Precision: FP16, Batch Size: 64", and the task status is updated to "To be executed (configuration updated)" (if the task is not started) or "Executing (adapted to new configuration)" (if the task is started). If potential risks are detected after configuration adjustment (such as the chip driver version not supporting FP16), a yellow warning icon and a prompt text (such as "Driver version V3.1 has limited support for FP16, please upgrade to V3.2") are added to the flag information.

[0085] The following describes how to achieve fine display and interaction of migration task progress and status through interactive task bars. Specifically, multiple interactive task bars are provided in each tab to display the execution progress and status of migration tasks, and each interactive task bar updates the display content through task status information. The model migration management subpage displays multiple tabs, each tab displays the progress of multiple model migration tasks of a model, including:

[0086] (1) In the target tab corresponding to the target model migration task, an interactive task bar is generated for each migration task.

[0087] It should be noted that the interactive task bar is a bar interface element within the tab for displaying the core information of a single migration task, supports user interaction operations such as clicking and hovering, can dynamically update the display content, and is the main visual carrier of task progress and status.

[0088] Specifically, after the model migration management platform completes the loading of the target tab, it automatically generates an independent interactive task bar for each task according to the number of migration tasks associated with the model of the tab. The interactive task bar includes a fixed information area (task name, target chip model) and a dynamic information area (progress display area, status identification area), the size is uniformly adapted to the width of the tab, and adjacent task bars maintain a fixed spacing to ensure neat layout.

[0089] (2) Call the task status monitoring script to periodically obtain the status parameters of each migration task.

[0090] The task state monitoring script is a program module specially used for tracking the running state of the migration task, can associate a specific task through a process ID or a task ID, and extract state parameters from a system kernel or a task execution log according to a preset period (such as 1 second / time); the state parameters include original data such as a task execution duration, a number of completed sub-steps, a currently running sub-module (such as an operator adaptation module), an error code (if an execution is abnormal), and a resource occupation peak value.

[0091] In a specific implementation, after the model migration management platform generates the interactive task bar, the task state monitoring script is automatically called, the script establishes a binding relationship with each migration task through a task ID, and state parameters are collected according to a preset period (such as 1 second / time). For a task being executed, dynamic data such as a current sub-step, a used time, and a progress ratio are extracted in real time; for a completed or failed task, final state parameters (such as a completion time and an error reason) are extracted at one time and periodic collection is stopped.

[0092] (3) The execution progress of each migration task is calculated based on the state parameters, and the progress display and task flag information of the corresponding interactive task bar are updated.

[0093] Specifically, the execution progress can be calculated based on a formula of a completed sub-step number / total sub-step number x 100% (for example, a model migration includes four sub-steps of analysis, operator adaptation, parameter calibration, and model generation, and the progress is 50% when two sub-steps are completed); the task flag information is determined according to a running state (normal execution / abnormal / complete) in the state parameters, and is identified by a combination of color and icon (for example, a green progress bar + a check mark indicates completion, and a red progress bar + an exclamation mark indicates abnormality).

[0094] In a specific implementation, the model migration management platform reads the state parameters from a real-time database, calculates the execution progress according to a preset formula (for example, the total steps are four steps, and the current completion is three steps, so the progress is 75%), then updates the progress display area (the progress bar length changes with the progress percentage) of the interactive task bar, and updates the flag information according to the task state. If it is in normal execution, it is displayed by a blue progress bar + “running” text; if it is in execution completion, it is displayed by a green progress bar + a check mark icon + “complete” text; if the task execution fails, the model migration management platform first determines the display area size of the task bar (such as a height of 50px and a width of 300px), calculates the number of lines of text that can be accommodated (about 3 lines according to a No. 12 font), then extracts error information (such as “operator XXX does not support FP16 precision, error code: E001”) from the state parameters, filters the core content (error type + key error code), and displays error prompt text (such as “error: operator incompatibility (E001)”) in a red background in the original progress bar area of the task bar, so as to clearly convey the failure reason in a limited space.

[0095] (4) In response to a user clicking an interactive task bar, a task detail acquisition script is called to load and display detailed execution information of the selected migration task.

[0096] The task detail acquisition script is a program module for extracting complete execution logs of a migration task. According to the task ID corresponding to the task bar clicked by the user, the full information of the task (including the start / end time of each sub-step, parameter adjustment record, resource occupation curve, warning information, etc.) can be queried from the system log library. Detailed execution information refers to more comprehensive original logs and statistical data than state parameters.

[0097] When a user clicks on an interactive task bar, the model migration management platform captures the click event and obtains the task ID corresponding to the task bar, triggering the task detail acquisition script. The script loads the full execution data of the task from the log library through the task ID (such as "parse sub-step: 00:00-00:02, time-consuming 2s, successfully extracted 32-layer network structure" "operator adaptation sub-step: 00:02-00:05, time-consuming 3s, replace 15 operators"), and performs structured processing on the data (sort by timeline, classify warning / normal information) to prepare for display.

[0098] (5) The detailed execution information is displayed in the migration task detail interface according to a preset template.

[0099] It should be noted that the migration task detail interface is an independent interface window that pops up after clicking the task bar, used to display the full execution information of a single task. The preset template is a fixed layout framework of the interface, including task basic information area, execution timeline area, resource occupation chart area, error / warning list area, etc.

[0100] Specifically, after obtaining the structured detailed execution information, the model migration management platform calls the detail interface rendering module to fill the data according to the preset template. Taking the above example, for example, the task basic information area displays task ID, associated model, target chip, start / end time, etc. static information; the execution timeline area displays the execution order, time-consuming, and results of each sub-step in the form of a timeline; the resource occupation chart area displays the CPU / memory occupation curve over time through a line chart; the error / warning list area displays error information (including error code, occurrence time, and suggested solution) in order of severity if there are any abnormalities.

[0101] It should be noted that after the task adjustment and interactive display logic of the model migration management sub-page is clear, the complete technical process of executing a target model migration task is introduced. Specifically, the execution of the target model migration task includes:

[0102] (1) Based on the model analysis sub-script, read the original algorithm model file corresponding to the target model migration task, extract the model architecture definition data, and convert the extracted model architecture definition data into intermediate data; the model architecture definition data at least includes the network layer structure of the model, the weight parameters of each layer, and the operator list relied on by the model.

[0103] It should be noted that the model analysis sub-script is a program module specially used for reading original model files, extracting key data, and standardizing, supporting mainstream model formats (such as ONNX, TensorFlow's.pb, and PyTorch's.pth); the original algorithm model file is an original model file that has not been adapted to the target chip, containing the complete structure and training parameters of the model; the model architecture definition data is the key information describing the core composition of the model, at least including the network layer structure (such as the number and connection order of convolutional layers and fully connected layers), the weight parameters of each layer (such as convolution kernel values and bias values), and the operator list relied on by the model (such as ReLU activation operators and MaxPooling pooling operators); the intermediate data is the standardized data converted from the model architecture definition data in a unified format (such as a custom JSON structure), which can eliminate the differences between different original model formats.

[0104] In specific implementation, the model analysis sub-script first receives the configuration instruction of the target model migration task (including the original model file path and model format), reads the original model file by calling the analysis interface of the corresponding format, then extracts the model architecture definition data from the original model file, such as extracting the network layer structure of 3 convolutional layers + 2 fully connected layers, the weight matrix of each layer, and the operator list, and finally converts these extracted data into a unified intermediate data format.

[0105] (2) Based on the operator adaptation sub-script, process the operator list in the intermediate data.

[0106] The operator library supported by different chips is different (such as NVIDIA chips supporting CUDA operator library, and domestic chips supporting self-developed operator library), if the operator relied on by the original model is not supported on the pre-migration chip, the model will not run. Therefore, through the operator adaptation sub-script, the operators not supported by the chip in the intermediate data are replaced with equivalent operators compatible with the chip, or the original operators are functionally decomposed, to ensure that the model can normally call computing resources on the target chip.

[0107] The operator adaptation sub-script first loads the operator support list of the pre-migration chip, compares it with the operator list in the intermediate data one by one, and screens out incompatible operators; then, the incompatible operators are processed according to the operator mapping rule library (preset incompatible operator-compatible operator corresponding relationship). Specifically, two processing methods of direct replacement or function decomposition can be adopted, if there is a compatible operator that is completely equivalent in function, the operator list of the intermediate data is directly updated; if there is no directly equivalent operator, the operator is decomposed into a combination of basic operators supported by the pre-migration chip, and the operator list and network layer structure description of the intermediate data are updated.

[0108] (3) Based on the parameter calibration sub-script, the model weight parameters in the intermediate data are numerically converted and accuracy calibrated to generate a model parameter file adapted to the pre-migration chip.

[0109] The parameter calibration sub-script is a program module for adjusting the numerical format and accuracy of the model weight parameters to adapt to the hardware characteristics of the target chip; numerical conversion refers to converting the numerical format of the weight parameters (such as FP32 single-precision floating point) to the format supported by the target chip (such as FP16 half-precision floating point); the purpose of accuracy calibration is to reduce the accuracy loss during numerical conversion through algorithms (such as the least mean square error method and the KL divergence calibration method) to ensure that the converted parameters can still maintain the prediction accuracy of the model; the model parameter file is a file that stores the calibrated weight parameters in the format required by the target chip and can be directly loaded and used by the chip.

[0110] Specifically, the parameter calibration sub-script first reads the parameter format requirements of the pre-migration chip (such as the domestic chip B200 recommending the use of FP16 precision to improve computing efficiency), extracts the weight parameters of the model (such as the 32-bit floating point weight matrix of the convolution layer) from the intermediate data; then, two-step processing is performed, the weight parameters are converted from the original format to the format supported by the chip through a numerical scaling algorithm (such as linear mapping of FP32 weight values to the numerical range of FP16); further, the KL divergence calibration method can be used to compare the probability distribution difference of the weight parameters before and after conversion, fine-tune the parameter values (such as adjusting the number of decimal places of part of the weight), and control the accuracy loss within a preset threshold (such as a loss rate <1%); finally, the calibrated weight parameters are stored in the format required by the chip (such as binary.bin), and a model parameter file adapted to the pre-migration chip is generated. In this way, through numerical conversion and accuracy calibration, the parameter format can be adapted to the chip characteristics on the premise of ensuring the model accuracy, and the computing performance of the chip can be maximized.

[0111] (4) Based on the task monitoring sub-script, the execution state parameters of each sub-script are obtained, and when an exception is detected, an exception handling mechanism is triggered to feed back the error information to the model migration management sub-page.

[0112] It should be noted that the task monitoring sub-script is a monitoring module for real-time tracking of the running state of each sub-script in steps (1)-(3), capturing exceptions and triggering processing. The execution state parameter is the key data describing the running condition of the sub-script, including whether the sub-script is started, the current execution progress, whether an error is thrown (such as file reading failure, operator matching error), error code and error description (such as "E001: original model file does not exist"). The exception handling mechanism is a preset exception handling strategy, including pausing the current sub-script running, recording error logs (including timestamp, error details), pushing error information to the model migration management sub-page, providing repair suggestions (such as "E001 suggestion to check file path") and the like.

[0113] The task monitoring sub-script is started synchronously when the migration task is started, and is associated with the model parsing sub-script, the operator adaptation sub-script and the parameter calibration sub-script through process ID binding, and then the execution state parameters of each sub-script are obtained at a preset period (such as every 0.5 seconds). If the state parameter shows that the sub-script is normally executed (such as 100% completion of model parsing, no error code), continuous monitoring is performed; if an exception is detected (such as the operator adaptation sub-script returns "E002: no compatible operator matched"), the exception handling mechanism is triggered immediately, the operator adaptation sub-script is paused, the error log ("time: 14:30, error code E002, details: original operator CUDA_MaxPooling has no compatible operator") is written into the system log library, and the error information is pushed to the model migration management sub-page (displayed in the form of a red warning box "operator adaptation failed: no compatible operator matched, suggest updating the chip operator support list") at the same time. The whole monitoring process continues until all sub-scripts are completed or terminated abnormally.

[0114] (5) In the case that all sub-scripts are executed and no exception occurs, the migration script generates a post-migration model file based on the pre-migration chip.

[0115] When the task monitoring sub-script confirms that the model parsing sub-script, the operator adaptation sub-script and the parameter calibration sub-script are normally executed (no error code, 100% progress), a generation instruction is sent to the migration script; after the migration script receives the instruction, the updated intermediate data (including the adapted operator list and network layer structure) are read from the system cache, and the model parameter file generated in step (3) is loaded, the network structure of the intermediate data and the weight data of the model parameter file are integrated according to the model format supported by the pre-migration chip, and a complete post-migration model file is generated; finally, the file is stored to the specified path of the pre-migration chip, and a task completion notification (such as a green prompt box "migration successful, model file saved to path XXX") is pushed to the model migration management sub-page.

[0116] Based on the specific implementation described above, the migration task management mechanism provided in this embodiment is fundamentally based on a unified and intelligent interface architecture and task processing logic. Firstly, at the interface display level, the model migration management subpage adopts a preset matrix tab layout as its unified display pattern. All tabs are arranged sequentially at the top of the page, forming a clear horizontal navigation structure, with each tab bound to a unique model identifier. These tabs are defined as interactive elements with clickable selection, hover prompts, and draggable sorting capabilities. When a user clicks to select any tab, the interface highlights it with a significant visual contrast (such as a darker background color and thicker borders). Crucially, the text displayed on the tabs is not fixed but dynamically determined based on semantic analysis technology. This technology intelligently extracts core functional terms (such as defect identification) from the complete model name while filtering out secondary information such as version numbers and manufacturer prefixes. Combined with the available display width of the current tab, it intelligently truncates or abbreviates the text, ensuring that the most essential and easily identifiable information is conveyed to the user within the limited interface space.

[0117] Secondly, the platform offers a highly intelligent user experience in the task creation process. Whether for a known or unknown chip, the core user operation is simplified to simply specifying the target chip and the model to be migrated. For known chips, the platform automatically performs chip-model compatibility verification in the background and incorporates a deduplication mechanism to avoid creating identical tasks. When creating new tasks increases the number of tabs, the interface adaptively adjusts the display size of all tabs proportionally. For unknown chips, the platform automatically triggers a complete chip configuration process, seamlessly completing the entire process from chip information creation to migration task creation. In all scenarios, key migration parameters (such as precision mode, batch size, and operator optimization strategies) are automatically recommended and the optimal solution is determined by the platform based on in-depth analysis of chip performance characteristics and model structural features. This intelligent parameter configuration scheme maximizes the computational performance of the target chip while ensuring model accuracy.

[0118] Finally, for dynamic adjustments during task execution, the platform established a set of time-based overarching processing principles. The core idea is to use the time when the user submits configuration modifications as the boundary. For all migration tasks after this point, the latest migration scheme is directly adopted for execution. For migration tasks completed before this point, the platform will identify key parameter changes by comparing the configuration differences between the old and new schemes, and then evaluate the performance improvement potential of the migrated model. Subsequently, a gradual fine-tuning strategy is adopted to adjust the affected hierarchical parameters in a targeted manner while maintaining the stability of the main model structure. Finally, the optimization effect is confirmed through validation set testing to ensure that the model's performance is substantially improved.

[0119] S103, determine the pre-migration chip information corresponding to the pre-migration model completing the model migration task.

[0120] It should be noted that the pre-migration model refers to the model that has been adapted to the target chip after the model migration process (analysis, operator adaptation, parameter calibration, etc.) in S102. The pre-migration chip information refers to the identification information of the target chip on which the pre-migration model will finally be deployed and run.

[0121] When the model migration task is completed (S102 step (5) generates the migrated model file and there is no exception), the model migration management platform will automatically trigger the associated information extraction process, extract the task configuration information from the history record of the migration task, and filter out the target chip identification corresponding to the task (such as the "domestic chip B200" bound during task creation); call the associated storage interface of the chip configuration sub-page to verify whether the chip corresponding to the chip identification is in a usable state (such as normal driving, not occupied); if the chip is available, bind the complete information of the chip (model, manufacturer, device ID, hardware parameter summary, etc.) with the pre-migration model (identified by the unique hash value or name of the model file), generate a model-chip association record, and store it in the system database; if the chip is not available (such as damaged or removed), the model migration management sub-page prompts the user that "the target chip is not available, please specify the pre-migration chip again", and provides a chip selection list for the user to re-associate.

[0122] S104, generating an evaluation task for the pre-migration model based on the pre-migration chip information, and modifying the number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management sub-page based on the result of the evaluation task.

[0123] It should be noted that the pre-migration chip information (such as chip model, hardware parameters) determined by S103 is used to generate a targeted evaluation task (evaluation dimensions include model accuracy, inference speed, resource occupation, etc., which need to match the hardware characteristics of the chip), then the evaluation task is executed and the number of migration task display bars in the tab corresponding to the pre-migration model in the model migration management sub-page is modified according to the result (whether the model meets the standard), if the evaluation passes, the display may be simplified (such as deleting duplicate task bars); if the evaluation fails, the task bar may be retained or added (such as displaying a "re-migration" task), ensuring that the interface display is consistent with the actual state of the task. In this way, the model adaptability is verified through the evaluation task, and the interface display is updated synchronously, so that the user can know whether the model is available, and also can quickly locate the effective or ineffective task through the interface, improving the management efficiency.

[0124] It should be noted that modifying the number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management sub-page based on the result of the evaluation task includes:

[0125] (1) Collect the basic information of the pre-migration model and the post-migration model, and generate model description data.

[0126] It should be noted that the model description data is structured data that integrates the basic information of the two types of models in a unified format, which is used for subsequent evaluation and comparison, and at least includes model name, version, network structure summary (such as 3-layer convolution + 2-layer full connection), original training dataset, input and output dimensions, dependent operator list, etc.

[0127] Specifically, the model migration management platform reads the metadata of the pre-migration model (such as model creation time, training completion time) from the system model library, extracts the adaptation information (such as the adapted chip model, the converted precision format FP16) from the post-migration model file generated in S102, and integrates the information of the two types of models according to the pre-set template (such as JSON format), to generate model description data.

[0128] (2) Prepare evaluation sample data according to the application scenario of the migrated model, and perform evaluation tasks on the pre-migration model and the post-migration model.

[0129] The evaluation sample data needs to be consistent with the actual application scenario of the model to ensure that the evaluation results can reflect the performance of the model in the real scenario, and the evaluation task needs to design core dimensions around the characteristics of the pre-migration chip to avoid the disconnection between general evaluation and chip adaptability. The model migration management platform selects the required evaluation samples (such as 1000 power equipment images containing different defect types, covering normal, short circuit, aging, etc.) from the scenario sample library according to the application scenario of the migrated model (such as power equipment defect identification), while ensuring that the sample data format matches the model input dimension (such as adjusting the image resolution to 224x224). Run the pre-migration model (which needs to be temporarily loaded through the compatible mode) and the post-migration model on the pre-migration chip, and perform evaluation according to the pre-set dimensions, for example, the pre-set dimensions can include precision dimensions (such as defect identification accuracy, prediction error); performance dimensions (such as inference speed FPS, single sample processing time); resource dimensions (such as memory occupancy, computing core utilization); stability dimensions (such as the number of crashes in continuous running for 1 hour) and the like, and record the evaluation data of the two types of models in real time.

[0130] (3) After the evaluation is completed, difference analysis data is generated based on the evaluation results of the pre-migration model and the post-migration model, and whether the performance of the post-migration model meets the preset conditions is determined according to the difference analysis data; wherein, after the real-time execution progress in the migration stage is greater than the preset value, the real-time execution progress is processed based on a preset reduction ratio, and the processed progress is displayed, when the real-time execution progress is 100%, the progress bar display progress of the migration task is less than 100%, and the progress bar display vacancy area is filled based on the progress in the verification stage after the real-time execution progress is 100%.

[0131] It should be noted that after the evaluation is completed, the platform will verify the execution of the task itself, the decision based on the results, and the integrated progress display synchronized with the task execution. Specifically, after the evaluation task is executed, the model migration management platform will generate structured difference analysis data based on the evaluation results of the pre-migration and post-migration models. This data clearly records the specific change values and trends of each evaluation dimension (such as accuracy, inference speed, and resource occupation), for example, "the accuracy of the post-migration model decreases by 2%, and the inference speed increases by 120%". The platform then automatically compares the difference analysis data with the preset model standard (such as an accuracy decrease of no more than 3% and an inference speed of no less than 1.5 times that of the pre-migration model), thereby objectively determining whether the performance of the post-migration model meets the requirements. If the post-migration model meets all the preset conditions, the evaluation is determined to be passed, the platform automatically marks the migration task as successful, deletes its progress bar in the model migration management sub-page, permanently associates the final evaluation results and verification data with the migration task, and adds a success identifier in the task bar of the corresponding model tab. If there are multiple repeated migration task bars for the same model and chip, the platform will intelligently delete redundant entries and only keep the final successful task record to ensure the simplicity and efficiency of the interface display. If the post-migration model does not meet the preset conditions, an optimization iteration cycle is immediately started, the platform automatically reverts to the corresponding migration sub-process (such as the parameter calibration sub-script) based on the specific performance shortcomings (such as insufficient accuracy) revealed by the difference analysis data, and uses more refined algorithms (such as the KL divergence calibration method) to fine-tune the parameters of the model. The platform executes the closed-loop process of model updating-re-evaluation according to the preset number of repetitions (for example, 3 times). If the model performance meets the standard within the number of cycles, it is processed according to the successful path described above; if the model still does not meet the standard after reaching the maximum number of repetitions, the platform terminates the cycle and explicitly displays the failure reason (for example, "after 3 optimizations, the accuracy loss still exceeds the threshold") in the corresponding tab of the model migration management sub-page, and keeps the failed task bar for problem tracing.

[0132] To ensure that the user can intuitively perceive the complete process of migration from the model to the effect verification, the platform designs and implements an intelligent display mechanism that combines the migration stage and the verification stage progress. In the early stage of the migration task execution, the progress bar reflects the actual completion percentage of the migration process (S102) in real time. When the real-time progress of the migration stage exceeds a preset threshold A% (for example, 90%), the display logic of the progress bar will switch to a scaling mode. In this mode, the subsequent migration progress will be displayed in a scaled manner according to a preset scaling ratio K (for example, K = 0.8) less than 1, which means that when the migration task itself is 100% complete in the background, the progress bar only displays to A% + (100% - A%) x K (for example, 90% + (10% x 0.8) = 98%), rather than 100%. The purpose of this is to reserve a certain display space (100% - 98% = 2%) to represent the verification stage that follows. After the verification task is started, the complete execution process is scaled and mapped into the 2% display interval. The progress bar increases by a corresponding percentage based on the current scaled progress (for example, 98%) according to the preset weight every time a key sub-step (such as sample loading, precision evaluation, performance evaluation, etc.) of the verification task is completed. Only when the verification task is completely executed and the final result meets the standard, the progress bar will gradually fill from 98% to 100%, marking the complete end of the entire migration + verification process.

[0133] Through this mechanism, the progress bar accurately reflects the weight of the migration and verification stages in the actual total task time, effectively avoiding misleading the user due to the completion of migration and displaying 100%, and truly and transparently presenting the overall progress of the task completion.

[0134] It should be further noted that in actual scenarios, migration tasks of the same model for different chips, or migration tasks between different models with dependency relationships (such as the migration of "power load prediction model V1.0" and "V2.0"), often have reusable parameters (such as operator adaptation rules and precision calibration parameters). By establishing a parameter inheritance relationship and sorting, the child task can directly reuse the effective parameters of the parent task, reducing repeated calculations, while ensuring that the task is executed in the order of dependency, avoiding conflicts.

[0135] It should be noted that the method provided by the application further includes:

[0136] (1) Obtain a plurality of migration tasks in a migration queue.

[0137] It should be noted that the migration queue is a collection of all migration tasks waiting for execution or being executed in the system, containing task ID, associated model, target chip, priority, creation time and other basic information. The model migration management platform reads all pending migration tasks (such as "task 1: model A→chip X" "task 2: model A→chip Y" "task 3: model B→chip X") from the system task pool through the task scheduling interface, and preliminarily classifies them according to the creation time+model name to form a migration task list.

[0138] (2) Based on the task constraint conditions and model characteristics of the plurality of migration tasks, determine the parameter inheritance relationship between the migration tasks.

[0139] It should be noted that the task constraint conditions include task relevance (such as whether based on the same base model), accuracy requirement (such as whether to allow the same accuracy loss range), resource limitation (such as whether to share chip computing power), etc.; the model characteristics refer to the functional characteristics of each layer of the model (such as the feature extraction logic of the convolution layer, the classification rule of the fully connected layer), the model version association (such as V2.0 is the upgraded version of V1.0), etc.; the parameter inheritance relationship refers to the parent-child dependency relationship between tasks, and the child task can directly reuse part of the parameters of the parent task (such as operator adaptation result, calibration algorithm parameter) without the need for re-computation.

[0140] If multiple tasks are associated with the same model, the relationship is determined by calculating the comprehensive similarity between the tasks, wherein the comprehensive similarity is obtained by quantitatively comparing the constraint conditions and the target chip architecture of the tasks, and the calculation covers two core dimensions. First, compare the accuracy requirements of the tasks to calculate the ratio of their allowed accuracy loss ranges; second, compare the hardware architectures of the target chips, and comprehensively consider the matching degree of key parameters such as the number of computing cores and memory bandwidth. When the calculated comprehensive similarity is greater than a preset threshold (for example, 85%), it is determined that the tasks meet the parameter inheritance condition and can be determined as siblings. At this time, one of them can be designated as the parent task and the others as child tasks, and the child tasks inherit the operator adaptation rules of the parent task; if the models associated with the tasks have version dependencies (such as "model V2.0" of task 2 is based on "model V1.0" of task 1) and the core network layer functional characteristics are consistent (such as the convolution layer structure does not change), then task 1 is determined as the parent task and task 2 is determined as the child task, and the child task inherits the weight parameter calibration method of the parent task; if the tasks are associated with different models and have no version association (such as model A and model B are unrelated), there is no parameter inheritance relationship and they are all independent tasks.

[0141] (3) According to the parameter inheritance relationship, sort the plurality of migration tasks.

[0142] Specifically, the execution order of parent tasks is prior to that of child tasks, ensuring that child tasks can reuse the calculation results of parent tasks. If there is no inheritance relationship between independent tasks, the tasks are sorted according to priority or creation time.

[0143] In a specific implementation, all parent tasks are placed at the front of the queue and sorted according to creation time or priority (for example, task 1 has the highest priority and is placed at the front); each child task is placed immediately after the corresponding parent task, and if there are multiple child tasks for the same parent task (for example, task 1 has child tasks 2 and 3), the child tasks are sorted according to the similarity to the parent task (for example, task 2 is more similar to task 1 in chip architecture and is placed before task 3); independent tasks are placed after all dependent tasks and sorted according to creation time.

[0144] (4) When a new migration task is added or a task parameter is updated, the parameter inheritance relationship is re-determined and the migration task is re-ordered.

[0145] It should be noted that when a user adds a migration task (for example, adding "task 4: model V1.0→chip C300") or modifies the parameters of an existing task (for example, changing the precision requirement of task 1 from "allow loss 3%" to "allow loss 1%"), the original parameter inheritance relationship may be invalid and needs to be re-analyzed.

[0146] Specifically, when a new task is added, the model migration management platform adds the new task to the migration queue, re-compare the constraint conditions and model characteristics of the new task with existing tasks (for example, task 4 is the same model as task 1 and is determined as a child task), and inserts the new task after the corresponding parent task (for example, 1→2→4→3); when a task parameter is updated, if the parent task parameter (for example, the precision requirement of task 1) is changed, the platform re-checks whether the child task still meets the inheritance condition (for example, whether the precision requirement of task 2 is compatible with the updated parent task), and if not, the inheritance relationship is cancelled and the tasks are re-ordered (for example, task 2 becomes an independent task and is placed at the end of the queue).

[0147] The method provided in this embodiment integrates scattered chip hardware parameters and driver information into a standardized configuration file through a tab-based creation process on the chip configuration subpage, and establishes an association storage mechanism between the chip tab and migration tasks. The chip tab can display the progress of associated migration tasks, and the model migration management subpage can display the corresponding target chip information. This solves the problems of fragmented chip information and disconnect between tasks and chips in traditional migration, allowing users to trace the relationship between chips and tasks bidirectionally from any subpage, significantly reducing information query and management costs. Through the design of target tab positioning, interactive task bar, and real-time progress updates, the progress of multiple migration tasks for a single model can be tracked. (For example, migrating the same power model to different domestic chips) is presented in a visual format. Users can click on the task bar to view detailed execution information, solving the problems of unintuitive progress and difficulty in tracking details in traditional command-line tools. Simultaneously, it supports dynamic updates to task execution configuration by inputting chip performance parameters and automatically adjusts the process through migration scripts, avoiding resource waste or underperformance caused by static configuration. This ensures deep adaptation between migration tasks and chip hardware characteristics, improving migration efficiency and model performance. Furthermore, it designs scenario-based evaluation samples (such as power equipment defect identification samples) and integrated progress displays specifically for the characteristics of domestic chips, solving the problems of traditional evaluations being detached from chip characteristics and progress feedback being disconnected. At the same time, it dynamically adjusts the number of tasks displayed in the tabs based on evaluation results. For tasks that meet the criteria, redundant progress bars are removed and linked to evaluation data; for failed tasks, the reasons are displayed and historical records are retained. This allows users to quickly identify valid migration results, avoid resource waste caused by invalid migrations, and ensure that the migrated model can be reliably deployed directly on the target chip. It should also be noted that by analyzing task constraints and model characteristics, parameter inheritance relationships between tasks are established, and tasks are executed in order of priority according to the parent task. When adding a new task or updating parameters, the relationships and order are automatically readjusted, which solves the problems of repeated parameter configuration and disordered task execution in traditional batch migration. This design allows multiple tasks to reuse core parameters and execute efficiently in the order of dependencies, greatly reducing the manual intervention cost and computing resource consumption of batch migration.

[0148] Example 2

[0149] Corresponding to the aforementioned embodiment of a cross-platform model migration method, this application also provides an embodiment of a cross-platform model migration apparatus.

[0150] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the cross-platform model transfer device provided in this application. Please refer to... Figure 2 The device provided in this embodiment includes a management module 210, an adjustment module 220, a determination module 230, and a processing module 240;

[0151] The management module 210 is configured to manage chip information configuration in a chip configuration subpage;

[0152] The adjustment module 220 is configured to adjust a target model migration task in a model migration management subpage, determine a target tab based on a model corresponding to the target model migration task, execute the target model migration task, and display a corresponding task progress in the target tab, wherein the model migration management subpage displays a plurality of tabs, each tab displays a progress of a plurality of model migration tasks of a model, and a display size of each tab is adaptively determined according to display content and a number of tabs, and the model migration task is a task of fine-tuning a model structure and parameters based on a new sample.

[0153] The determination module 230 is configured to determine pre-migration chip information corresponding to a pre-migration model that completes a model migration task.

[0154] The processing module 240 is configured to generate an evaluation task of the pre-migration model based on the pre-migration chip information, and modify a number of model migration task display bars in a tab corresponding to the pre-migration model in the model migration management subpage based on a result of the evaluation task.

[0155] The device of the embodiment can be used to execute Figure 1 The steps of the method embodiment are similar in implementation principle and process, and will not be described here.

[0156] The implementation process of the functions and roles of each unit in the above device is specifically described in the implementation process of the corresponding steps in the above method, which will not be described here.

[0157] For the device embodiment, since it basically corresponds to the method embodiment, the related parts can be referred to the part of the method embodiment. The device embodiments described above are only illustrative, and the units described as separate components can be or can not be physically separated, and the components displayed as units can be or can not be physical units, that is, they can be located in one place or distributed on multiple network units. According to actual needs, part or all of the modules can be selected to achieve the purpose of the present application. Those skilled in the art can understand and implement without creative labor.

[0158] The above is only the preferred embodiment of the present application, and is not used to limit the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A cross-platform model migration method, characterized in that, The method comprises: managing chip information configuration in a chip configuration subpage; adjusting a target model migration task in a model migration management subpage, determining a target tab based on a model corresponding to the target model migration task, executing the target model migration task, and displaying a corresponding task progress in the target tab, wherein the model migration management subpage displays a plurality of tabs, each tab displays the progress of a plurality of model migration tasks of one model, the display size of each tab is adaptively determined according to the display content and the number of tabs, and the model migration task is a task of fine-tuning the model structure and parameters based on new samples; determining pre-migration chip information corresponding to a pre-migration model of a completed model migration task; the pre-migration model of the completed model migration task is a migrated model obtained after the model migration task is completed, and the pre-migration chip information is identification information of a target chip; generating an evaluation task of the pre-migration model based on the pre-migration chip information, and modifying the number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management subpage based on the result of the evaluation task.

2. The method of claim 1, wherein, The method comprises: based on the chip identification information input by the user, a chip tab is newly created in the chip configuration subpage, and the display size of all display objects is re-determined according to the size of the display space and the number of display objects in the chip configuration subpage; triggering a configuration analysis script to analyze the chip identification information to obtain hardware parameters and driver version information of the chip; generating a corresponding chip configuration information file based on the hardware parameters and driver version information; loading the chip configuration information file to the chip configuration subpage, and displaying the chip configuration state in the chip tab; when a chip tab is newly added in the chip configuration subpage, the interface adjusts the font and tab size according to the number of tabs and display content.

3. The method of claim 1, wherein, An associated storage mode is established between the chip configuration subpage and the model migration management subpage, wherein in the chip configuration subpage, a plurality of migration task information associated with the chip is displayed, wherein each chip tab displays detailed information of the current chip and lists the progress of all migration tasks related to the current chip, and each migration task displays the execution state through flag information; in the model migration management subpage, the target chip information corresponding to the migration task is displayed, each task tab displays the information of the target chip related to the current task, and the execution progress and state of the current task are displayed; the chip tab in the chip configuration subpage and the task tab in the model migration management subpage are updated through a preset association, when a new chip or migration task is added, the related tab information is automatically refreshed and displayed in the corresponding page.

4. The method of claim 1, wherein, The method comprises: receiving a target model migration task selected by a user; determining a corresponding target tab in the migration task management subpage based on a model corresponding to the target model migration task; The migration script is called to execute the target model migration task and collect task execution state data in real time; A display area corresponding to the target model migration task is added in the target tab, and the display area displays the landmark information in the task execution state data.

5. The method of claim 1, wherein, The target model migration task is adjusted in the model migration management subpage, including: Receiving the chip performance parameters input by the user in the target tab; Based on the chip performance parameters, the target model migration task associated with the chip is located, and the execution configuration data of each target model migration task is updated; The migration script adjusts the model migration process according to the updated configuration; The landmark information is updated synchronously in the target tab and the corresponding migration task display bar.

6. The method of claim 1, wherein, Each tab is provided with a plurality of interactive task bars for displaying the execution progress and state of the migration task, and each interactive task bar updates the display content through task state information. The model migration management subpage displays a plurality of tabs, and the progress of a plurality of model migration tasks of one model is displayed in each tab, including: An interactive task bar is generated for each migration task in the target tab corresponding to the target model migration task; A task state monitoring script is called to periodically obtain the state parameters of each migration task; Based on the state parameters, the execution progress of each migration task is calculated, and the progress display and task landmark information of the corresponding interactive task bar are updated; In response to the user clicking an interactive task bar, a task detail acquisition script is called to load and display the detailed execution information of the selected migration task; The detailed execution information is displayed in the migration task detail interface according to a preset template.

7. The method of claim 1, wherein, The execution target model migration task includes: Based on the model analysis sub-script, the original algorithm model file corresponding to the target model migration task is read, the model architecture definition data is extracted, and the extracted model architecture definition data is converted into intermediate data; the model architecture definition data at least includes the network layer structure of the model, the weight parameters of each layer, and the operator list on which the model depends; Based on the operator adaptation sub-script, the operator list in the intermediate data is processed; Based on the parameter calibration sub-script, the model weight parameters in the intermediate data are numerically converted and accuracy calibrated to generate a model parameter file adapted to the pre-migration chip; Based on the task monitoring sub-script, the execution state parameters of each sub-script are obtained, and an exception handling mechanism is triggered when an exception is detected, and error information is fed back to the model migration management subpage; In the case that all subscripts are executed and there is no exception, the migration script generates a post-migration model file on the pre-migration chip.

8. The method of claim 1, wherein, The number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management subpage is modified based on the results of the evaluation task, including: Collecting the basic information of the pre-migration model and the post-migration model to generate model description data; According to the application scenario of the migration model, prepare evaluation sample data, and execute evaluation tasks on the pre-migration model and the post-migration model; After the evaluation is completed, difference analysis data is generated based on evaluation results of the pre-migration model and the post-migration model, and whether the performance of the post-migration model meets a preset condition is determined according to the difference analysis data; The real-time execution progress is processed based on a preset reduction ratio after the real-time execution progress in the migration stage is greater than a preset value, and the processed progress is displayed. When the real-time execution progress is 100%, the progress bar display progress of the migration task is less than 100%. The progress bar display gap area after the real-time execution progress is 100% is filled based on the progress of the verification stage.

9. The method of claim 1, wherein, The method further comprises: Obtaining a plurality of migration tasks in a migration queue; Based on the task constraint conditions and model characteristics of the plurality of migration tasks, determining the parameter inheritance relationship between the migration tasks; According to the parameter inheritance relationship, the plurality of migration tasks are sorted; When a new migration task or an updated task parameter is added, the parameter inheritance relationship is re-determined and the sorting of the migration tasks is adjusted.

10. A cross-platform model migration apparatus, comprising: The device comprises a management module, an adjustment module, a determination module and a processing module; The management module is configured to manage chip information configuration in a chip configuration sub-page; The adjustment module is configured to adjust a target model migration task in a model migration management sub-page, determine a target tab based on a model corresponding to the target model migration task, execute the target model migration task and display the corresponding task progress in the target tab, wherein the model migration management sub-page displays a plurality of tabs, each tab displays the progress of a plurality of model migration tasks of one model, the display size of each tab is adaptively determined according to the display content and the number of tabs, and the model migration task is a task of fine-tuning the model structure and parameters based on new samples; The determination module is configured to determine pre-migration chip information corresponding to a pre-migration model that has completed a model migration task, wherein the pre-migration model is a post-migration model obtained after completing the model migration task, and the pre-migration chip information is the identification information of a target chip; The processing module is configured to generate an evaluation task of the pre-migration model based on the pre-migration chip information, and modify the number of model migration task display bars in the tab corresponding to the pre-migration model in the model migration management sub-page based on the result of the evaluation task.

Images