Sandbox scheduling method based on code generation large model and related device

Abstract

The invention provides a sandbox scheduling method based on a code generation large model and a related device, and relates to the technical field of computers, in particular to the technical field of artificial intelligence such as large language models, sandboxes, human-computer interaction and low codes. The method comprises the following steps: determining personalized demand information according to a code development request initiated by a target user; in response to the existence of the reusable sandbox matched with the personalized demand information, the reusable sandbox matched with the personalized demand information is allocated to the target user, and the reusable sandbox is a sandbox in which data associated with the target user is retained; in response to the fact that the reusable sandbox matched with the personalized demand information does not exist, a to-be-activated sandbox corresponding to the personalized demand information is determined from a pre-constructed sandbox hot pool, the to-be-activated sandbox is distributed to the target user, and different sandboxes respectively provide the same code in different operation environments to generate a large model. According to the method, the resource utilization efficiency of sandbox scheduling is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of artificial intelligence technologies such as large language models, sandboxes, human-computer interaction, and low-code, and particularly to a sandbox scheduling method, apparatus, electronic device, computer-readable storage medium, and computer program product based on a large code generation model. Background Technology

[0002] In large-scale application models, especially in code generation agent scenarios, code execution relies on the isolation and security of sandbox environments. Frequent code execution and testing necessitate the use of multiple independent sandbox environments. The traditional approach to sandbox creation involves creating a new sandbox environment each time code is requested to be executed, thus ensuring system isolation and security. Optimizing the management and execution of sandbox environments and improving resource utilization efficiency has become a significant challenge for current code generation agent systems. Summary of the Invention

[0003] This disclosure presents a sandbox scheduling method, apparatus, electronic device, computer-readable storage medium, and computer program product based on a large code generation model, which improves the resource utilization efficiency of sandbox scheduling.

[0004] In a first aspect, embodiments of this disclosure propose a sandbox scheduling method based on a large code generation model, comprising: determining personalized requirement information based on a code development request initiated by a target user; in response to the existence of a reusable sandbox matching the personalized requirement information, allocating the reusable sandbox matching the personalized requirement information to the target user; wherein the reusable sandbox is a sandbox that retains data associated with the target user; in response to the absence of a reusable sandbox matching the personalized requirement information, determining a sandbox to be activated corresponding to the personalized requirement information from a pre-built sandbox hot pool, and allocating the sandbox to be activated to the target user; wherein different sandboxes provide the same large code generation model in different operating environments.

[0005] Secondly, embodiments of this disclosure propose a sandbox scheduling device based on a large code generation model, comprising: a personalized requirement information determination unit configured to determine personalized requirement information based on a code development request initiated by a target user; a sandbox reuse unit configured to, in response to the existence of a reusable sandbox matching the personalized requirement information, allocate the reusable sandbox matching the personalized requirement information to the target user; wherein the reusable sandbox is a sandbox that retains data associated with the target user; and a pre-built sandbox allocation unit configured to, in response to the absence of a reusable sandbox matching the personalized requirement information, determine a sandbox to be activated corresponding to the personalized requirement information from a pre-built sandbox pool, and allocate the sandbox to be activated to the target user; wherein different sandboxes provide the same large code generation model in different operating environments.

[0006] Thirdly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the sandbox scheduling method based on a large code generation model as described in the first aspect.

[0007] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the sandbox scheduling method based on a large code generation model as described in the first aspect.

[0008] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the steps of the sandbox scheduling method based on a large code generation model as described in the first aspect.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture to which this disclosure can be applied; Figure 2 A flowchart illustrating a sandbox scheduling method based on a large code generation model, provided in this embodiment of the disclosure; Figure 3A flowchart of another sandbox scheduling method based on a large code generation model provided in this disclosure embodiment; Figure 4 A flowchart illustrating yet another sandbox scheduling method based on a large code generation model provided in this disclosure; Figure 5 A structural block diagram of a sandbox scheduling device based on a large code generation model provided in this disclosure embodiment; Figure 6 This is a schematic diagram of the structure of an electronic device suitable for executing a sandbox scheduling method based on a large code generation model, as provided in an embodiment of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0012] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0013] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the code generation-based large model sandbox scheduling method, apparatus, electronic device, and computer-readable storage medium of this disclosure can be applied.

[0014] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0015] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various applications for enabling information communication between the terminal devices 101, 102, and 103 and server 105 can be installed. These applications include web browsers, search engines, and instant messaging applications.

[0016] Terminal devices 101, 102, and 103 and server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0017] Server 105 can provide various services through its built-in applications. Taking a web browser-like application that can provide a sandbox scheduling method based on a large code generation model as an example, when running this web browser-like application, server 105 can achieve the following effects: Based on the code development request initiated by the target user, it determines personalized requirement information. When a reusable sandbox matching the personalized requirement information exists, it assigns the reusable sandbox matching the personalized requirement information to the target user. Here, the reusable sandbox is the sandbox that retains data associated with the target user. When no reusable sandbox matching the personalized requirement information exists, it determines the sandbox to be activated corresponding to the personalized requirement information from the pre-built sandbox hot pool and assigns the activated sandbox to the target user. Here, different sandboxes provide the same large code generation model in different operating environments.

[0018] It should be noted that, in addition to being obtained from terminal devices 101, 102, and 103 via network 104, code development requests can also be pre-stored locally on server 105 through various means. Therefore, when server 105 detects that this data is already stored locally (e.g., when starting to process previously stored code development requests), it can choose to retrieve this data directly from the local storage. In this case, the exemplary system architecture 100 may also exclude terminal devices 101, 102, and 103 and network 104.

[0019] Since the code-based development request scheduling sandbox requires significant computing resources and power, the code-generation-based large-scale model sandbox scheduling method provided in the subsequent embodiments of this disclosure is generally executed by a server 105 with strong computing power and abundant computing resources. Correspondingly, the code-generation-based large-scale model sandbox scheduling device is also generally located in the server 105. However, it should also be noted that when terminal devices 101, 102, and 103 also possess sufficient computing power and resources, they can also perform the aforementioned calculations performed by the server 105 through web browser applications installed on them, thereby outputting the same results as the server 105. Especially when multiple terminal devices with different computing capabilities exist simultaneously, but a web browser application determines that its terminal device has strong computing power and abundant remaining computing resources, it can allow the terminal device to perform the aforementioned calculations, thereby appropriately reducing the computing pressure on the server 105. Accordingly, the code-generation-based large-scale model sandbox scheduling device can also be located in terminal devices 101, 102, and 103. In this case, the exemplary system architecture 100 may also exclude the server 105 and the network 104.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Please refer to Figure 2 , Figure 2 A flowchart of a sandbox scheduling method based on a large code generation model provided in this disclosure is included, wherein process 200 includes the following steps: Step 201: Determine personalized requirements based on the code development request initiated by the target user.

