Network security access method and device for large model task, equipment and medium

Abstract

Embodiments of the present disclosure relate to a network security access method and device for large model tasks, equipment and medium, wherein the method comprises: receiving a target access request sent by a first container group, wherein the target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in a built-in network card type node and an external network card type node; if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, the target access request is sent to the second container group, wherein the routing relationship library includes mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the same task. The present disclosure enables the container groups of the same task to communicate under heterogeneous models, and the container groups of different tasks can be isolated.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of cloud computing, and particularly relates to a network security access method and device for a large model task, equipment and a medium. BACKGROUND

[0002] In a cloud computing scenario, a cloud service provider of Model as a Service (MaaS) can provide a large model as a service to a user, and the user hopes that the model related task of the user runs in an isolated network environment. A task can be composed of a container group (Pod) or multiple container groups. In the related art, network isolation at the task level can be implemented for the network card of the container group. However, when the model of the container group is a heterogeneous model, including an internal remote network interface card (RNIC) model and an external remote network interface card model, it is difficult to implement network isolation at the task level. SUMMARY

[0003] To solve the above technical problems, the present disclosure provides a network security access method and device for a large model task, equipment and a medium.

[0004] The present disclosure provides a network security access method for a large model task, which comprises the following steps:

[0005] Receiving a target access request sent by a first container group, wherein the target access request comprises a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in an internal network card model node and an external network card model node;

[0006] If it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card model node, the target access request is sent to the second container group, wherein the routing relationship library comprises mapping information between the network card addresses of the container groups in the external network card model node and the internal network card model node and the same task.

[0007] The present disclosure also provides a network security access device for a large model task, which comprises:

[0008] receive a target access request sent by a first container group, wherein the target access request comprises a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in an inbuilt network card type node and an external network card type node;

[0009] send the target access request to the second container group if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, wherein the routing relationship library comprises mapping information between network card addresses of container groups in the external network card type node and the inbuilt network card type node and the same task.

[0010] The embodiment of the present disclosure further provides an electronic device, comprising: a processor; a memory for storing executable instructions of the processor; and the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the network security access method for large model tasks as provided by the embodiment of the present disclosure.

[0011] The embodiment of the present disclosure further provides a computer readable storage medium, which stores a computer program for executing the network security access method for large model tasks as provided by the embodiment of the present disclosure.

[0012] Compared with the prior art, the technical scheme provided by the embodiments of the present disclosure has the following advantages: the network access scheme provided by the embodiments of the present disclosure receives a target access request sent by a first container group, wherein the target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in a built-in network card type node and an external network card type node; if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, the target access request is sent to the second container group, wherein the routing relationship library includes mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the same task. By using the above technical scheme, when receiving an access request of one of the two container groups respectively deployed in the built-in network card type node and the external network card type node, the container network interface in the external network card type node can determine whether the two container groups belong to the same task based on the routing relationship library and the two network card addresses, and if so, the access request is allowed to be sent to the other container group. When the container groups of the same task are deployed in the heterogeneous nodes of the external network card type node and the built-in network card type node, since the container network interface of the external network card type node includes the mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the task in the routing relationship library in advance, communication between the container groups of the same task can be realized based on the routing relationship library under the heterogeneous nodes, the container groups of different tasks can realize a certain degree of task-level isolation, the invalidation of network isolation caused by the inability to manage the network access of the built-in network card in the built-in network card type node is avoided, and the security of network access is effectively improved. BRIEF DESCRIPTION OF DRAWINGS

[0013] The above and other features, advantages, and aspects of the embodiments of the present disclosure will become more apparent by describing in detail some embodiments thereof with reference to the attached drawings. Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. It should be understood that the drawings are schematic, and the original and elements are not necessarily drawn according to the scale.

[0014] Figure 1 A flowchart of a network security access method for a large model task provided by some embodiments of the present disclosure;

[0015] Figure 2 A schematic diagram of network access under a heterogeneous node provided by some embodiments of the present disclosure;

[0016] Figure 3 Another schematic diagram of network access under a heterogeneous node provided by some embodiments of the present disclosure;

[0017] Figure 4Another flowchart of a network security access method for a large model task provided by some embodiments of the present disclosure is shown in FIG. 6;

[0018] Figure 5 A schematic diagram of a split architecture provided by some embodiments of the present disclosure is shown in FIG. 7;

[0019] Figure 6 A schematic diagram of a control plane architecture provided by some embodiments of the present disclosure is shown in FIG. 8;

[0020] Figure 7 A structural schematic diagram of a network security access device for a large model task provided by an embodiment of the present disclosure is shown in FIG. 9;

[0021] Figure 8 A structural schematic diagram of an electronic device provided by an embodiment of the present disclosure is shown in FIG. 10. DETAILED DESCRIPTION

[0022] Embodiments of the present disclosure will be described in more detail by referring to the drawings. Although certain embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments set forth herein, but rather the embodiments are provided to make the disclosure more thorough and complete. It should be understood that the drawings and embodiments of the present disclosure are merely for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0023] It should be understood that each of the steps recited in the method embodiments of the present disclosure can be executed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the present disclosure is not limited in this respect.

[0024] The term “comprising” and variations thereof as used herein are open-ended, that is, “comprising but not limited to.” The term “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. The term “one embodiment” is used herein to mean at least one embodiment; the term “another embodiment” is used herein to mean at least one additional embodiment; the term “some embodiments” is used herein to mean at least some embodiments. Relative terms such as “first,” “second,” and the like can be used herein to describe various elements, but are not intended to connote a relative importance or a particular order of execution. Other definitions will be provided in the description that follows.

[0025] It should be noted that the terms “first,” “second,” and the like as mentioned in the present disclosure are merely used to distinguish different devices, modules, or units, and are not intended to limit the functions of these devices, modules, or units or the order or interdependence of these functions.

