執筆者：佐藤友昭
※ 「AI特需に対応: 安価なGPUの可能性」連載記事一覧はこちら
本記事は、株式会社アスク様による支援を受けて当社が作成・掲載しています。
記事内で紹介している内容や検証結果は、当社が実際の検証環境に基づき独自に取りまとめたものであり、商業的意図による記述変更や編集は行っていません。
ローカルLLMがあると何がうれしいのか？
言うまでもないと言われそうだが筆者の場合について敢えて書いてみる。
月並みな言い方だが、超人的に読むのが早いアシスタントのようなものである。
ブログでも紹介しているが、筆者は2017年頃からディスアグリゲーテッド・コンピューティング関連の講演をウォッチしている。初期のころは飛行機で現地に行ったりしていたが、今は居ながらにしてYouTubeで視聴できる。講演以外にも様々な発信形態が現れ、登録チャネルに毎日２桁から３桁の新着コンテンツがある。
とはいえ受け手である私のスループットは昔も今も10byte/secなので到底全てを受け止めることはできない。今にして思えば、時間をかけて聞いた英語を文字に起こししたりしていたので内容を理解できていたことを痛感する。(テキストは http://www.cdi-info.jp に掲載しています。)
そこにローカルLLMがやってくる。
登録しているYouTubeチャンネルが前日に配信した動画のURLリストから音声データをダウンロードし、parakeetやwhisperで文字にする。これをOpen-WebUIのナレッジに登録する。
エンべディングモデルの設定を多少いじると gpt-oss:20b 等のモデルと組み合わせて質問に答えてくれるようになる。
目的は実際に視聴すべきYouTubeコンテンツの発掘である。夥しい量の動画が押し寄せてきてもマイペースでゆったり視聴できる。心が折れない。
このユースケースはローカルLLMである必然性はないかもしれないが、こたつでUNIXと似たようなロマンはあると思う。
（www.cdi-info.jp は昨年度一杯で更新を終了している。クラウドLLMがいい感じに学習してくれているようである。）
別のユースケースとしては大きなコードベースの解読を llama4:17b-scout-16e-instruct-q4_K_M モデルのような10MトークンのローカルLLMに手伝ってもらう。 最近はクラウドLLMも最大コンテキストが大きくなってきたが10Mトークンというのはまだないのではないか。10Mトークンと言うと linux/net 配下をトークン化した規模に相当する。 残念ながらllama4:17b-scout-16e-instruct-q4_K_M は 70GB 程度のサイズがあり、4070 (16GB) では動かせなかったので M4 Max (128GB) で使用している。 対象が OSS なら、かつ、コードベースの規模がクラウドLLMの最大コンテキストに収まるならローカルLLMである必然性はないかもしれない。
4070 (16GB) では動かせなかったというのは正確ではない。動くことは動くがとても時間がかかる。例えば、linux/fs/ramfs/ 配下のコードの構造を知りたいとする。4070 (16GB) で実行すると 11 分かかった。
total duration: 11m5.285765035s load duration: 27.401705853s prompt eval count: 5227 token(s) prompt eval duration: 6m17.525824041s prompt eval rate: 13.85 tokens/s eval count: 819 token(s) eval duration: 4m20.354686019s eval rate: 3.15 tokens/s NAME ID SIZE PROCESSOR CONTEXT UNTIL llama4:17b-scout-16e-instruct-q4_K_M_128K 961f3adc7570 115 GB 87%/13% CPU/GPU 131072 4 minutes from now
これを前回の記事で取り上げた、会社のFalcon 4205+ NVIDIA RTX™ 4000 Ada 世代 4台による「スケールアップシナリオ」の環境で実行すると 6 分で終わる。
total duration: 5m57.822838336s load duration: 52.768515466s prompt eval count: 5227 token(s) prompt eval duration: 3m8.200174629s prompt eval rate: 27.77 tokens/s eval count: 812 token(s) eval duration: 1m56.851651798s eval rate: 6.95 tokens/s NAME ID SIZE PROCESSOR CONTEXT UNTIL llama4:17b-scout-16e-instruct-q4_K_M_128K 961f3adc7570 149 GB 49%/51% CPU/GPU 131072 4 minutes from now
しかし、他のエンジニアの皆さんも利用する共有環境なので一人で６分間も占有してしまうのは厳しい。
NVIDIA RTX PRO™ 6000 (96GB) があると１分で終わる。正確には、NVIDIA RTX PRO™ 6000 Blackwell Max-Q Workstation Edition。
total duration: 54.53759485s load duration: 11.134506642s prompt eval count: 5227 token(s) prompt eval duration: 18.220238151s prompt eval rate: 286.88 tokens/s eval count: 547 token(s) eval duration: 25.181188523s eval rate: 21.72 tokens/s NAME ID SIZE PROCESSOR CONTEXT UNTIL llama4:17b-scout-16e-instruct-q4_K_M_128K 961f3adc7570 115 GB 14%/86% CPU/GPU 131072 4 minutes from now
上記、３つのいずれの環境もllama4:17b-scout-16e-instruct-q4_K_Mモデルの最大コンテキスト(CONTEXTの値)を131072に設定している。調査対象のコード規模が大きければさらに拡大する必要がある。いずれの環境もGPUメモリには収まっていない。NVIDIA RTX PRO™ 6000 (96GB)が複数台あれば収まるのだろう。Falcon 4205の場合、４台 (384GB) まで収容可能と思われるが、要確認。
というわけで、我が家ではM4 Max (128GB) で使用している。
人類が所有しているデータのうち、オープンなものは１割程度という話を聞いたことがある。クラウドLLMはそのデータで学習している。会社の中に宝の山（データ）があるならローカルLLMは必須だろう。
ローカルLM分散実行ができると何がうれしいか？（妄想）
ローカルLLMが超人的に読むのが早いアシスタントだとして、会社などの組織に求められるアシスタント像を考えてみる。一人のアシスタントが全員の相手をしてくれると良いが、TCOは安い方が良い。
上述の YouTube コンテンツの文字起こしを Open-WebUI のナレッジに登録するにしても PC １台では実は結構時間が掛かる。測定してみたところ 24H で 6000件程度で、１件追加するコストは増加する傾向がある。試算すると20日で4万件、100日で12万件が限度という感じである。 私一人のアシスタントなら全く問題ないキャパシティであるが、一人のアシスタントが全員の相手をするような状況だと早々に破綻しそうである。
そこで登場するのがLM分散実行である。簡単に言うと一人に一台のアシスタント PC を置いて、アシスタント間でナレッジを共有するイメージである。
共有するのはナレッジだけではない。上述した llama4:17b-scout-16e-instruct-q4_K_M の GGUF モデルを Hugging Face からダウンロードするのに我が家の VDSL 回線では 35 時間かかった。総容量 1.7 TB。 （週末の間中、VOD の画質低下を我慢する必要があったので諦めて光コンセントの方に契約しなおした。） ひとり１台のアシスタントPCが同じモデルを重複してダウンロードするのは無駄である。ダウンロード済みのモデルも共有したい。
最大のメリットはアシスタントPC１台では動かせないサイズのモデルがアシスタントPC数台によるローカルLM分散実行で動くようになることである。 会社にアシスタントPCが何台かあるなら高価なハイスペックシステムを買わなくても済むかもしれない。 なんとなく、アシスタントPCのスペックとしても M4 Max (128GB) や DGX Spark (128GB)あたりがトータルのコストパフォーマンスでも最強な予感はするが。
