Random model generation method, random model generator, and hardware platform

Abstract

Embodiments of the present application provide a random model generation method, a random model generator and a hardware platform. The method comprises: randomly selecting model parameters from configuration parameters based on a probability distribution corresponding to a randomization engine to generate a candidate random model; performing multi-layer verification on operator matching of the candidate random model and resource demand amount deployed on the hardware platform; filtering out the candidate random model that does not pass the multi-layer verification to obtain an effective random model, the effective random model being used for deployment on the hardware platform. The method is used to improve the adaptability of the random model put into the hardware platform, so that the simulation time and the computing resources in the test process are concentrated on the executable model.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence chip verification, and in particular to a random model generation method, a random model generator, and a hardware platform. Background Technology

[0002] In the design and verification process of artificial intelligence chips, verification engineers need to build a large number of test cases for hardware platforms, such as neural network accelerators and graphics processing units (GPUs), to ensure the correctness of chip functions, performance stability and boundary condition coverage in different scenarios.

[0003] In existing technologies, test cases are typically constructed manually using neural network models. This involves manually designing the network structure, configuring operator parameters, and generating model files in target formats (such as ONNX and Caffe). However, with the increasing complexity of chips and the diversification of verification requirements, the efficiency of manually constructing test cases is no longer sufficient.

[0004] Therefore, there is an urgent need for a solution that automates the generation of test models, automatically verifying their compatibility with the hardware platform during model generation, thereby reducing the proportion of invalid models and improving verification efficiency. Summary of the Invention

[0005] This application provides a random model generation method, a random model generator, and a hardware platform to improve verification efficiency and completeness.

[0006] In a first aspect, embodiments of this application provide a method for generating a random model, including:

[0007] Based on the probability distribution corresponding to the randomization engine, model parameters are randomly selected from the configuration parameters to generate candidate random models;

[0008] The operator matching of the candidate random model and the resource requirements deployed on the hardware platform are verified in multiple layers.

[0009] Candidate random models that fail the multi-layer verification are filtered out to obtain valid random models, which are then deployed on the hardware platform.

[0010] In one possible implementation, the operator matching of the candidate random model and the resource requirements deployed on the hardware platform are verified in multiple layers, including:

[0011] Along the forward propagation path, deduce the tensor type of each node in the candidate random model;

[0012] The candidate random model is verified by comparing the consistency between the tensor type and the operator signature of the node;

[0013] After the type derivation verification is passed, the resource requirement of the candidate random model is calculated and compared with the resource threshold of the hardware platform.

[0014] When the resource demand is less than or equal to the resource threshold, the resource budget verification is deemed successful.

[0015] In one possible implementation, the method further includes:

[0016] When the resource demand exceeds the resource threshold, an excess ratio is determined based on the difference between the resource demand and the resource threshold.

[0017] When the excess ratio is less than the tolerance threshold, the candidate random model is pruned and the type derivation and verification are performed again.

[0018] When the excess ratio is greater than or equal to the tolerance threshold, the candidate random model is determined to be invalid, and the reason for invalidity is recorded.

[0019] In one possible implementation, the configuration parameters include: a preset depth range, a preset width range, and parameter spaces corresponding to each operator type. The step of randomly selecting model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine to generate candidate random models includes:

[0020] Based on the probability distribution corresponding to the randomization engine, random sampling is performed in the preset depth interval and the preset width interval respectively to construct a directed acyclic graph;

[0021] According to the position of each node in the directed acyclic graph, the operator type of each node is randomly determined. The operator type includes: standard operators and / or combined operators. The combined operator is obtained by combining at least two standard operators.

[0022] Within the parameter space corresponding to the operator type of each node, parameter constraints are randomly added to each node to generate the candidate random model.

[0023] In one possible implementation, based on the probability distribution corresponding to the randomization engine, random sampling is performed within the preset depth interval and the preset width interval respectively to construct a directed acyclic graph, including:

[0024] Based on the probability distribution corresponding to the randomization engine, random sampling is performed in the preset depth range and the preset width range respectively to obtain the model depth of the candidate random model to be generated and the node width of each layer node.

[0025] Based on the model depth and the node width of each layer, an initial directed graph is constructed;

[0026] Calculate the exponential decay probability based on the inter-layer distance, add jump connections to the initial directed graph based on the exponential decay probability, and perform topological sorting verification.

[0027] When the topological sorting verification indicates that there are no cycles in the initial directed graph after adding jump links, the initial directed graph after adding jump links is taken as the directed acyclic graph.

[0028] In one possible implementation, the generation space comprised of configuration parameters includes multiple candidate regions, and the method further includes:

[0029] The coverage of the effective random model is collected, and the coverage is used to characterize the ratio of the execution resources actually used to the allowed execution resources when the hardware platform executes the effective random model;

[0030] Based on the coverage rate, the weights corresponding to each candidate region are updated using an exponential gradient update strategy.

[0031] The updated weights of each candidate region are normalized to obtain a new probability distribution for the randomization engine.

[0032] In one possible implementation, before generating candidate random models by randomly selecting model parameters from configuration parameters based on the probability distribution corresponding to the randomization engine, the method further includes:

[0033] In response to the verification task, the type of candidate random model to be generated is determined based on the verification requirement characteristics of the verification task;

[0034] The types include:

[0035] The first type of model is encapsulated using a standard format, and / or the second type of model is built based on a custom intermediate representation layer.

[0036] In one possible implementation, the verification requirement features include: a compatibility score and a customization score. The determination of the type of candidate random model to be generated based on the verification requirement features of the verification task includes:

[0037] If the compatibility score is greater than a first preset value and the customization score is less than a second preset value, then the candidate random model to be generated is determined to be a first type of model.

[0038] If the compatibility score is greater than the first preset value and the customization score is greater than or equal to the second preset value, then the candidate random model to be generated is determined to be a first type model and a second type model.

[0039] When the compatibility score is less than or equal to the first preset value, the candidate random model to be generated is determined to be the second type of model.

[0040] Secondly, embodiments of this application also provide a random model generator, comprising:

[0041] The generation module is used to randomly select model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine, and generate candidate random models.

[0042] The verification module is used to perform multi-level verification of the operator matching of the candidate random model and the resource requirements deployed on the hardware platform.

[0043] The verification module is also used to filter out candidate random models that fail the multi-layer verification to obtain a valid random model, which is used to deploy on the hardware platform.

[0044] Thirdly, embodiments of this application provide a hardware platform, including: a memory and a processor;

[0045] The memory stores the target model, which is generated as described in the first aspect and / or various possible implementations of the first aspect;

[0046] The processor is used to perform inference on the input data based on the target model and output the inference results.