[0026] It should be noted that the terms “one,” “multiple,” and the like as used in the present disclosure are illustrative and not limiting, and those skilled in the art should understand that “one or more” should be understood unless the context clearly indicates otherwise.

[0027] Names of messages or information exchanged between multiple devices in the embodiments of the present disclosure are only for illustrative purposes, and are not intended to limit the scope of the messages or information.

[0028] In a cloud computing scenario, model as a service as a cloud service provider (CSP) can provide cloud services to serve model entities of different model vendors. Specifically, the CSP can undertake a large model of a model vendor, and then provide inference, fine-tuning, and other services based on the large model. A user wants to run his own model-related tasks in an isolated network environment.

[0029] When an application is deployed by a business in model as a service using a custom resource (CRD), there can be different tasks, each task having several container groups. Remote direct memory access (RDMA) communication is needed between different tasks, i.e., between different container groups of the same application. For example, assume that there are two tasks, A and B, in a custom resource, A has a container group a, and B has a container group b. a is deployed on a built-in remote network interface card model (referred to as a built-in network card model) node, and b is deployed on an external remote network interface card model (external network card model) node. Communication between a and b indicates that there is RDMA communication between heterogeneous models. In related technologies, when target tasks of an application are divided into different tasks, a container network interface (CNI) on the local machine can take over the remote network interface card on the local machine, and then use a routing table and other methods to control network access of the container groups of each task, to achieve network isolation at the task level. However, this method cannot directly take over the built-in network card in the graphics processing unit (GPU) of the built-in network card model node by the central processing unit (CPU), i.e., the container network interface cannot manage the built-in network card in the GPU, so effective network isolation cannot be achieved. If a container group is deployed on a built-in network card model node, it can send and receive data at will, which can cause potential information leakage.

[0030] To solve the above problems, the present disclosure provides a network security access method for large model tasks, which will be described below in conjunction with specific embodiments.

[0031] Figure 1A flowchart of a network security access method for a large model task provided by an embodiment of the present disclosure is shown in FIG. 1. The method can be executed by a network security access device for a large model task. The device can be implemented by software and / or hardware, and can be integrated in an electronic device. As shown in FIG. 1, the method includes the following steps. Figure 1

[0032] In step 101, a target access request sent by a first container group is received. The target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed. The first container group and the second container group are respectively deployed in an inbuilt network card type node and an external network card type node.

[0033] The network security access method for a large model task of the embodiment of the present disclosure can be executed by a model as a service cloud service platform. The cloud service platform can provide cloud services for different models, and provide inference and fine tuning services based on the models. The cloud service platform can manage network access of a task corresponding container group of a model user. The first container group can be a container group initiating network access. The second container group can be a container group accepting network access. The container group can be the smallest scheduling unit in the container technology. The container group can include one or more containers. Containers in the same container group share resources. Model inference and model fine tuning (SFT) tasks can be executed in the container group. The container group can be used to execute model inference or model fine tuning tasks of a user. The model of the embodiment of the present disclosure can be a large language model. The large language model can be a natural language processing model. The large language model can learn rules and structures of natural language, understand the meaning of natural language, and generate coherent text with correct grammar and semantics according to the understood meaning. The large language model can even generate images or videos.

[0034] The first network card can be a network card for implementing network communication of the first container group. The first network card is a network card configured when the first container group is created. The first network card address can be an Internet Protocol (IP) address of the first network card. The second network card can be a network card for implementing network communication of the second container group. The second network card is a network card configured when the second container group is created. The second network card address can be an Internet Protocol (IP) address of the second network card.

[0035] ​The built-in network card model node can be a node with a remote network interface card (NIC) inside the graphics processor, that is, a node that communicates through remote direct memory access (RDMA) through a built-in network card. The graphics processor with a built-in network card can be a non-mainstream processor. The built-in network card has the same functions as a general network card, but can only be used by the graphics processor. That is, the application on the node can use the built-in network card by controlling the graphics processor, and the central processing unit cannot control the built-in network card. The external network card model node can be a node without a network card inside the graphics processor, which communicates through an external network card. The application on the node can control the external network card through the central processing unit. The first container group and the second container group are deployed on two different model nodes, that is, on heterogeneous model nodes. One way is to deploy the first container group on the built-in network card model node and the second container group on the external network card model node. Another way is to deploy the first container group on the external network card model node and the second container group on the built-in network card model node. The target access request can be a network access request sent by the first container group to access the second container group, and can be an access request between the two container groups of the heterogeneous model nodes.

[0036] Specifically, when the first container group needs to access the second container group, the first container group can send a target access request carrying the first network card address of the first network card and the second network card address of the second container group to be accessed to the network security access device for large model tasks. The network security access device for large model tasks can receive the target access request.

[0037] Exemplarily, Figure 2 The schematic diagram of network access under heterogeneous models provided by some embodiments of the present disclosure is as follows, Figure 2 As shown in the figure, the built-in network card model node A and the external network card model node B are shown. The built-in network card model node A includes two graphics processors with built-in network cards, and the external network card model node B includes two graphics processors and two external network cards. The first container group of the built-in network card model node A can send a target access request to access the second container group in the external network card model node B, or the first container group of the external network card model node B can send a target access request to access the second container group in the built-in network card model node A.

[0038] In step 102, if it is determined through the first container network interface in the external network card model node that the first container group and the second container group belong to the same task based on the routing relationship library, the first network card address and the second network card address, the target access request is sent to the second container group. The routing relationship library includes mapping information between the network card addresses of the container groups in the external network card model node and the built-in network card model node and the same task.

[0039] The container network interface can be a standard interface for providing network configuration for a container group, and the container network interface can be defined with a set of interface specifications, and specification documents and standard implementations are provided. Through the container network interface, the container group can interact with a remote network interface card or a network interface card (NIC). The first container network interface can be a container network interface in a web card model node, and the container network interface can include a routing relationship library.

