MindSpore-based operator processing method and device

Abstract

The invention provides an operator processing method and device based on MindSpore, and relates to the technical field of data processing.The method comprises the steps that graph nodes with explicit calculation semantics in a deep learning model are extracted and are abstracted into an independent operator type set in a unified mode; constructing a minimum executable network structure to verify whether the minimum executable network structure can be successfully identified and generate intermediate representation in a MindSore framework, further calling a graph compiler to judge whether back-end graph optimization can be completed, loading to a running environment to execute verification if the back-end graph optimization can be completed, and calculating an error based on forward output and gradient return results, and if the error is lower than the set tolerance, identifying the operator as a function effective operator. According to the method and the device, the problem that the MindSore framework supports the operator incompletely or is insufficient in performance in the large model training and reasoning process can be solved, and the function effectiveness and the execution consistency of the target operator in the stages of composition, compilation and operation are guaranteed.

Description

Technical Field

[0001] The present application relates to the technical field of data processing, and in particular to a MindSpore-based operator processing method and device. Background Art

[0002] MindSpore is a full-scenario AI computing framework developed by Huawei. It is aimed at heterogeneous cloud, edge, and end environments, and has capabilities such as automatic differentiation, dynamic graph and static graph fusion, distributed training scheduling, and operator fusion optimization. It supports multiple hardware platforms such as GPUs and CPUs, and has high performance, high scalability, and modular design. It can cover large-model training, inference deployment, and AI engineering processes, and is particularly suitable for building autonomous and controllable deep learning application systems.

[0003] MindSpore's operator processing refers to the entire process of systematically identifying, adapting, completing, and optimizing the basic computing units that large models rely on during inference and training. This mainly includes extracting all operator types required by the model, verifying the MindSpore framework's support for these operators, identifying missing or performance-bottleneck operators, and achieving functional completeness and performance enhancement of operators through methods such as constructing equivalent logic, custom registration, and execution optimization, thereby ensuring the efficient operation and stable deployment of large models on MindSpore.

[0004] In MindSpore, operator support not only means that the front-end provides a callable API interface, but also requires that the operator can be correctly identified and converted into a unified intermediate representation MindIR during the static graph construction phase, and maintain functional integrity and execution consistency during subsequent graph compilation, graph optimization, and underlying device scheduling. Therefore, operator verification must cover the entire process from model construction to final operation, and cannot rely solely on correctness judgment during dynamic execution. Otherwise, problems such as functional loss, performance degradation, or operation failure may occur during static graph compilation or deployment. Summary of the Invention

[0005] This application provides an operator processing method and device based on MindSpore, which can solve the problem of incomplete support or insufficient performance of operators in the MindSpore framework during large-scale model training and inference, and ensure the functional effectiveness and execution consistency of the target operator in the composition, compilation and operation stages.

[0006] In a first aspect of the present application, a MindSpore-based operator processing method is provided, the method comprising: Obtain the complete computational graph of the target deep learning model during the inference and training phases, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types; For each target operator in the set of independent operator types, construct a minimum executable network structure containing the target operator in the MindSpore framework, and verify whether the target operator can be successfully recognized by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation; Call the graph compiler of the MindSpore framework to convert the intermediate representation into the underlying execution graph, and determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization; If it is determined that the target operator can be parsed and graph-level optimized by the back-end compiler, the target operator is loaded into the MindSpore runtime environment and executed on the specified hardware backend. The functional output and gradient return of the target operator are verified through the input tensor. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator.

[0007] Based on the above technical solution, preferably, after verifying the functional output and gradient return of the target operator through the input tensor, the method further includes: Collecting the execution time of each target operator on different devices; Calculating the computing power utilization and performance sensitivity of the target operator based on the execution time; Constructing a performance bottleneck map of the target operator based on computing power utilization and performance sensitivity; Correlate and analyze the performance bottleneck map with the MindSpore backend execution log to identify bottleneck factors affecting the performance of the target operator, including memory bandwidth limitations, operator fusion failures, scheduling delays, or thread concurrency conflicts. For the target operator identified as having abnormal performance in the performance bottleneck graph, the operator-level optimization interface provided by the MindSpore graph optimizer is called to perform optimization operations to generate an optimized execution path for the target operator. The optimization operations include operator fusion reconstruction, memory access mode rearrangement, instruction-level parallelism adjustment, and scheduling priority reordering. The optimized execution path is written to the location of the target operator in the underlying execution graph to form an updated underlying execution graph structure, and is reloaded into the MindSpore runtime environment to obtain the optimized output tensor and optimized gradient tensor of the optimized target operator for verification.

[0008] Based on the above technical solution, preferably, the calculating the computing power utilization and performance sensitivity of the target operator based on the execution time specifically includes: Calculating a computing power utilization rate of the target operator based on the execution time and a theoretical computing complexity of the target operator, wherein the theoretical computing complexity is calculated according to an input tensor dimension and a computing type of the target operator; Based on the changing trend of the execution time proportion of the target operator under different input tensor scales and concurrent running conditions, a performance response model of the target operator is fitted and constructed, and the response coefficient of the changing trend to the change in the execution time of the overall graph is calculated. The response coefficient is defined as the performance sensitivity.

[0009] Based on the above technical solution, preferably, for each target operator in the set of independent operator types, a minimum executable network structure including the target operator is constructed in the MindSpore framework, and verification is performed on whether the target operator can be successfully recognized by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation, which specifically includes: For the target operator, based on the input tensor type and output tensor type, construct a test tensor that meets the input and output dimension constraints. The tensor dimension and data type of the test tensor match the operator input requirements of the MindSpore framework. Constructing a single-operator network structure with the target operator as the core, wherein the single-operator network structure includes only one execution node, the input of the execution node is the test tensor, and the output is the tensor transformation result after executing the target operator; Embed the single operator network structure into the front-end network construction interface of the MindSpore framework and generate a computational graph using a symbolic graph construction mechanism; Calling the MindSpore graph builder to perform graph-level analysis on the computation graph to determine whether the target operator can be successfully identified by the computation graph construction mechanism; If the target operator can be successfully identified by the computation graph construction mechanism, the front-end network construction interface is called to convert the computation graph into the intermediate representation.

[0010] Based on the above technical solution, preferably, calling the graph compiler of the MindSpore framework to convert the intermediate representation into an underlying execution graph and determining whether the target operator can be parsed by the backend compiler and complete graph-level optimization specifically includes: Calling the entry function of the graph compiler, loading the intermediate representation and binding the backend environment information of the target hardware, wherein the backend environment information includes the device identification, execution memory parameters, parallel granularity parameters and scheduler policy identification of the target hardware; triggering a parsing process of the intermediate representation in the graph compiler, and traversing the structure graph nodes of the intermediate representation layer by layer; According to the operator type, input and output tensors, parameter configuration and data dependency corresponding to the parsed structure graph node, the target operator is mapped to the operator kernel library supported by the backend. If it is determined that the target operator is successfully mapped to the operator kernel library, a graph optimization operation is performed on the graph structure containing the target operator. The graph optimization operation includes operator fusion, redundant calculation elimination, memory reordering and constant folding. During the execution of the graph optimization operation, it is determined whether the target operator participates in fusion, triggers scheduling replacement or kernel selection adjustment, and if the target operator causes graph structure inconsistency during the optimization process, the target operator is identified as a successfully optimized operator.

