Tag: gpu

AMD 平台上的 LLM 計算

前幾天在 Hacker News 上看到的文章：「Making AMD GPUs competitive for LLM inference (mlc.ai)」，原文在「Making AMD GPUs competitive for LLM inference」這邊。

Nvidia 在 GPU 上的各種運算這塊進來的很早，除了本家開發了很多工具以外，社群的支援度也很好。而 AMD 這邊就差了不少，但這也反應在顯卡的售價上面。

作者整理了同樣是 24GB VRAM 的顯卡出來，分別是 AMD 的 7900XTX，以及 Nvidia 的 3090 Ti 與新的 4090：

可以看出來縮然同樣 fp16 對應到的功耗差蠻多的，但單價低很多，對於業餘玩家偶而用來說，其實是個可以考慮的方案。

而他們的成果可以看出來效果其實不差，跑 Llama 2 的 model 可以看到 CP 值相當高：

看起來支援的主力在 ROCm 上，就效能與功耗的筆直來說其實是超越的？(或者保守一點的說，是在同一個水平上的)

現在算是 AMD 顯卡在追趕的過程，社群的力量看起來會是主力...

用 ggml 跑的 MPT-30B

在 Simon Willison 這邊看到的「abacaj/mpt-30B-inference」，介紹了用 ggml 跑的 MPT-30B 專案：「abacaj/mpt-30B-inference」。

MPT-30 是個 open source model，比起同樣也是 open source model 的 Falcon-40B 小了一點，在官方的說明「MPT-30B: Raising the bar for open-source foundation models」可以看到其中一個特性是可以塞進單張 GPU：

The size of MPT-30B was also specifically chosen to make it easy to deploy on a single GPU—either 1x NVIDIA A100-80GB in 16-bit precision or 1x NVIDIA A100-40GB in 8-bit precision. Other comparable LLMs such as Falcon-40B have larger parameter counts and cannot be served on a single datacenter GPU (today); this necessitates 2+ GPUs, which increases the minimum inference system cost.

但即使如此，一般人也應該不會有 A100-40G 這種卡，所以很自然的就會想到可以用 ggml 在 CPU 上跑。

然後提到 ggml... 目前 llama.cpp 在 Falcon-40B 上還是卡關中，這樣看起來 MPT-30B 應該是目前 ggml 能跑的最大的 open source model？

Simon Willison 說他在 M2 MacBook Pro 上跑沒什麼問題，我在 32GB RAM 的 Linux 上也能跑，就照著 README.md 走就可以了，不過在 Python 裡面的預設是使用一半的 CPU core，我改成使用全部的 core，速度看起來有比較快。

然後回答的品質比起之前玩各家 7B 的版本好很多，丟了一些問題給他答，已經蠻有水準了...

John Carmack 對於 1990 年代類神經網路沒有興起的討論...

Hacker News 上看到「Neural networks in the 1990s (twitter.com/id_aa_carmack)」這篇，原推在：

在 Hacker News 上的 rm999 有提到當時的結果，可以解釋為什麼在 1990 年代時類神經網路沒有興起的關係：

A lot of the problems that did benefit from neural networks in the 90s/early 2000s just needed a non-linear model, but did not need huge neural networks to do well. You can very roughly consider the first layer of a 2-layer neural network to be a series of classifiers, each tackling a different aspect of the problem (e.g. the first neuron of a spam model may activate if you have never received an email from the sender, the second if the sender is tagged as spam a lot, etc). These kinds of problems didn't need deep, large networks, and 10-50 neuron 2-layer networks were often more than enough to fully capture the complexity of the problem. Nowadays many practitioners would throw a GBM at problems like that and can get away with O(100) shallow trees, which isn't very different from what the small neural networks were doing back then.

1990 年代時的主題還是比較簡單的題目，像是分 category 這類題目 (一個常見的應用是 spam filter)，而這些題目在傳統方式與類神經網路的差異並不大。

直到後來 GPU 運算技術的成熟，而且從 2010 年有 cloud 的概念以後，一般單位可以不用花大錢自己建整套超級電腦，只需要花一些 OPEX 就可以生出小型的超級電腦 (短時間)，這讓不少單位都可以有夠大的計算力計算大型 model (相較於以前的大小)，也才看得出來大型 model 用來解更複雜問題的威力。

而 2014 年的 AlphaGo 算是一個類神經網路對一般人衝擊的成功案例 (i.e. 跨出圈子)，這也讓投資人對人工智慧的主題更願意投資。

OpenLLM，用 Python 包裝 open source LLM 的套件

在 Hacker News 上看到「OpenLLM (github.com/bentoml)」，是一個用 Python 寫的軟體，把 open source LLM 包裝起來讓你用。

先拿 Mac 簡單測了一下，看起來包的不錯，可以用 HTTP API 來打。

先用 pip 裝：

pip install openllm

然後就可以把 server 跑起來了，依照範例跑 dolly-v2，第一次跑會比較久，需要下載 model：

