Message processing method, computing power device and storage medium

Abstract

The application provides a message processing method, a computing power device and a storage medium. The method can be applied to a first computing power device, and the flow includes: the first computing power device sends a message carrying a computing power resource node identifier list to a second computing power device, wherein the computing power resource node identifier list includes a first node identifier of a first computing power resource node which needs to receive the message, and the computing power resource node identifier list is used for the second computing power device to send the message to the first computing power resource node according to the first node identifier. According to the application, the computing power resource node identifier list is carried in the message, so that the first computing power device can instruct the second computing power device to send the message to the target node, the situation of repeatedly sending the same message to multiple computing power resource nodes is avoided, the waste of network bandwidth is effectively reduced, and the network transmission efficiency is improved.

Description

Technical Field

[0001] The embodiments of this application relate to, but are not limited to, the field of computer technology, and particularly to a message processing method, computing device, and storage medium. Background Technology

[0002] Artificial Intelligence (AI) tasks place extremely high demands on network performance, requiring not only high bandwidth but also non-blocking, ultra-low latency, and ultra-low jitter. DeepSeek V3 / R1 introduced the Mixture of Experts (MoE) mode, which decomposes a single task space into multiple sub-tasks, with multiple expert networks processing specific sub-tasks and ultimately outputting the overall prediction result. This mode improves the processing efficiency of AI tasks compared to single-task processing modes by utilizing more computing resources such as Graphics Processing Units (GPUs). However, in complex AI task scenarios, when an expert node needs to collaborate with multiple other expert nodes, the complexity and redundancy of data transmission increase dramatically. This is because the operation in this mode requires extensive data interaction and synchronization between expert nodes. For example, when an expert node needs to leverage the capabilities of three other expert nodes to collaboratively process a task, that expert node needs to send the same data packets to each of the three expert nodes multiple times. Furthermore, due to the physical dispersion of expert nodes, many data synchronization operations need to be completed across cascaded devices. All these factors combined ultimately lead to a decrease in the efficiency of data interaction and synchronization. Summary of the Invention

[0003] This application provides a message processing method, computing device, and storage medium that can effectively reduce network bandwidth waste and improve network transmission efficiency.

[0004] On one hand, this application provides a message processing method applied to a first computing power device, comprising: sending a message carrying a list of computing power resource node identifiers to a second computing power device, wherein the list of computing power resource node identifiers includes a first node identifier of a first computing power resource node that needs to receive the message, and the list of computing power resource node identifiers is used by the second computing power device to send the message to the first computing power resource node according to the first node identifier.

[0005] On the other hand, this application also provides a message processing method applied to a second computing power device, comprising: receiving a message sent by a first computing power device carrying a list of computing power resource node identifiers, wherein the list of computing power resource node identifiers includes a first node identifier of a first computing power resource node that needs to receive the message; and sending the message to the first computing power resource node according to the first node identifier in the list of computing power resource node identifiers.

[0006] On the other hand, embodiments of this application also provide a computing device, including: at least one processor; at least one memory for storing at least one program; and implementing the message processing method as described above when at least one program is executed by at least one processor.

[0007] On the other hand, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for performing the message processing method described above.

[0008] On the other hand, embodiments of this application also provide a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium, a processor of a computing device reads the computer program or computer instructions from the computer-readable storage medium, and the processor executes the computer program or computer instructions, causing the computing device to perform the message processing method as described above.

[0009] In this embodiment, the first computing power device can send a message carrying a list of computing power resource node identifiers to the second computing power device. The list includes the first node identifier of the first computing power resource node that needs to receive the message. The list of computing power resource node identifiers aims to provide a basis for the second computing power device to send the message to the corresponding first computing power resource node according to the first node identifier. By embedding a list of computing power resource node identifiers containing the first node identifier into the message, this embodiment enables the second computing power device to send the message to the target first computing power resource node according to the first node identifier, avoiding the repeated sending of the same message to multiple computing power resource nodes, thereby effectively reducing network bandwidth waste and improving network transmission efficiency. Attached Figure Description

[0010] Figure 1 This is a typical 2-layer Clos / Fat Tree topology network diagram for AI tasks provided in an embodiment of this application;

[0011] Figure 2 This is a flowchart of a message processing method provided in an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of an expert list provided in one embodiment of this application;

[0013] Figure 4 This is a schematic diagram of the encapsulation format of the BIER message header provided in one embodiment of this application;

[0014] Figure 5 This is a schematic diagram of the expert list encapsulation format provided in one embodiment of this application;

[0015] Figure 6 This is a flowchart of a message processing method provided in another embodiment of this application;

[0016] Figure 7 This is a schematic diagram of the expert number content provided in one embodiment of this application;

[0017] Figure 7a This is a schematic diagram of the expert number content provided as a specific example in this application;

[0018] Figure 8 This is a schematic diagram of a computing resource node forwarding table entry provided in one embodiment of this application;

[0019] Figure 9 This is a schematic diagram of a computing resource node forwarding table entry provided in another embodiment of this application;

[0020] Figure 10 This is a schematic diagram of an expert list provided in another embodiment of this application;

[0021] Figure 11 This is a schematic diagram of a computing resource node forwarding table entry provided as a specific example in this application;

[0022] Figure 12 This is a schematic diagram illustrating an expert list representation method provided in one embodiment of this application;

[0023] Figure 12a This is a schematic diagram illustrating a specific example of how an expert list is represented in this application;

[0024] Figure 13 This is a typical 2-layer Clos / Fat Tree topology network diagram provided in another embodiment of this application;

[0025] Figure 14 This is a schematic diagram of an expert list provided in yet another embodiment of this application;

[0026] Figure 15 This is a schematic diagram of a forwarding table entry on a first computing device according to an embodiment of this application;

[0027] Figure 16 This is a schematic diagram of a forwarding entry based on an expert number provided in one embodiment of this application;

[0028] Figure 17 This is a structural diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical methods, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0030] It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described may be executed in a different order than that shown in the flowchart. In the description of the specification, claims, and the above-mentioned figures, "multiple" means two or more; "greater than," "less than," and "exceeding" are understood to exclude the stated number; "above," "below," and "within" are understood to include the stated number. The use of terms such as "first" and "second" is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly specifying the number of indicated technical features or their sequential relationship. Furthermore, in the description of the specification, claims, and the above-mentioned figures, the various values ​​mentioned (such as first value, second value, etc.) can be flexibly represented as single numeric codes or enumerated type values. These values ​​can clearly guide and control the execution flow and behavior patterns of various functional modules, ensuring the efficiency of decoding or encoding.

[0031] AI tasks place extremely high demands on network performance, requiring not only high bandwidth but also non-blocking, ultra-low latency, and ultra-low jitter. DeepSeek V3 / R1 introduced a hybrid expert MoE mode that decomposes a single task space into multiple subtasks, with multiple expert networks processing specific subtasks and ultimately outputting the overall prediction result. This mode significantly improves the processing efficiency of AI tasks compared to a single-task processing mode by utilizing more computing resources such as GPUs. However, this mode requires extensive data interaction and synchronization between expert networks during computation. Due to the physical dispersion of expert networks, many data synchronization operations need to be completed across cascaded devices, leading to a decrease in data interaction and synchronization efficiency.