[0040] The mapping information between the network card address and the task is the mapping relationship between the network card address and the task label. The routing relationship library can include a plurality of network card addresses and a plurality of task labels having a mapping relationship, each network card address has a mapping relationship with a task label, one container group corresponds to one task label, and at least one network card address of one container group has a mapping relationship with the corresponding task label. Special is that the plurality of network card addresses include the network card addresses of the container groups in the external web card model node and the network card addresses of the container groups in the internal web card model node, that is, the plurality of network card addresses include at least one internal web card address and at least one external web card address. The internal web card address can be the address of the internal web card set in the graphics processor, and a plurality of web cards can be set in one graphics processor. The network card address corresponding to the container group in the above-mentioned internal web card model node is an internal web card address. The external web card address can be the address of the external web card not in the graphics processor, and the network card address corresponding to the container group in the above-mentioned external web card model node is an external web card address. The routing relationship library can be created by the first container network interface, and the first container network interface can receive the mapping relationship between the internal web card address of the container group and the task label sent by the information acquisition plug-in of the second container network interface in the internal web card model node, and then store it in the routing relationship library, so that the container group in the external web card model node can access and receive the access of the container group in the internal web card model node. And the routing relationship library is synchronized to the container network interface of each node, that is, the container network interfaces of different nodes can jointly maintain one routing relationship library, and operations such as adding, deleting and modifying the routing relationship library are performed.

[0041] The information acquisition plug-in can be a plug-in set in the container network interface of the built-in network card type node for acquiring container group related information. Specifically, container group configuration information can be acquired when the container group is created, and the mapping relationship between the built-in network card address corresponding to the container group and the task label can be extracted from the container group configuration information. The task can be a model related task issued or executed by the user through an application program under the cloud service platform. Specifically, the task can include model inference, model fine tuning, and the like. The application program can be a distributed application program in model as a service or an application program deployed based on a custom resource. For example, the application program can be an application program for processing question and answer data based on a large model, or the application program can be an application program for training a model based on a large model. The task label can be a label uniquely representing the task and can be represented by letters and / or numbers. For example, the task label can be a task identifier such as a task name and / or a task serial number.

[0042] Specifically, when the first container group is deployed in the built-in network card type node and the second container group is deployed in the external network card type node, and the target access request is sent by the first container group in the built-in network card type node to the built-in network card corresponding to the graphics processing unit, after receiving the target access request sent by the first container group, the method further includes: sending the target access request to the first container network interface corresponding to the second container group, and the network security access device for large model tasks determining whether the task corresponding to the first network card address and the task corresponding to the second network card address are the same through the routing relationship library, the first network card address and the second network card address in the first container network interface. If yes, it means that the first container group and the second container group belong to the same task. Since the container groups in the same task can access each other, the target access request can be sent to the second network card corresponding to the second network card address of the second container group, and the second container group receives the target access request through the second network card. If the first container network interface determines that the first container group and the second container group do not belong to the same task, since the container groups of different tasks need to be network isolated, the sending of the target access request to the second container group can be refused to prevent the first container group from accessing the network across tasks, thereby realizing network isolation between container groups of different tasks under heterogeneous machines.

[0043] When the first container group is deployed on an external network card type node, the second container group is deployed on an internal network card type node, and the target access request is sent by the external network card outside the graphics processor of the first container group in the external network card type node, the network security access device for large model tasks can send the target access request to the first container network interface of the first container group, and determine whether the tasks corresponding to the first network card address and the second network card address are the same through the routing relationship library, the first network card address and the second network card address in the first container network interface. If yes, it means that the first container group and the second container group belong to the same task. Since the container groups in the same task can access each other, the target access request is sent to the corresponding internal network card of the second container group in the graphics processor. The second container group can obtain the target access request through the internal network card. If the first container network interface of the first container group determines that the first container group and the second container group do not belong to the same task, the sending of the target access request to the second container group can be refused to prevent the first container group from accessing the network across tasks, thereby realizing network isolation between container groups of different tasks in heterogeneous machines.

[0044] In some embodiments, determining that the first container group and the second container group belong to the same task through the first container network interface in the external network card type node based on the routing relationship library, the first network card address and the second network card address can include: matching the first network card address and the second network card address in the routing relationship library through the first container network interface, respectively, to determine the first task label corresponding to the first network card address and the second task label corresponding to the second network card address; and if the first task label and the second task label are the same, it is determined that the first container group and the second container group belong to the same task.

[0045] The first task label can represent the task to which the first container group belongs. The second task label can represent the task to which the second container group belongs. When the network security access device for large model tasks determines whether the first container group and the second container group belong to the same task through the first container network interface in the external network card type node, it can query the first task label corresponding to the first network card address and the second task label corresponding to the second network card address in the routing relationship library, and then determine whether the first task label and the second task label are the same. If yes, it is determined that the first container group corresponding to the first task label and the second container group corresponding to the second task label belong to the same task; otherwise, it is determined that the first container group and the second container group do not belong to the same task.

[0046] For example, if IP1 and Grp1 have a mapping relationship in the routing relationship library, IP2 and Grp1 have a mapping relationship, and the first network card address is IP1 and the second network card address is IP2, since the task labels corresponding to the first network card address and the second network card address are both Grp1, it is determined that the first container group and the second container group belong to the same task.

[0047] In the above scheme, the mapping relationship between the network card address and the task tag recorded in the routing relationship library is used to determine whether the container groups belong to the same task, and the mapping relationship supports dynamic adjustment, thereby improving the flexibility and efficiency of network isolation between container groups and reducing the cost of adjusting the existing network isolation.