[0022] In this embodiment, the execution entity (e.g. Figure 1The server 105 shown can receive code development requests initiated by target users through an interactive portal or interface. The target user can refer to a user of the system, such as a developer or tester. The code development request indicates the development environment required by the target user, typically including a natural language description, project identifier, technology stack specification, and resource requirements. For example, the natural language description could be text directly entered by the target user, such as "Is the environment for my order processing microservice project from yesterday still available? I want to continue debugging." The project identifier could be a project ID, project name, or code repository link directly specified by the target user, indicating that the target user currently needs the development environment corresponding to this project. The technology stack specification could be an explicit requirement from the target user, such as "I need a Node.js v18 + React v18 + PostgreSQL development environment." Resource requirements can refer to explicit resource requirements directly stated by the target user, such as "This model training requires a GPU," or implicit resource requirements inferred from the target user's request to "start a large-scale data processing task," suggesting the need for more CPU / memory.

[0023] In this embodiment, the executing entity can parse the code development request using natural language understanding and structured parameter parsing to determine the target user's personalized requirements. These personalized requirements help the system customize the development environment for the target user and typically include user information, technology stack information, task type information, and resource requirements. For example, when the executing entity receives a code development request from the target user, such as "Is the environment for my order processing microservice project from yesterday still available? I want to continue debugging," it can use a large language model to extract keywords like "yesterday," "order processing microservice project," and "debug" from the request to determine the personalized requirements. When the executing entity directly specifies the technology stack, project ID, etc., through options or command parameters, the system directly extracts this explicit information as personalized requirements through structured parameter parsing.

[0024] Step 202: In response to the existence of a reusable sandbox that matches the personalized needs information, assign the reusable sandbox that matches the personalized needs information to the target user.

[0025] In this embodiment, when the executing entity determines that a reusable sandbox matching the personalized requirements exists, it directly assigns the reusable sandbox matching the personalized requirements to the target user. Here, a sandbox refers to an isolated virtual execution environment used to securely run code and avoid impacting the host system. A reusable sandbox is a sandbox created or used at a specific historical point in time that retains data associated with the target user. Besides maintaining the development environment at that time, a reusable sandbox also includes the code, dependencies, running programs, debugging status, and even unsaved files from that sandbox at that time.

[0026] In this embodiment, the executing entity can sequentially compare each piece of information contained in the personalized requirement information with the reusable sandbox to determine whether a reusable sandbox matching the personalized requirement information exists. Specifically, when the executing entity determines that the user information, technology stack information, and task type information in the personalized requirement information are consistent with the user ID, technology stack, and project ID corresponding to the reusable sandbox, respectively, and that the usable resources of the reusable sandbox meet the resource requirements information in the personalized requirement information, then it is determined that a reusable sandbox matching the personalized requirement information exists, and the reusable sandbox is directly assigned to the target user.

[0027] Step 203: In response to the absence of a reusable sandbox that matches the personalized needs information, determine the sandbox to be activated corresponding to the personalized needs information from the pre-built sandbox hot pool, and assign the sandbox to be activated to the target user.

[0028] In this embodiment, when the executing entity determines that there is no reusable sandbox matching the personalized requirements, it identifies a sandbox corresponding to the personalized requirements from a pre-built sandbox hot pool and assigns it to the target user. The sandbox hot pool refers to a pre-created, pre-warmed set of sandboxes awaiting activation. These sandboxes have already installed the basic operating system and core code runtime environment and are in a state of waiting to be activated. Different sandboxes provide the same large code generation model in different runtime environments.

[0029] In this embodiment, when the executing entity determines the sandbox to be activated corresponding to the personalized requirements from the pre-built sandbox pool, it must first ensure that the basic operating system and core code runtime environment of the sandbox to be activated strictly match the personalized requirements. Secondly, the usable resources of the sandbox to be activated (e.g., number of CPU cores, memory size, presence or absence of a GPU) must meet or exceed the resource requirements of the personalized requirements. Furthermore, since sandboxes on nodes with low resource loads have high efficiency and low latency, the executing entity can also select the optimal sandbox to be activated based on the resource load of different nodes, provided the above conditions are met.

[0030] In this embodiment, after determining the sandbox to be activated corresponding to the personalized needs information, the executing entity first wakes up the sandbox to be activated, then configures the woken sandbox according to the personalized needs information, and assigns the configured sandbox to the target user.

[0031] The sandbox scheduling method based on a large code generation model provided in this embodiment first determines personalized requirement information based on the code development request initiated by the target user. When a reusable sandbox matching the personalized requirement information exists, it is preferentially assigned to the target user. When no reusable sandbox matching the personalized requirement information exists, a sandbox to be activated corresponding to the personalized requirement information is determined from a pre-built sandbox hot pool and assigned to the target user. Since the reusable sandbox completely retains the user's previous development state, this embodiment achieves rapid recovery of the development environment through the priority matching of reusable sandboxes, ensuring a continuous experience during development. In addition, this embodiment also discloses a sandbox hot pool scheduling strategy that is activated when no reusable sandbox matching the personalized requirement information exists. By filtering out sandboxes to be activated that match the personalized requirement information from the sandbox hot pool and configuring them personalized according to the personalized requirement information, the delay in development environment configuration is reduced and resource utilization efficiency is improved.

[0032] To deepen your understanding of how to determine personalized requirements based on code development requests, please refer to [link / reference]. Figure 3 , Figure 3 A flowchart of another sandbox scheduling method based on a large code generation model provided in this disclosure embodiment is given, specifically for the case of determining personalized requirement information based on code development requests, and a specific implementation method is provided, wherein process 300 includes the following steps: Step 301: Extract user information, session information, and task requirement information from the code development request.

[0033] In this embodiment, the executing entity extracts user information, session information, and task requirement information from the code development request initiated by the target user. The user information includes the target user's user ID and historical preferences, which refer to the target user's commonly used technology stack and development environment habits. Session information refers to the target user's historical development records, which can be directly extracted from the code development request; for example, the target user may explicitly indicate in the code development request that they wish to continue the previous session, or the information can be retrieved from the database by associating with the user ID. The task requirement information is the executable environment configuration information parsed from the code development request, including the technology stack and task type.

[0034] Step 302: Determine the technology stack information and task type information based on the task requirements information.

[0035] In this application, the executing entity determines the technology stack information and task type information based on the task requirements information. The technology stack information includes at least one of the following: programming language, front-end / back-end, and design architecture. Specifically, the programming language refers to the specific programming language used to write the target code, such as Python, Java, C++, etc., and can be further subdivided into different versions, such as C++ version 2.0 and 2.5, etc.; the front-end / back-end can be divided into front-end-oriented and back-end-oriented; the design architecture can be a microservice architecture, client-server architecture, event-driven architecture, etc.; the task type information can include at least one of the following: code writing, code compilation, and test execution.

[0036] Step 303: In response to the existence of a reusable sandbox that matches the personalized needs information, assign the reusable sandbox that matches the personalized needs information to the target user.

[0037] In this embodiment, a reusable sandbox matching personalized needs information refers to a sandbox that matches at least one of the following: user information, session information, technology stack information, and task type information. The more matching items, the higher the degree of matching; the independent contribution of session information, user information, technology stack information, and task type information to the degree of matching decreases in that order. Furthermore, a reusable sandbox includes at least one of the following: a sandbox with identical user information, a sandbox with associated user information related to the user information, a sandbox with identical session information, and a sandbox with historical session information belonging to the session information.

[0038] The following concrete example helps to understand this embodiment. The personalized requirement of the target user, Xiao Wang, is to create a new payment interface API (task type information). The technology stack specifies Python 3.11 and Flask framework version 2.2. There are three reusable sandboxes in the current repository: Sandbox X, Sandbox Y, and Sandbox Z. Sandbox X was previously used by Xiao Wang (user information matching) in the same project session (session information matching), but the technology stack is Python 3.10 and Flask 2.0 (slightly older versions, partial match), and the task type is user management API (similar but not completely identical). Sandbox Y's technology stack perfectly matches Python 3.11 and Flask 2.2 (technology stack information complete match), and the task type is also API development (task type information matching), but the user is another user, Xiao Li (user information mismatch), and the session is a separate project debugging session (session information mismatch). Sandbox Z's task type perfectly matches payment interface development (task type information matching), and the user is Xiao Wang (user information matching), but the technology stack is Python 3.9 and Flask. Version 1.0 (too low, almost no match), the session is a historical session from another project a month ago (session information mismatch). It can be seen that Sandbox X matched user information and session information, Sandbox Y matched technology stack and task type, and Sandbox Z matched user and task type. The system selects reusable sandboxes based on the following methods: 1. The more matching items, the better. Sandbox X has two matches (user and session), Sandbox Y has two (technology stack and task type), and Sandbox Z also has two (user and task type); 2. Next, the degree of matching is considered: for example, Sandbox Y has a completely identical technology stack, Sandbox X has a different technology stack version, and Sandbox Z has a completely incompatible technology stack; 3. Finally, and most importantly, the weighting rule: session information has the highest independent contribution, followed by user information, then technology stack information, and task type information contributes the least. Sandbox X's advantage lies in session information matching, which has the highest weight, allowing for seamless development environment integration and saving initialization time. User information matching has the second highest weight, reflecting personal preferences. Although the technology stack only partially matches, its contribution weight is low, allowing the system to fine-tune and update the version. Sandbox Y has a perfect technology stack match, but its contribution weight is low. Furthermore, the session and user match are incompatible, potentially requiring additional context configuration after reuse. Sandbox Z has the smallest contribution to task type matching and a medium weight to user matching, but its technology stack is too old, resulting in high reuse costs. Therefore, ultimately, because the high-weighted matching items for sessions and users dominate, the overall matching score is the highest. The system selects sandbox X as the reusable matching sandbox. The system only needs to upgrade the Flask framework (technology stack) to quickly start generating code for large models in a secure and isolated environment.

[0039] Step 304: In response to the absence of a reusable sandbox that matches the personalized needs information, determine the sandbox to be activated corresponding to the personalized needs information from the pre-built sandbox hot pool, and assign the sandbox to be activated to the target user.

[0040] Steps 303-304 and as follows Figure 2 Steps 202-203 shown are the same. For the same parts, please refer to the corresponding parts of the previous embodiment. They will not be repeated here.

[0041] In this embodiment, the difference is... Figure 2 The illustrated embodiment provides a method for determining personalized requirement information in steps 301-302, and a method for scheduling the sandbox in steps 303-304, corresponding to steps 202-203. There is no causal or dependency relationship between the two methods, and they do not necessarily need to be applied simultaneously in one embodiment. They can be applied to different embodiments as needed to determine personalized requirement information, or used to determine personalized requirement information. This embodiment is merely a preferred embodiment that simultaneously includes two specific implementation methods.

[0042] The sandbox scheduling method based on a large code generation model provided in this disclosure first extracts user information, session information, and task requirement information from code development requests. Then, it determines technology stack information and task type information based on the task requirement information. When a reusable sandbox matching the personalized requirement information exists, it prioritizes allocating the reusable sandbox matching the personalized requirement information to the target user. When no reusable sandbox matching the personalized requirement information exists, it determines the sandbox to be activated corresponding to the personalized requirement information from a pre-built sandbox hot pool and allocates the sandbox to be activated to the target user. This embodiment extracts user information, session information, and task requirement information to determine technology stack information and task type information, generating executable environment configuration information. This avoids environment mismatch, resource waste, or state discontinuity problems caused by semantic ambiguity or vagueness. Furthermore, it achieves rapid recovery of the development environment through priority matching of reusable sandboxes, ensuring a continuous experience during development. When no reusable sandbox matching the personalized requirement information is found, a sandbox hot pool scheduling strategy is activated. By selecting sandboxes matching the personalized requirement information from the sandbox hot pool and configuring them according to the personalized requirement information, the delay in development environment configuration is reduced, and resource utilization efficiency is improved.

[0043] Based on the above implementation, to clarify the specific construction method of the sandbox hot pool, this embodiment also discloses the process of pre-constructing the sandbox hot pool, including: determining a first set containing multiple technology stack information and a second set containing multiple task types; determining the creation requirements of multiple runtime environments based on the combination of elements contained in the first and second sets; creating initial sandboxes that meet different creation requirements for runtime environments, and deploying the same code generation large model in each initial sandbox to obtain multiple sandboxes to be activated; and constructing the sandbox hot pool based on the multiple sandboxes to be activated. The execution entity can also preheat the sandboxes to be activated in the sandbox hot pool in advance according to the pre-determined active usage period; wherein, the active usage period is determined based on historical usage and / or task distribution information. Through the above method, this embodiment improves the system's resource utilization and response speed by arranging and combining technology stacks and task types, pre-fabricating sandboxes with consistent basic environments and unified large models in batches, and then performing precise preheating processing on the sandboxes to be activated by combining historical and real-time data.

[0044] Based on the above implementation, this embodiment also discloses a specific implementation method for scheduling sandboxes using a load balancing strategy. When different sandboxes are distributed across different nodes, based on the resource load of different nodes and a preset load balancing strategy, a reusable sandbox on the first target node is determined as a reusable sandbox matching personalized needs, or a sandbox to be activated on the first target node is determined as a sandbox to be activated matching personalized needs. The load balancing strategy is used to balance the usage of CPU resources, GPU resources, memory resources, network resources, and storage resources on each node, making resource usage on each node as even as possible. An example is provided to aid understanding: Currently, there are three nodes. Node A has a matching reusable sandbox, but its GPU utilization has reached 92%. Node B needs to activate a sandbox from the hot pool, and its GPU utilization is only 35%. Node C has a reusable sandbox, and its GPU utilization is 65%, but its network latency exceeds 100ms. When a user requests a GPU sandbox, the system first excludes node A (which poses a risk of GPU overload). Node B has a lower GPU load but requires activation time, while node C has a moderate GPU load but suffers from high latency. Although node B requires activation, its ample GPU resources ensure the smooth operation of subsequent tasks. Therefore, the system can select the sandbox on node B as the sandbox to be activated, matching the user's specific needs. This embodiment, while ensuring functional compatibility, utilizes a load balancing strategy to schedule the sandbox to the physical node with the optimal overall load, reducing the risk of single-point resource overload and improving overall resource utilization efficiency.

[0045] Building upon the sandbox scheduling method based on a large code generation model disclosed in processes 200 and 300, this disclosure provides another sandbox scheduling method based on a large code generation model. Specifically, it provides an implementation method for how to utilize snapshot locality to rationally schedule the sandbox. Please refer to [link / reference]. Figure 4 The flowchart, wherein process 400 includes the following steps: Step 401: In response to the absence of a reusable sandbox matching the personalized requirements information on any node, the existence of a sandbox to be activated corresponding to the personalized requirements information, but the second target node stores a sandbox snapshot matching the personalized requirements information, the second target node is controlled to restore a new reusable sandbox based on the sandbox snapshot, and the code development request is allocated to the second target node so that the second target node can allocate the new reusable sandbox to the target user to execute the code development request.

[0046] In this embodiment, when no reusable sandbox matching the personalized requirements exists on any node, and an inactive sandbox corresponding to the personalized requirements exists but a sandbox snapshot matching the personalized requirements is stored on the second target node, the executing entity controls the second target node to restore a new reusable sandbox based on the sandbox snapshot. Here, the second target node refers to a node that does not have an inactive sandbox corresponding to the personalized requirements but stores a sandbox snapshot matching the personalized requirements. The sandbox snapshot is a complete archive of the development environment state, including technology stack cloning, resource images, and runtime status. When a developer interrupts work, the system compresses the sandbox's disk, memory, and runtime status into a snapshot. Upon the next request, the system can quickly reconstruct a complete environment, including unsaved code, debug breakpoints, and even terminal history, on any node using this snapshot.

[0047] In this embodiment, after restoring the new reusable sandbox, the executing entity assigns the code development request to the second target node, so that the second target node can assign the new reusable sandbox to the target user to execute the code development request.

[0048] The following example helps to understand: When no reusable sandbox is available on any node, and a hot pool of sandboxes awaits activation on node A, if the system detects that node B stores a sandbox snapshot previously saved by the target user, the system can restore a new reusable sandbox based on the sandbox snapshot and assign the code development request to the second target node. The second target node then assigns the new reusable sandbox to the target user to execute the code development request.

[0049] Step 402: In response to the actual load of the target node exceeding the preset load threshold, determine the activity and availability requirements of each sandbox that is running on the target node.

[0050] In this embodiment, when the actual load of the target node exceeds a preset load threshold, the activity and availability requirements of each sandbox running on the target node are determined. Activity can be measured by user interaction frequency, resource consumption growth rate, and session persistence, while availability requirements refer to the tolerance threshold for service interruption for a specific task. These requirements can be categorized to reflect the criticality of the task; for example, real-time debugging sessions requiring millisecond-level migration are considered high-level, compilation tasks allowing second-level interruptions are considered medium-level, and offline training allowing minute-level pauses are considered low-level.

[0051] Step 403: Determine the hot migration sandbox and cold migration sandbox based on activity and availability requirements.

[0052] In this embodiment, the executing entity determines the hot migration sandbox and the cold migration sandbox based on activity level and availability requirements. The hot migration sandbox typically refers to a sandbox with activity levels greater than a first preset threshold and a high availability requirement level, while the cold migration sandbox typically refers to a sandbox with activity levels less than a second preset threshold and a low or medium availability requirement level. The first and second preset thresholds can be the same or different; developers can set the specific values ​​of the first and second preset thresholds according to actual needs.

[0053] Step 404: Use the User Space Checkpoint Recovery CRIU technique to migrate the hot migration sandbox to an idle node.

[0054] In this embodiment, the executing entity uses the Userspace Checkpoint Restore In Userspace (CRIU) technology to migrate the hot migration sandbox to an idle node. CRIU is a low-level mechanism for freezing and migrating runtime process states. It can save the complete state of a running program (including data in memory) like taking a photograph, and then restore it intact on another server, even maintaining network connectivity. Its core principle is to transfer the running application and its complete state to a new environment without interrupting service.

[0055] Step 405: Generate a snapshot or image of the cold migration sandbox, and regenerate a new sandbox consistent with the cold migration sandbox on an idle node using the snapshot or image.

[0056] In this embodiment, the execution entity generates a snapshot or image of the cold migration sandbox, and uses the snapshot or image to regenerate a new sandbox consistent with the cold migration sandbox on idle nodes, thereby maximizing the utilization of idle resources.

[0057] In this embodiment, the difference is... Figure 2 and Figure 3In the illustrated embodiment, step 401 specifically provides an implementation method for creating a new reusable sandbox, and steps 402-405 specifically provide an implementation method for rationally scheduling the sandbox when the target node is overloaded. There is a causal and dependent relationship between these two implementation methods. The implementation method provided in step 401 can exist independently, while the implementation methods provided in steps 402-405 depend on the implementation method disclosed in step 401. Therefore, step 401 can be applied independently in one embodiment, but steps 401 and 402-405 must be applied simultaneously in one embodiment. This embodiment exists only as a preferred embodiment that simultaneously includes two specific implementation methods.

[0058] The sandbox scheduling method based on a large code generation model provided in this embodiment quickly reconstructs a new reusable sandbox that matches personalized requirements when no sandbox is available, using sandbox snapshots, thus improving the recovery speed of the environment. Furthermore, when the actual load on the target node exceeds a preset load threshold, hot-migrating and cold-migrating sandboxes are determined based on the activity and availability requirements of each sandbox currently running on the target node. Different migration strategies are then applied to the hot-migrating and cold-migrating sandboxes respectively, thereby maximizing the utilization of idle resources while ensuring the core user experience.

[0059] To enhance understanding, this disclosure also provides a specific implementation scheme in conjunction with a particular application scenario.

[0060] In the code execution sandbox scheduling scenario of this implementation, the Coding Agent (AI code agent system) includes the following modules: request analysis and routing module, multi-level scheduler, snapshot manager, migration controller, and hot pool manager. The request analysis and routing module is responsible for parsing Coding Agent requests (i.e., code development requests mentioned in the above embodiments), identifying technology stack types, estimating task load characteristics, identifying session information, and determining whether an environment can be reused. The multi-level scheduler is divided into a session affinity scheduler (used to prioritize the reuse of allocated environments, i.e., sandboxes with the same session information or sandboxes with historical session information mentioned in the above embodiments), a load-aware scheduler (sandbox scheduling based on the actual load of nodes, prioritizing idle nodes), a technology stack balancing scheduler (used to identify the technology stack of tasks and avoid the concentration of similar tasks), and a snapshot locality scheduler (prioritizing nodes with snapshots). The snapshot manager is used to manage file system snapshots (Docker Commit), manage memory snapshots (CRIU), and the storage, distribution, and cleanup of snapshots. The migration controller is used to decide when to perform hot migration and cold migration, and to execute CRIU operations to ensure the transparency of the migration process. The hot pool manager is used to manage and maintain preheated sandbox instance pools by technology stack and dynamically adjust the pool capacity.

[0061] In this implementation, the hot pool manager maintains the sandboxes within the hot pool. Each sandbox needs to be preheated before joining the hot pool, with common dependencies already installed and grouped by technology stack, supporting immediate allocation and use. Its response time can reach less than 100 milliseconds. The capacity of the hot pool is dynamically adjusted based on historical load and technology stack usage frequency. The specific preheating steps for the sandbox are as follows: 1. Container creation and startup: Specifically, first create a Pod (the smallest deployment unit in Kubernetes, which can contain one or more containers) in Kubernetes (an open-source platform for automated deployment, scaling, and management of containerized applications), then pull the base image, start the container, and finally initialize the file system; 2. Verify the runtime version and functionality when loading the runtime of the corresponding technology stack; 3. Pre-install common dependencies and verify successful dependency installation by installing common packages according to the technology stack; 4. Prepare development tools: install code editing and debugging tools and configure the tool environment; 5. Health check: Specifically, this includes verifying the container's health status, runtime availability, and network connectivity. After successful verification, mark the container as READY. The total preheating time for the sandbox is 6-10 seconds.

[0062] In this implementation, the thermal pool manager can also manage the capacity of the thermal pool. Specifically, a baseline capacity of 15-30 sandbox instances can be initially allocated based on historical usage frequency, and these sandbox instances can be distributed according to the usage ratio of each technology stack. Then, the utilization rate of each technology stack can be monitored. When the utilization rate of a technology stack is > 80%, the capacity of that technology stack is increased; when the utilization rate of a technology stack is < 30%, the capacity of that technology stack is decreased. The capacity adjustment interval can be set to be evaluated every 5 minutes. The hot pool manager can also expand or shrink the capacity of the hot pool according to trigger conditions. The expansion trigger conditions are: hot pool utilization rate > 80%, waiting queue length > 5 for 2 consecutive minutes, and allocation failure rate > 5%. The specific expansion strategy is to prioritize expanding the technology stack with the highest utilization rate, expand 2-5 instances each time, and expand at least 1 minute apart. The shrinkage trigger conditions are: hot pool utilization rate < 30%, no waiting queue for 10 consecutive minutes, and total capacity > maximum capacity. The shrinkage restriction strategy is to prioritize shrinking the instance with the longest idle time, shrink 1-3 instances each time, and maintain the minimum capacity.

[0063] In this implementation, the preset optimization strategies for the hot pool include: 1. Intelligent predictive preheating: Based on the prediction of users' historical usage patterns, preheating is performed in advance before the users' active periods; 2. On-demand replenishment preheating: When a hot pool instance is allocated, a new instance is created immediately to replenish it, keeping the hot pool capacity stable. This is executed asynchronously and does not affect the current allocation; 3. Batch preheating: Multiple sandbox instances are created in batches and the preheating process is executed in parallel, thereby improving preheating efficiency.

[0064] In this implementation, the Coding Agent requests the sandbox multiple times within the same session. The system achieves environment reuse through session affinity, avoiding redundant initialization. Environment reuse scenarios include iterative code development (re-running after code modification), debugging processes (running code multiple times for debugging), test execution (running unit tests and integration tests), and continuous development (long-term development of the same project). The advantages of environment reuse are: installed dependencies do not need to be reinstalled, and the package manager cache is preserved; user-written code files are persistently stored in the sandbox, the working directory structure remains unchanged, and temporary files and compilation artifacts are retained; the Git (a distributed version control system) repository state remains unchanged, and the current branch, committed and uncommitted modification records are preserved; environment variables and configurations, background processes, and database connections do not need to be reinstalled.

[0065] In this implementation, the executing entity can use the session binding model to bind the session record structure. The binding state is ACTIVE, which means that the session is active and frequently used (interval < 5 minutes). The binding state is IDLE, which means that the session is idle and temporarily not used (5-30 minutes). The binding state is EXPIRED, which means that the session has expired and has not been used for more than 30 minutes.

[0066] In this implementation, the multi-level scheduler selects sandboxes according to the following priorities: Priority 1: Fully matched binding sandboxes (response time < 50ms), referring to healthy bound sandboxes with the same Session_ID, which can be reused immediately.

[0067] Priority 2: Sandboxes of the same user and project (response time < 500ms), which can refer to other session sandboxes with the same User_ID and Project_ID. These sandboxes may contain the same code and dependencies, and the working directory needs to be switched after reuse.

[0068] Priority 3: Sandboxes for different projects under the same user (response time 1-2 seconds), referring to sandboxes for other projects under the same User_ID, which may contain the same technology stack and tools, and require initialization of a new project environment after reuse.

[0069] Priority 4: New sandboxes in the hot pool (response time < 100ms), referring to hot pool sandboxes without binding relationships. After being assigned to the target user through technology stack matching, the project environment needs to be initialized.

[0070] In this implementation, the executing entity can also use a timeout policy to manage the bound sandboxes. Specifically, when the sandbox is idle for a short period (5 minutes), the session state changes from ACTIVE to IDLE, and the sandbox binding relationship is maintained; when the sandbox is idle for a medium period (30 minutes), the session state changes from IDLE to EXPIRED, the binding relationship between the sandbox and the session is released, and the sandbox is recycled to the hot pool or released; when the sandbox is in an absolute timeout period (2 hours), regardless of whether it is active, the binding between the sandbox and the session is forcibly released to prevent long-term resource occupation.

[0071] In this implementation, the load-aware scheduler schedules the sandbox in the following way: 1. Work Phase Identification: The resource requirements of the Coding Agent vary significantly across different work phases. Specifically, during the code writing phase, the resource requirements are low CPU and low memory, and it can be allocated to high-load nodes; during the code compilation phase, the resource requirements are high CPU and medium memory, and it can be preferentially allocated to nodes with sufficient CPU; during the code execution phase, the resource requirements are medium CPU and medium memory, and the scheduling strategy is balanced scheduling; during the test execution phase, the resource requirements are medium-high CPU, medium memory, and high IO, and it can be preferentially allocated to nodes with sufficient resources.

[0072] 2. Node Load Monitoring: The Coding Agent can monitor the load of each node in real time. Specific monitoring metrics include CPU utilization (current CPU usage percentage), CPU load (average load over 1 minute, 5 minutes, and 15 minutes), memory utilization (used memory / total memory), available memory (actual allocable memory), IO utilization (disk read / write activity), and network bandwidth utilization (inbound and outbound traffic). The Coding Agent can schedule sandboxes using a comprehensive load score. Each node's load score = CPU load × 0.4 + memory load × 0.3 + IO load × 0.2 + network load × 0.1, with a score range of 0-100. The lower the score, the less idle the node.

[0073] 3. Load-aware scheduling algorithm: The sandbox scheduling process is as follows: First, identify the task stage and resource requirements, parse request parameters, identify the technology stack and operation type, and estimate resource requirements; second, filter candidate nodes, filtering nodes with insufficient resources and high-load nodes (load > 80%), retaining the list of available nodes; then calculate node suitability, including resource matching score, load balancing score, snapshot locality score, and comprehensive score; finally, select the node with the highest score. The comprehensive score includes the node's total score, resource matching degree, and load balancing degree. The node's total score = resource matching degree × 0.3 + load balancing degree × 0.4 + snapshot locality × 0.3; resource matching degree = min(node ​​available resources / task required resources, 1.0); load balancing degree = (1 - node load score / 100).

[0074] 4. Load protection mechanisms are divided into high load protection and load balancing. High load protection involves: stopping new sandbox allocation when node load > 80%; triggering sandbox migration when node load > 90%; and forcibly evicting low-priority sandboxes when node load > 95%. Load balancing involves periodically (every 5 minutes) checking the cluster load distribution to identify load imbalances (highest load - lowest load > 30%), triggering sandbox rescheduling or migration. In this implementation, the technology stack load balancer schedules the sandboxes in the following way: 1. Technology stack resource characteristics: Different technology stacks have different resource usage characteristics. For example, Python has medium CPU characteristics, medium-high memory characteristics, and medium IO characteristics; Node.js has medium-low CPU characteristics, medium memory characteristics, and high IO characteristics.

[0075] 2. Technology stack identification, specifically through explicit specification in request parameters, file feature identification, and historical record query.

[0076] 3. Balanced scheduling strategy: The scheduling decision prioritizes the allocation of new tasks to the nodes with the fewest nodes in the same technology stack, avoiding resource competition caused by the concentration of similar tasks. CPU-intensive and I / O-intensive tasks can coexist, while memory-intensive tasks are avoided from being concentrated, thereby achieving resource complementarity.

[0077] In this implementation, the Coding Agent uses Docker commit to snapshot the sandbox file system. The snapshot content includes user code files, installed dependencies, configuration files, compilation artifacts, and data files. Snapshots are taken automatically at the end of the session, periodically every 30 minutes, after important operations (dependency installation, successful compilation), and manually triggered by the user. The snapshot naming format is as follows:<user_id> -<project_id> -<session_id> -<timestamp>.

[0078] In this implementation, the snapshot storage strategy is local storage (snapshots are preferentially stored on the node that created them), distributed storage (synchronized to a distributed storage system), and tiered storage (hot data: node local SSD storage (fast speed, suitable for high-performance computing, applicable to scenarios with high latency and bandwidth requirements), warm data: node local HDD storage (large capacity, low cost, suitable for scenarios requiring large amounts of storage but with lower speed requirements), and cold data: (object storage). The snapshot distribution method is proactive distribution (predicting the node that the user may use next and distributing snapshots in advance), on-demand retrieval (retrieval on demand when scheduled to a new node), and incremental transmission (only transmitting changed layers).

[0079] In this implementation, the snapshot locality scheduler prioritizes assigning tasks to nodes that already have snapshots. Locality score: Locality score = Snapshot integrity × 0.6 + Snapshot freshness × 0.4. Snapshot integrity: - Complete snapshot local: 1.0 - Partial layer local: 0.5 - No snapshot: 0.0. Snapshot freshness: - Latest version: 1.0 - 1 day ago: 0.8 - 1 week ago: 0.5 - 1 month ago: 0.2. The scheduling decision first queries which nodes have snapshots for the user / project, then calculates the node's comprehensive score (resource matching + load + locality), and finally prioritizes nodes with complete snapshots.

[0080] In this implementation, the snapshot manager is used for version management, incremental snapshots, snapshot deduplication, and snapshot cleanup. Version management means that each project retains the most recent few versions, supports rollback to historical versions, and automatically cleans up expired snapshots. Incremental snapshots utilize the Docker layer mechanism to save only changed file layers, reducing storage space. Snapshot deduplication identifies identical file layers and shares common layers. Snapshot cleanup periodically cleans up long-unused snapshots while retaining important snapshots marked by users. Furthermore, the recovery process when local snapshots are available is as follows: 1. Check snapshot availability, 2. Create a container using the snapshot image, 3. Start the container, 4. Verify the environment, 5. Ready and available. The total time is 2-5 seconds.

[0081] In this implementation, CRIU is a user-space process checkpointing and recovery technology. CRIU capabilities include saving the complete state of a process's memory, registers, file descriptors, etc., and restoring the process on the same or different machines without requiring modification of the process, without the user's awareness. It also supports Docker containers. Checkpoint content includes memory image, register state, file descriptors, process tree, signal state, and time information.

[0082] In this implementation, the snapshot timing for sandbox memory can be before migration (due to high node load or node maintenance), at periodic checkpoints (for long-running tasks), or at user request (to actively save the running state). The snapshot process is as follows: 1. Pause the container and send a signal to pause all processes; 2. Execute a CRIU dump (using the CRIU tool to save the state of currently running processes to a dump file), scan the process tree, save memory pages, save file descriptors, and generate a checkpoint file; 3. Compress and store the checkpoint file, storing it locally or in distributed storage; 4. Restore the container and send a signal to resume the process. The snapshot optimization steps are incremental snapshot (saving only changed memory pages), page deduplication (identifying identical memory pages), compression (using efficient compression algorithms), and parallel processing (multi-threaded parallel saving).

[0083] In this implementation, the migration controller migrates running sandboxes from one node to another. Migration triggering conditions include load balancing (source node overload), node maintenance (node ​​upgrade or restart required), fault recovery (node ​​failure), and resource optimization (consolidating scattered sandboxes). Migration decision: 1. Evaluate migration benefits, specifically assessing migration costs (time, network) and benefits (load reduction, resource optimization); execution is only performed if benefits > costs. 2. Select target nodes, choosing those with sufficient resources, low load, low network latency, and snapshot locality (a bonus). The migration process is as follows: Pre-iteration phase (optional, to reduce downtime): 1. Create an initial checkpoint on the source node; 2. Transfer the checkpoint to the target node; 3. Pre-create containers on the target node; 4. The source node continues to run, recording memory changes; Final migration phase: 1. The source node pauses containers, and downtime begins; 2. Create the final checkpoint, perform a CRIU dump (if there is pre-iteration, only save the increment); 3. Transfer the checkpoint to the target node, compressing, transmitting over high-speed network, and verifying integrity; 4. The target node restores containers, performs a CRIU restore to restore process state, restore network connectivity, and the process continues execution; 5. Update routes and bindings, update sandbox location information, update network routes, and the downtime ends; 6. Clean up the source node, delete the source container, and release resources. The migration downtime is: without pre-iteration: 5-10 seconds; with pre-iteration: < 1 second; virtually imperceptible to the user.

[0084] In this implementation, the following migration failure scenarios exist: insufficient target node resources, network transmission failure, CRIU recovery failure, and timeout. Rollback mechanism: 1. Detect migration failure; 2. Stop target node operations; 3. Restore the source node container and send a SIGCONT to resume the process; 4. Notify the scheduler of migration failure; 5. Analyze the cause of failure. Retry strategy: Automatically retry a number of times, with increasing retry intervals, and select different target nodes.

[0085] In this embodiment, the network connection processing by the executing entity specifically includes: TCP (connection-oriented transport layer protocol) connection maintenance: CRIU supports saving and restoring TCP connections, and TCP connections remain valid after migration; IP address processing: using an overlay network (a virtual network built on top of an existing physical network), sandbox IPs remain unchanged after migration, and the network layer automatically updates routes.

[0086] In this implementation, the development environment is quickly restored by prioritizing the matching of reusable sandboxes, ensuring a continuous experience during development. In addition, this implementation also discloses a sandbox hot pool scheduling strategy when no reusable sandbox matching the personalized requirements is available. By selecting sandboxes matching the personalized requirements from the sandbox hot pool and configuring them according to the personalized requirements, the delay in development environment configuration is reduced and resource utilization efficiency is improved. This implementation further determines technology stack and task type information by extracting user information, session information, and task requirement information, generating executable environment configuration information. This avoids environment mismatch, resource waste, or state discontinuity issues caused by semantic ambiguity or vagueness. Furthermore, it achieves rapid development environment recovery through priority matching of reusable sandboxes, ensuring a continuous experience during development. When no reusable sandbox matching the personalized requirements is available, a sandbox hot pool scheduling strategy is activated. By selecting sandboxes matching the personalized requirements from the hot pool and configuring them individually, the latency of development environment configuration is reduced, and resource utilization efficiency is improved. In addition, the sandbox scheduling method based on a large code generation model provided in this implementation quickly reconstructs new reusable sandboxes matching the personalized requirements when no available sandboxes are available, improving the speed of environment state recovery. Furthermore, when the actual load of the target node exceeds the preset load threshold, the hot migration sandbox and cold migration sandbox are determined based on the activity and availability requirements of each sandbox in operation on the target node. The hot migration sandbox and cold migration sandbox are migrated respectively based on different migration strategies, thereby maximizing the utilization of idle resources while ensuring the core user experience.

[0087] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a sandbox scheduling device based on a large code generation model. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0088] like Figure 5 As shown, the sandbox scheduling device 500 based on the code generation large model in this embodiment may include: a personalized demand information determination unit 501, a sandbox reuse unit 502, and a pre-built sandbox allocation unit 503.

[0089] The personalized requirement information determination unit 501 is configured to determine personalized requirement information based on the code development request initiated by the target user. Sandbox reuse unit 502 is configured to assign a reusable sandbox matching the personalized needs information to a target user in response to the existence of such a reusable sandbox; wherein the reusable sandbox is a sandbox that retains data associated with the target user. The pre-built sandbox allocation unit 503 is configured to, in response to the absence of a reusable sandbox that matches the personalized requirement information, determine the sandbox to be activated corresponding to the personalized requirement information from the pre-built sandbox hot pool, and allocate the sandbox to be activated to the target user; wherein, different sandboxes provide the same large code generation model in different operating environments.

[0090] The specific processing of the personalized demand information determination unit 501, the sandbox reuse unit 502, and the pre-built sandbox allocation unit 503, and the resulting technical effects, can be found in the respective references. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0091] In some optional implementations of this embodiment, the personalized requirement information determination unit 501 further includes: an information extraction module configured to extract user information, session information, and task requirement information from the code development request; and an information determination module configured to determine technology stack information and task type information based on the task requirement information. The technology stack information includes at least one of programming language, front-end / back-end, and design architecture; the task type information includes at least one of code writing, code compilation, and test execution. A reusable sandbox matching the personalized requirement information refers to a reusable sandbox where at least one of the user information, session information, technology stack information, and task type information matches. The more matching items, the higher the degree of matching. The independent contribution of session information, user information, technology stack information, and task type information to the degree of matching decreases sequentially. A reusable sandbox includes at least one of the following: a sandbox with the same user information, a sandbox with associated user information related to the user information, a sandbox with the same session information, and a sandbox with historical session information belonging to the session information.

