AMD 推出 16GB 的 RX 7600 XT

看到「AMD Unveils AMD Radeon RX 7600 XT Graphics Card – Incredible Gaming at 1080p and Beyond for Under $350」這篇,16GB VRAM 官方的定價在 US$329...

剛好昨天寫的「Mixtral 8x7B 的論文出來了」提到了 Nvidia 的 3060 Ti 的 16GB 版本是跑 LLM 的窮人選擇,因為 12GB VRAM 的卡官方訂在 US$329,目前售價大約在 NT$9000 (~US$300) 左右。

這次 AMD 這張 16GB VRAM 美國定價是 US$329,剛好跟 3060 Ti 12GB 版本相同,這下 entry level 的市場就瞬間變得有趣了起來,雖然說 AMD 這邊的軟體支援度是差了一些,但最近算是急起直追,對於想要追求 CP 值的群眾來說還蠻有吸引力的?

後續來追看看台灣的售價...

Mixtral 8x7B 的論文出來了

Hacker News 上看到 Mixtral-8x7B-v0.1 以及 Mixtral-8x7B-Instruct-v0.1 的論文出來了:「Mixtral 8x7B: A sparse Mixture of Experts language model (arxiv.org)」,arXiv 上的連結:「Mixtral of Experts」。

跟先前大家從公開資料研究的差不多,這個研究成果主要不是降低參數的大小,而是降低運算的量:

As a result, each token has access to 47B parameters, but only uses 13B active parameters during inference.

然後仍然是超越 GPT-3.5 的水準:

Mixtral was trained with a context size of 32k tokens and it outperforms or matches Llama 2 70B and GPT-3.5 across all evaluated benchmarks.

先看計算量的問題,Mixtral 8x7B 的 model 對 VRAM 要求仍然不是消費級 GPU 可以達到的,對一般家用電腦來說,還是需要 quantisation 降低精度換取對 VRAM 空間的壓力下降。

這點可以在 TheBloke/Mixtral-8x7B-v0.1-GGUF 這邊看到各種 quantisation 後需要的 VRAM 大小。

如果用 CPU 計算的話目前應該不是大問題,目前 LLM 的大小對於一般主機的 RAM 來說還不是問題 (單條 32GB,四條就有 128GB 了),加上現在 llama.cpp 主力已經是用 mmap 的方式在存取檔案,filesystem cache 可以在多次執行中重複使用,只是用 CPU 就不能對速度有太多想法了。

但如果往 GPU 這邊看的話就得取捨了,目前 GPU 中能跑 Mixtral 8x7B 最便宜的方案應該是兩張 3060 12GB 組成 24GB VRAM,一張約 NT$9k (~US$300),兩張約 NT$18k (~US$600),這樣的話有機會跑 mixtral-8x7b-v0.1.Q3_K_M.gguf,不過這邊寫「very small, high quality loss」。

如果 mixtral-8x7b-v0.1.Q3_K_M.gguf 的品質不能接受,希望計算品質好一點的話,三張 3060 Ti 12GB 組 36GB VRAM 的方案約 NT$27000 (~US$900),不過主機板可能要挑一下;這樣就有機會用需求 34.73 GB VRAM 的 mixtral-8x7b-v0.1.Q5_K_M.gguf 了,評語是「large, very low quality loss - recommended」。

最後岔題,剛剛算了一下成本,發現 3060 Ti 12GB 這張還是穩穩的 LLM 窮人卡,先前在「雲端上面的 GPU 資源費用,以及地端的 GPU 決策圖」這邊提到的決策圖,即使在 2023 年七月 4060 Ti 16GB 出了以後還是很好用... (約 NT$15k,~US$500)

Georgi Gerganov 給了在 AWS 上面用 GPU instance 跑 llama.cpp 的說明

Georgi Gerganov 寫了一篇怎麼在 AWS 上面用 GPU instance 跑 llama.cpp 的說明:「Using llama.cpp with AWS instances #4225」。

先跳到最後面的懶人套件,直接提供了 shell script 幫你弄完:

bash -c "$(curl -s https://ggml.ai/server-llm.sh)"