[0048] Exemplarily, Figure 3 Another schematic diagram of network access under a heterogeneous machine type is provided for some embodiments of the present disclosure, as shown in the figure. Figure 3 As shown in the figure, the network access under a heterogeneous machine type is shown, node A is a built-in network card machine type node, including two internal built-in network cards, node B is an external network card machine type node, including two graphic processors (not shown in the figure) and two external network cards, container group A and container group B are in node A, corresponding to container network interface 1, the container network interface 1 cannot manage the built-in network card in the graphic processor, container group C and container group D are in node B, corresponding to container network interface 2; assuming that the first container group is container group A, the first container network interface is container network interface 1, the first network card is a built-in network card, the second container group is container group C, the second network card is an external network card, and the second container network interface is container network interface 2, the container network interface 2 can obtain the mapping relationship between the built-in network card address and the task tag of the container group in node A from the information acquisition plug-in of the container network interface 1 and store it in the routing relationship library, the container network interface 2 obtains the target access request from the built-in network card corresponding to the container group A, and determines the task tags corresponding to the first network card address and the second network card address in the target access request based on the routing relationship library, such as the same task tag Grp1 in the figure, determines that the container group A and the container group C belong to the same task, forms an isolated network X, allows network access, and can send the target access request to the container group C.

[0049] Figure 3 In the middle, container group B and container group D belong to the same task and form an isolated network Y, corresponding to the same task tag Grp2, if the first container group is container group B, the container network interface 2 determines that the first network card address corresponds to the task tag Grp2 and the second network card address corresponds to the task tag Grp1 based on the routing relationship library, and the container group B and the container group C are deployed in the same task, the target network access can be rejected.

[0050] Further, if the network security access device facing the large model task determines that the first task label and / or the second task label is a service label, it is determined that the first container group and the second container group meet the access condition. The service label can be used to mark a service container group, the service container group can be a container group providing a system service, the service container group can have network access with other container groups, the system service can be understood as a service not directly related to the task and related to the system itself, for example, the system service can include a system storage service, a system network service, and the like. As shown in Figure 2 A service container group is included in both node A and node B, and if the first container group and / or the second container group is a service container group, access can be performed. When there is a service container group between the two container groups of network access, network access between the two container groups is allowed, ensuring that system services can be performed normally.

[0051] The network isolation scheme of the present scheme can guarantee a certain security at the task level under a heterogeneous machine type, a large number of heterogeneous machines are used for the deployment of some distributed reasoning, thereby improving the performance, various heterogeneous resources can be efficiently used at the same time, and the same security as the homogeneous machine type can be achieved, that is, the security index is maintained at a relatively high level, which is close to the security of the task level container group isolation under the homogeneous machine type.

[0052] The network access scheme provided by the embodiments of the present disclosure receives a target access request sent by a first container group, wherein the target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in a built-in network card type node and an external network card type node; if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, the target access request is sent to the second container group, wherein the routing relationship library includes mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the same task. By using the above technical solution, when receiving an access request of one of two container groups respectively deployed in a built-in network card type node and an external network card type node, it can be determined whether the two container groups belong to the same task based on a routing relationship library and two network card addresses by using a container network interface in the external network card type node, and if so, the access request is sent to the other container group. When the container groups of the same task are deployed in heterogeneous nodes of the external network card type node and the built-in network card type node, since the container network interface of the external network card type node includes mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the task in the routing relationship library in advance, communication between the container groups of the same task can be realized based on the routing relationship library in the heterogeneous nodes, the container groups of different tasks can realize a certain degree of task-level isolation, the invalidation of network isolation caused by the inability of the built-in network card type node to manage the network access of the built-in network card is avoided, and the security of network access is effectively improved.

[0053] Exemplary, Figure 4 Another flowchart of a network security access method for a large model task provided by some embodiments of the present disclosure is shown in Figure 4 As shown in a feasible implementation, before step 101, the network security access method for a large model task of the embodiments of the present disclosure can further include the following steps:

[0054] Step 401, in response to a container creation request of a target task, creating a target container group in at least one target node, and assigning a target task label to the target container group, wherein the number of target container groups is one or more.

[0055] The target task can be a model-related task issued by the user through the target application program on the cloud service platform. The target application program can be the application program currently being processed. For example, the target application program can be a question and answer program, and the target task can be a model inference task of the question and answer program. The target node can be a node for executing the target task. The number of target nodes can be one or more. The target container group can be a container group for executing the target task. One or more target container groups are created in each target node. The target task label can be a label representing the target task.

[0056] Specifically, when the network security access device for large model tasks receives a target task, it can be regarded as receiving a container creation request of the target task. The target container group required by the container creation request can be randomly selected from at least one target node among multiple nodes. At least one target container group is created in each target node. The specific number is set according to the actual situation. The target task label of the target task is assigned to each target container group, that is, each container group has a corresponding task label. When the target container group is created, a corresponding network card address is assigned. For nodes with built-in network cards, built-in network card addresses are assigned. For nodes with external network cards, external network card addresses are assigned.

[0057] In some embodiments, the prefill subtask (Prefill) and the decode subtask (Decode) in the target task are separately run through at least one target node with a built-in network card type and at least one target node with an external network card type. The target task can be a split architecture. The target task can include a prefill subtask and a decode subtask. The prefill subtask and the decode subtask are split and independently run on different graphics processor instances, that is, run on a heterogeneous machine type. The heterogeneous machine type in the embodiments of the present disclosure includes a node with a built-in network card type and a node with an external network card type. The prefill subtask can run on the node with a built-in network card type, and the decode subtask can run on the node with an external network card type. Alternatively, the prefill subtask runs on the node with an external network card type, and the decode subtask runs on the node with a built-in network card type.

[0058] An exemplary split architecture is provided as follows. Figure 5 An exemplary split architecture is provided as follows. Figure 5 As shown in the figure, the prefill subtask and the decode subtask are split and independently run on different graphics processor instances. For example, the prefill instance focuses on the calculation of the prefill subtask, and the decode instance focuses on the calculation of the decode subtask. After the prefill instance completes the calculation, the key-value cache (KV Cache) is calculated. After completion, the key-value cache can be transmitted to the decode instance, and the latter generates the result.