[0047] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0048] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0049] The random model generation method, random model generator, and hardware platform provided in this application introduce probability sampling constrained by configuration parameters during the model generation stage, and sequentially perform operator matching verification and resource requirement verification after the candidate random models are formed, so that random generation and deployment constraints are connected in the same process. Therefore, the output from the generator is not an unfiltered set of random networks, but a set of valid random models that already meet the structural consistency and hardware carrying capacity conditions. This solves the problems of low efficiency in manual construction and a high proportion of invalid models caused by unconstrained random generation. Furthermore, joint filtering of structural legality and resource deployability is performed before the random models enter the hardware platform, making the random models deployed to neural network accelerators, graphics processors, or other hardware platforms more closely fit the target platform constraints. This allows simulation time and computing resources in the testing process to be concentrated on executable models, and the verification results to provide more targeted coverage of the hardware platform logic. Attached Figure Description

[0050] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0051] Figure 1 A schematic diagram illustrating a scenario for verifying an artificial intelligence chip, provided as an embodiment of this application;

[0052] Figure 2 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 1 ;

[0053] Figure 3 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 2 ;

[0054] Figure 4 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 3 ;

[0055] Figure 5 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 4 ;

[0056] Figure 6 This is a schematic diagram of the structure of a random model generator provided in an embodiment of this application;

[0057] Figure 7 This is a schematic diagram of a hardware platform provided in an embodiment of this application.

[0058] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0059] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0060] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0061] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0062] Artificial intelligence chip verification is commonly used in the design verification phase of hardware platforms such as neural network accelerators and graphics processing units. Verification systems typically include a test model generation unit, a model checking unit, and a hardware platform or simulation platform, used to continuously feed neural network models to the hardware platform and observe the execution results.

[0063] Figure 1 This is a schematic diagram of a scenario for verifying an artificial intelligence chip, provided in an embodiment of this application. Figure 1As shown, in existing technologies, random models are typically constructed manually or generated randomly, and then the generated results are converted into deployable models for verification and operation. The manual method relies on experience to set the network structure, operator type, and parameter combination item by item, while the random method mainly completes the model splicing based on preset rules or probabilities.

[0064] Based on the above scenarios, it is evident that manually constructing models is time-consuming, involves a lot of repetitive work, and has limited model diversity, making it difficult to cover boundary branches in complex hardware logic. While random generation improves output speed, the generated results often lack constraint verification of operator matching relationships and hardware resource constraints, easily leading to inconsistencies in dimensions, invalid operator connections, and resource requirements exceeding the target platform's capacity. Furthermore, invalid models entering the verification process consume simulation time and computational resources, reducing effective test density and making the verification results insufficiently targeted to the hardware platform.

[0065] To address the aforementioned technical challenges, a randomization engine is used as the entry point for model generation. During model formation, model parameters are selected from configuration parameters according to a probability distribution, and candidate random models are generated in a progressive, layer-by-layer manner, shifting model construction from manual to automated generation. After candidate models are generated, their operator compatibility and resource requirements on the hardware platform are verified through multiple layers. Candidate random models that fail verification are directly filtered out, and only deployable, valid random models are retained for subsequent verification processes. This improves the efficiency of test model generation, reduces the proportion of invalid test cases, and enhances the adaptability of the generated results to the verification requirements of the hardware platform.

[0066] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0067] Figure 2 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method includes:

[0068] S201: Based on the probability distribution corresponding to the randomization engine, model parameters are randomly selected from the configuration parameters to generate candidate random models.

[0069] In this embodiment, the execution entity can be a processor at the model generation end, such as a random model generator. The model generation end can be a generation service deployed on a server or a model construction module integrated into the front end of the verification platform. The randomization engine is used to randomly select model parameters from the configuration parameters according to the corresponding probability distribution and drive the generation of candidate random models.

[0070] The probability distribution is used to indicate the probability of each configuration parameter being selected. It can be determined by weighted random sampling, and the weights can be dynamically adjusted based on the performance and coverage of the random model deployed on the hardware platform. Alternatively, it can be a fixed weight that is input along with the configuration parameters and is related to the hardware platform or the verification task.

[0071] Configuration parameters, serving as a set of input constraints for generating randomized models, include at least the parameter ranges related to candidate randomized model generation, parameter value constraints, and constraints adapted to the hardware platform. For example, configuration parameters may include network depth ranges (e.g., 6-30 layers), operator pools (e.g., Conv2D, Add, GELU), and hardware resource limitations (e.g., computing power limits, storage bandwidth). For example, configuration parameters may be stored in a structured text format and parsed before being written to memory when a randomized model needs to be generated.

[0072] Model parameters represent the specific parameters actually extracted and used to build the model during the randomization process. Candidate random models are model objects to be verified generated by the randomization engine based on configuration parameters. At this stage, a model structure description has been formed, but the legality and deployability have not yet been confirmed.

[0073] Since manually constructing models relies on engineers' experience, it is inefficient and lacks comprehensive coverage. Therefore, embodiments of this application employ a random model generator to generate random models.

[0074] In this step, a randomization engine randomly selects model parameters from the configuration parameters according to the corresponding probability distribution, driving the generation of candidate random models. The probability distribution can be a distribution directly given by preset rules, or a distribution generated based on the statistical results of historical validation samples.

[0075] Specifically, a parameter space index is established based on the configuration file, and the corresponding sampling probability distribution is bound to the parameter space. The overall structural parameters are extracted from the configuration parameters based on the randomization engine, and the model parameters of each layer are generated. By generating candidate random models, the time required for model construction is reduced compared with manually building models, and batch generation of random models is supported.

[0076] In one possible embodiment, candidate random models can be generated from a macroscopic to a microscopic level, for example, by first determining network-level parameters, then operator-level parameters, and finally parameter-level parameters, thus progressively generating candidate random models. In another possible embodiment, candidate random models can also be generated hierarchically, such as by recursively generating the structure of each layer from left to right.

[0077] Optionally, when generating random models in a progressive manner, a check can be added to each layer. Only when the parameter selection of the current layer meets the constraints of the generated structure can the parameter selection of the subsequent layers proceed. If a conflict is found between the current parameter and the previously determined parameter during the sampling process of a certain layer, resampling is performed in that layer. If necessary, the construction of the current candidate model is terminated and marked as an object to be filtered.

[0078] S202: Perform multi-layer verification on the operator matching of candidate stochastic models and the resource requirements deployed on the hardware platform.

[0079] The multi-layered verification process is used to screen candidate stochastic models at each level, including at least operator matching verification and resource requirement verification. Operator matching is used to determine whether the node operators and their input-output relationships in the candidate stochastic model meet consistency requirements, thus confirming the legality of the model structure and operator connections. Resource requirement represents the computing and storage resources required for the candidate stochastic model to be deployed on the hardware platform. The hardware platform is the target object for the final deployment and execution of the stochastic model and has corresponding resource constraint information.

