幹壞事是進步最大的原動力
在 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，連到專案頁面上時意外發現這兩個新的 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 的空間...
在 Hacker News 上的「Even Amazon can't make sense of serverless or microservices (world.hey.com)」這邊看到 DHH 抓到機會剛好戳了 AWS 的費用問題，不過讓我注意到的不是 DHH 的文章，而是在 Hacker News 上的留言 35823366，自稱是當時設計這個 serverless 架構的人出來解釋當時的確有壓力測試過，看起來也還 OK：
I actually designed the original serverless system (a few years back when I was still at Prime Video), and yes we did and it did sort of look like it could work until it didn't. Obviously wasn't the right solution for the scale we had in mind (or rather the type of problem we were working on) but it's sad to see the mistake of one team be used to justify shitting on serverless as a general solution.
但這是全新帳號的發言，拿這個 id 去找是可以翻到 TimboKZ 這個 GitHub 帳號，然後一路找也可以看到 Timur Kuzhagaliyev 的 LinkedIn 帳號，這個帳號裡面有提到 2019 到 2020 的時候在 Amazon 裡面當 SDE：
Worked on various computer vision projects as a part of Video Quality Analysis team at Prime Video.
是都符合沒錯，但還是不能完全肯定，目前看八卦的心態還是比較多...
先前在「Amazon Prime Video 捨棄 AWS Step Functions 回頭用 EC2 與 ECS 省錢的文章」這篇裡面有提到 Prime Video 團隊寫的文章，有點負面 PR 的感覺。
而讓人意外的是 Amazon.com 的 CTO Werner Vogels 也寫了一篇文章提到這件事情：「Monoliths are not dinosaurs」。
從標題可以看到他是針對 monolith 架構以及其他的架構在討論，而不是在講 AWS 成本問題 (這反而是原本 Prime Video 那篇文章在標題宣傳的)，另外也講了一些管理面上的東西，也就是文章裡面的副標題，以及兩段粗體字：
Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.
If you hire the best engineers, you should trust them to make the best decisions.
there is not one architectural pattern to rule them all.
至於算不算是提油... 就見仁見智了。
昨天在 Hacker News 上熱烈討論的文章，是一篇三月就放出來，但昨天被丟上來意外的熱烈討論，在講 Amazon Prime Video 的團隊改寫程式，把 AWS Step Functions 拔掉，並且回頭用 EC2 與 ECS 而省下大量 AWS 費用的文章討論：「Scaling up the Prime Video audio/video monitoring service and reducing costs (primevideotech.com)」，原文在「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」，Internet Archive 的備份、Archive Today 的備份。
先看文章的部分，裡面提到了他們用 AWS Step Functions，但意外的貴：
The initial version of our service consisted of distributed components that were orchestrated by AWS Step Functions. The two most expensive operations in terms of cost were the orchestration workflow and when data passed between distributed components.
然後改寫程式把所有東西都放在單一 process 裡面跑就好，用標準的 EC2 或是 ECS 就可以 scale 很好，而且也省錢：
To address this, we moved all components into a single process to keep the data transfer within the process memory, which also simplified the orchestration logic. Because we compiled all the operations into a single process, we could rely on scalable Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS) instances for the deployment.
可以看出起因是一開始設計時的 overdesign，把可以簡單處理的東西拆開，另外加上雲端在這塊收費特別貴而導致成本爆增... 這件事情偶而會發生，尤其是比較新的東西會沒注意到成本，通常在上線發現不太對的時候就會安排 refactor 掉。
但如果是 Amazon 自家集團的其他團隊出來抱怨，就有很棒的 PR 效果了，所以 Hacker News 上就看到有人在猜可能過不久後文章就會不見 XD (但文章紅了以後應該就不會不見 XD)：
My word. I'm sort of gob smacked this article exists.
I know there are nuances in the article, but my first impression was it's saying "we went back to basics and stopped using needless expensive AWS stuff that caused us to completely over architect our application and the results were much better". Which is good lesson, and a good story, but there's a kind of irony it's come from an internal Amazon team. As another poster commented, I wouldn't be surprised if it's taken down at some point.
很政治不正確的文章 XD
以之前的經驗來說，AWS 上類似的東西還包括了 NAT Gateway，這東西只適合在有強資安需求 (像是法規要求)，而且需要連外的流量很少的時候適合。
NAT Gateway 在新加坡 ap-southeast-1 要 $0.059/hr (美金，所以大約是 $42.48/mo)，以及 US$0.045/GB 的處理費用，所以假設你每天只有 100GB (平均 10Mbps)，就等於是 3TB/mo，要 $135/mo。這樣整包就 $172.48/mo 了。
如果讓 EC2 機器直接連去 internet 抓資料的話，這些費用就是 $0，你只要付無論是有 NAT Gateway 或是沒有 NAT Gateway 的 outbound traffic 費用部分 (大多是各種 TCP/TLS/HTTP header)。
比較省成本的解法是用 security group 對 outbound traffic 開放特定的流量來解。
另外一種方式還是 NAT，但是是自己架設 HA 的 NAT service，像是 2015 年的文章「The Right Way to set up NAT in EC2」提到的方法。
這個方法以現在的機種來說，兩台 t4g.nano 的機器加上 EBS 不到 $10/mo，唯一要注意的應該是網路頻寬雖然可以 burst 到 5Gbps，但他的網路頻寬是 credit 機制，當 credit 用完的時候 t4g.nano 記得是剩下 100Mbps 左右？不過真的有這個量的時候機器也可以往上開大一點...
另外還有很多「好用」的雲端服務，但看到帳單後就變得「不好用」的雲端服務... 在用之前先算一下成本就會發現了。
在 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 挖礦了...
Facebook 整理了一份他們採用 AV1 的記錄：「How Meta brought AV1 to Reels」，要注意這邊的產品線是短影片類型。
因為之前剛好也有碰到 codec 這塊，但最後是因為 AV1 在 client 的支援度還跟不上，而選了在 Android 上支援度更好的 VP9。
在文章前面有提到 server 端的需求，也就是 encoder 的部份，這是因為 AV1 的 encoding 真的很慢 (i.e. 外星技術)，還在每過幾個月就會看到 encoder 技術重大突破的階段，所以得花時間去研究。
Facebook 後來決定用 SVT-AV1，因為效能上好很多 (以他們測試的那個時間點)：
At any given point on the y-axis, SVT-AV1 can maximize encoding speed compared with any other production encoder. For example, the M8 preset is about as efficient as libvp9 preset 0, but M8 is almost 10 times faster.
而在 client 端的 decoder 部份，他們評估了 dav1d 與 libgav1 之後，選擇用 dav1d (iOS 與 Android 都是)：
Two major open source software decoders are compatible with multiple platforms: dav1d was developed by VideoLAN and the open source community and can serve as an app-level decoder, while Google’s libgav1 is integrated into the Android SDK.
[W]e decided to integrate dav1d into the player for both iOS and Android platforms.
但在軟解的情況下只能解 720p30，然後中高階的才能解 1080p30，不過這對於短影片來說夠用：
dav1d can support 720p30 real-time playback on most of the devices in our sample, achieving 1080p30 on certain mid-range and high-end models.
所以就 Facebook 目前提供的資料來看，這部份還沒到輕鬆應對的情況，還得繼續看各家 library 的進展...
Hacker News 上看到「Infinite-Storage-Glitch – Use YouTube as cloud storage for any files (github.com/dvorakdwarf)」這個討論，裡面的專案在 DvorakDwarf/Infinite-Storage-Glitch 這邊。
這種搞法有點像是以前 Love machine 的玩法，記得當年是和信這樣玩去塞爆 HiNet 跟 TWIX 中間的頻寬，算是老故事了。
看起來他的作法是透過 2x2 的黑白 pixel 儲存，然後讓 YouTube 壓縮，最終 YouTube 生出來的 mp4 檔案大概是四倍大：
Use the embed option on the archive (THE VIDEO WILL BE SEVERAL TIMES LARGER THAN THE FILE, 4x in case of optimal compression resistance preset)
另外真的是比較學術面的討論的話，有 Information hiding 這個主題 (不過這次這個專案沒在演)，在討論要怎麼「藏」資訊在媒體載體上。
不過現在有不少直接做免空服務的，這種方式算是好玩而已，「實用性」已經沒以前那麼高了。
在翻資料的時候翻到「Google Releases AOM-AV1 3.5 With More Speedups & Memory Optimizations」這篇，講 AOM-AV1 v3.5.0 的效能改善，看了 v3.4.0 的 changelog 可以看到最主要的大幫助是有 multithreading 的支援，但不確定跟其他的 AV1 library 相比可以有多快...
印象中 (好幾個月前的印象) 目前最快的應該是 SVT-AV1？記得 dav1d 有宣稱很快但不是 apple-to-apple 比較，比較像是 marketing 上的宣稱。
先前測試 AV1 在 Android 上的支援度與效能，記得在老一點的手機上軟解還是很辛苦啊，最後還是先選了 VP9 用，硬體解碼支援度比較廣，加上軟解需要的 CPU resource 也低不少。
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」這邊沒看到...