[0092] In some optional implementations of this embodiment, the process of pre-building a sandbox hot pool in the pre-built sandbox allocation unit 503 includes: determining a first set containing multiple technology stack information and a second set containing multiple task types; determining the creation requirements of multiple runtime environments based on the combination of elements contained in the first set and the second set; creating initial sandboxes that meet different creation requirements for runtime environments, and deploying the same large code generation model in each initial sandbox to obtain multiple sandboxes to be activated; and building a sandbox hot pool based on the multiple sandboxes to be activated.

[0093] In some optional implementations of this embodiment, the process of pre-building the sandbox hot pool in the pre-built sandbox allocation unit 503 further includes: preheating the sandboxes to be activated in the sandbox hot pool in advance according to the pre-determined active usage period; wherein, the active usage period is determined based on historical usage and / or task distribution information.

[0094] In some optional implementations of this embodiment, the sandbox scheduling device 500 based on the code generation large model may further include: a first sandbox scheduling unit 504, configured to, in response to different sandboxes being distributed on different nodes, determine a reusable sandbox on a first target node as a reusable sandbox matching personalized needs or determine a sandbox to be activated on a target node as a sandbox matching personalized needs, based on the resource load of different nodes and a preset load balancing strategy; wherein, the load balancing strategy is used to balance the use of CPU resources, GPU resources, memory resources, network resources, and storage resources on each node.

