Liquid AIのd1はゲームと同じPCで動かせるか

敵NPCが、追うか、隠れるか、仲間を呼ぶかを決める。こうした選択なら、長い返答を生成するAIを毎回呼ぶ必要はない。Liquid AIが2026年10月7日に公開したd1-3Bと実験版d1-omni-600Mは、あらかじめ用意した問いに、型の決まった判断を返すモデルだ。

ゲームへの組み込み経路はある。ただし、ゲームと同じPCで滑らかに動くかは別の問いになる。公開のRTX 4090で8msという値は、その保証ではない。この記事は2026年10月9日時点の公開資料を読むもので、LATENTによるモデル実行やゲーム同時測定は行っていない。

Liquid AIの公開発表

この記事の要点

1. d1は文章を生成せず、一回の推論で選択や数値を返す。NPCの行動候補や発言の意図を選ぶ用途が考えられるが、移動や攻撃の実行はゲーム側が担う。
2. RTX 4090の8msはウォームアップ済みの短い質問で、最適化ありの公表値だ。長い入力や描画との競合まで含めた遅延ではなく、同じPCでの余裕は別途測る必要がある。
3. 公式GGUFとllama.cppの経路があり、小さな量子化ファイルも配布されている。容量は実行時メモリと異なり、重みのライセンスは商用条件のあるlfm1.0だ。

NPCの判断に使うモデル

d1-3Bはテキストと画像を受け取り、600Mはテキストと画像、またはテキストと音声を扱う初期研究版だ。600Mへ画像と音声を同時に渡す使い方はできない。音声は英語の話者とアシスタントの依頼を使って学習され、30秒で切られる。日本語のゲーム内音声へそのまま一般化できるかは、別途評価が要る。

3Bの入出力仕様

600Mの入力と音声の制約

既存のStrands Deciderの記事と共通するのは、生成を省いて選択を返し、実行をアプリへ任せる設計だ。今回の関心は、その考え方を画像、さらに600Mでは音声へ広げられる点にある。モデルの系統も異なり、d1-3BはLFM2.5-VL-3B、600Mは双方向エンコーダーをもとにする。Deciderの旧版の速度と、今回の異なる機材・入力の数字を並べても、そのまま優劣は決まらない。

関連記事：Strands Deciderの仕組み

モデルが選びゲームが実行する

NPCを扱うための未実行の構成例

1 状態を絞る

体力、距離、直前の発言など、判断に必要な情報を取り出す。

2 候補を採点する

許可した行動をd1へ渡す。移動先の座標や台詞は別途用意する。

3 ルールで確かめる

現在も実行可能かを確認し、行動木や状態機械へ渡す。

8msの条件と入力が増えたときの遅延

速度表は開発元の測定値であり、ゲームとの同時実行ではない。RTX 4090の行はBF16、20回の中央値、ウォームアップ後の要求である。単一質問にはmodel.compileによるCUDA graphsを使い、未コンパイルでは16msと報告されている。新しい入力形状では初回に選択・コンパイルの負担が生じる。

公表値と測定条件：d1-3Bモデルカード

一回の推論でも、入力を読む計算は残る。3.4Kトークンで102msなら、8msの約12.8倍だ。64状態をまとめた475件/秒という値も、単独要求が約2msで返るという意味ではない。まとめ処理の待ち時間と、まとめて処理できる件数を区別したい。600Mの速度は今回公表されていないため、小さいという理由だけで3Bより速いと結論づけられない。

60fpsの1フレームは約16.7msだが、そこには描画やゲーム処理の時間も必要になる。8msを16.7msから引くだけでは、同時実行の予算を求められない。GPUの計算器、メモリ帯域、電力制限や待ち行列を共有するためだ。平均fpsが保てても、一部のフレームだけ長くなる可能性がある。

重みの容量と実行時の予算を分ける

まず重みだけの概算を置く。3Bは公称31.2億、600Mは5.87億パラメータを使い、パラメータ数×1要素のバイト数で計算した。下表は実測のVRAM使用量でも、推奨RAMでもない。GBは10億バイト、GiBは2の30乗バイトとする。

別の数字として、配布済みGGUFの3B Q4_K_M本体は1.67GB、600M Q8_0本体は407MBと表示される。これは公式配布ファイルの大きさで、全モダリティの重みや実行時の最大使用量ではない。画像・音声用のprojector、入力処理、中間計算、実行環境の領域が加わる。量子化の形式と、CPU/GPUへ何を置くかでも変わる。

3Bの公式GGUFと配布サイズ

600Mの公式GGUFと配布サイズ

上の合計は配布ファイルの表示値を足したものだ。RAMやVRAMへの配置と作業領域を含まないため、その容量だけ空ければ実行できるという必要スペックではない。

3Bのファイル一覧

600Mのファイル一覧

同じPCでは三つの資源に予算を分ける

容量に収まることと時間内に終わることは別条件

GPUのメモリ

ゲームのテクスチャと描画バッファ ＋ AIの重みと中間領域。

GPUの処理時間

描画 ＋ 推論。非同期でも同じ計算器や帯域を使う。

CPUとRAM

物理・音声・入力処理 ＋ CPU推論やモデル読み込み。

仮に8GiBのVRAMのうちゲームが6GiBを使うなら、残りは2GiBだ。3Bの16bit重み全体の概算5.81GiBは入らない。一方、1.67GBの量子化ファイルが2GiBより小さいことだけでも、収まるとは断定できない。逆にCPUへ移せばGPUの負担を減らせる可能性はあるが、今度はRAM、CPUの空き時間、転送が制約になる。これは説明用の予算例で、特定のゲームやPCの測定結果ではない。

