1080p配信時にAIアシスタントへ残すメモリの目安

まず、すでに使われている分を計算する

AIアシスタントは真空の中で動くわけではありません。ゲーム、エンコーダー、配信そのものとハードウェアを共有します。メモリを割り当てる前に、他の参加者がどれだけ消費しているかを計算しましょう。1080pでは主な負荷はエンコーダー（GPU上のハードウェアかCPU上のソフトウェア）にかかり、さらにゲーム本体と画面キャプチャにもかかります。

実用的な目安：ゲームとエンコーダーが合わせてビデオメモリの目立つ割合を占めているなら、空きの残りはキャッシュではなくモデルに回ることになり、メモリ不足ではなく絶え間ない再配分によってカクつきが発生します。ですから「いくつ与えるか」ではなく「ゲームとエンコーダーの後にいくつ残るか」を計算してください。

ローカルモデルかクラウドか

これが最大の分岐点であり、すべてがこれにかかっています。

クラウドのアシスタントはローカルメモリをほとんど消費しません。リクエストはネットワーク経由で送られ、手元のマシンにはクライアントだけが残ります。その場合の問題はギガバイト数ではなく、回線の安定性と遅延です。配信中はアップロードがすでに使われており、アシスタントはそれを映像と分け合います。回線が細いと、アシスタントは間を置いて応答するか、配信と帯域を奪い合うことになります。

ローカルモデルは重みをビデオメモリまたはシステムメモリに常時保持します。ここではメモリは直接の出費であり、あらかじめ確保しておく必要があります。その代わりネットワーク遅延がなく、アップロードも空いています。

ローカルモデルに必要なビデオメモリ

正確な数値はモデルと量子化に依存しますが、式で計算できます。パラメータ数に保存ビット数を掛けます。4ビット量子化では、10億パラメータあたり0.5GB強を占め、さらに管理用バッファとコンテキストキャッシュのオーバーヘッドが加わります。ここからVRAMの実用的な目安は次のとおりです：

• 30〜40億パラメータのモデルを4ビットで — 約2〜3GB;
• 70〜80億パラメータを4ビットで — およそ4.5〜5.5GB;
• 130〜140億パラメータを4ビットで — 約8〜9GB;
• 300〜340億パラメータを4ビットで — およそ18〜20GB。

これらの数値にコンテキストキャッシュを加えてください。これは会話の長さとともに増え、長いやり取りでは数ギガバイト上乗せされることがあります。量子化の代わりに完全精度を使うと重みの容量は3〜4倍になり、1080p配信ではほぼ常にゲーム用のビデオメモリが残らないことを意味します。

配信用に70〜80億クラスのモデルから何を選ぶか

4ビット量子化の7〜8Bクラスは、VRAM 12〜16GBの構成にとって現実的な中間点です。配信者のチャットアシスタントとしては、Qwen、Llama、Mistral、Gemmaといったファミリーのinstruct版が検討されます。これらは上記の式で予測どおりに計算でき、公称の容量に収まります。違いはロシア語での回答品質と生成速度にあり、メモリ要件ではありません。パラメータ数はほぼ同じです。

チャットを読み、短いリアクションを提案するアシスタントなら、適度なコンテキストで7〜8Bで十分です。3〜4Bのモデルは一貫したテキストでは明らかに劣りますが、ゲーム用に2〜3GBを空けられます。7〜8Bの完全な非量子化重みは何倍も大きくなり、1080p配信の予算には収まりません。

VRAM不足とオフロード：計算がどう変わるか

重みにビデオメモリが足りない場合、一部のレイヤーはオフロードによってシステムメモリへ移動し、モデルは動作を続けます。その代償は速度です。転送はバスを経由するため推論が遅くなり、RAMとVRAMの両方が同時に消費されます。オフロードは計算を帳消しにするのではなく、消費をVRAMからRAMへ移し、応答速度を下げます。

ですから配信中に「大きめのモデルを入れてオフロードを有効にする」のはぎりぎりの妥協です。アシスタントは考えるのに時間がかかり、システムはゲームのピーク時にスワップを始めます。小さめのモデルを選び、空きの残りに完全に収めるほうがよいでしょう。

システムメモリ

モデルがCPU上で動く場合、消費はRAMへ移ります。4ビットで10億パラメータあたり同じ0.5GBにバッファを加えたものです。7〜8BのモデルをCPUで動かすと、システム、ゲーム、エンコーダーの必要量に加えて約5〜6GBのRAMを占め、CPUでの推論は明らかに遅くなります。アシスタントは体感できるほどの間を置いて応答します。1080pのソフトウェアエンコード自体がCPUに負荷をかけるため、同じCPUで推論を重ねるのはドロップを招く確実な方法です。

空きメモリをすべて与えてはいけない理由

誘惑は単純です。これだけ空いているから全部モデルに与えよう。これは間違いです。メモリはピーク時のバッファとして必要です。ゲームでのアセットの読み込み、エンコーダーのビットレートの急上昇、システムのバックグラウンド処理などです。モデルが残りを占めてしまうと、システムはスワップを始め、原因がすぐには分からないフリーズが発生します。配信のピークは最も都合の悪い瞬間、動きの激しいシーンやロケーションの切り替え時に訪れます。

ピーク時の使用メモリを何で測るか

タスクマネージャーの平均値は欺きます。必要なのは戦闘中のピークであり、穏やかな画面ではありません。

• nvidia-smiをループで更新すると、使用中のVRAMとプロセスごとの合計上限が表示されます;
• MSI AfterburnerとRivaTunerのオーバーレイは、使用中のVRAMとGPU負荷をゲーム上に直接表示します。ピークを目視で追うのに便利です;
• 内蔵の統計やドライバーのオーバーレイでも、サードパーティ製ソフトなしで同じ値が得られます;
• タスクマネージャーとリソースモニターはRAMとスワップ用です。システムがページを吐き出し始めたのがそこで分かります。

平均ではなくセッション中の最大値を見てください。モデルに何が残るかを決めるのはまさにそれです。

自分の構成に合わせて容量を選ぶ方法

1. ゲームとエンコーダーを1080pの実戦モードで起動し、nvidia-smiまたはAfterburnerのオーバーレイでピークを計測します。
2. 利用可能な容量からピークを引きます。これがピーク用の余裕を含めたモデルの上限です。
3. アシスタントを起動し、フレーム、スワップ、応答時間を観察します。
4. フリーズが出たら、まずコンテキストを短くし、次にモデルのクラスを下げるかより積極的な量子化を有効にし、ドロップとスワップが消えるまで繰り返します。

この方法は繰り返しの計測を要します。ピークはゲームやシーンによって変わります。

実際にメモリを節約するもの

メモリが不足している場合、レバーはいくつかあり、それぞれに代償があります：

• コンテキストを短くし履歴をリセットするとキャッシュ消費は減りますが、会話の流れを失います;
• 小さめのモデルやより積極的な量子化はギガバイトを節約しますが、回答品質が落ちます;
• クラウドのアシスタントはローカルメモリを完全に解放しますが、遅延とネットワーク依存が加わります;
• 1080pをハードウェアエンコーダーに移すとCPU負荷が下がり、ギガバイトの調整よりも効果的なことがよくあります;
• クライアント設定で応答長と履歴サイズを制限すると、キャッシュ消費を予測可能に保てます。

エンコーダーとコンテキストから始めましょう。これらは品質面で最も安価な対策です。量子化とモデルの縮小は、これらの手順で足りなかったときに手を付けてください。