Model deployment processing method and device and electronic equipment

Abstract

The invention discloses a model deployment processing method and device and electronic equipment. Relates to the field of artificial intelligence, and the method comprises the steps that a business model is decomposed into N micro-services, N is an integer greater than or equal to 2, and the N micro-services correspond to different business data processing functions; n micro-service interfaces are defined, and the N micro-service interfaces are in one-to-one correspondence with the N micro-services; and correspondingly deploying the N micro-services and the N micro-service interfaces to the server-free architecture. Through the method and the device, the problems of poor business model deployment flexibility and low resource utilization rate in related technologies are solved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence, and more specifically, to a model deployment processing method, device, and electronic device. Background Art

[0002] Currently, the deployment and reasoning of large deep learning models involve many challenges, mainly as follows: 1) Computing resource requirements. Large models usually have millions or even billions of parameters, resulting in huge computing resource requirements. Especially in the reasoning stage, applications with high real-time requirements require powerful computing capabilities. 2) Model size and memory limitations. Large models take up a lot of storage space and memory, and deployment is difficult when resources are limited; 3) Reasoning delays and poor scalability. In large-scale application scenarios or scenarios with high complexity and large computing volume, it is difficult to meet high concurrency and high performance requirements, and the flexibility is low; 4) Performance monitoring and optimization. After the model is deployed, it is necessary to continuously monitor the performance of the model service to identify and resolve performance bottlenecks.

[0003] Currently, no effective solution has been proposed to address the problems of poor business model deployment flexibility and low resource utilization in related technologies. Summary of the invention

[0004] The main purpose of this application is to provide a model deployment processing method, device and electronic device to solve the problems of poor flexibility and low resource utilization in business model deployment in related technologies.

[0005] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a model deployment processing method is provided. The method includes: decomposing a business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; defining N microservice interfaces, where the N microservice interfaces correspond to the N microservices one by one; and deploying the N microservices and the N microservice interfaces to a serverless architecture.

[0006] Optionally, after deploying N microservices and N microservice interfaces correspondingly to the serverless architecture, the method also includes: obtaining a business processing request, wherein the business processing request carries business data; based on the N microservice interfaces, calling N microservices from the serverless architecture; processing the business processing request based on the N microservices to obtain business prediction results corresponding to the business data.

[0007] Optionally, based on the N microservice interfaces, N microservices are called from the serverless architecture, including: based on an API gateway or a service orchestration tool, the business processing requests are routed to the N microservice interfaces, and the calling order of the N microservice interfaces is determined; based on the N microservice interfaces, N microservices are called from the serverless architecture in the calling order.

[0008] Optionally, in the case where N microservices include a data preprocessing microservice, a feature engineering microservice, and a model reasoning microservice, the business processing request is processed based on the N microservices to obtain a business prediction result corresponding to the business data, including: processing the business data carried in the business processing request based on an instance of the preprocessing microservice to obtain preprocessed data; processing the preprocessed data based on an instance of the feature engineering microservice to obtain feature data; processing the feature data based on an instance of the model reasoning microservice to obtain a business prediction result.

[0009] Optionally, the method also includes: obtaining operation information corresponding to each of the N microservices; detecting whether the N microservices meet predetermined operation conditions and obtaining a detection result; and determining an operation resource adjustment strategy for any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operation conditions.

[0010] Optionally, when the operating information is the calling frequency of a microservice, when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, the operating resources of any microservice are adjusted, including: when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, determining the operating resource adjustment strategy as: increasing the number of instances of any microservice; wherein the predetermined operating condition is that the calling frequency of the microservice is greater than the predetermined frequency.

[0011] Optionally, when the operating information includes at least one of CPU usage, memory usage, and response time, when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, the operating resources of any microservice are adjusted, including: when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, determining the operating resource adjustment strategy as: increasing the computing resources allocated to any microservice; wherein the predetermined operating conditions include at least one of the following: CPU usage is greater than a preset first usage, memory usage is greater than a preset second usage, and the response time is greater than a predetermined time.

[0012] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a model deployment processing device is provided. The device includes: a decomposition module, which is used to decompose the business model into N microservices, wherein N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; a definition module, which is used to define N microservice interfaces, wherein the N microservice interfaces correspond to the N microservices one by one; and a deployment module, which is used to deploy the N microservices and the N microservice interfaces to the serverless architecture.

[0013] Optionally, the device also includes: a first acquisition sub-module, used to obtain a business processing request, wherein the business processing request carries business data; a first calling sub-module, used to call N microservices from a serverless architecture based on N microservice interfaces; and a first processing sub-module, used to process the business processing request based on the N microservices to obtain a business prediction result corresponding to the business data.

[0014] Optionally, the first calling sub-module also includes: a first determining sub-module, used to route business processing requests to N microservice interfaces based on an API gateway or a service orchestration tool, and determine the calling order of the N microservice interfaces; a second calling sub-module, used to call N microservices from the serverless architecture according to the calling order based on the N microservice interfaces.

