RTX 5090環境におけるAITuber開発ログ：vLLMからllama.cppへの移行とContext Window最適化の検証
1. はじめに
本プロジェクトの目的は、RTX 5090のVRAM 32GBを最大限活用し、低遅延かつマルチモーダル（視覚・聴覚・発話）なAITuberシステムをローカル環境で構築することです。
ハイエンドGPUの導入により、単に大規模モデルを動かすだけでなく、「Brain（思考）」「Vision（視覚）」「Avatar（表情）」を1台のPCで完結させることを目指しました。本記事では、その構築過程で直面したソフトウェア選定の課題と、パフォーマンスチューニングの知見をまとめます。
最終的なシステム性能（実測値）
快適なリアルタイム会話を実現するための技術要件として、「人間の発話速度を超える生成速度（30 TPS以上）」 と 「違和感のない応答速度（3秒以内）」 を設定し、検証を行いました。
以下は、最適化後の環境における測定結果です。
| 指標 | 測定値 | 要件（目標値） | 判定 |
|---|---|---|---|
| LLM推論速度 | 70.92 tokens/s | 30 TPS | ✅ 達成 (236%) |
| Vision推論速度 | 6.47 tokens/s | 5 TPS | ✅ 達成 (129%) |
| TTS応答時間 | 0.50秒 | < 0.5秒 | ✅ 達成 |
| E2E応答時間 | 1.91秒 | < 3.0秒 | ✅ 達成 |
| VRAM使用量 | 25.5GB / 32.6GB | < 30GB | ✅ 許容範囲内 |
2. システム構成とアーキテクチャ
計算資源を要する推論処理をWSL2（メインPC）に集約し、デバイス制御や描画が必要な層をWindowsネイティブで動作させるハイブリッド構成を採用しました。
構成のポイント:
- VRAM配分: メインPCの32GB VRAMには、LLM、Vision、LivePortraitを集約。
- サブPC活用: 音声合成（TTS）と音声認識（ASR）をサブPCへオフロードし、メインPCの負荷を分散。
- SSHトンネリング: WSL2のネットワーク制約を回避するため、SSH Port Forwardingを用いてサブPCと通信。
3. 課題：WSL2環境におけるvLLM運用のボトルネック
当初、推論エンジンとしてvLLMを採用しました。vLLMは高スループットで知られますが、今回の「WSL2 + シングルユーザー（AITuber）」という環境下では以下の課題に直面しました。
-
起動時間の長さ:
Qwen3-32B-AWQモデルのロード時、CUDA Graph構築等を含め起動完了までに50分以上を要するケースが発生しました。開発時の試行錯誤において、このリードタイムは致命的でした。 -
メモリ管理の挙動:
プロセス終了後もVRAMが解放されない現象（メモリリーク）が頻発し、WSL2自体の再起動が必要となる場面が多く見られました。
4. 解決策①：llama.cppへの移行
上記課題に対し、推論バックエンドを llama.cpp（llama-server） へ移行しました。
移行後の変化
| 項目 | vLLM (WSL2) | llama.cpp (WSL2) |
|---|---|---|
| 起動時間 | 51分以上 | 30〜60秒 |
| VRAM使用量 | 28GB (AWQ) | 15GB (IQ3_M) |
| 安定性 | 不安定 | 安定稼働 |
採用した起動スクリプト
llama.cppのサーバーモード（llama-server）を使用し、以下のような構成で起動しています。
#!/bin/bash
# Brain Server起動スクリプト例
LLAMA_SERVER="./llama.cpp/build/bin/llama-server"
MODEL_PATH="$HOME/models/Qwen_Qwen3-32B-IQ3_M.gguf"
$LLAMA_SERVER \
--model "$MODEL_PATH" \
--port 8000 \
--host 0.0.0.0 \
--ctx-size 8192 \ # 後述の最適化ポイント
--batch-size 512 \
--ubatch-size 512 \
--flash-attn on \ # Flash Attention有効化
--n-gpu-layers 99 \ # 全層GPUオフロード
-np 2 # 並列スロット数
量子化モデルの選定 (IQ3_M)
32GBのVRAM内に全てのモデルを収めるため、モデルの量子化レベルを調整しました。検証の結果、IQ3_M（約14GB）を採用することで、Q4_K_Mと比較しても会話性能を維持しつつ、VisionモデルやLivePortrait用のVRAM領域（約6GB分）を確保することに成功しました。
5. 解決策②：Context Windowサイズと推論速度の関係
llama.cpp移行後に行ったベンチマークで、Context Windowサイズ（--ctx-size）の設定が推論速度に劇的な影響を与えることが判明しました。
検証データ：ContextサイズによるTPS比較
同じ1700トークンのプロンプトを入力とした場合の比較結果です。
| Context Window設定 | 推論速度 (TPS) | 備考 |
|---|---|---|
| 16384 | 0.97 TPS | 実用困難 |
| 8192 | 53.0 TPS | 約53倍の高速化 |
考察
llama.cppはContext Windowサイズに応じてKV Cache用のVRAM領域を事前確保します。必要以上に大きなサイズ（16kや32k）を指定すると、VRAM圧迫や計算コストの増大を招きます。
AITuberのような対話用途では、過去ログを含めても4096〜8192トークン程度で十分なケースが多く、この値を最適化するだけで劇的な性能向上が得られました。
6. まとめ
RTX 5090のハードウェア性能を活かすためには、適切なソフトウェア選定とパラメータチューニングが不可欠でした。
- 推論エンジンの適材適所: WSL2環境においては、llama.cppの柔軟性と起動速度が開発効率と安定性に大きく寄与しました。
-
Context Windowの適正化:
--ctx-sizeは単なるバッファサイズではなく、推論速度に直結する重要パラメータであることを確認しました。 - VRAMリソース管理: 量子化（IQ3_M）とモデル構成の工夫により、32GB VRAM内にマルチモーダルシステムを統合できました。
本記事の記録が、ローカルLLMを用いたアプリケーション開発に取り組む方の参考になれば幸いです。
参考リンク
- llama.cpp: https://github.com/ggerganov/llama.cpp
- Qwen3: https://github.com/QwenLM/Qwen
- Style-Bert-VITS2: https://github.com/litagin02/Style-Bert-VITS2
- LivePortrait: https://github.com/KwaiVGI/LivePortrait
Discussion