A method and system for dynamic expansion and contraction of capacity and load balancing control of a lightweight computing power model service on a power grid side

Abstract

The application discloses a light-weight computing power model service dynamic expansion and contraction and load balancing control method and system on the power grid side, constructs a light-weight and high-reliability model service scheduling system based on a master-secondary node cooperative architecture, realizes resource optimized utilization through resource accurate matching type expansion and contraction, prevents node overload through serial feedback type load balancing, realizes unattended operation through whole-cycle abnormal monitoring and self-healing, and is suitable for actual scenes that terminal computing power equipment resources on the power grid side are limited, bandwidth is limited, and reliability requirements are high; and the application improves resource utilization.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance technology for power grids, specifically to a method and system for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid end side. Background Technology

[0002] Current scheduling and load management methods for grid-side model services have shortcomings: On the one hand, existing scheduling methods mostly adopt a fixed node deployment mode, without dynamically adjusting the start and stop of auxiliary nodes based on the inference load of the master node. This results in either overload of the master node inference leading to service lag and response delay, or idle auxiliary nodes causing waste of terminal computing resources and low resource utilization. On the other hand, existing load balancing strategies mostly rely on complex scheduling components, which require a large amount of terminal computing resources, have poor adaptability, and lack lightweight logic designed for the characteristics of grid-side terminal computing equipment. This can easily lead to problems such as single-node resource overload and crash, and uneven load distribution.

[0003] Regarding dynamic scaling up and down, existing technologies mostly employ extensive scheduling strategies. During scaling up, they fail to accurately match model resource requirements with available node resources, easily leading to resource fragmentation. During scaling down, they do not scientifically select redundant nodes, failing to maximize the release of idle resources. Furthermore, grid-side equipment is distributed widely and is difficult to maintain. Existing methods lack robust anomaly monitoring and self-healing mechanisms, making it impossible to identify anomalies such as master node overload and auxiliary node failure in real time. Manual intervention is required, making unattended operation and maintenance difficult. This can easily lead to model service interruptions and affect the normal operation of intelligent services on the grid side. Summary of the Invention

[0004] Purpose of the Invention: The purpose of this invention is to provide a lightweight computing power model service dynamic scaling and load balancing control method and system on the power grid side. Based on a master-slave node collaborative architecture, a lightweight and highly reliable model service scheduling system is constructed. Resource optimization is achieved through precise resource matching scaling, node overload is prevented through serial feedback load balancing, and unattended operation is achieved through full-cycle anomaly monitoring and self-healing. This invention is suitable for real-world scenarios where power grid-side terminal computing power equipment has limited resources, bandwidth, and high reliability requirements, thereby improving resource utilization and solving the problems existing in the background technology.

[0005] Technical solution: The present invention provides a method for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side, comprising the following steps: Step 1: Initialize the master-slave node architecture. The master node is the terminal computing power device on the power grid side. In the initial stage, there are no pre-existing slave nodes. Only when the master node is overloaded, a device that meets the conditions is selected from the existing terminal computing power devices on the power grid side to be temporarily generated and started as a slave node to undertake the model inference task. After the slave node is started, a one-to-one binding relationship is established between the slave node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding slave node. The master node's own inference task is handled independently. Step 2: Dynamic scaling-up and scaling-down strategy is executed, using a combination of precise resource matching for scaling-up and gradient scaling-down. During scaling-up, when the master node detects its own overload, it selects the device with the highest resource matching degree from the existing terminal computing power devices on the grid side that meets the minimum resource requirements of the model and temporarily creates it as a secondary node and starts its service. During scaling-down, when the master node detects its own load reduction, it prioritizes shutting down the slowest processing node among the currently started secondary nodes and reclaims the inference requests it has undertaken. Step 3: Lightweight load balancing scheduling, based on a one-to-one binding architecture between temporarily generated auxiliary nodes and child threads, adopts the core logic of single request serial processing and result confirmation before distribution. After the child thread distributes an inference request to the bound auxiliary node, it waits for the auxiliary node to return the processing result. After confirming that there is no error, it distributes the next request. Step 4: Anomaly monitoring and self-healing. The master node monitors its own and the running status of each currently started auxiliary node in real time, identifies three types of anomalies: its own overload, auxiliary node failure, and auxiliary node resource overload, and automatically performs isolation, service shutdown, resource release, and service redeployment operations for each type of anomaly. Step 5: Closed-loop verification. After completing scaling up / down, load adjustment, or self-healing operations, the master node verifies its own service status and resource usage as well as that of currently started auxiliary nodes to ensure a closed-loop process.

