Skip to content

Commit c4eeab8

Browse files
authored
Merge branch 'ArmDeveloperEcosystem:main' into content_review
2 parents 1a84331 + fe17602 commit c4eeab8

10 files changed

Lines changed: 257 additions & 190 deletions

File tree

.wordlist.txt

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4949,4 +4949,15 @@ uop
49494949
walkthrough
49504950
warmups
49514951
xo
4952-
yi
4952+
yi
4953+
AMX
4954+
AlexNet
4955+
FMAC
4956+
MySql
4957+
MyStrongPassword
4958+
RDBMS
4959+
SqueezeNet
4960+
TIdentify
4961+
goroutines
4962+
mysqlslap
4963+
squeezenet

content/learning-paths/servers-and-cloud-computing/_index.md

Lines changed: 10 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ key_ip:
88
maintopic: true
99
operatingsystems_filter:
1010
- Android: 3
11-
- Linux: 177
11+
- Linux: 179
1212
- macOS: 13
1313
- Windows: 14
1414
pinned_modules:
@@ -20,9 +20,9 @@ pinned_modules:
2020
subjects_filter:
2121
- CI-CD: 7
2222
- Containers and Virtualization: 32
23-
- Databases: 17
23+
- Databases: 18
2424
- Libraries: 9
25-
- ML: 31
25+
- ML: 32
2626
- Performance and Architecture: 72
2727
- Storage: 1
2828
- Web: 12
@@ -36,9 +36,9 @@ tools_software_languages_filter:
3636
- AI: 1
3737
- Android Studio: 1
3838
- Ansible: 2
39-
- Apache Bench: 1
4039
- Apache Spark: 2
4140
- Apache Tomcat: 2
41+
- ApacheBench: 1
4242
- Arm Compiler for Linux: 1
4343
- Arm Development Studio: 3
4444
- Arm ISA: 1
@@ -80,7 +80,7 @@ tools_software_languages_filter:
8080
- Daytona: 1
8181
- Demo: 3
8282
- Django: 1
83-
- Docker: 22
83+
- Docker: 23
8484
- Envoy: 3
8585
- ExecuTorch: 1
8686
- FAISS: 1
@@ -99,7 +99,6 @@ tools_software_languages_filter:
9999
- GitLab: 1
100100
- glibc: 1
101101
- Go: 4
102-
- go test -bench: 1
103102
- Golang: 1
104103
- Google Axion: 3
105104
- Google Benchmark: 1
@@ -139,15 +138,14 @@ tools_software_languages_filter:
139138
- mongostat: 1
140139
- mongotop: 1
141140
- mpi: 1
142-
- MySQL: 9
141+
- MySQL: 10
143142
- NEON: 7
144-
- Neoverse: 1
145143
- Networking: 1
146144
- Nexmark: 1
147145
- NGINX: 4
148146
- Node.js: 3
149147
- Ollama: 1
150-
- ONNX Runtime: 1
148+
- ONNX Runtime: 2
151149
- OpenBLAS: 1
152150
- OpenBMC: 1
153151
- OpenJDK 21: 2
@@ -157,7 +155,7 @@ tools_software_languages_filter:
157155
- perf: 6
158156
- PostgreSQL: 4
159157
- Profiling: 1
160-
- Python: 31
158+
- Python: 32
161159
- PyTorch: 9
162160
- QEMU: 1
163161
- RAG: 1
@@ -170,7 +168,7 @@ tools_software_languages_filter:
170168
- Siege: 1
171169
- snappy: 1
172170
- Snort3: 1
173-
- SQL: 7
171+
- SQL: 8
174172
- Streamline CLI: 1
175173
- Streamlit: 2
176174
- Supervisor: 1
@@ -204,6 +202,6 @@ weight: 1
204202
cloud_service_providers_filter:
205203
- AWS: 17
206204
- Google Cloud: 18
207-
- Microsoft Azure: 15
205+
- Microsoft Azure: 17
208206
- Oracle: 2
209207
---

content/learning-paths/servers-and-cloud-computing/llama_cpp_streamline/1_overview.md

Lines changed: 10 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -6,26 +6,21 @@ weight: 2
66
layout: learningpathall
77
---
88

9-
## Overview: Profiling LLMs on Arm CPUs with Streamline
9+
## Profiling LLMs on Arm CPUs with Streamline
1010