openllm start dolly-v2

接下來就可以直接開 http://127.0.0.1:3000/ 來操作了，另外也可以用 command line 跑，像是依照官方的範例來跑：

openllm query --endpoint http://127.0.0.1:3000 "What is the meaning of life?"

目前測到比較明顯的問題是 CPU 模式下只有 single thread，所以雖然會動，但相當慢... 之後再來測試 GPU 的部分。

在 Intel 內顯上面直接跑 CUDA 程式的 ZLUDA

Hacker News 首頁上看到的有趣東西：「Zluda: Run CUDA code on Intel GPUs, unmodified (github.com/vosen)」，專案在「CUDA on Intel GPUs」這邊，這是個最後更新在 2021 年的專案。

這個專案的想法可以猜得出來，想要吃 CUDA 的 ecosystem，把現有用 CUDA 的應用程式直接跑在 Intel 的 GPU 上面，這樣對於一些只有 CUDA 卻沒有 OpenCL 的實作就有機會拿來用。

一開始本來以為是給 Intel 新的獨立顯卡 Arc，結果發現是 2021 年就停更的專案，是以內顯來測試的：

ZLUDA performance has been measured with GeekBench 5.2.3 on Intel UHD 630.

從 benchmark 的結果看起來，大多數的功能應該都有 porting 上去，所以至少測試是能跑的，而不是 crash：

不過 Hacker News 的討論上可以看到似乎還是有問題，而且大多數的 AI 應用還是會回頭支援 OpenCL，似乎沒有那麼好用...

llama.cpp 有全 GPU 版本了

在 Hacker News 首頁上看到「Llama.cpp: Full CUDA GPU Acceleration (github.com/ggerganov)」，對應得原頁面在「CUDA full GPU acceleration, KV cache in VRAM #1827」這邊。

裡面是在講 llama.cpp 之前的 GPU 加速還是有不少事情是在 CPU 上面做，這次是把目前 ggml 支援的操作都實作 GPU 版本了：

This PR adds GPU acceleration for all remaining ggml tensors that didn't yet have it. Especially for long generations this makes a large difference because the KV cache is still CPU only on master and gets larger as the context fills up.

蠻多人有不同測試的結果，要注意這次不是把 CPU 搬到 GPU 上面做，而是把本來因為比較 light 而還沒搬上 GPU 的部分搬上去，所以不會是數量級的加速，但看起來改善也已經很不賴了：

Early attempt this morning we're getting ~2.5-2.8x perf increase on 4090s and about 1.8-2x on 3090Ti.

然後 Falcon... 目前看起來還沒有必較好的進展 XD

Georgi Gerganov 成立公司 GGML

Hacker News 首頁上看到 Georgi Gerganov 成立公司的計畫：「GGML – AI at the Edge (ggml.ai)」，官網在「GGML - AI at the edge」。

如同 Georgi Gerganov 提到的，llama.cpp 這些專案本來是他的 side project，結果意外的紅起來：

另外他提到了 Nat Friedman 與 Daniel Gross 也幫了一把：

在官網則是有提到是 pre-seed funding：

ggml.ai is a company founded by Georgi Gerganov to support the development of ggml. Nat Friedman and Daniel Gross provided the pre-seed funding.

現在回頭來看，當初 llama.cpp 會紅起來主要是因為 CPU 可以跑 LLaMA 7B，而且用 CPU 跑起來其實也不算慢。

後來吸引了很多人一起幫忙，於是有了不少 optimization (像是「llama.cpp 的載入速度加速」這邊用 mmap 減少需要載入的時間，並且讓多個 process 之間可以重複使用 cache)，接下來又有 GPU 的支援...

但不確定他開公司後，長遠的計畫是什麼...？

雲端上面的 GPU 資源費用，以及地端的 GPU 決策圖

在 Hacker News 上面看到「Cloud GPU Resources and Pricing (fullstackdeeplearning.com)」這篇，原網頁是「Cloud GPUs - The Full Stack」，裡面有些有用的資源可以拉出來獨立看。

雲端的選擇上，因為 H100 看起來還沒普及，所以用上一代的 A100 (80GB) 來看，可以看到大的雲端跟其他家的差異還是蠻大的：

不過這邊好像沒把 vast.ai 放進來。

地端的資訊主要是直接購買顯示卡時的選擇，可以看到如果除了各系列的旗艦卡外 (4090 & 3090 & 2080)，3060 是一張會在考慮到「便宜」而上榜的卡，應該是因為他是一張入門價位的顯卡，卻有 12GB VRAM 的關係：

在接下來七月要推出的 4060 會出 16GB VRAM 版本，應該會取代現在 3060 12GB VRAM 的地位...

llama.cpp 開始支援 GPU 了

前陣子因為重灌桌機，所以在重建許多環境... 其中一個就是 llama.cpp，連到專案頁面上時意外發現這兩個新的 feature：

