Swiftでガチガチのチューニングに挑戦して挫折しました。
今更C++も大変だし、Rustもアイデアは素敵と思ってもコーディングは何かしんどいという感じ。
諦めかけていたところ、Zigを知りました。
Rust is a better C++, Zig is a better C.
だそうで、その通りの言語仕様です。
メモリモデルがRustのように目新しくないので、文法さえ知れば普通に書けます。
まだ、バージョン1に到達していなくて破壊的な改良が続いているのでプロダクションに使うのは難しいと思いますが、正式版が出たら一定の層に流行ると思います。
Python/Swift/Zigの3つの言語がそれなりに使えたら大体満足できそう。
Python, Swiftの代替候補は色々ありますが、3つ目のC/C++/Rust層がつらかったんだよねぇ。
「俺の最強言語」という厨二病を持ちながら3つの言語で頑張ればいい😁
というわけで、Zigが無事正式リリースを迎えることを心から願います。
できれば貢献したいな。何かツール作ろうかな？
今年1月のProject DIGITSの発表から10ヶ月弱、ようやくDGX Sparkが出荷され始めました。
LLMについて色々調べて、特にToken Generationはメモリ帯域律速だということもわかって、DGX Spark、1PFLOPSの割にきついんじゃないかという気がしていました。
ベンチマーク結果は、M3 Maxと同じぐらいのようです。メモリ帯域(Spark 273GB/s, M3 Max 400GB/s)を考えると善戦。
(というか、M3 Maxチューニング足りてないのかも)
さて、値段ですが、日本では代理店経由で価格未公開が多いですが、公開しているところを参考にすると、税込70万円かそれ以上。
同等のスペックをMac Studioでカスタマイズすると、
で、税込733,800円。
AppleのSSDは高速ですが、Apple税が入っているので？節約コースを考えると、
583,800円＋40,000円=623,800円。DGX Sparkより安いです。
CUDAに慣れていてLLMをゴリゴリしたい人にはDGX Sparkはいいかもしれませんが、その辺りはお任せ、大きなLLMを動かして使いたいだけという人には、Mac Studioがお値打ちなようです。
一番に最初に、LLMにはMacがいいと言った人の先見の名に感心します。
当時、私も、LLMと言えばNVIDIA GPU必須やろ、さすがにMacがいいは言い過ぎと思いました。
AI PC/Copilot+ PCも基本UMAですが、Macほどその自由度が高くないようです。
NPUがメモリをフルにアクセスできなかったり帯域が絞られていたり。
というわけで、DGX Spark欲しい熱が冷めて、Mac Studioいいなぁと思いながらIntel iMacでブログを書いている今日この頃です。
struct InlineArray<let count : Int, Element> where Element : ~Copyable
InlineArrayのシグニチャを見て、「え？Elementはコピーできないの？なんのこっちゃ」と思ったのですが、今時のLLMに聞くとこれは「コピーできてもできなくてもいい」という意味らしいです。
そして、whereでElementがコピーできないという制約は書けないらしいです。
狂っている。控えめに言って狂っている。
この瞬間、Swiftの嫌なところがどっと湧いてきました。
classとstructって何？最初は参照型か値型かでメンタルモデルも作りやすかったです。しかし今では特に大きなデータの場合、結局どっちで作るのがいいか、ほぼどうでもいいのに決定しなければいけない無駄な意思決定を要求されます。
DispatchQueueかasync/awaitか。async/awaitのほうが効率良さそうなのはわかります。しかし移行するのにHaskellのモナドぐらい敷居があります。一つasyncで書くと、利用しているメソッド群を雪崩式にどどどっと書き直さないといけない。過去のリソースを使わない新規プロジェクトならいいですが、そうじゃない場合、結局両方書けっていうこと？
SwiftUIって結局、ロジックとUIの分離が難しくなってない？MVCかMVVMかTCA？もうええって。
ずっと、Swiftラブだったのに。愛はいつか冷めるもんですね。
ああ美しい言語と出会いたい。
5月にプレビュー版が公開されていたGemma 3nが正式公開です。
プレビュー版では.task(LiteRT (TensorFlow Liteのリブランディング))ファイルが公開されて、Androidでは一応動かせたようですが、正式公開では、各機械学習ライブラリ向け.safetensorsが公開されただけです。
モバイルで動くことが一番のアピールポイントなのにモバイル向けカスタマイズはサードパーティさん頑張ってと。
音声や動画まで扱えるマルチモーダルLMってサードパーティでどこも実現していないような…
研究段階だったLLMがいきなりイノベーションの先端に立って3年弱。研究者が製品を出荷するような状況で大変なんでしょうね。
そろそろ、ライセンス含めて使いやすいローカルLLMが出てきて欲しいです。
1年ぶりの投稿です。
AlphaGo以来、HPC(ゲーミングPCとも言う)が欲しいと言い続けながら購入しませんでした。
(iPadのNeural Engineで満足していた)
LLM時代に入って、AI用PCのスペックが一変しました。演算力よりメモリとメモリ帯域。巨大なニューラルネットワークのウェイトをメモリ上に置きそこからリードすることがボトルネックになるとは。
みなさん、LLMは利用されていますか？
私は、プログラミングには不可欠になりつつありますし、情報が知りたいというより対話したい時にはGoogleよりよい相手になりました。ChatGPTを無料の範囲で使っています。
VSCodeにもCopilotを入れましたが、編集中のコードがサーバーに上がっていそうでちょっと怖いです。
なのでローカルLLMが欲しい！
さて、民生価格で巨大なLLMモデルを動かすとなると選択肢はUMAのてんこ盛りMacか5月に発売予定のProject DIGITSか。
今まで欲しくてしかたなかったNVIDIAのGPUはメモリの観点からは1枚では足らなく複数枚となると民生の値段ではなくなります。
昨日発表されたM4 Max Mac StudioとProject DIGITSを比較したいと思います。
コスパの比較をしたいのでカスタマイズ可能な部分はできるだけ近づけます。
| Project DIGITS | Mac Studio (M4 Max) | Mac Studio (M3 Ultra) | Framework Desktop | |
| メモリ | 128GB | 128GB | 96GB | 128GB |
| メモリ帯域 | 273GB/s | 546GB/s | 819GB/s | 256GB/s |
| GPU(FP32) | 45TFLOPS | 17.04TFLOPS | 21.3TFLOP | 21TFLOP |
| Tensor Core / NPU(密INT8) | 250TOPS/125TFLOPS | 38TOPS/16TFLOPS | 36TOPS/36TFLOPS | 50TOPS |
| ARMコア数 | 20(10) | 16(12) | 28(20) | 16 |
| SME(AMX)ユニット数 | 0 | 2 | 4 | 0 |
| SSD | 1TB | 1TB | 1TB | 1TB |
| 価格 | $3000 | $3699 | $3999 | $2279 |
Project DIGITSも同じUMAで、となるとTensor Coreの250TOPS(FP4で1000TFLOPSが歌われているが多分sparseで、denseならその半分、そしてINT8換算にするとさらにその半分)の実力が発揮できるどうか。512GB/sはVRAMよりも遅いですが、PCとしては相当の数字。
Apple Siliconは現状、Neural EngineのDMAが速度を出せず38TOPSすら活かせていない状況です。なのでLLMはほぼGPU/CPU実装。
NVIDIAがUMAでもTensor Coreをフルに活用できるような効率のいいメモリアクセスを実装できたらびっくりするような数字が出そうです。逆にその辺りはAppleに1日の長があるなら、Project DIGITSはスペックの数字だけよくて性能はイマイチの可能性も。
いずれにしても5月が楽しみですねぇ。
追記。
ChatGPTに聞いたら、LLMのトークン/秒はFP16でTOPS = 0.05 * メモリ帯域がざっくり最適で、そこからずれるとどちらかが律速段階になるそうです。
512GB/sならFP16で25.6FLOPS。INT8なら51.2TOPS、FP4なら102.4FLOPS。Project DIGITSに搭載されるGB10はLLMにはオーバースペックかも。
今年はいよいよAI真っ盛りな一年になりそうです。
AlphaGoクローンの移植をきっかけに、せっかく、(学習じゃなくて)推論方面で色々ノウハウを持てたので、応用できたらと推論系調査備忘録。
| プラットフォーム | iOS/iPadOS | macOS | Android | Windows |
| フラグシッププロセッサ | A17 Pro | M3 | Snapdragon 8 Gen 3/Dimensity 9300 | Ryzen 7040U/Core Ultra |
| 上記プロセッサNPU性能 | 35TOPS(実力は8.75FLOPS) | 18TOPS(実力は9FLOPS) | 45TOPS/33TOPS | 10TOPS/11TOPS |
| 今年発売予定プロセッサ | A18 | M4? | Snapdragon X Elite | |
| ランタイム | Core ML | Core ML | TensorFlow Lite | DirectML |
| フォーマット | mlmodel/mlpackage | mlmodel/mlpackage | tflite | ONNX |
| 変換対象 | TensorFlow/PyTorch | TensorFlow/PyTorch | TensorFlow | TensorFlow/PyTorch/... |
以下、根拠のない印象。
ランタイムを使った開発の情報はあまりなく、相変わらずまだ開発者が少ない印象。
Core MLは現在、生成AI関連のウェイトをNeural Engine用にコンパイルする時間が非常に長く、推論の速さを活かすのが難しい。
AI Readyを謳おうと思うとCore MLの大改造が必要で、WWDCに向けて大忙しのはず。
メモリも今のiPhone/iPadで標準的な6〜8GBはちょっと苦しい。
今年のモデルから16GBが標準になるんじゃないか。
今のところ、Core MLやMPSGraphよりMetal生書きのサードパーティの生成AI実装のほうが優秀。
TensorFlow Lite、盛り上がっているのか不明。Pixel 8 ProやGalaxy S24のAI機能も果たしてTensorFlow Liteの上に作られているのかどうか。
DirectMLもこれから？
NPUを使おうと思うとこれを介する必要があるが、普通の開発者はNPU使わず、GPUでPyTorchおよびその関連ランタイムを使いそう。
PCメーカがAI PCをアピールするために同梱アプリを作るところから始まりそう。
Swiftプログラミング言語が発表されて今年は10年目で、私も10年近く書いてきました。
そんな私が、「今まで何勘違いしてたの？」とショックを受けたことがこれ。
SwiftのenumのrawValueは生の値じゃない
まあ、StringをrawValueにできる時点でそういう気はしていたのですが…
enum SomeEnum: Int { case aCase } enum AnotherEnum: Int { case aCase case bCase } print(MemoryLayout<SomeEnum>.size, MemoryLayout<AnotherEnum>.size, MemoryLayout<Int>.size)
上記コードをPlaygroundsで走らせると、出力は、
0 1 8
となります。
caseが1つしかない時にはメモリを消費せず、caseが2つの時は1バイトです。Intのサイズ8と一致しません。
みなさん知ってましたか？
ちなみに
print(MemoryLayout<AnotherEnum?>.size)
の出力は
1
です。つまりOptionalにしても(多分、caseの数が128以下なら)メモリフットプリントは増えません。いいですね。
Optional
Intに8バイトも普通要らないので、むしろ8バイトのOptinal_Int型が欲しいです。
