A service-based tool chain algorithm warehouse management method and system

Abstract

The embodiment of the application provides a kind of algorithm warehouse management method and system based on service tool chain, belong to algorithm warehouse management technical field.The method is matched resource demand by task category identification, generates hardware resource available parameter sequence in combination with the dynamic resource occupation prediction of parallel task of execution terminal, the first screening action is based on the resource fitting degree calculation matching degree per time, substantially improve the resource adaptation accuracy of algorithm model and execution terminal, reduce resource waste, the second screening action is combined with the historical execution information of target service terminal and non-target service terminal, both guarantee the confidence of single task to meet standard, also through service terminal group confidence distribution adjustment execution terminal selection, ensure the overall execution stability of system.Based on the confidence ratio of service terminal group, the execution terminal selection range is dynamically adjusted, the intelligent management of system confidence and computing power reserve is realized, extreme imbalance is avoided, and the adjustability of long-term operation is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of algorithm repository management technology, specifically to an algorithm repository management method based on a service-oriented toolchain and an algorithm repository management system based on a service-oriented toolchain. Background Technology

[0002] In distributed computing scenarios, the periodic execution tasks of service terminal groups need to be efficiently matched with the algorithm model and the execution terminal through scheduling terminals. As the core resource pool, the management efficiency of the algorithm repository directly affects the stability of task execution and resource utilization.

[0003] Existing algorithm repository management methods generally suffer from the following shortcomings: First, resource matching lacks precision. Most methods only match task types with static hardware configurations of execution terminals, failing to consider the dynamic resource consumption patterns of parallel tasks on the execution terminals. This leads to inaccurate estimations of available hardware resources, low adaptability between algorithm models and execution terminal resource requirements, and a tendency for resource waste or task execution failures. Second, overall task execution stability is poorly controlled. Existing solutions often focus on the execution results of individual tasks, neglecting to consider the historical execution information of the service terminal group for overall planning. They ignore the impact of the confidence distribution between target and non-target service terminals on the overall system stability, potentially leading to some service terminals having persistently low confidence levels and a decline in overall system execution quality. Third, there is a lack of dynamic adjustment mechanisms. Existing selection logic is mostly based on fixed rules, failing to dynamically adjust the execution terminal selection strategy according to the system confidence level. This can easily lead to extreme situations such as wasted computing power at high confidence levels or insufficient computing power reserves at low confidence levels, failing to achieve a dynamic balance between system confidence and computing power reserves. Over long-term operation, this may result in an unadjustable deadlock.

[0004] Therefore, existing algorithm repository management methods struggle to simultaneously address the three core requirements of accurate resource matching, overall execution stability, and dynamic balance adjustment, thus limiting the task processing capabilities and long-term operational stability of distributed systems. Summary of the Invention

[0005] The purpose of this invention is to provide an algorithm repository management method and system based on a service-oriented toolchain, so as to at least solve the problems of inaccurate resource matching, poor overall execution stability, and lack of dynamic adjustment mechanism in the prior art.

[0006] To achieve the above objectives, the first aspect of the present invention provides an algorithm repository management method based on a service-oriented toolchain for scheduling terminals, the method comprising:

[0007] When a request for algorithm invocation for a periodically executed task is received from a target service terminal in the service terminal group, the task category identifier of the periodically executed task is extracted.

[0008] Using the task category identifier, the task execution resource requirements of periodically executed tasks are matched to generate a sequence of available hardware resource parameters for each execution terminal within the task execution window;

[0009] The query service terminal group retrieves the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminals; wherein the first historical task execution information and the second historical task execution information include the algorithm analysis results of the corresponding service terminal executing tasks in several historical periods, and the algorithm analysis results include the algorithm execution time and the algorithm analysis confidence level;

[0010] Based on the sequence of available hardware resources for each execution terminal within the task execution window, the algorithm repository of the service-oriented toolchain and the execution terminal group respectively execute a first screening action related to hardware resource matching and a second screening action related to the overall task execution stability determined by the algorithm analysis results of several historical sets of periodic execution tasks between the target service terminal and non-target service terminals, thereby generating the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task.

[0011] Based on the optimal combination scheme, algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal are generated to complete task distribution and execution.

[0012] Optionally, upon receiving an algorithm call request for a periodically executed task uploaded by a target service terminal in the service terminal group, the task category identifier of the periodically executed task is extracted, including:

[0013] Receive the algorithm call request for the periodically executed task uploaded by the target service terminal in the service terminal group, parse and extract the task category field as the initial category identifier;

[0014] The standard task category library is pre-stored in the algorithm repository of the query service toolchain; wherein, the standard task category library contains all supported task category identifiers and corresponding encoding rules;

[0015] The extracted initial category identifier is matched with the standard task category library. If a match is found, the corresponding standard code is used as the task category identifier for the periodically executed task.

[0016] Optionally, using the task category identifier, the task execution resource requirements of periodically executed tasks are matched to generate a sequence of available hardware resource parameters for each execution terminal within the task execution window, including:

[0017] Using the task category identifier, the task execution resource requirements of periodically executed tasks are matched; wherein, the task execution resource requirements include task execution window requirements and hardware resource usage parameter requirements;

[0018] Query the parallel task execution list of several execution terminals in the execution terminal group, and generate a sequence of available hardware resource parameters for each execution terminal within the task execution window based on the execution time period and resource usage information of each parallel task in the parallel task execution list.

[0019] Optionally, the task category identifier is used to match the task execution resource requirements of periodically executed tasks, including:

[0020] The algorithm repository of the service-oriented toolchain is used to call the pre-stored task category and resource requirement mapping table; each record is associated with a task category identifier, the corresponding standard task execution window range, and the hardware resource usage parameter range;