[0032] See Figure 1 , Figure 1This application provides an embodiment of a typical two-layer Clos / Fat Tree topology network for AI tasks, consisting of a Spine layer and a Leaf layer. The Spine layer contains m devices (e.g., spine1-1 to spine1-m), serving as the network's core hub responsible for high-speed traffic forwarding. The Leaf layer contains x groups of devices, each group consisting of eight devices (e.g., Leaf1-1-1 to Leaf1-1-8, Leaf1-x-1 to Leaf1-x-8), directly connected to computing resources. Each Leaf device is connected to 64 Hosts (e.g., Leaf1-1-1 to Leaf1-1-8 correspond to Host1-1-1 to Host1-1-64), forming a "Leaf-Host" access layer, enabling Hosts to easily access the network and communicate with other nodes. During the execution of the AI ​​task, data traffic has diverse transmission paths within this network. Taking data transmission between Host1-1-1 and Host1-x-1 as an example, traffic can be forwarded via multiple Spine devices. The data originates from Host1-1-1, first reaching Leaf1-1-1 connected to it. Then, Leaf1-1-1 can forward the data to any Spine device (such as Spine1-1) according to the routing policy. Finally, Spine1-1 forwards the data to the target Leaf device (such as Leaf1-x-1), and finally delivers it to Host1-x-1.

[0033] The host stores resources used for AI task computation, such as GPUs, and a single host can accommodate multiple GPUs. A host can connect to different Leaf devices via multiple network interface cards (NICs). Assume a Leaf switch has 128 interfaces, with 64 used to connect to hosts and the other 64 to Spine devices. A single Leaf device can interconnect with 64 Spine devices through these 64 interfaces, thus building a large-scale network topology suitable for AI tasks.

[0034] In a single-task AI task, the task is completed by a single expert node. Since expert nodes are computing units running on GPUs, there is no need for cross-GPU data interaction. When handling larger task requirements, the expert nodes participating in the AI ​​task can also be limited to a single host, so data interaction does not need to cross cascaded devices, such as Leaf or Spine devices. However, in a hybrid expert MoE mode, a single task is broken down into many subtasks, handled by different expert nodes. When the number of expert nodes is very small, such as a maximum of 8 or 16, which can be accommodated within a single host, cross-cascaded device data interaction is also unnecessary.

[0035] However, the MoE mode introduced in DeepSeek V3 / R1 includes as many as 256 expert nodes (64 paths). Deploying so many expert nodes in a single host is extremely difficult, so they must be distributed across multiple hosts to complete the task. This necessitates data interaction across cascaded devices. Since the bandwidth and transmission speed of cascaded devices are typically much lower than those within a host, the large amount of data interaction and synchronization significantly reduces the execution efficiency of AI tasks. This data interaction and synchronization traffic pattern is a typical point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) transmission mode. Although AI tasks themselves involve data transmission in P2MP or MP2MP modes, the introduction of the Hybrid Expert (MoE) mode results in a larger volume and higher frequency of such data transmissions. For example, in the prefilling and decoding stages of large model inference, tokens and other data need to be sent to multiple expert nodes for computation. Currently, the industry generally uses a point-to-point method to transmit data to each expert node, which means that the same data needs to be transmitted repeatedly. Figure 1 For example, when the same data stream from Host1-1-1 needs to be transmitted to expert nodes on Host1-1-2, Host1-1-3, and Host1-1-4, Host1-1-1 needs to send the same data stream to Leaf1-1-1 multiple times so that Leaf1-1-1 can forward it to the target nodes respectively. This method reduces the execution efficiency of AI tasks.

[0036] In view of this, embodiments of this application provide a message processing method, a computing power device, a computer-readable storage medium, and a computer program product. This method can be applied to a first computing power device (such as a terminal device), and its specific operation flow is as follows: the first computing power device can send a message carrying a list of computing power resource node identifiers to a second computing power device. The list of computing power resource node identifiers includes the first node identifier of the first computing power resource node that needs to receive the message. The list of computing power resource node identifiers aims to provide a basis for the second computing power device to send messages to the corresponding first computing power resource node according to the first node identifier. Embodiments of this application, by embedding a list of computing power resource node identifiers containing the first node identifier into the message, enable the second computing power device to send messages to the target first computing power resource node according to the first node identifier, avoiding the repeated sending of the same message to multiple computing power resource nodes, thereby effectively reducing network bandwidth waste and improving network transmission efficiency.

[0037] Based on the above analysis, the embodiments of this application will be further described below with reference to the accompanying drawings.

[0038] See Figure 2 , Figure 2 This is a flowchart of a message processing method provided in one embodiment of this application. The method can be applied to a first computing device (such as a Host), and it can include at least step S210.

[0039] Step S210: Send a message carrying a list of computing resource node identifiers to the second computing power device, wherein the list of computing resource node identifiers includes the first node identifier of the first computing resource node that needs to receive the message, and the list of computing resource node identifiers is used by the second computing power device to send the message to the first computing resource node according to the first node identifier.

[0040] For example, a first computing power device sends a message to a second computing power device (e.g., Leaf), the message carrying a list of computing power resource node identifiers. The list contains the first node identifiers of the first computing power resource nodes that need to receive the message. The second computing power device can forward the message to the corresponding first computing power resource node based on these identifiers. Here, the first computing power device can be considered as a collection of devices consisting of multiple first computing power resource nodes, each node having a unique first node identifier; the second computing power device, as a network edge device, is primarily responsible for receiving messages from the first computing power device and accurately forwarding them to the corresponding first computing power resource nodes.

[0041] For example, the first computing resource node may include one of the following: GPU, Central Processing Unit (CPU), and AI task expert function entity (hereinafter referred to as expert node). It is understood that in AI tasks, GPUs are crucial computing resources, capable of large-scale parallel computing to accelerate model training and inference processes. Carrying a GPU identifier in the message allows devices like Leaf to accurately direct traffic to the corresponding GPU for computational processing. In AI tasks, the CPU is responsible for data processing, such as efficiently reading data from hard drive / memory and performing preprocessing operations like cleaning (e.g., denoising, filling missing values), format conversion (e.g., image decoding), and data augmentation (e.g., random cropping, rotation). These logically complex tasks, which rely on serial processing, all require the CPU's general-purpose computing and control capabilities. It is worth noting that in a pure supercomputer scenario, only the CPU is present, without a GPU; the CPU handles all computational tasks. In MoE mode, each expert node is responsible for processing a specific subtask; they are the key entities for completing AI tasks. By carrying an expert identifier in the message, data can be transmitted to the corresponding expert node for processing. It should be noted that in the MoE hybrid expert mode, the list of computing power resource node identifiers can be referred to as the expert list.

