A computing power dynamic allocation method under cooperation of local AI intelligent agent lightweight components

Abstract

The application discloses a computing power dynamic distribution method under local AI intelligent agent lightweight component cooperation, relates to the technical field of computing power distribution, and comprises the following steps: simplifying redundant functions of each function component of the local AI intelligent agent, encapsulating a lightweight interaction interface, setting a resource occupation threshold, simultaneously configuring corresponding priorities, collecting hardware resource states and component running states through a system call interface in a running process, calculating a comprehensive load index, and determining high-load, normal or low-load scenes; then, the resource occupation upper limit, memory quota and running state are adjusted in combination with the component priorities and the load scenes; process isolation and memory partition are simultaneously adopted in the component cooperation, and automatic degradation or restart is executed in an abnormal state. The application solves the technical problems that, in the prior art, computing power distribution is rigid and core component response speed is difficult to guarantee when multiple components of a local AI intelligent agent concurrently run, and achieves the technical effects of preferentially guaranteeing core component computing power requirements and improving local AI intelligent agent response efficiency.

Description

Technical Field

[0001] This invention relates to the field of computing power allocation technology, specifically to a method for dynamic allocation of computing power in collaboration with lightweight components of a local AI agent. Background Technology

[0002] As the application of local AI agents in PC-based office scenarios continues to expand, they typically integrate multiple functional components such as intelligent question answering, knowledge base retrieval, full-screen search, and word highlighting tools. Each component needs to share local computing resources such as CPU, memory, and NPU during operation. Due to differences in task types, resource requirements, and response demands among different components, when multiple components run concurrently, if a fixed resource allocation method is used or a scheduling mechanism based on runtime status is lacking, non-core components may continuously consume computing resources, while core components may not receive sufficient computing resources in a timely manner. This can lead to delays in the response of core functions such as intelligent question answering and knowledge base retrieval, impacting the overall operational efficiency and user experience of the local AI agent. Summary of the Invention

[0003] This application provides a method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent, which is used to address the technical problems of rigid computing power allocation and difficulty in guaranteeing the response speed of core components when multiple components of a local AI agent are running concurrently in the prior art.

[0004] In view of the above problems, this application provides a method for dynamic allocation of computing power under the collaboration of lightweight components of local AI agents, the method comprising: The local AI agent's multiple functional components undergo lightweighting, with priority levels configured for each component. Lightweighting includes streamlining redundant functions, encapsulating lightweight interaction interfaces, and setting maximum resource consumption thresholds. Local hardware resource status and component operating status are collected in real-time via system call interfaces. A comprehensive load index is calculated based on these hardware resource statuses and component operating statuses, and load scenarios are determined through matching, categorized as high-load, normal, or low-load scenarios. Dynamic computing power allocation is performed based on the functional component priority levels and the determined load scenarios, determining the computing power allocation strategy and adjusting the configuration parameters of each functional component. These configuration parameters include resource consumption limits, memory quotas, and operating status. Lightweight collaboration and fault isolation between functional components are implemented through process isolation and memory partitioning. Automatic degradation or restart is triggered when a functional component anomaly is detected.

[0005] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application performs lightweight processing on multiple functional components of a local AI agent, configuring priority levels for each component. The lightweight processing includes streamlining redundant functions, encapsulating lightweight interaction interfaces, and setting maximum resource consumption thresholds. Local hardware resource status and component operating status are collected in real-time via system call interfaces. A comprehensive load index is calculated based on the hardware resource status and component operating status, and a load scenario is determined through matching, where the load scenario is high-load, normal, or low-load. Dynamic computing power allocation is performed based on the priority levels of the functional components and the determined load scenario, determining the computing power allocation strategy and adjusting the configuration parameters of each functional component. These configuration parameters include resource consumption limits, memory quotas, and operating status. Lightweight collaboration and fault isolation between functional components are performed through process isolation and memory partitioning. Automatic degradation or restart is triggered when an abnormality is detected in a functional component. This invention addresses the technical problems of rigid computing power allocation and difficulty in guaranteeing the response speed of core components when multiple components of a local AI agent are running concurrently in the prior art. By configuring priority levels for functional components and combining real-time collected hardware resource status and component operating status to determine the load scenario, the invention dynamically adjusts the resource usage limit, memory quota, and operating status of each functional component, thereby achieving the technical effect of prioritizing the computing power needs of core components and improving the response efficiency of the local AI agent. Attached Figure Description

[0006] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0007] Figure 1 This application provides a schematic diagram of a method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent. Figure 2 This is a flowchart illustrating the configuration of priority levels in a method for dynamic allocation of computing power under the collaboration of a lightweight local AI agent component, as provided in an embodiment of this application. Detailed Implementation

[0008] This application provides a method for dynamic allocation of computing power under the collaboration of lightweight components in a local AI agent. It addresses the technical problems of rigid computing power allocation and difficulty in guaranteeing the response speed of core components when multiple components of a local AI agent are running concurrently in the prior art. By configuring priority levels for functional components and combining real-time collected hardware resource status and component operating status to determine the load scenario, the method dynamically adjusts the resource usage limit, memory quota and operating status of each functional component, thereby achieving the technical effect of prioritizing the computing power needs of core components and improving the response efficiency of the local AI agent.

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0010] It should be noted that any variation of the terms "comprising" and "having" is intended to cover non-exclusive inclusion, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0011] Example 1, as Figure 1 As shown, this application provides a method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent, the method comprising: Step S100: Perform lightweight processing on multiple functional components of the local AI agent, and configure priority levels for each functional component. The lightweight processing includes simplifying redundant functions of components, encapsulating lightweight interaction interfaces, and setting a maximum resource consumption threshold.