[0021] Based on the task category identifier, query the standard task execution window range in the task category and resource requirement mapping table. Combine the real-time indicators corresponding to the task category identifier, and take the intersection of the standard task execution window range and the real-time indicators to determine the task execution window requirement.

[0022] Based on the task category identifier, match the task category with the corresponding hardware resource usage parameter range in the resource requirement mapping table, and take the midpoint of the range for each type of hardware resource to determine the hardware resource usage parameter requirement.

[0023] Optionally, the parallel task execution list of several execution terminals in the execution terminal group is queried. Based on the execution time period and resource usage information of each parallel task in the parallel task execution list, a sequence of available hardware resource parameters for each execution terminal within the task execution window is generated, including:

[0024] A status query command is sent to all online execution terminals in the execution terminal group to obtain the parallel task execution list returned by each execution terminal; wherein, the parallel task execution list contains the execution time period and resource consumption information of each parallel task;

[0025] For each execution terminal, extract the parallel tasks from the parallel task execution list that have time overlap with the task execution window of the current period execution task, and form an overlapping task set;

[0026] For each task in the overlapping task set, based on historical resource usage trends, the resource usage sequence within the task execution window is predicted by fitting the resource usage curves of the three most recent similar tasks.

[0027] Obtain the hardware configuration parameters of each execution terminal, and for each resource type, calculate the available resource parameters at each moment within the task execution window; wherein, the available resource parameters are the maximum available value of the corresponding resource type minus the total predicted occupancy value of the overlapping task set for that resource at that moment;

[0028] Arrange all available resource parameters for each resource type in the task execution window in chronological order to form a sequence of available hardware resource parameters for the execution terminal.

[0029] Optionally, query the first historical task execution information of the target service terminal and the second historical task execution information of non-target service terminals in the service terminal group, including:

[0030] Access the historical task database; wherein, the historical task database stores the execution records of periodic tasks executed by all service terminals in the storage terminal group over a number of past periods, and each execution record includes the algorithm execution time and algorithm analysis confidence level;

[0031] The system queries all task execution records of the target service terminal over the past several periods to form the first historical task execution information. It also queries all task execution records of all non-target service terminals in the service terminal group over the past several periods, grouped by service terminal, to form the second historical task execution information.

[0032] Optionally, the first filtering action includes:

[0033] The algorithm repository of the service-oriented toolchain queries all algorithm models and their corresponding confidence versions that match the task category identifier of the task to be executed in the current cycle; each confidence version is associated with a unique sequence of resource requirements.

[0034] For each confidence version of each algorithm model, extract its resource requirement sequence;

[0035] For each execution terminal, the sequence of available hardware resource parameters is invoked to calculate the resource matching degree; wherein, the resource matching degree is obtained by multiplying the reciprocal of the task execution window duration by the sum of the matching degree between the resource demand and the available resource parameters at each moment within the window, and the matching degree at each moment is the smaller value of the resource demand and the available resource parameters at that moment divided by the larger value.

[0036] Based on a preset matching threshold, algorithm model confidence versions with resource matching scores greater than or equal to the threshold are selected and combined with execution terminals to form the first set of filtering results.

[0037] Optionally, the second filtering action includes:

[0038] Based on a preset confidence threshold, the algorithm analysis confidence of all periodically executed tasks of the target service terminal in the first historical task execution information is queried. The average confidence value is determined by the algorithm analysis confidence of all periodically executed tasks and the confidence value corresponding to each combination in the first screening result set. Combinations with an average confidence value greater than or equal to the confidence threshold are selected to form an intermediate screening set.

[0039] Based on a preset confidence reference value, the periodic execution tasks of each non-target service terminal in the second historical task execution information are queried. The historical average confidence value of each non-target service terminal is calculated. The number of positive terminals with a difference greater than zero between the historical average confidence value and the confidence reference value and the number of negative terminals with a difference less than zero are counted. The ratio of the number of positive terminals to the number of negative terminals plus 1 is calculated. The current total hardware resource utilization rate of all execution terminals is collected and sorted in ascending order to form an execution terminal sorting table. The selection position is determined according to the ratio and a preset rule. Execution terminals are selected from the execution terminal sorting table according to the selection position to form a candidate set of execution terminals.

[0040] The preset rule is as follows: when the ratio of the number of positive terminals to the number of negative terminals is greater than 2, the last 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is less than 1, the first 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is greater than or equal to 1 and less than or equal to 2, the middle 40% of the execution terminals in the execution terminal sorting table are selected.

[0041] The combinations whose execution terminals are not in the candidate set are removed from the intermediate selection set, and any combination is selected as the optimal combination of the current algorithm model and execution terminal for the periodic execution task.

[0042] Optionally, based on the optimal combination scheme, algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal are generated to complete task distribution and execution, including:

[0043] Extract the target execution terminal and algorithm model confidence version from the optimal combination scheme, and generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal;

[0044] Based on the algorithm model scheduling instruction, the algorithm model confidence version corresponding to the algorithm repository is sent to the corresponding target execution terminal. Based on the task data scheduling instruction, the task data corresponding to the algorithm call request is sent to the target execution terminal, so that the target execution terminal can perform task data processing according to the algorithm model confidence version execution cycle.

[0045] A second aspect of the present invention provides an algorithm repository management system based on a service-oriented toolchain, the system comprising:

[0046] The extraction module is used to extract the task category identifier of the periodically executed task when it receives an algorithm call request for the periodically executed task uploaded by the target service terminal in the service terminal group.

[0047] The generation module is used to match the task execution resource requirements of periodically executed tasks using the task category identifier, and generate a sequence of available hardware resource parameters for each execution terminal within the task execution window;

