Large-model multi-core task custom scheduling system and method based on prompt learning

Abstract

The invention discloses a large-model multi-core task custom scheduling system and method based on prompt learning, and the method comprises the steps: inputting a scheduling target through a natural language Prompt by a user, analyzing semantics through a large-scale language model, and automatically generating a corresponding multi-core task scheduling instruction; comprising a Prompt input analysis module, a large model scheduling reasoning module, a scheduling execution and feedback module and a knowledge base storage module. The system supports multi-round dialogue optimization, and a user can interactively adjust a scheduling strategy. The large model engine provides explanation for each scheduling decision, clarifies reasons and influences of adopting the strategy, and realizes interpretability and transparency of the scheduling decision. And the knowledge base module continuously updates the optimization strategy in combination with the historical Prompt and the scheduling effect to realize context-aware adaptive scheduling. According to the method and the device, the scheduling strategy is allowed to be flexibly customized in a dialogue mode, the intellectualization and usability of resource management of an operating system are improved, and the efficiency and the effect of multi-core scheduling can be remarkably improved especially in scenes of cloud computing, intelligent operation and maintenance and the like.

Description

Technical Field

[0001] This invention relates to the technical fields of computer operating systems and artificial intelligence, and in particular to a custom scheduling system and method for large-scale multi-core tasks based on prompting learning. Background Technology

[0002] Modern operating systems must balance performance, power consumption, and resource utilization when scheduling tasks on multi-core processors. Traditional scheduling algorithms (such as priority scheduling, round-robin, and shortest task first) typically use fixed rules and heuristics, making it difficult to adapt to complex and ever-changing workloads and user needs. With the proliferation of computing hardware (especially multi-core CPUs and heterogeneous computing architectures), traditional scheduling methods are becoming increasingly inadequate for high-concurrency, large-scale parallel computing scenarios. For example, when power consumption needs to be reduced, the operating system scheduling needs to consider CPU frequency, idle cores, and task binding; when the utilization of specific devices (such as GPUs) needs to be improved, task priorities and resource allocation need to be dynamically adjusted. However, most operating systems currently only provide limited policy adjustment interfaces, requiring administrators to possess professional knowledge and manually adjust scheduling parameters via command lines or configuration files. This approach is complex, unintuitive, and lacks automation.

[0003] Some existing scheduling systems rely excessively on manual instructions and fixed configurations, resulting in limited intelligence. For example, research indicates that traditional scheduling systems heavily depend on manual command and control, with low automation levels. Automation is only partially achieved in low-intelligence, high-repetition stages, failing to meet the future demands for flexibility and intelligence in scheduling systems. This leads to difficulties in timely adjustments to scheduling strategies when application requirements change or system states fluctuate, potentially resulting in performance degradation or resource waste. On the other hand, the development of artificial intelligence technology in recent years has provided new approaches to optimizing complex decision-making problems. In particular, methods such as deep reinforcement learning (DRL) have been tested for use in operating system scheduling. By learning strategies from historical scheduling data, they adaptively adjust task priorities and resource allocation based on real-time system states. Experiments show that these intelligent scheduling algorithms can significantly improve task completion efficiency, system throughput, and response speed under different load conditions compared to fixed strategies.

[0004] However, even with the introduction of AI optimization, current intelligent scheduling solutions still suffer from insufficient human-computer interaction and controllability. Many AI scheduling algorithms, such as reinforcement learning, are "black box" models, lacking interpretability of the decision-making process, making it difficult for system administrators to understand and trust scheduling decisions in a timely manner. If scheduling strategies are not transparent, enterprises or users will have concerns about scheduling critical tasks because they cannot understand why a task has been postponed or relocated. This lack of transparency can easily lead to inefficiency or misuse of resources, weakening the effectiveness of scheduling optimization.

[0005] Meanwhile, with the rise of Large Language Models (LLMs) such as GPT-4, the possibility of managing complex tasks through natural language and systems has emerged. OpenAI's latest GPT-4 version introduces task scheduling capabilities, enabling models to understand and manage complex task sequences, rather than simply generating text. This allows AI assistants to dynamically adjust the execution order and resource allocation of tasks based on real-time conditions. Similarly, frameworks such as "HuggingGPT" proposed by Microsoft Research and others utilize LLMs as controllers to plan and schedule tasks across different models and tools, demonstrating the potential of large models in cross-domain task orchestration. These trends indicate that natural language-driven task scheduling is becoming possible, with the advantage that users only need to describe the goal, and the AI ​​can autonomously decompose tasks, allocate resources, and provide results.

[0006] In the field of operations and maintenance (O&M), multi-agent collaborative systems are beginning to combine LLM (Limited Leverage Management) with traditional workflows to achieve orchestratable and interactive scheduling. For example, one study built an AIOps multi-scenario intelligent O&M system that introduced checkpoints for human-machine interaction, soliciting human feedback at key decision-making nodes before deciding on the next step. This human-machine collaborative model improves the credibility and flexibility of system decision-making. This demonstrates that combining the experience of human experts with AI decision-making can achieve scheduling that is both automatic and controllable.

[0007] In summary, the existing technology has the following shortcomings: (1) The scheduling strategy lacks intelligence and flexibility, and it is difficult to adapt and optimize in a timely manner according to the user's high-level goals (such as low power consumption, priority of specific devices, etc.); (2) The scheduling decision process is not transparent to the user, lacks interpretability, and is difficult for human intervention and adjustment; (3) There is a lack of human-computer interaction means, and system administrators cannot directly intervene or guide the scheduling process through natural language.

[0008] To address the aforementioned issues, a new scheduling system is urgently needed that can understand the scheduling objectives expressed by natural language prompts, leverage the reasoning capabilities of large models to generate corresponding scheduling strategies, and support multi-turn dialogue optimization and explanation of decision-making reasons. Summary of the Invention