[0011] Based on the above technical solution, preferably, the target operator is loaded into the MindSpore runtime environment and executed on a specified hardware backend, and the functional output and gradient return of the target operator are verified through input tensors. If the output error is lower than a set tolerance, the target operator is identified as a functionally valid operator, which specifically includes: Load the underlying execution graph containing the target operator into the MindSpore runtime execution engine. Based on the graph node scheduling order, kernel mapping information, and memory allocation structure in the underlying execution graph, initialize the resources required by the target operator and load execution instructions on the specified hardware backend. Construct an input tensor that matches the input requirements of the target operator, where the dimension, data type, and value distribution of the input tensor are consistent with the operator input requirements of the MindSpore framework, and inject the input tensor into the input buffer of the MindSpore runtime execution engine; Calling the MindSpore runtime scheduler to execute the underlying execution graph, completing the forward computation of the target operator through the specified hardware backend to obtain the forward output tensor of the target operator, and completing the reverse computation based on the automatic differentiation mechanism to obtain the gradient tensor of the target operator; Perform an error comparison between the forward output tensor and the corresponding reference output to calculate the maximum error value, and perform an error comparison between the gradient tensor and the reference gradient to calculate the mean square error value; If both the maximum error value and the mean square error value satisfy a tolerance threshold, the target operator is identified as the functionally valid operator.

[0012] Based on the above technical solution, preferably, all graph nodes with explicit computational semantics in the computation graph are uniformly abstracted to extract a set of independent operator types, specifically including: Load the model structure of the target deep learning model and convert the model structure into a static computational graph based on the symbolic graph building interface provided by the MindSpore framework. The static computational graph consists of a set of graph nodes and edges, and each graph node corresponds to a function module with tensor transformation logic. By traversing all graph nodes in the static computation graph, excluding nodes without computation graph definitions used for control flow or auxiliary attributes, the target graph nodes with explicit computation semantics are screened out. The target graph nodes are registered MindSpore operators whose operation types correspond to them, or combined function modules with tensor input and output features. Parse the operator information called by each target graph node, extract the operator type and parameter configuration corresponding to the target graph node, and record them as independent operator instances; For multiple target graph nodes that reference the same operator type but have different parameter configurations, they are classified according to the operator type to remove duplicate statistics caused by parameter differences; After the operator information of all target graph nodes is extracted, deduplication is performed based on the operator type to form an independent operator type set that does not contain duplicate entries.

[0013] In a second aspect of the present application, a MindSpore-based operator processing device is provided. The device is configured to execute any one of the above-described MindSpore-based operator processing methods. The device includes an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to obtain the complete computational graph of the target deep learning model in the inference and training stages, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types; The processing module is configured to construct, for each target operator in the set of independent operator types, a minimum executable network structure including the target operator in the MindSpore framework, verify whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework, and convert the target operator into an intermediate representation; The processing module is used to call the graph compiler of the MindSpore framework, convert the intermediate representation into an underlying execution graph, and determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization; The output module is used to load the target operator into the MindSpore runtime environment and execute it on the specified hardware backend if it is determined that the target operator can be parsed and graph-level optimized by the backend compiler. The functional output and gradient return of the target operator are verified through input tensors. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator.

[0014] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface and a network interface, the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device performs any of the methods described above.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions. When the instructions are executed, any one of the methods described above is executed.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. This application achieves systematic verification and completion of the target operator support in the MindSpore framework by constructing a full-process operator processing mechanism from computational graph parsing, minimum network structure verification, intermediate representation conversion, graph compilation optimization to runtime accuracy verification. It can accurately identify and solve problems such as operators being unable to be recognized in the graph composition stage, kernel mapping failures in the compilation stage, or substandard performance in the runtime stage, ensuring that each target operator has functional consistency and operational stability in all aspects of model construction, graph optimization, and execution scheduling, thereby effectively improving the operator support completeness and execution reliability of the MindSpore framework in large-model training and inference tasks.

[0017] 2. By collecting the execution time of each target operator on different devices and calculating its computing power utilization and performance sensitivity, we can construct a performance characteristic map of the operator in various hardware environments. Combined with the backend execution log, we can analyze the causes of bottlenecks and optimize the execution structure and schedule adjustments for operators with performance anomalies. This will improve the operator execution efficiency and resource utilization of the MindSpore framework in large models, and enhance the controllability and adjustability of the overall training and inference performance.

[0018] 3. By constructing a minimum executable network structure for each target operator and verifying whether it can be successfully constructed and converted into an intermediate representation in MindSpore, we ensure that each target operator has structural legitimacy and semantic identifiability during the static graph construction phase, eliminate problems such as construction failure or operator missing in advance, establish a correct structural foundation for subsequent graph compilation and execution, and enhance the front-end integrity of operator support.

[0019] 4. By loading the intermediate representation and calling the graph compiler to parse the graph nodes and scheduling paths, the target operator is mapped to the backend operator kernel library and graph optimization operations are performed. This ensures that each target operator can be successfully registered, kernel bound, and structurally optimized during the graph compilation phase. It also identifies graph fusion failures or scheduling anomalies, thereby improving the robustness of MindSpore's graph compilation and the optimization space for operator-level execution performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a flowchart of a MindSpore-based operator processing method disclosed in an embodiment of the present application; Figure 2 This is a module diagram of a MindSpore-based operator processing device disclosed in an embodiment of the present application; Figure 3 This is a schematic structural diagram of an electronic device disclosed in an embodiment of the present application.

[0021] Explanation of the reference numerals: 201, acquisition module; 202, processing module; 203, output module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0023] In the description of the embodiments of this application, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a concrete manner.

[0024] In the description of the embodiments of the present application, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0025] MindSpore is a high-performance AI computing framework developed by Huawei for heterogeneous cloud, edge, and device environments. It has core capabilities such as automatic differentiation, graph fusion, and distributed scheduling. It supports multiple hardware platforms and is suitable for the training and deployment of large models. Its operator processing mechanism covers the entire process from operator type extraction, support verification, function completion to performance optimization. It requires that operators not only have API-level callability, but also must maintain semantic consistency and effective execution in all stages such as static graph construction, unified intermediate representation MindIR generation, graph compilation optimization, and device scheduling, ensuring that the model can achieve complete functions, stable performance and efficient operation under the MindSpore framework.

[0026] This embodiment discloses a method for processing operators based on MindSpore. Figure 1 , including the following steps S110-S140: S110, obtain the complete computational graph of the target deep learning model in the inference and training stages, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types.

[0027] The MindSpore-based operator processing method disclosed in the embodiments of this application is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablet computers, wearable devices, and personal computers (PCs), and may also be a backend server running the MindSpore-based operator processing method. The server may be implemented as a standalone server or a server cluster consisting of multiple servers.

[0028] In one possible implementation, all graph nodes with explicit computational semantics in the computational graph are uniformly abstracted to extract a set of independent operator types, specifically including: loading the model structure of the target deep learning model, and converting the model structure into a static computational graph based on the symbolic mapping interface provided by the MindSpore framework, wherein the static computational graph is composed of a set of graph nodes and edges, and each graph node corresponds to a function module with tensor transformation logic; by traversing all graph nodes in the static computational graph, excluding the graph nodes without computational semantics used for control flow or auxiliary attribute definition, and screening out the graph nodes with explicit computational semantics. The target graph node is a MindSpore-registered operation operator or a combination function module with tensor input and output features corresponding to the operation type; the operator information called by each target graph node is parsed, and the operator type and parameter configuration corresponding to the target graph node are extracted and recorded as independent operator instances; for multiple target graph nodes that reference the same operator type but have different parameter configurations, they are classified according to the operator type to remove duplicate statistics caused by parameter differences; after completing the operator information extraction of all the target graph nodes, deduplication is performed based on the operator type to form an independent operator type set that does not contain duplicate entries.