[0015] Optionally, the second calling sub-module includes: a second processing sub-module, which is used to process the business data carried in the business processing request based on the instance of the preprocessing microservice to obtain preprocessed data; a third processing sub-module, which is used to process the preprocessed data based on the instance of the feature engineering microservice to obtain feature data; and a fourth processing sub-module, which is used to process the feature data based on the instance of the model reasoning microservice to obtain a business prediction result.

[0016] Optionally, the device also includes: a second acquisition submodule, used to obtain operating information corresponding to the N microservices respectively; a first detection submodule, used to detect whether the N microservices meet predetermined operating conditions and obtain detection results; a second determination submodule, used to determine the operating resource adjustment strategy of any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operating conditions.

[0017] Optionally, the second determination submodule includes: a third determination submodule, used to determine the operating resource adjustment strategy as: increasing the number of instances of any microservice when it is detected that any microservice among N microservices does not meet the predetermined operating conditions; wherein the predetermined operating condition is that the calling frequency of the microservice is greater than the predetermined frequency.

[0018] Optionally, the third determination submodule also includes: a fourth determination submodule, which is used to determine the operating resource adjustment strategy as: increasing the computing resources allocated to any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operating conditions; wherein the predetermined operating conditions include at least one of the following: CPU usage is greater than a preset first usage, memory usage is greater than a preset second usage, and response time is greater than a predetermined time.

[0019] In an embodiment of the present application, by decomposing the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; defining N microservice interfaces, where the N microservice interfaces correspond one-to-one to the N microservices; and deploying the N microservices and the N microservice interfaces accordingly to the serverless architecture, the purpose of decomposing the business model into multiple microservices and performing business processing through microservice calls is achieved, thereby achieving the technical effect of improving the flexibility of business model deployment and resource utilization, and further solving the technical problems of poor model deployment flexibility and low resource utilization caused by the overall deployment of the business model. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 A hardware structure block diagram of a computer terminal for implementing a model deployment processing method is shown;

[0022] Figure 2 is a flowchart of a model deployment processing method provided in an embodiment of the present application;

[0023] Figure 3 is a schematic diagram of a model deployment processing device provided according to an embodiment of the present application;

[0024] Figure 4 It is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following explanations:

[0028] Microservices (MS) refers to a software development architecture and design method that decomposes an application into a set of small, independent services, each of which runs in its own process and is usually built around specific business capabilities. These services can communicate with each other through lightweight communication mechanisms. The microservice architecture makes applications easy to expand and maintain because each service can be developed, deployed, and expanded independently. In addition, microservices usually support different programming languages ​​and data storage technologies to meet the specific needs of different services.

[0029] Serverless Architecture means that when building and running applications, developers do not need to worry about the underlying server hardware and operating system, but instead hand over the management of these infrastructures to the cloud service provider.

[0030] Application Programming Interface Gateway (APIGateway) refers to a server that acts as an intermediary between the internal and external APIs of the system. It is mainly responsible for processing API requests from clients and routing them to appropriate backend services. It is also responsible for some key functions such as authentication, authorization, monitoring, logging, current limiting, and cross-domain resource sharing processing. By using an API gateway, the interaction between the client and the backend service can be simplified, and the security and maintainability of the system can be improved.

[0031] The Central Processing Unit (CPU) is the core component of computer hardware, responsible for executing program instructions, processing data and controlling other hardware components of the computer. It is equivalent to the "brain" of the computer and determines the computer's computing speed and processing power. The main functions of the CPU include interpreting and executing program instructions, managing data flow, and communicating with other components of the computer (such as memory, hard disk, etc.).

[0032] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data are in compliance with relevant laws, regulations and standards, necessary confidentiality measures are taken, and public order and good customs are not violated, and corresponding operation entrances are provided for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation entrances for users to choose to agree or refuse the results of automated decision-making; if the user chooses to refuse, the expert decision-making process will be entered.

[0033] Example 1

[0034] According to an embodiment of the present application, a method embodiment of model deployment processing is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0035] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG. 1 shows a hardware structure block diagram of a computer terminal (or mobile device) for implementing a model deployment processing method. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0036] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the model deployment processing method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the above-mentioned model deployment processing method is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0038] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0039] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0040] In the above operating environment, this application provides an optional model deployment processing method. Figure 2: is a flowchart of a model deployment processing method according to Example 1 of the present application. The method comprises the following steps:

[0041] Step S200, decomposing the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions;

[0042] Optionally, when a microservice (such as a feature extraction module) processes a large amount of data, it can obtain more computing resources, while other microservices can reduce resource consumption, thereby improving resource utilization overall. Through model decomposition, each microservice can be independently developed, deployed, and maintained. Part of the business model can be updated or expanded without affecting other parts, which can improve the flexibility and maintainability of the entire model. And under the microservice architecture, the performance of each service can be monitored independently, which makes it easier to locate and solve performance bottlenecks. For example, if it is found that the response time of the feature extraction module is too long, the module can be optimized or its resource allocation can be adjusted in a targeted manner without having to make large-scale modifications to the entire model.

