本文へ移動
KX3
AI・ローカルLLM / 約10分

RTX 4060 LaptopでローカルLLMを育ててみた。個人開発で実際にやっていること

RTX 4060 Laptop(VRAM 8GB)で、アプリ組み込み向けのローカルLLM「Konohana」を開発中。LoRA/QLoRAによる追加学習、評価、Runtimeとの役割分担まで、個人開発で実際にやっていることをまとめます。

By admin@@
ノートPCでコードを表示しながらローカルLLMを開発するイメージ
Photo by James Harrison / Unsplash

最近、アプリに組み込むためのローカルLLMを開発しています。

名前はKonohana

「ChatGPTみたいなAIをゼロから作っているの?」と思われそうですが、もちろん違います。

そんなGPUはない。そんな予算もない。

OpenAIやGoogleと真正面から殴り合おうとしても、こちらの主力はRTX 4060 Laptop GPU、VRAM 8GBです。

勝負する場所が違う。

そこでKonohanaでは、既存のLLMをベースに、自作アプリの中で使いやすい小型AIへ少しずつ調整するという方向で開発しています。

RTX 4060 LaptopでローカルLLM開発って、実際には何をしているの?

今回は、LoRAやQLoRAを使った追加学習から、評価、アプリ側のRuntimeとの役割分担まで、個人開発で実際にやっていることをまとめます。


なぜ外部APIではなく、ローカルLLMなのか

今はChatGPTやGeminiなど、高性能なAIをAPI経由で簡単にアプリへ組み込めます。実際、それが一番合理的な場面も多いです。

ただ、小規模なアプリをいくつも作ろうとすると、少し事情が変わってきます。

API料金が継続的にかかる。
ネット接続が前提になる。
ユーザーデータを外部へ送る場面が増える。
サービス側の仕様変更にも影響される。

特に「ちょっとAI機能を足したい」という用途で、使われるたびにサーバー側のコストが積み上がる設計にはしたくありませんでした。

そこで考えたのが、端末やPC上で直接動くAIをアプリに組み込めないか、ということです。

全部をローカルLLMに置き換える必要はありません。外部APIが得意な仕事は外部APIに任せ、ローカルで十分な処理だけ端末側へ持ってくる。その選択肢を増やしたい、というのが出発点です。


「LLMを作る」と言っても、ゼロからではない

本当にゼロからLLMを作ろうとすると、大量の学習データ、大量のGPU、大量の電力、そしてたぶん大量の祈りが必要です。

個人開発でそこへ行くのは現実的ではありません。

Konohanaでやっているのは、既存のベースモデルを利用し、必要な能力を追加学習で伸ばしながら、アプリ側の仕組みと組み合わせる方法です。

ざっくり言えば、ベースLLM + 追加学習 + Runtime + Local Knowledge

頭脳そのものをゼロから作るのではなく、既にある頭脳を、アプリで扱いやすい方向へ調整するイメージです。


学習環境はRTX 4060 Laptop。VRAMは8GB

開発に使っているのはWindowsのゲーミングノートPCです。GPUはRTX 4060 Laptop GPUで、VRAMは8GB。

ローカルLLM界隈では24GB、48GB、さらに大容量のユニファイドメモリを使う構成も珍しくありません。

その中で8GB。

かなり慎ましい。

モデルサイズや学習設定を無視すると、VRAMから「その要求は聞いてないんですけど?」と言われそうになります。

それでも、やり方を選べば追加学習はできます。その中心にあるのがLoRAとQLoRAです。

LoRAとQLoRAがかなり助かる

LLM全体のパラメータをそのまま学習し直すのは、8GB VRAMではかなり厳しいです。

そこで使っているのがLoRA。ものすごく雑に言えば、モデル全体を書き換えるのではなく、比較的小さな追加部分を学習する方法です。

1000ページの教科書を全部書き直す代わりに、「ここはこう考えて」という補足ノートを追加する感じです。

さらにQLoRAを使えば、元のモデルを低ビット量子化してメモリ使用量を抑えながら、LoRA部分を学習できます。もちろん何でも8GBで動くわけではありませんが、モデルサイズや設定を選べば、ゲーミングノートでも試行錯誤できる範囲がかなり広がります。

初めて学習が最後まで走ったときは、普通に感動しました。

ノートPCでLLMを学習している。

字面だけ見ると、まだちょっと未来です。


目標は「なんでもできるAI」ではない

Konohanaの目的は、ChatGPTの代わりになる万能AIを作ることではありません。

アプリに組み込むなら、総合力よりも決められた用途で安定して動くことのほうが重要です。

日本語の指示を理解する。文章を整理する。内容を分類する。必要な情報を抽出する。決められたJSON形式で返す。

料理も世界史も量子力学も完璧に答える必要はありません。

このデータを、この形式で整理して。

アプリからそう言われたときに、余計なことをせず、期待した形式でちゃんと返してくれる。それだけでも十分価値があります。


「学習すれば性能が上がる」は、そんなに単純ではなかった

最初はかなり単純に考えていました。

データを追加して学習すれば、当然もっと賢くなるでしょ。

なお、現実はそうでもありません。

