その１ じじいを置いてきぼりにしないで
2023年頃からこの2年間で急速に発展した生成AIですが、2023年5月にローカルで動く女子高校生言語モデル(rinna：3.8B) が、ChatGPT3.5と同じ時期にリリースされました。インターフェース2024年5月号には、メタが提供するコンパクトなllama2をラズパイ5に搭載した記事も報告され、そのたびに追試を行ってきました。https://twinkletec.org/2024/12/24/gpt-llm-llama2-diffusers-magenta/ 一方で、クラウドベースの生成AIビジネスの状況は過熱していて、GPU搭載サーバと基盤モデル開発がキーになるようで大手の投資が続いています、2030年にはマイクロソフト・アマゾン・グーグルが支配するクラウドサービスの売上は自動車産業に並び、その3割が生成AIサービスになると予測されています。生成AIビジネスはクラウド3社と基盤モデルを開発するOpenAI社とGPUを売るNVIDIAの寡占状態にあるようです。1990年にスパーコンピュータブームが起こった時のことを思いだします。メインフレームからパーソナルコピュータに移行したように、生成AIもクラウドからローカルに移行する可能性が高いように思います。そこで、今回ローカルにこだわって生成AIを調査してみました。扱えるモデル容量の不足や処理スピードは雲泥の差ですが、今後の半導体の進歩に期待したいです。
インターフェース2025年3月号にOpenWebUIの記事が掲載されたことをきっかけに、今回は、文書生成AI(txt2txtと一部img2txt)と：ollama＋openwebuiと、画像生成AI(txt2imgとimg2img)：stable diffusion＋automatic1111をGPUマシーンに実装してみました。パソコンクラブ以来の手作りです。ATX基盤に、GPU(RTX2060:12GB+RTX 2070：8GB)を刺し、主メモリを64GBにしています。筐体はアルミのオープンフレームです。
GPUのVRAMが重要です。ローカルモデルのパラメータ数は、3～20Bくらいです。一番多いのが7Bモデルです。モデルを置く場所がVRAM上だと一番高速に動くようです。8GBは最低必要だと思います。ローカル生成AIのエンジンであるollmaについて以下のような記述があります。OllamaのGPUとRAMの使用について – Genspark
上記、urlの情報を纏めると、
「Ollamaを使用してGPUでモデルを実行する際、VRAM（ビデオRAM）のみが使用されるわけではありません。特に、GPUのVRAMが不足している場合、OllamaはシステムのRAMを利用することがあります。これは、モデルのサイズがGPUのVRAMの容量を超える場合に発生します。たとえば、llama3:70bモデルは、必要なメモリがVRAMの容量を超えるため、システムRAMも使用されることになります。また、OllamaはVRAMが不足している場合にCPUを使用して計算を行うこともあります。これにより、GPUとCPUの両方が協力してモデルの推論を行うことが可能です。」ということで、
グラボが2本刺せるATXのMBを使用しました。
その2 OllamaとOpenWebUI
OpenWebUIとローカルLLMのエンジンであるollamaを導入してみました。Ollamaは
Meta社のLLMはオープンソースです。ラズパイ5に搭載したLlama2等の軽量なモデル
については既報です。ollamaを使うと、これらの軽量モデルを使ってローカルな環境
が構築できます。コマンドラインで動くのですが、ollamaをGUIで操作するものとしてOpenWebUIを使います。OpenWebUIはDockerDesktopから起動します。
この辺の手順を以下に示します。DockerDesktopを介してOpenWebUIを導入する方法は、https://note.com/tamo02918/n/n94b8561fb70c に丁寧に記載されています。
localhost:3000で、ＷＥＢ画面で操作します。画面は、chatGPTのそれに同じです。まず、モデルを選択します。一番軽量な「llama3.2」は3.2Bモデルでモデル容量は大体ですが、パラメータ数(Bilion単位)くらいのモデル占有メモリ量（GB単位）だと思います。なので、llama3.2(3.2B)はGPUのVRAMが4GB程度のGPUボードでも快適に動作します。(以前利用していた画像AI用のPC：RTX1050Ti-4GB LP搭載でそこそこに動きました) 人気ある軽量モデルとしては、mistral-nemo(12.8GB)とかgemma2(9.2B)とかdeepseek-r1(7.6B)とかあります。検索してダウンロードできます。deepseekは天安門の件は修正されているようできちんとお答えしてくれました。モデルの比較として、Interface2025年3月号P99で試された「阿蘇山の標高」を聞いてみました。
Interfaceにはありませんが、deepseek-r1も正解でした。OpenWebUIはRAGが扱えます。（RAG=Retrieval-Augmented Generation：検索拡張生成） RAGは、urlを参照したり、別途用意したデータ(txtやpdf等)を読み込み参照することで、より精度の高い回答が得られます。また、ローカルで使用する今回のような場合、個情
報などを完全にローカルで扱うことができます。会社の従業員情報とかクレーム情報みたいなものがローカルで扱えます。まず、urlやtxtデータを使用して、吉野ケ里遺跡の説明精度が上がるか確認しました。モデルは、mistral-nemo(12.8B)です。
最初は、吉野ケ里遺跡は奈良県にあることになっていましたが、吉野ケ里遺跡のパンフレットから取り出したtxtをRAGに使用すると、九州になりました。更にweb検索を許すと、2件ほど関連urlを拾ってきて、新たに吉野ケ里女神像の情報が加わりました。
次に、個人データをRAGに使って試験をしてみました。過去3回分の、師弟関係にある人のメール文章を使用しています。500文字x3程度のデータです。本文はtxtですが、3通を纏めてpdf形式にしました。正式な使用許可は得てないので、ここだけにしてください。モデルは一番軽量な、llama3.2(3.2B)を使用しました。
LLMによる想像が含まれ事実と異なる部分もありますが、こんな軽量モデルでも
RAGを利用することでプライベートな情報を処理できることが判りました。
次回は、copilot等のサービスでコード生成が可能ですが、ローカルLLMでコード
生成ができるかを検討します。
その3 ローカルLLMでのコード生成
クラウドでは、microsoftのブラウザについている「copilot」を便利に使っています。
これまではプログラムを作る場合、まずwebでライブラリなどを検索して、先人たちの記事を参考にしていました。ただし、記事が古すぎて環境を再現できなかったり、macユーザーの記事などが含まれていて、10件検索して1～2件のあたりがあれば良いかなというものでした。Copilotは、前段でのフィルタリングの手間が省けて、プログラム仕様の9割くらいは最初のトライでこなせるため重宝に使わせていただいています。
無料で使えて、エラーの相談にも乗って頂いています。今回は、ローカルLLMでコード生成の実験を行いました。LLMのモデルには「mistral-nemo」を使いました。
電子回路の設計が記載されたpdfファイル8個をRAGデータとしました。
お題は、「20Hzから100Hzの信号を通過させるバンドパスフィルターを設計してください」としました。そうするとフィルターの伝達関数の定数を計算してくれ、更にプログラムコードを出力してくれました。しかし、よく見るとmatlabコードです。普通はpythonコードを返すのですが、参考にしたRAG資料はmatlabコードを使用していたことで、LLMが併せてくれたものと思われます。
次のお題は、「サンプリング周波数1000HzのDACのデータを使って、上記バンドパスフィルターを通過した信号波形を表示するプログラムコードをpythonで記述してください」としてみました。
30行くらいのpythonコードを生成してくれました。これでは、正しくコードが生成されたかどうかわからないため、次のお題を出しました。「ｘを乱数で、1秒分1000個発生させ、それに対するｙを表示するプログラムコードをpythonで記述してください」 すると、新たにコードを生成してくれました。
このコードをAnaconda環境(Python3.6,3.8,3.9の３環境)で動作させてみました。
Python3.6～3.9の環境全てで、エラーが出ました。X軸の数値を作るのに、np.linspace()を使っているのが良くないようなので、np.arange()で書き替えました。
動作は確認できました。コード生成はローカルLLMにとって比較的楽な作業なのかもしれませんね。Interface2025年3月号P102に掲載されている「qwen2.5-coreder8b」
がコード生成・修正によさそうです。時間があれば試してみたいと思います。
その4 ローカルLLMでの画像判読
Meta 社から、画像と文書を扱えるVLM(Visual Langage Model)として、「llama3.2-vision」が提供されています。流行りのマルチモーダルモデルです。今回は、画像推論の機能を試しました。2つの画像から情報を抽出してみました。ヤシの木の写真は、太平洋の島と言っていますし、犬の写真は、犬が読書していることと、犬はゴールデンリトリバー(金色コマチドッッグ)と言っています。
次に、表データの画像から数値を読み込んで表データを再構築できるかを試しました。
OCRの機能ですね。ヘッダーも読み取ってくれています。
次は、グラフ画像から数値を読み込んで表データにすることを試しました。できていそうですが、できていませんでした。読み取った数値は単調増加しています。
読み取るグラフのドットを大きくすると、読み取り精度が上がるかを試してみました。
最後に、VLMの応用例として朝ごはんの写真からカロリー計算をしてもらいました。約400KCalだそうです。携帯電話のアプリにも同じようなものがありますが、ローカルで処理をしています。
その5 ローカルLLMでの画像生成
Stable_diffusionは、代表的な画像生成AIです。以前もノートPCでコマンドラインを使って宇宙人の画像を生成しました。1枚生成するのに3時間程度の時間が掛かっていました。https://twinkletec.org/2024/12/24/gpt-llm-llama2-diffusers-magenta/
今回はGPUマシーンを使用しました。1画像生成するのに数秒でした。
また、stable_diffusionのWEBUIであるautomatic1111を導入しました。OpenWebUIに比べ設定は非常に簡単です。以下のurlに詳しく導入方法が記載されています。
https://pcniki.com/stable-diffusion-web-ui-automatic1111-install/ です。導入手順と簡単な操作方法を纏めました。
WEBUI画面で、ポジティブプロンプトとネガティブプロンプトを入力します。ネガティブプロンプトは手足や顔の配置や本数が異常な画像が生成される等を防ぐためのものでbad anatomytとかの単語をコンマ区切りで入力します。
また、同じプロンプトでも毎回違う画像が生成されるので、複数枚生成して自分のイメージに合ったものを選びましょう。(歩留を考慮します)
画像サイズや配色、写実的なものなどをポシティブプロンプトに書き込みます。以下に生成例を示しました。
画像生成AIの応用例として、本などの表紙絵を生成してみました。人物などは著作権に引っかかる可能性もあるので、ロボットを出演させることにしました。
今までの画像生成は「txt2img」ですがautomatic1111では、「img2img」のUIもサポートしています。操作方法と例を示します。Img2imgのタブを選びます。元画像を準備して入力画像BOXに貼り付けます。この絵を基に何がしたいのかをプロンプトで記述します。さすがに英語の方が伝わるようです。3体のロボット漫画からより写実的な画像を生成しています。
最後に、img2imgの応用例として、沢田研二さんの変化予想をしてみました。40歳の写真から75歳の写真を予測するように指示しています。眼鏡をかけていますが雰囲気はあります。実際にはどうなのかWEBからの比較写真を勝手に使わせてもらいました。眼鏡はしてないですが似ているような気がします。
