Windows向けの手順書作成アプリに、画面を読み取るVision機能を追加していたときの話です。

モデル単体が動くことは確認できました。ただ、それだけではアプリに組み込んだときのメモリ使用量は分かりません。当時は、文章補正とVisionで別のモデルを使う構成を検証していたためです。

今回は、2026年9月の検証記録から、単体・同時実行・逐次実行を分けて確認した過程を整理します。新しく測定した結果ではありません。また、文章整形とVisionを一つのモデルに統合した現在の構成とは異なる、当時の二モデルPoCの話です。

1. Vision単体が動いても、もう一つのモデルがいる

当時の構成は、文章補正がQwen2.5とONNX Runtime GenAI、VisionがQwen3.5-2Bでした。

文章補正とVisionを別々に動かした記録と、実際に同時実行した記録は次のとおりです。

ここで避けたかったのは、Vision単体の値を、そのまま二つのモデルが動く構成の必要量として紹介することでした。

逆に、単体の値を足した計算だけで済ませたわけでもありません。同時実行の7.09 GiBは、当時の報告にある実測合計です。単体値の測定タイミングと、同時実行中にピークを迎えるタイミングは同じとは限りません。単体値の足し算と、実際の同時実行の観測は分けて扱います。

2. 二つを順番に動かす場合も測った

次に、文章補正とVisionを順番に動かす構成を測りました。

検証記録では、次の順序です。

逐次実行の報告上のピークは5.82 GiBでした。

実行方法	報告上のピーク・実測合計
同時実行	7.09 GiB
文章補正終了・メモリ回収確認後にVisionを開始	5.82 GiB

今回の記録では、二つの処理を重ねない構成のほうが低い値でした。ただし、この比較だけで「逐次実行がいつでも有利」とは決められません。利用者が待つ時間や、連続して処理するときの挙動も含めて判断する必要があります。

当時の報告には逐次実行の所要時間もありますが、ここでは速度比較の表にしません。同時実行側の対応する時間、繰り返し回数、ばらつきまでそろえて示せないためです。

また、今回参照した記録だけでは、回収を確認した具体的な実装や測定間隔までは説明できません。特定の解放処理を呼べば同じ結果になる、という実装手順にはしないことにしました。

もう一つ注意したのは、観測したメモリの値を、そのままPCの搭載RAMの最低条件にしないことでした。

当時の記録にも、Working Setの実測値を搭載RAMの最低要件と断定しない、という注意を残しています。

WindowsのWorking Setは、プロセスの仮想アドレス空間のうち、その時点で物理メモリに存在するページを指します。予約したメモリ量や、PC全体の搭載容量とは別の指標です。Microsoft Learn：Working Set

加えて、今回の記録では、集計したプロセスの範囲や共有ページの扱い、測定間隔を十分に追える形で示せていません。7.09 GiBをOSやほかのアプリまで含むPC全体の使用量だと言い換えることも避けます。

「検証時にこの値が観測された」と「この容量のPCなら十分に使える」は、別々に確認すべきことでした。

同じような比較をするなら、結果の数字と一緒に次を残しておくと、後から判断しやすくなります。

これは、今回すべて取得できていた項目の一覧ではありません。記録の不足を踏まえた、次に比較を行うときの確認項目です。

モデル単体のメモリ使用量は、構成を考えるための出発点になります。ただ、アプリで複数の処理を動かすなら、同時に動くものと動かす順番を含めて確認する必要があります。

今回の検証では、モデルの選び方だけでなく、処理を重ねるかどうかも、メモリを考えるうえで分けて測るべき条件になりました。