[0095] In some optional implementations of this embodiment, the sandbox scheduling device 500 based on the code generation large model may further include: a second sandbox scheduling unit 505, configured to respond to the fact that no reusable sandbox matching the personalized requirement information exists at any node, or that there is an activating sandbox corresponding to the personalized requirement information but the second target node stores a sandbox snapshot matching the personalized requirement information, control the second target node to restore a new reusable sandbox based on the sandbox snapshot, and allocate the code development request to the second target node so that the second target node can allocate the new reusable sandbox to the target user to execute the code development request.

[0096] In some optional implementations of this embodiment, the sandbox scheduling device 500 based on the code generation large model may further include: a third sandbox scheduling unit 506, configured to, in response to the actual load of the target node exceeding a preset load threshold, determine the activity and availability requirements of each sandbox in operation on the target node; determine hot migration sandboxes and cold migration sandboxes based on the activity and availability requirements; migrate the hot migration sandboxes to idle nodes using the User Space Checkpoint Recovery (CRIU) technology; generate a snapshot or image of the cold migration sandboxes, and regenerate a new sandbox consistent with the cold migration sandboxes on the idle nodes using the snapshot or image.

[0097] This embodiment exists as a device embodiment corresponding to the above method embodiment. The sandbox scheduling device based on the code generation large model provided in this embodiment realizes the rapid recovery of the development environment through the priority matching of reusable sandboxes, ensuring a continuous experience during the development process. In addition, this implementation also discloses a sandbox hot pool scheduling strategy when there is no reusable sandbox matching the personalized requirement information. By filtering out the sandbox to be activated from the sandbox hot pool that matches the personalized requirement information, and performing personalized configuration of the sandbox to be activated according to the personalized requirement information, the delay in development environment configuration is reduced and resource utilization efficiency is improved. This implementation further determines technology stack and task type information by extracting user information, session information, and task requirement information, generating executable environment configuration information. This avoids environment mismatch, resource waste, or state discontinuity issues caused by semantic ambiguity or vagueness. Furthermore, it achieves rapid development environment recovery through priority matching of reusable sandboxes, ensuring a continuous experience during development. When no reusable sandbox matching the personalized requirements is available, a sandbox hot pool scheduling strategy is activated. By selecting sandboxes matching the personalized requirements from the hot pool and configuring them individually, the latency of development environment configuration is reduced, and resource utilization efficiency is improved. In addition, the sandbox scheduling method based on a large code generation model provided in this implementation quickly reconstructs new reusable sandboxes matching the personalized requirements when no available sandboxes are available, improving the speed of environment state recovery. Furthermore, when the actual load of the target node exceeds the preset load threshold, the hot migration sandbox and cold migration sandbox are determined based on the activity and availability requirements of each sandbox in operation on the target node. The hot migration sandbox and cold migration sandbox are migrated respectively based on different migration strategies, thereby maximizing the utilization of idle resources while ensuring the core user experience.

