「結城のあ」は、ローカルで動く大規模言語モデル（LLM）を頭脳にしたAITuberです。ChatGPT のような外部APIを使えば実装は楽ですが、配信中はずっと喋り続けるため、API課金が積み重なりますし、応答内容も自分でコントロールしづらくなります。そこで、推論まで含めてすべて自宅の機材で完結させる方針にしました。この記事では、その全体構成を順番に説明します。
使っているハードウェア
頭脳を動かしているのは Minisforum UM790 Pro という手のひらサイズのミニPCです。CPU内蔵のGPU（Radeon 780M iGPU）を使い、メインメモリの一部をGPUと共有する構成で、専用のグラフィックボードは積んでいません。消費電力が小さく、常時稼働させても電気代が穏やかなのが個人運営にはありがたいところです。
- 本体: Minisforum UM790 Pro（Ryzen 9 7940HS 系）
- GPU: Radeon 780M iGPU（メモリは本体の32GBから共有）
- 推論バックエンド: Vulkan（Mesa/RADV ドライバ経由でiGPUを使う）
専用GPUを積んだマシンに比べれば推論は速くありませんが、後述するモデル選びと組み合わせることで、配信に耐える応答速度を確保しています。
会話モデル: Gemma 4 26B MoE
会話の中心に据えているのは Gemma 4 26B MoE をベースにした noa というカスタムモデルです。MoE（Mixture of Experts）は、巨大なモデルでも実際の推論時には一部の「エキスパート」だけが動く仕組みで、26B というパラメータ規模のわりに、推論で実際に使われるのは 4B 程度に抑えられています。これが、非力なiGPUでも実用的な速度を出せている大きな理由です。
- モデル: Gemma 4 26B MoE（ライセンスは Apache 2.0）
- コンテキスト長: 256K トークン（長い会話履歴や記憶を渡せる）
- アクティブパラメータ: 約 4B（推論時に動く部分）
- 実測の生成速度: おおよそ 14 トークン/秒
14トークン/秒は、人がチャットを読む速度とだいたい釣り合うくらいです。配信では音声合成のほうにも時間がかかるので、このくらいの速度でも会話のテンポは十分保てます。
推論エンジン: Ollama を Vulkan で
モデルの実行には Ollama を使っています。Ollama は Modelfile という定義ファイルから、システムプロンプトやパラメータを組み込んだカスタムモデルを作れるのが便利です。「結城のあ」の口調や性格は、この Modelfile のシステムプロンプトで方向づけしています。
Ollama は Vulkan バックエンドで Radeon 780M を使うように設定しています。重要なのが keep_alive の扱いです。デフォルトだとモデルは一定時間でメモリからアンロードされてしまい、次の発話のたびにロードし直して数秒の待ちが発生します。配信では致命的なので、モデルを常駐させる設定にしています（この詳細は 自宅k3sの記事 で扱います）。
APIサーバー: FastAPI が司令塔
配信ソフトやチャット画面から届く発話は、Python の FastAPI で書いたコアAPIがすべて受け取ります。ここが「結城のあ」の司令塔で、ひとつの発話に対して次のような流れを回します。
- ユーザーの発話を受け取る
- 長期記憶（RAG）から関連する記憶を検索する
- 短期記憶（直近の会話履歴）を取り出す
- それらをまとめてプロンプトを組み立て、Ollama に投げる
- 返ってきた応答を、テキスト・感情・音声合成パラメータに分けて配信側へ返す
長期記憶には PostgreSQL + pgvector、短期記憶には Redis を使っています。記憶まわりの仕組みは RAGの記事 で詳しく書きました。
肝になる設計: 感情を「単一のLLM呼び出し」で出す
AITuberは、ただ喋るだけでなく表情も動かしたいところです。素朴に作ると「①返答を生成する → ②その返答の感情を別途分類する」と2回モデルを呼びたくなりますが、それでは応答が遅くなり、iGPUには負担が重すぎます。
そこで「結城のあ」では、返答テキストと感情を一度のLLM呼び出しで同時に出す設計にしています。モデルには、自然な返答文に加えて感情ラベル（喜び・困り・驚きなど）を含む構造化された出力（JSON）を返すよう指示しています。APIはその出力をパースして、テキストは音声合成へ、感情ラベルは表情制御へと振り分けます。
なぜ1回にこだわるか
iGPUでの推論はLLM呼び出し1回ぶんが一番のボトルネックです。感情分類のために呼び出しを2回にすると、単純に応答時間が倍近くになります。出力フォーマットを工夫して1回にまとめるだけで、体感のテンポが大きく変わります。
この感情ラベルが、最終的に VTube Studio の表情切り替えにつながります。表情制御の実装は VTube Studio の記事 をご覧ください。
配信時の構成
配信のときだけ、デスクトップPC側で次のソフトを立ち上げます。頭脳（ミニPC）と表示（デスクトップPC）を分けることで、推論の負荷が配信の描画に影響しないようにしています。
- VTube Studio: 「結城のあ」のキャラクターを画面に表示し、表情を動かす
- VOICEVOX: 返答テキストを音声に合成する（感情ごとにパラメータを変える）
- OBS: 配信そのものの映像をまとめて出力する
視聴者からのコメントは YouTube ライブのチャットから取り込んでいます。取り込みには pytchat を使っていて、その実装上の注意点は別の機会にまとめたいと思っています。
まとめ
「結城のあ」は、特別なGPUを積まない小さなミニPCでも、モデル選び（MoEで実効パラメータを抑える）と設計の工夫（感情を1回の呼び出しで出す）で、配信に耐えるAITuberが作れることを示す試みです。各パーツの詳細は個別の記事に分けて書いていきます。
続けて読む: 自宅k3sでAI基盤を組む ／ pgvectorで長期記憶を持たせる ／ VTube Studioの表情API
「結城のあ」と実際に話してみたい方は noa.aituber-tkg.com へどうぞ。