[0042] For example, the first node identifier encompasses both the node number and the node IP address. Specifically, when the first computing resource node is an expert node, its corresponding first node identifier is the node number; when the first computing resource node is a GPU, its corresponding first node identifier can be either the node number or the node IP address. A unique node number (such as a numerical identifier) ​​is assigned to the expert node, and a unique node number or node IP address is assigned to the GPU. When the Leaf device receives the list of computing resource node identifiers sent by the Host, it can forward packets to the corresponding computing resource node based on the node number of the expert node, the node number of the GPU, or the node IP address in the list.

[0043] For example, when the node identifier of the first computing resource node uses a node number, this node identifier can be carried in the computing resource node identifier list in the form of a bit string. A bit string is a string composed of a series of binary bits (0 or 1). In this representation, a fixed position (bit index) is pre-allocated for each expert node or GPU. When it is necessary to indicate in the message that data should be sent to certain expert nodes or GPUs, the bits corresponding to these expert nodes or GPUs are set to 1 in the corresponding bit string, and the remaining bits are set to 0. Suppose there is a bit string of length 8 used to represent 8 expert nodes or GPUs, numbered 1-8. If data is to be sent to expert nodes or GPUs numbered 2, 5, and 7, then the corresponding bit string is "01010010". Here, the 2nd, 5th, and 7th bits from right to left are set to 1, corresponding to expert nodes or GPUs numbered 2, 5, and 7 respectively. Using this bit string format, only 8 bits are used to represent the node information that needs to be sent in the message, saving space when processing a large number of nodes, and allowing for fast judgment and operation using bitwise operations.

[0044] For example, when the node identifier of the first computing resource node uses a node number, the node identifier can also be carried in the computing resource node identifier list in the form of a number. That is, the expert nodes or GPUs that need to receive the message can be directly presented in the list in the form of numbers. This representation method is intuitive and clear, directly listing the numbers of the expert nodes or GPUs that need to receive the data in the message, and each element in the list is the number of an expert node or GPU. For example, assuming there are 8 expert nodes or GPUs, if data needs to be sent to expert nodes or GPUs numbered 2, 5, and 7, then the computing resource node identifier list in the message would be "[2,5,7]".

[0045] For example, when the number of first computing resource nodes is too large, if the node identifier of the first computing resource node is carried in the computing resource node identifier list in the form of a bit string, the bit string length usually needs to be increased accordingly. However, this will lead to an increase in the space occupied by the computing resource node identifier list, resulting in additional overhead. To this end, a hierarchical identifier can be introduced into the computing resource node identifier list, which is used to further distinguish computing resource nodes of different levels or groups. The node number can be determined based on the bit string length supported by the computing resource node identifier list, the value of the hierarchical identifier, and the position of the first node identifier in the bit string (i.e., message setting), where the value of the hierarchical identifier represents the level of the expert node (i.e., the expert level), such as... Figure 3 As shown, the actual expert node number is determined by the formula "bit string length × expert layer + message set bits". The host sending the expert data packet can encapsulate the expert list according to this formula. When intermediate devices (such as Leaf devices and Spine devices) receive the data packet and forward it, they can calculate the actual expert number according to this formula and forward it according to the forwarding table entry. Assuming the expert IDs to be sent are 5, 68, 253, and 365, and the bit string length is 256 bits, it can be split into two data packets: In the first data packet, bits 5, 68, and 253 of the bit string are set to 1, and the expert layer is set to 0, corresponding to actual IDs 5, 68, and 253 (calculated as: 256×0+5=5, 256×0+68=68, 256×0+253=253); in the second data packet, bit 109 of the bit string is set to 1, and the expert layer is set to 1, corresponding to actual ID 365 (calculated as: 256×1+109=365). When processing the data, Leaf and Spine devices can call the corresponding layer forwarding table entry based on the expert layer value of the data packet. For example, when the expert layer is 0, the corresponding ID in the bit string is directly matched; when the expert layer is 1, the complete ID is calculated using a formula and then the table entry is matched. When the bit string length of a device forwarding table entry is limited, the table capacity can be expanded through layering (such as expert layer 0, expert layer 1, etc.) to adapt to scenarios with different numbers of expert nodes. In this way, by combining the bit string length and the node's position in the bit string, the layered identifier can further distinguish nodes of different levels and groups, thereby accurately determining the identifier of each node.

[0046] For example, the list of computing resource node identifiers can be placed in the following positions within a message: the BIER header at the very beginning of the message; the new Ethernet header at the very beginning of the message; after the Ethernet header; after the IP header; and the IPv6 extension header. Specifically, BIER (Bit Indexed Explicit Replication) is a technology used for network multicast and multipoint transmission. The BIER header, located at the beginning of the message, is specifically designed to support efficient multicast and multipoint data distribution. When the list of computing resource node identifiers is placed in the BIER header, network devices (such as routers and switches) can accurately copy and forward data to multiple target computing resource nodes based on the information in the list, utilizing the technical characteristics of BIER. For instance, in a large-scale data center network, multiple GPU nodes (as computing resource nodes) need to simultaneously receive the same data for parallel computation. By placing the identifiers of these GPU nodes in the computing resource node identifier list of the BIER header, fast and accurate data distribution can be achieved. The new Ethernet header is also located at the very beginning of the message. With the development of network technology, new Ethernet message structures are designed to meet new network demands and functions. Placing the list of computing resource node identifiers in the new Ethernet header is because this new header can more flexibly carry and process this identification information according to new network specifications and design requirements. For example, in scenarios with special requirements for network performance and functionality, the new Ethernet header can optimize the encoding or processing of computing resource node identifiers, enabling network devices to more efficiently identify and forward data to the corresponding nodes. The traditional Ethernet header is an important component of the Ethernet data frame, used to identify basic information such as the source and destination of the data. Placing the list of computing resource node identifiers after the Ethernet header preserves Ethernet compatibility without changing the basic structure and function of the Ethernet header. At the same time, it allows for the convenient addition of additional computing resource node identifier information without disrupting the original message format. For example, in a network environment that already widely uses Ethernet architecture, adding a list of computing resource node identifiers after the Ethernet header enables targeted data transmission to computing resource nodes without large-scale network modifications. The IP (Internet Protocol) header is a crucial part of data transmission in IP networks, containing important information such as the source IP address and destination IP address. Placing the list of computing resource node identifiers after the IP header is suitable for transmission scenarios based on IP networks.This approach leverages the routing capabilities of the IP layer. When forwarding data, network devices first select a route based on the destination IP address in the IP header, and then further determine which specific computing resource nodes to forward the data to based on the list of computing resource node identifiers. For example, in a wide area network spanning multiple subnets, this method can accurately transmit data from the source to multiple computing resource nodes distributed across different subnets. The IPv6 (Internet Protocol version 6) extension header can flexibly add various options and information according to different needs. Placing the list of computing resource node identifiers in the IPv6 extension header fully utilizes the flexibility and scalability of the IPv6 network. For example, the IPv6 Hop-by-Hop Options (HBH) header can process node identifiers at each hop of data transmission; the Destination Options (DOH) header can perform relevant operations when data arrives at the destination node; and the Routing Header (RH) header can perform more flexible routing selection based on node identifiers. By placing the list of computing resource node identifiers in the IPv6 extension header, a suitable extension header can be selected according to specific network applications and requirements to achieve more efficient network communication and data distribution to computing resource nodes. This embodiment does not impose any restrictions on this.