[0012] In this embodiment, during the initialization phase of the local AI agent, multiple functional components included in the local AI agent are identified. The component identifier, component name, component type, startup entry point, interaction interface, resource requirement parameters, and current running status of each functional component are read to form a set of functional components to be processed. These functional components include an intelligent question-answering component, a knowledge base retrieval component, a full-disk search component, a word-selection translation component, an application center component, and a loading page component. Subsequently, each functional component in the set undergoes lightweighting processing. This lightweighting process includes streamlining redundant component functions, encapsulating lightweight interaction interfaces, and setting a maximum resource consumption threshold. Streamlining redundant component functions refers to splitting the execution logic according to the component type and retaining the execution logic directly corresponding to the core business of the component. For example, the intelligent question-answering component retains the logic for receiving questions, calling the local large model, generating inference results, and outputting answers; the knowledge base retrieval component retains the logic for receiving retrieval requests, indexing, and returning retrieval results; the full-disk search component retains the logic for file indexing and returning search results; and the word-selection translation component retains the logic for extracting selected text, processing text, and returning translation results.

[0013] After streamlining redundant components, lightweight interaction interfaces are encapsulated for each functional component. These interfaces include component call interfaces, status reporting interfaces, resource release interfaces, and exception reporting interfaces. The component call interfaces transmit the caller component identifier, the callee component identifier, the request type, and request parameters. The status reporting interfaces transmit the running status, current request volume, and actual resource usage. The resource release interfaces perform cache clearing, task pause, or status switching. The exception reporting interfaces transmit the exception type, exception timestamp, and exception information. Subsequently, maximum resource usage thresholds are set for each functional component, including CPU usage limits, memory usage limits, and NPU computing power limits when the local device supports NPU. Priority levels are also configured for each functional component. Specifically, the intelligent question answering component and knowledge base retrieval component are configured as P0 priority components, the full-disk search component and word-selection translation component as P1 priority components, and the application center component and loading page component as P2 priority components. After configuration, the component identifier, priority level, lightweight interaction interface, maximum resource usage threshold, and current running status of each functional component are written to the component registry.

[0014] Furthermore, such as Figure 2 As shown, the method provided in the application embodiment, in configuring priority levels, further includes: By accessing historical runtime data, we can extract scenario-based component combinations and computing power allocation ratios based on component response times and use this information as a configuration file. Through the configuration file, we can configure priority levels for each functional component.

[0015] In this embodiment, historical running data is first retrieved, and the scenario-based component combinations and computing power allocation ratios are mined based on component response times, serving as a configuration file. Specifically, historical running data recorded by the local AI agent during operation is read. This historical running data includes component identifier, component name, start time, end time, component response time, component request volume, CPU utilization, memory utilization, NPU computing power utilization, and running status. The component response time is the time elapsed between a functional component receiving a request and returning a result. Using the historical running data of the past 5 minutes as a statistical window, the running records of each functional component are merged according to timestamps. When at least two functional components are simultaneously running within the same statistical window, or when one functional component calls another functional component through a lightweight interactive interface, the corresponding functional components are recorded as candidate component combinations. The frequency of occurrence of candidate component combinations and the average component response time of each functional component are counted. When the frequency of occurrence of a candidate component combination reaches a preset threshold, and the average component response time of the intelligent question-answering component in the candidate component combination reaches 2000ms, the candidate component combination is determined as a scenario-based component combination. For the identified scenario-based component combinations, the computing power allocation ratio is written according to the component type and response time threshold. In the "Question Answering + Knowledge Base Retrieval" scenario-based component combination, the intelligent question answering component and the knowledge base retrieval component are allocated a P0 base computing power allocation ratio, i.e., 30% CPU and 800MB memory. In the "Question Answering + Search" scenario-based component combination, the intelligent question answering component is allocated 40% CPU and 1GB memory, and the full-disk search component is allocated 10% CPU and 300MB memory. In the "Search + Word Selection and Translation" scenario-based component combination, the full-disk search component and the word selection and translation component are allocated a P1 base computing power allocation ratio, i.e., 15% CPU and 300MB memory. The application center component and the loading page component are allocated a P2 base computing power allocation ratio, i.e., 5% CPU and 100MB memory. The above scenario identifier, component combination name, component identifier, component response time threshold, CPU allocation ratio, memory allocation amount, NPU allocation ratio, resource usage limit, and running status adjustment rules are written into the configuration file.

[0016] Next, priority levels are configured for each functional component using configuration files. Specifically, the configuration file is read during local AI agent initialization or functional component startup. Functional components are matched one by one according to their component identifiers in the configuration file, and the scene identifier, CPU allocation ratio, memory allocation quota, NPU allocation ratio, and running status adjustment rules in the configuration file are associated with the corresponding functional components. Priority levels are configured based on the component type field in the configuration file. When the component identifier corresponds to an intelligent question-answering component or a knowledge base retrieval component, the functional component is configured with a P0 priority level; when the component identifier corresponds to a full-disk search component or a word-selection translation component, the functional component is configured with a P1 priority level; when the component identifier corresponds to an application center component or a loading page component, the functional component is configured with a P2 priority level. If the same functional component exists in multiple scenario-based component combinations, the scene identifier is first matched based on the currently running functional components, and then the corresponding computing power allocation ratio and priority level under that scene identifier are read. After configuration, the component identifier, scene identifier, priority level, CPU allocation ratio, memory allocation quota, NPU allocation ratio, resource usage limit, and current running status of each functional component are written to the component registry.