[0059] When the target task is not a separate architecture, that is, the pre-filling sub-task and the decoding sub-task are executed by one graphics processor, and is executed by a built-in network card model node or an external network card model node, the network access of the external network card model node does not have the problem of heterogeneous model network isolation cannot be implemented, and the network access of the built-in network card model node can solve the problem of heterogeneous model network isolation by the model provider.

[0060] In a traditional large model inference framework, the pre-filling sub-task and the decoding sub-task are usually executed by the same graphics processor. The scheduler of the inference engine will switch between the two sub-tasks according to the memory usage and the request queue state to complete the entire inference process, which may cause resource competition and performance degradation.

[0061] In the above scheme, by separating the pre-filling stage and the decoding stage in the task, resource allocation can be optimized independently for the characteristics of different stages, performance can be optimized, and resource utilization and flexibility can be improved, which helps to cope with inference tasks of different scales and complexities.

[0062] Step 402, for each target node, determine the node model according to the container network interface of the target node, and establish the mapping relationship between the network card address of the target container group and the target task label based on the node model when the target container group is created, and store the mapping relationship in the routing relationship database.

[0063] The node model can be a model determined by a node according to whether the graphics processor includes a built-in network card. The node model can include a built-in network card model and an external network card model. The built-in network card model can be a model in which the graphics processor of the node has a built-in network card. The external network card model can be a model in which the graphics processor of the node does not have a network card and communicates through an external network card.

[0064] Specifically, the network security access device for large model tasks can determine the node model of the current target node through the container network interface of each target node, and establish the mapping relationship between the network card address of the target container group and the target task label in different ways for different node models when the target container group is created, especially the mapping relationship between the built-in network card address of the target container group and the target task label in the built-in network card model node. Then store the mapping relationship in the routing relationship database, which stores the mapping relationship between the network card address of the target container group and the target task label of each target node, and synchronize the routing relationship database to the container network interface of each target node. Or after the container network interface of each target node determines the mapping relationship between the network card address of the target container group and the target task label, the mapping relationship can be synchronized to the container network interface of other nodes. The mapping relationships of different nodes are synchronized to each other, and each container network interface can construct a routing relationship database.

[0065] In some embodiments, determining the node type of the target node according to the container network interface of the target node can include: if a built-in NIC type label is obtained through the container network interface of the target node, determining that the node type of the target node is a built-in NIC type; otherwise, determining that the node type of the target node is an external NIC type.

[0066] The built-in NIC type label can be a label indicating that a node belongs to a built-in NIC type. When a node is labeled with the label, it indicates that the graphics processor of the node includes a built-in NIC. Optionally, the built-in NIC type label is added when a built-in NIC type node is added. Specifically, the cloud service platform can determine whether a newly added node is a built-in NIC type when adding a node in the node pool. If it is, the built-in NIC type label is added to the node for storage, ready for subsequent container group creation and information acquisition, to ensure the accuracy of node type determination. Specifically, the network security access device for large model tasks can query whether the target node includes a built-in NIC type label when determining the node type of each target node through the container network interface. If the built-in NIC type label is obtained, it is determined that the node type of the target node is a built-in NIC type; otherwise, it is determined that the node type of the target node is an external NIC type. By adding the type label when adding the node, it can be quickly and accurately determined whether the node is a built-in NIC type or an external NIC type.

[0067] In some embodiments, establishing a mapping relationship between the NIC address of the target container group and the target task label based on the node type can include: if the node type is a built-in NIC type, obtaining container group configuration information of the target container group through an information acquisition plug-in in the container network interface of the target node, and extracting at least one built-in NIC address corresponding to the target container group in the container group configuration information to establish a mapping relationship between the at least one built-in NIC address and the target task label; if the node type is an external NIC type, obtaining at least one external NIC address corresponding to the target container group through a network plug-in in the container network interface of the target node, and establishing a mapping relationship between the at least one external NIC address and the target task label.

[0068] The information acquisition plug-in can be a plug-in configured in the container network interface of the built-in network card type node for acquiring container group related information. Specifically, container group configuration information can be acquired when the container group is created, the built-in network card addresses corresponding to the container group are extracted from the container group configuration information, and the mapping information between the built-in network card addresses corresponding to the container group and the tasks corresponding to the container group, i.e., the mapping relationship between the built-in network card addresses corresponding to the container group and the task labels, is established. The container group configuration information can include containers included in the container group, images used, environmental changes, storage configurations, network settings, etc. The network settings include the network card addresses of the container group. The container group configuration information in the built-in network card type node includes the above built-in network card addresses. For example, one target container group configuration information can include a container group name, a service identifier, and eight built-in network card addresses corresponding to the container group.

[0069] The network plug-in can be a plug-in for acquiring the external network card addresses of the external network cards and synchronizing between nodes. The network plug-in is configured in the container network interface of any node, i.e., the network plug-in is included in the container network interface of the built-in network card type node and the external network card type node. The built-in network card address can be the address of the built-in network card arranged inside the graphics processor, and the external network card address can be the address of the external network card not inside the graphics processor. The external network card address can serve as the network card address of the service container group and the network card address of other container groups.

