ステータス: ドラフト(2026-10-13)、一部実測値を追加(2026-10-15)。 SAM 2.1 tinyの速度・精度は、「TT Score モデル解剖」第3部の実測値(2026-10-11~12、サーバーGPUを共用していた時期およびCPUの一時Pod)を引用しました。メモリ削減のサンプルはノートPCのCPU上で直接実行しました(
code/10_memory_pool.py、数秒)。 2026-10-15の追記: 未計測としていたEfficientTAMについては、卓球台の自動検出タスクにおいてSAM 2.1 tinyと同条件で測定された値を第6節に引用しました。実際の記憶マップの滑らかさは依然として未計測です。論文の数値は原文を開いて条件とともに転記し、ハードウェアはグレードで記載しました。 作成ルール: 実測データが基本であり、測定できなかったものは「未計測」と表示します。
目次
- 1. 画像から動画へ:何がさらに必要か
- 2. 構造:流しながら記憶する
- 3. データと数値
- 4. EfficientTAM:記憶を削減して軽量化する
- 5. 制限事項
- 6. 私たちのプロジェクトとの繋がり
- 参考文献
1. 画像から動画へ:何がさらに必要か
第9部のSAMは1枚の画像をセグメンテーションします。動画において「最初のフレームで指定した物体を最後までセグメンテーションしてほしい」を実現するには、さらに2つの要素が必要です。
- 記憶:前のフレームでその物体がどのような形状だったか。物体が回転したり、一時的に遮られてから再登場したりしても、同じ物体であると認識できなければなりません。
- 速度:フレームごとに重いエンコーダーを最初から実行すると遅くなります。
RaviらによるSAM 2は、SAMの構造に メモリを組み込むことでこれら2つの課題を解決します。画像は「1フレーム分の動画」として扱われるため、同一のモデルが画像と動画の両方をセグメンテーションします。
2. 構造:流しながら記憶する
フレームは1枚ずつ順番に入力されます(ストリーミング)。各フレームで処理される内容は以下の通りです。
- 画像エンコーダー:MAEで事前学習された Hiera(第7部第6節の階層型Transformer)がフレームを特徴量に変換します。フレームごとに1回実行されます。
- メモリアテンション:今回のフレームの特徴量がまず自分自身を参照し(自己注意)、次にメモリバンクの記憶を参照します(クロスアテンション)。このようなブロックが基本で4つあります。
- マスクデコーダー:SAMと同様のデコーダーがマスクを出力します。今回のフレームに対してユーザーがクリックを入力した場合、それもプロンプトとして使用されます。物体がこのフレームに 映っているかを予測する専用のヘッドがあり、完全に遮られたフレームでは「なし」を出力することができます。
- メモリエンコーダー:今回セグメンテーションされたマスクを縮小して今回のフレームの特徴量に加え、軽量な畳み込みで混合することで、「このフレームにおいてその物体はこうであった」という記憶を生成します。
- メモリバンク:直近のフレームの記憶(基本6枚)と、ユーザーがプロンプトを与えたフレームの記憶を別々に並べて保持します(先入れ先出し)。ここに、マスクデコーダーの出力トークンから抽出した オブジェクトポインター(256次元を64次元トークン4つに分割したもの)も一緒に保持します。空間マップが「どこにどのように」であるのに対し、ポインターは「その物体が何であるか」についての要約です。
直感的には、「直近の数枚でその物体がどのように見えたか、そしてユーザーが最初に指示したシーンではどうであったかを合わせて参照して今回のシーンで検出する」ということです。ユーザーが指定したフレームの記憶を別途長期間保持することが主要な設計となっています。直近の記憶のみを保持すると、少しずつ誤差を含んだマスクが記憶となって次のフレームの精度をさらに低下させる ドリフトが発生しやすくなります。ユーザーが確認した記憶がアンカーの役割を果たします。
3. データと数値
SA-Vデータ:50,900本の動画、642,600個のマスクレット(動画内の1つの物体のフレームごとのマスクのまとまり。人間によるもの190,900 + 自動生成451,700)、3,550万個のマスク。SAMのデータエンジン(第9部)のように、モデルがセグメンテーションして人間が修正するループを動画に対して実行して作成されました。
| 項目 | 値(論文) | 条件 |
|---|---|---|
| 動画セグメンテーションのインタラクション | 従来手法よりも 3倍少ない クリックでより高精度に | 論文の概要 |
| 画像セグメンテーション | SAMよりも高精度かつ 6倍高速(130.1対21.7 FPS) | データセンター向けGPU 1枚、bfloat16、画像エンコーダーのコンパイル、バッチサイズ10 |
| 動画の速度 | Hiera-B+ 43.8 FPS、Hiera-L 30.2 FPS | 同一のGPU、バッチサイズ1 |
| 学習 | データセンター向けGPU 256枚、108時間 | モデルカード |
2024年9月にリリースされた SAM 2.1 チェックポイントの公式テーブルです(データセンター向けGPU 1枚、すべてのコンポーネントをコンパイル。論文とは測定環境が異なります)。
| サイズ | パラメータ数 | FPS | SA-Vテスト J&F | MOSE検証 J&F | LVOS v2 J&F |
|---|---|---|---|---|---|
| tiny | 3,890万 | 91.2 | 76.5 | 71.8 | 77.3 |
| small | 4,600万 | 84.8 | 76.6 | 73.5 | 78.3 |
| base+ | 8,080万 | 64.1 | 78.2 | 73.7 | 78.2 |
| large | 2億2,440万 | 39.5 | 79.5 | 74.6 | 80.6 |
J&Fは、マスク領域の重なり(J)と境界の精度(F)の平均です。サイズを約6倍に拡大しても、SA-Vにおける差が3ポイントである点が目を引きます。コードとチェックポイントはApache-2.0です。
私たちの実測値:SAM 2.1 tiny
TT Scoreでは、卓球台のセグメンテーションに最も小さいtinyモデルを実験しました(「TT Score モデル解剖」第3部)。
| 条件 | 値 |
|---|---|
| サーバーGPU、他のタスクと共用している場合(2026-10-11) | 画像エンコーディング 40ms、プロンプト予測 26ms、動画追跡対象の物体1つあたり 36~38ms/フレーム、GPUメモリ 0.68~0.96GB |
| CPUの一時Pod(2026-10-12) | フレームあたり中央値 1.14秒 |
| 卓球台のコーナー(実際の試合第12部、5フレームの中央値) | データセットマスクとの差の中央値 4.7px、90%が 11.2px |
公式テーブルの91.2 FPS(1フレームあたり約11ms)と私たちの36~38msは条件が異なります。公式テーブルは専用GPUですべてのコンポーネントをコンパイルした値であり、私たちは他のタスクとGPUを共用していました。「同じモデル」であっても、数値を引用する際は条件もあわせて記載する必要がある例です。
4. EfficientTAM:記憶を削減して軽量化する
XiongらによるEfficientTAMは、SAM 2をスマートフォンでも動作するほど軽量化することを目指しています。変更点は2つあります。
- フラットなViTエンコーダー。 階層型のHieraの代わりに、単一解像度の小さなViT(Tiny・Small、パッチサイズ16)を使用します。EfficientSAMのSAMI事前学習で初期化します。
- 粗いメモリクロスアテンション。 メモリの空間トークン(キー・バリュー)を2×2のウィンドウで 平均化して4分の1に 縮小した上でアテンションを実行します。オブジェクトポインターのトークンは縮小しません。
2番目の根拠は 局所的な滑らかさです。記憶マップにおいて隣接するセルの特徴量は互いに似通っているため、4つを平均化した1つが4つを代用してもアテンションの結果は大きく変化しないという考え方です。論文では、ある例において全体のアテンションに対する相対誤差が0.03であると示され(図3、1つの例)、4×4にさらに縮小すると精度が約1ポイント低下する一方で速度のメリットは小さかったと報告されています。
実際に試してみる:本当に滑らかであれば問題ないのか
この仮説を直接検証しました。記憶 = 32×32セル × 4枚 × 64次元、クエリ 1,024個。2種類の記憶を作成し、キー・バリューを2×2で平均化したときのアテンション出力がどれだけ変化するかを測定しました(実測値、ノートPCのCPU、7回の中央値)。
| 記憶 | キー数 | 相対誤差 | 時間 |
|---|---|---|---|
| 滑らかな記憶(近隣同士が類似する低周波な場) | 4,096 → 1,024 | 0.050 | 29.2 → 8.4ms |
| 複雑な記憶(セルごとに不規則) | 4,096 → 1,024 | 0.753 | 30.9 → 8.3ms |
時間はキー数に比例して約4分の1に削減されました。誤差は、記憶が滑らかな場合にのみ小さくなりました。EfficientTAMの削減手法はタダではなく、 「動画の特徴量は隣接同士が類似している」という仮説に賭けたものであり、その仮説が成り立つ分だけ正確です。実際の特長量がどれほど滑らかであるかはモデルやシーンによって異なり、実際の記憶マップを用いて私たちは測定していません(未計測)。
論文の数値と読み取る際の注意点
| モデル | SA-Vテスト J&F | パラメータ数 | データセンター向けGPU FPS | スマートフォン(1フレームあたり) |
|---|---|---|---|---|
| SAM 2(比較対象) | 74.7 | 8,100万 | 43.8 | — |
| EfficientTAM-S | 74.5 | 3,400万 | 85.0 | 1,010.8ms |
| EfficientTAM-S/2 | 74.0 | 3,400万 | 109.4 | 450ms |
| EfficientTAM-Ti | 70.7 | 1,800万 | 96.2 | 840.5ms |
| EfficientTAM-Ti/2 | 70.8 | 1,800万 | 109.4 | 261.4ms |
(論文の表1、1024×1024入力。「/2」はメモリを2×2に削減したバージョン。スマートフォンは2023年の上位機種。)
原文を開いてみると、2箇所で食い違いが見られます。
- 比較対象のSAM 2のサイズが曖昧である点。 表のSAM 2はパラメータ数が8,100万(base+サイズ)ですが、本文にはSAM 2のtinyが43.8 FPSであるという文もあります。上記のSAM 2.1公式テーブルのtiny(3,890万、SA-V 76.5)と比較すると、状況が異なってきます。
- 「スマートフォンで約10 FPS」という要約と表が一致しない点。 1024×1024の表では1フレームあたり261~1,011ms(1~4 FPS)であり、10 FPSに近い値は512×512入力を扱った別の表(EfficientTAM-S 80.6ms)に記載されています。
論文の要約の数値だけを転記すると、このような条件が抜け落ちてしまいます。これが原文の表を直接確認する理由です。コードとチェックポイントはApache-2.0であり、学会での発表有無は確認できていません(arXiv版)。
5. 制限事項
- ドリフトと長時間の遮蔽。 メモリは直近の数枚とプロンプトフレームのみです。物体が長時間遮られてから再登場したり、類似した物体(隣のテーブル)が通過したりすると、関係のないものを追従してしまう可能性があります。
- 小さく高速な物体。 TT ScoreにおいてSAM 2でボールを追跡したところ、選手と重なったボールの再現率は0.879から0.926へと向上したものの、バウンドの精度が低下してラリーの勝者予測の精度向上は0でした。そのため採用しませんでした(同第3部)。
- 軽量版の代償。 フラットなエンコーダーと粗いメモリは、精度を少しずつ犠牲にします(上記の表においてTiバージョンは4ポイント低い)。
6. 私たちのプロジェクトとの繋がり
- カメラを三脚に固定すれば、卓球台は動きません。そのため、TT ScoreはSAM 2の トラッキングではなく 試合開始時に一度マスクを指定する処理にこのモデルを使用します。数百msかかっても問題なく、CPUでも1秒強で処理できます。
- ユーザーのタップなしで卓球台を検出し、揺れるカメラに追従する機能が2026-10-13に実装されたことに伴い、EfficientTAMをSAM 2.1 tinyと同条件で測定しました(正解の頂点がある画像103枚×合成劣化7種類=721枚、512×288、サーバーGPUを他の作業と共用していた時点)。タップなしで検出した頂点の誤差中央値は、SAM 2.1 tinyが23.1px、EfficientTAM Sが8.8px、EfficientTAM Tiが8.8pxであり、20px以内に収まった割合は45%・57%・53%でした。検出にかかった時間は1.48・1.65・1.55秒とほぼ同様で、時間の大部分はモデルではなくマスクを頂点に変換するCPU側の後処理でした。追加のGPUメモリは0.70・0.64・0.54GBでした。こうした理由から、TT ScoreはEfficientTAM Sをデフォルトに選定しました。ユーザーが一度タップを提供すると、3つのモデルすべてが7〜8pxに収束します(TT Scoreモデル解剖編3の5節の補足、リポジトリ
docs/tt/PERFORMANCE.md2.12). - 論文ではEfficientTAM-S/2がSAM 2に比べてSA-Vでわずかに劣ると報告されていましたが(74.0対74.7)、私たちの卓球台検出においてはEfficientTAMの方がより正確でした。比較対象(SAM 2.1 tiny)とタスクが異なるため、論文を反駁する結果として解釈はしていません。上記の「実際に試してみる」での質問、すなわち実際のメモリマップがどれほど滑らかかについては、まだ測定していません(未計測)。
- EfficientTAMが狙う「スマートフォン内でのセグメンテーション」は、いつかサーバーなしで卓球台検出を行うための道筋です。試合開始時に一度行えばよいため、1フレームあたり450msでも十分に実用圏内です。
次の記事は、クリックの代わりに テキストでオブジェクトを指定するSAM 3です。
TTひとこと。 メモリを2×2に統合しても問題ないのは、隣接するセル同士が似通っている場合だけです。デタラメなメモリを統合したところ、出力が75%も変わってしまいました。
参考文献
- Ravi, N. et al. (2025). SAM 2: Segment Anything in Images and Videos. ICLR 2025. https://arxiv.org/abs/2408.00714, リポジトリ https://github.com/facebookresearch/sam2 (Apache-2.0)
- Xiong, Y. et al. (2024). Efficient Track Anything. arXiv. https://arxiv.org/abs/2411.18933, リポジトリ https://github.com/yformer/EfficientTAM (Apache-2.0)
- Ryali, C. et al. (2023). Hiera: A Hierarchical Vision Transformer without the Bells-and-Whistles. ICML 2023. https://arxiv.org/abs/2306.00989
- 我々の測定:TT Scoreモデル解剖編3、リポジトリ
docs/tt/PERFORMANCE.md2.4·2.12 - サンプルコードと出力:このフォルダーの
code/10_memory_pool.py,code/10_memory_pool.out.txt