[0017] Step S200: Collect local hardware resource status and component running status in real time through system call interface.

[0018] Furthermore, the method provided in the application embodiments also includes: The hardware resource status includes CPU utilization, memory usage, and NPU computing load, while the component operation status includes component request volume, actual resource usage, and operation status flags.

[0019] In this embodiment, during the operation of the local AI agent, the status of local hardware resources is collected in real time through a system call interface according to a preset collection cycle, which can be set to 100ms / time. At each collection cycle, the system call interface is invoked to read CPU utilization, memory usage, and NPU computing power load. CPU utilization includes total CPU utilization or utilization of individual CPU cores; memory usage is determined based on the total and remaining memory capacity of the local device; and NPU computing power load is the proportion of computing power currently occupied by the NPU in the local device. When the local device does not have an NPU configured, the NPU computing power load is recorded as null or disabled. The collected CPU utilization, memory usage, and NPU computing power load are associated with the corresponding collection timestamps to form a local hardware resource status record.

[0020] Within the same data collection period, the operational status of each functional component in the local AI agent is collected. The component operational status includes component request volume, actual resource usage, and operational status flags. Component request volume refers to the number of requests currently being processed and the number of requests waiting to be processed by the current functional component; actual resource usage refers to the CPU percentage, memory capacity, and NPU computing power usage currently used by the current functional component; operational status flags include running, idle, sleeping, paused, or abnormal. After data collection, the component identifier, component request volume, actual resource usage, and operational status flags of each functional component are associated with the local hardware resource status at the same data collection timestamp to obtain the status collection data used for subsequent comprehensive load index calculation.

[0021] Step S300: Calculate the comprehensive load index based on the hardware resource status and component operating status, and determine the load scenario by matching, wherein the load scenario is a high load scenario, a normal scenario, or a low load scenario.

[0022] In this embodiment, after obtaining the local hardware resource status and component operating status, the CPU utilization rate, memory usage rate, component response lag coefficient, and request queue pressure are normalized to obtain the CPU pressure value, memory pressure value, response lag coefficient, and request queue pressure. Then, a comprehensive calculation formula is used to obtain the comprehensive load index of the current local AI agent.

[0023] Then, the overall load index is matched with the preset scenario threshold. When the overall load index is greater than 0.8, or the CPU pressure value is greater than 0.85 and the response lag coefficient is greater than 0.8, it is judged as a high load scenario; when the overall load index is less than 0.3 and the CPU pressure value is less than 0.3, it is judged as a low load scenario; the rest are judged as normal scenarios.

[0024] Furthermore, in the method provided in the application embodiments, calculating the comprehensive load index based on the hardware resource status and component operating status further includes: Based on the local hardware resource status and component operating status, normalized parameters are determined by normalizing the status parameters. These status parameters include CPU utilization, memory usage, component response lag coefficient, and request queue pressure, which are normalized to a range of 0 to 1. A weighted summation model is used to calculate the normalized parameters to obtain the comprehensive load index.

[0025] Furthermore, the method provided in the application embodiments also includes: The weighted summation model contains a comprehensive calculation formula: S=w1×L cpu +w2×L mem +w3×L lat +w4×Q req ; among which, Lcpu L represents the CPU stress value. mem L represents the memory stress value. lat Q is the response lag factor. req To represent the request queue pressure, w1, w2, w3, and w4 are weighted distributions.

[0026] In this embodiment, after acquiring the local hardware resource status and component running status, CPU utilization and memory usage are read from the local hardware resource status, and component response time and component request volume are read from the component running status as status parameters for calculating the comprehensive load index. The status parameters include CPU utilization, memory usage, component response lag coefficient, and request queue pressure; wherein, CPU utilization is used to determine the CPU pressure value L. cpu Memory utilization is used to determine the memory stress value L. mem The component response time is used to determine the response hysteresis coefficient L. lat The component request volume is used to determine the request queue pressure Q. req Since the data sources and dimensions of the aforementioned state parameters are different, the state parameters are normalized so that they are all mapped to the interval between 0 and 1, resulting in normalized parameters.

[0027] In normalization processing, the CPU stress value L cpu Directly retrieve the CPU usage percentage; for example, when the system call interface collects a CPU usage rate of 85%, the CPU stress value L is... cpu Recorded as 0.85. Memory stress value L mem Calculated based on remaining memory and total memory, the calculation method is L. mem =1 Remaining memory / Total memory; for example, when the total memory is 16GB and the remaining memory is 4GB, the memory pressure value L is... mem =1 4 / 16 = 0.75. Response hysteresis coefficient L lat Based on the current response time t of the P0 priority component and the preset response time threshold T max Calculation, the calculation method is L lat =min(t / T max ,1.0), where T max It can be set to 2000ms; for example, when the current response time of the intelligent question answering component is 1600ms, the response lag coefficient L lat The request queue pressure is 0.8. reqBased on the component request volume, firstly, within the current collection period, count the number of requests currently being processed and the number of requests waiting to be processed for the corresponding functional component, and add them together to obtain the current total request volume. Then, read the pre-set request volume limit for the functional component and compare the current total request volume with the request volume limit. If the current total request volume is less than the request volume limit, the proportion of the current total request volume to the request volume limit is used as the request queue pressure Q. req When the current total number of requests is equal to or greater than the request limit, the request queue pressure Q will be increased. req The maximum value is set to 1.