[0006] Further, step 1 is as follows: Deploy terminal computing devices on the power grid side. In the initial stage, the master node takes priority in handling all model inference requests. Only when the master node is overloaded will auxiliary nodes be dynamically selected and temporarily generated from the existing terminal computing devices on the power grid side. Preset monitoring period, expansion threshold, reduction threshold and debouncing period. Only after the master node is overloaded and a temporary auxiliary node is selected, establish a one-to-one binding relationship between the auxiliary node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding auxiliary node.

[0007] Furthermore, step 2 is as follows: During expansion, the master node monitors its core indicators according to a preset monitoring cycle. After meeting the expansion threshold, it first calculates the minimum resource requirements for the model service, and then selects the equipment with the highest available resources and resource matching degree from the existing online terminal computing power equipment on the power grid side to temporarily generate auxiliary nodes. After starting, it diverts inference requests. During shrinkage, after the master node detects that its own load is lower than the shrinkage threshold, it calculates the average processing speed of each auxiliary node based on the speed at which the results are returned by each currently started auxiliary node, selects the auxiliary node with the slowest processing speed, shuts down the service, and withdraws the inference request. After each expansion or shrinkage operation is completed, the anti-jitter cycle is started, and indicator collection and scheduling decisions are paused.

[0008] Furthermore, step 3 is as follows: load isolation is achieved based on the one-to-one binding relationship between the temporary auxiliary nodes and child threads that are temporarily generated and bound after the master node is overloaded; the master node prioritizes processing inference requests itself, and when the temporary auxiliary nodes have been started, requests are serially distributed to the auxiliary nodes through child threads. After the child thread distributes a request, it waits for the auxiliary node to return the processing result, and only distributes the next request after confirming that there is no error; through the serial distribution logic, it strictly controls that each auxiliary node processes only one request at a time.

[0009] Furthermore, step 4 is as follows: Each node reports its own operating status, resource utilization, and heartbeat signal to the master node according to a preset period; the master node identifies three types of abnormal situations, namely, if the message queue of the master node continues to grow for several consecutive periods or the resource utilization exceeds the threshold, it is determined to be overloaded; if the started auxiliary node does not receive a heartbeat signal for several consecutive periods and does not respond to inquiries, it is determined to be a failure of the auxiliary node; if the resource utilization of the started auxiliary node exceeds the threshold for several consecutive periods, it is determined to be overloaded of the auxiliary node; if the master node is overloaded, it triggers the expansion process to re-select and generate new auxiliary nodes; if the auxiliary node is abnormal, it issues a shutdown command to isolate the abnormal node and divert its requests; if the master node is still overloaded after the resources are released, it re-selects auxiliary nodes and deploys services.

[0010] The present invention discloses a lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side, comprising: Initialization module: Used for initializing the master-slave node architecture. The master node is the terminal computing power device on the power grid side. In the initial stage, there are no pre-existing slave nodes. Only when the master node is overloaded, devices that meet the conditions are selected from the existing terminal computing power devices on the power grid side to be temporarily generated and started as slave nodes to undertake model inference tasks. After the slave node is started, a one-to-one binding relationship is established between the slave node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding slave node. The master node's own inference tasks are handled independently. The scaling up / down module is used to execute dynamic scaling up / down strategies. It adopts a combination of precise resource matching for scaling up and gradient scaling down. During scaling up, when the master node detects that it is overloaded, it selects the device with the highest resource matching degree from the existing terminal computing power devices on the grid side that meets the minimum resource requirements of the model and temporarily creates it as a secondary node and starts its service. During scaling down, when the master node detects that its load has decreased, it prioritizes selecting the slowest processing node among the currently started secondary nodes to shut down its service and reclaims the inference requests it has undertaken. Load balancing module: Used for lightweight load balancing scheduling. Based on the architecture of temporary auxiliary nodes and child threads being bound one-to-one, it adopts the core logic of single request serial processing and result confirmation before distribution. After the child thread distributes an inference request to the bound auxiliary node, it waits for the auxiliary node to return the processing result. After confirming that there is no error, it distributes the next request. Monitoring and self-healing module: Used for anomaly monitoring and self-healing. The master node monitors its own and the running status of each currently started auxiliary node in real time, identifies three types of anomalies: its own overload, auxiliary node failure, and auxiliary node resource overload, and automatically performs isolation, service shutdown, resource release, and service redeployment operations for each type of anomaly. Closed-loop verification module: Used for closed-loop verification. After the master node completes scaling up / down, load adjustment or self-healing operations, it verifies the service status and resource usage of itself and the currently started auxiliary nodes to ensure the process is closed-loop.