[0029] Specifically, after loading the model structure of the target deep learning model, the symbolic mapping interface provided by the MindSpore framework is called to perform structural analysis of the model. This symbolic mapping interface can automatically convert the dynamic graph structure defined by the user in the Python front-end into a static computational graph. The static computational graph is a directed acyclic graph consisting of a set of graph nodes and graph edges, where graph nodes represent specific computational operations and graph edges represent the paths through which tensors are transferred between nodes. Taking a Transformer encoder with a residual structure as an example, the graph nodes in its static computational graph will represent operations such as matrix multiplication, addition, normalization, and activation functions, and each node will record information about the operation type, input tensors, and output tensors.

[0030] The static computational graph is then traversed, and the graph nodes are visited one by one to identify their functional attributes. The MindSpore graph analysis tool or IR parsing interface is used to exclude control nodes that do not have actual tensor operation behaviors, such as If nodes, While nodes, or auxiliary nodes used to mark attributes such as learning rates, and only those graph nodes with explicit computational semantics are retained. Explicit computational semantics here refers to computational behaviors in which the operations performed by the nodes can produce specific numerical transformations on the input tensors, such as convolution, full connection, activation function, Softmax, normalization, etc. For example, a LayerNorm node in a residual structure has a clear input tensor, mean calculation, standard deviation calculation, and normalized output, and is a target graph node with explicit computational semantics.

[0031] Next, for each selected target graph node, the operator information called within it is parsed. Specifically, the MindSpore Intermediate Representation (MindIR) or Abstract Syntax Tree interface is used to obtain the operator type identifier (such as MatMul, ReLU, LayerNorm, etc.) bound to the graph node, as well as its execution configuration parameters (such as whether to use Bias, activation function type, axis direction, etc.). These parameters jointly determine the operator's behavioral logic. The operator type and parameter configuration parsed for each graph node are combined to form an independent operator instance, which is recorded for subsequent verification.

[0032] If multiple graph nodes call operators of the same type but have different parameter configurations, such as two MatMul nodes with transA=1 and transA=0 respectively, these operators, though inconsistent in terms of parameters, are classified as the same operator type and only the operator type identifier is retained for subsequent processing. This classification can be achieved using a hash deduplication mechanism, where a mapping table is created using operator type as the key and duplicate entries are merged.

[0033] After extracting operator instance information for all target graph nodes, the entire list of extracted operator types is deduplicated to ensure that the final set of operator types contains only unique operator type names. This independent operator type set is the basic operator set that the deep learning model must support during MindSpore operation, and serves as input for operator support verification, compilation testing, and optimization. Taking the aforementioned Transformer model as an example, the final independent operator type set typically includes several core operator types such as MatMul, Add, ReLU, LayerNorm, and Softmax. This set is model-independent and transferable, and can be used to verify the operator capabilities of other large model structures.

[0034] S120: For each target operator in the set of independent operator types, a minimum executable network structure containing the target operator is constructed in the MindSpore framework to verify whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation.

[0035] In one possible implementation, for each target operator in the set of independent operator types, a minimum executable network structure containing the target operator is constructed in the MindSpore framework to verify whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation, specifically including: for the target operator, based on the input tensor type and the output tensor type, constructing a test tensor that meets the input and output dimension constraints, wherein the tensor dimension and data type of the test tensor match the operator input requirements of the MindSpore framework; constructing a single operator with the target operator as the core The network structure of the single operator network structure only includes one execution node, the input of the execution node is the test tensor, and the output is the tensor transformation result after executing the target operator; the single operator network structure is embedded in the front-end network construction interface of the MindSpore framework, and a computational graph is generated using a symbolic graph construction mechanism; the MindSpore graph builder is called to perform graph-level analysis on the computational graph to determine whether the target operator can be successfully identified by the computational graph construction mechanism; if the target operator can be successfully identified by the computational graph construction mechanism, the front-end network construction interface is called to convert the computational graph into the intermediate representation.

[0036] Specifically, first, for the target operator, the corresponding input and output tensor types must be obtained based on the operator's registration information in the MindSpore framework. The input tensor type includes the tensor dimension (e.g., 2D, 3D, or 4D), the shape of each dimension (e.g., [64, 128] indicates a batch size of 64 and a feature dimension of 128), and the tensor data type (e.g., float32, int32, etc.). Based on this information, a test tensor is constructed. This test tensor, serving as the operator's input data carrier, must meet the strict tensor structure and data type requirements of MindSpore's execution interface for the target operator. For example, if the target operator is MatMul, its input tensor must be a 2D or 3D tensor with a shape that meets the rules of matrix multiplication. For example, if the input tensors have shapes [32, 64] and [64, 128], the output shape should be [32, 128], and the data type must be uniformly float32.

[0037] After constructing the test tensor, a minimized single-operator network structure is constructed with the target operator as the core. The single-operator network structure contains only one execution node. The operation type of the execution node corresponds to the target operator type. Its input is the test tensor constructed above, and its output is the result tensor after the tensor is transformed by the target operator. It does not contain other intermediate calculation logic or auxiliary modules. This single-operator network structure is used to isolate the calculation path that the target operator depends on, so as to accurately verify whether its composition and execution logic are correct. For example, for the Softmax operator, a tensor with input shape = [32,100] can be constructed, and Softmax is applied to the last dimension. The output dimension is the same, but the data is normalized to the range of 0~1.

[0038] The single-operator network structure is embedded in the MindSpore front-end network construction interface, and its symbolic mapping mechanism is called to generate a computational graph. The symbolic mapping mechanism refers to the process in MindSpore used to convert the network structure defined by the user in Python code into an internal graph structure. The generated computational graph is a static graph structure, in which the graph nodes are operator call instances and the graph edges are tensor flow paths.

[0039] Subsequently, the MindSpore graph builder is invoked to perform graph-level parsing on the computational graph to determine whether the execution nodes can be successfully identified as the target operator type registered in MindSpore. This process includes node type verification, tensor dimension inference, and parameter configuration validity checks to ensure that the target operator is not marked as an illegal or unknown node during the graph construction phase. If the execution node is successfully parsed during the graph construction process, it indicates that the target operator has front-end build support in the current version of the MindSpore framework.

[0040] If the target operator is confirmed to be successfully recognized by the MindSpore graph construction mechanism, the MindSpore front-end interface is called to convert the computational graph into a unified intermediate representation, MindIR. MindIR is the intermediate format used in the MindSpore framework to uniformly describe model structures. It records the operator type, input and output tensor structure, and parameter configuration of each graph node, and is the core representation structure of MindSpore during graph compilation, graph optimization, and backend execution. The resulting MindIR file serves as input for subsequent graph compilation and execution verification, enabling complete parsing and semantic expression verification of the target operator during the static graph construction phase.

[0041] S130 calls the graph compiler of the MindSpore framework to convert the intermediate representation into the underlying execution graph, and determines whether the target operator can be parsed by the backend compiler and complete graph-level optimization.

[0042] In a possible implementation, the graph compiler of the MindSpore framework is called to convert the intermediate representation into a bottom-level execution graph, and to determine whether the target operator can be parsed by the back-end compiler and complete graph-level optimization, specifically including: calling the entry function of the graph compiler, loading the intermediate representation and binding the back-end environment information of the target hardware, the back-end environment information including the device identification, execution memory parameters, parallel granularity parameters and scheduler strategy identification of the target hardware; triggering the parsing process of the intermediate representation in the graph compiler, traversing the structure graph nodes of the intermediate representation layer by layer; The operator type, input and output tensors, parameter configuration and data dependency corresponding to the graph node are used to map the target operator to the operator kernel library supported by the backend. If it is determined that the target operator is successfully mapped to the operator kernel library, a graph optimization operation is performed on the graph structure containing the target operator. The graph optimization operation includes operator fusion, redundant calculation elimination, memory reordering and constant folding. During the execution of the graph optimization operation, it is determined whether the target operator participates in the fusion, whether the scheduling replacement or kernel selection adjustment is triggered, and if the target operator causes graph structure inconsistency during the optimization process, the target operator is identified as a successfully optimized operator.