[0047] For example, when the computing resource node identifier list is set in the BIER header at the very beginning of the packet, the BIER header contains a node forwarding identifier (such as BIFT-ID). This node forwarding identifier can be used to indicate that the purpose of the computing resource node identifier list is to realize packet forwarding between different computing resource nodes. Specifically, the computing resource node identifier list can directly borrow the encapsulation form of the BIER header. A BIER header of Ethernet type 0xAB37 can be selected and encapsulated before the data packet. Its content can be directly referred to the definition in RFC8296, such as... Figure 4 As shown. The BIFT-id used for forwarding entry positioning can be set to a special value, such as 0xFFFFF, to indicate that the entry is used for expert node forwarding. Simultaneously, the corresponding expert node bit is set to 1 in the BitString.

[0048] It's worth noting that even if other fields in the BIER header are set to 0, they may still occupy some space. For example, if the BIER header is originally 32 bytes long, and 8 bytes of fields could be set to 0 in this scenario, they would still occupy those 8 bytes, leading to message redundancy. To reduce this unnecessary space consumption, a further optimization method can be used, namely... Figure 5The expert list encapsulation shown employs a new Ethernet message type to distinguish it from other Ethernet message types, directly carrying a bit string representing the expert list. Assume a new Ethernet type value, such as "0xABCD," is defined for this message used to carry the expert list. In traditional Ethernet messages, the Ethernet type field is used to identify upper-layer protocols, such as IPv4 ("0x0800"), IPv6 ("0x86DD"), etc. Now, when the second computing device receives a message with the Ethernet type "0xABCD," it knows that this is a message specifically used to carry the expert list. Assume there are 128 expert nodes in this AI training task, each with a unique ID. To indicate which expert nodes need to receive a particular message, a 128-bit bit string is used to represent the expert list. Each bit in the bit string corresponds to an expert node; a value of 1 indicates that the expert node needs to receive the message, and a value of 0 indicates that it does not. For example, if a message needs to be sent to expert nodes numbered 10, 25, 64, and 100, the corresponding bit string would be a 128-bit binary string, where bits 10, 25, 64, and 100 are 1, and the remaining bits are 0. In the new Ethernet message, this 128-bit bit string is directly carried as the data portion, instead of including a large number of potentially zero fields in the BIER header as before.

[0049] For example, the expert list encapsulation operation can be performed by the GPU, CPU, network interface card (NIC) connected to the GPU / CPU, or Leaf device. The following details the encapsulation tasks performed by each component: The GPU, with its powerful parallel computing capabilities, can, after processing data, integrate the expert node information to be received into an expert list format and complete the encapsulation if data needs to be passed to specific expert nodes for further processing. The CPU, as the core control unit of the computer system, bears the key responsibility of system task scheduling and instruction execution. In the expert list encapsulation stage, when the system receives a task request, the CPU can collect, organize, and sort the expert node information according to the specific requirements of the task, determine the expert list to be received, and complete the encapsulation operation. The NIC, as the interface between the computer and the network, is responsible for data transmission and reception. After the GPU or CPU completes data processing, it transmits the data to the NIC. The NIC can perform in-depth processing of the data according to the requirements of the network transmission protocol, including the encapsulation of the expert list. The NIC encapsulates the expert node information provided by the GPU or CPU according to the established network protocol format, ensuring accurate and efficient data transmission over the network. Leaf devices are located at the edge of the network architecture and are directly connected to computing resource nodes. When a Leaf device receives data from a computing resource node, it can accurately determine which expert nodes the data should be transmitted to based on factors such as network topology and routing strategies. It then encapsulates the expert list to optimize data processing at the network edge, thereby improving overall network performance and the accuracy of data transmission.

[0050] For example, the first computing power device can also notify the second computing power device of the second node identifiers of the second computing power resource nodes it owns. The second computing power device can generate computing power resource node forwarding table entries based on these second node identifiers, and the forwarding table entries can guide the forwarding of messages to the corresponding second computing power resource nodes, ensuring efficient and accurate network communication. For instance, when the second computing power device receives a message from the first computing power device carrying a list of computing power resource node identifiers, it can match the generated computing power resource node forwarding table entries with the list to quickly locate the target node for forwarding the message, i.e., the second computing power resource node, thereby completing the message delivery.

[0051] For example, the second node identifier can be advertised to the second computing device in one of the following ways: advertising based on an extended TLV (Type-Length-Value) of a routing protocol; or advertising based on an extended TLV of the LLDP protocol. When the second node identifier is advertised to the second computing device via an extended TLV based on a routing protocol, the selected routing protocols include BGP (Border Gateway Protocol), OSPF (Open Shortest Path First), IS-IS (Intermediate System to Intermediate System), RIFT (Routing in Fat Trees), and BABEL. For example, assuming a communication path (for running these routing protocols) has been established between the Host and Leaf devices, the second node identifier information can be carried using the TLV (Type-Length-Value) data structure by extending these protocols. For example, when running the BGP protocol, the second node identifier can be added in the form of a TLV by extending its protocol content, and then this extended BGP protocol is used to transmit information to the Leaf device. LLDP (Link Layer Discovery Protocol) is mainly used to discover neighboring devices at the link layer. Extending the LLDP protocol, a TLV structure can also be used to transmit the second node identifier. For example, a host can use the LLDP protocol to extend the TLV to inform the Leaf device of the expert ID within the host, using a similar principle to the first method to announce the second node identifier to the Leaf device.

[0052] It should be noted that when the first computing power device notifies the second computing power device of the second node identifier of the second computing power resource node it possesses, this can also be directly configured on the Leaf device. In other words, the network administrator can manually enter the second node identifier information of the second computing power resource node from the first computing power device into the Leaf device. This information can be used by the Leaf device to generate computing power resource node forwarding table entries, thereby guiding packets to be correctly forwarded to the corresponding second computing power resource node.

[0053] Reference Figure 6 , Figure 6 This is a flowchart of a message processing method provided in another embodiment of this application. The method is applied to a second computing device and may include, but is not limited to, steps S610 to S620.

[0054] Step S610: Receive a message sent by the first computing power device carrying a list of computing power resource node identifiers, wherein the list of computing power resource node identifiers includes the first node identifier of the first computing power resource node that needs to receive the message.

[0055] Step S620: Send the message to the first computing resource node according to the first node identifier in the computing resource node identifier list.

[0056] For example, the second computing power device may also receive a second node identifier of the second computing power resource node that the first computing power device has, as notified by the first computing power device; and generate a computing power resource node forwarding table entry based on the second node identifier, wherein the computing power resource node forwarding table entry is used to guide the forwarding of messages to the second computing power resource node.