[0043] Optionally, microservices allow each business function module to be upgraded and iterated independently, that is, a part of the business model (such as feature extraction algorithm) can be continuously optimized with technological advances without affecting the stability and performance of other parts.

[0044] Optionally, decompose the large model into multiple functional modules, each module as a separate microservice to implement independent functions. Perform a detailed analysis of the structure and functions of the large model (i.e., business model), determine the division principles of each module, and ensure that the large model is decomposed into multiple independent functional modules, each of which corresponds to a microservice. Each module implements part of the model's functions, such as preprocessing, feature extraction, inference, etc. For example, define a preprocessing module (PreprocessingModule), a feature extraction module (FeatureExtractionModule), and an inference module (InferenceModule), all of which contain independent processing logic.

[0045] It should be noted that the deployment of large models (i.e. business models) is usually limited by hardware resources, especially memory and computing power. Through microservices, different parts of the large model can be deployed on different microservices. Even if the resources of a single instance are limited, the overall needs of the large model can be met through the superposition and dynamic adjustment of instances.

[0046] Optionally, the microservice architecture enables each microservice to respond to requests quickly without waiting for the entire model to complete inference. For example, the preprocessing module can start processing input data immediately and then pass the results to the feature extraction module, which can process data in parallel and reduce the latency of the entire inference.

[0047] Step S202, defining N microservice interfaces, wherein the N microservice interfaces correspond one-to-one to the N microservices;

[0048] Optionally, each microservice interface defines the rules for communicating with the microservice, including input and output parameter types, data formats, calling methods, etc. This ensures that the interaction between microservices is standardized and clear, simplifies the calling process between services, and avoids errors caused by inconsistent data formats or unclear calling methods. For example, the interface of the preprocessing module defines how to receive raw data and return the preprocessed data format, so that the feature extraction module can know how to call the preprocessing module and process the data it returns.

[0049] Among them, the microservice interface serves as an external contract of the service, allowing a microservice to be developed, tested, and deployed independently of other services. That is, if other services change, as long as the interface definition remains unchanged, the current microservice can continue to work without modification.

[0050] Microservice interfaces define how services are called, so that microservices can be called by multiple different applications or services, thereby achieving functional reuse. For example, the feature extraction module can not only be used in the reasoning process of the deep learning model, but can also be called by other applications that require feature extraction, reducing duplication of development and improving development efficiency.

[0051] Optionally, the definition of microservice interfaces makes service testing independent and simple. You can test the functionality of a single microservice first, and then test the interactions between microservices. API gateways or service orchestration tools need to call and combine microservices based on microservice interfaces. Clear interface definitions enable API gateways to route requests more accurately, and service orchestration tools to coordinate interactions between microservices more efficiently, thereby ensuring the smooth operation of the entire system process.

[0052] Among them, the service orchestration tool refers to a tool or platform that manages and controls the interaction process between services in the microservice architecture. It is responsible for combining a series of microservices according to predefined orders and rules to realize the automated execution of complex business processes.

[0053] Optionally, define an independent microservice interface for each model module, that is, define an independent standardized microservice interface for each model module as a microservice, so that it can be called and extended independently. When defining the microservice interface, you can clearly define the input, output, calling method and other information of each microservice interface.

[0054] Step S204, deploying N microservices and N microservice interfaces to the serverless architecture accordingly.

[0055] Optionally, the core advantage of serverless architecture is that it can automatically and dynamically allocate computing resources. When a request arrives, instances are started or added according to the actual needs of the microservice; when requests decrease, resources are automatically reduced to avoid waste of resources. The model of allocating resources on demand can significantly reduce costs compared to fixed server deployment in related technologies, especially for applications with high resource consumption such as deep learning large models.

[0056] Among them, serverless architecture refers to Serverless architecture. In Serverless architecture, each request triggers a new execution instance to ensure that each request can be processed independently and is not affected by other requests. When the model faces high concurrent requests, the Serverless platform will automatically increase the number of instances, thereby improving the system's processing power and response speed, ensuring service stability and user experience.

[0057] Optionally, the Serverless architecture can provide a stateless service execution environment. Developers do not need to worry about the deployment details of the service and can focus more on the business logic. The Serverless platform has built-in monitoring and logging functions, which makes it easy for operation and maintenance personnel to monitor the service status in real time and quickly locate problems. The deployment details of the service can include but are not limited to server configuration, network settings, operating environment, etc.

[0058] It should be noted that each service in the microservice architecture is independent. They can be deployed, scaled, and upgraded independently, which can reduce the mutual impact between services and improve the overall stability and maintainability of the system. When a microservice has a problem, it can be repaired or replaced individually without affecting the normal operation of other microservices. In a serverless environment, microservices can quickly iterate and integrate new technologies because they are independent, and upgrading or replacing a microservice will not have a significant impact on the entire system.

[0059] In an optional embodiment, each microservice is deployed on a Serverless platform to achieve on-demand expansion.