回到開頭的部分,機器的選擇上面,他選了一台最便宜的 4 vCPU + 16GB RAM + 16GB VRAM 的機器來跑。

然後他提到了 OpenHermes-2.5-Mistral-7B 這個模型最近很紅,也許有機會看一下:

We have just 16GB VRAM to work with, so we likely want to choose a 7B model. Lately, the OpenHermes-2.5-Mistral-7B model is getting some traction so let's go with it.

用 llama.cpp 裡面的 server 跑起 API server:

./server -m models/openhermes-7b-v2.5/ggml-model-q4_k.gguf --port 8888 --host 0.0.0.0 --ctx-size 10240 --parallel 4 -ngl 99 -n 512

接著就可以用 cURL 測試:

curl -s http://XXX.XXX.XXX.XXX:8888/v1/chat/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer no-key" \
    -d '{
        "model": "gpt-3.5-turbo",
        "messages": [
            {
                "role": "system",
                "content": "You are ChatGPT, an AI assistant. Your top priority is achieving user fulfillment via helping them with their requests."
            },
            {
                "role": "user",
                "content": "Write a limerick about python exceptions"
            }
        ]
    }' | jq

都包好了...

用 llama.cpp 玩 Mistral 7B Instruct,補一下 llama.cpp 的發展

看到「Workers AI Update: Hello Mistral 7B」這篇想到的,先前有提到「號稱目前最強的 Mistral 7B」,加上有一陣子沒看 llama.cpp 最近的發展,跳下去重新測試時發現有不少進展。

一個比較大的進展是 llama.cpp 推出 gguf 格式,取代之前的 ggml 格式。

新的格式可以想像是在檔案裡面放了通用性的 feature flag,就不會遇到新的 model 用到新的方法,沒辦法在 ggml 裡面指定 + 新增 feature,就得把 llama.cpp 整包 fork 拉出出去大改。

這差不多是三個月前的事情,蠻多 model 都已經支援了,像是 maddes8cht 這邊就整理了很多 OSL model (open source license) 可以直接下載下來用,不需要自己轉檔。

像是 Falcon 40B 與標題提到的 Mistral 7B,以及對應的 Instruct 版本 Mistral 7B Instruct 都有轉好的檔案可以下載。

另外一個有趣的功能是 llama.cpp 有了輸出 embedding 的能力,在編完後會多了一個 embedding 執行檔可以用;原來的主程式 main 也還在。

往 git repository 裡面看了一下記錄,差不多是在今年三月就已經有的功能,然後九月加到 README.md 裡面說明。

在蠻多情況下 embedding 輸出 vector 會比輸出 string 好用很多,像是相似度、推薦、語意分析這些計算;拿到 vector 後就算沒有專門的系統處理,用個 PostgreSQL 搭個能進行 vector 計算的 plugin 也就可以弄出不少東西了 (像是 pgvector)。

不過會用 embedding 的人應該早就用 PyTorch 或是其他工具,直接拉出來用了,llama.cpp 支援輸出 embedding 算是有趣但沒有到重要?

然後是支援 OpenCL,這個功能讓不少非 Nvidia 的平台可以利用 GPU 資源加速,像是 AMD 的顯卡,以及一些嵌入式系統,這點對於 llama.cpp 當初的目標就蠻有幫助的...

回到 Mistral 7B Instruct,其實小模型還是小模型,我問個演算法的題目:

./main -m models/7B/mistral-7b-instruct-v0.1.Q8_0.gguf -t 1 -ngl 32 -p '請給出一個 python 寫的 fibonacci sequence 演算法,需要 O(log(n)) 的時間複雜度。'

輸出長這樣:

 請給出一個 python 寫的 fibonacci sequence 演算法,需要 O(log(n)) 的時間複雜度。

```python
def fib_seq(n):
    return get_fibonacci(n, 0, 1)


def get_fibonacci(n, a=0, b=1):
    if n == 0:
        return []
    if n == 1:
        return [a]
    fib_seq = [a]
    for i in range(1, n):
        fib_seq.append(get_fibonacci(i, b, a + b)[0])
    return fib_seq
``` [end of text]

ChatGPT 的話可以給出一個正確的演算法,這邊只需要 ChatGPT-3.5 的 model 就可以了:

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