[0080] Because existing random model generation methods lack validation, the generated random models may not be executable on hardware platforms, resulting in invalid validation. Therefore, this application embodiment, after generating candidate random models, also employs multi-layered validation to prevent invalid models from entering subsequent validation stages.

[0081] In this step, the executing entity reads the structural description information of the candidate random model and performs operator matching verification according to the predetermined verification process to prevent hardware execution errors caused by operator signature mismatch, as well as resource requirement verification to ensure that the generated random model meets the computing power, storage, and bandwidth constraints of the hardware platform.

[0082] Optionally, operator matching verification can check whether the operators, parameter configurations, and connection relationships of each node in the candidate random model are compatible with each other; if there are any cases that do not meet the requirements, the candidate random model is judged to have failed the verification and the subsequent analysis is terminated.

[0083] Optionally, the resource requirements of the candidate randomized model on the hardware platform can be evaluated, such as theoretical computational load (number of MACs), memory usage, and bandwidth requirements. This evaluation is then combined with the resource constraints of the hardware platform to determine whether the candidate randomized model meets the deployment requirements. If the candidate randomized model does not meet the deployment requirements, it is marked as a failed resource requirement evaluation.

[0084] By performing operator matching verification and resource requirement verification, the model before deployment simultaneously meets the two conditions of operator connection establishment and hardware resource capacity, thus avoiding the generation of random models that cannot be executed on the hardware platform.

[0085] S203: Filter out candidate random models that fail the multi-level validation to obtain effective random models.

[0086] Valid random models are used for deployment on hardware platforms. Candidate random models are those that fail multi-level validation and cannot be used for deployment. When a candidate random model fails to meet the requirements in operator matching or resource requirement validation, it is identified as a candidate random model that needs to be filtered out. Valid random models are those that have passed multi-level validation and can be used for deployment on hardware platforms.

[0087] In this step, the executing entity performs classification processing on the candidate random models based on the verification results of step S202, filters out the candidate random models that fail the verification, and only allows the candidate random models that pass all verifications to enter the subsequent deployment process.

[0088] Optionally, for candidate random models that fail multi-level verification, their deployment markers are deleted and written into the failure record, and the reason for their invalidity can also be recorded; for candidate random models that pass all verifications, a valid identifier is generated and output to the subsequent deployment process.

[0089] In one possible embodiment, after filtering out candidate random models that fail multi-level validation, the valid random models can be output to the subsequent deployment process to complete deployment on the hardware platform. For example, after receiving a valid random model, the deployment module can complete graph compilation, instruction mapping, storage allocation, and script generation according to the model format supported by the hardware platform, then drive the hardware platform to run test tasks and send the results back to the verification system.

[0090] Since the model output in step S203 has completed operator matching verification and resource requirement verification, the sources of failure in the subsequent deployment phase are limited to a narrower range, allowing verification engineers to focus their attention on the chip execution logic itself.

[0091] Based on the above analysis, this step effectively filters out multi-layered verification results, retaining only deployable and valid random models for entry into the hardware verification chain. This prevents verification resources from being consumed by obviously unworkable models, thereby increasing the effective density of random models injected into the hardware platform per unit verification time.

[0092] This application provides a method for generating random models. By introducing probability sampling constrained by configuration parameters during the model generation stage, and sequentially performing operator matching verification and resource requirement verification after the candidate random models are formed, random generation and deployment constraints are seamlessly integrated within the same process. Therefore, the output from the generation end is not an unfiltered set of random networks, but a set of valid random models that already meet the requirements of structural consistency and hardware capacity. This solves the problems of low efficiency in manual construction and a high proportion of invalid models due to unconstrained random generation. Furthermore, joint filtering of structural validity and resource deployability is performed before the random models enter the hardware platform, making the random models deployed to neural network accelerators, graphics processors, or other hardware platforms more closely aligned with the target platform constraints. This allows simulation time and computational resources in the testing process to be concentrated on executable models, and the verification results to provide more targeted coverage of the hardware platform logic.

[0093] Figure 3 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 2 In this embodiment, the configuration parameters include: a preset depth range, a preset width range, and a parameter space corresponding to each operator type. The parameter space of the operator type refers to the range of parameter values ​​for each operator type. Furthermore, this embodiment provides a detailed explanation of how to randomly select model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine to generate candidate random models, such as... Figure 3 As shown, the method includes:

[0094] S301: Based on the probability distribution corresponding to the randomization engine, random sampling is performed in the preset depth range and the preset width range to obtain the model depth of the candidate random model to be generated and the node width of each layer node.

[0095] The preset depth range is used to define the minimum and maximum number of network layers, for example, 6 to 30 layers; the preset width range is used to define the maximum and minimum width of nodes in each layer, for example, 16 to 1024.

[0096] Specifically, based on the probability distribution corresponding to the randomization engine, random sampling is performed in a preset depth range to obtain the model depth of the candidate random model to be generated. Then, according to the preset width range, the node width is sampled for each layer. Based on the model depth and node width, the corresponding number of nodes are created for each layer.

[0097] S302: Construct an initial directed graph based on the model depth and the node width of each layer; calculate the exponential decay probability based on the inter-layer distance; add skip connections to the initial directed graph based on the exponential decay probability; and perform topological sorting verification.

[0098] The initial directed graph refers to a graph where edges are connected based on unidirectional dependencies between adjacent layers. The exponential decay probability is an exponential coefficient that varies with the distance between layers. Performing topology sorting verification is used to detect whether the directed graph after adding skip connections contains cycles or isolated nodes. Cycles are linked by links with the same start and end nodes, while isolated nodes are nodes with no connections to other nodes.

[0099] Specifically, for any two non-adjacent layers, the following formula is used to calculate the exponential decay probability based on the inter-layer distance, and the result of random number sampling is used to determine whether to add an edge connection between the two layers.

[0100] S303: If the topological sorting verification indicates that the initial directed graph after adding jump links is acyclic, the initial directed graph after adding jump links will be treated as a directed acyclic graph.

[0101] Specifically, after adding jump connections, a topology sorting verification is performed on the graph. If an impossible sorting relationship exists, a cycle is identified in the graph, and the current structure is abandoned. If the topology sorting can cover all nodes, the graph is determined to be a directed acyclic graph. If isolated nodes are detected in the graph after adding jump connections, they can be marked as warnings but allowed to proceed to subsequent processes, or they can be marked as warnings and local resampling (such as adjusting jump connection positions) can be triggered before re-performing the topology sorting verification. Topology sorting verification ensures the legality of the model's network topology structure, avoiding simulation crashes or invalid verification due to structural defects. In the random generation process, structural verification acts as a quality gate, ensuring that only models with legal topologies proceed to the next stage.