[0048] The query module is used to query the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminal in the service terminal group; wherein, the first historical task execution information and the second historical task execution information include the algorithm analysis results of the corresponding service terminal executing tasks in several historical periods, and the algorithm analysis results include the algorithm execution time and the algorithm analysis confidence level;

[0049] The filtering module is used to perform a first filtering action related to hardware resource matching and a second filtering action related to the overall task execution stability determined by the algorithm analysis results of the target service terminal and non-target service terminals in several historical sets of periodic task execution, based on the sequence of available hardware resource parameters of each execution terminal within the task execution window of the service toolchain, in the algorithm repository and execution terminal group, respectively, to generate the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task.

[0050] The execution module is used to generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal according to the optimal combination scheme, and to complete task distribution and execution.

[0051] Through the above technical solution, this invention matches resource requirements by task category identification and combines dynamic resource occupancy prediction of parallel tasks on the execution terminal to generate a sequence of available hardware resource parameters. The first screening action calculates the matching degree based on the resource fit at each time step, significantly improving the resource adaptation accuracy between the algorithm model and the execution terminal and reducing resource waste. Based on this, the second screening action combines historical execution information of the target service terminal and non-target service terminals, ensuring that the confidence level of individual tasks meets the standard and adjusting the selection of execution terminals through the confidence distribution of the service terminal group, ensuring the overall execution stability of the system. The dynamic adjustment of the execution terminal selection range based on the confidence ratio of the service terminal group achieves intelligent management of system confidence and computing power reserves, avoiding extreme imbalances and ensuring long-term adjustability. Ultimately, this solves the problems of inaccurate resource matching, poor overall execution stability, and lack of dynamic adjustment mechanisms in existing technologies.

[0052] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0053] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0054] Figure 1 This is a flowchart of the steps of an algorithm repository management method based on a service-oriented toolchain provided in one embodiment of the present invention;

[0055] Figure 2 This is a system architecture diagram of an algorithm warehouse management system based on a service-oriented toolchain provided in one embodiment of the present invention. Detailed Implementation

[0056] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0057] like Figure 1 As shown, this invention provides an algorithm repository management method based on a service-oriented toolchain, the method comprising:

[0058] Step S1: When receiving an algorithm call request for a periodically executed task uploaded by a target service terminal in the service terminal group, extract the task category identifier of the periodically executed task.

[0059] Specifically, the target service terminal generates an algorithm call request and uploads it to the scheduling terminal based on the business requirements of periodically executing tasks. This algorithm call request contains basic task information, including core parameters such as task ID, task category field, real-time indicators, and data volume. The task category field is used to specify the business type to which the task belongs (such as data detection, signal analysis, etc.).

[0060] After receiving an algorithm call request, the scheduling terminal performs structured parsing on the request data according to preset parsing rules, extracting the task category field as the initial category identifier. The initial category identifier adopts a standardized string format to ensure compatibility with the subsequent standard task category library.

[0061] The scheduling terminal queries the algorithm repository of the service-oriented toolchain, which contains a pre-stored standard task category library. This standard task category library is an offline-built structured database that includes all task category identifiers supported by the system, corresponding 6-digit numeric encoding rules (the first 2 digits are the task category code, and the last 4 digits are the task sub-category code), and adapted algorithm model types. It is also updated regularly according to business expansion.

[0062] The scheduling terminal performs a precise match between the extracted initial category identifier and the records in the standard task category library. If the match is successful, the corresponding 6-digit code is directly used as the task category identifier for the periodically executed task. If the match fails, the scheduling terminal returns a matching failure message to the target service terminal, requesting a re-upload of a compliant task category field. Simultaneously, a fuzzy matching algorithm is activated to determine the closest standard task category identifier based on string similarity (such as edit distance), and a verification label is added and synchronized to the scheduling terminal backend for manual review by administrators to ensure the accuracy of the task category identifier. Step S2: Using the task category identifier, the task execution resource requirements of the periodically executed task are matched to generate a sequence of available hardware resource parameters for each execution terminal within the task execution window.

[0063] Specifically, step S2 includes the following steps:

[0064] Step S21: Using the task category identifier, match the task execution resource requirements of periodically executed tasks; wherein, the task execution resource requirements include task execution window requirements and hardware resource usage parameter requirements.

[0065] Specifically, the scheduling terminal calls the pre-stored task category and resource requirement mapping table in the algorithm repository of the service-oriented toolchain. This mapping table is structured data generated offline based on historical task execution data. Each record is associated with a task category identifier, the corresponding standard task execution window range, CPU utilization range, memory utilization range, GPU memory utilization range, and bandwidth utilization range, ensuring the targeted matching of resource requirements.

[0066] Based on the task category identifier, a mapping table is queried to obtain the corresponding standard task execution window range (e.g., 10-30 seconds). Simultaneously, the real-time performance metrics (i.e., the maximum allowable delay of the task) carried in the algorithm call request are extracted. The intersection of the standard task execution window range and the real-time performance metrics is taken to determine the task execution window requirement. ,in Add 2 seconds to the current timestamp for scheduling preparation time. The window duration ensures that the task execution window meets both the regular execution requirements of the task type and the real-time constraints.

[0067] Based on the hardware resource usage parameter ranges corresponding to the task category identifier matching mapping table, the median value of each hardware resource (CPU, memory, GPU, bandwidth) is taken as the initial resource usage parameter. For example, when the CPU utilization rate range is 30%-50%, the initial value is 40%; when the memory usage range is 2-4GB, the initial value is 3GB. This ultimately forms the hardware resource usage parameter requirements for periodically executed tasks, providing a benchmark for subsequent calculations of available hardware resources.

