ドット絵三段階アーキテクチャ：画像理解、描画、画像検証の分離

（記事は中国語） 中文 →

ドット絵ツールはクリックから完了まで 100 秒かかり、遅すぎた。所要時間分析スクリプトを書き、ボトルネックが単一エージェントアーキテクチャにあることを発見した。一つのモデルが画像を見て描画し検証もする。三段階に分割後、47.8 秒で完了、52% 高速化した。

前回パレットとギャラリーを改めた後、ドット絵ツールは使えるようになったが、明らかな問題が一つあった。「描画開始」をクリックしてから作品完成まで、約 100 秒待つ必要がある。AI の描画プロセスをリアルタイムで展示するツールにとって、この待機時間は長すぎる。

ボトルネックはどこにあるのか。感覚で推測するよりデータを取る。所要時間分析スクリプトを書き、全体の描画フローをシミュレートし、各工程に正確に計時した。スクリプトは直接 LLM API を呼び出し、サーバー側の核心ロジックを複製する。WebSocket を経由しないため、ネットワークとサーバー処理の干渉を排除し、純粋に LLM 自身の応答速度を測定できる。

実行後のデータは明確だった。単一エージェントアーキテクチャでは、一つのモデルが三つの職責を同時に担う。画像を見て理解し、一マスずつ描画し、結果を検証する。画像理解にはマルチモーダル能力が必要で、描画には正確な tool call が必要で、検証にもマルチモーダル能力が必要だ。この三つを一つのモデルの同一対話に詰め込むと、毎ラウンドすべての tool call 履歴を保持する必要があり、メッセージサイズが 2KB から 18KB に膨張する。ラウンドが進むほど、毎ラウンド遅くなる。

解決策は分離だ。三段階でそれぞれ最適なモデルを使い、互いに干渉しない。

第一段階は画像理解で、MiMo V2.5 で元画像を見て、自然言語で画像内容を記述する。記述には主体が何か、キャンバス上の位置、使う色、光源の方向、どの特徴を保持すべきかを含む。この段階は LLM を一回だけ呼び出し、tool call も推論も不要で、モデルは画像を見て話すだけでよい。

第二段階は描画で、ブループリントテキストをモデルに渡し、paint と fill_rect ツールで一マスずつ描画させる。この段階は元画像を見る必要がなく、ブループリントが十分な情報を提供している。描画段階は MiMo V2.5 を使い、reasoning_effort を low に設定し、モデルに迅速な判断をさせる。毎ラウンド複数の tool call を返し、三五ラウンドで描き上げる。

第三段階は画像検証で、再び MiMo V2.5 を呼び出す。今回は二枚の画像、元画像と最終キャンバスの PNG を添付する。モデルが両者を比較し、JSON を返す。検証を通過したか、評価 1-5、一言コメント。この段階は推論不要だが、二枚の画像の視覚比較を処理する必要があり、19 秒かかり、三段階の中で最も長い。画像検証の価値はフォールバックにある。描画段階でズレた場合、少なくとも評価と理由を返せて、サイレント失敗に至らない。

三段階アーキテクチャの核心設計は、描画段階が元画像を保持しないことだ。単一エージェントアーキテクチャでは、元画像は第一ラウンド後にテキストプロンプトに置換されるが、モデルのコンテキストには画像のトークンスロットが残留する。三段階アーキテクチャは直接ブループリントテキストで元画像を代替し、描画モデルは最初からテキスト入力のみで、コンテキストがクリーンで、毎ラウンドのメッセージサイズがずっと小さい。

実測データの対比。単一エージェントアーキテクチャは 100 秒で、うち描画段階が大部分を占める。モデルは毎ラウンドますます長いメッセージ履歴を処理し、さらに推論を行う。三段階アーキテクチャは 47.8 秒。画像理解 12.9 秒、描画 15.6 秒（14 ステップ）、画像検証 19.3 秒。52% 高速化した。生成画像の品質は低下しなかった。画像検証評価 4/5、モデルのコメントは「カートゥーンカエルの突き出た大きな目とシンプルな輪郭を成功裏に再現し、参照図とブループリントと高度に一致している」。

途中で一つのトラブルにハマった。最初描画段階は DeepSeek V4 Flash を使い、その高速推論能力を活用しようとした。だが dsv4 の tool call 効率は MiMo より却って低いことが分かった。同じタスクで、dsv4 は 36 ステップ 7 ラウンド必要で、MiMo は 14 ステップ 3 ラウンドで済む。dsv4 の reasoning_effort は high と max しかサポートせず、low に下げられないため、毎ラウンドの推論オーバーヘッドが MiMo よりずっと大きい。最終的に MiMo 全行程構成（画像理解 + 描画 + 画像検証すべて MiMo V2.5）が最速だった。

もう一つ詳細がある。dsv4 の複数ラウンド tool call には特殊な要求がある。毎ラウンドの assistant メッセージは以前の全ラウンドの reasoning_content を含めなければならず、さもなくば API が直接 400 を返す。このトラブルはデバッグに時間がかかり、最終的にメッセージシーケンスに reasoning_content フィールドを追加して解決した。最終的に dsv4 は使わなかったが、この互換性は保留され、今後モデルを切り替える際にもう一度ハマらなくて済む。

コスト面では、三段階は単一エージェントより画像理解呼び出しを一回多く消費するが、描画段階のラウンド数が 10+ ラウンドから 3 ラウンドに下がり、毎ラウンドのメッセージサイズもずっと小さい。総トークン消費はほぼ横ばいで、API 費用の顕著な増加はない。

三段階アーキテクチャにはもう一つの利点がある。各段階を独立に最適化できる。画像理解段階はより強力な視覚モデルに交換でき、描画段階は異なる tool call 戦略を試せ、画像検証段階は評価基準を調整できる。三段階のプロンプトも独立で、一つを変えても他の二つに影響しない。画像検証段階の 19 秒という所要時間は次の最適化の重点だ。より軽量な視覚モデルを試すか、検証を非同期にし、先に結果を返してからバックグラウンドで検証するか。

ツールのアドレス：AI ドット絵

関連記事