[0028] Get CPU stress value L cpu Memory stress value L mem Response hysteresis coefficient L lat and request queue pressure Q req Then, a weighted summation model is used to calculate the normalized parameters, yielding the comprehensive load index S. The weighted summation model contains the comprehensive calculation formula S=w1×L. cpu +w2×L mem +w3×L lat +w4×Q req ; among which, L cpu L represents the CPU stress value. mem L represents the memory stress value. lat Q is the response lag factor. req To determine the queue pressure, w1, w2, w3, and w4 are weighted. During calculation, L... cpu L mem L lat and Q req Substitute the corresponding weights into w1 (0.3 to 0.4), w2 (0.2 to 0.3), w3 (0.3 to 0.4), and w4 (0.1 to 0.2), and sum the four products to obtain the comprehensive load index S of the current local AI agent.

[0029] Step S400: Based on the priority level of the functional components and the determined load scenario, perform dynamic allocation of computing power, determine the computing power allocation strategy, and adjust the configuration parameters of each functional component. The configuration parameters include the upper limit of resource consumption, memory quota and running status.

[0030] In this embodiment, after the load scenario is determined, the priority level of each functional component in the component registry is read, and the corresponding computing power allocation strategy is determined according to the current load scenario. If the current scenario is normal, a basic computing power allocation strategy is determined, and the configuration parameters are adjusted according to the basic computing power allocation strategy. The resource usage limit of the P0 priority component is configured to 30% CPU and 800MB memory quota, and it is kept running. The resource usage limit of the P1 priority component is configured to 15% CPU and 300MB memory quota, and it is switched to running or sleeping state depending on whether there is a request. The resource usage limit of the P2 priority component is configured to 5% CPU and 100MB memory quota, and it is switched to running or sleeping state depending on the task status.

[0031] If the current scenario is high-load, with total CPU utilization exceeding 80% or memory utilization exceeding 70%, a resource preemptive computing power allocation strategy is determined, and configuration parameter adjustments are executed according to this strategy: the running status of P2 priority components is adjusted to pause or hibernate, and their occupied resources are released; the resource utilization limit of P1 priority components is adjusted to 50% of the base value, correspondingly reducing their CPU utilization limit and memory quota; the resource utilization limit of P0 priority components is adjusted to 40% CPU and 1GB memory quota, while maintaining their running status. For example, when the intelligent question-answering component and the full-disk search component are running concurrently and the CPU utilization reaches 85%, the CPU utilization limit of the full-disk search component is adjusted from 20% to 10%, and the CPU utilization limit of the intelligent question-answering component is adjusted to 40%, with the memory quota adjusted to 1GB.

[0032] If the current scenario is low-load, and the total CPU utilization does not exceed 30% and memory utilization does not exceed 40%, then an elastic scaling computing power allocation strategy is determined, and configuration parameter adjustments are performed according to this strategy: the CPU utilization limit of the currently running P0 priority component is adjusted to 50%, and it remains running; the basic resource utilization limit and memory quota are maintained for P1 priority components with requests, and P1 priority components without requests are switched to a dormant state; the running state of P2 priority components is switched based on whether there are task requests. After the adjustments are completed, the updated resource utilization limit, memory quota, and running state of each functional component are written to the component registry, so that each functional component runs according to the determined computing power allocation strategy.

[0033] Furthermore, the method provided in the application embodiments also includes: After adjusting the configuration parameters of each functional component, the process also includes handling concurrent conflicts among components. When there are at least two concurrent requests from components of the same priority, a time-slice rotation strategy is triggered. According to the time-slice rotation strategy, the target task is split into a set of micro-tasks, and the set of micro-tasks is assigned to components of the same priority. Component-driven task management is then implemented. If the concurrent requests involve components of the same priority that include core components and non-core components, the core components have response priority.

[0034] In this embodiment, after adjusting the configuration parameters of each functional component, concurrent conflict handling is performed on the functional components in the running state. Specifically, the priority level, request queue, target task, and running status flag of each functional component are read, and the functional components are grouped according to their priority level. When at least two functional components at the same priority level have non-empty request queues, it is determined that there are at least two concurrent requests from components of the same priority, and a time-slice rotation strategy is triggered. For example, if the full-disk search component and the word-selection translation component both belong to the P1 priority component, and both have search requests and word-selection translation requests in the same collection period, the concurrent conflict handling process for the P1 priority component is entered.