[0011] Furthermore, in the initialization module, the specific steps are as follows: Terminal computing devices are deployed on the power grid side, with the master node initially handling all model inference requests; auxiliary nodes are dynamically selected and temporarily generated from existing terminal computing devices on the power grid side only when the master node is overloaded; monitoring cycles, expansion thresholds, reduction thresholds, and debouncing cycles are preset; only after the master node is overloaded and a temporary auxiliary node is selected, a one-to-one binding relationship is established between the auxiliary node and its child thread, with each child thread only responsible for request distribution and result reception for its corresponding auxiliary node.

[0012] Furthermore, in the scaling up / down module, the specific steps are as follows: During scaling up, the master node monitors its core indicators according to a preset monitoring cycle. After meeting the scaling up threshold, it first calculates the minimum resource requirements for the model service, and then selects the device with the highest available resources and resource matching degree from the existing online terminal computing power devices on the power grid side to temporarily generate it as an auxiliary node. After starting, it distributes inference requests. During scaling down, after the master node detects that its own load is lower than the scaling down threshold, it calculates the average processing speed of each auxiliary node based on the speed at which the results are returned by each of the currently started auxiliary nodes, selects the auxiliary node with the slowest processing speed, shuts down the service, and withdraws the inference request. After each scaling up / down operation is completed, an anti-jitter cycle is started, pausing indicator collection and scheduling decisions.

[0013] Furthermore, in the load balancing module, the specific implementation is as follows: load isolation is achieved based on the one-to-one binding relationship between the temporary auxiliary nodes that are generated and bound after the master node becomes overloaded and the child threads; the master node prioritizes processing inference requests itself, and when temporary auxiliary nodes have been started, requests are serially distributed to the auxiliary nodes through child threads. After distributing a request, the child thread waits for the auxiliary node to return the processing result, and only distributes the next request after confirming that it is correct; through the serial distribution logic, it strictly controls that each auxiliary node processes only one request at a time.

[0014] Furthermore, the self-healing monitoring module works as follows: Each node reports its own operating status, resource utilization, and heartbeat signals to the master node according to a preset cycle; the master node identifies three types of abnormal situations: if the master node's message queue continues to grow for several consecutive cycles or its resource utilization exceeds the threshold, it is determined to be overloaded; if a started auxiliary node does not receive a heartbeat signal for several consecutive cycles and does not respond to inquiries, it is determined to be a faulty auxiliary node; if the resource utilization of a started auxiliary node exceeds the threshold for several consecutive cycles, it is determined to be an overloaded auxiliary node; if the master node is overloaded, it triggers a capacity expansion process to re-select and generate new auxiliary nodes; if an auxiliary node is abnormal, it issues a shutdown command to isolate the abnormal node and divert its requests; if the master node is still overloaded after the resources are released, it re-selects auxiliary nodes and deploys services.

[0015] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: (1) It adopts a collaborative architecture of "primary node priority inference, temporary generation and startup of auxiliary nodes after overload", combined with resource precise matching expansion and gradient shrinkage strategies, to avoid fragmentation and idle waste of terminal computing power resources, greatly improve resource utilization, and adapt to the scenario of limited resources on the power grid side. (2) It designs a lightweight serial feedback load balancing strategy, which does not require complex scheduling components, has low resource overhead, and can effectively prevent the temporary auxiliary nodes from overload and crash, taking into account both load balancing and service stability. (3) It constructs a fully automated anomaly self-healing mechanism to realize the real-time identification, isolation and recovery of anomalies of primary nodes and temporary auxiliary nodes, without manual intervention, realizing unattended operation and maintenance on the power grid side, and reducing operation and maintenance costs. (4) The overall logic is lightweight and highly implementable. It does not require additional hardware and can directly generate auxiliary nodes from the existing terminal computing power equipment on the power grid side, adapting to the scenario of limited bandwidth and complex operating environment on the power grid side, and significantly improving the model service scheduling efficiency and operation stability. Attached Figure Description