[0098] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the sandbox scheduling method based on the large code generation model described in any of the above embodiments.

[0099] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that enable a computer to implement the sandbox scheduling method based on a large code generation model as described in any of the above embodiments.

[0100] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when executed by a processor, can implement the sandbox scheduling method based on a large code generation model described in any of the above embodiments.

[0101] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0102] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0103] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0104] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the sandbox scheduling method based on a code-generated large model. For example, in some embodiments, the sandbox scheduling method based on a code-generated large model can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the sandbox scheduling method based on a code-generated large model described above can be performed. Alternatively, in other embodiments, computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to execute a sandbox scheduling method based on a large code generation model.

[0105] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0106] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0109] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0110] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0111] According to the technical solution of this disclosure, the development environment is quickly restored by prioritizing the matching of reusable sandboxes, ensuring a continuous experience during the development process. In addition, this implementation also discloses a sandbox hot pool scheduling strategy when no reusable sandbox matching the personalized requirements information is available. By selecting sandboxes to be activated from the sandbox hot pool that match the personalized requirements information, and configuring the sandboxes to be activated according to the personalized requirements information, the delay in development environment configuration is reduced and resource utilization efficiency is improved. This implementation further determines technology stack and task type information by extracting user information, session information, and task requirement information, generating executable environment configuration information. This avoids environment mismatch, resource waste, or state discontinuity issues caused by semantic ambiguity or vagueness. Furthermore, it achieves rapid development environment recovery through priority matching of reusable sandboxes, ensuring a continuous experience during development. When no reusable sandbox matching the personalized requirements is available, a sandbox hot pool scheduling strategy is activated. By selecting sandboxes matching the personalized requirements from the hot pool and configuring them individually, the latency of development environment configuration is reduced, and resource utilization efficiency is improved. In addition, the sandbox scheduling method based on a large code generation model provided in this implementation quickly reconstructs new reusable sandboxes matching the personalized requirements when no available sandboxes are available, improving the speed of environment state recovery. Furthermore, when the actual load of the target node exceeds the preset load threshold, the hot migration sandbox and cold migration sandbox are determined based on the activity and availability requirements of each sandbox in operation on the target node. The hot migration sandbox and cold migration sandbox are migrated respectively based on different migration strategies, thereby maximizing the utilization of idle resources while ensuring the core user experience.