[0060] Optionally, the serverless architecture provides the ability to allocate computing resources on demand, and each microservice is deployed on the serverless platform to achieve on-demand expansion. For example, you can use serverless services such as Amazon Web Services' serverless computing service (AWS Lambda), Microsoft's serverless execution environment (Azure Functions), or Google Cloud Platform's serverless computing service (Google Cloud Functions) to deploy microservice interfaces such as the preprocessing interface PreprocessingService, feature extraction interface FeatureExtractionService, and inference interface InferenceService.

[0061] In an optional embodiment, after deploying N microservices and N microservice interfaces correspondingly to a serverless architecture, the method further includes: obtaining a business processing request, wherein the business processing request carries business data; based on the N microservice interfaces, calling N microservices from the serverless architecture; processing the business processing request based on the N microservices to obtain a business prediction result corresponding to the business data.

[0062] Optionally, this embodiment can ensure that the model can receive business processing requests from clients or upstream services, where the requests carry business data to be processed. In deep learning large model application scenarios, business data may include, but is not limited to, complex data types such as images, voice, and text. By obtaining this data, the business model can start the subsequent microservice call process and pass the data to each microservice for processing. When the business model receives a business processing request, it calls each microservice according to the defined microservice interface, which can ensure that the data can be correctly passed to each microservice according to the preset rules and processes.

[0063] Among them, N microservices are each responsible for different business data processing functions, from preprocessing (such as data cleaning, format conversion, etc.) to feature extraction, and then to the final inference prediction. Each link is an indispensable step in the execution process of the deep learning large model. By gradually passing the business data to these microservices, the computing power of the large model can be used to conduct in-depth analysis and prediction of the business data, and finally generate business prediction results. By defining the microservice interface and calling the microservice based on the interface, the business model can realize the automation and standardization of the business processing flow, reduce the need for manual operation, avoid errors caused by human factors, make the business process easy to audit and repeat, and improve the reliability and consistency of the business process.

[0064] In an optional embodiment, based on N microservice interfaces, N microservices are called from a serverless architecture, including: based on an API gateway or a service orchestration tool, routing business processing requests to the N microservice interfaces, and determining the calling order of the N microservice interfaces; based on the N microservice interfaces, calling N microservices from the serverless architecture in the calling order.

[0065] Optionally, the API gateway or service orchestration tool can identify business processing requests and intelligently distribute the requests to the corresponding microservice interfaces based on the content and purpose of the requests. This routing mechanism ensures that each microservice only receives requests related to its function, avoiding unnecessary resource consumption and improving processing efficiency. For example, in the microservice processing of a large deep learning model, the API gateway can distribute the raw data to the preprocessing microservice interface, then pass the processed data to the feature extraction microservice interface, and finally send the feature data to the inference microservice interface to ensure the consistency and efficiency of the data processing process.

[0066] Optionally, considering that there are dependencies between microservices, the output of the previous microservice is the input of the next microservice. Service orchestration tools can help developers define and manage these sequences, ensuring the correctness and effectiveness of business processes even when models are updated or services are adjusted.

[0067] In an optional embodiment, calls between microservices are coordinated through an API gateway or a service orchestration tool.

[0068] Optionally, there is a close relationship between each microservice interface and the API gateway. The API gateway plays the role of a "front-end bus" in the microservice architecture. It is responsible for routing external requests to the corresponding microservice interfaces. It can also be responsible for formatting, combining or converting the response results of the microservices and returning them to the client.

[0069] Optionally, with the help of service orchestration tools, data consistency assurance and transaction management mechanisms can be designed and implemented. In deep learning applications, data consistency in preprocessing, feature extraction, and reasoning, as well as transaction integrity during multiple microservice calls, can be ensured to prevent data loss or processing errors, and improve the accuracy and reliability of business processing.

[0070] In an optional embodiment, when N microservices include a data preprocessing microservice, a feature engineering microservice, and a model reasoning microservice, the business processing request is processed based on the N microservices to obtain a business prediction result corresponding to the business data, including: processing the business data carried in the business processing request based on an instance of the preprocessing microservice to obtain preprocessed data; processing the preprocessed data based on an instance of the feature engineering microservice to obtain feature data; processing the feature data based on an instance of the model reasoning microservice to obtain a business prediction result.

[0071] Optionally, each microservice can have multiple instances, that is, the number of instances of each microservice is pre-set. When a business processing request comes, the corresponding microservice instance is called to process the request. One business processing request is processed by one microservice instance. By decomposing the large model (i.e., business model) processing flow into three stages: preprocessing, feature engineering, and model reasoning, and each corresponding to a microservice, the modularization of functions can be achieved to ensure the decoupling between services. Each microservice can be developed, tested, and deployed independently without having to care about the details of other services, reducing the overall complexity and development difficulty. In addition, in the Serverless architecture, each microservice instance will be dynamically started and expanded according to the specific needs of processing requests. The preprocessing microservice can quickly expand when facing a large amount of raw data, the feature engineering microservice can also get enough resources when processing complex features, and the model reasoning microservice can automatically increase the number of instances when there are high-concurrency prediction requests. The preprocessing microservice converts raw data into preprocessed data, the feature engineering microservice further converts preprocessed data into feature data, and finally the model inference microservice generates prediction results based on the feature data. This series of operations follows predefined orders and rules, which can reduce the need for human intervention and improve the efficiency and accuracy of process execution. The above on-demand resource allocation method can avoid resource waste, while ensuring that high-quality business prediction results can be provided even under high load, improving resource utilization and system response speed.

