Tag: llama

Meta 的 Llama 3.1

Meta 發佈了 Llama 3.1：「Introducing Llama 3.1: Our most capable models to date」，這本來就只是個發佈而已，但讓我注意到的是 AWS 與 GCP 都同時宣佈在雲端上支援 Llama 3.1 了：

這代表 Meta 在 Llama 3.1 發表前就先跟 AWS & GCP 合作了，這看起來是一個包圍 OpenAI (以及微軟) 的姿態，之前好像沒看到這樣？(單純印象...)

用 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 就可以了：

原來 OSI 有寫過 LLaMA 的 license 不是 open source license 的宣告

Meta 的 LLaMA 宣稱是「The next generation of our open source large language model」，而 OSI 很早就有發文駁斥：「Meta’s LLaMa 2 license is not Open Source」。

在 OSI 的網站上可以看到「The Open Source Definition」，其中這條：

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

open source 不能限制使用，而 LLaMA 的授權限制了商業使用：

2. Additional Commercial Terms. If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion, and you are not authorized to exercise any of the rights under this Agreement unless or until Meta otherwise expressly grants you such rights.

前幾天翻車的 CKIP-Llama-2-7b 目前都已經下架了，但可以在 Archive Today 的「CKIP Llama 2 7b Chat - a Hugging Face Space by ckiplab」看到存檔頁面，以及在 Internet Archive 上的「GitHub - ckiplab/CKIP-Llama-2-7b: CKIP Traditional Chinese Llama-2」看到 GitHub 當時的頁面。

當時看到 CKIP-Llama-2-7b 宣稱用 Apache License, Version 2.0 放出來，我就「蛤？」了出來...

Anyway，雖然是其他原因被下架了...

不是 open source license 的 Falcon 180B 釋出

看到「Spread Your Wings: Falcon 180B is here」這個，Falcon 180B 釋出，號稱跟 LLaMA 2 站在同一個平台上，但目前看到的授權不是 open source license，大概就是留個記錄下來，實際上應該就不會去碰...

關於 license 的討論在 Hacker News 上有不少，可以參考：「Falcon 180B (huggingface.co)」。

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 的支援...

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

Falcon 40B 超越 LLaMA 65B 成為目前 Open LLM 的領頭

在 LLM 裡面講的 Open 不是 open-source license 的定義，比較接近「免費使用」而已，通常會帶有限制。

但即使放寬到「免費使用」，LLaMA 65B 從二月放出來 (或者說「被放出來」) 已經領頭領了三個多月了，直到上個禮拜看到被 Falcon 40B 超越的消息：

在「Open LLM Leaderboard」這邊的 benchmark 可以看到除了 TruthfulQA (0-shot) 以外，其他的都領先，而綜合平均值也是領先的：

而往下拉可以看到 7B 的版本表現也不錯，之後應該也可以再 tune。

更重要的是，剛剛看到這個 model 把授權改成 Apache License 2.0 的消息，這所以 LLaMA 的替代方案總算有樣子了：

另外看了一下，這包 model 是在 AWS 的 SageMaker 上面幹出來的，翻了一下 Technology Innovation Institute，真不愧是有錢的單位：

Falcon-40B was trained on AWS SageMaker, on 384 A100 40GB GPUs in P4d instances.

The Technology Innovation Institute (TII) is an Abu Dhabi government funded research institution that operates in the areas of artificial intelligence, quantum computing, autonomous robotics, cryptography, advanced materials, digital science,[4] directed energy and secure systems. The institute is a part of the Abu Dhabi Government’s Advanced Technology Research Council (ATRC).

在 Hacker News 上有人已經跑起來了，而且是透過 InstructGPT 調教過的版本：「Falcon 40B LLM (which beats Llama) now Apache 2.0 (twitter.com/thom_wolf)」，據說 4-bit quantized 版本可以在 40GB 的 A100 或是兩張 24GB 的 3090/4090 跑起來。