[0035] After triggering the time-slice round-robin strategy, a round-robin queue is established for components of the same priority participating in concurrent requests, and the target task of each functional component is split into a set of microtasks. The target task is the complete processing task corresponding to the current request of the functional component, and the set of microtasks consists of multiple independently schedulable subtasks obtained according to the execution order. For example, the target task of the full-disk search component is split into index location microtasks, index reading microtasks, result filtering microtasks, and result return microtasks; the target task of the word-selection translation component is split into text extraction microtasks, text processing microtasks, translation invocation microtasks, and result return microtasks. Subsequently, the microtask sets are allocated to components of the same priority according to the time-slice round-robin strategy, and components of the same priority are driven to execute alternately using a preset time slice. The preset time slice can be set to 16ms. At the end of the current time slice or after the current microtask is completed, the execution progress of the corresponding functional component's microtask is recorded, and execution is switched to the next functional component in the round-robin queue.

[0036] When managing component-driven task alternation, the memory quota limit is dynamically calculated based on the number of real-time active components. The number of real-time active components, N, represents the number of functional components currently running and participating in concurrent request processing. The memory quota limit is calculated as available memory × 0.8 / N. After calculation, the current memory usage of each component of the same priority is compared with the memory quota limit. When the memory usage of any functional component exceeds the memory quota limit, a cache cleanup mechanism is triggered to release the cached data of that functional component and update its memory usage record and running status flag.

[0037] If concurrent requests involve components of the same priority, including both core and non-core components, the core component is given response priority in the time-slice round-robin strategy. Specifically, the core component flag of the components of the same priority participating in the concurrent request is read; when a core component has pending microtasks, it is placed at the beginning of the current round-robin cycle, and its microtasks directly related to the user response are executed first; when the core component's response task is not yet completed, its unfinished microtasks continue to be prioritized in the next time slice. Microtasks of non-core components enter the round-robin execution after the core component completes its current response microtask. After handling component concurrency conflicts, the microtask execution progress, request queue status, memory usage, and running status flags of each component of the same priority are written to the component registry.

[0038] Furthermore, in the method provided in the application embodiments, the execution component's alternating task-driven management further includes: The memory quota limit is dynamically calculated based on the number of active components in real time. The memory quota limit is calculated as: (available memory × 0.8) / N, where N is the number of active components in real time. When the memory usage of a component exceeds the memory quota limit, a cache cleanup mechanism is triggered.

[0039] In this embodiment, during the component alternation task-driven management process, the number of functional components currently participating in concurrent request processing and in running state is counted in real time, and this number is determined as the number of real-time active components N. Then, the currently available memory of the local device is read; available memory is the remaining memory capacity after deducting the occupied memory capacity from the total memory capacity. After obtaining the available memory and the number of real-time active components N, the memory quota limit corresponding to each real-time active component is calculated according to "memory quota limit = available memory × 0.8 / N". After the calculation is completed, the component memory usage of each real-time active component is read, and the component memory usage is compared with the memory quota limit. When the component memory usage of a certain functional component is greater than the memory quota limit, it is determined that the functional component has exceeded the memory quota under the current concurrency scenario, and a cache cleanup mechanism is triggered.

[0040] After the cache cleanup mechanism is triggered, cache release processing is performed on functional components that exceed the memory quota limit. Specifically, the cached data generated during the operation of the functional component is first identified, including search result cache, historical request cache, temporary file cache, and intermediate calculation result cache; then, the corresponding cached data is cleaned up according to the least recently used rule, and the memory space occupied by the functional component is released; after the cache cleanup is completed, the component memory usage of the functional component is re-collected, and the updated component memory usage is compared with the memory quota limit. If the updated component memory usage is not greater than the memory quota limit, the component's alternating task-driven management continues; if the updated component memory usage is still greater than the memory quota limit, cache cleanup continues, or some tasks of the functional component are switched to a paused state, and the running status flag of the functional component is updated.

[0041] Step S500: Lightweight collaboration and fault isolation between functional components are performed through process isolation and memory partitioning. When an abnormality of a functional component is detected, automatic degradation or restart is triggered.

[0042] In this embodiment, during the operation of functional components, lightweight collaboration and fault isolation between functional components are achieved through process isolation and memory partitioning. Specifically, functional components are assigned running processes according to their priority level and business type. P0 priority components run in an independent rendering process, while P1 and P2 priority components run in rendering processes distinct from those of the P0 priority components. The P0 priority components include an intelligent question-answering component and a knowledge base retrieval component; the P1 priority components include a full-disk search component and a word-selection translation component; and the P2 priority components include an application center component and a loading page component. This separates core and non-core components at the process level, ensuring that the operation of the P0 priority component's process is not directly interrupted when a non-core component crashes, blocks, or abnormally occupies memory.

[0043] When performing lightweight collaboration between functional components, data interaction occurs through pre-loaded scripts and global state management. The text, search results, or call parameters generated by the first functional component are written to the global cache, generating a corresponding cache identifier. The second functional component reads the data corresponding to the cache identifier through a standardized API, instead of repeatedly transmitting complete data between different processes. For example, after the word-selection translation component extracts the user-selected text, it writes the selected text to the global cache. The intelligent question-answering component reads the selected text through the cache identifier and initiates question-answering processing. When the intelligent question-answering component needs to call the full-search component, it initiates a temporary collaboration request to the full-search component through a standardized API. After the full-search component performs the index query and returns the results, it releases its computing power and switches to a dormant state.