[0112] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0113] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.< / timestamp>

Claims

1. A sandbox scheduling method based on a large code generation model, comprising: Based on the code development requests initiated by the target users, determine the personalized requirements information; In response to the existence of a reusable sandbox that matches the personalized needs information, the reusable sandbox that matches the personalized needs information is assigned to the target user; wherein, the reusable sandbox is a sandbox that retains data associated with the target user; In response to the absence of a reusable sandbox matching the personalized requirements information, a sandbox to be activated corresponding to the personalized requirements information is determined from a pre-built sandbox hot pool, and the sandbox to be activated is assigned to the target user; wherein, different sandboxes provide the same large code generation model in different operating environments.

2. The method according to claim 1, wherein, The process of determining personalized requirements based on the code development request initiated by the target user includes: Extract user information, session information, and task requirement information from the code development request; The technology stack information and task type information are determined based on the task requirement information; wherein, the technology stack information includes at least one of programming language, front-end and back-end, and design architecture, and the task type information includes at least one of code writing, code compilation, and test execution.

3. The method according to claim 2, wherein, A reusable sandbox that matches the personalized requirements information refers to a reusable sandbox that matches at least one of the user information, the session information, the technology stack information, and the task type information. The more matching items there are, the higher the degree of matching.

4. The method according to claim 3, wherein, The degree of independent contribution of the session information, user information, technology stack information, and task type information to the matching degree decreases in that order.