[0016] Figure 1 This is a flowchart of the present invention; Figure 2 This is a schematic diagram of the master-slave node collaborative architecture, sub-thread binding, and lightweight load balancing serial distribution and result confirmation structure of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0018] like Figure 1 As shown, this embodiment of the invention provides a method and system for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side, including the following steps: This embodiment is implemented based on a Python development environment and a lightweight scheduling framework. It does not require complex hardware support and can be directly adapted to resource-constrained terminal computing devices such as power grid edge gateways and distribution terminals, meeting the requirements of low-overhead and high-reliability operation of model services.

[0019] Step 1: Deployment and initialization of the master-slave node collaborative architecture The core architecture of this embodiment is a master-slave terminal computing power device collaborative mode. Only when the master node is overloaded with inference will a suitable device be selected from the existing terminal computing power devices on the grid side to be started as a slave node, without requiring additional hardware. The initialization process focuses on lightweight configuration of the master node to avoid consuming excessive device resources, laying the foundation for subsequent scheduling processes. A related structural diagram is shown below. Figure 2 .

[0020] 1.1 Architecture Deployment and Equipment Selection Existing power grid terminal computing devices (such as edge computing terminals and smart distribution terminals) are selected, and the device configuration meets the basic requirements for lightweight model inference (CPU ≥ 4 cores, memory ≥ 8G). The master node is responsible for overall coordination and independently undertakes all model inference, scheduling decisions, and status monitoring tasks in the initial stage. Auxiliary nodes are not pre-deployed. Only when the master node is overloaded by inference will eligible devices be selected from the existing power grid terminal computing devices and started as auxiliary nodes, which are dedicated to model inference tasks and do not participate in scheduling decisions.

[0021] 1.2 Core Parameter Presets and Configuration After the system starts, it automatically loads the preset core scheduling parameters. All parameters adopt a minimalist design, requiring no complex calibration, and are adapted to the low computing power characteristics of terminal computing devices. The specific parameters are as follows: Monitoring cycle: 3 seconds, to balance the master node monitoring overhead and load response real-time performance, avoiding excessive computing power consumption due to too short a cycle and load response lag due to too long a cycle; Expansion threshold: The message queue length of the master node continues to increase within 3 consecutive monitoring periods (the queue length in the later period is greater than that in the previous period), or the CPU / GPU utilization rate both exceed 70% (only the resource usage related to model inference is counted). Scaling down threshold: The message queue length of the master node is ≤3 for three consecutive monitoring periods; Anti-shake cycle: 15 seconds, to prevent frequent capacity expansion and contraction caused by temporary load fluctuations; Resource margin rule: The minimum resource requirements for model service operation are calculated based on the number of model parameters. When selecting auxiliary nodes, it is necessary to meet the requirement that "available resources ≥ minimum requirements, and surplus resources are about 30% of the total equipment capacity".

[0022] 1.3 One-to-one binding between child threads and auxiliary nodes When the master node triggers the scaling process and selects eligible devices as slave nodes, it automatically creates sub-threads corresponding to the number of slave nodes, establishing a one-to-one binding relationship between slave nodes and sub-threads. Each sub-thread is only responsible for request distribution and result reception tasks for its corresponding slave node and does not participate in related operations of other slave nodes, achieving load isolation and reducing the thread management overhead of terminal computing devices. The master node's own inference tasks are processed independently and are not distributed through sub-threads, ensuring the inference efficiency of the master node.

[0023] Step 2: Implementation of the Dynamic Scaling-Up Strategy The dynamic scaling strategy consists of two core components: scaling up and scaling down. Combined with a debouncing mechanism, it achieves precise resource scheduling, avoiding resource waste and overload. The entire process is automatically triggered and executed by the master node without manual intervention.

[0024] 2.1 Implementation of Capacity Expansion Operation The scaling operation is triggered by overload of the master node. The core is to accurately match the model's resource requirements with the available resources of the auxiliary nodes. The specific steps are as follows: Load monitoring and threshold determination: The master node collects its own core indicators (message queue length, CPU / GPU utilization) in real time at 3-second intervals and compares them with the preset expansion threshold. If the expansion conditions are met for 3 consecutive cycles, the master node is determined to be overloaded and the expansion process is triggered immediately. Model resource requirement estimation: The master node calls the lightweight resource estimation module, which calculates the minimum resource requirements required for the model to run normally based on the number of parameters of the currently deployed lightweight model, prior knowledge, or by quickly calculating the estimation process. The estimation process does not require complex algorithms, reducing the computing power consumption of the master node. Auxiliary node screening and selection: The master node obtains the current available resource data of each device from the existing online terminal computing power devices on the power grid side (only CPU / GPU utilization and memory availability are collected), and screens out devices whose "available resources meet the minimum requirements of the model and the surplus resources are about 30% of the total capacity of the device", and determines them as temporary auxiliary nodes (i.e., auxiliary nodes generated after overload). The device with the highest resource matching degree is selected as the target auxiliary node. Service startup and request routing: The master node sends a service startup command to the target slave node; after receiving the command, the target slave node adaptively starts the model service and reports the startup status to the master node after startup is complete; after the master node confirms successful startup, it starts to route some inference requests to the slave node, while continuing to undertake the remaining inference tasks to alleviate overload pressure. Anti-shake mechanism activated: After the expansion operation is completed, the master node immediately starts a 15-second anti-shake cycle, during which indicator collection and expansion / contraction decisions are suspended, and only basic state reception and its own inference tasks are maintained to avoid frequent expansion.