另外 ggml 的人應該這幾天就會動起來了，可以讓子彈再放著飛一下...

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 的空間...

llama.cpp 的載入速度加速

在 Hacker News 上看到「Llama.cpp 30B runs with only 6GB of RAM now (github.com/ggerganov)」這個消息，原 pull request 在「Make loading weights 10-100x faster #613」這邊。

這個 PR 的作者 Justine Tunney 在 PR 上有提到他改變 model 檔案格式，以便改用 mmap()，大幅降低了需要預先讀取的時間 (因為變成 lazy-loading style)，而且這也讓系統可以利用 cache page，避免了 double buffering 的問題：

This was accomplished by changing the file format so we can mmap() weights directly into memory without having to read() or copy them thereby ensuring the kernel can make its file cache pages directly accessible to our inference processes; and secondly, that the file cache pages are much less likely to get evicted (which would force loads to hit disk) because they're no longer competing with memory pages that were needlessly created by gigabytes of standard i/o.

這讓我想到在資料庫領域中，PostgreSQL 也會用 mmap() 操作，有點類似的概念。

另外 Justine Tunney 在這邊的 comment 有提到一個意外觀察到的現象，他發現實際在計算的時候用到的 model 內容意外的少：他用一個簡單的 prompt 測試，發現 20GB 的 30B model 檔案在他的 Intel 機器上實際只用到了 1.6GB 左右：

If I run 30B on my Intel machine:

[...]

As we can see, 400k page faults happen, which means only 1.6 gigabytes ((411522 * 4096) / (1024 * 1024)) of the 20 gigabyte weights file actually needed to be used.

這點他還在懷疑是不是他的修改有 bug，但目前他覺得不太像，也看不太出來：

Now, since my change is so new, it's possible my theory is wrong and this is just a bug. I don't actually understand the inner workings of LLaMA 30B well enough to know why it's sparse. Maybe we made some kind of rare mistake where llama.cpp is somehow evaluating 30B as though it were the 7B model. Anything's possible, however I don't think it's likely. I was pretty careful in writing this change, to compare the deterministic output of the LLaMA model, before and after the Git commit occurred. I haven't however actually found the time to reconcile the output of LLaMA C++ with something like PyTorch. It'd be great if someone could help with that, and possibly help us know why, from more a data science (rather than systems engineering perspective) why 30B is sparse.

如果不是 bug 的話，這其實冒出了一個很有趣的訊號，表示這些 model 是有可能再瘦身的？

Alpaca.cpp 有 13B 與 30B 的 model 可以玩了

在「Stanford Alpaca 與 Alpaca.cpp」這邊有提到 Alpaca 有放出 7B 的 model 可以用，後來 community 也照著同樣的方式訓練出對應的 13B 與 30B 的 model 了，在 Alpaca.cpp 專案的 README.md 有寫怎麼取得。

看起來比較大的限制是記憶體，13B 與 30B 的記憶體建議是 >10GB RAM 與 >32GB RAM，不知道剛好 32GB RAM 跑不跑得動，先拿 32GB RAM 的機器跑看看，如果真的不行的話家裡桌機是 64GB RAM，應該是不會有大問題...

不過 13B 的 model 檔案位置是放在 IPFS 上，透過這幾個 gateway 下載起來都有點慢，有需要的人用 BitTorrent 可能會快一點？

Update：測了一下 13B 的版本：

> Explain FAANG.
FAANG refers to five of America's largest technology companies - Facebook, Apple Inc., Amazon, Netflix and Google (Alphabet). These are some of the most valuable brands in today’s marketplace with a combined value that exceeded $3 trillion as at 2018.

以及 30B 的版本：

> Explain FAANG.
FAANG stands for Facebook, Amazon, Apple, Netflix and Google - five of the most powerful technology companies in today's world. These tech giants have become increasingly influential over recent years due to their dominance in various markets such as social media platforms (Facebook), e-commerce websites (Amazon) or streaming services (Netflix).