用 2024 年的技術花 US$20 嘗試重建當年 OpenAI 的 GPT-2 (124M)

GPT-2 出來的 2019 年 Nvidia 的家用顯卡應該是 2080 Ti (2018/09/27),抓一下感覺。

在「Reproducing GPT-2 in llm.c (github.com/karpathy)」這邊看到 Andrej Karpathy 試著重建 GPT-2 的計畫,雖然是最小的 model (124M),不過這邊可以注意到當年最小是 117M,其實有一點差距 (大約多了 6%):

Two other smaller releases of GPT-2 are available, including the small version of 117M parameters and the medium size of 355M parameters. Both are available to download from Huggingface.

另外維基百科上面可以看到 OpenAI 發表 GPT-2 的時候他不在 OpenAI

OpenAI (2015–2017, 2023-2024)

但畢竟曾經是 OpenAI 裡面的老大,能看到的資料總是比外面的人多不少 (加上 GPT-2 屬於過時的技術,管制上應該會鬆不少?),這也是為什麼大家會關注的原因。

這次的嘗試不是完全重現,因為當初 GPT-2 的 training data 並沒有公開,所以他只能找個接近的 data set 訓練,這代表這次不是完全與 GPT-2 相同的情況下重建:

it was trained on the never released "WebText" dataset

雖然知道軟硬體的成長速度頗快 (畢竟整個產業的錢都往這邊丟進去),不過發現用現在的技術只要 US$20 就可以重現最小的 model 還是讓人有點驚訝:

With llm.c, which is quite efficient at up to ~60% model flops utilization, reproducing this model on one 8X A100 80GB SXM node takes ~90 minutes.

理論上同樣的 code 改一些參數也就可以訓練出比較大的幾個 model?

Vector embedding

最近累積起來的東西,都跟 vector embedding 有關,第二篇甚至有提到透過 embedding 切入可以找到不少 LLM 有趣的使用方式:

自己編 llama.cpp 的時候會產生出 embeeding 這隻程式,就可以測試把文字轉成 vector 的功能,接著就可以套用高維空間的數學運算了,像是最常被提到的是利用兩個 vector 的夾角來判斷相似度。

因為是對一堆 vector 處理,就不太需要去管輸出格式的問題 (像是 ChatGPT 會自由輸出任何東西),對程式開發上會方便不少...

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)

微軟 Phi-2 model 的授權改成 MIT License

Hacker News 的「Microsoft Phi-2 model changes licence to MIT (huggingface.co)」這邊看到的消息,連結是改成 MIT License 的 commit:「Upload 3 files · microsoft/phi-2 at 7e10f3e」。

看了一下 model 的參數是 2.7B,宣稱在 13B 以下 model 中是前段班:

Phi-2 showcased a nearly state-of-the-art performance among models with less than 13 billion parameters.

再回頭查一下這段宣稱的時間,當初發表的時間是 2023/12/12:「Phi-2: The surprising power of small language models」。

應該是希望在行動裝置上用更少的運算量達到效果...

另外找了一下 GGUF 格式,看起來 TheBloke/phi-2-GGUF 這邊已經有轉好的了,可以直接上 llama.cpp 跑。

JavaScript 的分號,以及 ASI (Automatic Semicolon Insertion)

目前 community 的主流跟我理出來的期望不一樣... 所以記錄一下。

先提一下背景,在 JavaScript 程式語言裡面,在大多數的情境下是可以省略掉分號 (;) 的,也就是說這兩種寫法都是合法的 JavaScript 語法:

console.log('Hello, world.')
console.log('Hello, world.');

這是因為在 ECMA-262 裡面有 ASI (Automatic Semicolon Insertion) 的設計:「Automatic Semicolon Insertion」。

ASI 設計本身是好的,可以讓開發者少處理 ;,但偏偏 EMCA-262 又允許千變萬化的換行,於是就造成了各種奇怪的現象。

因此早期在 community 上都是推薦無條件加上分號,這可以避免各種奇怪的 bug 與 error,像是「Do you recommend using semicolons after every statement in JavaScript?」以及「Should I use semicolons in JavaScript?」這些問答。