[0044] Building upon process isolation, memory partitioning is implemented for each functional component. Specifically, each functional component is allocated a corresponding independent memory space, and its identifier, memory partition identifier, memory usage, and running status flags are recorded. During component execution, its cached data, temporary data, and intermediate calculation results are written to the corresponding memory partition. When a functional component experiences abnormal memory growth or needs to release resources, only the memory partition corresponding to that component is reclaimed, preventing abnormal data from continuing to occupy global memory. Thus, memory partitioning limits the scope of memory impact of functional components and, in conjunction with process isolation, achieves fault isolation.

[0045] During operation, anomalies in functional components are detected. Each functional component sends a heartbeat packet at preset time intervals, including the component identifier and timestamp. If a heartbeat is lost for more than 3000ms, the corresponding functional component is considered to be inactive. Process monitoring determines the existence of the process corresponding to the functional component; if the process identifier disappears, the corresponding functional component is considered to have crashed. Process metrics are used to read the heap memory usage and handle count of the functional component; if heap memory usage consistently exceeds a preset memory threshold, the corresponding functional component is considered to have a memory leak. The execution time of critical business functions is monitored; if a single query takes more than 5 seconds, the corresponding functional component is considered to have timed out.

[0046] When a functional component malfunction is detected, automatic degradation or restart is triggered based on the malfunction type. If a process crash is detected, the corresponding functional component's running process is recreated and restored to operation according to the configuration parameters in the component's registry. If a component appears to be frozen, the corresponding functional component's process is forcibly terminated and then restarted. If a memory leak is detected, the memory partition of the corresponding functional component is reclaimed and memory space is reallocated. If a business timeout is detected, automatic degradation is triggered, switching the corresponding functional component from full running mode to basic running mode. For example, the full-disk search component disables semantic matching when the index query times out, and only performs filename retrieval. After completing automatic degradation or restart, the running status flags, memory partition status, and process status of the corresponding functional component are updated.

[0047] Furthermore, in the method provided in the application embodiments, when an abnormality in a functional component is detected, it further includes: Through a heartbeat keep-alive mechanism, functional components send heartbeat packets at preset time intervals and perform multi-level exception management. Specifically, the main process maintains component heartbeat records, and when the heartbeat loss exceeds a preset timeout threshold, the component is judged to be faulty and forced termination is triggered. The main process polls to obtain the heap memory usage and handle count of the component process, and when it exceeds a preset memory threshold, memory partition reclamation is triggered. Exceptions are monitored for critical business functions, and automatic degradation is triggered when the time taken for a single query exceeds a preset business timeout threshold.

[0048] In this embodiment, during the operation of a functional component, a heartbeat keep-alive mechanism is used to enable the component to send heartbeat packets at preset time intervals, and multi-level exception management is performed based on these heartbeat packets. Specifically, each functional component sends a heartbeat packet to the main process at a preset time interval. The heartbeat packet includes a component identifier, a sending timestamp, and a running status flag. The preset time interval can be set to 500ms. After receiving the heartbeat packet, the main process maintains the component heartbeat record according to the component identifier and updates the most recent heartbeat time under the corresponding component identifier to the sending timestamp. The main process reads the component heartbeat record according to the monitoring cycle and compares the current time with the most recent heartbeat time. When the heartbeat loss exceeds a preset timeout threshold, the corresponding functional component is determined to have experienced a component failure, and a forced termination is triggered. The preset timeout threshold can be set to 3000ms. When a forced termination is triggered, the main process sends a termination command to the corresponding component process, ending the component process and updating the running status flag of the functional component to abnormal or terminated.

[0049] While executing the heartbeat keep-alive mechanism, the main process polls to obtain the heap memory usage and handle count of each component process. Specifically, the main process reads the heap memory usage and handle count of each component process according to a preset polling cycle, and stores the reading results in association with the component identifier. Heap memory usage represents the memory capacity that a component process has allocated but not released, and the handle count represents the number of system objects currently held by the component process. When the heap memory usage of any functional component exceeds a preset memory threshold, it is determined that the functional component has abnormal memory usage, and memory partition reclamation is triggered. The preset memory threshold can be set to 500MB. When memory partition reclamation is triggered, cached data, temporary data, and intermediate calculation results in the corresponding memory partition of the functional component are released, and the memory usage and running status flags of the functional component are updated.

[0050] When monitoring for exceptions in critical business functions, the start time is recorded at the execution entry point and the end time at the execution exit point. The time taken for a single query is determined based on the start and end times. Critical business functions include at least one of index queries, knowledge base retrieval, local large model calls, and result returns. When the time taken for a single query exceeds a preset business timeout threshold, the corresponding functional component is determined to have experienced a business timeout, and automatic degradation is triggered. The preset business timeout threshold can be set to 5 seconds. After triggering automatic degradation, the corresponding functional component is switched from full running mode to basic running mode. For example, the full-disk search component disables semantic matching and performs filename retrieval when the index query times out. After completing forced termination, memory partition reclamation, or automatic degradation, the exception type, trigger time, handling method, and updated running status flags are written to the component status record.

[0051] Furthermore, the method provided in the application embodiments also includes: A multi-process architecture and memory partitioning tool are used to isolate faults between functional components. The multi-process architecture runs core components in the first rendering process and non-core components share the second rendering process. The memory partitioning tool allocates independent memory space to each functional component. When a functional component malfunctions, the component's running mode is downgraded.

