# Linux 核心專題: 分析 BitNet 的系統效能表現
> 執行人: willy-liu
> [專題解說影片](https://youtu.be/vMq8v2Kho-4)

## 任務簡述
BitNet b1.58 的運行效率極高。在 Apple M2 這類通用 CPU 上可達 29 毫秒延遲，且記憶體佔用僅為 0.4GB，遠小於例如 Gemma 3 1B 所需的 1.4GB。微軟團隊在基準測試中將其與 Llama 3.2 1B、Gemma 3 1B 與 Qwen 2.5 1.5B 等全精度模型對比，發現 BitNet 即使在參數較少、權重精度較低的情況下，仍能在 MMLU、GSM8K、MATH 等任務中維持穩定表現，並在 GSM8K 上奪得最佳成績。BitNet 於 30 億參數以上的規模下，其性能已能接近 FP16 模型，並於 70 億參數規模達成高達 4 倍的推理速度提升與 7 倍的記憶體節省，顯示此技術具備高度擴展潛力。

本任務嘗試運用 Linux 核心提供的效能分析工具，定位出 BitNet 運行時期的效能瓶頸，歸納出推理過程中的程式熱點並予以分析

## TODO: 探討 BitNet 的關鍵突破和原理

BitNet是微軟研究院與中國科學院研究人員在2023年發表的一個 [1-bit transformers for LLM](https://arxiv.org/abs/2310.11453) 架構，原生訓練純二值（1‑bit，權重僅為 ±1）BitLinear 模組，和其他研究不同，BitNet是原生用 1 Bit 從頭訓練，而不是先訓練全精度再量化，目標是達到與 FP16/FP32 Transformers 相當的效能，同時顯著減少記憶體佔用與能源消耗。

在 2024 年 2 月，團隊進一步提出 [BitNet b1.58 2B4T](https://arxiv.org/abs/2504.12285) 模型，使用1.58-bit權重量化(即三值 {-1, 0, +1})與8-bit激活值(float32->int8)方案，在2B參數規模、4兆token語料上從零訓練，效能可與同級全精度開源模型媲美，同時支援將訓練好的模型在bitnet.cpp(llama.cpp)框架等進行高效CPU/GPU推理；可以用在更輕量的平台。
（p.s. 累加和矩陣運算仍以 int32 或 float32 處理，這樣能兼顧訓練精度與推理速度。）

## TODO: 定位 BitNet 運行時期的效能瓶頸
> 運用 Linux 核心提供的效能分析工具，如 perf，也搭配 [uftrace](https://github.com/namhyung/uftrace) 一類使用者層級的工具，歸納出推理過程中的程式熱點並予以分析

:::spoiler 實驗環境

(bitnet-cpp) willy@linux2025:~/Desktop/linux2025$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

(bitnet-cpp) willy@linux2025:~/Desktop/linux2025$ lscpu
架構：                    x86_64
  CPU 作業模式：          32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   12
  On-line CPU(s) list:    0-11
供應商識別號：            GenuineIntel
  Model name:             Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
    CPU 家族：            6
    型號：                158
    每核心執行緒數：      2
    每通訊端核心數：      6
    Socket(s):            1
    製程：                10
    CPU(s) scaling MHz:   60%
    CPU max MHz:          4600.0000
    CPU min MHz:          800.0000
    BogoMIPS:             6399.96
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sys
                          call nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni p
                          clmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_dea
                          dline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpri
                          ority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt
                           xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilit
                          ies
Virtualization features:  
  虛擬：                  VT-x
Caches (sum of all):      
  L1d:                    192 KiB (6 instances)
  L1i:                    192 KiB (6 instances)
  L2:                     1.5 MiB (6 instances)
  L3:                     12 MiB (1 instance)
NUMA:                     
  NUMA 節點：             1
  NUMA node0 CPU(s)：     0-11
Vulnerabilities:          
  Gather data sampling:   Mitigation; Microcode
  Itlb multihit:          KVM: Mitigation: VMX disabled
  L1tf:                   Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
  Mds:                    Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Mitigation; Clear CPU buffers; SMT vulnerable
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; IBRS
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Mitigation; Microcode
  Tsx async abort:        Mitigation; TSX disabled
(bitnet-cpp) 

willy@linux2025:~/Desktop/linux2025$ gcc --version
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(bitnet-cpp) willy@linux2025:~/Desktop/linux2025$ conda info

     active environment : bitnet-cpp
    active env location : /home/willy/miniconda3/envs/bitnet-cpp
            shell level : 2
       user config file : /home/willy/.condarc
 populated config files : /home/willy/miniconda3/.condarc
          conda version : 25.1.1
    conda-build version : not installed
         python version : 3.12.9.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=skylake
                          __conda=25.1.1=0
                          __cuda=12.4=0
                          __glibc=2.39=0
                          __linux=6.11.0=0
                          __unix=0=0
       base environment : /home/willy/miniconda3  (writable)
      conda av data dir : /home/willy/miniconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/willy/miniconda3/pkgs
                          /home/willy/.conda/pkgs
       envs directories : /home/willy/miniconda3/envs
                          /home/willy/.conda/envs
               platform : linux-64
             user-agent : conda/25.1.1 requests/2.32.3 CPython/3.12.9 Linux/6.11.0-26-generic ubuntu/24.04.2 glibc/2.39 solver/libmamba conda-libmamba-solver/25.1.1 libmambapy/2.0.5 aau/0.5.0 c/. s/. e/.
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

:::

參考其他人的實驗：

- [alanhc](https://hackmd.io/@alanhc/2025q1-term-project)
- [Denny0097](https://hackmd.io/dXidLYjqT3SLwAyY2LSRpA?view)

### [microsoft/BitNet](https://github.com/microsoft/BitNet)

實驗方向

- [ ] 也許可以改變 chunk size 進行記憶體、 cache miss 和時間的分析
- [x] Huge Page
- [x] CPU Affinity
- [ ] 排程
- [ ] NUMA 調整

#### perf(kernel level)

- perf record
- https://gist.github.com/willy-liu/8d1708483690ab71f5048f8c68e7a59e

分析程式的熱點函式
| 佔比（%） | 函式名稱 | 所屬模組 | 推測用途與說明 |
| ------ | ---------------------------------- | ------------- | ------------------------------------------------------------ |
| 54.33% | `ggml_vec_dot_i2_i8_s` | `libggml.so` | **量化矩陣乘法核心**：針對 i2/i8 格式做向量內積運算，加速推論；通常為低精度 INT2/INT8 的權重乘法。 |
| 36.03% | `ggml_vec_dot_f16` | `libggml.so` | **向量內積（半精度）**：FP16 格式的內積操作，是未量化模型的基礎乘法核心。 |
| 26.41% | `_start` → `main` → `llama_decode` | `llama-cli` | **主要執行流程**：程式從主函式 `main` 開始，呼叫 LLaMA 解碼（推論）流程。 |
| 25.92% | `llama_decode_internal` | `libllama.so` | **核心推論邏輯**：負責 LLaMA 模型解碼，包括 token-by-token 的預測計算。 |
| 17.98% | `ggml_graph_compute_thread` | `libggml.so` | **背景執行緒**：處理計算圖執行的多執行緒核心。 |
| 1.74% | `ggml_vec_dot_i2_i8_s`（其他執行緒） | `libggml.so` | 同上，分佈在其他 thread 中。 |
| 0.75% | `ggml_barrier` | `libggml.so` | **執行緒同步點**：等待所有執行緒完成，類似 barrier 的功能。 |
| 0.74% | `quantize_row_i8_s` | `libggml.so` | **量化處理**：將浮點資料轉換為 INT8 表示，通常在加速部署時使用。 |

火焰圖

函式用途分類
| 分類 | 函式（代表） | 說明 |
| ----------- | ------------------------------------------------------------------------------------------ | -------------------------------------- |
| **矩陣/內積計算** | `ggml_vec_dot_i2_i8_s`, `ggml_vec_dot_f16` | 是整個模型計算的最核心部分（矩陣乘法的 dot product）。 |
| **矩陣乘法流程** | `ggml_compute_forward_mul_mat`, `ggml_compute_forward_mul_mat_one_chunk` | 表示計算圖中 forward pass 的一部分，針對不同區塊處理矩陣乘法。 |
| **模型執行主體** | `llama_decode_internal`, `llama_graph_compute` | 控制推論 token 的運作流程、計算圖排程等。 |
| **排程與執行緒** | `ggml_graph_compute_thread`, `ggml_graph_compute_secondary_thread`, `ggml_backend_sched_*` | 代表 GGML 用來安排 CPU 多執行緒運算的排程與背景執行邏輯。 |
| **同步與量化** | `ggml_barrier`, `quantize_row_i8_s` | 在前後處理中同步各 thread，或處理資料格式轉換。 |

- perf stat
- 預設執行 https://gist.github.com/willy-liu/3bbee1d5492d02b919e7445b59366a44
- 開啟 huge page https://gist.github.com/willy-liu/409f33add5bb65db3dce68d28cfd74b0
- huge page + CPU affinity https://gist.github.com/willy-liu/626c8a19fc4e82754ef8181e693b1d97

整體效能指標
| 項目 | 數值 | 解釋與分析 |
| ---------------------- | ----------------------- | -------------------------------------------------------------- |
| `cycles` | **337,403,155,184** | CPU 時鐘週期數，越多表示執行時間越長。 |
| `instructions` | **375,024,850,451** | 指令數量，代表總共執行的 CPU 指令。 |
| `insn per cycle (IPC)` | **1.11** | 每 cycle 執行 1.11 條指令，<br>理想值越高越好，通常 > 1 表示 CPU 沒有完全被 memory 拖慢。 |
| `time elapsed` | **16.46 秒**（wall clock） | 真實執行時間。注意和下方 `user`/`sys` 是不同角度。 |
| `user` time | **84.49 秒** | 表示使用者空間總 CPU 使用時間，<br>多執行緒程式會大於實際時間（共用 CPU 核心）。 |
| `sys` time | **0.27 秒** | 核心空間（系統呼叫）耗費的時間，低代表系統開銷小。 |

快取
| 項目 | 數值 | 解釋與分析 |
| -------------------- | ---------- | ------------------------------------------------------ |
| `cache-references` | 6.13B | Cache 存取次數。高代表 CPU 積極使用快取。 |
| `cache-misses` | 1.68B | Cache miss 數量，越高代表從 RAM 讀取次數多。 |
| **cache miss ratio** | **27.37%** | 高達 27% → **快取命中率差，效能可能受限於記憶體存取延遲**。可能是模型參數太大或資料存取模式不佳。 |

TLB（Translation Lookaside Buffer）
| 項目 | 數值 | 解釋 |
| ------------------ | ------------- | ---------------------------------------------------- |
| `dTLB-loads` | 155B | data TLB 存取次數 |
| `dTLB-load-misses` | 19M（0.01%） | 幾乎沒有 miss，代表資料分頁效率很好 |
| `iTLB-loads` | 7.59M | instruction TLB 存取次數 |
| `iTLB-load-misses` | 1.05M（13.89%） | **iTLB miss 比例偏高** → 程式碼/指令分布廣、跳躍多，可能影響效能（常見於大型模型推論） |

效能比較
| 項目 | ❌ 預設 | ✅ 開啟 THP | ✅ THP + 綁定核心<br>`taskset -c 0-5` |
| ------------------ | --------------- | ---------- | -------------------------------- |
| `time elapsed`（秒） | 16.46 | 15.64 | 15.53 |
| `instructions` | 375.02B | 373.47B | 373.01B |
| `cycles` | 337.4B | 324.7B | 320.1B |
| `IPC` | 1.11 | 1.15 | 1.17 |
| `cache-miss ratio` | 27.37% | 27.86% | 28.17% |
| `iTLB-load-misses` | 1.05M | **0.64M** | 0.97M |
| `iTLB miss rate` | 13.89% | **13.30%** | **18.84%** 🔺 |

#### uftrace

使用uftrace前，要重新 make 專案，並加入
- cmake
- -pg
- 插入 mcount() 呼叫點，讓 uftrace 能靜態追蹤每個函式的呼叫與耗時。
- uftrace 預設是靠這個符號來追蹤函式層級的動態呼叫圖。
- -g
- 加入 debug 符號（如函式名稱、原始碼行號），讓 uftrace report 顯示人類可讀的函式名，而不是地址。
- 若省略會導致 report 顯示不出原始碼函式。
- fno-omit-frame-pointer
- 保留堆疊追蹤資訊，對 uftrace、perf、gdb 都有幫助。
- 預設編譯器會優化掉 frame pointer，這會讓函式追蹤和火焰圖解析不準。
- -O0（選擇性）
- 關閉編譯最佳化，讓追蹤結果更接近原始碼結構。
- 缺點是效能變慢，不建議在大型推論中長時間使用，但可用於小範例測試。

修改`./setup_env.py`

-    run_command(["cmake", "-B", "build", *COMPILER_EXTRA_ARGS[arch], *OS_EXTRA_ARGS.get(platform.system(), []), "-DCMAKE_C_COMPILER=clang", "-DCMAKE_CXX_COMPILER=clang++"], log_step="generate_build_files")
+    run_command([
+        "cmake",
+        "-B", "build",
+        *COMPILER_EXTRA_ARGS[arch],
+        *OS_EXTRA_ARGS.get(platform.system(), []),
+        "-DCMAKE_C_COMPILER=clang",
+        "-DCMAKE_CXX_COMPILER=clang++",
+        "-DCMAKE_BUILD_TYPE=RelWithDebInfo",
+        "-DCMAKE_C_FLAGS=-pg -fno-omit-frame-pointer",
+        "-DCMAKE_CXX_FLAGS=-pg -fno-omit-frame-pointer",
+    ], log_step="generate_build_files")

再重新編譯
`python setup_env.py -md models/BitNet-b1.58-2B-4T -q i2_s`

執行結果
- https://gist.github.com/willy-liu/66e9c3f60170ffd657abcdfea2f20d46

熱點分析
| # | Function 名稱 | 呼叫次數 | 總時間 | 主要功能說明 |
| -: | ---------------------------------------- | ------: | ------: | ---------------------------- |
| 1 | `ggml_vec_dot_i2_i8_s` | \~37M | 40.35s | INT2xINT8 量化矩陣乘法 dot product |
| 2 | `ggml_vec_dot_f16` | \~11.7M | 18.87s | float16 dot product，應為主推理路徑 |
| 3 | `ggml_compute_forward_mul_mat_one_chunk` | \~715K | 6.46s | 單一 chunk 的矩陣乘法計算 |
| 4 | `ggml_barrier` | \~424K | 20.05s | 執行緒同步，thread barrier |
| 5 | `ggml_graph_compute_thread` | 306 次 | 85.57ms | 主要 graph 計算執行緒 |
| 6 | `ggml_graph_compute_secondary_thread` | 10 次 | 119μs | 次要執行緒調度 |
| 7 | `ggml_thread_cpu_relax` | \~219M | 23.36s | idle 等待同步，表示有大量同步等待時間 |
| 8 | `llama_decode` | 102 次 | 41.93s | 單一 token 的推理過程 |
| 9 | `llama_decode_internal` | 51 次 | 20.97s | `llama_decode` 的核心實作 |
| 10 | `std::map::emplace` 等 STL | - | 10s+ | token 對應、編碼解碼查表等 |

主要耗時在：
- 向量運算與矩陣乘法核心
- ggml_vec_dot_i2_i8_s, ggml_vec_dot_f16, ggml_compute_forward_mul_mat_one_chunk
- 大量執行緒同步
- ggml_barrier, ggml_thread_cpu_relax 表示 CPU threads 在等待任務分配與同步
- token 解碼
- llama_decode, llama_token_to_piece 系列是處理 token 字串的轉換與生成

#### 嘗試修改chunk_size，觀察ggml_compute_forward_mul_mat的cache和時間變化

[tiled matrix mul筆記](https://hackmd.io/@willy-liu/ryh9rcJree)