[0072] In an optional embodiment, the method further includes: obtaining operation information corresponding to each of the N microservices; detecting whether the N microservices meet predetermined operation conditions and obtaining a detection result; and determining an operation resource adjustment strategy for any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operation conditions.

[0073] Optionally, the running status of each microservice can be monitored in real time by continuously acquiring the running information of the microservice (such as CPU usage, memory usage, response time, etc.). By detecting whether the microservice meets the predetermined running conditions, service anomalies or performance bottlenecks can be discovered and warned in a timely manner. Once a microservice exceeds these conditions, the business model will immediately generate a detection result, prompting that resources need to be adjusted. When it is detected that a microservice does not meet the predetermined running conditions, the running resources of the microservice will be automatically adjusted according to the pre-set strategy. For example, if the CPU usage of the feature extraction service is continuously too high, the CPU or memory resources allocated to the service can be automatically increased, or more service instances can be started to share the load. Among them, the predetermined running conditions can include but are not limited to resource usage upper limits, response time thresholds, etc. The above dynamic adjustment mechanism can ensure efficient use of resources while improving the response speed and processing power of the system. In addition, in the Serverless architecture, resource usage is calculated based on consumption. By dynamically adjusting running resources, resource waste can be avoided, operating costs can be reduced, and sufficient computing power can be ensured when it is most needed, thereby optimizing performance.

[0074] In an optional embodiment, when the operating information is a calling frequency of a microservice, when it is detected that any microservice among N microservices does not meet a predetermined operating condition, the operating resources of any microservice are adjusted, including: when it is detected that any microservice among N microservices does not meet a predetermined operating condition, determining an operating resource adjustment strategy as: increasing the number of instances of any microservice; wherein the predetermined operating condition is that the calling frequency of the microservice is greater than a predetermined frequency.

[0075] Optionally, when the call frequency of any microservice exceeds the preset threshold, it indicates that the microservice is experiencing the pressure of high concurrent requests. At this point, the business model can automatically identify this situation and respond to higher request frequencies by increasing the number of microservice instances. This ensures that the model can respond quickly even during business peaks, avoiding request queuing or delays due to insufficient resources, thereby improving the model's real-time responsiveness and user experience. By monitoring the call frequency and dynamically adjusting the number of instances as needed, the Serverless architecture can achieve refined resource management. When the call frequency is low, fewer service instances will be maintained to reduce resource consumption and reduce costs; when the call frequency surges, instances will be automatically added to ensure sufficient resources and improve processing efficiency.

[0076] Optionally, when the call frequency exceeds a predetermined value, adding microservice instances can disperse the load and reduce the pressure on a single instance, thereby maintaining the stability and consistency of the service. Even in high-concurrency scenarios, it can ensure that each request is processed promptly and accurately, avoiding service performance degradation or failures, and improving business reliability and continuity.

[0077] Optionally, the adjustment strategy is based on the call frequency, which can provide a basis for cost-benefit analysis. The operation and maintenance team can analyze the changes in resource demand at a specific time or business scenario based on the historical data of the call frequency, thereby optimizing the resource allocation strategy, reducing unnecessary expenses, and improving the economic benefits of the microservice business model. In the Serverless architecture, the dynamic adjustment of the number of microservice instances can easily cope with sudden changes in the scale of the business. Whether the demand surges or decreases, it can maintain efficient operation through automatic scaling of resources.

[0078] In an optional embodiment, when the operating information includes at least one of CPU usage, memory usage, and response time, when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, the operating resources of any microservice are adjusted, including: when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, determining the operating resource adjustment strategy as: increasing the computing resources allocated to any microservice; wherein the predetermined operating conditions include at least one of the following: CPU usage is greater than a preset first usage, memory usage is greater than a preset second usage, and the response time is greater than a predetermined time.

[0079] Optionally, when it is detected that the CPU usage exceeds the preset first usage, increasing CPU resources can improve computing power, speed up data processing, and effectively cope with computing-intensive tasks. If the memory usage exceeds the preset second usage, allocating more memory can avoid memory overflow and ensure the continuity and efficiency of data processing, especially for microservices that require a lot of memory reading and writing. If the response time exceeds the predetermined time, a series of resource optimization operations can be triggered, such as increasing CPU and memory resources, or reducing unnecessary calculations by tuning code logic, thereby shortening processing time and improving user experience. By detecting and adjusting resources, system crashes or service unavailability caused by excessive resource use can be avoided, and the stability and reliability of the model can be enhanced. In addition, dynamic resource adjustment can respond to load changes in a timely manner, ensuring that each request can be processed in a timely manner in high-concurrency scenarios, reducing fluctuations in service response time, and improving the consistency of the model's response to external requests.