[0052] In this embodiment, a multi-process architecture is used to divide the functional components into processes when performing fault isolation between them. Specifically, core components run in a first rendering process, while non-core components are shared in a second rendering process. The core components include an intelligent question-answering component and a knowledge base retrieval component, while the non-core components include a full-disk search component, a word-selection translation component, an application center component, and a loading page component. The first rendering process is used to run the intelligent question-answering component and the knowledge base retrieval component, while the second rendering process is used to run the full-disk search component, the word-selection translation component, the application center component, and the loading page component. When a non-core component in the second rendering process crashes, blocks, or abnormally consumes resources, the abnormal component is handled within the second rendering process. When a core component in the first rendering process malfunctions, the corresponding core component is handled within the first rendering process, thereby limiting the impact of functional component malfunctions through the multi-process architecture.

[0053] While adopting a multi-process architecture, independent memory spaces are allocated to each functional component using a memory partitioning tool. Specifically, corresponding memory partitions are created for the intelligent question-answering component, knowledge base retrieval component, full-disk search component, word-selection translation component, application center component, and loading page component, and the component identifier, memory partition identifier, partition capacity, current memory usage, and running status flags are recorded. During the operation of each functional component, its cached data, temporary data, and intermediate calculation results are written to the corresponding independent memory space; when an abnormal operation of a functional component is detected, the memory partition corresponding to that functional component is reclaimed, releasing the cached data, temporary data, and intermediate calculation results in that memory partition, so that the memory usage of the abnormal functional component does not affect the global memory.

[0054] When a functional component malfunctions, its runtime mode is downgraded. This downgrading includes disabling extended processing flows in the malfunctioning component, retaining basic processing flows that can continue, or pausing the malfunctioning component and prompting the user. For example, if the full-disk search component experiences an index query timeout, semantic matching is disabled, and the search is performed only by filename; if the word-selection translation component malfunctions, the text extraction flow is retained, but extended processing flows are paused; if the application center component or loading page component continues to malfunction, the corresponding functional component's runtime is paused, and an error message is displayed. After completing the runtime mode downgrading, the runtime status flags, memory partition status, and rendering process status of the corresponding functional component are updated.

[0055] Furthermore, in the method provided in the application embodiments, the lightweight collaboration between functional components further includes: Core components and non-core components initiate temporary collaboration requests through standardized APIs. After executing the request, non-core components immediately release computing power and enter a dormant state. Functional components communicate with each other in a lightweight manner through pre-loaded scripts and global state management. Among them, the data extracted by the first functional component is directly stored in the global cache, and the second functional component reads the data from the global cache.

[0056] In this embodiment, when performing lightweight collaboration between functional components, the core component initiating the collaboration and the non-core component being called are first determined according to the component registry. The core components include the intelligent question-answering component and the knowledge base retrieval component, while the non-core components include the full-disk search component, the word-selection translation component, the application center component, and the loading page component. When a core component needs to call a non-core component to complete auxiliary processing, the core component initiates a temporary collaboration request through a standardized API. The temporary collaboration request carries the identifier of the requesting component, the identifier of the requesting component, the request type, the request parameters, and the result return path. After receiving the temporary collaboration request, the non-core component performs the corresponding processing according to the request type, and after the processing result is returned, it calls the resource release interface to release the CPU resources, memory resources, and NPU computing power resources occupied by this request, and then updates its running state to a dormant state. For example, when the intelligent question-answering component needs to query local files during the answer generation process, it initiates a local file retrieval request to the full-disk search component through a standardized API. After the full-disk search component performs the index query and returns the retrieval results, it clears the temporary cache generated by this retrieval, releases the corresponding computing power resources, and enters a dormant state.

[0057] Lightweight communication between functional components is achieved through preloaded scripts and a global state management system. The preloaded scripts provide a controlled communication entry point within the rendering process of each functional component, enabling them to write to or read shared data via a unified interface. The global state management system records the cache identifier, data type, source component identifier, target component identifier, and write time of the shared data. During data transfer, the data extracted by the first functional component is directly stored in the global cache, and the generated cache identifier is written to the global state management system. When the second functional component needs to use this data, it reads the cache identifier through a standardized API and then retrieves the data from the global cache based on the cache identifier. Therefore, functional components transfer cache identifiers and structured state information, rather than repeatedly copying complete data between different functional components.

[0058] For example, after the word-selection translation component, as the first functional component, extracts the user-selected text, it directly stores the selected text in the global cache and writes the text cache identifier, word-selection translation component identifier, and data write time into the global state management. When the intelligent question-answering component, as the second functional component, receives a question-answering request initiated by the user based on the selected text, it reads the text cache identifier through a standardized API and retrieves the selected text from the global cache for question-answering processing. As another example, when the intelligent question-answering component calls the full-disk search component to complete a local file retrieval, the full-disk search component writes the retrieval results to the global cache and returns a result cache identifier. The intelligent question-answering component then reads the retrieval results from the global cache based on the result cache identifier. After completing the reading, the corresponding non-core components release the computing resources occupied by this collaborative request and enter a dormant state.