[0025] 2.2 Implementation of volume reduction operation The scaling-down operation is triggered by a reduction in the load on the master node. Its core purpose is to maximize the release of redundant resources. The specific steps are as follows: Load monitoring and threshold determination: The master node continuously monitors its own message queue length. If the queue length is ≤3 for three consecutive monitoring periods, it is determined that the master node's inference load is low and there is no need for the auxiliary node to continue to share the load, thus triggering the scaling-down process. Auxiliary node processing speed calculation: The master node actively calculates and statistically analyzes the average processing speed of each auxiliary node (generated after overload) based on the speed at which each of the currently started auxiliary nodes returns inference results, and selects the auxiliary node with the slowest average processing speed and the highest resource redundancy as the target scaling-down node. Service shutdown and resource release: The master node sends a service shutdown command to the target scaling-down node, requiring it to stop accepting new requests, process the current requests first, shut down the model service, and release all occupied resources (CPU, memory, etc.); after the target auxiliary node completes the operation, it reports the resource release status back to the master node; Request recovery and verification: After the master node confirms the release of resources, it stops routing requests to the slave node, recovers all inference requests, and assumes the responsibility itself; Anti-shake mechanism activated: After the scaling down operation is completed, a 15-second anti-shake cycle is activated to prevent scaling up or down from being triggered again due to temporary load fluctuations.

[0026] Experiments were conducted on expansion and contraction, and the results are shown in Table 1. Each expansion and contraction operation was repeated 50 times. The timing started when the master node determined that the expansion / contraction threshold had been reached, and ended when the target auxiliary node fully received the expansion / contraction scheduling command.

[0027] Table 1 shows the experimental results of capacity scaling and delay in this invention.

[0028] Step 3: Implementation of Lightweight Load Balancing Scheduling The load balancing strategy in this embodiment focuses on lightweight and low resource consumption. Based on a one-to-one binding relationship between "secondary nodes and child threads," it employs serial distribution logic to achieve coordinated load distribution between primary and secondary nodes. The relevant processes have been integrated into [the relevant documentation / system / process]. Figure 2 The specific implementation steps are as follows: 3.1 Basic Preparations for Load Distribution Based on the one-to-one binding relationship between "auxiliary nodes and child threads" established after the master node is overloaded, the core responsibilities of each child thread are clearly defined: it is only responsible for request distribution and result reception for its corresponding auxiliary node, and does not participate in the scheduling of other auxiliary nodes, thereby achieving load isolation and reducing the thread contention overhead of terminal computing devices. The master node's own inference tasks are processed independently and do not depend on child threads, ensuring that the inference efficiency of the master node is not affected.

[0029] 3.2 Serial Distribution and Result Confirmation Execution After receiving a model inference request from the power grid side, the master node prioritizes undertaking the inference task itself. When the master node reaches the overload threshold and starts the auxiliary node, it distributes some requests to the dedicated sub-threads of the corresponding auxiliary nodes in a preset order, executing the logic of "serial processing of single requests and distribution after result confirmation". After the child thread dispatches an inference request to the bound auxiliary node, it immediately enters a waiting state and no longer dispatches new requests to that auxiliary node. After receiving the request, the auxiliary node starts model inference and, upon completion, feeds back the processing results (including processing status and inference results) to the corresponding sub-thread. After the child thread confirms that the result has been received correctly, it then distributes the next inference request to the auxiliary node, ensuring that each auxiliary node processes only one request at a time.