[0043] Specifically, the MindSpore framework's graph compiler entry point function is first called to load the model structure that has been built and converted into a unified intermediate representation (UIR). This UIR is a static graph structure in the MindIR format, containing the complete graph node topology, operator types, tensor edge information, and parameter configuration data. While loading the MindIR file, the target hardware's backend environment information must be bound. This backend environment information guides the graph compiler in selecting the appropriate device execution path. This backend environment information includes the device identifier (e.g., Ascend 910, GPU, or CPU), execution memory parameters (e.g., memory limits, cache page size), parallel granularity parameters (e.g., number of threads, tensor splitting strategy), and scheduler policy identifiers (e.g., priority scheduling, streaming scheduling, or tensor fusion strategy). This ensures that the graph compiler's optimization behavior conforms to the resource constraints and compute characteristics of the target hardware platform. For example, on Ascend devices, the Ascend operator scheduling mode and L1 cache policy must be explicitly configured.

[0044] The parsing process of the intermediate representation is triggered in the graph compiler, that is, each graph node is read from the MindIR structure graph and traversed layer by layer to extract the operator type identification, input and output tensor dimensions, data types, parameter configurations and edge dependency information between graph nodes in the graph nodes. This process is the syntax parsing and structural analysis stage of the graph structure, which is used to establish the position relationship of each operator in the graph and initialize the data structures required for subsequent kernel mapping and scheduling path construction. For example, for a graph structure containing MatMul and ReLU, the traversal order will first parse the MatMul node, record its input tensor and output tensor information, then parse the ReLU node, and establish a dependency edge in which its input tensor depends on the MatMul output tensor.

[0045] Based on the above analysis results, the target operator type bound to each graph node is searched in the operator kernel library registered with the MindSpore backend. This operator kernel library contains operator implementations supported by specific devices, including kernel call instructions, tensor layout rules, and concurrent scheduling mechanisms. If the target operator has a corresponding implementation in the backend operator kernel library and the input and output tensors and parameter configurations are correctly matched, the target operator is considered to have been successfully mapped to the backend execution path. If the mapping fails (for example, the input tensor dimensions do not meet the backend operator requirements or the data type is unsupported), the process is exited and the target operator is marked as uncompilable.

[0046] After confirming the successful mapping of the target operator, graph optimization operations are performed on the graph structure containing the target operator. Graph optimization is the core stage of the MindSpore graph compiler and includes multiple optimization submodules, primarily including operator fusion, redundant computation elimination, memory reordering, and constant folding. Operator fusion combines multiple adjacent graph nodes (such as MatMul and BiasAdd) into a composite kernel to reduce memory access overhead and scheduling latency. Redundant computation elimination analyzes the usage paths of graph node output tensors, identifies intermediate computations that are not called by subsequent nodes, and prunes them. Memory reordering optimizes the in-memory layout of tensors based on their read and write patterns. Constant folding pre-calculates constant expressions in the graph to reduce runtime overhead.

[0047] During the execution of the above-mentioned graph optimization operations, it is determined in real time whether the target operator participates in the operator fusion process and whether the scheduling path reconstruction or reselection of the kernel call instruction is triggered. For example, when the target operator is ReLU and its predecessor node is Conv2D, the compiler can fuse the two into the FusedConvRelu kernel. If this fusion is successful, it is recorded as the target operator participating in the fusion; if the number of input and output edges of the graph nodes changes or the operator execution logic changes during the fusion process, it is further determined whether the target operator causes graph structural inconsistency (such as a broken data dependency chain or a topological closed loop error). If no structural inconsistency is caused and the fusion or scheduling replacement operation is successfully applied to the graph structure, the target operator is identified as a successfully optimized operator, and the corresponding execution path information and kernel instruction template before and after the optimization are recorded for subsequent scheduling verification phase calls.

[0048] S140: If it is determined that the target operator can be parsed by the back-end compiler and complete graph-level optimization, the target operator is loaded into the MindSpore runtime environment and executed on the specified hardware backend. The functional output and gradient return of the target operator are verified through the input tensor. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator.

[0049] In one possible implementation, the target operator is loaded into the MindSpore runtime environment and executed on a specified hardware backend, and the functional output and gradient return of the target operator are verified through input tensors. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator. Specifically, the following steps are performed: loading the underlying execution graph containing the target operator into the MindSpore runtime execution engine, completing the initialization and execution instruction loading of the resources required by the target operator on the specified hardware backend according to the graph node scheduling order, kernel mapping information and memory allocation structure in the underlying execution graph; constructing an input tensor that matches the input requirements of the target operator, and the dimension, data type and value distribution of the input tensor are consistent with the M The operator input requirements of the MindSpore framework are consistent, and the input tensor is injected into the input buffer of the MindSpore runtime execution engine; the MindSpore runtime scheduler is called to execute the underlying execution graph, and the forward calculation of the target operator is completed through the specified hardware backend to obtain the forward output tensor of the target operator, and the reverse calculation is completed based on the automatic differentiation mechanism to obtain the gradient tensor of the target operator; the forward output tensor is compared with the corresponding reference output to calculate the maximum error value, and the gradient tensor is compared with the reference gradient to calculate the mean square error value; if the maximum error value and the mean square error value both meet the tolerance threshold, the target operator is identified as the functionally valid operator.

[0050] Specifically, the underlying execution graph containing the target operator is loaded into the MindSpore runtime execution engine. The underlying execution graph is an executable graph structure generated through the graph construction and graph compilation phases, and includes the graph node scheduling order, kernel mapping information, and memory allocation structure. The runtime execution engine determines the execution order of each graph node based on the graph node scheduling order, i.e., the topological sorting result; selects the specific backend operator implementation template based on the kernel mapping information; and completes the static or dynamic allocation of tensor buffers based on the memory allocation structure. On a designated hardware backend, such as an Ascend chip or GPU device, the runtime engine loads the kernel functions, tensor buffer space, and intermediate variable structures required by the target operator into the target device through the driver interface and completes the initialization of the execution context, such as instruction cache preheating and L2 data preloading.

[0051] Then, based on the target operator's interface definition, an input tensor is constructed that matches its input requirements. This input tensor must meet the input dimension structure, data type, and data layout requirements declared by the target operator. For example, for a Conv2D operator, the input tensor should be a four-dimensional tensor, typically with a shape format of [batch_size, channel, height, width] and a data type of float32. If the target operator has multiple input ports (such as the AddN operator), a separate input tensor must be constructed for each input port. Furthermore, to ensure numerical stability, the numerical distribution should be set to conform to the range of values ​​that the operator may encounter during normal model training, such as a normally distributed tensor with a mean of 0 and a standard deviation of 1. Once constructed, the input tensor is injected into the MindSpore runtime execution engine's input buffer. This buffer is a tensor storage area maintained by the runtime engine for graph node execution, ensuring readability and alignment of the input data during backend device scheduling.

[0052] Next, the MindSpore runtime scheduler is called to initiate the execution of the underlying execution graph. The scheduler sequentially calls the kernel instructions bound to the target operator based on the order in which the graph nodes are scheduled, completes the forward computation of the tensor through the backend hardware, and outputs the corresponding forward output tensor. After the forward computation is complete, the MindSpore automatic differentiation mechanism (AutoGrad) is called to perform backpropagation on the target operator, automatically constructing the gradient flow graph and calling the corresponding gradient operator (such as GradReLU, GradMatMul, etc.) for reverse computation to generate the output gradient tensor. The automatic differentiation mechanism relies on the computational trajectories and tensor dependencies in the graph structure to ensure that the generated gradient tensor has the same dimensional structure and mathematical relationship as the forward output.