[0102] The exponential decay design of the exponential decay probability simulates the long and short hop connection patterns of real networks such as ResNet / DenseNet, making the generated model structure closer to real-world application scenarios.

[0103] For example, the probability of exponential decay is calculated using the following formula:

[0104]

[0105] Where p is the basic exponential decay probability, and Δ layer This represents the interlayer distance. Then, a random number r between 0 and 1 is generated; when r... <p skip Add jump connections when r ≥ p skip No additions are made at certain times. It's understandable that the exponentially decaying probability isn't compared to a fixed threshold; for example, when p... skip =0.3 means there is a 30% probability of adding a jump combo.

[0106] The exponential decay probability is compared with the generated random number. When the exponential decay probability is greater than the random number extraction result, a jump connection is added between the two layers; when the exponential decay probability is less than or equal to the random number, no jump connection is added. The exponential decay probability is not compared with a fixed threshold, but with a randomly generated random number, which improves the randomness of the candidate random model.

[0107] For example, if the initial directed graph of the candidate random model contains nodes A→B→A, since the starting node and the ending node of this link are the same, it indicates that there is a loop in the directed graph after the jump connection, and the topology sorting verification fails.

[0108] The random sampling results directly determine the number of model layers and the size of each layer. The exponential decay probability makes the generation distribution of cross-layer connections related to the inter-layer distance. Topological sorting verification checks the consistency of the structure after the introduction of jump connections. The resulting directed acyclic graph can serve as the skeleton structure of the candidate random model and be used for subsequent operator configuration and parameter constraint processing. This makes the generated model structure have good randomness and verifiability, and is more likely to meet the needs of subsequent verification.

[0109] S304: Based on the position of each node in the directed acyclic graph, randomly determine the operator type of each node, and randomly add parameter constraints to each node in the parameter space corresponding to the operator type of each node to generate a stochastic model.

[0110] The operator types include standard operators and / or combined operators. Standard operators can be, for example, convolution operators, normalization operators, activation operators, pooling operators, etc. Combined operators are obtained by combining at least two standard operators. For example, a combined operator can be Conv2D + Transpose + a custom activation function. Optionally, the combination method of combined operators can be limited by preset combination rules. The parameter space is used to define the independent sampling space and hardware alignment constraints of each operator. The parameter types in the parameter space include at least kernel size, stride, padding method, number of channels, number of groups, or activation threshold.

[0111] In practical implementation, standard operators or combined operators are randomly assigned according to the probability distribution based on the position of each node in the graph. It can be understood that the combined operators are logically considered as single-node operators. For each assigned operator type, parameter constraints are randomly generated in its corresponding parameter space and bound to the corresponding nodes. The final output is a candidate stochastic model that satisfies the structural and parameter boundaries. The dynamic combination capability of combined operators allows the generated stochastic model to cover non-standard operator combinations that cannot be expressed by standard formats such as the Open Neural Network Exchange (ONNX).

[0112] Optionally, the available operator pool can be filtered by node position (input layer / hidden layer / output layer), and the operator type can be weighted and randomly sampled.

[0113] For example, Table 1 is a parameter space table provided in an embodiment of this application. Table 1 includes parameter types, sampling spaces for each parameter type, constraints, and technical functions.

[0114] Table 1

[0115]

[0116] By combining node positions to complete operator assignment and parameter constraint binding, the generated results have a clear hierarchical relationship and deployability. While maintaining the structural diversity of candidate random models, it also ensures that the candidate random models are consistent with the preset parameter space, thereby improving the effectiveness of model generation and its adaptability to the target validation scenario.

[0117] S305: Along the forward propagation path, deduce the tensor type of each node in the candidate random model; by comparing the consistency between the tensor type and the operator signature of the node, perform type deduction verification of the candidate random model.

[0118] In this model, each node corresponds to a standard operator such as convolution, normalization, activation, pooling, or matrix multiplication, as well as a combined node formed based on combinations of standard nodes. Tensor types describe the dimension and data type of the data tensors in the neural network. For example, the input tensor type of Conv2D is Tensor<3,256,256>, and the output type is Tensor<64,128,128>.

[0119] Specifically, starting from the input node, the tensor type of the current node is derived along the forward propagation path based on the input tensor rules of the node operators. This tensor type is then passed along the edges to the successor nodes, i.e., the tensor type is used as the input tensor type of the successor node, and the output tensor type of the successor node is updated with the input tensor type, until the full model derivation is completed. After the derivation is complete, the tensor type derived by each node is compared with the input dimension, output dimension, data type, and broadcast constraints in its operator signature. If any node has inconsistent dimensions, incompatible types, or unsatisfactory connection relationships, the candidate random model is determined to have failed the type derivation verification. If the tensor types of all nodes are consistent with the operator signatures of the nodes, the candidate random model is determined to have passed the type derivation verification.

[0120] For example, Table 2 is a type derivation verification reference table provided in an embodiment of this application. Table 2 includes operators, operator signatures, and constraints. The type derivation verification comparison can also be restricted by the constraints, and the consistency between the tensor type of each node and the operator signature of the node can be determined according to the constraints of each operator.

[0121] Table 2:

[0122]

[0123] Type deduction verification prevents hardware execution errors caused by tensor shape mismatches or data type conflicts when deploying random models on hardware platforms. In randomly generated scenarios, the probability of type conflicts is much higher than in manually constructed scenarios because operator types and parameters are random combinations. Therefore, automated type deduction verification is an indispensable part of the random model generation process.

[0124] S306: After the type derivation verification passes, calculate the resource requirements of the candidate random model and compare them with the resource threshold of the hardware platform; if the resource requirements are less than or equal to the resource threshold, the resource budget verification is confirmed to have passed.

[0125] Resource requirements refer to the resources needed to execute the candidate stochastic model. Resource thresholds refer to the upper limits of the hardware platform in terms of computing power, storage, bandwidth, and other resources. Resource thresholds may correspond to one or more of the following: on-chip storage capacity, maximum computing unit occupancy, and bandwidth budget.

[0126] If the type derivation verification passes, the theoretical computational load (number of MACs), memory usage, and bandwidth requirements are calculated and compared with the resource thresholds preset by the hardware platform. If the resource requirements are less than or equal to the resource thresholds, the resource budget verification is considered to have passed.

[0127] Candidate random models that fail the resource budget check can be filtered out directly, or the model can be pruned until the pruned candidate random model passes the type inference check and the resource budget check before it can be included in the subsequent deployment process.

[0128] By first eliminating models with invalid operator connections during the type derivation verification stage, and then eliminating models that exceed the hardware's carrying capacity during the resource budget verification stage, the random models entering the subsequent verification stage can simultaneously satisfy structural executability and deployment carrying capacity, thereby reducing invalid model inputs and increasing the proportion of valid verification samples.