[0030] 3.3 Implementation of Load Protection Mechanism By using the above serial distribution logic, the number of concurrent requests for each auxiliary node is strictly controlled, avoiding resource overload caused by parallel processing of multiple requests, and effectively preventing auxiliary nodes (terminal computing devices) from crashing due to resource exhaustion.

[0031] Step 4: Anomaly Detection and Fully Automated Self-Healing Implementation This module enables real-time monitoring, isolation, and self-healing of anomalies in the master node and auxiliary nodes, ensuring continuous and stable operation of the model service. It adapts to the unattended operation and maintenance requirements of the power grid end side and is completed automatically by the master node without manual intervention.

[0032] 4.1 Implementation of Status Monitoring Mechanism Auxiliary node status reporting: Auxiliary nodes report their core status data to the master node every 3 seconds, including only the model service running status (running / stopping), CPU / GPU utilization, and heartbeat signal, to avoid redundant data transmission and reduce the overhead of auxiliary nodes. Master Node Status Acquisition: The master node collects its own status data in real time, including the number of inference tasks, CPU / GPU utilization, and message queue length, to fully understand its own inference load. Processing speed calculation: The master node actively calculates the request processing speed of each slave node based on the time interval between the return of inference results from the slave nodes, providing data support for anomaly detection and scaling down selection.

[0033] 4.2 Abnormal Judgment Criteria Based on the collected status data, the master node establishes three types of anomaly judgment rules to quickly identify anomalies: Master node overload: The message queue length continues to increase or the CPU / GPU utilization exceeds 70% within three consecutive monitoring periods; Secondary node failure: This applies only to secondary nodes that have been started. If the primary node fails to receive a status report (no heartbeat signal) from the secondary node for three consecutive monitoring cycles (a total of 9 seconds), and still does not respond after sending an inquiry command, the secondary node is considered to be faulty. Secondary node resource overload: This applies only to started secondary nodes. If their CPU / GPU utilization exceeds 70% for three consecutive monitoring cycles (9 seconds), it is considered that the secondary node is overloaded. 4.3 Exception Handling and Self-Healing Execution Anomaly Isolation: For identified anomalies, the master node immediately performs isolation operations: if it is overloaded, it triggers the scaling process; if a secondary node is abnormal, it is marked as "unavailable" and any requests to it are suspended. Service shutdown and resource release: The master node sends a service shutdown command to the abnormal slave node, requiring the resource-overloaded node to immediately stop receiving new requests, process the current requests, shut down the service, and release resources; after the faulty node recovers communication, it immediately performs the service shutdown and resource release operations. Self-healing and recovery: After the master node confirms that the abnormal auxiliary node has completed resource release, if it is still in an overloaded state, it immediately triggers a new round of expansion process. From the existing online terminal computing power equipment on the power grid side, it re-selects healthy and resource-appropriate equipment as auxiliary nodes and deploys model services. After the service deployment is completed, it updates the auxiliary node status list, marks it as "available", restores normal request distribution, and realizes a fully automated self-healing closed loop.

[0034] Step 5: Closed-loop verification and system maintenance To ensure long-term stable operation of the system, the master node automatically performs a closed-loop verification operation after each scaling up / down, load adjustment, or anomaly self-healing operation. Status verification: The master node verifies the service operation status of itself and each auxiliary node to confirm that the model service has started normally and that request distribution is normal; Resource verification: Verify the resource utilization of each auxiliary node to ensure that there is no resource overload or resource residue, and that the load of the main node is within a reasonable range; If the verification is successful, the system continues to operate normally; if the verification finds an anomaly, the master node immediately re-executes the corresponding processing procedure to ensure service continuity.

Claims

