Llama3-8B (Text Generation)¶
This case study runs Llama3-8B with RBLN Optimum and analyzes computation and data transfers distributed across multiple ATOM™ devices using RSD.
Llama3-8B is an open-source LLM (Large Language Model) developed by Meta that shows superhuman performance across various natural language processing tasks. Its large number of parameters and substantial memory requirements pose significant challenges for deploying the model on a single device.
To address this issue, Rebellions supports LLMs through tensor parallelism, which is called RSD (Rebellions Scalable Design). As shown in the visualized profiling data below, the simultaneous use of multiple devices introduces unique patterns that are not observed in single-device operations. This page introduces several distinct scenarios that arise when running an LLM with RSD.
Preliminaries¶
Installation¶
Compile Model and Activate RBLN Profiler¶
Or, set rbln_activate_profiler=True to enable the RBLN Profiler:
Extract Profiled Data with Inference¶
Run inference to obtain profiling data:
Alternatively, use scoped profiling methods as shown below:
Analysis of Profiled data from Llama3-8B with RBLN Profiler¶
This analysis explains how synchronization and input/output are handled for layer normalization in the LlamaDecoderLayer and for the q_proj and o_proj layers of self-attention, which are divided by compiler sharding. In addition, it explains the attention suffix that is appended to the names of several commands to help users understand how the attention mechanism executes.
LlamaDecoderLayer¶
LlamaAttention¶
Layernorm Execution in Root Node¶
The 0_causal_lm.model.0.input_layernorm layer is small enough to run on a single device. Thus, this layer is processed on a single device and the output is transferred to other devices. While the root ATOM™ device processes input_layernorm, other devices use Neural DMA to load weight parameters that are needed later. After input_layernorm is computed, the output tensor is transferred to leaf ATOM™ devices with Device HDMA commands.
Send Output Data and Synchronization¶
The output tensor of input_layernorm is transferred to the DRAM of ATOM™ 0 by Task DMA. Also, because leaf ATOM™ devices should use the same tensor, it is transferred to them by Device HDMA. These processes occur with almost no time delay, allowing the leaf nodes to quickly process the next layer. When tensor data is transferred by a Device HDMA command, a receiver (leaf) ATOM™ executes the Device Sync command for integrity. After this command is processed, each device loads the data in the same way as data transferred from External HDMA. Note that the Device HDMA command is executed on the sender, not the receiver.
Gather data to root node¶
The Device HDMA command is executed not only when an output tensor computed in the root ATOM™ device is scattered, but also when output tensors computed in leaf ATOM™ devices are gathered. The above example shows how the output tensor computed on a leaf ATOM™ device is transferred to the root ATOM™ device. Each output tensor that is transferred by Device HDMA is transferred to the internal Shared Memory of the root ATOM™ by Task DMA. The Neural Engine Clusters command that gathers the output tensors depends on the final Task DMA command, which retrieves the last output tensor from a leaf ATOM™ device, so it runs only after that Task DMA command completes.
Naming policy about attention¶
In transformer-based networks, it is important to understand how the attention mechanism works. However, because existing frameworks mainly construct models using modules, it is hard to identify when and how attention operates. To help users understand, the RBLN Profiler appends an attention suffix to commands that consist of an attention operation.
References¶
- RBLN Profiler
- Analyzing profiler data with Perfetto
- Other profiling examples: YOLOv8 (Object Detection), Stable Diffusion 3 (Image Generation)




