[オタク機器日記] 160B化されたCommand R+を動かしてみた件
生成AI方面だと知らぬ人はいない(だろうと思われる)nitkyさんがCommand R+を160Bパラメータ版化すると同時に、量子化したGGUF版も提供して下さっている。今回はそれ(4bit量子化版)を動かすことに成功したという話。
僕の場合は開発元のCohere社が提供する104B版の4bit量子化版を、VRAM 16GBで主メモリ 64GB環境で利用している。だから別に動作させることに成功したからといって、驚くようなことではない。しかし今回はボケが進んだのか、妙にドタバタと時間を浪費する結果になってしまった。既に構築済みの環境も壊してしまった。
つまり本記事はいつものように、「失敗談」という訳である。
実行環境と実行結果
まずは今回の実行環境。
CPU：第10世代i5
主メモリ：64GB
NVIDIA Quadra RTX 8000 (VARMは48GBでECCオフ)
SSD：1TB
マザーボード：ASRock
OS：Ubuntu Linux 22.04
Llama.cpp (GPU使用設定でコンパイル)
実行結果は下記画像の通り。なんかtransformersあたりの動きが怪しいので、処理速度を上げることは可能かもしれない。いずれ時間が確保できたら、環境を再構築したいと考えている。
モデルは下記よりダウンロード。(nitkyさん、ありがとうございます)
実行時のコマンドは次の通り。プロンプトのテキストファイルは、既に報告している4bit量子化版Command R+ 104B版で報告したものを再利用。
./main -f dragon2.txt --color -m ./models/Megac4ai-command-r-plus-Q4_K_M-00001-of-00003.gguf -ngl 43失敗：モデルのファイル拡張子を書き忘れた
全くもってして面目ない話であるが、これが今回の失敗の全て。僕は『タイプミスの酷い残念な人』なので、モデル名をモデルのプロパティから引っ張って来た。その際にモデル名へファイル拡張子「.gguf」を追記することを忘れてしまった。
Llama.cppが「モデルをロードできません」とメッセージを吐き出すので頭を抱え込んでしまったが、わかってしまえば『至極あたり前の話』という訳である。
しかし『トラブった時あるある』で、あれこれと変な方向へ突っ走って、最後は幾つものシステム環境を破壊する羽目になってしまった。
迷走1：ご本尊へのアクセス
nitkyさんはGGUF版だけでなく、160B版もHugging Faceで公開して下さっている。「もしかして皆は、こちらの4bit環境を実行しているのか？」と試してみようとしたら、知らずして160B版そのものをダウンロードする作業をやっていた。
160B版そのものは350GBを超えるサイズであり、自分のSSD(500GB)では容量不足でダウンロードさえ出来ない。いつの間にか実行環境が1TBと豪華になっているのは、実はこの『意味不明な迷走』に拠る。
ここに貼られていたサンプルスクリプトを実行したのだから、そりゃまあ350GBは必要になってしまう。しかしこの時は「Elyzaみたいに実行時にHugging Faceからダウンロードするのかな」と勘違いしてしまった。冷静に考えれば「そうだったらGGUF版の存在は？」となるので、寄る年波には勝てないというところだろうか。
失敗2：ウワサに流される
利用するモデルの勘違いは1日後に気づいたものの、今度はX(旧Twitter)で見かけたコメントに流されてしまった。
"llama.cpp(llama_cpp_python)、メインメモリよりモデルサイズが大きい場合はuse_mmap=Falseにする必要があるらしい。"
あちらは100GBのCPUメモリで実行しているらしいが、こちらは64GBである。そして3bit量子化版でさえ64GBを超える。「もしかしてSSDだけでなくてCPUメモリも128GBへする必要があるか？」と怯えてしまった。
nitkyさんのGGUF版を試すことが出来ないのだから、そうすると「既に動かせる104B版の6bit量子化版で試そう」ということになった。僕は共用住宅に住んでいるので、夜の環境は宜しくない。全住戸で1Gbpsという契約だったと思うけれども、なぜか夜は30Mbps程度に落ち込むこともある。
おまけに中古品のコンシューマ向け中古マザーボードを買い叩いたせいか、Ethernetポートに接続すると3Mbps程度しか出ない。幸い子供がSwitch用に1GbpsのUSBタイプEthernetポートを使っていなかったので拝借できたけれども、随分と時間をロスしてしまった。
試した結果はウワサはウワサに過ぎず、『メインメモリよりも大きなモデルサイズでも問題ない』と分かった。しかしここから、僕はさらに迷走を続ける羽目になってしまった。
失敗3：GGUF結合の可能性
次にハマったのが、こちらの情報。
"Qwen1.5-72Bのggufとかって50GB超えてるヤツは"なんちゃら.gguf.a"とかいう感じで複数ファイルに分割されてるんだけど、Llama .cppでロードできなくて困ってた。Llama3とかの分割ggufは普通にロードできるのに。結局、なんちゃら.gguf.aみたいな名前のファイルは本当に元ファイルをブツ切りで分割しちゃってるだけらしい。だから普通にファイル結合してやらないとロードできない。コマンドプロンプトで"copy /b qwen1_5.gguf.* qwen1_5.gguf"みたくやれば結合できて、無事ロードできた。"
これは拡張子を見ると少し怪しいものの、ともかく実験してみる価値はありそうに思った。そこで僕の場合はUbuntu環境なので、catコマンドを利用して3bit量子化版を結合してみた。
これは早朝の700Mbpsが出ている時間帯に実行したのでダウンロードには困らなかったものの、やはり48GB超と18GB超のファイルを結合するには時間を要する。おまけに第10世代のi5だから、処理速度もイマイチだ。結局は2時間ほどかかって、結果は「このGGUFファイルは変な結合をされた代物なので実行できません」というメッセージ表示となった。
解決した理由
さて解決したのは、某氏のツイートのおかげである。彼のツイート内容は正確に記述されていたので、GGUFの後ろに文字が付くと書かれていた。
そして結合ファイルを実行する命令を書いた時のことが頭に浮かび、「もしかして最初に実行させた時、うっかり拡張子「.gguf」を書き割れていたのでは？」と思い至った。
ここまで来れば後は簡単で、二日前の苦労がウソのように、アッサリと生成AI様は出力結果を返してくださった。
しめくくり
なんだか初歩的なミスで時間と労力を費やしてしまったけれども、ともかくnitkyさんの4bit量子化版Command R plus 160B版を利用できるようになった。単純に104B版を量子化したモデルは日本語利用を想定したものではないので、実行リソースが厳しくなると中国や英語を応答したり、今一つ改善を期待したいところがあった。
それが今回の160B版も使えるようになったおかげで、状況は大いに改善した… と思う。それに4bit量子化しても、モデルサイズは約100GBである。(メモするのを忘れてしまったけれども、99.7GBくらいだったように記憶している)
先々のことを考えると、今回の1TB容量のSSD調達は無駄にはならないような気がしている。
それから今回はngl 43で実行したけれども、46GBというVRAM表示のうちで、利用したのは42GBである。もしかしたら45にして、もう少し高速処理することも可能かもしれない。
なお見る人が見ると一目瞭然なのだが、nvidia-smiコマンドから分かるように、環境構築でミスを犯している。
僕のNVIDIA Quadra RTX 8000は計算処理専用のGPUなので、ビデオ出力ポートを持っていない。だからコンシューマ向けNVIDIA GPUとは違って、汎用ドライバを使い続けて構わない。その作業ミスがxorgに表れている。
と、いう次第で、ともかく無事に利用できることは判明したのだから、折を見て環境を再構築したいと考えている次第である。1TBあれば、それなりの期間は使い続けることが出来そうな気もする。
それでは今回は、この辺で。ではまた。
P.S.
お小遣いに余裕が生じたらばメモリ128GBに移行したいとは思っている。GPUとCPUのメモリ量は、多くて困ることはないのだから。
ーーーーーーー
記事作成：小野谷静（おのたにせい）
この記事が気に入ったらサポートをしてみませんか？