[0080] As an optional embodiment, the performance of each microservice can be detected in real time, and resource allocation and service calling strategies can be adjusted dynamically.

[0081] Optionally, the Serverless platform can set up a performance detection module to detect the performance of each microservice in real time, collect data such as CPU usage, memory usage, response time, etc. of each microservice, and optimize resource allocation and service call strategies based on the detection results. Monitoring in this mode is more detailed and can more accurately identify performance bottlenecks and solve them in a timely manner.

[0082] It should be noted that the model deployment processing method provided in the embodiment of the present application solves the problem of poor flexibility in business model deployment and low resource utilization in related technologies by decomposing the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; defining N microservice interfaces, where the N microservice interfaces correspond to the N microservices one by one; and deploying the N microservices and the N microservice interfaces to the serverless architecture. This achieves the purpose of decomposing the business model into multiple microservices and performing business processing by calling microservices, thereby achieving the effect of improving the flexibility of business model deployment and resource utilization.

[0083] Based on the above embodiment and optional embodiment, the present invention proposes an optional implementation of a model deployment processing method, which includes:

[0084] S1, model modularization: decompose the large model into multiple functional modules, each module as a separate microservice to implement independent functions.

[0085] Specifically, we analyze the structure and function of the large model in detail, determine the division principle of each module, and ensure that the large model is decomposed into multiple independent functional modules. Each module implements part of the model's functions, such as preprocessing, feature extraction, and reasoning. For example, we define the preprocessing module PreprocessingModule, the feature extraction module FeatureExtractionModule, and the inference module InferenceModule, all of which contain independent processing logic.

[0086] S2, microservice definition: define an independent microservice interface for each model module.

[0087] Specifically, define an independent standardized microservice interface for each model module as a microservice so that it can be called and extended independently. It is necessary to clearly define the input, output, and calling method of each microservice interface. For example, define corresponding microservice interfaces for PreprocessingModule, FeatureExtractionModule, and InferenceModule (sample code).

[0088] S3, Serverless deployment: deploy each microservice on the Serverless platform to achieve on-demand expansion.

[0089] Serverless architecture provides the ability to allocate computing resources on demand. Each microservice is deployed on the Serverless platform to achieve on-demand expansion. For example, you can use Serverless services such as AWS Lambda, Azure Functions, or Google Cloud Functions to deploy microservice interfaces such as PreprocessingService, FeatureExtractionService, and InferenceService.

[0090] S4, service orchestration: coordinate calls between microservices through API gateway or service orchestration tools.

[0091] API gateways or service orchestration tools can be used to coordinate calls between microservices to achieve a complete reasoning process. There is a close relationship between each microservice interface and the API gateway. The API gateway plays the role of a "front-end bus" in the microservice architecture. It is responsible for routing external requests to the corresponding microservice interface, and may also be responsible for formatting, combining or converting the response results of the microservice and returning them to the client.

[0092] S5, performance monitoring and optimization: monitor the performance of each microservice in real time and dynamically adjust resource allocation and service call strategies.

[0093] The Serverless platform can set up a performance detection module to detect the performance of each microservice in real time, collect data such as CPU usage, memory usage, response time, etc. of each microservice, and optimize resource allocation and service call strategies based on the detection results. The detection in this mode is more detailed and can more accurately identify performance bottlenecks and solve them in a timely manner.

[0094] It should be noted that this embodiment can achieve at least one of the following effects: 1) Solve the problem of large model (i.e. business model) deployment and reasoning computing resource requirements, low resource utilization, and limited resources for large model deployment. The Serverless architecture provides the ability to allocate computing resources on demand. By microservice-izing the large model, the resources required for the entire large model are also split, solving the problem of limited resources for large model deployment, thereby improving resource utilization. 2) Solve the problem of large model reasoning delay and poor scalability. By microservice-izing each module and deploying it in a Serverless environment, it can be quickly scaled to meet high concurrency and high performance requirements and improve the flexibility of the system. 3) Performance monitoring and optimization. The deployment method in the relevant technology needs to continuously monitor the performance of the model service after the model is deployed to identify and solve performance bottlenecks. The combination of microservices and Serverless can make detection more refined, identify and locate specific performance bottlenecks, and adjust resources in a timely manner.

[0095] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0096] Example 2

[0097] The embodiment of the present application also provides a model deployment processing device. It should be noted that the model deployment processing device of the embodiment of the present application can be used to execute the model deployment processing method provided by the embodiment of the present application. The model deployment processing device provided by the embodiment of the present application is introduced below.