5. The method according to claim 2, wherein, The reusable sandbox includes at least one of the following: Sandboxes with identical user information, sandboxes with associated user information related to the user information, sandboxes with identical session information, and sandboxes with historical session information belonging to the session information.

6. The method according to claim 1, wherein, The process of pre-constructing the sandbox thermal pool includes: Determine a first set containing information on multiple technology stacks and a second set containing information on multiple task types; Based on the combination of elements contained in the first set and the second set, the creation requirements of multiple runtime environments are determined; An initial sandbox is created to meet the different creation requirements, and the same code generation model is deployed in each of the initial sandboxes to obtain multiple sandboxes to be activated. The sandbox thermal pool is constructed based on multiple sandboxes to be activated.

7. The method according to claim 6, further comprising: According to the predetermined active usage period, the sandbox to be activated in the sandbox hot pool is preheated in advance; wherein, the active usage period is determined based on historical usage and / or task issuance information.

8. The method according to any one of claims 1-7, further comprising: In response to the distribution of different sandboxes on different nodes, based on the resource load of the different nodes and the preset load balancing strategy, the reusable sandbox on the first target node is determined as a reusable sandbox matching the personalized needs, or the sandbox to be activated on the first target node is determined as a sandbox to be activated matching the personalized needs; wherein, the load balancing strategy is used to balance the use of CPU resources, GPU resources, memory resources, network resources, and storage resources on each node.

