5年越しに、俺は96GBのVRAMを手に入れた ― エージェントループが回る GPU の話
RTX PRO 6000 Blackwell Max-Q を買った。
96GB VRAM、Blackwell 世代、プロ向けワークステーション GPU。Max-Q とはいえ個人で買うには明らかに馬鹿でかい買い物だ。
最初に言っておくと、この記事は GPU 開封記ではない。
開封記なら世の中に山ほどある。ベンチマーク記事も山ほどある。「96GB を持つと、何が設計できるようになるか」を、自分のサービス（Kotonia）と動画自動生成パイプラインで実測した話を書く。
技術パートを先に置く。買った話は後半に置く。順番が逆だと「ポエム長すぎ」で離脱されるので。
96GB は「複数モデルが載る」ではなく「エージェントループが回る」
世の中の GPU レビュー記事の多くは「単一モデルベンチ」で終わる。LLM が何 tokens/s 出る、Stable Diffusion が何秒で出る。それは別に間違いじゃないけど、個人開発で 96GB を買う意味の本質はそこじゃないと思う。
俺がやってる音声ロールプレイ + 絵コンテ→動画パイプラインを例に取る。1 つのリクエストで時間軸上に複数の重いモデルが点火する。
時間軸 →
[Stage A] Gemma 4 31B NVFP4 (38 GB) ← 構造生成 (orchestrator)
[Stage B] HiDream-O1-Image (~20 GB) ← 5 枚一貫画像 (T2I + edit x5)
[Stage C-1] Irodori-TTS / Qwen3-TTS ← 6 beat 分音声
[Stage C-2] Ditto talkinghead (3 GB) ← 会話 beat
[Stage C-3] LTX-2 A2V (peak 24 GB) ← reaction beat
[Stage C-4] Qwen3-ASR ← 生成動画の音声チェック
[Stage C-5] Gemini 3.1 Pro Preview (API) ← multimodal editorial
↓ feedback
[--regen-beats N] で beat 単位再生成 ← ループ
ここで肝なのは、reviewer → regen のフィードバックループがあること。生成物を見て「scene 3 やり直し」と判断したら、orchestrator も画像 ref も TTS も LTX-2 もまた呼び直す。
24GB GPU だとここで詰む。1 ループの「ロード → 推論 → 解放」を毎回シリアル運用してたら、1 ループ 4 分が 10 分以上になる。エージェントループの反復速度が桁で変わる。
96GB は、これを常駐で殴れる容量。
実測してみた
実測値を貼る。RTX PRO 6000 Blackwell Max-Q（96GB）の上で動かしてる現状のサービススタックを 1 Hz で nvidia-smi にロギングして、3 つのケースを並べた。
Case D: warm idle baseline（サービス本番稼働中）
TTS server (Kokoro + Whisper): 8.9 GiB
Qwen3-TTS standard (vllm-omni): 20.1 GiB
HiDream-O1-Image: 19.4 GiB
Ditto talkinghead: 3.0 GiB
LTX-2 A2V (cold-start mode): 1.5 GiB
─────────────────────────────────────────
合計: 52.8 GiB
30 秒間トレースして完全フラット (GPU utilization 0%)。これが何もリクエストが来てない時の常駐コスト。
ローカル LLM（Gemma 4 31B）は今ここに居ない。後で出てくる Case B で起動する。
Case A: single-scene A2V を 1 本生成
「可愛い女の子がささやき声で誘惑する」最小フロー：HiDream で 1 枚生成 → Qwen3-TTS で whisper 音声 → LTX-2 A2V で結合。これ 1 本に 138 秒。
VRAM の動きが面白い：
- min 52.8 GiB（baseline）→ peak 75.0 GiB → 52.8 GiB に戻る
- delta は +22.2 GiB、LTX-2 自身が report する
peak_vram_gib=23.9 GiBとほぼ一致 - LTX-2 の山が 3 つの compute フェーズに分かれてる：stage_1 (denoiser) → release → stage_2 (high-res denoiser) → release → spatial upscaler
cold-start + fp8-cast 設計のおかげで、LTX-2 は各フェーズの直前にロードして直後に解放する。これで peak が 24 GiB に収まる（persistent モード bf16 だと 86 GiB 常駐が必要、過去記事 /articles/ltx2-cold-start-vram-coexistence 参照）。
そして 96 GiB cap には 21 GiB の余裕が残ってる。
Case B: ローカル LLM (31B) + 絵コンテ生成の共存
Qwen3-TTS を一旦停止して 20 GiB 解放、代わりに Gemma 4 31B NVFP4（42.8 GiB）を起動。それから storyboard.run（Stage A: 31B が 5 beat 構造を生成 → Stage B: HiDream が base 1 枚 + 5 beat edit）を走らせる。
ここが一番見せたい絵。VRAM が +1.9 GiB しか動かない。74.5 → 76.4 GiB でほぼフラット。
なぜか。31B も HiDream も TTS も Ditto も LTX-2 も全部常駐したままで、HiDream の per-job allocation だけが乗ってるから。GPU util のグラフを見ると 6 個の鋭い山が並んでて（base 1 + 5 beat の compute）、これが「VRAM は触らずに compute だけ走る」エージェント常駐パターンの教科書的な絵。
これが 96GB の真価。reviewer が「やり直し」と言った瞬間に、全モデルが warm 状態でレスポンスできる。
それでも越えられない境界線がある
96GB は無限じゃない。実際にやってみて見えた境界線が 3 つある。
1. 動画生成 + ローカル LLM (31B) + editorial reviewer の同居 = 無理
数字を並べる：
- 31B: 42 GiB
- LTX-2 peak: +22 GiB
- HiDream + TTS + Ditto: ~22 GiB
- editorial reviewer (Gemma 4 E4B): 20 GiB
- 合計: 106 GiB → 96 GiB cap オーバー
正攻法では入らない。editorial reviewer を Gemini 3.1 Pro Preview に逃がす設計判断はここで生まれる。
2. editorial signal は frontier model じゃないと拾えない
VRAM の制約以前に、品質の問題がある。動画の subtle bugs（音声 truncation、character voice mismatch、pacing）は local 4B では rubber-stamp になりがち。frontier multimodal model（Gemini 3.x Pro 等）は同じ動画を見て「scene 5 truncated at 'I ate p-'」と正確に指摘してくる。
過去記事 /articles/comedy-shorts-claude-gemini でその経緯を書いた。月 100-500 review でも数 $ で済むので、editorial layer は frontier API で十分合理的。
3. Qwen3-TTS の voice cloning 版 (Base) と preset speaker 版 (CustomVoice) の同時提供は不可
本来は preset speaker（instruct で「ささやき」「怒り」を指示）と voice cloning（任意の声サンプルから複製）を両方ユーザーに提供したい。両方常駐で +40 GiB が要る。Case D の 52.8 GiB に上乗せすると 73 GiB warm idle。Case A の LTX-2 peak (+22.2 GiB) で 95 GiB、cap ギリギリ。実用は難しい。
これは「96 GiB あっても、ユーザーに見せたい全機能は載らない」境界線の例。Kotonia は現状 preset speaker のみ提供、voice cloning は意図的に外している。これも一つの設計判断。
結論：「ローカル原理主義」じゃなく「使い分けの設計」
96GB は何でもローカルのためじゃない。ローカルでやるべきものを集中させるための器だ。
- ローカルでやる: 音声生成、画像生成、動画生成、リップシンク — レイテンシ命、課金気にせず叩きたい、ループ回したい
- API に逃がす: editorial reviewer、長文 reasoning — 品質と VRAM コストの両面で frontier の方が合理的
- 諦める: voice cloning と preset speaker の同時提供 — 物理的に載らない
クラウド GPU 借りる選択肢もあった。でも時間課金だと「ループ回すほど赤字」になる。買い切りの 96GB GPU と frontier API の使い分けこそが、個人開発者が時間で殴れる唯一の戦い方だと思う。
ここに辿り着くまで
ここからは口直しのポエム。技術だけ知りたい人はここで閉じても OK。
3 万円の Chromebook で勉強してた
俺がプログラムを勉強してた頃に使ってたマシンは、3 万円の Chromebook だった。
そのときの俺には、それが手に入る現実的なマシンだった。でも AI をやりたい人間にとって、3 万円の Chromebook はあまりに非力だった。
ローカル LLM どころか、少し重い開発環境ですらきつい。「いつか、ちゃんとした GPU が欲しい」と思いながら、かなり長い時間が過ぎた。
Colab でお茶を濁す日々
Google Colab も使った。無料枠や安い GPU で、なんとかそれっぽいことを試した。
動く範囲のモデルを選んで、動く範囲のコードを書いて、動く範囲の実験をした。
でも、それはずっと「お茶を濁してる」感覚だった。本当に触りたいものは載らない。少し欲張ると落ちる。セッションは切れる。毎回環境構築で時間を溶かす。
借り物の GPU、借り物の時間、借り物の実験場所。自分の夢を他人の都合に預けている感じがあった。
その間に AI はどんどん進んでいった。GPT が出て、LLM が爆発的に広がり、OSS モデルもどんどん強くなった。タイムラインには、強いマシンで OSS を試して知見を貼ってる人たちがいた。
俺もそっち側に行きたかった。
AI スタートアップに入った。でも
やっとの思いで AI スタートアップに入った。でも組織の空気としてかなりしんどいものがあって、続けられる状況ではなかった。
技術が面白くても、環境が壊れてると人間は壊れる。やっと AI に近づけたと思ったのに、そこで削られていく感覚があった。
ただ、AI そのものへの興味は消えていなかった。むしろ「自分の環境でやりたい」気持ちは強くなっていた。
フリーランスになって、震える指で購入した
その後フリーランスになり、半年ほどしてようやく「自分のための大きな投資」を考えられるようになった。
そのとき、真っ先に頭に浮かんだのが GPU だった。
普通に考えればもっと堅実な使い道はいくらでもある。貯金、税金、生活防衛資金、仕事用 PC の整備。でも何年も「マシンが弱いから」で諦めてきたことを、ここでまた「いつか買う」と言ってたら、その「いつか」はまた遠くなる。
購入ボタンを押すとき、普通に手が震えた。「本当に買うのか？」「これは正気か？」「失敗したらどうする？」
送金しようとしたら、銀行に怪しまれて送金が止まった。そりゃそうだと思う。いきなり高額な GPU を買おうとしてる。でもこっちは人生の何かを賭けてる気持ちだったので、止められた瞬間はかなり焦った。
なんやかんやあって、最終的に購入できた。届いた瞬間、これは GPU じゃなくて、俺が諦めなかった時間の塊だと思った。
何ができるようになったか（買って数週間で）
ここからは現在進行形の話。買った 96GB で何が動いてるか。
Kotonia（音声ロールプレイ）
kotonia.ai で運用してる本業プロダクト。VAD + STT + LLM + 多言語 TTS + Ditto リップシンクのリアルタイム会話パイプライン。
Qwen3-TTS（10 言語、preset speaker + instruct）と Ditto talkinghead で、デート / ファンタジー相棒 / 語学パートナー用途のロールプレイを想定。
絵コンテ → 動画自動生成パイプライン
1 アイディアから 5 beat 構造のコメディショート動画を ~4 分で自動生成。本記事の Case B の発展系。HiDream で 5 枚一貫画像、Irodori-TTS / Qwen3-TTS で音声、Ditto と LTX-2 で動画化、Gemini 3.1 Pro で editorial review。
HiDream Studio（無料公開中）
/studio で Adobe Firefly 風 3 ペイン UI を公開してる。T2I / 編集 / キャラ一貫 / 試着 / 集合写真の 5 機能。HiDream-O1-Image（OpenWeight 最高峰 T2I 2026-05 時点）を 96GB GPU 上で常駐運用してる。
Codex CLI + ローカル Gemma 4
codex exec -p gemma4 で OpenAI 互換のローカル LLM をサブエージェント化。API 課金ゼロで CLI agent が回せる。本記事の Case B で 31B を回したのもこの構成。
過去記事
このマシンを軸に書いてきた技術記事：
/articles/ltx2-22b-fp8-cast-quantization— LTX-2 を fp8_cast で VRAM 40% 削減した話/articles/ltx2-cold-start-vram-coexistence— TTS と LTX-2 を 1 枚 GPU で同居させる設計/articles/comedy-shorts-claude-gemini— Gemini を sub-agent 化したマルチモーダル拡張/articles/hidream-quality-speed-bench— HiDream を 3〜8 倍速く使うベンチ/articles/hidream-skeleton-pose-prompt— HiDream skeleton: openpose ref より prompt が強い
まとめ
RTX PRO 6000 Blackwell Max-Q を買った。
これは GPU 開封の話じゃなくて、個人開発における計算資源アーキテクチャの判断記だと思って書いた。
- 96GB の本質は「容量」じゃなく「常駐」。エージェントループが回るかどうかの境目
- それでも越えられない境界線（local LLM + 動画 + reviewer 同時稼働）がある
- frontier API への使い分けが「ローカル原理主義」を回避する鍵
- voice cloning と preset speaker の両立諦めも、設計判断の一つ
5 年ぐらい「マシンが弱いから無理」と言い続けてきた。その言葉を少しずつ過去のものにしていく。次は、これで何を作るか。