11-
Large Language Models (LLMs) run efficiently on Arm CPUs.
12-
Frameworks that run LLMs, such as [**llama.cpp**](https://github.com/ggml-org/llama.cpp), provides a convenient framework for running LLMs, it also comes with a certain level of complexity.
11+
Deploying Large Language Models (LLMs) on Arm CPUs provides a power-efficient and flexible solution. While larger models may benefit from GPU acceleration, techniques like quantization enable a wide range of LLMs to perform effectively on CPUs alone.
12+
13+
Frameworks such as [**llama.cpp**](https://github.com/ggml-org/llama.cpp), provide a convenient way to run LLMs, but it also comes with a certain level of complexity.
1314

1415
To analyze their execution and use profiling insights for optimization, you need both a basic understanding of transformer architectures and the right analysis tools.
1516

16-
This learning path demonstrates how to use the **llama-cli** application from llama.cpp together with **Arm Streamline** to analyze the efficiency of LLM inference on Arm CPUs.
17+
This Learning Path demonstrates how to use `llama-cli` application from llama.cpp together with Arm Streamline to analyze the efficiency of LLM inference on Arm CPUs.
1718

18-
In this guide you will learn how to:
19-
- Profile token generation at the **Prefill** and **Decode** stages
19+
You will learn how to:
20+
- Profile token generation at the Prefill and Decode stages
2021
- Profile execution of individual tensor nodes and operators
21-
- Profile LLM execution across **multiple threads and cores**
22+
- Profile LLM execution across multiple threads and cores
2223

23-
You will run the **Qwen1_5-0_5b-chat-q4_0.gguf** model with llama-cli on **Arm64 Linux** and use Streamline for analysis.
24-
The same method can also be applied to **Arm64 Android** platforms.
24+
You will run the `Qwen1_5-0_5b-chat-q4_0.gguf` model using `llama-cli` on Arm Linux and use Streamline for analysis.
2525

26-
## Prerequisites
27-
Before starting this guide, you should be familiar with:
28-
- Basic understanding of llama.cpp
29-
- Understanding of transformer model
30-
- Knowledge of Streamline usage
31-
- An Arm Neoverse or Cortex-A hardware platform running Linux or Android to test the application
26+
The same method can also be applied to Android platforms.
Lines changed: 58 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -1,57 +1,86 @@
11
---
2-
title: Understand the llama.cpp
2+
title: Understand llama.cpp
33
weight: 3
44

55
### FIXED, DO NOT MODIFY
66
layout: learningpathall
77
---
88

9-
## Understand the llama.cpp
9+
## Understand llama.cpp
1010

11-
**llama.cpp** is an open-source LLM framework implemented in C++ that supports both training and inference.
12-
This learning path focuses only on **inference on the CPU**.
11+
llama.cpp is an open-source LLM framework implemented in C++ that supports both training and inference.
1312

14-
The **llama-cli** tool provides a command-line interface to run LLMs with the llama.cpp inference engine.
13+
This Learning Path focuses on inference on Arm CPUs.
14+
15+
The `llama-cli` tool provides a command-line interface to run LLMs with the llama.cpp inference engine.
1516
It supports text generation, chat mode, and grammar-constrained output directly from the terminal.
1617

1718
![text#center](images/llama_structure.png "Figure 1. llama-cli Flow")
1819

19-
### What llama-cli does
20-
- Load and interpret LLMs in **.gguf** format
21-
- Build a **compute graph** based on the model structure
22-
- The graph can be divided into subgraphs, each assigned to the most suitable backend device
23-
- In this guide, all operators are executed on the **CPU backend**
24-
- Allocate memory for tensor nodes using the **graph planner**
25-
- Execute tensor nodes in the graph during the **graph_compute** stage, which traverses nodes and forwards work to backend devices
20+
### What does the Llama CLI do?
21+
22+
Here are the steps performed by `llama-cli`:
23+
24+
1. Load and interpret LLMs in GGUF format
25+
26+
2. Build a compute graph based on the model structure
27+
28+
The graph can be divided into subgraphs, each assigned to the most suitable backend device, but in this Learning Path all operations are executed on the Arm CPU backend.
29+
30+
3. Allocate memory for tensor nodes using the graph planner
2631

27-
Step2 to Step4 are wrapped inside the function **`llama_decode`**.
28-
During **Prefill** and **Decode**, `llama-cli` repeatedly calls `llama_decode` to generate tokens.
29-
The parameter **`llama_batch`** passed to `llama_decode` differs between stages, containing input tokens, their count, and their positions.
32+
4. Execute tensor nodes in the graph during the `graph_compute` stage, which traverses nodes and forwards work to backend devices
33+
34+
Steps 2 to 4 are wrapped inside the function `llama_decode`.
35+
During Prefill and Decode, `llama-cli` repeatedly calls `llama_decode` to generate tokens.
36+
37+
The parameter `llama_batch` passed to `llama_decode` differs between stages, containing input tokens, their count, and their positions.
38+
39+
### What are the components of llama.cpp?
3040

31-
### Components of llama.cpp
3241
The components of llama.cpp include:
33-
![text#center](images/llama_componetns.jpg "Figure 2. llmama.cpp components")
3442

35-
llama.cpp supports various backends such as `CPU`, `GPU`, `CUDA`, `OpenCL` etc.
43+
![text#center](images/llama_components.jpg "Figure 2. llama.cpp components")
44+
45+
llama.cpp supports various backends such as `CPU`, `GPU`, `CUDA`, and `OpenCL`.
46+
47+
For the CPU backend, it provides an optimized `ggml-cpu` library, mainly utilizing CPU vector instructions.
48+
49+
For Arm CPUs, the `ggml-cpu` library also offers an `aarch64` trait that leverages 8-bit integer multiply (i8mm) instructions for acceleration.
3650

37-
For the CPU backend, it provides an optimized `ggml-cpu` library (mainly utilizing CPU vector instructions).
38-
For Arm CPUs, the `ggml-cpu` library also offers an `aarch64` trait that leverages the new **I8MM** instructions for acceleration.
3951
The `ggml-cpu` library also integrates the Arm [KleidiAI](https://github.com/ARM-software/kleidiai) library as an additional trait.
4052

4153
### Prefill and Decode in autoregressive LLMs
42-
Most autoregressive LLMs are Decoder-only model.
43-
Here is a brief introduction to Prefill and Decode stage of autoregressive LLMs.
44-
![text#center](images/llm_prefill_decode.jpg "Figure 3. Prefill and Decode stage")
54+
55+
An autoregressive LLM is a type of Large Language Model that generates text by predicting the next token (word or word piece) in a sequence based on all the previously generated tokens.
56+
57+
The term "autoregressive" means the model uses its own previous outputs as inputs for generating subsequent outputs, creating a sequential generation process.
58+
59+
For example, when generating the sentence "The cat sat on the", an autoregressive LLM:
60+
1. Takes the input prompt as context
61+
2. Predicts the next most likely token (e.g., "mat")
62+
3. Uses the entire sequence including "mat" to predict the following token
63+
4. Continues this process token by token until completion
64+
65+
This sequential nature is why autoregressive LLMs have two distinct computational phases: Prefill (processing the initial prompt) and Decode (generating tokens one by one).
66+
67+
Most autoregressive LLMs are Decoder-only models. This refers to the transformer architecture they use, which consists only of decoder blocks from the original Transformer paper. The alternatives to decoder-only models include encoder-only models used for tasks like classification and encoder-decoder models used for tasks like translation.
68+
69+
Decoder-only models like LLaMA have become dominant for text generation because they are simpler to train at scale, can handle both understanding and generation tasks, and are more efficient for text generation.
70+
71+
Here is a brief introduction to Prefill and Decode stages of autoregressive LLMs.
72+
![text#center](images/llm_prefill_decode.jpg "Figure 3. Prefill and Decode stages")
4573

4674
At the Prefill stage, multiple input tokens of the prompt are processed.
47-
It mainly performs GEMM (A matrix is multiplied by another matrix) operations to generate the first output token.
75+
76+
It mainly performs GEMM (a matrix is multiplied by another matrix) operations to generate the first output token.
77+
4878
![text#center](images/transformer_prefill.jpg "Figure 4. Prefill stage")
4979

50-
At the Decode stage, by utilizing the [KV cache](https://huggingface.co/blog/not-lain/kv-caching), it mainly performs GEMV (A vector is multiplied by a matrix) operations to generate subsequent output tokens one by one.
80+
At the Decode stage, by utilizing the [KV cache](https://huggingface.co/blog/not-lain/kv-caching), it mainly performs GEMV (a vector is multiplied by a matrix) operations to generate subsequent output tokens one by one.
81+
5182
![text#center](images/transformer_decode.jpg "Figure 5. Decode stage")
5283

53-
Therefore,
54-
- **Prefill** is **compute-bound**, dominated by large GEMM operations
55-
- **Decode** is **memory-bound**, dominated by KV cache access and GEMV operations
84+
In summary, Prefill is compute-bound, dominated by large GEMM operations and Decode is memory-bound, dominated by KV cache access and GEMV operations.
5685

57-
This can be seen in the subsequent analysis with Streamline.
86+
You will see this highlighted during the analysis with Streamline.

0 commit comments

Comments
 (0)