1. A lightweight computing power model service dynamic scaling and load balancing control method on the power grid end side, characterized in that, Includes the following steps: Step 1: Initialize the master-slave node architecture. The master node is the terminal computing power device on the power grid side. There are no pre-existing slave nodes in the initial stage. Only when the master node is overloaded for inference, a device that meets the conditions is selected from the existing terminal computing power devices on the power grid side to be temporarily generated and started as a slave node to undertake the model inference task. After the auxiliary node starts, a one-to-one binding relationship is established between the auxiliary node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding auxiliary node, while the main node's own inference tasks are handled independently. Step 2: Dynamic scaling-up and scaling-down strategy is executed, using a combination of precise resource matching for scaling-up and gradient scaling-down. During scaling-up, when the master node detects its own overload, it selects the device with the highest resource matching degree from the existing terminal computing power devices on the grid side that meets the minimum resource requirements of the model and temporarily creates it as a secondary node and starts its service. During scaling-down, when the master node detects its own load reduction, it prioritizes shutting down the slowest processing node among the currently started secondary nodes and reclaims the inference requests it has undertaken. Step 3: Lightweight load balancing scheduling, based on a one-to-one binding architecture between temporarily generated auxiliary nodes and child threads, adopts the core logic of single request serial processing and result confirmation before distribution. After the child thread distributes an inference request to the bound auxiliary node, it waits for the auxiliary node to return the processing result. After confirming that there is no error, it distributes the next request. Step 4: Anomaly monitoring and self-healing. The master node monitors its own and the running status of each currently started auxiliary node in real time, identifies three types of anomalies: its own overload, auxiliary node failure, and auxiliary node resource overload, and automatically performs isolation, service shutdown, resource release, and service redeployment operations for each type of anomaly. Step 5: Closed-loop verification. After completing scaling up / down, load adjustment, or self-healing operations, the master node verifies its own service status and resource usage as well as that of currently started auxiliary nodes to ensure a closed-loop process.

2. The method for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side according to claim 1, characterized in that, Step 1 is as follows: Deploy terminal computing devices on the power grid side. In the initial stage, the master node takes priority in handling all model inference requests. Only when the master node is overloaded will auxiliary nodes be dynamically selected and temporarily generated from the existing terminal computing devices on the power grid side. Preset monitoring period, expansion threshold, reduction threshold and debouncing period. Only after the master node is overloaded and a temporary auxiliary node is selected, establish a one-to-one binding relationship between the auxiliary node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding auxiliary node.

3. The method for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side according to claim 1, characterized in that, Step 2 is as follows: During expansion, the master node monitors its core indicators according to a preset monitoring cycle. After meeting the expansion threshold, it first calculates the minimum resource requirements for the model service, and then selects the device with the highest available resources and resource matching degree from the existing online terminal computing power devices on the power grid side to temporarily generate auxiliary nodes. After starting, it distributes inference requests. During shrinkage, after the master node detects that its own load is lower than the shrinkage threshold, it calculates the average processing speed of each auxiliary node based on the speed at which the results are returned by each currently started auxiliary node, selects the auxiliary node with the slowest processing speed, shuts down the service, and withdraws the inference request. After each expansion or shrinkage operation is completed, the anti-jitter cycle is started, and indicator collection and scheduling decisions are paused.

4. The method for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side according to claim 1, characterized in that, Step 3 is as follows: Load isolation is achieved based on the one-to-one binding relationship between the temporary auxiliary nodes and child threads that are temporarily generated and bound after the master node is overloaded; the master node prioritizes processing inference requests itself. When the temporary auxiliary nodes have been started, requests are serially distributed to the auxiliary nodes through child threads. After the child thread distributes a request, it waits for the auxiliary nodes to return the processing result. After confirming that there is no error, it distributes the next request. By using serial distribution logic, each auxiliary node is strictly controlled to process only one request at a time.

5. The method for dynamic scaling and load balancing control of a lightweight computing power model service on the power grid side according to claim 1, characterized in that, Step 4 is as follows: Each node reports its own operating status, resource utilization, and heartbeat signal to the master node according to a preset period. The master node identifies three types of abnormal situations: if the message queue of the master node continues to grow for several consecutive periods or the resource utilization exceeds the threshold, it is determined to be overloaded; if the started auxiliary node does not receive a heartbeat signal for several consecutive periods and does not respond to inquiries, it is determined to be a failure of the auxiliary node; if the resource utilization of the started auxiliary node exceeds the threshold for several consecutive periods, it is determined to be overloaded of the auxiliary node. If the master node is overloaded, it triggers the expansion process to re-select and generate new auxiliary nodes. If the auxiliary node is abnormal, it issues a shutdown command to isolate the abnormal node and divert its requests. If the master node is still overloaded after the resources are released, it re-selects auxiliary nodes and deploys services.