[0053] After calculating the forward output tensor and gradient tensor, they are compared against the preset reference output for error. The forward output error comparison uses the maximum error (Max Error) as a metric, calculating the element-by-element difference between the predicted output and the reference output and taking the maximum absolute value to assess output stability. The gradient error comparison uses the mean squared error (MSE) as a metric, calculating the mean squared difference between the predicted gradient and the reference gradient to assess the accuracy of the backpropagation results. These two error metrics together constitute the numerical accuracy verification criteria for the target operator.

[0054] If both the maximum error and mean square error values ​​are less than the preset tolerance thresholds, the maximum error is less than the preset first tolerance threshold, the mean square error is less than the preset second tolerance threshold, and no exceptions occur during graph execution (such as segmentation faults, kernel overflows, or data out-of-bounds), the target operator is identified as a functionally valid operator, indicating that it has the triple guarantee capabilities of graph construction, graph execution, and numerical correctness in the current MindSpore version. If any metric fails to meet the requirements, the target operator function is determined to not meet the verification criteria, and further analysis is required for operator implementation logic, kernel accuracy, or numerical stability issues. This verification process ensures that the functional support of each target operator in MindSpore is not only reflected at the API interface level, but is fully confirmed through actual execution paths and accuracy results.

[0055] In one possible implementation, after verifying the functional output and gradient return of the target operator through the input tensor, the method further includes: collecting the execution time of each target operator on different devices; calculating the computing power utilization and performance sensitivity of the target operator based on the execution time; constructing a performance bottleneck map of the target operator based on the computing power utilization and performance sensitivity; correlating the performance bottleneck map with the MindSpore backend execution log to identify bottleneck factors affecting the performance of the target operator, wherein the bottleneck factors include memory bandwidth limitations, operator fusion failures, scheduling delays, or line Process concurrency conflict; for the target operator identified as having performance abnormality in the performance bottleneck graph, call the operator-level optimization interface provided by the MindSpore graph optimizer, perform optimization operations to generate an optimized execution path for the target operator, and the optimization operations include operator fusion reconstruction, memory access mode rearrangement, instruction-level parallelism adjustment, and scheduling priority reordering; write the optimized execution path into the location of the target operator in the underlying execution graph to form an updated underlying execution graph structure, and reload it into the MindSpore runtime environment to obtain the optimized output tensor and optimized gradient tensor of the optimized target operator for verification.

[0056] Specifically, first, after completing the functional output and gradient backpropagation verification of the target operator, the runtime performance monitoring module integrated in the MindSpore framework is called to collect the actual execution time of the target operator on different hardware devices. The execution time refers to the total number of clock cycles that the target operator experiences from kernel startup to result output in a single graph scheduling, usually measured in milliseconds (ms). The collection method includes inserting profiling markers into the underlying execution graph and capturing the start and end timestamps of the target operator execution phase through hardware-level performance counters. Optionally, NVIDIA CUPTI is used on the GPU, the Ascend Profiling API is used on Ascend devices, and the runtime profiler interface of MindSpore is used to complete data aggregation. This process can be repeated multiple times to obtain the average execution time, eliminating the interference of environmental fluctuations on the measurement.

[0057] Subsequently, based on the collected execution time data, the target operator's computing power utilization and performance sensitivity are calculated. Computing power utilization refers to the ratio of the target operator's theoretical computing load to its actual execution time. The theoretical computing load is derived based on the operator's input tensor dimensions, data type, and operator arithmetic complexity. Performance sensitivity is calculated by constructing an elasticity coefficient of the operator's execution time to the overall execution time of the model. This involves measuring the response relationship between changes in the target operator's execution time and changes in the full graph's runtime under different input scales or scheduling densities. Regression fitting or principal component analysis methods are often used to model the performance impact of the target operator in the entire model execution path.

[0058] In one possible implementation, the computing power utilization and performance sensitivity of the target operator are calculated based on the execution time, specifically including: calculating the computing power utilization of the target operator based on the execution time and the theoretical computing complexity of the target operator, the theoretical computing complexity is calculated according to the input tensor dimension and operation type of the target operator, and the computing power utilization is the ratio of the theoretical computing complexity to the actual execution time; based on the changing trend of the execution time proportion of the target operator under different input tensor scales and concurrent running conditions, a performance response model of the target operator is fitted and constructed, and the response coefficient of the changing trend to the change in the execution time of the overall graph is calculated, and the response coefficient is defined as the performance sensitivity.

[0059] Specifically, to calculate the computing power utilization based on the execution time of the target operator and its theoretical computational complexity, the theoretical computational complexity of the target operator must be determined first. Theoretical computational complexity refers to the total amount of basic mathematical operations that the target operator needs to complete under ideal conditions without considering hardware bandwidth, memory access latency, and thread scheduling costs. It is usually measured in floating-point operations (FLOPs). The theoretical computational complexity is determined by the dimensional information and operation type of the input tensor. For a two-dimensional matrix multiplication operator MatMul, whose input tensors are matrices of dimensions [M×K] and [K×N] respectively, the number of basic multiplication and addition operations is expanded to a joint expression that includes tensor access cost, computational parallelism impact, and memory access reordering overhead: Where: α is the computational density weighting factor, which accounts for the hardware's FMA (fused multiply-add) capability. β is the tensor access cost coefficient, which captures the overhead of intermediate storage and load operations. γ is the memory access path reordering factor, reflecting the scheduling cost within the cache hierarchy. M, K, and N are the input tensor dimensions, corresponding to the row and column dimensions in matrix multiplication scenarios. The coefficient of 2 indicates that each multiply-add operation consists of one multiplication and one addition.

[0060] This formula quantifies the total computational cost of the target operator under ideal execution conditions, taking into account various sources of overhead, including multiplication-add operations, tensor accesses, and memory scheduling. The first term, 2•M•K•N, represents the number of basic floating-point operations required to complete all multiplications and additions in a matrix multiplication operation. The coefficient 2 indicates that each multiplication-add consists of one multiplication and one addition. Multiplying this term by α reflects the utilization efficiency of the FMA (fused multiply-add) units in different hardware. For example, on devices that support the FMA instruction set, α < 1 indicates a merging speedup. The second term, β•(M•N), represents the tensor store and load burden imposed by write operations on the output tensor. The coefficient β measures the cost of memory accesses in the overall computation. The third term, γ•log_2(K), represents the cost of memory path reordering, particularly when the input dimension is large, due to the additional overhead incurred by tensor pruning, permutation, and alignment within the cache hierarchy. γ is the weight by which this memory access overhead is mapped across different architectures. Overall, this complex expression extends the traditional FLOPs model by introducing structural factors, providing a more realistic assessment of computational load.

[0061] The actual execution time of the target operator is provided by the MindSpore runtime performance monitoring module. Furthermore, the computational power utilization is expressed in a complex form as follows: in: is the actual execution time of the target operator, Indicates the device idle time caused by memory access conflicts or load waits. represents the scheduling overhead of synchronization between threads or devices, Idle delay caused by thread load imbalance, They are the corresponding weighted scheduling coefficients, which are set according to the device architecture and thread model.

[0062] This formula measures the efficiency of the target operator in utilizing computing resources in the actual operating environment, which is the ratio between the theoretical computing load and the total cost of the actual execution time. This is the main timeline for actually running the operator on the hardware. However, due to many non-ideal factors in modern computing platforms, such as memory access waits and thread blocking, three time compensation terms need to be introduced: Indicates the device pause time due to memory access conflicts or insufficient bandwidth, which is common in deep models with a large amount of random memory access; This is the synchronization wait time between operators, threads, or devices, which is particularly significant in multi-threaded or distributed scenarios; The three compensation items are multiplied by the architecture-related weighting coefficients. , reflecting their proportion on different platforms, forming the weighted total execution time. The physical significance of the entire fractional structure is that the numerator is the computing power requirement, and the denominator is the actual running cost. The larger the ratio, the more efficient the resource utilization, and the closer the operator execution in MindSpore is to the hardware limit.