[0070] Specifically, when the network security access device for large model tasks establishes the mapping relationship between the network card addresses of each target container group and the target task labels based on the node type through the container network interface for each target node, when the node type is a built-in network card type, the information acquisition plug-in of the container network interface can listen to the creation of the target container group, acquire the corresponding container group configuration information when the target container group is created, extract at least one built-in network card address corresponding to the target container group in the container group configuration information, the specific number is not limited, for example, there can be eight built-in network card addresses, and the mapping relationship between each built-in network card address in the at least one built-in network card address of the target container group and the target task label is established; when the node type is an external network card type, the network plug-in of the container network interface can directly acquire at least one external network card address corresponding to the target container group when the target container group is created, and establish the mapping relationship between each external network card address in the at least one external network card address of the target container group and the target task label. After each target node establishes the mapping relationship between the network card addresses of the target container group and the target task label, it is stored in the routing relationship database, and the routing relationship database is synchronized to each node; after each target node establishes the mapping relationship between the network card addresses of the target container group and the target task label, it can be synchronized to other nodes, so that each node includes the mapping relationship between the network card addresses of all target container groups and the target task labels and constructs the routing relationship database.

[0071] After the above routing relationship library is constructed, the network access request sent by the container group on the built-in network card type node can be received by the container group on the external network card type node of the same task; the container group on the built-in network card type node can receive all network requests sent by the container group, especially the network request sent by the container group on the external network card type node of the same task; the network access request sent by the container group on the external network card type node can be sent to the container group of the same task on the built-in network card type node through the routing relationship library, because the routing relationship library includes the mapping relationship of the network card addresses of the container group on the built-in network card type node and the container group on the external network card node of the same task; the container group on the external network card type node can refuse the network access request sent by the container group on the built-in network card type node of the different task, because the routing relationship library is different for different tasks and does not allow access.

[0072] The network security access method for large model tasks of the embodiments of the present disclosure can further include deleting the routing relationship library in the container network interface of all target nodes when the above target task is destroyed. In addition, the built-in network card address of the container group on the built-in network card type node can be detected on the router, and the network access of the container group is analyzed based on the detection result.

[0073] In the above scheme, the mapping relationship of the network card address of the container group and the target task label can be established according to the node type of the container group created for the task, and the mapping relationship is stored in the routing relationship library. The network card address can include a built-in network card address and an external network card address, which is helpful for subsequent rapid implementation of network isolation control under heterogeneous models. In the network isolation mode of the present case, the container group in the built-in network card type node can be externally accessed, and although it can randomly receive data through the built-in network card and attempt to establish a connection to send data to the container group of the built-in network card type node of other tasks, the service container group cannot be sent to any other task of the external network card type node of the container group, and when sending, it is equivalent to solving multiple parties to meet the successful conditions, which is difficult to achieve, thereby effectively enhancing the security of network access.

[0074] In some embodiments, the network security access method for large model tasks can further include: storing the routing relationship library into the built-in network card through the dynamic routing interface of the graphics processing unit by using the network configuration plug-in in the container network interface of the built-in network card type node, so as to control the network access of the container group through the built-in network card in the built-in network card type node according to the routing relationship library.

[0075] The network configuration plug-in can be a plug-in that calls a dynamic routing interface of the graphics processor and stores a routing relationship library to a built-in network card through a control plane command, so that network access of the built-in network card is dynamically controlled through the routing relationship library. The dynamic routing interface can be an interface opened by the graphics processor to enable external access to the built-in network card. After the provider of the graphics processor sets the dynamic routing interface, network access control of the built-in network card can be achieved. Through the network configuration plug-in set in the built-in network card model node and the dynamic routing interface of the graphics processor, network access control of the built-in network card can be achieved, the same network access control strategy as the external network card model node is achieved, and the container groups of different tasks can communicate based on the routing relationship library under the heterogeneous model, so that a certain degree of task-level isolation of the container groups of different tasks can be achieved.

[0076] Next, the architecture of the control plane in the network security access method for large model tasks in the embodiments of the present disclosure is further described through a specific example. The application program of the network security access method for large model tasks can provide corresponding services based on the control plane. For example, Figure 6 The architecture of the control plane provided by some embodiments of the present disclosure is shown in the following figure, Figure 6 The hardware in the figure includes a central processing unit, a network interface card (NIC), and an accelerator (Accelerated Devices). The network interface card can include a data processing unit (DPU). The accelerator can include one of a graphics processing unit, a tensor processing unit (TPU), a field programmable gate array (FPGA), and an application specific integrated circuit (ASIC). Figure 6 The storage service in the figure can be a cloud storage service implemented based on a cloud server. The specific hardware device for implementing the storage service is not limited in the embodiment. The storage service can include one or more databases. As shown in the figure, Figure 6 In the embodiment, the model of the control plane can be a model as a service that undertakes large models of various model providers, and then uses the large models to provide inference services, fine-tuning services, and other services. Essentially, the model as a service is a platform as a service (PaaS).

[0077] In a data plane relying on Infrastructure as a Service (IaaS), the data plane can have a corresponding software stack that can be deployed as a service container group on a governed cloud server (ECS) node, and in response to a user's scheduling, the corresponding scheduling can be performed according to a scheduler. Figure 6 There are multiple user container groups (User Pods) and service container groups (Service Pods) in the middle cloud server virtual machine (ECS VM).

[0078] Generally, the related tasks of model as a service can be divided into inference tasks and training tasks (for example, dynamic fine-tuning tasks), etc. And there are three roles in the task, cloud service providers, model providers and users.

[0079] Specifically, the cloud service provider provides cloud services (for example, infrastructure as a service or platform as a service) to serve different model providers. The model provider owns a large model and uses the cloud service provider to build its own inference task service entity. The user runs the application provided by the cloud service provider and the model provider. The user has corresponding isolation requirements for the model provider and the cloud service provider. Specifically, when the user obtains model as a service from the cloud service provider, the user hopes that the container group of the model related task is isolated in the network, computing and storage dimensions to ensure security.

[0080] Figure 7 The structure diagram of the network security access device for large model tasks provided by the embodiment of the present disclosure. The device can be implemented by software and / or hardware, and can be integrated in an electronic device. As shown in Figure 7 The device includes:

[0081] The receiving module 701 is configured to receive a target access request sent by a first container group, wherein the target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in an internal network card type node and an external network card type node.

