ローカルLLMが遅すぎる。高速化する前に「待ち時間」を分解した話
この記事では、ゲーム用画像を作るImageStudioにローカルLLMとComfyUIを組み込み、待ち時間を短くしようとした開発記録をまとめます。
結論から言うと、モデルを軽くするだけでは解決しませんでした。
効いたのは「毎回LLMを使わない」「待ち時間を工程ごとに分ける」「速度より先に品質の基準を固定する」という設計の見直しでした。
「画像生成が遅い」の前に、プロンプト作成が遅かった
今回改善したのは、ADVゲーム制作ツール内で使うアプリです。
ユーザーがキャラクター、場所、構図、画角などを選ぶと、ローカルLLMが画像生成用のプロンプトへ変換し、その内容をComfyUIへ送って画像を作る仕組みでした。
流れだけを見ると、きれいに自動化できています。
`日本語で指示 → ローカルLLMでプロンプト化 → ComfyUIで画像生成 → 候補を保存`
しかし、実際に使うと、とにかく待ちます。
最初は「ComfyUIの画像生成が重いのだろう」と考えていました。ところが処理を追ってみると、画像生成が始まる前のローカルLLMにもかなり時間を使っていました。
しかも画面上では、ずっと同じ「生成中」のように見えます。
プロンプトを考えているのか。画像を描いているのか。保存中なのか。それともアプリが止まったのか。
ユーザーからは分かりません。
そこで最初に、目標時間を一つにまとめず、次のように分けました。
プロンプト変換：10秒以内
画像生成：30秒以内
保存と画面反映：できるだけ即時
「全部で何秒」ではなく、どこで時間を使っているかを分けたことで、初めて改善場所が見えてきました。
一番の無駄は、毎回ローカルLLMを通していたこと
ローカルLLMを速くする方法として、最初に思いつくのはモデルの軽量化です。
小さいモデルへ変える。量子化する。常駐させる。最初に読み込んでキャッシュする。
もちろん、これらも有効です。
ただ、今回もっと大きな問題だったのは「本当にLLMが必要な処理なのか」を考えず、ほぼすべての入力をLLMへ渡していたことでした。
たとえば、ユーザーが画面上で次の項目を選んだとします。
キャラクター：プロジェクトに登録済み
服装：登録済みの普段着
場所：川沿いの堤防
構図：振り向き
画角：バストアップ
これらは、すでに意味が決まったデータです。
毎回LLMへ渡して、美しい文章に書き直してもらう必要はありません。決められた順番で画像生成用のタグへ変換すれば済みます。
LLMが賢いからといって、すべてを考えさせる必要はなかったのです。
プリセットは即時変換、自由記述だけAIに任せる
そこで、ImageStudioの入力を5項目へ整理しました。
キャラクター
服装
場所
構図
画角
キャラクターと服装は、ゲームのプロジェクトに保存された設定から取得します。場所、構図、画角はシステム側のプリセットから選びます。
これらの選択情報は、決められたテンプレートで即座にプロンプトへ組み立てます。
一方、「夕焼けの河川敷で振り向きざまに微笑む」のような自由記述だけは、そのままでは画像生成モデルに伝わりにくい場合があります。
そこで自由記述のときだけ、プロンプト変換用のSlopPromptを通すようにしました。
つまり、次のように役割を分けました。
`プリセット選択 → ルールで即時変換`
`自由記述 → SlopPromptで画像向けに変換`
`変換後 → ComfyUIで生成`
AIを高速化したというより、AIを呼ばなくていい場所から外した形です。
この変更は、処理時間だけでなく、生成結果の安定にも効きました。
LLMへ毎回自由に文章を作らせると、同じ設定でも表現が微妙に変わります。すると、服装の細部やキャラクターの特徴が抜けたり、背景の説明が強くなりすぎたりします。
テンプレートで固定できる情報は固定する。創造的な解釈が必要な部分だけLLMへ渡す。
この境界を決めることが大切でした。
1024×576では約20秒。でもサイズを上げると37.1秒
画像生成側では、まず速度を測れる基準を作りました。
初期の軽量設定は、1024×576、20 steps、CFG 4.5です。実際の画面から「夕焼けの河川敷で振り向きざまに微笑む」という内容を生成すると、約20秒で完了しました。
30秒以内という目標には入っています。
ところが、画像を1280×720へ上げると、実測は37.1秒でした。
たった少し画像を大きくしただけに見えても、生成で扱う画素数は増えます。品質を上げるためにstepsやLoRAを追加すれば、さらに時間がかかります。
ここで、内部では少し小さく生成し、最後に拡大する案も検討しました。
しかし、速度だけを見て設定を削っていくと、別の問題が起きました。
キャラクターがぼやける。線が細くなる。目の形や服装が変わる。背景の指示を強くすると、人物の再現度が落ちる。
数字上は速くなっても、欲しい画像ではなくなってしまったのです。
速度を追いかけたら、画質の基準を見失った
開発途中では、プロンプトを短くし、LoRAを減らし、解像度も調整しました。
処理を軽くする方向としては間違っていません。
ところが、もともとComfyUI単体で生成したときには、納得できる画像が出ていました。それをアプリへ組み込む過程で、長い汎用指示やキャラクター設定、速度対策を足していくうちに、画質が崩れていきました。
そこで一度、秒数制限を外しました。
まずComfyUI単体で成功したワークフローを「正解」として固定する。そこへキャラクター、服装、場所、構図を一つずつ追加し、崩れた時点で戻す。
速度を測るのは、品質が安定した後です。
この順番に変えたことで、「速いけれど使えない画像」を完成扱いするのを避けられました。
ローカルAIでは、どうしても秒数やVRAM使用量に目が向きます。
でも制作ツールの場合、一番速い設定が一番良い設定とは限りません。作り直しが増えれば、最終的な制作時間はむしろ長くなります。
実際の時間を縮められなくても、体感は改善できる
もう一つ大きかったのが、画面側の問題です。
処理が20秒でも、何も変化しない20秒はかなり長く感じます。
逆に、今どの工程にいるか分かれば、同じ20秒でも待ちやすくなります。
今回の画面では、少なくとも次の状態を明確に扱うようにしました。
生成処理が始まっている
実行中は生成ボタンを無効にし、連打を防ぐ
入力不足なら、生成できない理由を表示する
完了後は、候補画像と生成レシピが保存されたことを表示する
特に重要なのが、ボタンを押した直後の反応です。
何も変わらないと、ユーザーは「押せていなかったかも」と考えて、もう一度押します。すると同じ生成処理が重複し、GPUの待ち行列が増え、本当に遅くなります。
処理中であることを表示し、二重実行を防ぐだけでも、無駄な待ち時間を減らせます。
これはLLMやComfyUIの速度とは関係ありません。
でも、ツールの使いやすさには大きく影響します。
作ってみて分かった、ローカルAI高速化の順番
今回の改善で、ローカルAIツールの待ち時間に対する考え方が変わりました。
以前は、まず軽いモデルや高速な生成設定を探していました。
今は、次の順番で考えるようにしています。
待ち時間を工程ごとに計測する
LLMを使わなくていい処理を外す
成功している品質を基準として固定する
現在の処理状態を画面に表示する
その後で、モデル・解像度・stepsを調整する
特に大切だったのは、「AIを使うこと」と「AIを毎回使うこと」は違う、という点です。
決まった選択肢はルールで処理する。自由な解釈が必要なときだけLLMを呼ぶ。画像生成は、品質を確認できたワークフローを崩さず使う。
この構成にした方が、速くて、安定していて、結果も予測しやすくなります。
ローカルLLMが遅いとき、すぐにモデルを入れ替える必要はないかもしれません。
その前に、「この処理、本当にLLMへ考えさせる必要があるか？」を確認してみる。
そして、どうしても待つ処理なら、何をしている時間なのかを見せる。
高速化は、モデル選びだけではなく、処理の分け方と待たせ方まで含めた設計なのだと実感しました。
この記事が参考になったら「スキ」をお願いします。ローカルAIやComfyUIで困っている待ち時間があれば、コメントで教えてください！
いいなと思ったら応援しよう！
僕の記事に価値を見出してくれた…そのチップという名の『覚悟』、心に響きました。あなたからの応援は、より良い記事を作るための『黄金の風』にしてみせます。後悔はさせません、心からグラッツェ！