[0057] For example, the second computing device (Leaf) can also announce the second node identifier of the second computing resource node to which the second computing device is connected to to the third computing device (such as Spine). The second node identifier is used by the third computing device to generate a forwarding table entry for the computing resource node, which guides packet forwarding to the second computing resource node. When a data packet needs to be transmitted in the network, and the target is a second computing resource node, Spine can determine the correct forwarding path based on the information recorded in this forwarding table entry, accurately sending the packet to the corresponding second computing resource node. For example, in a data center network, Leaf connects to multiple GPU servers as second computing resource nodes, each GPU server having a unique IP address (which can serve as the second node identifier). Leaf announces these GPU server IP addresses to Spine, and Spine generates forwarding table entries based on these IP addresses. When a data packet generated by a computing task needs to be sent to one of the GPU servers, Spine will find the corresponding path based on the forwarding table entry and forward the packet to that GPU server, thereby completing the data transmission and processing task.

[0058] It should be noted that when the bit string length of the forwarding table entries of computing power resource nodes on Leaf and Spine devices is limited, forwarding table entries of different levels, such as expert layer 0 and expert layer 1, can also be constructed to adapt to different scenario requirements.

[0059] For example, the second node identifier can be advertised to the third computing device in one of the following ways: by advertising based on the extended TLV of the routing protocol; or by advertising based on the extended TLV of the LLDP protocol. For details, please refer to the method described above for the first node identifier to be advertised to the second computing device, which will not be repeated here.

[0060] For example, when the second node identifier is advertised to the third computing device via an extended TLV based on a routing protocol, the routing protocol includes one of the following: BGP, OSPF, IS-IS, RIFT, or BABEL. For details, please refer to the previous process of the first node identifier being advertised to the second computing device via an extended TLV based on a routing protocol; it will not be repeated here.

[0061] For example, in a scenario where a first computing power device (Host) and a second computing power device (Leaf device) interact based on the MoE mode, a unique numerical number can be assigned to each expert node. For example, expert node 1 corresponds to numerical number 1, expert node 2 corresponds to numerical number 2, and so on, until expert node 100 corresponds to numerical number 100, expert node 256 corresponds to numerical number 256, and so on. It should be noted that one or more expert nodes can be deployed in a Host, and the number is not limited. The specific number is determined according to the actual deployment requirements. Furthermore, this embodiment supports dynamic expansion of the number of expert nodes. Even if it is subsequently expanded to 512 or 1024 expert nodes, the method provided in this embodiment will still be applicable. The Host announces the internal expert node numbers to the Leaf device as follows: First, the Host can announce the node identifiers of its own computing power resource nodes (such as GPUs and expert nodes) to the Leaf device. This node identifier is used by the Leaf device to generate computing power resource node forwarding table entries, thereby guiding the accurate forwarding of messages to the corresponding computing power resource nodes. When a host contains resources such as multiple GPUs, it can connect to multiple Leaf devices through multiple interfaces. In this case, the announcement of expert node numbers can typically be based on the interface level. The announcement content is as follows: Figure 7 As shown. Assuming that there are expert nodes 1, 2, and 5 on a certain GPU of Host1-1-1, then it can be done through a similar... Figure 7a The connection status is communicated to the connected Leaf devices in a specific manner. Typically, after learning about the connection status between its interface and the expert node, the Leaf device can generate corresponding forwarding table entries (i.e., computing resource node forwarding table entries), such as... Figure 8 As shown, on a Leaf device (such as Leaf1-1-1), interface Intf1-1 is connected to expert node 1 (Host1-1-1-E1), interface Intf1-2 is connected to expert node 2 (Host1-1-1-E2), and interface Intf1-4 is connected to expert node 3 (Host1-1-1-E3), etc. When an interface of a Leaf device is connected to multiple expert nodes, the forwarding table entries on the Leaf device can be presented as follows: Figure 9 As shown, the Leaf's interface Intf1-1 is connected to expert nodes 1 and 2, and the interface Intf1-3 is connected to expert nodes 3, 4, and 5.

[0062] Understandably, when initiating an AI task, based on the gating system's decision, data packets can be sent to multiple expert nodes. During task execution, these expert nodes interact extensively with each other using KV (Key-Value) caches and other data, similar to P2MP and MP2MP, meaning multiple expert nodes need to receive the same data. However, in the existing model, data delivery to multiple expert nodes can only be achieved through multiple point-to-point packet transmissions. This results in a large amount of repetitive data consuming significant bandwidth within and between hosts, leading to extremely low efficiency. This embodiment addresses this by including the numbers of the multiple expert nodes that need to receive the data traffic in an expert list format, such as... Figure 10 As shown. The expert list can be carried anywhere in the data traffic packet, such as at the very beginning of the data traffic packet, identified by the new Ethernet type, or after the Ethernet or IP header of the data traffic packet itself, or directly in the IPv6 extension header of the data traffic packet. This embodiment does not limit this. Even when the data traffic transmission uses a non-Ethernet type, the expert list can still be carried.

[0063] For example, in the expert list, the number of each expert node can be represented by 1 bit. This method can be used not only in data packets but also in the forwarding table, significantly reducing the space required. Figure 9 Taking the forwarding table entry as an example, its forwarding table entry is as follows: Figure 11 As shown, expert nodes corresponding to the same outgoing interface can be merged into one entry. One entry can hold 256 expert numbers, with each bit identifying an expert node. For example, in the first row, the lowest two bits are set to 1, indicating that expert nodes numbered 1 and 2 (i.e., Host1-1-1-E1 and Host1-1-1-E2) both correspond to outgoing interface Intf1-1; other bits in the entry are omitted as 0. In the second row, bits 3, 4, and 5 from the rightmost bit are set to 1, indicating that expert nodes numbered 3, 4, and 5 (i.e., Host1-1-1-E3, Host1-1-1-E4, and Host1-1-1-E5) correspond to outgoing interface Intf1-3. This process continues, avoiding the complexity of entry lookup. When sending data packets and carrying the expert list, the bitwise representation of the expert number can also be used to indicate the expert number to be reached, such as... Figure 12 As shown in the previous example, assuming a data packet needs to be sent to expert nodes 1, 4, and 5, its expert list is as follows. Figure 12aAs shown, from right to left, bits 1, 4, and 5 are set to 1. After receiving the data packet, the Leaf device compares and searches the expert list in the data packet with the expert list in its own expert forwarding table. Then, it sends the packet from Intf1-1 to Host1-1-1 and from Intf1-3 to Host1-1-3, thus completing the forwarding of the data packet to multiple expert nodes. In this way, the same data only needs to be sent once to be received by all expert nodes, and the traffic forwarding is as follows: Figure 13 As shown.

[0064] It is worth noting that when the number of expert nodes is less than 256 bits, such as when there are only 128 or 64 expert nodes, the length of the bit string in the expert forwarding table and the expert list can be reduced accordingly to reduce overhead.