[0129] Based on the foregoing embodiments, the method further includes:

[0130] When the resource demand exceeds the resource threshold, the excess ratio is determined based on the difference between the resource demand and the resource threshold. When the excess ratio is less than the tolerance threshold, the candidate random model is pruned and the type derivation is re-validated. When the excess ratio is greater than or equal to the tolerance threshold, the candidate random model is determined to be invalid, and the reason for invalidity is recorded.

[0131] The tolerance threshold is used to indicate the range within which resource requirements can exceed the resource threshold. The tolerance threshold can be preset based on the hardware platform's resource margin, verification strategy, and generation strategy; for example, it could be 20%. In practical applications, this threshold can also be adjusted based on the platform model, test batch, or resource-sensitive items; this application does not limit this adjustment.

[0132] In practical implementation, when performing resource budget verification on candidate random models, if the resource requirement of a candidate random model exceeds a resource threshold, the difference between the resource requirement and the resource threshold is calculated, and the difference is divided by the resource threshold to obtain the excess ratio. The excess ratio is then compared with a preset tolerance threshold.

[0133] When the comparison results show that the excess ratio is less than the tolerance threshold, it indicates that although the candidate random model has resource overruns, the overrun is still within a correctable range. At this time, the random model is pruned. Pruning can target redundant nodes, duplicate branches, excessively wide channel numbers, or the size of some parameters to reduce resource consumption. After pruning, the tensor types of each node are derived again along the forward propagation path, and the consistency between the node operator signature and the tensor type is checked to confirm that the pruned model still meets the type constraints and operator matching requirements, and outputs the corrected candidate random model that can continue to enter the verification process.

[0134] Preferably, during pruning, priority is given to downsampling the channels to minimize accuracy loss, followed by deleting layers, and finally replacing them with smaller kernels.

[0135] When the excess ratio is greater than or equal to the tolerance threshold, it indicates that the resource excess of the candidate random model has exceeded the allowable correction range. The system will then determine the candidate random model as invalid and write the corresponding resource item, excess ratio, and the judgment condition for invalidation into the invalidation reason record so that the parameter distribution, structure sampling rules, or resource constraint configuration of the randomization engine can be analyzed and corrected in the future.

[0136] Through the above processing, candidate random models with slightly excessive resources can be pruned, re-verified, and retained, while candidate random models with severely excessive resources will be directly eliminated and the reason information will be retained. This makes the selection of effective random models closer to the hardware resource boundary and reduces the proportion of invalid models entering the subsequent verification stage.

[0137] S307: Filter out candidate random models that fail multi-level validation to obtain effective random models.

[0138] Step S307 is similar to step S203, and will not be described again here.

[0139] This application provides a random model generation method that, through the probability distribution corresponding to the randomization engine, determines the model depth and node width of each layer of candidate random models from configuration parameters, and adds jump connections to form a directed graph. Only directed graphs that pass topological sorting verification are allowed to enter the subsequent generation process. The method also determines the operator type and operator parameters layer by layer to obtain candidate random models. Type deduction verification and resource budget verification are performed on the generated candidate random models to filter out those that fail the verification. In the random generation process, structural verification acts as a quality gate, ensuring that only topologically valid models enter the next stage. By first eliminating models with invalid operator connections in the type deduction verification stage and then eliminating models exceeding hardware capacity in the resource budget verification stage, the random models entering the subsequent verification stage simultaneously satisfy structural executability and deployment compatibility. This reduces invalid model input and increases the proportion of valid verification samples, allowing simulation time and computing resources in the testing process to be concentrated on executable models, making the verification results more targeted in covering the hardware platform logic.

[0140] Existing random generation methods are open-loop structures, which cannot utilize coverage data from random model validation to optimize random model generation strategies, resulting in a lack of specificity in random model generation. Figure 4 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 3 In this embodiment Figure 2 or Figure 3 Based on the implementation example, in this example, the probability distribution is determined through weighted random sampling. Furthermore, a method for generating a random model is explained in detail. Before generating a candidate random model by randomly selecting model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine, as follows... Figure 4 As shown, the method also includes:

[0141] S401, Collect the coverage of the effective random model.

[0142] Coverage rate is used to characterize the ratio of actual execution resources used to the allowed execution resources when a hardware platform executes a stochastic model. Coverage rate includes at least one of the following: operator coverage rate, topology coverage rate, and flip coverage rate. Specifically, operator coverage rate refers to the proportion of operators in the effective stochastic model to the actual usable operators in the configuration parameters; topology coverage rate refers to the proportion of the actual topology structure of the effective stochastic model to the theoretical topology structure; and flip coverage rate refers to the proportion of the number of flipped signals after the effective stochastic model is deployed to the hardware platform to the theoretical number of flipped signals.

[0143] Table 3 is a coverage information table provided in the embodiments of this application, including coverage dimensions, granularity, measurement methods, and technical functions.

[0144] Table 3

[0145]

[0146] The coverage of candidate random models in several dimensions is collected after they are deployed on the hardware platform. Among them, operator coverage and topology coverage can be collected after the candidate random models are generated, while flip coverage can only be collected after the random models are deployed on the hardware platform.

[0147] S402. Based on the coverage, the weights corresponding to each candidate region are updated using an exponential gradient update strategy.

[0148] Among them, the exponential gradient update strategy refers to dynamically adjusting the weights of each parameter through an exponential weight update formula.

[0149] Specifically, based on characteristics such as operator type, input data type, parameter value range, and model structure, the configuration parameters of the stochastic model are divided into multiple candidate regions, and the actual coverage gap of each region is statistically analyzed based on coverage rate. Regions where no corresponding model has been generated, or where the actual coverage is lower than the target coverage, are considered uncovered or under-covered regions. The coverage gap is determined based on the difference between the target coverage and the actual coverage of each candidate region. The larger the coverage gap, the fewer models have been generated in that candidate region, and the more necessary it is to increase the sampling weight of each candidate parameter in the corresponding candidate region during subsequent stochastic model generation.

[0150] The formula for updating index weights is as follows:

[0151]

[0152] in, Let i be the sampling weight of the i-th candidate region after this round of adjustment. The sampling weight of the i-th candidate region before this round of adjustment is given. The difference between the current coverage and the target coverage of the i-th candidate region can be either the coverage rate or a difference determined based on the coverage rate. The larger the value, the more times the candidate region needs to appear in subsequent stochastic models. 'a' is the learning rate (default 2.0; this value is based on empirical experiments: a=1.0 results in slow convergence, a=3.0 results in overfitting to a single dimension, and a=2.0 strikes a balance between exploration and exploitation). This represents the sum of the coverage gaps of all candidate regions, used to normalize the coverage gap of the i-th candidate region.