大家會推薦加上分號主要的原因是因為,不加上分號遇到的 error 與 bug 不是那種你知道很雷,所以會主動查詢 & 避開的問題:

而是各種平常寫就會遇到的情況,最容易中獎的是第二組敘述是 ([ 開頭的,像是 ECMA-262 文件裡面提到的 case 就算常見了:

a = b + c
(d + e).print()

// 等價於:
a = b + c(d + e).print();

而且不因為註解受到影響:

// blahblah
a = b + c

// blahblah
(d + e).print()

// 還是等價於:
a = b + c(d + e).print();

另外一個常見的情況是我們會利用 anonymous function 包出一個 block,避免變數污染到外面:

// I want to do blahblahblah...
(() => {
  const a = '';
  // ...
})()

// I want to do another blahblahblah...
(() => {
  const a = '';
  // ...
})()

大多數的情況應該會 error,除非第一個 anonymous function 傳回一個 callable,而這種情況跑出來的結果就更慘了...

另外這種 case 也是常見的情況:

// ...
[1, 2, 3].forEach(...)

// ...
[4, 5, 6].forEach(...)

// 等價於:
[1, 2, 3].forEach(...)[4, 5, 6].forEach(...)

這邊省略分號最大的問題是你無法知道「自己這行需不需要加上分號」,因為註解可能很長有個 30 行,所以依照這些現況,比較好的方法應該是全部加上分號,保持一致性。

但這幾年所有的 frontend framework 都是推動拿掉分號,這可以從各家的文件看到,就搞不懂 community 是怎麼推導出來的... 在全部都拿掉分號的情況下,遇到上面的情況就得寫成不一致的 style:

// ...
[1, 2, 3].forEach(...);

// ...
[4, 5, 6].forEach(...)

查了目前可行的 workaround,大多都是透過 ESLint 類的工具來擋可能會出現 bug 的地方,也只能先這樣做了...

漢字字形的處理

Hacker News 上看到「Your Code Displays Japanese Wrong (heistak.github.io)」這篇,原文是「Your Code Displays Japanese Wrong」。

這個算是 CJK 族群的經典問題,主要的問題是有不同的團體都在使用漢字,但雖然都是 U+5203 的「刃」,在不同的地區的「標準寫法」是不一樣的,像是「國家教育研究院 - 教育部國語小字典-刃」這邊就有 SVG 版本的「圖」可以看:

我在 different-lang.html 這邊把他提到的「刃直海角骨入」給放了進去,指定不同的 lang,像是這樣:

<dt>lang="jp"</dt><dd lang="jp">刃直海角骨入</dd>

如果你的電腦裡面有 Noto Sans CJK 的話,應該可以看出不同的字形。

在 HTML 網頁上可以利用 html 內的 lang 資訊告訴瀏覽器去抓取對應的字形,當然,系統有沒有這個字形又是另外一回事了,不過市場上至少有 open source license 的 Noto CJK 系列,算是個低標的答案可以用。

至於要更多樣的話,應該是要分不同語言下去找...

一個檔案直接跑起大型語言模型的 llamafile

llamafile 是昨天很紅的一個專案,由 Mozilla Internet Ecosystem (MIECO) 弄出來的專案,可以使用一個檔案直接跑起大型語言模型的 HTTP server,讓你可以在瀏覽器裡面直接使用。

直接看官方的 README.md 就可以蠻簡單的跑起來,不過 Simon Willison 也有寫一篇文章介紹一下,可以看看:「llamafile is the new best way to run a LLM on your own computer」。

這邊說的「一個檔案」是指同一個檔案同時可以在 WindowsmacOSLinuxFreeBSDOpenBSD 以及 NetBSD 上面跑,而且這個檔案也把大型語言模型 (LLM) 的 model 檔案包進去,所以檔案會蠻大的,但畢竟就是方便讓人使用:

下載下來直接執行,預設就會在 port 8080 跑起來,可以直接連到 http://127.0.0.1:8080/ 連進去使用。

llamafile 用到的技術是 Cosmopolitan 專案,可以把多個平台的執行檔包在同一個檔案裡面使用。

另外用到的專案是 llama.cpp,這個蠻多人都用過了,可以很方便的用 CPU 或是 GPU 跑 LLM。

我在 Linux 上面跑剛好遇到幾個問題,都是在 README.md 上面有提到的。

第一個是 zsh 無法直接跑 llamafile (Ubuntu 22.04 內建 zsh 的是 5.8.1),這邊官方的建議是用 sh -c ./llamafile 避開:

If you use zsh and have trouble running llamafile, try saying sh -c ./llamafile. This is due to a bug that was fixed in zsh 5.9+. The same is the case for Python subprocess, old versions of Fish, etc.

另外一個對是 GPU 的支援,這邊跟你說加上 --n-gpu-layers 35 就可以用,所以一開始先用 sh -c ./llamafile --n-gpu-layers 35 試著跑:

On Linux, Nvidia cuBLAS GPU support will be compiled on the fly if (1) you have the cc compiler installed, (2) you pass the --n-gpu-layers 35 flag (or whatever value is appropriate) to enable GPU, and (3) the CUDA developer toolkit is installed on your machine and the nvcc compiler is on your path.

但可以看到沒有被 offload 到 GPU 上面:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  = 4165.47 MB
llm_load_tensors: offloading 0 repeating layers to GPU
llm_load_tensors: offloaded 0/35 layers to GPU
llm_load_tensors: VRAM used: 0.00 MB

嘗試了不同的方法,發現要跑 sh -c "./llamafile --n-gpu-layers 35",也就是把參數一起包進去,這樣就會出現對應的 offload 資訊,而且輸出也快很多:

llm_load_tensors: ggml ctx size =    0.11 MB
llm_load_tensors: using CUDA for GPU acceleration
llm_load_tensors: mem required  =   70.42 MB
llm_load_tensors: offloading 32 repeating layers to GPU
llm_load_tensors: offloading non-repeating layers to GPU
llm_load_tensors: offloaded 35/35 layers to GPU
llm_load_tensors: VRAM used: 4095.05 MB

玩了一下像是這樣:

InfluxDB 好像又在搞事了:從 Golang 換 Rust

在「Influxdb made the switch from Go to Rust (reddit.com)」這邊看到 RedditInfluxDB 的 CTO 出來的解釋:「influxdb officially made the switch from Go => Rust」。

可以看到 Hacker News 上的討論很多人都有提到 InfluxDB 的各種問題,而且在量還不大的時候就會遇到了。

這次 Golang 換成 Rust,依照 InfluxDB CTO 的說法有這些「優點」:

  • No garbage collector
  • Fearless concurrency (thanks Rust compiler)
  • Performance
  • Error handling
  • Crates

不過如果在 Golang 沒辦法解決 scalability 的問題 (通常需要 profiling 找出熱點然後改善演算法),Rust 這邊遇到一樣的問題應該也是一樣炸裂...

另外這家公司先前也出過事,七月的時候 InfluxDB 把比利時區的服務給關掉,但有不少客戶因為種種原因沒有收到通知,加上他們是直接 hard shutdown (沒有備份資料),造成 InfluxDB Cloud 的企業用戶直接幹翻天:「InfluxDB Cloud shuts down in Belgium; some weren't notified before data deletion (influxdata.com)」。

基本上可以閃遠一點... 目前看到的替代方案有 TimescaleDB (在 comment 裡有看到一些抱怨) 與 Clickhouse (在這篇的 comment 討論的比較少)。

號稱目前最強的 Mistral 7B

Hacker News 上看到「Mistral 7B (mistral.ai)」,Mistral 7B 是目前號稱最強的 7B model。

宣稱在所有項目超越 Llama 2 13B,以及在許多項目超越 Llama 1 34B:

Outperforms Llama 2 13B on all benchmarks
Outperforms Llama 1 34B on many benchmarks

很重要的是以 open source license 放出來的,選的是 Apache License, Version 2.0

We’re releasing Mistral 7B under the Apache 2.0 license, it can be used without restrictions.

這個 model 大小是可以用 CPU 跑的,馬上就有人推 patch 進 llama.cpp 了:「Added the fact that llama.cpp supports Mistral AI release 0.1 #3362」。

我記得 Llama 2 13B 的輸出結果還有點微妙,但如果說是全部都超過的話,也許可以期待看看品質...