[0065] For example, when there are many expert nodes or they are scattered, the Spine device may also need to participate in the replication and forwarding of expert node data traffic. In this case, the Leaf device can use routing protocol extensions to advertise the IDs of the expert nodes it connects to to the Spine device. Similarly, the Spine device can also advertise the IDs of expert nodes learned from other Leaf devices to the Leaf devices. The announcement content is similar. Figure 7It supports TLV extensions based on BGP, OSPF, IS-IS, RIFT, LLDP, or BABEL protocols. The specific formats are as follows: BGP protocol scenario: Add a new SubTLV representing expert node number advertisement to the BIER Path attribute of the GPU prefix route advertisement. If non-MPLS encapsulation (such as Ethernet / IPv4 / IPv6 protocols) is used, the expert node number is carried in the BIER NonMPLS encapsulated Sub-TLV, where the BIFT-id value is set to a special value (e.g., 0xFFFFF); if MPLS encapsulation is used, the expert node number is carried in the BIER-MPLS encapsulated Sub-TLV, where the Label field is set to a special value (e.g., 0xFFFFF). IS-IS protocol scenario: Add a SubSubTLV representing expert node number advertisement under the BIER InfoSub-TLV. OSPF protocol scenario: Add a SubTLV representing expert node number advertisement under the BIER Sub-TLV. RIFT and BABEL protocol scenarios: Referring to the BGP extension logic, differentiate between Non-MPLS and MPLS encapsulation methods, setting BIFT-id or Label to special values ​​(such as 0xFFFFF) respectively. LLDP protocol scenario: The LLDP-based advertising process between Leaf and Spine devices is consistent with the advertising logic between Host and Leaf devices. After learning the expert node number, the Spine device can generate forwarding table entries based on the expert node number, similar to those of the Leaf device. The Leaf device, in turn, generates forwarding table entries for other experts reachable through the Spine device. By setting the BIFT-id, Label, or forwarding table index in the advertising content to special values ​​such as 0xFFFFF, expert node data traffic can be effectively distinguished from other BIER multicast packets in the network, avoiding processing conflicts. Assume... Figure 1 The Spine, Leaf, and Host devices in the network form a Point of Delivery (PoD). When the network scales up and multiple PoDs are interconnected by Core layer devices, the Spine and Core layer devices can also use a similar method to announce the expert node number, thereby enabling cross-PoD expert node data transmission.

[0066] It should be noted that if the Host and Leaf devices use a routing protocol to announce expert node numbers, a similar method to that used for Leaf and Spine devices can be adopted, which will not be elaborated here.

[0067] For example, when the bit string length is short and the expert nodes are sparsely distributed, continuing to use bit string-based encapsulation might revert to sending point-to-point data packets to each expert node. For instance, when sending to expert nodes 5, 68, 253, and 365, and the bit string length is 64, the host responsible for sending the expert node data packets needs to encapsulate four data packets: the first data packet has its 5th bit set to 1, and the expert layer is 0; the second data packet has its 4th bit set to 1, and the expert layer is 1; the third data packet has its 61st bit set to 1, and the expert layer is 3; the fourth data packet has its 45th bit set to 1, and the expert layer is 5. This approach is essentially no different from point-to-point transmission to four expert nodes, and it does not improve transmission efficiency. Therefore, in this case, the encapsulation of the expert list can adopt a similar approach... Figure 14 The method shown involves directly encapsulating the numbers of multiple expert nodes sequentially in an expert list. When an intermediate device (such as Leaf) receives the data, it can look up the forwarding table entry (such as...) based on the expert number. Figure 8 or Figure 9 Forward the corresponding entries shown in the diagram. To ensure that forwarding devices such as Leaf can correctly identify and process the changes, the changes in the expert list encapsulation method can also be reflected by adding new Ethernet types, new IPv4 / IPv6 protocols, or new types in IPv6 HBH, DOH, RH, and other extension headers, so that forwarding devices such as Leaf can correctly identify and process them.

[0068] For example, the host device can be optimized to enable each interface or some interfaces to receive data from all expert nodes within the host, and then the host can complete the internal data distribution. Figure 1 For example, each Host is configured with multiple interfaces to receive data sent to all GPUs within the Host, and then the Host distributes the data to the specific GPUs. Taking Host1-1-1 as an example, since its multiple interfaces can all receive data, the Host needs to maintain a searchable forwarding table. Unlike Leaf and Spine devices, the forwarding table on the Host only needs to contain two types of entries: internal expert entries and external expert entries. The internal expert entries point to the expert mapping relationship of the GPUs within the Host (e.g., expert nodes 1 and 2 are deployed on GPU1, and expert node 5 is deployed on GPU3), while the external expert entries (i.e., the computing resource node identifier list mentioned earlier) point to the Leaf device and are used to forward expert node data to other Hosts. The Leaf device can learn all the expert node information of the Host through the Host interface. Figure 15As shown, assuming the GPU on Host1-1-1 hosts multiple expert roles, including expert nodes 1, 2, and 5, the forwarding table entries on the host include entries for the GPU expert nodes within the host. For example, expert nodes 1 and 2 are deployed on GPU1 (the bit index value of expert node 1 is "00000001", and the bit index value of expert node 2 is "00000010"), and data traffic destined for expert nodes 1 and 2 needs to be sent to GPU1; expert node 5 is deployed on GPU3 (the bit index value of expert node 2 is "00010010"), and data traffic destined for expert node 5 needs to be sent to GPU3, and so on. For other expert nodes not within the host, all traffic is forwarded to Leaf devices (such as Leaf-1-1-1, Leaf-1-1-2, Leaf-1-1-3, etc.) and then forwarded by the Leaf devices. Suppose that GPU1 on Host1-1-1 initiates a task requiring the participation of multiple expert nodes, namely expert nodes 2, 5, 20, 22, and 50. Expert nodes 2 and 5 are located within the same host and can be processed directly by the GPU itself; therefore, expert nodes 2 and 5 can be encapsulated in the expert node list or not. Expert nodes 20, 22, and 50 are located on other hosts and therefore need to be encapsulated in the expert list. Assume expert nodes 20 and 22 are located on Host1-1-3, and expert node 50 is located on Host1-1-7. After receiving a packet carrying expert nodes 20, 22, and 50, the Leaf device can forward the traffic to Host1-1-3 and Host1-1-7 according to the forwarding table entries. Upon receiving the packet, Host1-1-3 and Host1-1-7 can look up the internal forwarding table entries according to the expert list and distribute the data to the corresponding GPU (e.g., expert nodes 20 and 22 → target GPU of Host1-1-3) through the host's internal network. In this system, multiple interfaces connecting a Host to a Leaf device can publish the Host's expert node information. Therefore, traffic sent to other Hosts can select different Leaf interfaces to achieve load balancing. Similarly, the expert routing table entries of Leaf and Spine devices support multiple next hops, which can further optimize traffic distribution.

[0069] For example, in some implementation scenarios, large-scale models may be difficult to modify at the software level, making it impossible to assign expert node numbers. In such cases, the connection and conversion can be achieved through a network interface card (NIC) connecting the GPU resources or a CPU within the host. For instance, when the GPU is connected to other GPUs and Leaf devices in the host via a NIC, the NIC can pre-establish a mapping relationship between expert node identifiers and expert node numbers (the expert node identifier can be an expert node IP address or other format defined by the large-scale model software). When the GPU sends a data packet for multi-expert node computation to the NIC, the NIC can parse the expert node identifier in the packet, obtain the corresponding expert node number by referring to the pre-generated mapping table, and then encapsulate the data packet containing the expert list. In this way, both the host and Leaf devices can send data packets to multiple expert nodes via multicast based on the method of this embodiment, thereby improving the execution efficiency of AI tasks.