[0068] Step S22: Query the parallel task execution list of several execution terminals in the execution terminal group. Based on the execution time period and resource usage information of each parallel task in the parallel task execution list, generate a sequence of available hardware resource parameters for each execution terminal within the task execution window. Specifically, the scheduling terminal sends a status query command to all online execution terminals in the execution terminal group. This command uses a standardized communication protocol (such as HTTP / 2) and includes parameters such as query timestamp and data format requirements, requiring the execution terminals to return a response within 1 second.

[0069] After receiving the status query command, each execution terminal collects the current list of parallel tasks being executed and returns it to the scheduling terminal. This list of parallel tasks includes the task ID, execution start timestamp, estimated end timestamp, task category identifier, and real-time resource usage information (instantaneous utilization of CPU, memory, GPU, and bandwidth, sampled at a frequency of 1 time / second) for each parallel task, comprehensively reflecting the current load status of the execution terminal.

[0070] The scheduling terminal analyzes the parallel task execution list of each execution terminal and extracts the task execution window that is related to the task being executed in the current cycle. Parallel tasks with overlapping execution times form an overlapping task set. The criterion for determining time overlap is: the execution start timestamp of the parallel tasks ≤ And the expected end timestamp is ≥ This ensures that no parallel tasks that might affect the execution of the target task are overlooked.

[0071] For each task in the overlapping task set, the scheduling terminal queries the historical task database for the three most recent execution records of the task's category, extracting the corresponding resource usage curves (time-resource utilization relationship). A multinomial fitting algorithm is used to fit the three curves, generating a resource usage prediction model for the task in the current execution scenario. Based on this model, the resource usage within the task execution window is predicted. Resource usage sequence within ( , (Memory, GPU, bandwidth), prediction accuracy error is controlled within ±5%.

[0072] The scheduling terminal obtains the hardware configuration parameters of each execution terminal, including the number of CPU cores, total memory, total GPU memory, and maximum bandwidth, and calculates the maximum available value of each resource. (For example, maximum available CPU value = number of cores × 100%, maximum available memory value = total memory).

[0073] For each resource type In the task execution window Every moment within Calculate the available resource parameters at that moment:

[0074]

[0075] in, For overlapping task sets at time Resources The total predicted occupancy rate. If the calculated result is less than zero, then... Set it to 0 to ensure the reasonableness of available resource parameters.

[0076] All available resource parameters for each resource type within the task execution window are arranged in chronological order to form a sequence of available hardware resource parameters for the execution terminal. This sequence is stored as an array, with the array length being the window duration multiplied by the sampling frequency (sampling frequency is 1 time / second). For example, when the window duration is 20 seconds, the array length is 20. Each element corresponds to an available resource parameter at a given moment, providing accurate data support for subsequent resource matching.

[0077] Step S3: Query the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminals in the service terminal group; wherein, the first historical task execution information and the second historical task execution information include the algorithm analysis results of the corresponding service terminal executing tasks in several historical periods, and the algorithm analysis results include the algorithm execution time and the algorithm analysis confidence level.