[0153] Optionally, after updating the sampling weights, a smoothing factor β can be introduced to retain the lowest exploration rate and avoid zero weights causing certain parameter combinations to permanently lose the opportunity to be sampled. The smoothing factor ensures that even areas that are currently completely uncovered have a non-zero exploration probability.

[0154] The sampling weights of each configuration parameter are adjusted using an exponential weight update formula, thereby dynamically adjusting the sampling priority. Regions with larger coverage gaps receive more significant weight increases. The exponential function ensures a non-linear response to the weight adjustment: small gaps are adjusted gradually, while large gaps are adjusted rapidly.

[0155] S403. Normalize the updated weights of each candidate region to obtain a new probability distribution for the randomization engine.

[0156] Specifically, a new probability distribution is obtained through normalization, which is then used by the randomization engine in subsequent model generation. Since the probability distribution is directly driven by the actual coverage, the randomized generation results will shift towards resource dimensions and parameter combinations with insufficient coverage, thereby making subsequent candidate randomized models more suitable for the verification requirements of the hardware platform.

[0157] The probability distribution of the randomization engine can be updated after each generation of a candidate random model, after each deployment of a valid random model, or periodically. This application does not impose any restrictions on this.

[0158] The random model generation method provided in this application collects the coverage of candidate random models, updates the weights of each candidate region based on the coverage using an exponential gradient update strategy, normalizes the updated weights of each parameter, and obtains a new probability distribution of the randomization engine. This enables the random model generation process to form a closed-loop feedback with hardware resource usage, improves the targeting of configuration parameter sampling, and reduces the probability of repeatedly covering fully validated regions.

[0159] Furthermore, the method also includes applying random perturbation to the sampling process during random sampling to establish a dynamic balance between exploration and exploitation, preventing candidate random models from collapsing into local optima prematurely, thereby ensuring that the generated random models have sufficient topological diversity.

[0160] The dynamic exploration rate is determined based on the coverage rate, and the random perturbation amplitude is adjusted accordingly. The dynamic exploration rate and the random perturbation amplitude are positively correlated. The greater the difference between the current coverage rate and the target coverage rate, the larger the random perturbation amplitude is used; the closer the current average coverage rate is to the target coverage rate, the smaller the random perturbation amplitude is used.

[0161] Specifically, the dynamic exploration rate is determined using the following formula:

[0162]

[0163] in, For dynamic exploration rate, The adjustment factor can be 0.1, 0.05, etc. c represents the current average coverage rate, which is the mean of the coverage rate. target Target coverage.

[0164] Optionally, a minimum exploration rate can be set for the dynamic exploration rate. The lower limit value can be, for example, 0.01, 0.02, etc. When the calculated dynamic exploration rate is less than the minimum exploration rate, the lower limit value is used as the dynamic exploration rate.

[0165] Based on the degree of coverage insufficiency, expected increase in coverage, historical anomalies, and the importance of the corresponding functions in each candidate region, the testing benefits of continuing to generate stochastic models in each candidate region are evaluated. Regions with a high expected contribution to improving test coverage, discovering potential defects, or validating important functions are identified as high-value regions. Appropriate operators, parameter values, input data, and model structures are selected for these high-value regions to generate subsequent stochastic models. In the early stages of validation (low coverage), a high exploration rate is encouraged, promoting extensive exploration of various model structures. In the later stages of validation (coverage close to the target), the exploration rate decreases, converging to the identified high-value regions. The minimum exploration rate is always maintained to prevent getting trapped in local optima.

[0166] Furthermore, the goodness-of-fit of the generated random model can be tested. Specifically, the goodness-of-fit is determined based on the actual frequency of occurrence of each operator type, topology, and parameter combination in the generated random model. The goodness-of-fit is determined using the following formula:

[0167]

[0168] in, For goodness of fit, The frequency of observations is the actual number of times the i-th operator type, topology, or parameter combination appears in the generated stochastic model. This represents the expected number of occurrences of the i-th operator type, topology, or parameter combination, calculated according to the probability distribution of the randomization engine. The goodness of fit is compared to the chi-square distribution critical value (b=0.05).

[0169] If the uniform coverage assumption is rejected, regions with negative bias exceeding the bias threshold are marked as coverage holes. From a statistical significance perspective, this determines whether the coverage distribution is uniform, identifies insufficiently covered operator types, topologies, and parameter combinations, and guides the direction of exponential weight adjustments. The bias threshold could be, for example, 50%.

[0170] Based on the foregoing embodiments, a further explanation is provided regarding a random model generation method. Before generating candidate random models by randomly selecting model parameters from configuration parameters based on the probability distribution corresponding to the randomization engine, the method further includes:

[0171] In response to the verification task, the type of candidate random model to be generated is determined based on the verification requirement characteristics of the verification task.

[0172] The types include: a first type of model encapsulated in a standard format, and / or a second type of model built based on a custom intermediate representation layer. Standard formats include ONNX format, etc. The verification task includes verification requirement features, which are used to determine at least one type of candidate stochastic model to be generated. These verification requirement features include: compatibility score and customization score; the compatibility score is determined based on the hardware platform's support for standard formats; the customization score is determined based on the strength of the verification task's requirement for combinations of non-standard operators.

[0173] The candidate random models to be generated include: a first type of model encapsulated in a standard format, and / or a second type of model built based on a custom intermediate representation layer (Abstract Semantic Abstraction Layer, ASA), which is located above the hardware description layer and below the operator semantic layer.

[0174] Specifically, upon receiving the verification task and configuration parameters, the compatibility score and customization score are first extracted from the verification requirement features. These scores are then compared with a first preset value and a second preset value, respectively. Based on the comparison results, the type of the candidate random model to be generated is determined. For example, the first and second preset values ​​could be 0.7 and 0.5, respectively.

[0175] By determining the model type before random parameter sampling, the generation target is limited to a model representation that matches the validation requirements, and the subsequent generation process is directly oriented towards the required standard or customized model, thereby improving the format adaptability and scenario relevance of the generated candidate random models.

[0176] If the compatibility score is greater than a first preset value and the customization score is less than a second preset value, then the candidate random model to be generated is determined to be a first-class model. If the compatibility score is greater than the first preset value and the customization score is greater than or equal to the second preset value, then the candidate random model to be generated is determined to be both a first-class model and a second-class model. If the compatibility score is less than or equal to the first preset value, then the candidate random model to be generated is determined to be a second-class model.

[0177] Furthermore, if the first type of model is selected, the operator graph, tensor properties, and input / output interfaces are encapsulated using a standard format;

[0178] For example, the random model generator automatically generates a network model in the ONNX standard format based on a preset model template or configuration parameters. Randomization elements include the number of network layers (depth), the operator type for each layer, operator parameters (kernel size, stride, padding), the shape and dimensions of the data tensors, the weight distribution, and the network connection topology.