6. A lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side, characterized in that, include: Initialization module: Used for initialization of the master-slave node architecture. The master node is the terminal computing power device on the power grid side. There are no pre-existing slave nodes in the initial stage. Only when the master node is overloaded for inference, a device that meets the conditions is selected from the existing terminal computing power devices on the power grid side to be temporarily generated and started as a slave node to undertake the model inference task. After the auxiliary node starts, a one-to-one binding relationship is established between the auxiliary node and the child thread. Each child thread is only responsible for the request distribution and result reception of the corresponding auxiliary node, while the main node's own inference tasks are handled independently. The scaling up / down module is used to execute dynamic scaling up / down strategies. It adopts a combination of precise resource matching for scaling up and gradient scaling down. During scaling up, when the master node detects that it is overloaded, it selects the device with the highest resource matching degree from the existing terminal computing power devices on the grid side that meets the minimum resource requirements of the model and temporarily creates it as a secondary node and starts its service. During scaling down, when the master node detects that its load has decreased, it prioritizes selecting the slowest processing node among the currently started secondary nodes to shut down its service and reclaims the inference requests it has undertaken. Load balancing module: Used for lightweight load balancing scheduling. Based on the architecture of temporary auxiliary nodes and child threads being bound one-to-one, it adopts the core logic of single request serial processing and result confirmation before distribution. After the child thread distributes an inference request to the bound auxiliary node, it waits for the auxiliary node to return the processing result. After confirming that there is no error, it distributes the next request. Monitoring and self-healing module: Used for anomaly monitoring and self-healing. The master node monitors its own and the running status of each currently started auxiliary node in real time, identifies three types of anomalies: its own overload, auxiliary node failure, and auxiliary node resource overload, and automatically performs isolation, service shutdown, resource release, and service redeployment operations for each type of anomaly. Closed-loop verification module: Used for closed-loop verification. After the master node completes scaling up / down, load adjustment or self-healing operations, it verifies the service status and resource usage of itself and the currently started auxiliary nodes to ensure the process is closed-loop.

7. A lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side according to claim 6, characterized in that, In the initialization module, the specific steps are as follows: Deploy terminal computing devices on the power grid side; the master node initially takes the lead in handling all model inference requests; only when the master node is overloaded will auxiliary nodes be dynamically selected and temporarily generated from the existing terminal computing devices on the power grid side; preset monitoring period, expansion threshold, reduction threshold, and debouncing period; only after the master node is overloaded and a temporary auxiliary node is selected, establish a one-to-one binding relationship between the auxiliary node and the child thread, with each child thread only responsible for the request distribution and result reception of the corresponding auxiliary node.

8. A lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side according to claim 6, characterized in that, In the scaling up / down module, the specific steps are as follows: During scaling up, the master node monitors its core indicators according to a preset monitoring cycle. After meeting the scaling up threshold, it first calculates the minimum resource requirements for the model service, and then selects the device with the highest available resources and resource matching degree from the existing online terminal computing power devices on the power grid side to temporarily generate it as an auxiliary node. After starting, it distributes inference requests. During scaling down, after the master node detects that its own load is lower than the scaling down threshold, it calculates the average processing speed of each auxiliary node based on the speed at which the results are returned by each of the currently started auxiliary nodes, selects the auxiliary node with the slowest processing speed, shuts down the service, and withdraws the inference request. After each scaling up / down operation is completed, an anti-jitter cycle is started, pausing indicator collection and scheduling decisions.

9. A lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side according to claim 6, characterized in that, In the load balancing module, the specific implementation is as follows: load isolation is achieved based on the one-to-one binding relationship between the temporary auxiliary nodes that are generated and bound after the master node is overloaded and the child threads; the master node prioritizes processing inference requests itself, and when the temporary auxiliary nodes have been started, requests are serially distributed to the auxiliary nodes through the child threads. After the child thread distributes a request, it waits for the auxiliary nodes to return the processing result, and only distributes the next request after confirming that there is no error. By using serial distribution logic, each auxiliary node is strictly controlled to process only one request at a time.

10. A lightweight computing power model service dynamic scaling and load balancing control system for the power grid end side according to claim 6, characterized in that, The self-healing monitoring module works as follows: Each node reports its own operating status, resource utilization, and heartbeat signals to the master node according to a preset cycle; the master node identifies three types of abnormal situations: if the master node's message queue continues to grow for several consecutive cycles or its resource utilization exceeds the threshold, it is determined to be overloaded; if a started auxiliary node does not receive a heartbeat signal for several consecutive cycles and does not respond to inquiries, it is determined to be a faulty auxiliary node; if the resource utilization of a started auxiliary node exceeds the threshold for several consecutive cycles, it is determined to be an overloaded auxiliary node; if the master node is overloaded, it triggers a capacity expansion process to re-select and generate new auxiliary nodes; if an auxiliary node is abnormal, it issues a shutdown command to isolate the abnormal node and divert its requests; if the master node is still overloaded after the resources are released, it re-selects auxiliary nodes and deploys services.

Images