9. The method according to claim 8, further comprising: In response to the situation where no reusable sandbox matching the personalized requirement information exists on any node, or a sandbox corresponding to the personalized requirement information exists but the second target node stores a sandbox snapshot matching the personalized requirement information, the second target node is controlled to restore a new reusable sandbox based on the sandbox snapshot, and the code development request is allocated to the second target node, so that the second target node can allocate the new reusable sandbox to the target user to execute the code development request.

10. The method of claim 8, further comprising: In response to the actual load of the target node exceeding a preset load threshold, the activity and availability requirements of each sandbox in operation on the target node are determined; The hot migration sandbox and cold migration sandbox are determined based on the activity level and availability requirements; The hot migration sandbox is migrated to an idle node using the CRIU technique with user space checkpoint recovery. Generate a snapshot or image of the cold migration sandbox, and regenerate a new sandbox consistent with the cold migration sandbox on an idle node using the snapshot or image.

11. A sandbox scheduling device based on a large code generation model, comprising: The personalized requirements information determination unit is configured to determine personalized requirements information based on the code development request initiated by the target user; A sandbox reuse unit is configured to, in response to the existence of a reusable sandbox that matches the personalized needs information, assign the reusable sandbox that matches the personalized needs information to the target user; wherein the reusable sandbox is a sandbox that stores data associated with the target user. A pre-built sandbox allocation unit is configured to, in response to the absence of a reusable sandbox matching the personalized requirement information, determine a sandbox to be activated corresponding to the personalized requirement information from a pre-built sandbox pool, and allocate the sandbox to be activated to the target user; wherein different sandboxes provide the same large code generation model in different operating environments.

12. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the sandbox scheduling method based on the large code generation model as described in any one of claims 1-6.

13. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the sandbox scheduling method based on a large code generation model according to any one of claims 1-6.

14. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the sandbox scheduling method based on a large code generation model according to any one of claims 1-6.

Images