ある能力を改善しようとして学習すると、別の能力が落ちることがあります。SQL系のデータを増やしてSQLは良くなった。でも他の評価を回すと、なぜか前より弱い。

学習した結果、弱体化。

ゲームならパッチノートを確認したいところですが、開発者はこっちです。逃げ場がありません。

だから実際の作業は、学習して、評価して、設定を変えて、また学習して、また評価する。その繰り返しです。

LoRAの設定、学習データの量、学習回数、Seed、評価セット。少しずつ条件を変え、Baseモデルや前バージョンと比較します。

数時間試して、結論が「今回の変更、ほぼ効果なし」になる日もあります。

悲しい。でも「この方法では改善しない」と分かったので、たぶん前進です。たぶん。


能力・人格・知識を分けたほうが扱いやすい

開発初期には、モデル自身に「私はKonohanaです」と覚えさせることも考えていました。専用モデルなんだから、名前くらい知っていてほしい。

でも途中で思いました。

それ、モデル本体に学習させる必要ある?

AIの名前、役割、話し方、出力ルールは、アプリから実行するときにRuntime側で指定できます。しかもアプリごとに役割を変えるなら、そのほうが柔軟です。

Weights:モデル本体の基礎能力

日本語の指示理解、構造化出力、文章整理、アプリからの命令理解、不確実なことを無理に断言しない、といった汎用的な能力を担当します。

Runtime:アプリごとの役割や振る舞い

AIの名前、役割、話し方、出力ルール、アプリ固有の制約などを担当します。

Local Knowledge:そのアプリで必要な知識

アプリ固有の情報や、必要なときだけ参照したいローカルデータを担当します。

つまり、能力はWeights、役割はRuntime、知識はLocal Knowledge

この分け方にしてから、一つのモデルを複数のアプリで使う設計がかなり分かりやすくなりました。

RTX 4060 Laptopに頑張ってもらって「私はKonohanaです」を覚えさせるより、そのGPUにはもっと重要なことを覚えてもらいたい。


実は一番大変なのは、学習よりデータ作りと評価

LLM開発というと、GPUが回って、ターミナルにLossが流れて、いかにも「AIを作っています」という画を想像します。

もちろんそれもあります。ただ、実際に時間を使っているのは学習データ作りと評価設計です。

たとえば「JSONを正しく返してほしい」というだけでも、どんな指示を用意するのか、何を正解とするのか、説明文を付けたら失敗なのか、曖昧な指示にはどう反応させるのか、と考えることがかなりあります。

AI開発というより、AI用の問題集と採点基準を作っている時間が長い。

先生側です。

評価も難しいです。新しいモデルを作ると、どうしても「新しいほうが良く見える」というバイアスが入ります。

そのため、Baseモデル、前バージョン、同じ評価セット、学習に使っていない問題などを使い、できるだけ条件を揃えて比較しています。構造化出力の成功率など、数値にできるものは数値で追います。


AIを使ってAIを作る

Konohanaの開発には、ChatGPTやCodexなどのAIも使っています。

学習コードの確認、エラー解析、データセットのチェック、評価結果の整理。場合によっては、AIが作った学習データを別のAIが学習します。

AI「AI作っときました」
人間「ヨシ!」

……で終われば楽なのですが、生成データには偏りや変な正解が混ざることがあります。そのまま大量投入するのは危険なので、最終的な確認や評価基準づくりはまだ人間の仕事です。

人類、まだクビにはならない。


アプリ用LLMなら、ChatGPTより賢くなくてもいい

ローカルLLMを作ると、どうしても「これ、GPTより強い?」と考えたくなります。

普通に総合力で比べれば負けます。相手は世界トップクラスの企業が作る巨大モデル。こちらはゲーミングノートです。

戦う場所を間違えてはいけない。

アプリ用なら、世界知識や難しい数学で勝つ必要はありません。特定のJSONを安定して返す、メモを整理する、文章を分類する、ローカルデータから必要な情報を抜き出す、といった仕事が安定してできれば価値があります。

しかも小型モデルなら、容量、メモリ使用量、推論速度、消費電力の面でもアプリへ組み込みやすくなります。

大事なのは最高性能のモデルを作ることではなく、必要十分な性能をできるだけ小さく実現すること

この考え方は、普通のAIベンチマークとは少し違っていて面白いところです。


これからKonohanaでやりたいこと

Konohanaはまだ開発途中です。

今後は、日本語の指示理解、構造化出力、アプリ操作意図の理解をさらに安定させたい。モデルサイズを抑えながら性能を上げ、Runtimeとの役割分担やLocal Knowledgeの扱いも詰めていく予定です。

そして最終的には、実際のアプリへ組み込みます。

「AI機能が欲しいから、とりあえず外部APIを呼ぶ」だけではなく、「この処理ならローカルAIで十分できる」という選択肢を持てるようにしたい。

巨大LLMをゼロから作るのは個人には現実的ではありません。でも、既存のオープンなモデルを使い、LoRAやQLoRAで自分の用途に合わせて育てることは、普通のゲーミングノートでもかなり現実的になってきました。

自分のアプリに必要なAIを、自分の手元で育てる。

これはかなり面白い時代だと思います。

そして今日もRTX 4060 Laptopに学習させます。

GPU:「またですか?」

はい。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です