[0009] To address the shortcomings of existing technologies, the present invention aims to provide a large-model multi-core task custom scheduling system based on prompting learning. This system allows system administrators or users to directly specify operating system scheduling targets using natural language. The system automatically parses the user's intent using a large language model and converts it into specific multi-core task scheduling policy instructions, thereby achieving conversational operating system scheduling management. This system aims to improve the intelligence, flexibility, and controllability of operating system scheduling, overcoming the rigidity and lack of interpretability of scheduling policies in existing technologies. To achieve the above-mentioned objectives and other advantages of the present invention, a large-model multi-core task custom scheduling system based on prompting learning is provided, comprising: The Prompt input parsing module receives and preprocesses the user's natural language scheduling objective description (Prompt). This module performs word segmentation and syntactic analysis on the Prompt to extract key scheduling requirement words. For example, the user input "maintain low-power operation" will be parsed to reveal power-related intents; "prioritize GPU tasks" will extract requirements related to GPU resource scheduling priority; and "reduce inter-core migration" will identify constraints related to task binding and migration frequency. The parsed information can be structured and used as input for subsequent large-scale model inference.

[0010] Large-Model Scheduling Inference Engine: This module incorporates a large pre-trained language model (such as the GPT series), optimized through prompting-based learning for scheduling tasks. It receives structured scheduling requests or direct natural language prompts from the Prompt parsing module, combines them with the current system state and historical context, and generates a corresponding set of scheduling policy instructions. The large model utilizes its learned knowledge to infer scheduling schemes that meet the user's goals, including but not limited to: adjusting task priorities, allocating / migrating tasks across different CPU cores, adjusting CPU / GPU frequency and power consumption modes, and modifying thread affinity to reduce cross-core migration. The large-model engine also generates a natural language explanation of the policy, explaining why these scheduling decisions are made for user comprehension.

[0011] The scheduling strategy execution and feedback module receives scheduling instructions from the large model and executes corresponding operation strategies at the operating system kernel or management level. Specifically, it calls underlying operating system interfaces (such as CPU frequency adjustment APIs, task binding settings, and scheduling parameter adjustments) to implement the strategy. For example, under the "low power" strategy, the execution module can call the operating system's energy management interface to switch the CPU scheduling mode to power-saving mode; under the "GPU priority" strategy, it can increase the priority of GPU task threads or offload more computing tasks to the GPU; under the "reduce migration" strategy, it sets CPU affinity for processes to fix them running on a specific core. During execution, this module continuously monitors key system indicators (such as CPU utilization of each core, task completion time, power consumption level, temperature, etc.) and feeds back the execution effect data and system status to the large model engine and the Prompt parsing module. On the one hand, the large model can evaluate the effect of the strategy based on this and adjust the strategy in the next round of dialogue if necessary; on the other hand, the feedback module will also generate a brief report or prompt feedback to the user, including the execution result and effect summary of the current scheduling strategy.

[0012] Knowledge Base and Historical Context Cache: This system includes a scheduling knowledge base to store historical prompts, system states, and corresponding generated scheduling strategies and execution effects. The knowledge base can be in the form of a database or files, recording the intent of each user interaction, the system response strategy, and post-execution performance metrics. This constitutes a context cache, supporting the context-aware capabilities of large models: when a new prompt arrives, the large model engine can retrieve relevant historical cases as a reference for experience-based adaptive adjustments (Context-Aware Adaptation). For example, if a user has repeatedly prompted "low power" and ultimately chosen a certain performance sacrifice range, the model will learn the user's preferred power-performance balance point from the knowledge base and directly generate a more suitable strategy for similar requests in the future. The knowledge base can also integrate general scheduling optimization rules and prior knowledge (such as Linux energy consumption models, common performance tuning experiences, etc.) to enrich the basis for large model inference.

[0013] The above modules work together to implement a prompt-driven scheduling process: users propose high-level scheduling goals via natural language, the large model automatically translates them into executable low-level scheduling instructions, the execution module applies them to the system and provides feedback. The entire process supports multi-round dialogue optimization, meaning users can continue to propose new requirements or fine-tune the prompt based on the feedback from the previous round. The large model will refer to the new instructions and existing context to further optimize the scheduling strategy, gradually bringing the system closer to the user's expectations.

[0014] Compared with the prior art, the advantages and positive effects of the present invention are: 1. Prompt-driven custom scheduling: Breaking away from the traditional model of configuring scheduling with static parameters, this system introduces a Prompt-driven mechanism. Users only need to provide a high-level natural language description (such as "keep low power"), and the system can automatically parse and map it to specific scheduling actions. Compared to manually adjusting kernel parameters, this lowers the technical barrier and improves the flexibility and efficiency of scheduling strategy customization.

[0015] 2. Conversational Operating System Management: This system supports multi-turn dialogue interaction, forming a new paradigm for operating system management similar to a chat application. Users can continuously make requests, inquire about system status, or ask the system to explain the basis for their decisions, with the system responding and optimizing in real time. This human-machine collaborative scheduling method makes operating system management more intuitive, enabling complex configurations to be completed through dialogue, achieving unprecedented ease of use. System administrators can control system behavior as if conversing with an assistant, improving the operational experience.

[0016] 3. Automated Explanation and Transparent Decision-Making: The system has a built-in explanation generation mechanism that uses a large model to generate natural language explanations, detailing the rationale and expected impact of each scheduling decision. For example, when a user requests low power consumption, the system might explain: "The CPU clock speed has been reduced and high-power cores have been limited to reduce energy consumption; the expected performance drop is no more than 20%." This transparency makes the scheduling process no longer a black box, enhancing user trust and control over automated scheduling. Users can better understand system behavior based on the explanations and make adjustments when necessary.

[0017] 4. Historical Adaptation and Knowledge Accumulation: By introducing a knowledge base, this system can memorize and learn from historical scheduling experience, achieving context-aware adaptation. When encountering similar situations or prompts, the system will refer to previously successful strategies, reducing redundant exploration. For example, in a cloud data center environment, typical load patterns and corresponding optimal strategies for different time periods can be learned and stored for direct future use. This experience-based learning improves the speed and effectiveness of scheduling strategy optimization and makes the system increasingly intelligent with use.

[0018] 5. Wide Applicability: The framework proposed in this invention is independent of specific hardware / operating system implementations and can be ported to various multi-core or heterogeneous computing environments. For example, on mobile devices, it can be used to dynamically balance performance and battery life according to user needs; in server and cloud environments, it can be used for intelligent management of computing resource allocation; and in edge computing and the Internet of Things, it can simplify the scheduling and configuration of resource-constrained devices through natural language commands. Therefore, it has broad application prospects. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the architecture of a custom scheduling system for large-scale multi-core tasks based on prompting learning according to the present invention. Figure 2 The flowchart of the custom scheduling system for large-scale multi-core tasks based on prompting learning according to the present invention is shown below. Detailed implementation. The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The invention can be implemented in software, hardware, or a combination of both. For example, the large model scheduling inference engine can run in the cloud, with the execution module controlling the local operating system kernel via API; or the entire system can be integrated as part of the operating system to achieve local autonomous decision-making. The system of this invention adopts a modular architecture design, such as... Figure 1 As shown, users input scheduling requests (Prompts) through a natural language interface (such as a chat window or voice assistant), and the system processes these requests sequentially through multiple functional modules to achieve complete closed-loop control.