[0063] The linear sensitivity is extended to a curvature index based on a high-order derivative response function, introducing multi-dimensional input perturbations and local extreme value features: Where S represents the input tensor scale perturbation variable (e.g., number of elements, number of channels, or sequence length), P represents the concurrency perturbation variable (e.g., number of threads, parallel batches), the first term is the second-order derivative of the proportional change in execution time under input perturbation, reflecting curvature or nonlinear acceleration characteristics, the second term is the square of the first-order response under concurrency perturbation, measuring the impact of the parallel strategy on performance fluctuations, and η is the concurrency impact weight, which adjusts the sensitivity measure to the parallel structure. Through high-order derivatives and combined perturbation analysis, this sensitivity expression can identify potential bottleneck operators with nonlinear scaling characteristics and reveal areas of performance instability during large-scale operations.

[0064] This formula measures the responsiveness of the target operator's runtime to perturbations in input scale and concurrency parameters, specifically, the degree to which its performance fluctuates with changes in input and scheduling conditions. The first term, the curvature of the performance response under input perturbations, captures nonlinear growth characteristics by taking the second-order derivative of the execution time ratio function with respect to the input tensor scale variable S. For example, in multidimensional convolutions and long-sequence Transformers, operator execution time increases exponentially after the input dimension reaches a certain critical point. This term reveals this high-order scaling behavior. The second term, the sensitivity under concurrency policy perturbations, indicates how the execution time proportion of the target operator changes when adjusting scheduling parameters P such as the number of threads, parallel batches, and tensor splitting method. The square of its first-order derivative represents the absolute magnitude of the change, amplifying the sudden change. η is the concurrency impact weight, which adjusts its contribution to the overall sensitivity to accommodate differences in scheduling models across different platforms. Combining these two terms, performance sensitivity can be used to identify bottleneck operators that are highly sensitive to input scale or thread configuration, guiding subsequent local graph structure reconstruction, scheduling policy optimization, or operator kernel replacement.

[0065] After obtaining the two performance metrics above, a performance bottleneck graph is constructed with the target operator as the node. This graph uses a graph structure to represent the performance impact path of each target operator during model execution. Graph nodes represent target operators, and graph edges represent dependencies between operators. Each graph node is assigned computing power utilization and performance sensitivity attributes, and bottleneck operators are highlighted in the graph (e.g., those with utilization below 30% or sensitivity greater than 0.7). The bottleneck graph structure can be used for visual analysis, helping to prioritize operator optimization and forming the basis for performance improvement strategies.

[0066] Subsequently, the performance bottleneck graph was correlated with the MindSpore backend execution log for analysis. The backend execution log contains runtime behavior information such as the scheduling status of each graph node, memory read and write logs, scheduler latency, and thread blocking. By comparing the target operators identified as having performance anomalies in the graph with their specific runtime behavior in the execution log, the causes of performance bottlenecks were extracted. Common bottleneck factors include: ① Memory bandwidth limitations—operators access large amounts of data and discontinuous memory access patterns, leading to bandwidth bottlenecks; ② Operator fusion failures—adjacent operators are not fused due to inconsistent data types or unsatisfied boundary conditions, increasing the scheduling load; ③ Scheduling delays—target operators wait in the scheduler for a long time and are not prioritized; and ④ Thread concurrency conflicts—operators compete fiercely for thread resources, leading to frequent context switches.

[0067] For the target operators identified as having abnormal performance in the bottleneck graph, the operator-level optimization interface provided by the MindSpore graph optimizer is called to perform optimization operations. These include: ① Operator fusion reconstruction—redefining the data boundaries and fusion strategies between the target operator and the preceding and following operators, merging multiple graph nodes into a unified kernel, such as refactoring MatMul and BiasAdd into FusedMatMul; ② Memory access pattern rearrangement—optimizing data alignment by changing the tensor storage order or adjusting the tile strategy to improve memory access efficiency; ③ Instruction-level parallelism adjustment—changing the kernel's thread granularity configuration, vectorization strategy, or pipeline depth to increase execution concurrency; and ④ Scheduling priority reordering—modifying the scheduling order in the execution graph to improve the scheduling response speed of the target operator in the critical path.

[0068] After the optimization operation is complete, the optimized execution path of the target operator is written to the original location of the underlying execution graph, replacing the old graph structure and generating an updated underlying execution graph structure. This structure retains the original graph node numbering and dependency relationships, ensuring that the optimized graph structure is functionally equivalent to the original graph structure. The updated underlying execution graph is then reloaded into the MindSpore runtime environment, and the operators under the optimized path are executed to obtain the optimized output tensors and gradient tensors.

[0069] Finally, the optimized output tensor and gradient tensor are verified against their original reference values, and the maximum error and mean square error comparison process is repeated to ensure that the optimization operation improves execution efficiency while not introducing numerical bias. If the error still meets the set tolerance threshold, the target operator is successfully optimized, its status flag is updated, and performance comparison data before and after optimization is recorded, forming a complete optimization feedback loop. This process implements a closed-loop optimization path from performance bottleneck identification, optimization solution execution, to functional consistency verification, improving the operational efficiency and system stability of the target operator within the MindSpore framework.

[0070] This embodiment also discloses an operator processing device based on MindSpore, referring to Figure 2 , comprising an acquisition module 201, a processing module 202, and an output module 203, the device is configured to execute any one of the above-mentioned MindSpore-based operator processing methods, wherein: The acquisition module 201 is used to obtain the complete computational graph of the target deep learning model in the reasoning and training stages, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types.

[0071] Processing module 202 is used to construct a minimum executable network structure containing the target operator in the MindSpore framework for each target operator in the independent operator type set, verify whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework, and convert it into an intermediate representation.

[0072] Processing module 202 is used to call the graph compiler of the MindSpore framework, convert the intermediate representation into the underlying execution graph, and determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization.

[0073] Output module 203 is used to load the target operator into the MindSpore runtime environment and execute it on the specified hardware backend if it is determined that the target operator can be parsed and graph-level optimized by the backend compiler. The functional output and gradient return of the target operator are verified through input tensors. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator.

[0074] In a possible implementation, the acquisition module 201 is configured to collect the execution time of each target operator on different devices.

[0075] The processing module 202 is configured to calculate the computing power utilization and performance sensitivity of the target operator based on the execution time.

[0076] The output module 203 is used to construct a performance bottleneck map of the target operator based on computing power utilization and performance sensitivity.

[0077] Processing module 202 is used to correlate and analyze the performance bottleneck map with the MindSpore backend execution log to identify bottleneck factors affecting the performance of the target operator. Bottleneck factors include memory bandwidth limitations, operator fusion failures, scheduling delays, or thread concurrency conflicts.

[0078] Processing module 202 is used to call the operator-level optimization interface provided by the MindSpore graph optimizer for the target operator identified as having performance anomalies in the performance bottleneck graph, perform optimization operations to generate an optimized execution path for the target operator, and the optimization operations include operator fusion reconstruction, memory access mode rearrangement, instruction-level parallelism adjustment, and scheduling priority reordering.

[0079] Output module 203 is used to write the optimized execution path to the location of the target operator in the underlying execution graph to form an updated underlying execution graph structure, and reload it into the MindSpore runtime environment to obtain the optimized output tensor and optimized gradient tensor of the optimized target operator for verification.

[0080] In one possible implementation, the processing module 202 is configured to calculate the computing power utilization of the target operator based on the execution time and the theoretical computing complexity of the target operator, where the theoretical computing complexity is calculated according to the input tensor dimension and operation type of the target operator.