[0179] The generated ONNX model is parsed by an AI compiler, which performs model structure validity checks, operator-level optimizations, and format conversion from ONNX to the target intermediate representation (IR). During this process, the compiler eliminates any redundant structures in the ONNX model and fuses and rearranges operators to adapt to the execution requirements of the verification environment. The format-converted model is then input into the IP verification environment for hardware simulation verification.

[0180] By fully utilizing the existing ONNX ecosystem toolchain, the generated candidate stochastic models exhibit good versatility and portability.

[0181] If the second type of model is selected, the intermediate representation is constructed according to the node semantics, connection relationships and parameter description rules of the custom intermediate representation layer, and then mapped to the model skeleton that can be called by the randomization engine.

[0182] For example, the randomization configuration parameters and hardware constraints (including computing power limit, storage bandwidth limit, list of supported operator types, maximum network depth, etc.) specified by the user are received to establish the generation space of the random model generator.

[0183] The random model generator directly defines the structured description of the model in the intermediate representation layer of ASA, including: network hierarchical topology (forward propagation path described by DAG directed acyclic graph), operator types and parameter configurations bound to each node at each level, and the flow direction and size definition of tensor data between nodes.

[0184] Randomization is generated sequentially according to a three-tiered progressive structure: "network level → operator level → parameter level".

[0185] Among them, network-level randomization: randomly determines the number of network layers and the connection method between each layer (serial / parallel / jump connection) to generate DAG topology.

[0186] Operator-level randomization: Randomly selects an operator type from the available operator pool for each network node and randomly generates a combination of configuration parameters for that operator. For abnormal scenarios not covered by the standard operator pool, activate the custom operator generation module to dynamically combine non-standard operators based on basic operator primitives.

[0187] Parameter-level randomization: Randomizes numerical parameters such as weights, biases, and tensor shapes, and supports multiple random distribution strategies (uniform distribution, normal distribution, boundary value distribution, etc.).

[0188] Multi-level formal validation (structural validation → type derivation validation → resource budget validation) is also required. Candidate random models that pass the multi-level validation are considered valid random models. Candidate random models that fail the multi-level validation are recycled back to the random generator for regeneration, and the reasons for failure are recorded as input for subsequent negative samples.

[0189] Establish and validate a coverage feedback channel for the environment to acquire coverage data of executed models in real time. Based on coverage backtracking analysis, identify uncovered circuit logic paths and functional scenarios, and dynamically adjust the probability distribution in the randomization strategy.

[0190] The runtime scheduling module distributes the formally validated model data to the IP validation environment for execution. By reducing intermediate steps such as standard format model export and front-end compilation, the latency from model generation to validation execution is significantly reduced.

[0191] The generated second type of model requires no intermediate conversion and supports non-standard operator combinations that cannot be expressed in the standard format. It is suitable for verification tasks that pursue high verification efficiency, require deeply customized operators, and cover non-standard scenarios.

[0192] If both the first and second type models are generated simultaneously, a random model is obtained after multiple iterations of the graph hashing algorithm (Weisfeiler-Lehman, WL) to remove structural deduplication. By quantifying and representing the characteristics of the verification requirements and performing threshold determination, the type of the candidate random model to be generated is kept consistent with the verification target. This allows the generation direction of the random model to switch according to changes in compatibility and customization requirements, making the output random model more suitable for the verification needs of the hardware platform.

[0193] Optionally, differentiated dynamic randomization strategies can be designed based on the behavioral characteristics of effective randomized models in different application scenarios. Scenario templates are predefined in YAML format. When the randomized model generator starts, it reads the YAML scenario configuration file, parses fields such as the operator pool whitelist, parameter value range constraints, and topology rule constraints, and merges them into the default configuration to generate the final randomization configuration parameters. Scenario templates support user-defined extensions.

[0194] For example, Table 4 is a schematic table of scene templates provided in the embodiments of this application. As shown in Table 4, a variety of scene templates are provided.

[0195]

[0196] For example, Figure 5 A flowchart illustrating a random model generation method provided in this application embodiment. Figure 4 ,like Figure 5 As shown, upon receiving a verification task, the verification requirement features, including compatibility scores and customization scores, are extracted and compared with preset values. Based on the comparison results, the corresponding random model generation path is determined, and a random model is generated and deployed on the hardware platform. If it is a parallel path, a graph hashing algorithm is needed to fuse and deduplicate the two generated random models before deploying them on the hardware platform.

[0197] Figure 6 This is a schematic diagram of the structure of a random model generator provided in an embodiment of this application, as shown below. Figure 6 As shown, the random model generator 60 provided in this embodiment includes: a generation module 601 and a verification module 602;

[0198] Among them, the generation module 601 is used to randomly select model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine to generate candidate random models;

[0199] The verification module 602 is used to perform multi-level verification of the operator matching of the candidate random model and the resource requirements deployed on the hardware platform.

[0200] The verification module 602 is also used to filter out candidate random models that fail the multi-level verification to obtain valid random models, which are then deployed on the hardware platform.

[0201] In one possible implementation, the verification module 602 is also used to deduce the tensor type of each node of the candidate random model along the forward propagation path; and to perform type deduction verification of the candidate random model by comparing the consistency between the tensor type and the operator signature of the node.

[0202] After the type derivation verification passes, the verification module 602 is also used to calculate the resource requirements of the candidate random model and compare them with the resource threshold of the hardware platform; when the resource requirements are less than or equal to the resource threshold, the resource budget verification is determined to be successful.

[0203] In one possible implementation, the verification module 602 is further configured to determine the excess ratio based on the difference between the resource demand and the resource threshold when the resource demand exceeds the resource threshold; to prune the candidate random model and re-perform type derivation verification when the excess ratio is less than the tolerance threshold; and to determine that the candidate random model is invalid and record the reason for invalidity when the excess ratio is greater than or equal to the tolerance threshold.

[0204] In one possible implementation, the configuration parameters include: a preset depth interval, a preset width interval, and parameter spaces corresponding to each operator type. The generation module 601 is further used to construct a directed acyclic graph by randomly sampling within the preset depth interval and the preset width interval based on the probability distribution corresponding to the randomization engine; randomly determining the operator type of each node according to the position of each node in the directed acyclic graph, the operator type including: standard operators and / or combined operators, where the combined operator is obtained by combining at least two standard operators; and randomly adding parameter constraints to each node within the parameter space corresponding to the operator type of each node to generate a candidate random model.

[0205] In one possible implementation, the generation module 601 is further configured to perform random sampling within a preset depth range and a preset width range based on the probability distribution corresponding to the randomization engine, to obtain the model depth of the candidate random model to be generated and the node width of each layer node; construct an initial directed graph based on the model depth and the node width of each layer node; calculate the exponential decay probability according to the inter-layer distance, add jump connections to the initial directed graph based on the exponential decay probability, and perform topological sorting verification; when the topological sorting verification indicates that there are no cycles in the initial directed graph after adding jump connections, the initial directed graph after adding jump connections is regarded as a directed acyclic graph.