[0059] In summary, the embodiments of this application have at least the following technical effects: This application performs lightweight processing on multiple functional components of a local AI agent, configuring priority levels for each component. The lightweight processing includes streamlining redundant functions, encapsulating lightweight interaction interfaces, and setting maximum resource consumption thresholds. Local hardware resource status and component operating status are collected in real-time via system call interfaces. A comprehensive load index is calculated based on the hardware resource status and component operating status, and a load scenario is determined through matching, where the load scenario is high-load, normal, or low-load. Dynamic computing power allocation is performed based on the priority levels of the functional components and the determined load scenario, determining the computing power allocation strategy and adjusting the configuration parameters of each functional component. These configuration parameters include resource consumption limits, memory quotas, and operating status. Lightweight collaboration and fault isolation between functional components are performed through process isolation and memory partitioning. Automatic degradation or restart is triggered when an abnormality is detected in a functional component. This invention addresses the technical problems of rigid computing power allocation and difficulty in guaranteeing the response speed of core components when multiple components of a local AI agent are running concurrently in the prior art. By configuring priority levels for functional components and combining real-time collected hardware resource status and component operating status to determine the load scenario, the invention dynamically adjusts the resource usage limit, memory quota, and operating status of each functional component, thereby achieving the technical effect of prioritizing the computing power needs of core components and improving the response efficiency of the local AI agent.

[0060] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0061] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for dynamic allocation of computing power under the collaboration of lightweight components in a local AI agent, characterized in that, The method includes: The local AI agent performs lightweight processing on multiple functional components and configures priority levels for each functional component. The lightweight processing includes streamlining redundant functions of components, encapsulating lightweight interaction interfaces, and setting a maximum resource consumption threshold. The system call interface is used to collect the status of local hardware resources and the running status of components in real time. The comprehensive load index is calculated based on the hardware resource status and component operating status. The load scenario is determined by matching, where the load scenario is a high load scenario, a normal scenario, or a low load scenario. Dynamic computing power allocation is performed based on the priority level of functional components and the determined load scenario. The computing power allocation strategy is determined and the configuration parameters of each functional component are adjusted. The configuration parameters include the upper limit of resource consumption, memory quota and running status. Among them, lightweight collaboration and fault isolation between functional components are achieved through process isolation and memory partitioning, and automatic degradation or restart is triggered when an abnormality of a functional component is detected.

2. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, Configure priority levels, including: By accessing historical runtime data, we can extract scenario-specific component combinations and computing power allocation ratios based on component response times, and use this as a configuration file. Priority levels can be configured for each functional component through configuration files.

3. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, The hardware resource status includes CPU utilization, memory usage, and NPU computing load, while the component operation status includes component request volume, actual resource usage, and operation status flags.

4. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, The comprehensive load index is calculated based on the hardware resource status and component operating status, including: Based on the local hardware resource status and component running status, normalization parameters are determined by normalizing the status parameters. These status parameters include CPU utilization, memory usage, component response lag coefficient, and request queue pressure. The normalization process maps these parameters to the range of 0 to 1. The weighted summation model is used to calculate the normalized parameters to obtain the comprehensive load index.

5. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 4, characterized in that, The weighted summation model contains a comprehensive calculation formula: S=w1×L cpu +w2×L mem +w3×L lat +w4×Q req ; Among them, L cpu L represents the CPU stress value. mem L represents the memory stress value. lat Q is the response lag factor. req To account for the request queue pressure, w1, w2, w3, and w4 are weighted distributions.

6. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, After adjusting the configuration parameters of each functional component, the process also includes handling component concurrency conflicts. When at least two components of the same priority make concurrent requests, the time-slice rotation strategy is triggered. According to the time-slice rotation strategy, the target task is divided into a set of micro-tasks, and the set of micro-tasks is assigned to components of the same priority, and the components are managed in an alternating task-driven manner. If concurrent requests involve components of the same priority, including both core and non-core components, the core components have response priority.

7. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 6, characterized in that, Execution component alternation task-driven management, including: The memory quota limit is dynamically calculated based on the number of active components in real time. The memory quota limit is calculated as: (available memory × 0.8) / N, where N is the number of active components in real time. Specifically, when the component's memory usage exceeds the memory quota limit, a cache cleanup mechanism is triggered.

8. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, An anomaly was detected in a functional component, including: Through the heartbeat keep-alive mechanism, functional components send heartbeat packets at preset time intervals to perform multi-level exception management; The main process maintains the component's heartbeat record. When the heartbeat is lost for more than a preset timeout threshold, the component is determined to be faulty and a forced termination is triggered. The main process polls to obtain the heap memory usage and handle count of the component process. When the preset memory threshold is exceeded, memory partition reclamation is triggered. Monitor critical business functions for exceptions and trigger automatic degradation when the time taken for a single query exceeds a preset business timeout threshold.

9. The method for dynamic allocation of computing power under the collaboration of lightweight components of a local AI agent as described in claim 1, characterized in that, A multi-process architecture and memory partitioning tools are used to isolate faults between functional components. The system employs a multi-process architecture, where core components run in the first rendering process and non-core components are shared in the second rendering process. The memory partitioning tool allocates independent memory space to each functional component. When a functional component malfunctions, the component's operating mode is downgraded.

10. The method for dynamic allocation of computing power under the collaboration of lightweight components in a local AI agent as described in claim 1, characterized in that, Lightweight collaboration between functional components includes: Core components and non-core components initiate temporary collaboration requests through standardized APIs. After executing the request, the non-core components immediately release computing power and enter a dormant state. Functional components communicate with each other in a lightweight manner through preloaded scripts and global state management; The data extracted by the first functional component is directly stored in the global cache, while the data is read from the global cache by the second functional component.

Images