[0078] Specifically, the scheduling terminal accesses its associated historical task database. This database uses a distributed storage architecture to store the past tasks of all service terminals in the storage terminal group. One cycle ( The system records periodically executed tasks (default value 5, configurable according to business needs). Each record includes the service terminal ID, task ID, task category identifier, execution timestamp, algorithm model ID, algorithm version (confidence version), algorithm execution time, algorithm analysis confidence level (accurate to 3 decimal places), and execution status (success / failure). The data retention period is [not specified in the original text]. Maintain consistency.

[0079] The dispatch terminal queries the target service terminal's past performance based on the target service terminal ID and the task category identifier determined in step S1. The execution records of all tasks executed within a given period constitute the first historical task execution information. This information is sorted in descending order of execution timestamp for easy retrieval of recent execution data; if the number of records is insufficient... If there are no records, then all valid records (records with a successful execution status) will be retrieved.

[0080] The dispatch terminal queries all non-target service terminals in the service terminal group, excluding the target service terminal, in the past All execution records of tasks within a given period are grouped by service terminal ID, and within each group, they are sorted in descending order of execution timestamp, forming the second historical task execution information. This information reflects the overall execution quality distribution of the service terminal group. The scheduling terminal performs data cleaning on the first and second historical task execution information. Records with failed execution status, abnormal records with an algorithm analysis confidence level of 0, and invalid records whose algorithm execution time exceeds twice the corresponding task execution window are removed, resulting in cleaned and valid historical task execution information to ensure the reliability of subsequent analysis data.

[0081] Step S4: Based on the sequence of available hardware resources for each execution terminal within the task execution window, perform a first screening action related to hardware resource matching and a second screening action related to the overall task execution stability determined by the algorithm analysis results of several historical sets of periodic task executions in the service-oriented toolchain's algorithm repository and execution terminal group, respectively, to generate the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task.

[0082] Specifically, step S4 includes:

[0083] S41: Query the algorithm repository of the service-oriented toolchain for all algorithm models and their corresponding confidence versions that match the task category identifier of the task to be executed in the current cycle; where each confidence version is associated with a unique resource requirement sequence;

[0084] S42: For each confidence version of each algorithm model, extract its resource requirement sequence;

[0085] S43: For each execution terminal, call the sequence of available hardware resources and calculate the resource matching degree; wherein, the resource matching degree is obtained by multiplying the reciprocal of the task execution window duration by the sum of the matching degree between the resource demand and the available resource parameters at each moment within the window, and the matching degree at each moment is the smaller value of the resource demand and the available resource parameters at that moment divided by the larger value.

[0086] S44: Based on a preset matching threshold, select algorithm model confidence versions with resource matching scores greater than or equal to the threshold and combine them with execution terminals to form the first set of filtering results.

[0087] Specifically, the scheduling terminal queries the algorithm repository of the service-oriented toolchain for all algorithm models and their corresponding confidence versions that match the task category identifier of the task to be executed in the current cycle. Each algorithm model in the algorithm repository is divided into multiple versions according to confidence (such as high-confidence version, balanced version, and lightweight version). Different versions are associated with a unique resource requirement sequence (the requirement rate sequence of CPU, memory, GPU, and bandwidth within the task execution window, which is consistent with the time dimension of the available hardware resource parameter sequence, with a sampling frequency of 1 time / second), and the higher the confidence of the version, the higher the value of the resource requirement sequence.

[0088] For each confidence version of each algorithm model, the scheduling terminal extracts its resource requirement sequence. ( This sequence reflects the real-time hardware resource requirements of the algorithm version during execution.

[0089] For each execution terminal, the scheduling terminal invokes the sequence of available hardware resource parameters generated in step 2. ( ), calculate the resource matching degree. The calculation rule for the resource matching degree is:

[0090]

[0091] in, for from arrive The summation operation, this formula quantifies the degree of fit between resource demand and available resources by weighting the average of their time-by-time matching. The range of values ​​is The closer the value is to 1, the higher the compatibility.

[0092] The scheduling terminal has a pre-set allocation threshold (default is 0.7, which can be dynamically adjusted according to the system resource shortage) to filter out... The algorithm model confidence level, version, and execution terminal are combined to form the first screening result set. This result set includes the combination ID, algorithm model ID, version confidence level, execution terminal ID, and matching score, providing a basic combination pool for subsequent stability screening.

[0093] S45: Based on a preset confidence threshold, query the algorithm analysis confidence of all periodically executed tasks of the target service terminal in the first historical task execution information, calculate the average confidence of the algorithm analysis confidence of all periodically executed tasks and the confidence of each combination in the first screening result set, and screen out the combinations whose average confidence is greater than or equal to the confidence threshold to form an intermediate screening set;

[0094] S46: Based on the preset confidence reference value, query the periodic execution tasks of each non-target service terminal in the second historical task execution information, calculate the historical average confidence value of each non-target service terminal, count the number of positive terminals with a difference greater than zero between the historical average confidence value and the confidence reference value and the number of negative terminals with a difference less than zero, calculate the ratio of the number of positive terminals to the number of negative terminals plus 1, collect the current total hardware resource utilization rate of all execution terminals, sort them in ascending order to form an execution terminal sorting table, determine the selection position according to the ratio and preset rules, select execution terminals from the execution terminal sorting table according to the selection position, and form an execution terminal candidate set;

[0095] The preset rule is as follows: when the ratio of the number of positive terminals to the number of negative terminals is greater than 2, the last 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is less than 1, the first 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is greater than or equal to 1 and less than or equal to 2, the middle 40% of the execution terminals in the execution terminal sorting table are selected.

[0096] S47: Eliminate combinations whose execution terminals are not in the candidate set from the intermediate selection set, and select any combination as the optimal combination of the current algorithm model and execution terminal for the periodic execution task.

[0097] Specifically, the second screening process is carried out in three steps, with the core objective of selecting the combination scheme that is most conducive to the overall stability of task execution:

[0098] The first step is to generate the intermediate filter set:

[0099] Preset confidence threshold in dispatch terminal (Default is 0.9, can be adjusted according to business requirements for execution quality). Query the algorithm analysis confidence score of all valid records in the first historical task execution information, and calculate the historical average confidence score:

[0100] ;

[0101] in, The number of valid records in the first historical task execution information. For the first Algorithm analysis confidence of records.

[0102] For each algorithm model confidence version-execution terminal combination in the first screening result set, calculate the combined confidence mean:

[0103]

[0104] in, This represents the confidence level of the algorithm model version within the combination. Filtering... The combination of these elements forms an intermediate filter set, ensuring that the confidence level of the task execution results of the target service terminal meets the standard.

[0105] The second step is to determine the candidate set of execution terminals:

[0106] Preset confidence reference value for dispatch terminal (The default value is 0.85, used to measure the historical execution quality of the service terminal). Query the valid records of each non-target service terminal in the second historical task execution information, and calculate the historical average confidence score for each non-target service terminal:

[0107]

[0108] in, This represents the number of valid records for this service terminal. For this service terminal Algorithm analysis confidence of records.

[0109] Statistics of non-target service terminals that meet the requirements Number of positive terminals and satisfy Number of negative terminals Calculate the ratio:

[0110]

[0111] Adding 1 to the denominator to avoid The divisor may be zero at times. This ratio... Reflects the overall confidence distribution of the service terminal group. The larger the value, the better the overall execution quality.

[0112] Collect the current total hardware resource utilization rate of all execution terminals (the average of the sum of the real-time resource utilization rates of all parallel tasks), and sort them in ascending order to form an execution terminal ranking table. In the ranking table, terminals in the preceding order indicate low hardware resource utilization rate and sufficient remaining available resources, and strong adaptability to high-confidence algorithm versions; terminals in the following order indicate high hardware resource utilization rate and low remaining available resources, and weak adaptability to high-confidence algorithm versions.

[0113] According to the ratio The range of execution terminals is determined according to preset rules:

[0114] when At this time, the overall confidence level of the service terminal group is high. The bottom 30% of the execution terminals in the execution terminal ranking list are selected to form the execution terminal candidate set. At this time, selecting terminals with high resource utilization can activate idle computing power and increase the system's computing power reserve. At the same time, because the overall confidence level of the system is redundant, it will not affect the task execution quality, thus realizing the adjustment of high confidence level → increased computing power reserve.

[0115] when When the overall confidence level of the service terminal group is low, the top 30% of the execution terminals in the execution terminal ranking list are selected to form a candidate set of execution terminals. At this time, high-quality terminals with sufficient resources are selected to prioritize task execution confidence, quickly improve the overall system confidence level, and achieve the adjustment from low confidence to increased confidence.

[0116] when At this time, the overall confidence level of the service terminal group is in a balanced state. The middle 40% of the execution terminals (31%-70%) of the execution terminal ranking table are selected to form the execution terminal candidate set, maintaining a dynamic balance between confidence level and computing power reserve, and avoiding the system from shifting to extreme directions.

[0117] The third step is to generate the optimal combination scheme:

[0118] The scheduling terminal removes combinations from the intermediate filtering set whose execution terminals are not in the candidate execution terminal set, resulting in a second filtering result set. This result set retains the combination ID, algorithm model ID, version confidence score, execution terminal ID, matching score, and... value.

[0119] The optimal combination scheme is selected from the second set of results. The selection rule can be: prioritizing schemes ordered by matching score in descending order. The value is sorted in descending order as the second priority; if there are ties, the combination with the highest historical task success rate (number of successful executions / total number of assignments) of the execution terminal is selected, and the optimal algorithm model ID, the optimal confidence version and the target execution terminal ID are finally determined to form the optimal combination scheme for the task to be executed in the current period.

[0120] Step S5: Based on the optimal combination scheme, generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal, and complete task distribution and execution.

[0121] Specifically, based on the optimal combination scheme, the scheduling terminal extracts core parameters such as the target execution terminal ID, the optimal algorithm model ID, and the optimal confidence version, and generates two types of scheduling instructions:

[0122] Firstly, the algorithm model scheduling instructions: These use a JSON structure and include the instruction type (algorithm scheduling), target execution terminal ID, optimal algorithm model ID, optimal confidence version, algorithm storage path (a unique access address within the algorithm repository), transmission priority (set to high / medium / low based on task real-time metrics), checksum (generated based on the hash value of the algorithm model file, used for integrity verification), and instruction validity period. (The first 30 seconds) ensure the accuracy and timeliness of the algorithm model transmission.

[0123] Secondly, the task data scheduling instructions adopt a JSON structure, including the instruction type (data scheduling), target execution terminal ID, target service terminal ID, task ID, task data storage path (task data access address of the target service terminal), and task execution window. Hardware resource usage parameters and result feedback address (the address where the scheduling terminal receives the execution results) are specified to ensure the matching between task data and algorithm model.

[0124] The scheduling terminal sends corresponding scheduling instructions to the algorithm repository and the target service terminal through the communication module of the service-oriented toolchain. Simultaneously, an instruction transmission confirmation mechanism is activated, with a preset timeout of 5 seconds. If no confirmation response is received from the receiver within the timeout period, the instruction is resent, with a maximum of 3 retries to ensure reliable instruction transmission.

[0125] After receiving the algorithm model scheduling instruction, the algorithm repository first verifies the validity of the checksum and the instruction's expiration date. If the verification passes, it transmits the optimal algorithm model and its corresponding version (including model weights, inference configuration, etc.) to the target execution terminal via a high-speed transmission channel (such as FTP protocol). Upon completion of the transmission, the algorithm repository sends an algorithm-ready notification to the scheduling terminal, informing it that the algorithm model has been successfully deployed to the target execution terminal.

[0126] After receiving the task data scheduling instruction, the target service terminal packages the task data according to the format specified in the instruction, ensuring that the data format is consistent with the input requirements of the optimal algorithm model. After packaging, the task data is transmitted to the target execution terminal through a secure transmission channel, and a data ready notification is sent to the scheduling terminal after the transmission is complete.

[0127] After receiving both the algorithm-ready and data-ready notifications, the target execution terminal will display the notifications in the task execution window. The optimal algorithm model is launched internally, task data is loaded, and computation is performed. During execution, the target execution terminal reports its resource usage status (real-time utilization of CPU, memory, GPU, and bandwidth) and execution progress (completed data volume / total data volume) to the scheduling terminal at a preset frequency (once every 5 seconds). After execution, the algorithm analysis results (including algorithm execution time, algorithm analysis confidence level, and task processing results) are fed back to the scheduling terminal, which then synchronizes the results to the historical task database, completing the distribution and execution of the task for this cycle.

[0128] like Figure 2 As shown, this invention provides an algorithm repository management system based on a service-oriented toolchain, the system comprising:

[0129] The extraction module is used to extract the task category identifier of the periodically executed task when it receives an algorithm call request for the periodically executed task uploaded by the target service terminal in the service terminal group.

[0130] The generation module is used to match the task execution resource requirements of periodically executed tasks using the task category identifier, and generate a sequence of available hardware resource parameters for each execution terminal within the task execution window;

[0131] The query module is used to query the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminal in the service terminal group; wherein, the first historical task execution information and the second historical task execution information include the algorithm analysis results of the corresponding service terminal executing tasks in several historical periods, and the algorithm analysis results include the algorithm execution time and the algorithm analysis confidence level;

[0132] The filtering module is used to perform a first filtering action related to hardware resource matching and a second filtering action related to the overall task execution stability determined by the algorithm analysis results of the target service terminal and non-target service terminals in several historical sets of periodic task execution, based on the sequence of available hardware resource parameters of each execution terminal within the task execution window of the service toolchain, in the algorithm repository and execution terminal group, respectively, to generate the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task.

[0133] The execution module is used to generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal according to the optimal combination scheme, and to complete task distribution and execution.

[0134] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0135] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details described above. Within the scope of the technical concept of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all fall within the protection scope of the embodiments of the present invention. It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the embodiments of the present invention will not further describe the various possible combinations.

[0136] Furthermore, various different embodiments of the present invention can be combined in any way, as long as they do not violate the spirit of the embodiments of the present invention, they should also be regarded as the content disclosed by the embodiments of the present invention.

Claims

1. A method for managing an algorithm repository based on a service-oriented toolchain, characterized in that, For scheduling terminals, the method includes: When a request for algorithm invocation for a periodically executed task is received from a target service terminal in the service terminal group, the task category identifier of the periodically executed task is extracted. Using the task category identifier, the task execution resource requirements of periodically executed tasks are matched to generate a sequence of available hardware resource parameters for each execution terminal within the task execution window; The query process involves querying the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminals within the service terminal group. The first and second historical task execution information include algorithm analysis results of the corresponding service terminals executing tasks in several historical periods. The algorithm analysis results include algorithm execution time and algorithm analysis confidence level. Based on the sequence of available hardware resources for each execution terminal within the task execution window, the algorithm repository of the service-oriented toolchain and the execution terminal group respectively execute a first screening action related to hardware resource matching and a second screening action related to the overall task execution stability determined by the algorithm analysis results of several historical sets of periodic execution tasks between the target service terminal and non-target service terminals, thereby generating the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task. The first screening step includes: The algorithm repository of the service-oriented toolchain queries all algorithm models and their corresponding confidence versions that match the task category identifier of the task to be executed in the current cycle; each confidence version is associated with a unique sequence of resource requirements. For each confidence version of each algorithm model, extract its resource requirement sequence; For each execution terminal, the sequence of available hardware resource parameters is invoked to calculate the resource matching degree; wherein, the resource matching degree is obtained by multiplying the reciprocal of the task execution window duration by the sum of the fit between the resource demand and the available resource parameters at each moment within the window, and the fit at each moment is the smaller value of the resource demand and the available resource parameters at that moment divided by the larger value. Based on a preset matching threshold, algorithm model confidence versions with resource matching scores greater than or equal to the threshold are selected and combined with execution terminals to form the first set of filtering results. The second screening step includes: Based on a preset confidence threshold, the algorithm analysis confidence of all periodically executed tasks of the target service terminal in the first historical task execution information is queried. The average confidence value is determined by the algorithm analysis confidence of all periodically executed tasks and the confidence value corresponding to each combination in the first screening result set. Combinations with an average confidence value greater than or equal to the confidence threshold are selected to form an intermediate screening set. Based on a preset confidence reference value, the periodic execution tasks of each non-target service terminal in the second historical task execution information are queried. The historical average confidence value of each non-target service terminal is calculated. The number of positive terminals with a difference greater than zero between the historical average confidence value and the confidence reference value and the number of negative terminals with a difference less than zero are counted. The ratio of the number of positive terminals to the number of negative terminals plus 1 is calculated. The current total hardware resource utilization rate of all execution terminals is collected and sorted in ascending order to form an execution terminal sorting table. The selection position is determined according to the ratio and a preset rule. Execution terminals are selected from the execution terminal sorting table according to the selection position to form a candidate set of execution terminals. The preset rule is as follows: when the ratio of the number of positive terminals to the number of negative terminals is greater than 2, the last 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is less than 1, the first 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is greater than or equal to 1 and less than or equal to 2, the middle 40% of the execution terminals in the execution terminal sorting table are selected. The combinations whose execution terminals are not in the candidate set are removed from the intermediate screening set, and any combination is selected as the optimal combination of the current algorithm model and execution terminal for the periodic execution task; Based on the optimal combination scheme, algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal are generated to complete task distribution and execution.

2. The algorithm repository management method based on service-oriented toolchain according to claim 1, characterized in that, Upon receiving a request from a target service terminal in the service terminal group to invoke the algorithm for a periodically executed task, the task category identifier of the periodically executed task is extracted, including: Receive the algorithm call request for the periodically executed task uploaded by the target service terminal in the service terminal group, parse and extract the task category field as the initial category identifier; The standard task category library is pre-stored in the algorithm repository of the query service toolchain; wherein, the standard task category library contains all supported task category identifiers and corresponding encoding rules; The extracted initial category identifier is matched with the standard task category library. If a match is found, the corresponding standard code is used as the task category identifier for the periodically executed task.

3. The algorithm repository management method based on service-oriented toolchain according to claim 1, characterized in that, Using the task category identifier, the task execution resource requirements of periodically executed tasks are matched to generate a sequence of available hardware resource parameters for each execution terminal within the task execution window, including: Using the task category identifier, the task execution resource requirements of periodically executed tasks are matched; wherein, the task execution resource requirements include task execution window requirements and hardware resource usage parameter requirements; Query the parallel task execution list of several execution terminals in the execution terminal group, and generate a sequence of available hardware resource parameters for each execution terminal within the task execution window based on the execution time period and resource usage information of each parallel task in the parallel task execution list.

4. The algorithm repository management method based on service-oriented toolchain according to claim 3, characterized in that, Using the task category identifier, the task execution resource requirements for periodically executed tasks are matched, including: The algorithm repository of the service-oriented toolchain is used to call the pre-stored task category and resource requirement mapping table; each record is associated with a task category identifier, the corresponding standard task execution window range, and the hardware resource usage parameter range; Based on the task category identifier, query the standard task execution window range in the task category and resource requirement mapping table. Combine the real-time indicators corresponding to the task category identifier, and take the intersection of the standard task execution window range and the real-time indicators to determine the task execution window requirement. Based on the task category identifier, match the task category with the corresponding hardware resource usage parameter range in the resource requirement mapping table, and take the midpoint of the range for each type of hardware resource to determine the hardware resource usage parameter requirement.

5. The algorithm repository management method based on service-oriented toolchain according to claim 3, characterized in that, Query the parallel task execution list of several execution terminals in the execution terminal group. Based on the execution time period and resource usage information of each parallel task in the parallel task execution list, generate a sequence of available hardware resource parameters for each execution terminal within the task execution window, including: A status query command is sent to all online execution terminals in the execution terminal group to obtain the parallel task execution list returned by each execution terminal; wherein, the parallel task execution list contains the execution time period and resource consumption information of each parallel task; For each execution terminal, extract the parallel tasks from the parallel task execution list that have time overlap with the task execution window of the current period execution task, and form an overlapping task set; For each task in the overlapping task set, based on historical resource usage trends, the resource usage sequence within the task execution window is predicted by fitting the resource usage curves of the three most recent similar tasks. Obtain the hardware configuration parameters of each execution terminal, and for each resource type, calculate the available resource parameters at each moment within the task execution window; wherein, the available resource parameters are the maximum available value of the corresponding resource type minus the total predicted occupancy value of the overlapping task set for that resource at that moment; Arrange all available resource parameters for each resource type in the task execution window in chronological order to form a sequence of available hardware resource parameters for the execution terminal.

6. The algorithm repository management method based on service-oriented toolchain according to claim 1, characterized in that, Query the first historical task execution information of the target service terminal and the second historical task execution information of non-target service terminals in the service terminal group, including: Access the historical task database; wherein, the historical task database stores the execution records of periodic tasks executed by all service terminals in the storage terminal group over a number of past periods, and each execution record includes the algorithm execution time and algorithm analysis confidence level; The system queries all task execution records of the target service terminal over the past several periods to form the first historical task execution information. It also queries all task execution records of all non-target service terminals in the service terminal group over the past several periods, grouped by service terminal, to form the second historical task execution information.

7. The algorithm repository management method based on service-oriented toolchain according to claim 1, characterized in that, Based on the optimal combination scheme, algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal are generated to complete task distribution and execution, including: Extract the target execution terminal and algorithm model confidence version from the optimal combination scheme, and generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal; Based on the algorithm model scheduling instruction, the algorithm model confidence version corresponding to the algorithm repository is sent to the corresponding target execution terminal. Based on the task data scheduling instruction, the task data corresponding to the algorithm call request is sent to the target execution terminal, so that the target execution terminal can perform task data processing according to the algorithm model confidence version execution cycle.

8. An algorithm repository management system based on a service-oriented toolchain, characterized in that, The system includes: The extraction module is used to extract the task category identifier of the periodically executed task when it receives an algorithm call request for the periodically executed task uploaded by the target service terminal in the service terminal group. The generation module is used to match the task execution resource requirements of periodically executed tasks using the task category identifier, and generate a sequence of available hardware resource parameters for each execution terminal within the task execution window; The query module is used to query the first historical task execution information of the target service terminal and the second historical task execution information of the non-target service terminal in the service terminal group; wherein, the first historical task execution information and the second historical task execution information include the algorithm analysis results of the corresponding service terminal executing tasks in several historical periods, and the algorithm analysis results include the algorithm execution time and the algorithm analysis confidence level; The filtering module is used to perform a first filtering action related to hardware resource matching and a second filtering action related to the overall task execution stability determined by the algorithm analysis results of the target service terminal and non-target service terminals in several historical sets of periodic task execution, based on the sequence of available hardware resource parameters of each execution terminal within the task execution window of the service toolchain, in the algorithm repository and execution terminal group, respectively, to generate the optimal combination scheme of the current algorithm model and execution terminal for the periodic execution task. The first screening step includes: The algorithm repository of the service-oriented toolchain queries all algorithm models and their corresponding confidence versions that match the task category identifier of the task to be executed in the current cycle; each confidence version is associated with a unique sequence of resource requirements. For each confidence version of each algorithm model, extract its resource requirement sequence; For each execution terminal, the sequence of available hardware resource parameters is invoked to calculate the resource matching degree; wherein, the resource matching degree is obtained by multiplying the reciprocal of the task execution window duration by the sum of the fit between the resource demand and the available resource parameters at each moment within the window, and the fit at each moment is the smaller value of the resource demand and the available resource parameters at that moment divided by the larger value. Based on a preset matching threshold, algorithm model confidence versions with resource matching scores greater than or equal to the threshold are selected and combined with execution terminals to form the first set of filtering results. The second screening step includes: Based on a preset confidence threshold, the algorithm analysis confidence of all periodically executed tasks of the target service terminal in the first historical task execution information is queried. The average confidence value is determined by the algorithm analysis confidence of all periodically executed tasks and the confidence value corresponding to each combination in the first screening result set. Combinations with an average confidence value greater than or equal to the confidence threshold are selected to form an intermediate screening set. Based on a preset confidence reference value, the periodic execution tasks of each non-target service terminal in the second historical task execution information are queried. The historical average confidence value of each non-target service terminal is calculated. The number of positive terminals with a difference greater than zero between the historical average confidence value and the confidence reference value and the number of negative terminals with a difference less than zero are counted. The ratio of the number of positive terminals to the number of negative terminals plus 1 is calculated. The current total hardware resource utilization rate of all execution terminals is collected and sorted in ascending order to form an execution terminal sorting table. The selection position is determined according to the ratio and a preset rule. Execution terminals are selected from the execution terminal sorting table according to the selection position to form a candidate set of execution terminals. The preset rule is as follows: when the ratio of the number of positive terminals to the number of negative terminals is greater than 2, the last 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is less than 1, the first 30% of the execution terminals in the execution terminal sorting table are selected; when the ratio of the number of positive terminals to the number of negative terminals is greater than or equal to 1 and less than or equal to 2, the middle 40% of the execution terminals in the execution terminal sorting table are selected. The combinations whose execution terminals are not in the candidate set are removed from the intermediate screening set, and any combination is selected as the optimal combination of the current algorithm model and execution terminal for the periodic execution task; The execution module is used to generate algorithm model scheduling instructions from the algorithm repository to the target execution terminal and task data scheduling instructions from the service terminal to the execution terminal according to the optimal combination scheme, and to complete task distribution and execution.

Images