Kobo Libra 2 をしばらく前から使っている。最近でたカラーのやつではなく、一世代前。
感想。
- 今更ながら e-Reader は良い。Boox のような Android デバイスと違って読むしか出来ないぶん、読むのが捗る。(ただし読むものがどれだけあるかというと、後述。)
- 軽いのも良い。自分が持っている 10-inch の Boox (Note) は、ごろ寝しながら読むには重すぎた。ただし Libra 2 の 7 インチの画面では論文の PDF は読めない。つまり論文はゴロゴロしながら読めないわけですね。まあ仕方なし。
- 書店としての Kobo の品揃えは、悪い。Amazon より悪いのは仕方ないとして Play Books よりも悪い気がする。そして高い。(あとウェブストアの UI は最悪だが、それは期待値の範囲内。)
- かわりに図書館で本が借りられる(Libby)。特定の読みたいものを探すとほぼ借りられているが、なんか読むものないかなーと探すと何かはある。なおこれは Kindle にもある。
- Pocket 対応。期待していたが、残念ながらゴミだった。ウェブサイトの scrape 失敗率が高すぎて、読みたいものを全然 Pocket に取り込めない。これは Kobo ではなく Pocket の問題。Instapaper と比べ scraper の出来が悪すぎ。ショックを受けた。無能とかではなく何らかの意向が働いているとしか思えない。なお Kobo 側にも問題があり、画像がよく欠落している。JPEG 以外を表示できないらしい。
- ハードウェアは良い。特に不満なし。
当初の目論見としては Pocket 経由でウェブが読めたらいいなと思っていたがそのあては完全に外れ、じゃあ本でも読むかと自分の仮想積読リストのうち Kobo で売っているものを選んで買って読んでいる。
他人に勧めるかというと、ノーだね。予想にたがわずたぶん Kindle の方がいい。なにしろ本がなんでも売っているので。Instapaper も対応してるし(有料機能だけど)。Kobo ストアの品揃えのしょぼさと Pocket の出来の悪さには本当にがっかり。特に後者。俺の中二病は今回も不発だったぜ・・・。
ほとぼりが冷めた頃に Kindle でも買おうかな、とサイトを眺めたら Kindle Oasis はディスコンなのか。Libra 2, ハードウェアの出来はいいのでほんとに残念。まあ年が明けた頃にでも考え直します。
Pocket は Mozilla の子会社なのだから Firefox だとちゃんと動くとかあるのでは？と思ったら Firefox Android に Pocket integration はないらしい。その Reader mode で作った HTML を Pocket に入れてくれればいいのよ?? アホなの？？？自分のような heavy Chrome user を転向させる機会をみすみす逃すとは、お前ら競合の悪口いう前にやるべきこと色々あんだろ。
はー Pocket が最低限の仕事をすればこの Libra 2 は素敵な Web reading 端末になるというのに、あんまりだわ。
Flash Attention や 教科書のTiled Matmul を読んで意外だったのは、これらが単一の Streaming Multiprocessor の上で実装されていることだった。Triton もそういう実装を想定し, Per-SM というか Per-ThreadBlock の実行モデルを持っている。
SRAM に tile を載せたい動機を考えると当然といえば当然だけれど、古いコンピュータ・グラフィクスの世界観で理解している GPU とは随分違って、自分のメンタルモデルを書き直す必要を感じた。
古いコンピュータグラフィクスの世界では、SM とか ThreadBlock みたいのは実装の詳細であり、プログラマは気にしない。GL のシェーダにも (compute shader は別とすると) 基本的には SRAM/SHARED みたいな概念はない。個々の WARP も独立して動き、syncthread() とかもない。
したがってグラフィクスの世界では GPU のスループットを増やせば頂点やピクセルが十分にある限り自動的に計算資源を使い切れる。GPU のスケールの仕方はあまり気にしない。SM の数が増えても SM 内の compute core / warp の数が増えても、結果はだいたい同じである。これは単純化しすぎてグラフィクスプログラマに怒られるとおもうけど、メンタルモデルとしては間違ってないと思う。
一方 Flash Attention みたいのは GPU のスループット向上が性能向上につながるとは限らない。つまり、GPU 内の SM の数が増えても単一の Flash Attention は速くならない。Attention はふつう multi-head なので head の数だけ並列化はできる。あと training ならバッチサイズを増やせば並列度は増す。inference serving も本質的に並列である。ただグラフィクスと比べると透過的でない。それなりに気にしないといけない。
個々の Flash Attention 自体を速くしようと思ったら、SM を大きくしないといけない。単一 SM 内の CUDA Core の数を増やしたり、SRAM をでかくしてタイルを広げたり、あとは Tensor Core を載せたりみたいなのもある。ただこういう細部は FLOPS だけ見てるとわからない気がする。
誰かがローカル LLM 遊びをしようと気の迷いで A100 を買ったとして、そのスループットを活用できるのだろうか。A100 には 108 も SM が入っているわけで、ローカル用途の LLM でそんな並列度あるの？（買わねーよという話は置いといて。うちのアパートとか一瞬でブレーカ落ちるわ。）
・・・と思って Lhama2 を見てみると、わー 65B で 64 heads! 64/108 半分以上は使えるのか。思ったより並列度が高かった。7B ですら 32 heads もある。ご家庭の GPU なら十分に活用できそうである。というかモデルのサイズに合わせた compute を使い切れるように調整してあるのだろうな。
A100 はさておき家庭用で買える GPU で一番奮発した型番は 4090 らしいのでスペック紹介記事を見ると・・・ 128 SM! A100 より多いじゃねーか！ 64 heads だと半分しか使えないじゃん。とはいえ様々なトリックでスループットを使い切る工夫はあると思われるので, heads で半分埋まるくらいなら案外丁度いいのかもしれない。全力で回すと画面が固まりそうだし。GPU だけに。
結論としては、Triton のような SM-based programming の世界はグラフィクスと比べると GPU が transparently scalable ではないが、AI 人材はご家庭の GPU を使い切れるよう、おおむねきちんとモデルのサイズを調整していた。よかったね。