[0082] The sending module 702 is configured to send the target access request to the second container group if it is determined, based on a routing relationship library, the first network card address and the second network card address, through the first container network interface in the external network card type node, that the first container group and the second container group belong to the same task, wherein the routing relationship library includes mapping information between network card addresses of the container groups in the external network card type node, the internal network card type node and the same task.

[0083] Optionally, the sending module 702 is configured to:

[0084] match the first network card address and the second network card address in the routing relationship library through the first container network interface, to determine a first task label corresponding to the first network card address and a second task label corresponding to the second network card address.

[0085] If the first task label and the second task label are the same, it is determined that the first container group and the second container group belong to the same task.

[0086] Optionally, the routing relationship library includes a plurality of network card addresses and a plurality of task labels having a mapping relationship, the plurality of network card addresses include at least one internal network card address and at least one external network card address, and the routing relationship library is synchronized to the container network interfaces of the nodes.

[0087] Optionally, the apparatus further includes a relationship module, comprising:

[0088] The first unit is configured to, in response to a container creation request of a target task, create a target container group in at least one target node and assign a target task label to the target container group, wherein the number of the target container groups is one or more.

[0089] The second unit is configured to, for each target node, determine a node type according to a container network interface of the target node, establish a mapping relationship between a network card address of the target container group and the target task label based on the node type when the target container group is created, and store the mapping relationship in a routing relationship library.

[0090] Optionally, the second unit includes a first sub-unit, and the first sub-unit is configured to:

[0091] If an internal network card type label is acquired through the container network interface of the target node, it is determined that the node type of the target node is an internal network card type; otherwise, it is determined that the node type of the target node is an external network card type.

[0092] Optionally, the second unit includes a second sub-unit, and the first sub-unit is configured to:

[0093] If the node type is the built-in network card type, container group configuration information of the target container group is obtained through an information obtaining plug-in in a container network interface of the target node, and at least one built-in network card address corresponding to the target container group in the container group configuration information is extracted, and a mapping relationship between the at least one built-in network card address and the target task label is established.

[0094] If the node type is the external network card type, at least one external network card address corresponding to the target container group is obtained through a network plug-in in a container network interface of the target node, and a mapping relationship between the at least one external network card address and the target task label is established.

[0095] Optionally, the built-in network card type label is added when a built-in network card type node is added.

[0096] Optionally, the pre-filled subtasks and the decoding subtasks in the target task are separately run through built-in network card type nodes and external network card type nodes in the at least one target node.

[0097] Optionally, the apparatus further includes a configuration module configured to:

[0098] The network configuration plug-in in the container network interface in the built-in network card type node is used to store a routing relationship library into a built-in network card by using a dynamic routing interface of a graphics processing unit, so as to control network access of a container group in the built-in network card type node through the built-in network card according to the routing relationship library.

[0099] The network security access apparatus for a large model task provided by the embodiments of the present disclosure can execute the network security access method for a large model task provided by any of the embodiments of the present disclosure, and has the corresponding function modules and beneficial effects of the execution method.

[0100] The embodiments of the present disclosure further provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the network security access method for a large model task provided by any of the embodiments of the present disclosure.

[0101] Figure 8 A structural schematic diagram of an electronic device provided by the embodiments of the present disclosure is shown in FIG. 1. The following will be specifically described with reference to Figure 8The diagram illustrates a structural schematic suitable for implementing the electronic device 800 in the embodiments of this disclosure. The electronic device 800 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0102] like Figure 8 As shown, the electronic device 800 may include a processing unit 801 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from storage device 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device 800. The processing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0103] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 800 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0104] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication apparatus 809, or installed from the storage apparatus 808, or installed from the ROM 802. When the computer program is executed by the processing apparatus 801, the above-mentioned functions defined in the network security access method for large model oriented tasks of the embodiments of the present disclosure are executed.

[0105] It should be noted that the computer readable medium described above in the present disclosure can be a computer readable signal medium or a computer readable storage medium or any combination thereof. The computer readable storage medium may, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory, a read-only memory, an electrically erasable programmable read-only memory (EPROM), an optical fiber, a portable compact disk read-only memory (Compact Disc Read-Only Memory, CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus or device. In the present disclosure, the computer readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer readable program code. Such a propagated data signal can take many forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination thereof. The computer readable signal medium can also be any computer readable medium other than the computer readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium can be transmitted by any suitable medium, including but not limited to a wire, an optical fiber, a radio frequency (Radio Frequency, RF), or the like, or any suitable combination thereof.

[0106] In some embodiments, the client, server, or other computing machines can communicate using any known or later developed form of computer-readable data signals over any type of transmission medium when communicating data. Such computer-readable data signals can be of the type generally known to those skilled in the art, that can be generated and transmitted, for example, by a computer or other computing machine, in order to communicate some information over a communication network. Such data signals can take a variety of forms, all essentially being manifestations of one or more types of physical signals. For example, such computer-readable data signals can be (i) the bits, waves or pulses of various forms, including, for example, electrical, electromagnetic, optical or quantum signals, (ii) the various states of a physical entity, including, for example, a magnetic, electric, optical or quantum states, or (iii) any combination of the above. Such network communications can be carried out, for example, over communications media that can include wires, wireless links, wires meshes, optical fibers, "the Internet", "intranets", "extranets" and / or any combination thereof.

[0107] The computer-readable medium described above can be included in the electronic device described above; or can exist independently of the electronic device.

[0108] The computer-readable medium described above carries one or more programs that, when executed by the electronic device, cause the electronic device to: receive a target access request sent by a first container group, wherein the target access request includes a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in a built-in network card type node and an external network card type node; if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, send the target access request to the second container group, wherein the routing relationship library includes mapping information between the network card addresses of the container groups in the external network card type node and the built-in network card type node and the same task.

[0109] Computer program code for carrying out operations of the present disclosure can be written in any one or combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0110] The computer program product of the present disclosure can be a computer program product, which can be implemented as a tangible computer readable storage medium or media having computer readable program instructions thereon for use by or in connection with an instruction execution system. In this context, a tangible computer readable storage medium can be any hardware- based device that stores information. With this in mind, a computer readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a computer readable storage medium that is a tangible device. However, it should be understood by those skilled in the art that the present disclosure can be implemented in many different ways and that the computer program product can take many different forms.