[0098] According to an embodiment of the present application, a device for implementing the above-mentioned model deployment processing method is also provided, such as Figure 3 As shown, the device includes: a decomposition module 300, used to decompose the business model into N microservices, wherein N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; a definition module 302, connected to the decomposition module 300, used to define N microservice interfaces, wherein the N microservice interfaces correspond one-to-one to the N microservices; a deployment module 304, connected to the definition module 302, used to deploy the N microservices and the N microservice interfaces to the serverless architecture.

[0099] The model deployment processing device provided in the embodiment of the present application is used to decompose the business model into N microservices by setting a decomposition module, wherein N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; a definition module is used to define N microservice interfaces, wherein the N microservice interfaces correspond to the N microservices one by one; and a deployment module is used to deploy the N microservices and the N microservice interfaces to the serverless architecture, thereby solving the problem of poor flexibility in business model deployment and low resource utilization in the related technology. The purpose of decomposing the business model into multiple microservices and performing business processing by calling microservices is achieved, thereby achieving the effect of improving the flexibility of business model deployment and resource utilization.

[0100] Optionally, the model deployment processing device provided in the embodiment of the present application also includes: a first acquisition sub-module, used to obtain a business processing request, wherein the business processing request carries business data; a first calling sub-module, used to call N microservices from a serverless architecture based on N microservice interfaces; and a first processing sub-module, used to process the business processing request based on the N microservices to obtain a business prediction result corresponding to the business data.

[0101] Optionally, in the model deployment processing device provided in the embodiment of the present application, the first calling sub-module also includes: a first determination sub-module, used to route business processing requests to N microservice interfaces based on an API gateway or a service orchestration tool, and determine the calling order of the N microservice interfaces; a second calling sub-module, used to call N microservices from the serverless architecture according to the calling order based on the N microservice interfaces.

[0102] Optionally, in the model deployment processing device provided in the embodiment of the present application, the second calling sub-module includes: a second processing sub-module, which is used to process the business data carried in the business processing request based on the instance of the preprocessing microservice to obtain preprocessed data; a third processing sub-module, which is used to process the preprocessed data based on the instance of the feature engineering microservice to obtain feature data; and a fourth processing sub-module, which is used to process the feature data based on the instance of the model reasoning microservice to obtain a business prediction result.

[0103] Optionally, the model deployment processing device provided in the embodiment of the present application also includes: a second acquisition sub-module, used to obtain the operating information corresponding to the N microservices respectively; a first detection sub-module, used to detect whether the N microservices meet the predetermined operating conditions and obtain the detection results; a second determination sub-module, used to determine the operating resource adjustment strategy of any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operating conditions.

[0104] Optionally, in the model deployment processing device provided in the embodiment of the present application, the second determination submodule includes: a third determination submodule, for determining the operating resource adjustment strategy as: increasing the number of instances of any microservice when it is detected that any microservice among N microservices does not meet the predetermined operating conditions; wherein the predetermined operating condition is that the calling frequency of the microservice is greater than the predetermined frequency.

[0105] Optionally, in the model deployment processing device provided in the embodiment of the present application, the third determination submodule also includes: a fourth determination submodule, which is used to determine the operating resource adjustment strategy as: increasing the computing resources allocated to any microservice when it is detected that any microservice among the N microservices does not meet the predetermined operating conditions; wherein the predetermined operating conditions include at least one of the following: CPU usage is greater than a preset first usage, memory usage is greater than a preset second usage, and response time is greater than a predetermined time.

[0106] It should be noted that the above-mentioned decomposition module 300, definition module 302, and deployment module 304 correspond to steps S200 to S204 in Example 1, and the two modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the contents disclosed in the above-mentioned Example 1. It should be noted that the above-mentioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n), and the above-mentioned modules may also be part of the device and may be run in the computer terminal 10 provided in Example 1.

[0107] Example 3

[0108] An embodiment of the present application may provide an electronic device, Figure 4 is a structural block diagram of an electronic device according to an embodiment of the present application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (only one is shown) processor 1002, memory 1004, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0109] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0110] The processor can call the information and application programs stored in the memory through the transmission device to perform the following steps: decompose the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; define N microservice interfaces, where the N microservice interfaces correspond one-to-one to the N microservices; and deploy the N microservices and the N microservice interfaces to the serverless architecture.

[0111] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: obtain a business processing request, wherein the business processing request carries business data; based on N microservice interfaces, call N microservices from the serverless architecture; based on the N microservices, process the business processing request to obtain a business prediction result corresponding to the business data.

[0112] The processor can also call the information and applications stored in the memory through the transmission device to perform the following steps: based on the API gateway or service orchestration tool, route the business processing request to N microservice interfaces, and determine the calling order of the N microservice interfaces; based on the N microservice interfaces, call N microservices from the serverless architecture according to the calling order.

[0113] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: based on the instance of the preprocessing microservice, the business data carried in the business processing request is processed to obtain preprocessed data; based on the instance of the feature engineering microservice, the preprocessed data is processed to obtain feature data; based on the instance of the model reasoning microservice, the feature data is processed to obtain business prediction results.