[0021] Reference Figure 1 A custom scheduling system for large-scale multi-core tasks based on cue learning, comprising: Prompt input parsing module: This module serves as the system's front-end entry point, its primary function being to transform unstructured natural language into structured scheduling request representations. Its implementation can be based on existing Natural Language Processing (NLP) technologies, including word segmentation, part-of-speech tagging, named entity recognition, dependency parsing, and semantic role labeling. Given the diverse range of user expressions, the module needs to possess a certain degree of robustness and fault tolerance. Keyword Extraction: The module has a built-in keyword library related to scheduling, such as "power consumption, performance, temperature, GPU, CPU, memory, priority, real-time, latency, bandwidth, migration, binding, load balancing," etc., as well as a corresponding thesaurus. By quickly scanning the prompt, it initially extracts words related to intent. For example, a user saying "reduce energy consumption" is equivalent to "low power consumption"; "complete GPU computing as soon as possible" means "GPU task priority," etc.

[0022] Template matching: For common requirements, several templates can be preset for matching. For example, the pattern "keep X mode running for Y time" can be parsed into two parameters: target X and time Y. If the prompt matches a certain template, the parameters are directly extracted according to the template and filled into the structured format, improving efficiency and accuracy.

[0023] Deep parsing: For complex or long prompts, pre-trained language models or semantic parsing models can be invoked. For example, a Transformer model can be used to perform intent classification and slot filling (similar to NLU in dialogue systems). For instance, in a prompt like, "Please schedule batch processing tasks for the next two days at night to minimize the impact on user services," the model needs to identify the time frame as the next two days, the preference as nighttime scheduling, and the constraint as minimizing impact on user services (which might mean lowering the priority of batch processing tasks or limiting CPU affinity to non-critical cores). This implicit information can only be extracted through the contextual understanding of deep models.

[0024] Contextual coherence: In multi-turn dialogues, the parsing module needs to consider the dialogue history. For example, in the previous round, the user asked, "What is the current system power consumption?", and the system responded, "About 50W." In the next round, the user directly says, "Then reduce it to around 30W." The second sentence alone doesn't have a clear subject; it needs to be inferred from the preceding context that the user wants to reduce the system power consumption to 30W. This requires the parsing module to retain contextual references, interpreting "reduce to 30W" as "reduce the system power consumption to 30W." Similarly, pronouns, ellipses, etc., also require contextual inference.

[0025] The output of the parsing module can take two forms: one is an intermediate semantic representation (such as an abstract syntax tree, logical form, or DSL statement) for further processing by the large model; the other is a direct Prompt for the large model. In this embodiment, the large model itself excels at language understanding, so the parsing module can be relatively simplified, adding some structural hints to the original user Prompt for the model to use. For example, a system message can be appended before the Prompt: "User request:" followed by the original user text. The large model will complete its understanding and decision-making within the context. To enhance reliability, a dual-mode parsing can also be used: the parsing module provides machine-readable structured parameters and simultaneously generates a corresponding natural language explanation, which is then sent to the large model via the Prompt. For example, the input Prompt template for the large model: User objective: Reduce power consumption to 30W.

[0026] Analysis result: {"target_power":30W, "strategy":"energy_saving"} Please generate a scheduling strategy based on the above objectives.

[0027] This allows the large model to utilize structured information to constrain its output. It's important to note that this module processes natural language related to management commands, which differs from conventional human-computer dialogue systems, emphasizing precise parsing within the specific domain. Therefore, a restricted-domain language understanding model can be trained specifically for the operating system scheduling domain, leveraging domain data to improve accuracy. For example, a large corpus of commands issued by operations and maintenance personnel can be collected to train an intent recognition model specifically for recognizing intents such as power consumption control, performance optimization, and task allocation.

[0028] Large Model Scheduling Inference Engine: This is the core decision-making unit of the system, internally carrying one or more large pre-trained models. It can be deployed after fine-tuning open-source large language models (such as GPT-NeoX, Bloom, etc.), or by calling commercial models (such as the OpenAI GPT series) via API. To ensure high-quality decision generation in scheduling scenarios, the model needs to be optimized specifically for the characteristics of this invention. Hint-based learning: Guide the model to output results in the required format by carefully designing prompt templates. This includes adding system role descriptions within the dialogue context, such as, "You are an operating system scheduling optimization assistant," and providing example output formats. Few-shot examples can be used to allow the model to learn to provide decisions and explanations for input requests. For instance, providing several example prompts and their corresponding policy explanations allows the model to generalize through analogy.

[0029] Domain knowledge embedding: Large models are trained on internet corpora and may not possess specific OS scheduling expertise (e.g., scheduling algorithms, kernel parameter names, etc.). Therefore, it's necessary to embed domain knowledge during prompts or fine-tuning. One approach is to summarize commonly used strategies and OS interfaces in a knowledge base and provide them to the model in document form (through knowledge in the prompts). Another approach is to perform secondary pre-training or supervised fine-tuning on the model using specially constructed Q&A or dialogue datasets. The questions are scheduling requirements, and the answers are reasonable strategy solutions and explanations. Based on this, the model learns scheduling decision-making capabilities.

[0030] Multimodal information processing: If the system status contains non-textual information (such as numerical values ​​or tables), the model needs to understand it. For example, real-time performance metrics can be converted into text descriptions such as "CPU average utilization 80%, temperature 75℃," embedded in the prompt; or structured data can be used to allow the model to obtain results through plugins or code execution. In this invention, the large model engine can also integrate tool usage capabilities. When more accurate decision evaluation is needed, the model can call a computational module (such as an energy consumption estimation function) to assist in decision-making. This is similar to giving the model some AutoML or agent characteristics to improve decision reliability.