[0070] For example, in some MoE models, the demand for expert nodes differs between stages such as Prefilling and Decoding, necessitating different methods to distinguish expert nodes at each stage. Two common methods are: first, assigning uniform numbers to expert nodes across multiple stages, for example, numbering expert nodes in the Prefilling stage from 1 to 256, and expert nodes in the Decoding stage from 257 to 384; second, assigning non-uniform numbers to expert nodes on the GPU at different stages, for example, numbering expert nodes in the Prefilling stage from 1 to 256, and expert nodes in the Decoding stage from 1 to 128. To accurately identify the task stage to which an expert node belongs, the computing resource node identifier list in this embodiment can also introduce a first-stage identifier, which indicates the task stage corresponding to the first node identifier. When announcing the expert node numbers, different type values ​​can be used to distinguish expert nodes at different stages. For example, if there are two phases, two different type values ​​can be used to advertise the expert node numbers for the corresponding phases. When advertising using routing protocol extensions such as BGP, the distinction can be made by setting the characteristic values ​​(such as 0xFFFFF, 0xFFFFE) of BIFT-id / Label in Non-MPLS encapsulation or MPLS encapsulation of Sub-TLV / Sub-Sub-TLV. Specifically, 0xFFFFF can be set to represent the Prefilling phase, and 0xFFFFE to represent the Decoding phase, and forwarding table entries based on expert node numbers can be generated accordingly. It is worth noting that when encapsulating the expert list in the data packet, the encapsulation format of the expert number remains unchanged, but it still needs to be identified by different type values ​​to indicate the phase. If the already defined BIER encapsulation is used, the expert node number can be... Figure 4The first 20 digits of the BIFT-id / Label field are set to the corresponding stage value (i.e., the value set during the notification stage). For example, if data is sent during the Prefilling stage, and the BIFT-id / Label value is 0xFFFFF during expert number notification, then the first 20 digits of the field value should be set to 0xFFFFF; if data is sent during the Decoding stage, and the BIFT-id / Label value during that stage notification is 0xFFFFE, then the corresponding field should be set to 0xFFFFE so that after receiving the data, the Leaf and Spine devices can retrieve the correct expert number forwarding table based on this value and perform the forwarding operation. Stage differentiation can also be achieved using other encapsulation methods. For example, when using new types of Ethernet packets, identification can be achieved by adding subtype values ​​or using different Ethernet types, such as... Figure 16 As shown. If a new type of IPv4 / IPv6 protocol type encapsulation is used, it can be distinguished by adding subtypes or using different protocol type values. For IPv6-based HBH, DOH, or RH extension header encapsulation, different option values ​​or type values ​​can be used to distinguish stages. It should be noted that the expert list can be represented as a bit string or by directly listing expert numbers. Regardless of the form used, as long as network devices can uniformly identify and process it, the expert forwarding table entries can be accurately queried, and data can be correctly forwarded to the target expert node.

[0071] For example, in large-scale model computations, a large amount of data is transmitted in P2MP or MP2MP format, and the method of this embodiment also applies to the transmission of this data. Even if this data does not originate from the interaction between the MoE hybrid expert mode and expert nodes, but is transmitted between GPUs, efficient distribution can still be achieved through the method of this embodiment. Specifically, GPUs can be numbered in the same way as expert node numbers: a unique number is assigned to each GPU, and the GPU number is advertised to the Leaf device through the LLDP protocol or extensions of routing protocols such as BGP, OSPF, IS-IS, RIFT, and BABEL. To avoid confusion with expert node numbers, different types of values ​​can be used when advertising, such as setting a special BIFT-id / Label value. After receiving the GPU number, the Leaf device generates a forwarding table entry based on the GPU number, the format of which is similar to that of the expert node number entry (e.g., ...). Figure 8 , Figure 9 or Figure 11As shown), only the expert node number in the table entry is replaced with the GPU number. When encapsulating data, the encapsulation logic for expert node numbers can be used, encapsulating multiple target GPU numbers as bit strings or directly as numbers. Forwarding encapsulation can still use existing BIER encapsulation, adding Ethernet types, and other methods. Furthermore, when announcing GPU numbers between devices such as Leaf and Spine, different type and feature values ​​can be set to distinguish them, ensuring that each device accurately generates forwarding table entries based on the GPU number. Another implementation method is to directly use the GPU's IP address as its identifier. In this mode, differentiated type and feature values ​​can be used to distinguish the GPU IP address announcement information from expert node numbers and other content. When a device generates a forwarding table entry, Figure 8 or Figure 9 The expert node number will be replaced with the GPU's IP address. During data encapsulation, the IP addresses of multiple target GPUs can be processed in a similar encapsulation method to the expert node number. Forwarding encapsulation also supports multiple schemes such as adding Ethernet type, new IPv4 / IPv6 protocol or IPv6 extension header options, which will not be elaborated here.

[0072] For example, in a supercomputer scenario, the method of this embodiment is also applicable to data transmitted in P2MP or MP2MP format. Even if this data does not originate from the interaction between the MoE hybrid expert mode and expert nodes, and is not transmitted between GPUs but between CPUs, efficient distribution can still be achieved through the method of this embodiment. Specifically, CPUs can be numbered in the same way as expert node numbers: a unique number is assigned to each CPU, and the CPU number is advertised to the Leaf device through the LLDP protocol or extensions of routing protocols such as BGP, OSPF, IS-IS, RIFT, and BABEL. Different types of values ​​can be used for the advertisement, such as setting a special BIFT-id / Label value. After receiving the CPU number, the Leaf device generates a forwarding table entry based on the CPU number, the format of which is similar to that of the expert node number entry (e.g., ...). Figure 8 , Figure 9 or Figure 11As shown), only the expert node number in the table entry is replaced with the CPU number. When encapsulating data, the encapsulation logic for expert node numbers can be used, encapsulating multiple target CPU numbers as bit strings or directly as numbers. Forwarding encapsulation can still use existing BIER encapsulation, adding Ethernet types, and other methods. Furthermore, when announcing CPU numbers between devices such as Leaf and Spine, different type and feature values ​​can be set to distinguish them, ensuring that each device accurately generates forwarding table entries based on the CPU number. Another implementation method is to directly use the CPU's IP address as its identifier. In this mode, differentiated type and feature values ​​can be used to distinguish the CPU IP address announcement information from expert node numbers and other content. When a device generates forwarding table entries, Figure 8 or Figure 9 The expert node number will be replaced with the CPU's IP address. During data encapsulation, the IP addresses of multiple target CPUs can be directly encapsulated in a similar manner to the expert node number. Forwarding encapsulation also supports multiple schemes such as adding Ethernet types, new IPv4 / IPv6 protocols, or adding options to the IPv6 extension header, which will not be elaborated here.

[0073] Reference Figure 17 An embodiment of this application also discloses a computing device 1700, which includes: at least one processor 1710; at least one memory 1720 for storing at least one program; when the at least one program is executed by the at least one processor 1710, the message processing method as described in any of the preceding embodiments can be implemented.