[0206] In one possible implementation, the generation space composed of configuration parameters includes: multiple candidate regions, each candidate region including candidate parameters; the generation module 601 is also used to collect the coverage of the effective random model, the coverage being used to characterize the ratio of the execution resources actually used to the allowed execution resources when the hardware platform executes the effective random model; based on the coverage, the weights corresponding to each candidate region are updated through an exponential gradient update strategy; the updated weights of each candidate region are normalized to obtain a new probability distribution of the randomization engine.

[0207] In one possible implementation, the generation module 601 is further configured to, in response to a verification task, determine the type of candidate random model to be generated based on the verification requirement characteristics of the verification task; the type includes: a first type of model encapsulated in a standard format, and / or a second type of model built based on a custom intermediate representation layer.

[0208] In one possible implementation, the verification requirement features include: a compatibility score and a customization score. The generation module 601 is further configured to determine the candidate random model to be generated as a first type model if the compatibility score is greater than a first preset value and the customization score is less than a second preset value; to determine the candidate random model to be generated as a first type model and a second type model if the compatibility score is greater than the first preset value and the customization score is greater than or equal to the second preset value; and to determine the candidate random model to be generated as a second type model if the compatibility score is less than or equal to the first preset value.

[0209] The random model generator provided in this embodiment can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0210] Figure 7 This is a schematic diagram of a hardware platform provided in an embodiment of this application. Figure 7 As shown, the hardware platform 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the hardware platform 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0211] The memory 702 is used to store the target model, which is generated based on the random model generation method described above; its implementation principle and technical effect are similar, and will not be repeated here in this embodiment.

[0212] In the specific implementation process, at least one processor 701 is used to perform inference on the input data based on the target model and output the inference result.

[0213] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0214] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0215] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0216] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0217] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0218] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0219] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0220] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0221] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0222] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0224] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0225] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for generating a random model, characterized in that, include: Based on the probability distribution corresponding to the randomization engine, model parameters are randomly selected from the configuration parameters to generate candidate random models; The operator matching of the candidate random model and the resource requirements deployed on the hardware platform are verified in multiple layers. Candidate random models that fail the multi-layer verification are filtered out to obtain valid random models, which are then deployed on the hardware platform.

2. The method according to claim 1, characterized in that, The multi-layer verification of the operator matching of the candidate random model and the resource requirements deployed on the hardware platform includes: Along the forward propagation path, deduce the tensor type of each node in the candidate random model; The candidate random model is verified by comparing the consistency between the tensor type and the operator signature of the node; After the type derivation verification is passed, the resource requirement of the candidate random model is calculated and compared with the resource threshold of the hardware platform. When the resource demand is less than or equal to the resource threshold, the resource budget verification is deemed successful.

3. The method according to claim 2, characterized in that, The method further includes: When the resource demand exceeds the resource threshold, an excess ratio is determined based on the difference between the resource demand and the resource threshold. When the excess ratio is less than the tolerance threshold, the candidate random model is pruned and the type derivation and verification are performed again. When the excess ratio is greater than or equal to the tolerance threshold, the candidate random model is determined to be invalid, and the reason for invalidity is recorded.

4. The method according to claim 1, characterized in that, The configuration parameters include: a preset depth range, a preset width range, and parameter spaces corresponding to each operator type. The step of randomly selecting model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine to generate candidate random models includes: Based on the probability distribution corresponding to the randomization engine, random sampling is performed in the preset depth interval and the preset width interval respectively to construct a directed acyclic graph; According to the position of each node in the directed acyclic graph, the operator type of each node is randomly determined. The operator type includes: standard operators and / or combined operators. The combined operator is obtained by combining at least two standard operators. Within the parameter space corresponding to the operator type of each node, parameter constraints are randomly added to each node to generate the candidate random model.

5. The method according to claim 4, characterized in that, The step of constructing a directed acyclic graph by randomly sampling within the preset depth and preset width intervals based on the probability distribution corresponding to the randomization engine includes: Based on the probability distribution corresponding to the randomization engine, random sampling is performed in the preset depth range and the preset width range respectively to obtain the model depth of the candidate random model to be generated and the node width of each layer node. Based on the model depth and the node width of each layer, an initial directed graph is constructed; Calculate the exponential decay probability based on the inter-layer distance, add jump connections to the initial directed graph based on the exponential decay probability, and perform topological sorting verification. When the topological sorting verification indicates that there are no cycles in the initial directed graph after adding jump links, the initial directed graph after adding jump links is taken as the directed acyclic graph.

6. The method according to claim 1, characterized in that, The generation space comprised of the configuration parameters includes multiple candidate regions, and the method further includes: The coverage of the effective stochastic model is collected, and the coverage is used to characterize the ratio of the execution resources actually used to the allowed execution resources when the hardware platform executes the effective stochastic model; Based on the coverage rate, the weights corresponding to each candidate region are updated using an exponential gradient update strategy. The updated weights of each candidate region are normalized to obtain a new probability distribution for the randomization engine.

7. The method according to any one of claims 1-6, characterized in that, Before generating candidate random models by randomly selecting model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine, the method further includes: In response to the verification task, the type of candidate random model to be generated is determined based on the verification requirement characteristics of the verification task; The types include: The first type of model is encapsulated using a standard format, and / or the second type of model is built based on a custom intermediate representation layer.

8. The method according to claim 7, characterized in that, The verification requirement features include: compatibility score and customization score. The determination of the type of candidate random model to be generated based on the verification requirement features of the verification task includes: If the compatibility score is greater than a first preset value and the customization score is less than a second preset value, then the candidate random model to be generated is determined to be a first type of model. If the compatibility score is greater than the first preset value and the customization score is greater than or equal to the second preset value, then the candidate random model to be generated is determined to be a first type model and a second type model. When the compatibility score is less than or equal to the first preset value, the candidate random model to be generated is determined to be the second type of model.

9. A random model generator, characterized in that, include: The generation module is used to randomly select model parameters from the configuration parameters based on the probability distribution corresponding to the randomization engine, and generate candidate random models. The verification module is used to perform multi-level verification of the operator matching of the candidate random model and the resource requirements deployed on the hardware platform. The verification module is also used to filter out candidate random models that fail the multi-layer verification to obtain a valid random model, which is used to deploy on the hardware platform.

10. A hardware platform, characterized in that, include: Memory, processor; The memory stores the target model, which is generated based on the method described in any one of claims 1-8; The processor is used to perform inference on the input data based on the target model and output the inference results.

Images