VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡,兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet,這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet,但我希望 VM 是走社區網路,所以用 bridge mode 設定到網卡上,用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到,前幾天用 Line 傳照片的時候很慢 (之前就有發生了,一直忘記去追問題),花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢,這點可以從 Speedtest 的測試結果看到:

先講最後的結論,在交叉測了很多組合後,我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled

回到當時抓問題的情況,當時先用筆電與 host 測試都沒看到問題,所以看起來應該是 VM 裡面的狀況,但不確定是什麼情況,畢竟不是斷掉...

由於下載速度正常,只有上傳速度卡住,一開始想到的是跟 MTU 相關的問題,所以找了指令降到 1400 後測試,還是一樣...

後來先把 VM 的網路改成 NAT,再測試上傳速度就正常了...

接著想要換個網路卡類型看看,結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了,但想說先去看看 Windows 10 網卡設定裡面的設定,結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗?)。

然後一關就正常了,交叉再開關兩次確認這個參數有影響,就肯定這個 workaround 應該是有效了...

另外在自己找完問題後,在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

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 跑。

一個檔案直接跑起大型語言模型的 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

玩了一下像是這樣:

號稱目前最強的 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 的輸出結果還有點微妙,但如果說是全部都超過的話,也許可以期待看看品質...

問 LLM 台灣是不是獨立國家...

Hacker News 上看到「Comparing 60 LLMs with a set of 20 prompts (llmonitor.com)」這篇 (看到的時候在第一名),原文在「Asking 60+ LLMs a set of 20 questions」這邊。

作者寫了 20 個問題讓一堆 LLM 回答,把回答的結果以及時間記錄起來,其中看到「Is Taiwan an independent country?」這個問題,共有 54 個 LLM 的結果,可以看到各家 LLM 的回答。

作者雖然註解解釋這題的回答是「是」(Note: Correct answer: yes it is.),但考慮到訓練的語料,大多數的回答都會提到全世界的政治情勢,或是帶出「這個問題很複雜」的說明。

不過我就是想看其他類型的回答 XD

直接拒絕回答,出現空白的有 Code Llama Instruct (7B)、Dolly v2 (3B)、Dolly v2 (7B)、Falcon Instruct (7B)、Koala (13B)、Luminous Supreme Control、Vicuna v1.3 (7B)。

然後出現沒意義的輸出的是 Vicuna v1.5 (13B),這邊丟出 48 行的 <bot>:,沒有其他內容。

另外一個頗歡樂的回答是 Vicuna v1.3 (13B),直接出現簡體中文回答的,而且獨立了 XDDD

台湾是一个独立的国家。

這邊 Koala 與 Vicuna 系列的都是 LMSYS 的作品,這邊的學生團隊 (Student Team) 都是華人名字:「About | LMSYS Org」,可能是丟了不少中文資料進去才會冒出簡體中文的回答?

另外一個有趣的是 Databricks 的 Dolly v2 (12B) 的回答直接說「不是」,沒有人和其他解釋:

<bot>: No.

而 Dolly 在專案頁面上有提到是基於 pythia-12b

Based on pythia-12b, Dolly is trained on ~15k instruction/response fine tuning records databricks-dolly-15k generated by Databricks employees in capability domains from the InstructGPT paper, including brainstorming, classification, closed QA, generation, information extraction, open QA and summarization.

不過回頭看同樣是 Pythia 家系的 Open-Assistant Pythia SFT-4 (12B),他的回答是:

<bot>: Yes, Taiwan is an independent country.

以及 Pythia-Chat-Base (7B) 的回答:

Yes, Taiwan is an independent country.

所以 Databricks 怎麼 train 的,把 pythia 的結果直接反過來 XDDD

不是 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)」。

日本 LINE 推出的 LLM (以日語材料訓練)

看到「36億パラメータの日本語言語モデルを公開しました」這篇,日本的 LINE 丟出 Apache License 2.0 的 LLM,拿起來跑看看還蠻有趣的:

他的特點是用日語資料訓練出來的 LLM:

最終的な学習には約650GBのコーパスを利用していますが、英語の大規模コーパスとして一般的に用いられているもの(Pileコーパス)が約800GBであることを踏まえると、我々のデータも遜色ない大きさであると言えます。

我拿 1.7B 跑,小修改一下故意給英文的 prompt 後,可以看到輸出頗有趣的,畢竟是從日文資料訓練出來的:

{'generated_text': 'An apple a day keeps the doctor away.\n「一日リンゴ1個」は apple days で'}
{'generated_text': 'An apple a day keeps the doctor away thinking happier. The biggest happ'}
{'generated_text': 'An apple a day keeps the doctor away from here.」と英語で訳しましょう。「I have a dream'}
{'generated_text': 'An apple a day keeps the doctor away(sometimes usually thinks far a'}
{'generated_text': 'An apple a day keeps the doctor away. 日はまたのぼり、 医者は去って行った。 They'}
{'generated_text': 'An apple a day keeps the doctor away thought about being in the center of the'}
{'generated_text': 'An apple a day keeps the doctor away from all the time.\n16. I feel like'}
{'generated_text': 'An apple a day keeps the doctor away and draws and eats around one table'}
{'generated_text': 'An apple a day keeps the doctor away from your mother\nAnd another male you are'}
{'generated_text': "An apple a day keeps the doctor away. What's the opinion you wrote in"}

這邊有訓練的運算量計算,1.7B 的 model 訓練換成起來會用道 4000 小時的 A100 80GB (假設你有 100 張的話,就是 40 小時):

本モデルの構築に要した時間について、例えば1.7BモデルについてはA100 80GBで換算し、約4000GPU時間を費やしています。学習時間は特に日本語の大規模言語モデルの学習では公開されていないことが多く、適切な比較はできませんが、例えば rinna 0.3Bモデルの学習はV100 32GBで約8600GPU時間を費やしているようで、費やした時間に比して効率の良い学習が行えていると考えられます。

目前是提到有計畫要放出 instruction tuning 的版本:

また、これらのモデルについて、指示文に対して適切な出力を行えるようにチューニング(Instruction tuning)したモデルを近日中に公開予定です。続報は@LINE_DEVをフォローしてお待ち下さい。

這個 LLM 先記起來,以後也許在其他場景有機會用到?

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 顯卡在追趕的過程,社群的力量看起來會是主力...