[0114] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: obtain the operating information corresponding to the N microservices respectively; detect whether the N microservices meet the predetermined operating conditions and obtain the detection results; when it is detected that any microservice among the N microservices does not meet the predetermined operating conditions, determine the operating resource adjustment strategy of any microservice.

[0115] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, determine the operating resource adjustment strategy as: increase the number of instances of any microservice; wherein the predetermined operating condition is that the calling frequency of the microservice is greater than the predetermined frequency.

[0116] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: when it is detected that any microservice among N microservices does not meet the predetermined operating conditions, determine the operating resource adjustment strategy as: increase the computing resources allocated to any microservice; wherein the predetermined operating conditions include at least one of the following: the CPU usage rate is greater than a preset first usage rate, the memory usage rate is greater than a preset second usage rate, and the response time is greater than a predetermined time.

[0117] By adopting the embodiment of the present application, a solution of a model deployment processing method is provided. By decomposing the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; defining N microservice interfaces, where the N microservice interfaces correspond to the N microservices one by one; deploying the N microservices and the N microservice interfaces to the serverless architecture, the purpose of decomposing the business model into multiple microservices and performing business processing by microservice calls is achieved, thereby achieving the technical effect of improving the flexibility of business model deployment and resource utilization, and thus solving the technical problem of poor model deployment flexibility and low resource utilization caused by the overall deployment of the business model.

[0118] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, or other terminal devices. Figure 4 The structure of the electronic device is not limited. Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 4 Different configurations are shown.

[0119] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0120] Example 4

[0121] The embodiment of the present application also provides a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the model deployment processing method provided in the first embodiment.

[0122] Optionally, in this embodiment, the above storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0123] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the steps of the model deployment processing method.

[0124] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0125] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0126] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, 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 interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0128] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0129] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0130] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A model deployment processing method, characterized in that: include: Decomposing the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; Define N microservice interfaces, wherein the N microservice interfaces correspond one-to-one to the N microservices; Deploy the N microservices and the N microservice interfaces correspondingly to the serverless architecture.

2. The method according to claim 1, characterized in that After deploying the N microservices and the N microservice interfaces to the serverless architecture, the method further includes: Obtaining a business processing request, wherein the business processing request carries business data; Based on the N microservice interfaces, calling the N microservices from the serverless architecture; The business processing request is processed based on the N microservices to obtain a business prediction result corresponding to the business data.

3. The method according to claim 2, characterized in that The calling the N microservices from the serverless architecture based on the N microservice interfaces includes: Based on an API gateway or a service orchestration tool, the business processing request is routed to the N microservice interfaces, and the calling order of the N microservice interfaces is determined; Based on the N microservice interfaces, the N microservices are called from the serverless architecture in the calling order.

4. The method according to claim 3, characterized in that In a case where the N microservices include a data preprocessing microservice, a feature engineering microservice, and a model reasoning microservice, the processing of the business processing request based on the N microservices to obtain a business prediction result corresponding to the business data includes: Processing the business data carried in the business processing request based on the instance of the preprocessing microservice to obtain preprocessed data; Processing the preprocessed data based on the instance of the feature engineering microservice to obtain feature data; The feature data is processed based on an instance of the model reasoning microservice to obtain the business prediction result.

5. The method according to claim 1, characterized in that The method further comprises: Obtaining the operation information corresponding to each of the N microservices; Detect whether the N microservices meet the predetermined operating conditions and obtain the detection result; When it is detected that any microservice among the N microservices does not meet the predetermined operating condition, an operating resource adjustment strategy for the any microservice is determined.

6. The method according to claim 5, characterized in that In the case where the operation information is a call frequency of a microservice, when it is detected that any microservice among the N microservices does not meet the predetermined operation condition, adjusting the operation resources of any microservice includes: When it is detected that any of the N microservices does not meet the predetermined operating condition, the operating resource adjustment strategy is determined to be: increasing the number of instances of any of the microservices; The predetermined operating condition is that the calling frequency of the microservice is greater than a predetermined frequency.

7. The method according to claim 6, characterized in that In a case where the operation information includes at least one of a CPU usage rate, a memory usage rate, and a response time, when it is detected that any microservice among the N microservices does not meet the predetermined operation condition, adjusting the operation resources of any microservice includes: When it is detected that any of the N microservices does not meet the predetermined operating condition, determining the operating resource adjustment strategy to be: increasing the computing resources allocated to any of the microservices; The predetermined operating condition includes at least one of the following: the CPU usage is greater than a preset first usage, the memory usage is greater than a preset second usage, and the response time is greater than a predetermined time.

8. A model deployment processing device, characterized in that: include: A decomposition module is used to decompose the business model into N microservices, where N is an integer greater than or equal to 2, and the N microservices correspond to different business data processing functions; A definition module is used to define N microservice interfaces, where the N microservice interfaces correspond one-to-one to the N microservices; The deployment module is used to deploy N microservices and N microservice interfaces to the serverless architecture.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the model deployment processing method described in any one of claims 1 to 7.

10. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 7 when running.

Images