[0074] In addition, one embodiment of this application discloses a computer-readable storage medium storing computer-executable instructions for performing message processing methods as described in any of the preceding embodiments.

[0075] Furthermore, one embodiment of this application also discloses a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of the computing device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the computing device to perform the message processing method as described in any of the preceding embodiments.

[0076] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0077] The above is a detailed description of the preferred embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A message processing method, applied to a first computing device, comprising: Send a message carrying a list of computing resource node identifiers to a second computing power device, wherein the list of computing resource node identifiers includes a first node identifier of a first computing resource node that needs to receive the message, and the list of computing resource node identifiers is used by the second computing power device to send the message to the first computing resource node according to the first node identifier.

2. The message processing method according to claim 1, characterized in that, The first node identifier includes one of the following: Node number; Node IP address.

3. The message processing method according to claim 2, characterized in that, The first node identifier is a node number, which is carried in the computing resource node identifier list in the form of a bit string or a number.

4. The message processing method according to claim 1, characterized in that, The list of computing resource node identifiers is set in one of the following locations in the message: The BIER header, located at the very beginning of the message; A new type of Ethernet header is located at the very beginning of the message; The message is after the Ethernet header; The message is after the IP header; The IPv6 extension header of the message.

5. The message processing method according to claim 4, characterized in that, The list of computing resource node identifiers is set in the BIER header at the very beginning of the message. The BIER header includes a node forwarding identifier, which indicates that the purpose of the list of computing resource node identifiers is to enable message forwarding between different computing resource nodes.

6. The message processing method according to claim 2, characterized in that, The first node identifier is a node number, which is carried in the computing power resource node identifier list in the form of a bit string. The computing power resource node identifier list also includes a hierarchical identifier. The node number is determined based on the bit string length supported by the computing power resource node identifier list, the value of the hierarchical identifier, and the position of the first node identifier in the bit string.

7. The message processing method according to claim 1, characterized in that, The list of computing resource node identifiers also includes a first stage identifier, which is used to indicate the task stage to which the first node identifier belongs.

8. The message processing method according to claim 1, characterized in that, The method further includes: The second computing power device is notified of the second node identifier of the second computing power resource node possessed by the first computing power device, wherein the second node identifier is used by the second computing power device to generate a computing power resource node forwarding table entry, and the computing power resource node forwarding table entry is used to guide the forwarding of messages to the second computing power resource node.

9. The message processing method according to claim 8, characterized in that, The second node identifier is communicated to the second computing device in one of the following ways: Announcements are made using an extended TLV based on the routing protocol; Announcements are made using an extended TLV based on the LLDP protocol.

10. The message processing method according to claim 9, characterized in that, The second node identifier is advertised to the second computing device via an extended TLV based on a routing protocol, the routing protocol including one of the following: BGP protocol, OSPF protocol, IS-IS protocol, RIFT protocol, and BABEL protocol.

11. The message processing method according to claim 1, characterized in that, The first computing resource node includes one of the following: GPU; CPU; Artificial intelligence task expert functional entity.

12. A message processing method, applied to a second computing device, the method comprising: Receive a message sent by a first computing power device carrying a list of computing power resource node identifiers, wherein the list of computing power resource node identifiers includes the first node identifier of the first computing power resource node that needs to receive the message; The message is sent to the first computing resource node according to the first node identifier in the computing resource node identifier list.

13. The message processing method according to claim 12, characterized in that: The first node identifier includes one of the following: Node number; Node IP address.

14. The message processing method according to claim 13, characterized in that, The first node identifier is a node number, which is carried in the computing resource node identifier list in the form of a bit string or a number.

15. The message processing method according to claim 12, characterized in that, The list of computing resource node identifiers is set in one of the following locations in the message: The BIER header, located at the very beginning of the message; A new type of Ethernet header is located at the very beginning of the message; The message is after the Ethernet header; The message is after the IP header; The IPv6 extension header of the message.

16. The message processing method according to claim 15, characterized in that, The list of computing resource node identifiers is set in the BIER header at the very beginning of the message. The BIER header includes a node forwarding identifier, which indicates that the purpose of the list of computing resource node identifiers is to enable message forwarding between different computing resource nodes.

17. The message processing method according to claim 13, characterized in that, The first node identifier is a node number, which is carried in the computing power resource node identifier list in the form of a bit string. The computing power resource node identifier list also includes a hierarchical identifier. The node number is determined based on the bit string length supported by the computing power resource node identifier list, the value of the hierarchical identifier, and the position of the first node identifier in the bit string.

18. The message processing method according to claim 12, characterized in that, The list of computing resource node identifiers also includes a first stage identifier, which is used to indicate the task stage to which the first node identifier belongs.

19. The message processing method according to claim 12, characterized in that, The method further includes: Receive the second node identifier of the second computing power resource node that the first computing power device has, as notified by the first computing power device. A computing resource node forwarding table entry is generated based on the second node identifier, wherein the computing resource node forwarding table entry is used to guide the forwarding of messages to the second computing resource node.

20. The message processing method according to claim 19, characterized in that, The second node identifier is communicated to the second computing device in one of the following ways: Announcements are made using an extended TLV based on the routing protocol; Announcements are made using an extended TLV based on the LLDP protocol.

21. The message processing method according to claim 20, characterized in that, The second node identifier is advertised to the second computing device via an extended TLV based on a routing protocol, the routing protocol including one of the following: BGP protocol, OSPF protocol, IS-IS protocol, RIFT protocol, and BABEL protocol.

22. The message processing method according to claim 12, characterized in that, The first computing resource node includes one of the following: GPU; CPU; Artificial intelligence task expert functional entity.

23. The message processing method according to claim 12, characterized in that, The method further includes: The third computing power device is notified of the second node identifier of the second computing power resource node to which the second computing power device is connected. The second node identifier is used by the third computing power device to generate a computing power resource node forwarding table entry, which is used to guide the forwarding of messages to the second computing power resource node.

24. The message processing method according to claim 23, characterized in that, The second node identifier is announced to the third computing device in one of the following ways: Announcements are made using an extended TLV based on the routing protocol; Announcements are made using an extended TLV based on the LLDP protocol.

25. The message processing method according to claim 24, characterized in that, The second node identifier is advertised to the third computing device via an extended TLV based on a routing protocol, the routing protocol including one of the following: BGP protocol, OSPF protocol, IS-IS protocol, RIFT protocol, and BABEL protocol.

26. A computing power device, characterized in that, include: At least one processor; At least one memory for storing at least one program; The message processing method according to any one of claims 1 to 25 is implemented when at least one of the programs is executed by at least one of the processors.

27. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the message processing method according to any one of claims 1 to 25.

28. A computer program product, comprising a computer program or computer instructions, characterized in that, The computer program or the computer instructions are stored in a computer-readable storage medium. The processor of the computing device reads the computer program or the computer instructions from the computer-readable storage medium and executes the computer program or the computer instructions, causing the computing device to perform the message processing method according to any one of claims 1 to 25.

Images