描画を待たせない組み込み方

ゲーム側の最初の候補は、毎フレームの照準や衝突判定より、数秒おきの方針変更や会話の区切りだ。体力が減った、敵を見失った、プレイヤーが話し終えた、といった変化で要求を出す。すでに数値で決まる距離判定まで文章にしてAIへ渡す必要はない。

構成例として、描画スレッドは現在の行動を続け、別プロセスの推論へ状態のコピーを渡す。要求にNPC ID、状態の版、期限を付け、古くなった結果は破棄する。返答が遅いときは既存の行動木を続ける。無制限に要求を積まず、NPCごとの未処理要求を一つに絞れば、古い状況への判断で埋まるのを防ぎやすい。

頻度の影響も大きい。NPCが20体いて、それぞれ毎秒2回なら毎秒40要求になる。仮に一件8msで直列処理しても、計算上は1秒あたり320msの処理時間だ。これは同時実行時のGPU使用率ではない。入力や競合で一件100msになれば、同じ要求数を直列には処理しきれない。画面にいる重要なNPCへ頻度を割り当て、遠いNPCは従来ロジックで動かす設計が考えられる。

複数の質問を同じ状態にまとめることはできるが、共有すべきでないNPCの知識まで混ぜないようにする。ゲーム内部の状態を短く渡せるなら、画面を撮影して画像として解釈し直すより、入力と処理の範囲を管理しやすい。音声を使う場合は録音を待つ時間や前処理も含めて、プレイヤーが待つ時間を測る。

Pythonとllama.cppの二つの経路

PythonではTransformersとPyTorchを使う公式例がある。3BはTransformers 5.14以上、600Mは5.15以上を要求する。CPUではfloat32、GPU側は3Bがbfloat16、600Mがfloat16という例なので、同じ精度を機械的に当てない。600Mはbfloat16を避けるようモデルカードが注意している。

重みのロードにはtrust_remote_code=Trueが必要だ。配布コードを実行する設定なので、採用時にはコードと版を確認して固定する。今回、依存関係の導入や重みの取得は行っていない。

Python専用ではない。公式GGUFのREADMEは、llama.cppのllama-serverへ読み込み、/v1/systemoneへstateとquestionsを送る経路を示す。600Mでは一つの問いがバッチに収まる必要があり、例は-b 4096 -ub 4096を指定する。画像や音声には対応するprojectorも必要だ。

UnityやUnrealからローカルHTTPで呼ぶ構成は作れる。ただし、これは統合案であり、公式のゲームエンジン用プラグインを確認したという意味ではない。llama.cppへの対応追加は3Bが10月7日の88dcc46、600Mが10月8日のa657f7eで取り込まれている。その変更を含むビルドで、対象OS、専用エンドポイント、各モダリティの動作を確認する必要がある。最小リリース番号とWindowsでの実動作は今回未検証だ。

llama.cppの3B対応PR

llama.cppの600M対応PR

Hugging Faceの一般的な「Use this model」表示だけで、OllamaやLM Studioの通常チャットからこの判断APIまで使えると判断しない。確認するのは生成用のチャット画面ではなく、作者のREADMEにある専用の呼び出しだ。

llama.cppでの3Bの呼び出し

llama.cppでの600Mの呼び出し

ゲームに同梱するときの商用条件

モデルカードのライセンスはlfm1.0、正式にはLFM Open License v1.0だ。Apache 2.0をもとにした文面でも、ApacheやMITとして扱うことはできない。商用利用には年商1,000万米ドルの閾値があり、法的主体が閾値を超える場合、この契約では商用利用を許諾されない。ゲーム一本の売上だけを見て判断しない。

再配布にはライセンスの同梱、変更箇所の表示、必要な権利表示やNOTICEの保持などの条件がある。ゲームへ重みを同梱する場合と、後から取得させる場合で配布工程は違っても、商用利用条件が消えるわけではない。対象主体や契約条件を確認し、閾値を超える場合はLiquid AIへ商用ライセンスを相談する。

LFM Open License v1.0の本文と商用条件

小さく試すなら何を測るか

最初の試作なら、テキスト状態から一体のNPCの方針を選ぶ用途が適している。1〜2Hzを試行の出発点とし、場面変化でも要求を出す。これは推奨動作周波数の測定値ではなく、比較しやすい小さな構成案だ。モデルなしの同じ場面を基準に、ゲームだけ、AIだけ、同時実行の三条件を比べる。

記録するのは、要求から行動反映までの中央値とp95、初回遅延、遅いフレーム、VRAMとRAMの最大値、CPU負荷だ。短文、長文、画像を分け、量子化で判断が変わる場面も調べる。出力の確率が高いことと、NPCの行動が面白いことは別なので、行動の揺れや不自然な連続選択も見る。

ゲームと同じPCで動く可能性はある。採用を決める条件は、小さいファイルや最短遅延の一つの数字ではなく、対象PCで画面の滑らかさを保ち、必要なタイミングで有効な判断を受け取れることだ。大容量のダウンロードや負荷試験を伴うこの検証は、今回の記事制作とは別に行う作業になる。

出典と調査範囲

公開日と確認基準日は2026年10月9日。発表日は10月7日。表の遅延は開発元の公表値、メモリ表は公称パラメータ数による概算、図とNPC構成はLATENTの設計例だ。ブログと更新されるモデルカードでは評価表の構成や数値が異なるため、異なる平均値を一つの比較へ合成していない。

一次資料：d1-3Bモデルカード

一次資料：d1-omni-600Mモデルカード