Intel Arc 顯卡在 Machine Learning 上的運算

前面提到「AMD 平台上的 LLM 計算」,在「Testing Intel’s Arc A770 GPU for Deep Learning Pt. 2」這邊看到另外一家也在追趕的 Intel 對於自家顯卡 Intel Arc 在 ML 上的運算。

文章裡面是透過 Intel 自家的 OpenVINO 以及微軟的 DirectML 在存取顯卡資源。

這張最大記憶體是 16GB,對於 ML 訓練算是堪用?

話說 Intel N100 主機把 OpenCL 弄好後也可以跑 KataGo,當然速度沒有獨立顯卡那麼快,但比起純粹用 CPU 計算的速度還是快不少...

雲端上面的 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 的空間...

透過 WebGPU 跑的 Web LLM

Simon Willison 這邊看到的玩法,透過 WebGPU 在瀏覽器上面直接跑 LLM 的 demo:「Web LLM runs the vicuna-7b Large Language Model entirely in your browser, and it’s very impressive」,專案在「Web LLM」這邊,可以直接玩。

不過要注意一下瀏覽器的支援度,如果是 Chrome 的話需要 113+,但目前 stable 還是 112;而 Firefox 的話我試過在 about:config 裡面用 dom.webgpu.enabled 打開 WebGPU 支援,但重開瀏覽器後還是跑不動?(也有可能是 Linux 環境的關係)

Update:應該是 Linux 環境的關係,我在 Linux 下用 dev channel (114) 也不行。

話說有 WebGPU 後是不是開始要擋 GPU 挖礦了...

美國政府禁止 NVIDIA 將高階顯卡輸出到中國與俄羅斯

Hacker News 首頁上看到「US Government Bans Export of Nvidia A100 and H100 GPUs to China and Russia (sec.gov)」這篇,是 NVIDIA 發出了 Form 8-K,說明美國政府禁止 A100 與 H100 或是更高階 (更快) 的卡以及產品輸出到中國 (包括香港) 與俄羅斯:「nvda-20220826.htm」。

先是指出 A100、H100 以及 A100X (Ampere) 被管制:

On August 26, 2022, the U.S. government, or USG, informed NVIDIA Corporation, or the Company, that the USG has imposed a new license requirement, effective immediately, for any future export to China (including Hong Kong) and Russia of the Company’s A100 and forthcoming H100 integrated circuits. DGX or any other systems which incorporate A100 or H100 integrated circuits and the A100X are also covered by the new license requirement.

另外是禁止新產品的部份,效能與 A100 相等或是更好的卡也被禁止輸出,除非有取得授權:

The license requirement also includes any future NVIDIA integrated circuit achieving both peak performance and chip-to-chip I/O performance equal to or greater than thresholds that are roughly equivalent to the A100, as well as any system that includes those circuits.

然後有提到軍事相關考量:

A license is required to export technology to support or develop covered products. The USG indicated that the new license requirement will address the risk that the covered products may be used in, or diverted to, a ‘military end use’ or ‘military end user’ in China and Russia. The Company does not sell products to customers in Russia.

有看到一些報導指出 AMD 也有收到類似的禁令 (畢竟也是個顯卡大廠),但在「SEC Filings」這邊沒看到...

Raspberry Pi 4 將可以透過有線網路安裝系統了

在「Raspberry Pi 4 to support Network install to a blank MicroSD card」這邊看到 Raspberry Pi 4 將可以透過有線網路安裝系統了:

The Raspberry Pi 4 will soon be able to install Raspberry Pi OS without the need for external hardware to flash the image.

先前都是透過其他機器先刷好 SD card 再放進去開機,之後可以透過有線網路直接裝,讓步驟簡單一些... 另外有提到這次會支援的只有 RPi4 與 CM4 機種,先前的版本還是得透過其他機器生出可開機的 SD card:

The Raspberry Pi Foundation simply changed the bootloader code to enable the Network install feature, and yes, it will only work with Raspberry Pi 4, CM4, and Raspberry Pi 400 keyboard PC, but not Raspberry Pi 3 and earlier models.

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1,專門為影片壓縮而推出的 family type:「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速,號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%):

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台?另外專利的費用不知道怎麼算...

Stripe 原來支援 JCB 了啊...

剛剛在買東西的時候故意丟 JCB 的卡號進去,發現 Stripe 認得,找了一下公告資料,發現是去年 2020 年五月支援的:「Expanding support for JCB payments」。

先前在日本買 Live 物販的時候 (2019 年年底,應該是 H-el-icalSee-Saw 這兩場),看到現場是使用 iPad + Stripe 的組合,一開始還驚訝了一下,但被告知不支援 JCB 的時候心裡「...」了一陣子,只能刷 Mastercard 或是 Visa

看起來在去年推出的時候,日本地區是自動開放:

Businesses using Stripe in Japan can now automatically accept payments with JCB, in most cases without any additional work.

其他地區則是逐步開放:

We are rolling out JCB acceptance to businesses in more countries, starting with Canada, Australia, and New Zealand, with more to come. This lets global businesses, from e-commerce sites in Canada to subscription services in Australia, easily transact with JCB cardholders.

如果 2022 年有機會去日本的話,應該會看到更多使用 Stripe 的方案了...

Visa 網站上面的 Opt-Out 功能被拿來玩 Timing Attack...

Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out,本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個),但最上面的討論居然是在討論 timing attack,像是這篇:

morpheuskafka 2 days ago [–]

Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.

For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.

我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack),討論裡面有提到「Exploiting remote timing attacks」這篇,也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD

不過 Visa 的這個網站前面用了 Cloudflare,用機器人掃感覺很容易被擋,這又是另外一回事了...

在 Hacker News 上看到 Raspberry Pi 400 使用心得

Hacker News 看到 Raspberry Pi 400 的使用心得:「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」,先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400,主要就是一台 Raspberry Pi 4 Model B 的主機,但跟鍵盤整合在一起。

在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇),主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD),這一直都是 Raspberry Pi 上面用 SD card 的問題,看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。

If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.

另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度,不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向,本來就有取捨,不太可能什麼都做進去...

回到作者的心得,雖然 USB3 轉 SSD 看起來 i/o 速度快不少,但我好像主要不是遇到 i/o 速度問題,反倒是最近 chromium 的硬體解碼好像有些進度,也許看影片有機會用硬體處理 (至少一部份?),希望至少可以輕鬆看 1080p60 啊...