[0081] Processing module 202 is used to fit and construct a performance response model of the target operator based on the changing trend of the execution time proportion of the target operator under different input tensor scales and concurrent running conditions, calculate the response coefficient of the changing trend to the change in the execution time of the overall graph, and define the response coefficient as performance sensitivity.

[0082] In one possible implementation, the output module 203 is used to construct a test tensor that satisfies the input and output dimension constraints for the target operator based on the input tensor type and the output tensor type. The tensor dimension and data type of the test tensor match the operator input requirements of the MindSpore framework.

[0083] The processing module 202 is used to construct a single-operator network structure with the target operator as the core. The single-operator network structure only includes one execution node. The input of the execution node is the test tensor, and the output is the tensor transformation result after executing the target operator.

[0084] The processing module 202 is used to embed the single operator network structure into the front-end network construction interface of the MindSpore framework and generate a computational graph using a symbolic graph construction mechanism.

[0085] The processing module 202 is used to call the MindSpore graph builder to perform graph-level analysis on the computation graph and determine whether the target operator can be successfully identified by the computation graph construction mechanism.

[0086] The processing module 202 is used to call the front-end network construction interface to convert the computation graph into an intermediate representation if the target operator can be successfully identified by the computation graph construction mechanism.

[0087] In one possible implementation, the entry function of the graph compiler is called to load the intermediate representation and bind the backend environment information of the target hardware. The backend environment information includes the device identification, execution memory parameters, parallel granularity parameters and scheduler policy identification of the target hardware.

[0088] The processing module 202 is used to trigger the intermediate representation parsing process in the graph compiler and traverse the structure graph nodes of the intermediate representation layer by layer.

[0089] Processing module 202 is used to map the target operator to the operator kernel library supported by the backend according to the operator type, input and output tensors, parameter configuration and data dependency corresponding to the parsed structure graph node. If it is determined that the target operator is successfully mapped to the operator kernel library, a graph optimization operation is performed on the graph structure containing the target operator. The graph optimization operation includes operator fusion, redundant calculation elimination, memory reordering and constant folding.

[0090] Processing module 202 is used to determine whether the target operator participates in fusion, triggers scheduling replacement or kernel selection adjustment during the execution of the graph optimization operation. If the target operator causes graph structure inconsistency during the optimization process, the target operator is marked as a successfully optimized operator.

[0091] In one possible implementation, processing module 202 is used to load the underlying execution graph containing the target operator into the MindSpore runtime execution engine, and complete the initialization of resources required for the target operator and the loading of execution instructions on the specified hardware backend based on the graph node scheduling order, kernel mapping information, and memory allocation structure in the underlying execution graph.

[0092] Processing module 202 is used to construct an input tensor that matches the input requirements of the target operator. The dimension, data type and value distribution of the input tensor are consistent with the operator input requirements of the MindSpore framework, and inject the input tensor into the input buffer of the MindSpore runtime execution engine.

[0093] Processing module 202 is used to call the MindSpore runtime scheduler to execute the underlying execution graph, complete the forward calculation of the target operator by specifying the hardware backend, obtain the forward output tensor of the target operator, and complete the reverse calculation based on the automatic differentiation mechanism to obtain the gradient tensor of the target operator.

[0094] The processing module 202 is used to perform an error comparison between the forward output tensor and the corresponding reference output to calculate the maximum error value, and to perform an error comparison between the gradient tensor and the reference gradient to calculate the mean square error value.

[0095] The processing module 202 is configured to identify the target operator as a functionally valid operator if both the maximum error value and the mean square error value satisfy a tolerance threshold.

[0096] In one possible implementation, the processing module 202 is used to load the model structure of the target deep learning model and convert the model structure into a static computational graph based on the symbolic mapping interface provided by the MindSpore framework, wherein the static computational graph is composed of a set of graph nodes and edges, and each graph node corresponds to a function module with tensor transformation logic.

[0097] Processing module 202 is used to traverse all graph nodes in the static computation graph, exclude nodes without computation graph definitions used for control flow or auxiliary attributes, and filter out target graph nodes with explicit computation semantics. The target graph nodes are operation types corresponding to registered MindSpore operators or combination function modules with tensor input and output features.

[0098] The processing module 202 is used to parse the operator information called by each target graph node, extract the operator type and parameter configuration corresponding to the target graph node, and record them as independent operator instances.

[0099] The processing module 202 is used to classify multiple target graph nodes that reference the same operator type but have different parameter configurations according to the operator type, and remove duplicate statistics caused by parameter differences.

[0100] The processing module 202 is configured to perform deduplication based on operator types after extracting operator information of all target graph nodes, thereby forming an independent operator type set that does not contain duplicate entries.

[0101] It should be noted that the above embodiments provide devices that implement their functions using only the division of the above functional modules as examples. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0102] This embodiment also discloses an electronic device, referring to Figure 3 The electronic device may include: at least one processor 301 , at least one communication bus 302 , a user interface 303 , a network interface 304 , and at least one memory 305 .

[0103] The communication bus 302 is used to implement the connection and communication between these components.

[0104] The user interface 303 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0105] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0106] The processor 301 may include one or more processing cores. The processor 301 utilizes various interfaces and circuits to connect various components within the server. It executes instructions, programs, code sets, or instruction sets stored in the memory 305, as well as accesses data stored in the memory 305, to perform various server functions and process data. Optionally, the processor 301 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 301 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and application programs. The GPU is responsible for rendering and drawing content displayed on the display screen. The modem handles wireless communications. It is understood that the modem may not be integrated into the processor 301 but implemented as a separate chip.

[0107] The memory 305 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory may include non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned method embodiments, etc. The data storage area may store data involved in the above-mentioned method embodiments, etc. The memory 305 may also optionally be at least one storage device located remotely from the processor 301. The memory 305, as a computer storage medium, may include an operating system, a network communication module, a user interface 303 module, and an application based on the MindSpore operator processing method.

[0108] exist Figure 3In the electronic device shown, user interface 303 is primarily used to provide an input interface for the user and to obtain user input data. Processor 301 can be used to invoke an application stored in memory 305 that contains a MindSpore-based operator processing method. When executed by one or more processors 301, the electronic device executes one or more of the methods described in the aforementioned embodiments.

[0109] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for this application.

[0110] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely schematic, such as the division of units, which is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some service interface, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0112] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0113] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0114] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of this application. The aforementioned memory 305 includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a magnetic disk, or an optical disk.

[0115] The present application also discloses a computer-readable storage medium storing instructions, which, when executed by one or more processors 301 , enable an electronic device to execute one or more methods in the above embodiments.

[0116] The above are merely exemplary embodiments of the present disclosure and are not intended to limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification and the truth of practice, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any variations, uses or adaptations of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not recorded in the present disclosure. The description and examples are to be regarded as exemplary only, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. An operator processing method based on MindSpore, characterized in that: The method comprises: Obtain the complete computational graph of the target deep learning model during the inference and training phases, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types; For each target operator in the set of independent operator types, construct a minimum executable network structure containing the target operator in the MindSpore framework, and verify whether the target operator can be successfully recognized by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation; Call the graph compiler of the MindSpore framework to convert the intermediate representation into the underlying execution graph, and determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization; If it is determined that the target operator can be parsed and graph-level optimized by the back-end compiler, the target operator is loaded into the MindSpore runtime environment and executed on the specified hardware backend. The functional output and gradient return of the target operator are verified through the input tensor. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator.