OpenBLAS support
cuBLAS and CLBlast support

這代表可以用 GPU 加速了，所以就照著說明試著編一個版本測試。

編好後就跑了 7B 的 model，看起來快不少，然後改跑 13B 的 model，也可以把完整 40 個 layer 都丟進 3060 (12GB 版本) 的 GPU 上：

./main -m models/13B/ggml-model-q4_0.bin -p "Building a website can be done in 10 simple steps:" -n 512 -ngl 40

從 log 可以看到 40 layers 到都 GPU 上面，吃了 7.5GB 左右：

llama.cpp: loading model from models/13B/ggml-model-q4_0.bin
llama_model_load_internal: format     = ggjt v2 (latest)
llama_model_load_internal: n_vocab    = 32000
llama_model_load_internal: n_ctx      = 512
llama_model_load_internal: n_embd     = 5120
llama_model_load_internal: n_mult     = 256
llama_model_load_internal: n_head     = 40
llama_model_load_internal: n_layer    = 40
llama_model_load_internal: n_rot      = 128
llama_model_load_internal: ftype      = 2 (mostly Q4_0)
llama_model_load_internal: n_ff       = 13824
llama_model_load_internal: n_parts    = 1
llama_model_load_internal: model size = 13B
llama_model_load_internal: ggml ctx size =  90.75 KB
llama_model_load_internal: mem required  = 9807.48 MB (+ 1608.00 MB per state)
llama_model_load_internal: [cublas] offloading 40 layers to GPU
llama_model_load_internal: [cublas] total VRAM used: 7562 MB
llama_init_from_file: kv self size  =  400.00 MB

30B 的 model 我也試著丟上去跑，但只能丟 28 layers 上去 (全部是 60 layers)，再多 GPU 的記憶體就撐不住了。

但能用 GPU 算是一個很大的進展，現在這版只快了一半的時間，不知道後面還有沒有 tune 的空間...

Hashcat 在 3090 與 4090 上的速度差異

想到的時候查了一下，發現進步頗大的...

可以參考「Hashcat v6.1.1 benchmark on the Nvidia RTX 3090」與「Hashcat v6.2.6 benchmark on the Nvidia RTX 4090」這兩份資料。

已經被打到爛的 $1$ 或是 $apr1$ 就不看了，主要還是看比較有抵抗性的 KDF 的速度。

撞老牌的 bcrypt，在 4090 的速度快要是 3090 的兩倍了：

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32)
Speed.#1.........:    96662 H/s (36.29ms) @ Accel:8 Loops:16 Thr:11 Vec:1
* Hash-Mode 3200 (bcrypt $2*$, Blowfish (Unix)) [Iterations: 32]
Speed.#1.........:   184.0 kH/s (50.22ms) @ Accel:4 Loops:32 Thr:24 Vec:1

但是在看 scrypt 的時候不知道為什麼 3090 跑的 iterations 是 1，這兩個不對等：

Hashmode: 8900 - scrypt (Iterations: 1)
Speed.#1.........:  2308.2 kH/s (8.64ms) @ Accel:16 Loops:1 Thr:16 Vec:1
* Hash-Mode 8900 (scrypt) [Iterations: 16384]
Speed.#1.........:     7126 H/s (29.16ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

改看 9300 這組的話，iterations 還是 1：

Hashmode: 9300 - Cisco-IOS $9$ (scrypt) (Iterations: 1)
Speed.#1.........:    85331 H/s (122.39ms) @ Accel:16 Loops:1 Thr:8 Vec:1
* Hash-Mode 9300 (Cisco-IOS $9$ (scrypt)) [Iterations: 16384]
Speed.#1.........:    83890 H/s (1.76ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

再來是看 PBKDF2 類的，這邊先抓 9200 這組，可以看到 4090 的速度是 3090 的兩倍多：

Hashmode: 9200 - Cisco-IOS $8$ (PBKDF2-SHA256) (Iterations: 19999)
Speed.#1.........:   187.2 kH/s (91.61ms) @ Accel:16 Loops:256 Thr:1024 Vec:1
* Hash-Mode 9200 (Cisco-IOS $8$ (PBKDF2-SHA256)) [Iterations: 19999]
Speed.#1.........:   430.1 kH/s (60.71ms) @ Accel:16 Loops:512 Thr:512 Vec:1

另外 10900 這組也是兩倍多：

Hashmode: 10900 - PBKDF2-HMAC-SHA256 (Iterations: 999)
Speed.#1.........:  3785.4 kH/s (87.58ms) @ Accel:4 Loops:999 Thr:1024 Vec:1
* Hash-Mode 10900 (PBKDF2-HMAC-SHA256) [Iterations: 999]
Speed.#1.........:  8865.7 kH/s (50.50ms) @ Accel:64 Loops:124 Thr:512 Vec:1

考慮到單位價錢的效能，與單位功率的效能，4090 都是大幅領先的情況 (台積電幫了不少？)。