[0031] Output Control: To ensure the output format meets the requirements of the execution module, post-processing or constraints are needed for large model outputs. Regular expression matching or a parser can be used to break down the model output. For example, if the model outputs a Markdown-formatted explanation and a code block containing instructions, the execution module can extract and parse the code block. For safety, function calling mode (such as OpenAI API's function calling) can be enabled, pre-defining executable functions (such as `set_cpu_freq(limit)`, `set_task_affinity(task, core)`, etc.) so the model directly returns the function and parameters. This structured output method reduces the difficulty of parsing free text.

[0032] The large model inference engine not only acts as a policy generator throughout the system, but also serves as a "translator" for communication with the user through its generated explanations. The explanations seen by the user are actually the model's description of the rationale behind its own decisions, which is equivalent to AI self-censoring and reporting to the user. This approach ensures that the user is always aware of what the system is doing and why it is doing it, thereby enhancing decision-making transparency.

[0033] Furthermore, a balance needs to be struck between the model's inference speed and resource consumption. Large models may have long inference times, which is not conducive to real-time scheduling. Possible optimizations include: distilling or quantizing the model, or using smaller dedicated models to handle urgent / simple requests, while using large models to handle complex strategies (i.e., a multi-layered model architecture, similar to a teacher-student model). In addition, depending on actual needs, the scheduling frequency usually does not need to be at the second level and can tolerate decision delays of several seconds to tens of seconds, which provides room for using large models.

[0034] Scheduling Strategy Execution and Feedback Module: This module connects the AI ​​world and the operating system reality, responsible for implementing the decisions of large models and supervising the results. It can be implemented as a module within the operating system kernel (such as an extended scheduling subsystem) or in user space via privileged interfaces. Its main functionalities include: Instruction parsing and mapping: After receiving the scheduling instruction set generated by the large model, the meaning of each instruction needs to be parsed and the corresponding system service needs to be invoked. For example, the large model might output: "limit_cpu_freq(1.0GHz, big_cores)". The execution module parses out the function limit_cpu_freq and its parameters, and then matches them to the underlying implementation—on Linux, this can be achieved through the interface writing / sys / devices / system / cpu / cpu* / cpufreq / scaling_max_freq, setting the maximum frequency of the big cores to 1GHz. If the instruction is in natural language, such as "reduce the frequency of the big cores to 1.0GHz", the execution module can use NLP techniques to simply parse the action = reduce frequency, the object = big cores, and the value = 1.0GHz, and then invoke the corresponding interface. This is similar to a reverse control instruction NLU process.

[0035] Permissions and Security Checks: The execution module has high privileges and directly accesses sensitive settings such as operating system scheduling and power supply, therefore security checks are essential. It must be ensured that the operations required by the model are permitted and reasonable in the current environment. For example, if the user has ordinary privileges but certain adjustments require administrator privileges, execution should either be denied or a privilege elevation prompt should be displayed. Furthermore, if model instructions might affect system stability (e.g., binding all tasks to the same core, causing overload), the execution module should detect and issue warnings or denials to prevent reckless execution from causing system failures. A built-in security policy whitelist / blacklist can be used to verify the model output.

[0036] Step-by-step execution and monitoring: When applying a series of scheduling adjustments, it should be done step by step to observe the effects. For example, first reduce the frequency, then measure the power consumption, and then decide whether to continue reducing it to avoid excessive adjustment all at once. The execution module can contain a simple strategy engine to implement closed-loop control (PID control concept) – gradually approaching the target. For example, if the user's target power consumption is 30W, first try reducing the frequency by 10%, and the measured power consumption is 40W. Then reduce it by another 10% to reach 30W, and then stop adjusting. This is more reliable than the model giving a drastic change all at once. The strategy given by the model can also be regarded as an initial plan. The execution module can fine-tune the parameters according to real-time feedback to form a hybrid execution of AI decision-making and program control.

[0037] Real-time monitoring: The execution module needs to obtain a large amount of status data from the operating system for feedback and possible emergency adjustments. Information is collected through statistical interfaces provided by the operating system (such as / proc / stat, / proc / loadavg, utilization metrics provided by the GPU driver, temperature sensor drivers, etc.). Some specific metrics, such as task migration rate, can be obtained by adding a hook to the kernel to calculate the number of core swaps during task scheduling; other metrics, such as memory bandwidth usage and I / O status, can also be obtained. All this data is compiled into a system status overview and periodically sent to the large model module (if continuous model evaluation is required) and provided to the user interface.

[0038] Feedback Report Generation: The module summarizes key metric changes into human-readable feedback. For example, "Power consumption has decreased to 30W, a reduction of 15W from before the adjustment; average CPU usage has decreased from 80% to 60%, with an expected performance decrease of approximately 10%." This content is partly derived from monitoring data and partly references previous model predictions, which are then updated by the execution module. Feedback reports can be directly displayed on the user interface or sent as part of a dialogue to the larger model for further refinement. In this invention, the model is typically responsible for generating the final explanation, but the execution module can provide a data summary text, which the model uses to refine its language.

[0039] Through the execution and feedback module, the system achieves a closed loop from decision-making to action to evaluation, enabling AI scheduling to adaptively adjust. Simultaneously, it serves as the entry point for human intervention—administrators can directly view the current strategy and status through this module's interface, and even manually take over control in emergencies. For example, if an inappropriate AI strategy leads to a severe performance degradation, the administrator can pause AI scheduling and restore the default strategy. Therefore, this module also provides a one-click rollback function: restoring the system scheduling configuration to its state before AI intervention to ensure safety.

[0040] Knowledge Base and Historical Context Cache Module: The knowledge base acts as the "experience brain" in this system, storing and managing knowledge and experience in the scheduling domain. Its components may include: Rule base: A collection and organization of existing scheduling optimization rules. Examples include rules of thumb such as "prioritize interactive response under heavy load and maximize energy efficiency under light load"; and general best practices for scheduling under various hardware architectures (how to reduce remote access in NUMA architecture, how to combine hyper-threading with scheduling, etc.). These rules can be derived from literature and expert knowledge, and are formalized and stored (e.g., IFTTT rules, logical expressions, case studies -> measures comparisons, etc.).

[0041] Case Library: Records actual scheduling cases that occur during system operation. Each case includes: user objective, initial system state, model decision, execution result, user feedback, etc. It can be indexed using unique IDs and continuously accumulated. For efficient retrieval, cases need to be tagged or indexed, for example, categorized and stored according to objective type (power consumption / performance / thermal management, etc.), effectiveness, hardware environment, etc.

[0042] Model interaction logs: These logs record all conversations with the large model. This is crucial for auditing and improving the model. If the model makes an inappropriate decision, the conversation logs can be traced to analyze the cause. Furthermore, this log data can be used to retrain the model, continuously improving its performance.

[0043] Context caching: In multi-turn dialogues, to prevent long dialogues from causing the model's context window to overflow or forgetting remote history, important context summaries can be stored in a knowledge base. When the dialogue reaches a certain length, the model or system summarizes the previous content and writes it into the knowledge base, retrieving it when needed next. This ensures that the model references long-range history while saving context length.

[0044] A knowledge base can be implemented as a database or a file system. The retrieval mechanism is crucial: when a new prompt arrives or the system state is updated, how can relevant knowledge be retrieved from the knowledge base and provided to the model? One approach is semantic search: embedding the prompt and performing approximate matching with the embeddings of knowledge entries in the knowledge base to find similar cases. For example, if a user requests reduced power consumption, all cases related to power consumption are retrieved, sorted by similarity, and provided to the model for reference. The model can then cite these cases in the prompt: "Historical cases show that the XXX strategy works well in similar situations." This method integrates implicit knowledge into the model's reasoning process, essentially adding retrieval memory capabilities to the model.

[0045] Furthermore, the knowledge base can be used for evaluation and continuous learning: after the system has been running for a period of time, it can evaluate which strategies are effective and which are ineffective, scoring them based on the presence or absence of positive user feedback. This data can then be used for offline training of the model (either reinforcement learning or supervised learning). For example, successful cases from the knowledge base can guide the model, making it more inclined to output similar strategies in similar scenarios, while avoiding strategies that were previously rejected. In this way, the system of this invention can continuously improve itself, and its performance will increase over time.

[0046] Therefore, users / administrators interact with the system through Prompt; the Prompt input parsing module interprets natural language intent; the large-scale model scheduling inference engine generates scheduling instructions and interpretations; the scheduling execution and feedback module applies strategies and collects system status feedback; and the knowledge base module provides historical context support. These modules collaborate to achieve conversational task scheduling management. By combining the powerful natural language understanding and decision-making reasoning capabilities of the large-scale model, a novel operating system scheduling interaction method is provided, enabling intelligent, personalized, and interpretable multi-core task scheduling management, significantly improving the efficiency of system resource management and user experience.

[0047] Furthermore, such as Figure 2 As shown, a multi-core task scheduling method includes the following steps: 1. User inputs scheduling target System administrators or users input scheduling requests in natural language through the front-end interface. For example: "Please keep the server running at low power for 4 hours," or "Prioritize image rendering tasks on the GPU." Input can be text or speech (transcribed into text by a speech recognition module). The user-inputted natural language scheduling request is denoted as: Pin = {Objective, Constraints, Task Type, Time Window, Resource Preference} For example: Pin={Target=Low power consumption, Time=4h} or Pin={Task Type=Rendering, Resource=GPU, Priority=High} 2. Prompt parsing The Prompt input parsing module receives natural language commands and performs language processing analysis. First, it performs word segmentation and lexical analysis to identify core keywords and parameters (such as "low power consumption," "4 hours," or "rendering task," "GPU," etc.). Then, it performs syntactic and semantic parsing to transform the user's intent into a structured scheduling requirement representation.

[0048] The parsed results can be used to form structured objects, such as: {"Target": "Low power consumption", "Duration": 4 hours} or {"Task Type": "Image Rendering", "Resource": "GPU", "Priority": true} For ambiguous or incomplete information, the system can use a rule base or pre-trained language model to complete and disambiguate it. Additionally, if historical context exists, the parsing module will semantically associate the information with the content of recent turns of the conversation. For example, in a multi-turn conversation, if the user first inquires about power consumption and then requests "keep low power," the parsing module will automatically associate the preceding semantics.

[0049] The Prompt parsing module ultimately maps the natural language input into a structured scheduling vector: Vp=fparse(Pin)=BERT(Pin)+Rcontext Here, Rcontext represents contextual memory from historical dialogues or knowledge cache. Based on the lexical analysis results, a set of keywords can be extracted: K={k1,k2,…,kn} For example: K = {Low power consumption, 4h} or K = {Rendering task, GPU, High priority} 3 major model reasoning and decision making The structured demand vector Vp output by the parsing module will be submitted to the large model scheduling inference engine. This engine can be implemented based on API calls to large language models (such as GPT-4) or by local model deployment. During inference, the model comprehensively considers user intent and real-time system state to generate targeted task scheduling strategies and execution instructions. The large model scheduling inference engine simultaneously receives the structured demand Vp and the system state St, with the input definitions as follows: St={UCPU,UGPU,Psys,Ttemp,Ltask} Where: UCPU and UGPU represent the utilization rates of the CPU and GPU, respectively; Psys represents the system power consumption; Ttemp represents the core temperature; and Ltask represents the task queue length or waiting time distribution. Combining the knowledge base information Kb, the model generates scheduling decisions based on a language-numerical joint reasoning mechanism. D=fLLM(Vp,St,Kb) Where D represents the decision outcome, which includes a strategy description and an executable instruction template. The reasoning process generally follows these steps: Goal understanding → Knowledge retrieval (including pre-trained knowledge and historical cases) → Strategy planning → Instruction and interpretation generation 4. Strategic Planning Phase During the strategy planning phase, the large model maps the user's high-level semantic goals into specific, executable scheduling schemes. For example, when a user requests "maintain low-power operation," the model can retrieve common energy-saving scheduling measures from the knowledge base, including: Reduce CPU clock speed and operating voltage; Reduce the number of active cores; In the big.LITTLE architecture, tasks are prioritized for scheduling to the more energy-efficient small cores; Merge low-priority tasks to reduce frequent migrations.

[0050] The model calculates the performance-power ratio using an energy consumption assessment model, with the goal of maximizing performance output per unit power. maxθΓ=Pref(θ)Power(θ) Or, equivalently, minimize the energy consumption per instruction: minθEinstr=Power(θ)IPS(θ) Where: Prefθ represents the system's average performance (instructions per second) under policy parameter θ; Power(θ) corresponds to power consumption; Γ represents the Energy Efficiency Ratio (EER). If the user's goal is "GPU-prioritized task execution," the model will further introduce a weighted resource allocation mechanism, defining the GPU task weighting coefficient: WGPU = TGPU + TCPU + TGPU When WGPU > δ (the threshold is typically set between 0.5 and 0.7), the model prioritizes assigning tasks to the GPU queue and appropriately reduces the scheduling weight of CPU-intensive tasks to achieve optimal resource allocation. Considering the trade-offs between different objectives (energy consumption, performance, latency, etc.), the large model internally establishes a multi-objective optimization function: minθJθ=α⋅Pavg+β⋅Dlatency−γ⋅Γ Where: Pavg represents average power consumption; Dlatency represents average task response latency; Γ represents energy efficiency ratio; α, β, γ represent weighting coefficients used to achieve a dynamic balance between power consumption, latency, and energy efficiency. During the optimization process, the model can adaptively adjust the weights based on empirical data in the knowledge base, ensuring that the generated scheduling strategy meets user objectives while also considering system stability and long-term energy efficiency.

[0051] 5. Instruction Set Generation and Interpretation Output After completing policy planning, the large-scale model scheduling inference engine enters the instruction generation phase. Based on the decision result (DDD), the model automatically generates a set of machine-executable scheduling instructions to implement the policy. Depending on different user objectives, the large-scale model can output corresponding pseudocode, configuration sets, or structured instructions. For example, when the objective is a low-power mode, the model might generate the following instruction sequence: Set CPU scheduling mode to powersave; Set the maximum frequency of the big core to 1.0 GHz; Set the maximum frequency of the little core to 0.8GHz; Enable the Dynamic Voltage Frequency Regulation (DVFS) energy-saving option; Reduce the scheduling priority of non-critical tasks; If the target is a GPU-first strategy, the model output instructions might be: For task type = rendering, set sched_priority = HIGH; Bind the rendering task thread to the NUMA node where the GPU resides; Adjust the GPU driver mode to maximum performance; Pause low-priority background CPU tasks; The above instructions can be output by the large model in natural language form and then parsed into system operation commands by the scheduling and execution module; alternatively, they can be directly generated in structured form (such as JSON, YAML, or API call parameters) for automatic parsing and invocation by the execution module. The complete set of configuration instructions generated by the large model can be formally defined as: C = {c1, c2, ..., cm} For example: c1: Set CPU scheduling mode = powersave c2: Set the maximum frequency of the big core to 1.0 GHz. c3: Set the upper limit of little core frequency to 0.8 GHz c4: Enable power saving option c5: Adjust GPU scheduling priority = HIGH The instruction generation process can be formally represented by the decoding function of the large model as follows: C = fgen(D) = DecoderLLM(D) Ultimately, the instruction set can be further mapped to a set of operating system calls: {syscall1,syscall2,…,syscalln} This enables seamless integration with the system kernel or scheduling interface. To enhance interpretability and user trust, the large model generates policy explanation reports in natural language along with the instruction set. For example, when a user requests "maintain low-power operation," the model might automatically generate the following explanation: "Since you requested low-power operation, I have reduced the CPU clock speed and the number of active cores, which will reduce system power consumption by about 30%, but processing speed may decrease by about 15%. At the same time, I have adjusted process priorities to ensure that critical tasks can still be completed in a timely manner." This explanatory text not only explains the rationale behind the strategy but also includes quantitative predictions of performance and power consumption changes, making it easier for users to understand the decision-making logic. The functional form of the model-generated explanation can be expressed as: Eexp=fexplain(D) = Template(D, Γ, Δ Perf, Δ Power) Where Γ represents the energy efficiency ratio; ΔPerf represents the performance change; and ΔPower represents the power consumption change. For example, the output natural language interpretation result could be: "Currently, power consumption has decreased by about 30%, and performance has decreased by about 15%. The system has entered a low-power operation mode." The introduction of this module enables the large model scheduling system to have good explainability and human-in-the-loop coordination, significantly improving users' understanding and trust in automated scheduling decisions.

[0052] 6. Strategy Execution After receiving the instruction set generated by the large model, the scheduling strategy execution and feedback module first translates the natural language scheduling instructions into system-executable calls or configuration commands. If the large model output is already in a structured format (such as JSON, YAML, or script), it can be directly parsed and executed. The execution module implements specific scheduling operations through operating system interfaces or system calls. The execution process can be formalized as follows: Exec(C) = i = 1 mApply(ci) Where Apply(ci) represents the actual execution of the i-th instruction. If an instruction fails to execute (e.g., insufficient permissions, device incompatibility, or abnormal parameters), the system generates an error feedback set: Ferr = {i | Apply(ci) = 0} The results are then fed back to the larger model and the user interface. Typical execution examples include: Use the Linux cpupower or / sys / devices / system / cpu interface to set the CPU frequency limit; The sched_setaffinity() system call is used to set CPU affinity for a specific process, thus achieving task binding. High-priority tasks can be assigned to GPUs via GPU scheduling APIs such as CUDA Stream or OpenCL Queue. Modify the task cgroup or scheduling policy (such as placing background processes into a low-priority queue).

[0053] During execution, the module verifies the result of each instruction to ensure that the operation is legal, safe, and complies with system constraints. If an anomaly is detected, a log entry is automatically generated and fed back to the model and user for subsequent adaptive optimization. This stage achieves a precise mapping from high-level policies to low-level operating system configurations.

[0054] 7. System Monitoring and Feedback After the new scheduling strategy is applied, the execution module enters the monitoring phase to continuously evaluate the system's operational status. Monitoring content includes, but is not limited to: Total power consumption (obtained by a power sensor or energy consumption estimation module); CPU core utilization and temperature distribution; Average load, task queue length, and response latency; GPU utilization and task completion rate; Abnormal conditions (such as overheating, sudden performance degradation, task starvation, etc.).

[0055] System periodic data acquisition performance metrics: Mt ={ Pt, Tt, Ut, Lt, Ft} Where: Pt is power consumption (W), Tt is temperature (°C), Ut is CPU / GPU utilization, Lt is average task latency, and Ft is task failure rate. The strategy benefit is calculated based on time series differencing. Γt =Γtnew −Γtold If ΔΓt > 0, it indicates that the new strategy is effective, and its data will be written to the knowledge base for future reference. The monitoring results from the execution module are fed back to two locations: 1. User interface – Display system status in natural language or graphical form, such as: “Current CPU power consumption has decreased to 45W, average response time has increased by about 5ms, and the system is in low power mode.” 2. Large Model Inference End – The monitoring results are fed into the model as new input feedback (Prompt) for the next round of decision-making.

[0056] For example, the model might automatically generate internal hints: "The previous strategy has been applied, resulting in a 25% reduction in actual power consumption and a 10% performance decrease. Is further optimization needed?" This triggers the model to enter the next round of multimodal inference adjustment, achieving continuous adaptive optimization.

[0057] 8. Multi-round interaction optimization Users can choose whether to continue adjusting the scheduling strategy based on the feedback. If the user is satisfied, the system can continue running under the current configuration until the target time window (e.g., 4 hours) ends; if the user is not satisfied, they can directly modify their requirements via natural language. For example: User feedback: "The power consumption reduction is good, but the performance drop is significant. Can you slightly improve the performance?" The system parses this new prompt and recalculates the input: Pink+1=guser(Ft, Γt) And then call the model to perform the next round of inference: Dk+1 = fLLM(Pink+1, Stk+1, Kb) This forms a dynamic, closed-loop human-machine collaborative optimization process. When necessary, the model can also proactively ask the user questions, such as, "Is it permissible to raise the temperature to 80°C to improve performance?" to further obtain decision constraints and improve the matching degree.

[0058] 9. Knowledge Base Updates and Self-Learning For each complete "Prompt → Strategy → Execution → Feedback → Adjustment" process, the system records relevant data, forming structured knowledge samples: Xi=(Pin,Vp,D,C,Mt,Eexp) The knowledge base update rules are as follows: Kbnew=Kbold∪{Xi} After long-term operation, the system's knowledge base will accumulate a large number of typical scheduling scenarios and optimal strategy combinations. For example: "Server A adopted a frequency reduction + core binding scheme under low-power requests, resulting in a 28% reduction in power consumption and a 12% performance loss, which was well received by users." When a similar new request occurs, the large model can retrieve similar cases from the knowledge base, quickly generate high-quality decisions, significantly reduce exploration and reasoning costs, and enable the system to have continuous learning and self-optimization capabilities.

[0059] 10. Closed-loop control characteristics This invention establishes a complete adaptive closed-loop scheduling system: Natural language input → AI decision-making → Execution feedback → AI / user adjustment → Knowledge accumulation In this process, the large model acts as an "intelligent hub," translating high-level intentions into low-level execution logic; users, as collaborating decision-makers, provide preferences and experiences, enabling the system to continuously optimize through multiple iterations. The overall process can be abstractly represented as: Vp=fparsePinD=fLLMVp,St,KbC=fgenDExecC=System Configuration Execution Ft=ffeedbackMtKbt+1=Kbt∪{Xi} This system is essentially a multi-round reinforcement-based human-machine collaborative optimization mechanism. Its operating logic can be summarized as: Prompt → Structure → Reason → Execute → Feedback → Learn, which mathematically constitutes a self-learning closed-loop control system.

[0060] Furthermore, the application scenarios and examples are as follows: The prompt-driven scheduling system of this invention has a wide range of applications. Several typical fields are listed below, along with application examples of this system in those fields: Interactive Scheduling in Cloud-Native Environments: In large cloud data centers, tens of thousands of different types of tasks typically run, with load conditions changing rapidly. Traditional static scheduling struggles to meet constantly evolving SLA requirements. With this system, operations personnel can adjust cloud resource scheduling in real-time through dialogue. For example, if a service's response slows down, an administrator can ask the system, "Why is the latency of service X increasing? Can we allocate more CPU to it?" The system uses LLM analysis to identify possible causes (high load, CPU contention) and proposes solutions such as increasing container CPU share or migrating to idle nodes, explaining the reasons before implementation. Operations personnel can also set high-level policies: "Prioritize service performance during peak days and prioritize batch processing at night," and the system will automatically switch scheduling policies according to time periods. Compared to traditional scripts, this system provides flexible and natural resource orchestration capabilities, improving resource utilization and service quality in the cloud environment.

[0061] Intelligent Operations and Maintenance Platform (AIOps): Many enterprise IT operations and maintenance systems have adopted AIOps platforms that combine monitoring and AI analytics. This system can serve as a decision-making and execution component within AIOps. For example, if the monitoring system detects excessively high server temperatures, its knowledge base reveals that similar situations in the past have been effectively addressed with measures such as reducing frequency and load balancing. Therefore, it automatically generates a scheduling adjustment plan and notifies the administrator: "Due to a detected temperature of 90°C, I have transferred some computing tasks to lower the temperature." Administrators can modify the policy through dialogue if they have different preferences. This achieves a dual-mode system: AI automatically optimizes during normal operations, while manual intervention is required at critical points to ensure stable business operations.

[0062] Advanced System Management Visualization Tool: In scenarios requiring fine-grained resource control, such as large-scale scientific research computing, factory automation control, and 5G network slicing resource scheduling, this system can be integrated into a visual management interface. Managers can view current resource metrics through dashboards and issue optimization commands directly in natural language. For example, in manufacturing scheduling, if a manager sees a backlog of tasks on a production line, they can tell the system, "Increase the scheduling priority of production line A to complete orders 12345 as soon as possible." The system will identify the tasks related to the orders, give them higher priority, adjust the production sequence, and explain, "The priority of production line A has been increased to expedite the completion of orders 12345 due to their tight delivery deadline." This allows managers to intuitively control complex scheduling plans without delving into technical details, greatly improving decision-making efficiency.

[0063] Edge Computing and IoT: Deploying this system on edge nodes or IoT gateways allows for the configuration of device operating modes through dialogue. For example, an IoT controller in a factory workshop can accept voice commands such as, "If the temperature exceeds the threshold, reduce the sensor's sampling frequency to save power." The system will then parse this and add conditional rules to the scheduling. This user-friendly configuration method is suitable for on-site engineers who may not be familiar with programming but can directly state their needs, which the system will translate into executable strategies.

[0064] As can be seen from the above examples, the system of this invention is applicable to various multi-processing scenarios, from large data centers to small embedded devices. It transforms complex resource scheduling problems into simple human-computer dialogue problems, significantly lowering the barrier to entry. Especially in fields requiring frequent strategy adjustments and high dynamism, the advantages of this system are even more pronounced, and it is expected to become part of the next generation of intelligent infrastructure.

[0065] In summary, the prompting-learning-driven multi-core scheduling scheme proposed in this invention is the first of its kind in the prior art. It introduces a large language model into operating system resource management, providing unprecedented conversational interaction and interpretive decision-making capabilities. While related research and patents may share similar ideas in certain areas (such as natural language commands and AI scheduling), they differ from this invention in overall system architecture, application layers, and functional focus. This invention realizes a complete closed-loop system from user intent acquisition, AI inference and decision-making, execution feedback to continuous learning, possessing significant innovation and practical value. It can effectively compensate for the shortcomings of existing technologies and is expected to lead a new development direction in the field of intelligent operating systems.

[0066] The number of devices and processing scale described herein are for simplification of the invention. Applications, modifications, and variations of this invention will be readily apparent to those skilled in the art. Although embodiments of the invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. It can be applied to various fields suitable for this invention, and further modifications can be readily implemented by those skilled in the art. Therefore, without departing from the general concept defined by the claims and their equivalents, this invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A custom scheduling system for large-scale multi-core tasks based on cue-based learning, characterized in that, include: The input parsing module is used to receive natural language scheduling target instructions input by the user, perform language parsing and intent extraction on the instructions, and generate structured scheduling requirement information. The large model scheduling thrust engine, which is connected to the prompt input parsing module, is used to generate a corresponding task scheduling strategy instruction set and an explanation of the strategy based on scheduling requirement information and optional current system state and historical context using a pre-trained large language model. The scheduling strategy execution and feedback module and the knowledge base and historical context cache module are connected to the large model scheduling thrust engine. The scheduling strategy execution and feedback module is used to receive the task scheduling strategy instruction set, map the instructions to specific operating system scheduling configurations and execute them, monitor the system status after execution, and send feedback information to the large model scheduling inference engine and provide it to the user. The knowledge base and historical context cache module are used to store historical scheduling instructions, system status and effect data, provide them to the large model scheduling inference engine for decision reference, and support the caching and retrieval of context information during multi-turn dialogues.

2. The custom scheduling system for large-scale multi-core tasks based on cue learning as described in claim 1, characterized in that, The prompt input parsing module includes a keyword extraction unit, a template matching unit, a deep parsing unit, and a context connection unit. The deep parsing unit can call a pre-trained language model or semantic parsing model for complex or long prompts. The output of the deep parsing unit includes an intermediate semantic representation for further processing by a large model, and a prompt that is directly generated for the large model.

3. The custom scheduling system for large-scale multi-core tasks based on cue learning as described in claim 1, characterized in that, The large model scheduling thrust engine includes a prompting learning unit, a domain knowledge embedding unit, a multimodal information processing unit, and an output control unit. The output control unit ensures that the output format meets the requirements of the execution module and performs post-processing or constraints on the large model output. Thus, the large model scheduling thrust engine pre-sets the output template through the prompting learning unit, enabling it to produce a result containing two parts: a structured set of scheduling strategy instructions and a corresponding human-readable explanation, which uses natural language to explain the reasons and expected impact of each scheduling decision.

4. The custom scheduling system for large-scale multi-core tasks based on cue learning as described in claim 1, characterized in that, The scheduling strategy execution and feedback module includes: An instruction parsing submodule used to translate instructions output by large models into functions or commands that can be called by the operating system; The execution submodule is used to call kernel interfaces or system APIs to apply scheduling policies; A monitoring submodule for acquiring system operation metrics such as CPU utilization, power consumption, and task latency; A feedback generation submodule is used to generate feedback reports based on monitoring data and send the feedback reports to the large model scheduling inference engine and the user interface.

5. A custom scheduling system for large-scale multi-core tasks based on cue learning as described in claim 1, characterized in that, The knowledge base and historical context cache module includes a rule base, a case base, a model interaction log, and a context cache. The rule base is used to collect and organize existing scheduling optimization rules; the case base is used to record actual scheduling cases that occur during system operation. Thus, when the large model scheduling inference engine generates scheduling policy instructions, it searches the rule base and the case base, incorporates experiential knowledge that conforms to the current situation into the decision reference, and realizes adaptive optimization of the scheduling policy.

6. A method for multi-core task scheduling applied to a large-model multi-core task custom scheduling system based on cue learning as described in any one of claims 1-5, characterized in that, Includes the following steps: S1. Receive the natural language scheduling target input by the user, and obtain the structured scheduling requirements through the prompt input parsing module; S2. Provide the scheduling requirements to the large model scheduling thrust engine to generate corresponding scheduling strategy instructions and explanations of the strategy; S3. The scheduling strategy instructions are executed through the scheduling strategy execution and feedback module to adjust the scheduling parameters of the computing system; S4. Monitor the execution results, obtain the changes in the system's performance and power consumption indicators under the scheduling strategy, and feed back the changes to the user and provide them to the large language model; S5. When the user has new tuning instructions or the large language model needs to adjust the strategy based on feedback, repeat steps S1-S4 to form an iterative optimization dialogue scheduling process until the predetermined goal is achieved or the dialogue ends.

7. The multi-core task scheduling method as described in claim 6, characterized in that, In step S2, when the large language model of the large model scheduling thrust engine generates a scheduling strategy, it calls the pre-stored scheduling knowledge base to retrieve optimization schemes for similar scenarios and integrates them into the new scheduling strategy decision to improve the effectiveness and convergence speed of the strategy.

8. The multi-core task scheduling method as described in claim 7, characterized in that, In step S3, the instructions output by the large language model are subjected to security verification and order optimization to avoid potential conflicts or system instability. The adjustment of the scheduling parameters involves at least one of the following: CPU frequency limit, task priority modification, task CPU affinity setting, thread binding, power mode switching, and task migration strategy.

9. A multi-core task scheduling method as described in claim 8, characterized in that, The feedback in step S4 includes a comparison of key performance indicators before and after the scheduling adjustment, as well as an evaluation of the scheduling effect by a large language model. The feedback is given to the user in the form of a natural language report, so that the user can understand the impact of the scheduling decision and decide on the next steps.

10. An electronic device, characterized in that, The electronic device includes: at least one multi-core processor; and a memory communicatively connected to the at least one multi-core processor; wherein the memory stores a computer program executable by the at least one multi-core processor, the computer program being executed by the at least one multi-core processor to enable the at least one multi-core processor to execute the large model multi-core task custom scheduling system based on cueing learning as described in any one of claims 1-5.

Images