2. The operator processing method based on MindSpore according to claim 1, characterized in that: After verifying the functional output and gradient return of the target operator through the input tensor, the method further includes: Collecting the execution time of each target operator on different devices; Calculating the computing power utilization and performance sensitivity of the target operator based on the execution time; Constructing a performance bottleneck map of the target operator based on computing power utilization and performance sensitivity; Correlate and analyze the performance bottleneck map with the MindSpore backend execution log to identify bottleneck factors affecting the performance of the target operator, including memory bandwidth limitations, operator fusion failures, scheduling delays, or thread concurrency conflicts. For the target operator identified as having abnormal performance in the performance bottleneck graph, the operator-level optimization interface provided by the MindSpore graph optimizer is called to perform optimization operations to generate an optimized execution path for the target operator. The optimization operations include operator fusion reconstruction, memory access mode rearrangement, instruction-level parallelism adjustment, and scheduling priority reordering. The optimized execution path is written to the location of the target operator in the underlying execution graph to form an updated underlying execution graph structure, and is reloaded into the MindSpore runtime environment to obtain the optimized output tensor and optimized gradient tensor of the optimized target operator for verification.

3. The operator processing method based on MindSpore according to claim 2, characterized in that: Calculating the computing power utilization and performance sensitivity of the target operator based on the execution time specifically includes: Calculating a computing power utilization rate of the target operator based on the execution time and a theoretical computing complexity of the target operator, wherein the theoretical computing complexity is calculated according to an input tensor dimension and a computing type of the target operator; Based on the changing trend of the execution time proportion of the target operator under different input tensor scales and concurrent running conditions, a performance response model of the target operator is fitted and constructed, and the response coefficient of the changing trend to the change in the execution time of the overall graph is calculated. The response coefficient is defined as the performance sensitivity.

4. The operator processing method based on MindSpore according to claim 1, characterized in that: For each target operator in the set of independent operator types, a minimum executable network structure including the target operator is constructed in the MindSpore framework, and verification is performed on whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework and converted into an intermediate representation, specifically including: For the target operator, based on the input tensor type and output tensor type, construct a test tensor that meets the input and output dimension constraints. The tensor dimension and data type of the test tensor match the operator input requirements of the MindSpore framework. Constructing a single-operator network structure with the target operator as the core, wherein the single-operator network structure includes only one execution node, the input of the execution node is the test tensor, and the output is the tensor transformation result after executing the target operator; Embed the single operator network structure into the front-end network construction interface of the MindSpore framework and generate a computational graph using a symbolic graph construction mechanism; Calling the MindSpore graph builder to perform graph-level analysis on the computation graph to determine whether the target operator can be successfully identified by the computation graph construction mechanism; If the target operator can be successfully identified by the computation graph construction mechanism, the front-end network construction interface is called to convert the computation graph into the intermediate representation.

5. The operator processing method based on MindSpore according to claim 1, characterized in that: The graph compiler of the MindSpore framework is called to convert the intermediate representation into an underlying execution graph, and to determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization. Specifically, the following steps are performed: Calling the entry function of the graph compiler, loading the intermediate representation and binding the backend environment information of the target hardware, wherein the backend environment information includes the device identification, execution memory parameters, parallel granularity parameters and scheduler policy identification of the target hardware; triggering a parsing process of the intermediate representation in the graph compiler, and traversing the structure graph nodes of the intermediate representation layer by layer; According to the operator type, input and output tensors, parameter configuration and data dependency corresponding to the parsed structure graph node, the target operator is mapped to the operator kernel library supported by the backend. If it is determined that the target operator is successfully mapped to the operator kernel library, a graph optimization operation is performed on the graph structure containing the target operator. The graph optimization operation includes operator fusion, redundant calculation elimination, memory reordering and constant folding. During the execution of the graph optimization operation, it is determined whether the target operator participates in fusion, triggers scheduling replacement or kernel selection adjustment, and if the target operator causes graph structure inconsistency during the optimization process, the target operator is identified as a successfully optimized operator.

6. The operator processing method based on MindSpore according to claim 1, characterized in that: The target operator is loaded into the MindSpore runtime environment and executed on a specified hardware backend. The functional output and gradient return of the target operator are verified through input tensors. If the output error is lower than the set tolerance, the target operator is identified as a functionally valid operator. Specifically, the following steps are performed: Load the underlying execution graph containing the target operator into the MindSpore runtime execution engine. Based on the graph node scheduling order, kernel mapping information, and memory allocation structure in the underlying execution graph, initialize the resources required by the target operator and load execution instructions on the specified hardware backend. Construct an input tensor that matches the input requirements of the target operator, where the dimension, data type, and value distribution of the input tensor are consistent with the operator input requirements of the MindSpore framework, and inject the input tensor into the input buffer of the MindSpore runtime execution engine; Calling the MindSpore runtime scheduler to execute the underlying execution graph, completing the forward computation of the target operator through the specified hardware backend to obtain the forward output tensor of the target operator, and completing the reverse computation based on the automatic differentiation mechanism to obtain the gradient tensor of the target operator; Perform an error comparison between the forward output tensor and the corresponding reference output to calculate the maximum error value, and perform an error comparison between the gradient tensor and the reference gradient to calculate the mean square error value; If both the maximum error value and the mean square error value satisfy a tolerance threshold, the target operator is identified as the functionally valid operator.

7. The operator processing method based on MindSpore according to claim 1, characterized in that: The process of abstracting all graph nodes with explicit computational semantics in the computational graph and extracting a set of independent operator types specifically includes: Load the model structure of the target deep learning model and convert the model structure into a static computational graph based on the symbolic graph building interface provided by the MindSpore framework. The static computational graph consists of a set of graph nodes and edges, and each graph node corresponds to a function module with tensor transformation logic. By traversing all graph nodes in the static computation graph, excluding nodes without computation graph definitions used for control flow or auxiliary attributes, the target graph nodes with explicit computation semantics are screened out. The target graph nodes are registered MindSpore operators whose operation types correspond to them, or combined function modules with tensor input and output features. Parse the operator information called by each target graph node, extract the operator type and parameter configuration corresponding to the target graph node, and record them as independent operator instances; For multiple target graph nodes that reference the same operator type but have different parameter configurations, they are classified according to the operator type to remove duplicate statistics caused by parameter differences; After the operator information of all target graph nodes is extracted, deduplication is performed based on the operator type to form an independent operator type set that does not contain duplicate entries.

8. An operator processing device based on MindSpore, characterized in that: The device is used to execute the operator processing method based on MindSpore according to any one of claims 1 to 7, and the device comprises an acquisition module (201), a processing module (202) and an output module (203), wherein: The acquisition module (201) is used to obtain the complete computational graph of the target deep learning model in the inference and training phases, abstract all graph nodes with explicit computational semantics in the computational graph, and extract a set of independent operator types; The processing module (202) is used to construct a minimum executable network structure containing each target operator in the independent operator type set in the MindSpore framework, verify whether the target operator can be successfully identified by the computational graph construction mechanism of the MindSpore framework, and convert it into an intermediate representation; The processing module (202) is used to call the graph compiler of the MindSpore framework, convert the intermediate representation into an underlying execution graph, and determine whether the target operator can be parsed by the backend compiler and complete graph-level optimization; The output module (203) is used to load the target operator into the MindSpore runtime environment and execute it on the specified hardware backend if it is determined that the target operator can be parsed by the backend compiler and complete graph-level optimization, verify the functional output and gradient return of the target operator through the input tensor, and identify the target operator as a functionally valid operator if the output error is lower than the set tolerance.

9. An electronic device, characterized in that: The electronic device comprises a processor (301), a communication bus (302), a user interface (303), a network interface (304) and a memory (305), wherein the memory (305) is used to store instructions, the user interface (303) and the network interface (304) are both used to communicate with other devices, the communication bus (302) is used to realize connection and communication between components in the electronic device, and the processor (301) is used to execute the instructions stored in the memory (305) so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is executed.

Images