[0111] The units described in the embodiments of the present disclosure can be implemented by software, or by hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself.

[0112] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, non-limitingly, example types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0113] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include a lined-inked electrical connection, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, a flash memory, an optical fiber, a portable compact disc read-only memory, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0114] It can be understood that, before using the technical solutions disclosed in the embodiments of the present disclosure, the type of information involved in the present disclosure, the use range, the use scenario, etc. should be informed to the user and the authorization of the user should be obtained through appropriate means according to relevant laws and regulations.

[0115] The above description is merely preferred embodiments of the present disclosure and a description of the principles of the technology used. Those skilled in the art should understand that the scope of the disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combinations of the above technical features, and also covers other technical solutions formed by any combination of the above technical features or equivalent features without departing from the above disclosed concept.

[0116] In addition, although each operation is described in a particular order, this should not be understood as requiring the operations to be performed in the specific order shown or in a sequential order. In certain circumstances, multitasking and parallel processing can be advantageous. Similarly, although several implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments can also be combined in a single embodiment. Conversely, various features described in the context of a single embodiment can also be separated and implemented in multiple embodiments.

[0117] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A network security access method for a large model task, characterized in that, The method comprises: receiving a target access request sent by a first container group, wherein the target access request comprises a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in an inbuilt network card type node and an external network card type node; if it is determined through a first container network interface in the external network card type node that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address, the target access request is sent to the second container group, and the mapping information between the network card addresses of the container groups in the inbuilt network card type node and the external network card type node and the same task in the routing relationship library is established, which comprises: in response to a container creation request of a target task, creating a target container group in at least one target node, and assigning a target task label to the target container group, wherein the number of the target container groups is one or more; for each target node, determining the node type according to the container network interface of the target node, wherein the node type comprises an external network card type and an inbuilt network card type, and establishing the mapping relationship between the network card addresses of the target container group and the target task label based on the node type when the target container group is created, and storing the mapping relationship in the routing relationship library.

2. The method of claim 1, wherein, The method for determining that the first container group and the second container group belong to the same task through the first container network interface in the external network card type node based on the routing relationship library, the first network card address and the second network card address comprises: matching the first network card address and the second network card address in the routing relationship library through the first container network interface, and determining a first task label corresponding to the first network card address and a second task label corresponding to the second network card address; if the first task label and the second task label are the same, it is determined that the first container group and the second container group belong to the same task.

3. The method of claim 1, wherein, The routing relationship library comprises a plurality of network card addresses and a plurality of task labels having a mapping relationship, the plurality of network card addresses comprise at least one inbuilt network card address and at least one external network card address, and the routing relationship library is synchronized to the container network interfaces of the nodes.

4. The method of claim 1, wherein, The method for determining the node type according to the container network interface of the target node comprises: if an inbuilt network card type label is acquired through the container network interface of the target node, it is determined that the node type of the target node is the inbuilt network card type; otherwise, it is determined that the node type of the target node is the external network card type.

5. The method of claim 1, wherein, The method for establishing the mapping relationship between the network card addresses of the target container group and the target task label based on the node type comprises: If the node type is the built-in network card type, container group configuration information of the target container group is obtained through an information obtaining plug-in in a container network interface of the target node, and at least one built-in network card address corresponding to the target container group in the container group configuration information is extracted, and a mapping relationship between the at least one built-in network card address and the target task label is established. If the node type is the external network card type, at least one external network card address corresponding to the target container group is obtained through a network plug-in in a container network interface of the target node, and a mapping relationship between the at least one external network card address and the target task label is established.

6. The method of claim 4, wherein, The built-in network card type label is added when a built-in network card type node is added.

7. The method of claim 1, wherein, The pre-filled subtask and the decoding subtask in the target task are separately run on built-in network card type nodes and external network card type nodes in the at least one target node.

8. The method of claim 1, wherein, The method further comprises: The network configuration plug-in in the container network interface in the built-in network card type node is used to store the routing relationship library into the built-in network card by using a dynamic routing interface of a graphics processing unit, so as to control network access of the container group by the built-in network card according to the routing relationship library in the built-in network card type node.

9. A network security access device for large-scale model tasks, characterized in that, Comprise: The receiving module is configured to receive a target access request sent by a first container group, wherein the target access request comprises a first network card address of the first container group and a second network card address of a second container group to be accessed, and the first container group and the second container group are respectively deployed in built-in network card type nodes and external network card type nodes. The sending module is configured to send the target access request to the second container group if it is determined that the first container group and the second container group belong to the same task based on a routing relationship library, the first network card address and the second network card address through a first container network interface in the external network card type node, wherein the routing relationship library comprises mapping information between network card addresses of container groups in the external network card type node and the built-in network card type node and the same task, and the step of establishing the mapping information comprises: creating a target container group in at least one target node and assigning a target task label to the target container group in response to a container creation request of a target task, wherein the number of the target container groups is one or more; determining a node type according to a container network interface of each target node, wherein the node type comprises an external network card type and a built-in network card type, and establishing a mapping relationship between a network card address of the target container group and the target task label based on the node type when the target container group is created, and storing the mapping relationship in the routing relationship library.

10. An electronic device, comprising: The electronic device comprises: a processor; a memory for storing executable instructions of the processor; the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the network security access method for large model tasks according to any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The storage medium stores a computer program for executing the network security access method for large model tasks in any of claims 1-8.

Images