ローカルLLMを使って画像を100枚処理した。
やっていることは単純だ。
1枚ずつ画像を送り、結果を受け取る。
それだけのはずだった。
しかし途中から、メモリが異様な挙動を見せ始める。
そして最終的に行き着いた結論は、少し意外なものだった。
「APIはステートレスでも、推論エンジンはステートレスではない」
![タスクマネージャで[メモリ使用量]が徐々に積み上がっていく様子](https://b.aries67.com/wp-content/uploads/2026/05/image.webp)
起きた問題｜“ステートレスなはず”の処理でメモリが膨らむ
・画像を1枚ずつ送る単純ループ
・会話履歴は送っていない
・毎回独立リクエスト
それにも関わらず、
・LM Studioのメモリ使用量が増え続ける
・一定数で不安定化
・モデルをオフロードすると一気に解放
つまり、
内部で何かが保持されている
検証で分かったこと｜設定では完全には止まらない
試したこと：
・Context長を削減
・Unified KV Cache OFF
・GPUオフロードOFF
結果：
・増加は緩やかになる
・しかし完全には止まらない
さらに、
Contextを2048にした場合は安定したが、実際は
推論が失敗していただけ（トークン不足）
原因の正体｜KVキャッシュと内部バッファ
ログから見える事実：
request (3002 tokens) exceeds contextつまり画像1枚で数千トークンを消費している。
ここで重要なのは、
・KV cache（注意機構の中間状態）
・画像埋め込み
・推論バッファ
これらが
リクエスト単位で完全に解放されていない
可能性が高いという点だ。
なぜUIでは問題が起きないのか
LM StudioのUIでは、
・New Chat
・Clear Context
で問題が起きない。
これは内部的に
セッション（slot）をリセットしている
ためと考えられる。
しかしAPIでは、
・同じモデルインスタンス
・同じslotの再利用
が行われている可能性が高い。
APIはステートレスでも、実装はステートフル
ここが今回の核心。
API設計 → ステートレス
実装 → ステートフルこれは矛盾ではなく、
高速化のためのキャッシュ戦略
としては正しい。
ただし、
・対話用途 → 有利
・バッチ処理 → 不利
というトレードオフがある。
エージェンティックAIとの相性問題
エージェント的な処理では、
・長時間稼働
・多数の独立タスク
・完全な状態リセット
が必要になる。
つまり必要なのは
「毎回クリーンな推論環境」しかしLM Studioは
「状態を内部で最適化して使い回す設計」このズレが今回の問題の正体。
対策｜どう使うべきか
実用的な解：
・一定件数ごとにモデルをリセット
・処理を分割して実行
・もしくは別プロセスで分離
あるいは、
・llama.cpp server
・vLLM
など、
状態制御が可能なランタイムを使う
結論｜問題はLMではなく“実行環境”
今回の結論はシンプルだ。
LM Studioは優れたツールだが、用途を選ぶ
・対話 → 非常に優秀
・検証 → 十分便利
・エージェント処理 → 不向き
これは欠点というより、
設計思想の違いだ。
設計原則｜ローカルLLMを“安全に”使うための3つの前提
今回の検証から見えてきたのは、単なるツールの相性ではない。
ローカルLLMを扱う上での、基本的な設計原則だ。
1. 推論は「関数」ではなく「プロセス」である
呼べば消える存在ではない内部には、
・キャッシュ
・バッファ
・状態
が存在する。
そのため、長時間の連続処理では、必ず何かが蓄積する。
2. 状態は“外で持つ”
エージェント設計では、
状態をモデルに持たせないこれが重要になる。
・履歴 → DB
・進捗 → ログ
・中間結果 → ストレージ
モデルはあくまで「1回の推論」に閉じ込める。
3. 推論環境は「使い捨て」を前提にする
最も重要な考え方がこれだ。
長時間動かし続ける前提にしない・一定件数で再起動
・プロセス分離
・セッションリセット
これを前提に設計することで、安定性は一気に上がる。
まとめ
ローカルLLMは「関数」ではない。
単に呼べば消える存在ではない。
その裏には、
・状態
・キャッシュ
・最適化
が存在している。
そしてエージェント時代に求められるのは、
モデルの賢さではなく、状態の制御能力
なのかもしれない。
