仮説: セーフガードを外したら、ニッチ需要は大きいのでは
自分のプラットフォームのアナリティクスを眺めていて、動画生成まわりのアクションが他機能に比べて突出して多いことに気づいた。
ここから一つ仮説が立った。汎用 AI チャットや専門家コラボみたいな領域は、Anthropic / OpenAI / Google といったサプライヤーとのコスト勝負になり、個人が同じ土俵で殴り合っても勝てない。一方、大手が規約上どうしても踏み込めない「セーフガードを外した自由な創作」——ここは frontier モデルが原理的に避けるので、個人にこそ残っている隙間なのでは。動画生成への関心の高さと重ねると、ニッチだが厚い需要が眠っている可能性がある。
この仮説を検証するために、検閲を持たない community fine-tune モデルを実際に動かして比較してみることにした。以下はその実験ログと、最終的に「I2V を主力に据える」という結論に至るまでの試行錯誤。
（この記事は SFW で通す。露骨な作例と生々しい detail は末尾ゲートの奥に「包み隠さない版」として置いた。）
実験: 何をどう比較したか
ローカル GPU（RTX PRO 6000 Blackwell, 96 GB）一枚に、ベース checkpoint と community fine-tune を並べ、同一プロンプト集 × 複数モデルで fair に比較する方式を組んだ。画像生成で先にやっていた A/B 手法（curated プロンプト → 横並びコンタクトシート → 勝てる領域を特定）を動画にそのまま移植した形。
検証したのは大きく 2 軸:
- モデル間の A/B（汎用ベース vs community fine-tune）— どのモデルがどの領域で勝つか
- 生成経路の比較（T2V = テキスト→動画 vs I2V = 静止画→動画）— 安定供給にどちらが向くか
分かったこと
| 比較軸 | 結果 |
|---|---|
| ベース vs community fine-tune | ベースは物理整合性が強い（破綻が少ない）。fine-tune は表現の自由度が広い代わりに汎化を一部犠牲にし、人体の崩れが出やすい |
| T2V（テキスト→動画） | seed ガチャと人体破綻が出やすく、安定供給に向かない。当たりを引くまで試行 + プロンプト調整が前提 |
| 複数人のシーン | 2 人以上のインタラクションは肢体が人物間で混線して崩壊。まず solo（単体被写体）で品質を確立すべき |
| 解像度 | 高解像度ほど細部・人体の整合が改善する（"高画素数が正義"）。低解像度 → 後段アップスケールでは情報が戻らない |
| anatomy negative prompt / seed | 崩れにくい seed を選ぶ + 「extra fingers / fused limbs / distorted anatomy …」系の negative を効かせると solo の安定が上がる |
結論: 主力は I2V
T2V の seed ガチャと破綻を、プロンプトと negative でいくら抑えても「安定供給」には届かない。そこで発想を変えた。
綺麗な静止画を先に作り込み、それを I2V でそっと動かす。 起点（静止画）の anatomy がすでに正しいので、クリップを通して破綻が構造的に起きにくい。実際フレームを追うと、元画像の整合性を数秒の動画を通して保持できていた。T2V のガチャを経路設計で回避できる、という手応え。
これはロールプレイ用途の本命——「ユーザーの既存キャラを動かす」——とも完全に一致する。主力は I2V、という結論に落ち着いた。
ボトルネックは「ハード不足」ではなく「思い込み」だった
ただ I2V を高解像度で回すと VRAM が跳ねた。1024×768 で peak 83.5 GB、同居サービスと一緒だと OOM。「96 GB 一枚じゃ実用は無理かも」と半分諦めかけた。
ところが追い込んだら、ハードの問題ですらなかった。推論ハーネスの 1 行——no_grad のスコープの外で遅延 decode が走り、不要な autograd グラフが 54 GB 食っていただけ。直したら 83.5 GB → 29.5 GB、しかも 2048×1536（3.1 MP）でも 33.6 GB で回るようになった。「高画素数が正義」を VRAM の天井に怯えず追える状態になった。
（この切り分け——フェーズ別に peak を測って真因を特定する手順、最初に試して外した「VAE tiling 細分化」の寄り道まで——は技術記事に分けて書いた → 高解像度 I2V が OOM する → 実は no_grad の外で decode してただけだった話）
個人開発はリソースが限られるからこそ、「足りない」を計測アーティファクトのまま受け入れると、本当はできることを諦めてしまう。この一件はそれを痛感した。
本番でユーザーを止めずに実験する — GPU の交通整理
ここが地味だが効いている工夫。GPU は 1 枚しかなく、そこを ユーザー向けの生成（画像・動画・音声）と、自分の実験・ベンチが奪い合う。重い拡散ジョブを無防備に同時実行すれば即 OOM するし、ユーザーのリクエストを巻き添えにする。本番上で実験する以上、ここを捌けないと話にならない。
やったことは交通整理:
- 重いジョブ用の単一ロック（セマフォ, 同時実行 1） を置き、画像生成・動画生成・ベンチの全部を同じ枠で直列化する。GPU 上で重い拡散が一度に 1 件しか走らないので、OOM が構造的に起きない。
- 優先度: ユーザーの課金ジョブが待っていれば、自分の実験（free 扱い）は枠を譲る。拡散は途中で中断できないので preempt はせず、「次に空く 1 枠を必ずユーザーに渡す」方式にした。
- 外から叩く実験も同じ枠を取りに行く: ローカルで回すベンチ/CLI も、HTTP の permit broker 経由で同一のロックを取得する。プロンプトごとに permit を取って解放するので、ベンチの合間にユーザーのリクエストが割り込める。
- 泥臭い後始末: 一度、ベンチがクラッシュして permit を握ったまま leak し、全生成が hang する事故を起こした。そこから「5 分で放置 permit を自動回収する TTL リーパー」を足した。事故ってから足す典型的なやつ。
この交通整理があるから、「本番でユーザーを止めずに、裏で実験を回す」が成立している。個人運営でメンテ停止＝機会損失なので、ここはサボれない。
いま動いている状態
- 高品質な静止画 → I2V で動かす経路が 30 GB 級で安定。画像・音声スタックと競合せず共存。
- 解像度を上げても peak はほぼ横ばい。高解像度を常用できる。
- 複数モデルをリクエストごとに切り替えて A/B する仕組みを本番に組み込み、刺さるレシピを本番上で詰めている段階。
大手が降りた領域を、個人が、GPU 一枚で。ボトルネックが「思い込みだった」と分かるたびに、この賭けの勝ち筋が少しずつ太くなる。
包み隠さない版（NSFW・閲覧注意）
ここまでは SFW で通した。実際にどの community モデルを使い（base / Sulphur / 10Eros）、どんな出力が出て、どこまで実用になっているのか——比較動画と生々しい detail を含む真実版を別ページに用意した。本当に見たい人だけどうぞ。
🔞 真実版を見る（NSFW・閲覧注意）→ 成人向けの作例を含みます。18 歳未満の方、露骨な表現を望まない方は開かないでください。
このプラットフォーム（kotonia.ai）は、音声 × 動画の没入ロールプレイを個人で開発・運営しています。