【VIVANT考察】GPUを知らないマーケ担当が、シンシーの極秘監視網を実際に作って測ってみた
※本ブログは9/6放送のVIVANTのネタバレを含みますので、まだご覧になっていない方はブラウザバックしてください。
このブログは、技術的バックグラウンドのないVIVANT好きなマーケ担当者が、100%好奇心の赴くままに「シンシーの監視網って、実際に作ったらどうなるんだろう?」を試してみた個人的な検証記録です。技術的な正確性や性能を保証するものではなく、あくまで一つの実験・考察としてお楽しみください。
半熟卵お仕置き和久井とクシャクシャポーイされる山本が話題になった先週のVIVANT。SNSでも大いに盛り上がりましたね。
さて、今回どうしても気になってしまったのが、シンシーが仕掛けたあの極秘監視システムです。15台のカメラ映像から、東條・野崎・佐野の3名を顔認識で24時間リアルタイムに検出し続けるという要件。あれを現実のクラウドで構築すると、一体どうなるのか?
先に白状しておくと、私はGPUに詳しいエンジニアではありません。Akamai Japanでマーケティングを担当していて、自社のGPUクラウドが実際に何をどこまで捌けるのかは、カタログの数字でしか知りませんでした。だから環境を借りて、動かして、測ってみることにしました(検証環境は社内のSEチームに用意してもらいました。この場を借りてお礼を)。
結論から言います。4 vCPU + GPU 1枚のインスタンスで、実測「カメラ12台」まで捌けました。 そして最大の発見は、ボトルネックになったのがGPUではなかったことです。GPU使用率が70%止まりのまま、先にCPUが音を上げました。
(ドラマには「別班」という音声キーワード検知の要件もありますが、こちらは常時Whisperを回すと重装備すぎるため、今回は映像側に絞ります)
1. 要件定義:シンシーの「要件」を分解する
ドラマの設定を技術要件に落とすと、こうなります。
- 入力: フルHD(1080p)監視カメラ × 15台、24時間365日
- 処理: 全映像から顔を検出し、登録済みターゲット3名と照合
- 出力: ターゲットが映った瞬間のクリップのみを保存・通知
- 制約: 極秘作戦なので、検知漏れは作戦の失敗に直結する
処理の中身は「顔検出 → 顔の特徴量(embedding)抽出 → 登録人物との照合」というパイプラインです。AIの学習(トレーニング)ではなく推論(インファレンス)のワークロードで、これがのちのち効いてきます。
なお、監視で全フレーム(30fps)を推論する必要はありません。人がカメラの前を通過するには数秒かかるので、毎秒数回の判定で足ります。今回は毎秒5回(5fps/ストリーム)を初期要件としました。それでも 15台 × 5fps = 毎秒75フレームの顔認識 が必要です。
2. 課題:中央クラウドへの「垂れ流し」が抱えるリスク
素朴に組むなら、15台分の映像を全部中央のクラウド(東京リージョンなど)に送って、そこで推論する構成です。しかしこれには2つの壁があります。
壁①: ネットワーク品質への依存。 1080pの映像15本は合計で数十Mbpsの継続的なアップロードになります。ネットワークが逼迫したり、遅延やジッタ、パケットロスが発生すれば、映像伝送が遅延したり、場合によってはフレームが欠落したりします。AIは存在しないフレームを推論できません。ターゲットが一瞬だけカメラを横切ったその瞬間にコマ落ちすれば、極秘作戦も水の泡。極秘監視網として生データの長距離伝送は、それ自体が作戦リスクです。
壁②: Egress(データ転送料)。 多くのクラウドは「入りは無料、出るときに課金」の従量モデルです。しかし、15台分のフルHD映像のような重いデータを24時間365日クラウドへ出し入れするとなると、通信量とコストは相当なものになります。
これは特定ベンダーの問題ではなく、集中型アーキテクチャ一般の構造問題です。
3. 設計:エッジで推論を完結させる
解決の方向はシンプルで、映像を推論の場所へ送るのではなく、推論をカメラの近くへ置くことです。
[カメラ×15] → [エッジノード: デコード+顔検出+照合] → ヒットした数秒のクリップだけ中央へ
エッジノードで映像を捨て、検知時のクリップとメタデータだけを送れば、転送量は桁違いに減り、ネットワーク起因の検知漏れも構造的に抑えられます。この設計パターン自体はベンダー非依存で、各クラウドが取り組んでいる領域です。
技術選定は、顔検出+照合に InsightFace(SCRFD + ArcFace)、推論ランタイムに ONNX Runtime(CUDA Execution Provider)を使いました。
4. ハードウェア選定:「推論向け」を鵜呑みにした結果
ここで私がカタログから仕入れた知識はこうでした。
「AI推論のワークロードは、学習ほどCPUを使わない。だからGPU 1枚に対してvCPUを絞った構成がコスト効率に優れる」
そのため、今回はB300のような学習向けの巨大GPUではなく、推論向けのミドルクラスGPU + 少なめのvCPU、という構成を選びました。
今回使ったのは Akamai Cloud RTX4000 Ada x1 Small(NVIDIA RTX 4000 Ada / VRAM 20GB、4 vCPU、RAM 16GB、$0.52/時)。他社にも同クラスの構成があり(AWS g6.xlarge、GCP g2-standard-4 はいずれもNVIDIA L4 + 4 vCPU)、エッジ推論ノードとしては標準的なサイズです。
では、この構成で毎秒75フレームの顔認識は捌けるのか。ここからが本番です。
5. 【実測】20fpsの壁、29fpsの壁、そして犯人
検証環境
- Akamai Cloud RTX4000 Ada x1 Small(4 vCPU / RAM 16GB / VRAM 20GB)
- Ubuntu 24.04 / NVIDIA Driver 580.173.02 / CUDA 13.0
- Python 3.12 / onnxruntime-gpu 1.29.0 / InsightFace buffalo_l
- テスト映像: 著作権フリーの街頭雑踏1080p動画(25fps)。1フレームに顔5〜6個が映り込む、雑踏監視として現実的な負荷
- 15台のカメラは15本のデコードスレッドで模擬し、キュー経由でGPU推論ワーカーへ流す構成
- CPU使用率は
mpstat -P ALL、GPU使用率はnvidia-smi dmonで並行記録
なお本検証は素朴なPython実装での結果です。C++実装やTensorRTでの最適化、NVDECによるデコードのGPUオフロードを行えば数字は変わります。「この構成でどこが先に詰まるか」を見るための計測とお考えください。
環境構築でさっそく詰まったので共有しておくと、onnxruntime-gpu 1.29はCUDA 13世代のビルドで、pipで入れるNVIDIAライブラリもCUDA 13系が必要です。しかもCUDA 13からパッケージ名が変わっており(nvidia-cublas-cu13は非推奨、nvidia-cublasが正式名)、旧名を指定すると謎のビルドエラーで弾かれます。libcublasLt.so.13 not found で1時間溶かしました。もしこれから同じことをやる方は、世代とパッケージ名には要注意です。
Round 1: 素朴な実装 → 20fpsの壁
まず推論ワーカー1本の素朴な実装で計測。
| ストリーム数 | 要求fps | 実効fps | ドロップ率 | 判定 |
|---|---|---|---|---|
| 1 | 5 | 5.0 | 0% | ○ |
| 5 | 25 | 20.9 | 15.6% | × |
| 10 | 50 | 21.3 | 56.7% | × |
| 15 | 75 | 20.6 | 71.8% | × |
1台なら余裕。5台で早くも飽和し、15台では投入フレームの7割を取りこぼしました。
注目すべきは、実効スループットがどの条件でも約21fpsで頭打ちなことです。1フレームの推論に約50msかかるので、直列処理の理論上限は 1000ms ÷ 50ms ≒ 20fps。GPUの性能以前に、実装が直列であることが最初のボトルネックでした。ここは私の実装が素朴すぎただけです。
Round 2: ワーカー並列化 → 今度は29fpsの壁
推論ワーカーを複数持てるようスクリプトを書き直し、各ワーカーに独立のONNXセッションを持たせました(VRAM消費は1ワーカーあたり約1GB。20GBに対して余裕)。
| ワーカー数 | 実効fps | 推論p50 |
|---|---|---|
| 1 | 19.9 | 51.6ms |
| 2 | 27.3 | 72.9ms |
| 3 | 28.9 | 103.7ms |
| 4 | 28.6 | 140.2ms |
※ワーカー1の行は、Round 1と同じ条件(15台・det640・5fps)を書き直し後のスクリプトで測り直したものです。Round 1の20.6fpsに対して19.9fpsと3%以内の差で、実装の書き直しによる影響は誤差範囲でした。
伸びは29fpsで停止。しかも1フレームあたりの推論時間が、ワーカー数にほぼ比例して悪化しています。これは並列化が効いているのではなく、ワーカー同士が何かを奪い合っている症状です。
nvidia-smi dmon を眺めると、手がかりが2つ見つかりました。
- dec列(ハードウェアデコーダ使用率): 終始0% — RTX 4000 AdaにはNVDEC(動画デコード専用エンジン)が2基載っているのに、完全に遊んでいる。OpenCVのデフォルトでは、1080p×15本のデコードは全部CPUの仕事でした
- sm列(GPU演算使用率): 70%前後で頭打ち — GPUは使い切られていない
犯人はGPUの外にいる。ここで私は「デコードだ」と確信しました。CPUで15本のフルHDをデコードしているなら、4 vCPUなど一瞬で溶けるはずだからです。
Round 3: 分離実験 → 犯人の正体
「デコードだけ」「推論だけ」に分けて上限を測り、同時にCPU使用率も記録しました。
デコード単体(15ストリーム): 447fps。 必要な375fpsは満たせています。ところが計測中に mpstat -P ALL を見ると、4コアすべてが %idle 0%。速度の要件は満たすが、CPUに1%の余力も残していませんでした。「CPUデコードが4 vCPUを食い尽くしている」という読み自体は当たっていたわけです。
外れたのはその次でした。「ならばデコードさえ排除すれば壁は消えるはず」——消えませんでした。
推論単体(デコードを完全に排除、ワーカー1/2/4): 18.7 / 26.8 / 27.9fps。 デコードを取り除いても、壁は同じ29fpsの場所にあります。このときのCPU使用率は %idle 11〜13%、つまり4コアが常時90%近く稼働。一方GPUのsmは70%前後です。GPUには余力があるのに、CPUはほぼ埋まっている。
GILの検証: Pythonには GIL(同時に1スレッドしかPythonコードを実行できない制約)があるので、これが原因かを確かめるためプロセスを分けて2本並走させました。結果は合算24.3fps。スレッドで並列化した場合(26.8fps)とほぼ同じ、むしろ僅かに低い。GILを回避しても壁は動かないので、少なくとも主因はGILではないと考えました。
3つを合わせると、デコードも推論もそれぞれCPUを大量に消費し、両者が同じ4コアを奪い合っている——主要な制約はCPU側にあるという結論になります。
なお推論単体でも10%強のidleが残っている点は補足しておきます。CPUを完全に使い切って頭打ちになったというより、スレッド間の同期待ちなども混ざって「使い切れてすらいない」状態です。後述するワーカー4本で悪化する現象とも、おそらく同じ根を持っています。
なぜ「推論」なのにCPUが詰まるのか。顔認識1フレームの処理を分解すると、こうなっていました。
- 映像のデコード → CPU
- 画像を検出器の入力サイズにリサイズ → CPU
- 顔検出モデルの推論 → GPU
- 検出枠の重複除去(NMS) → CPU
- 顔ごとの切り出しと傾き補正(アライメント) → CPU
- ArcFaceで特徴量抽出 → GPU
- 登録3人との照合 → CPU(軽い)
GPUが働くのは3と6だけ。残りは全部CPUの仕事です。しかも今回の素材は1フレームに顔が5〜6人分。顔1個ごとに5のアライメントと6の照合が走るので、雑踏を映すカメラでは人数分だけCPU負荷が膨らみます。
つまり、私が鵜呑みにした「推論はCPUを使わない」という常識は、LLMの推論を念頭に置いたものでした。テキスト生成はトークン化くらいしかCPU仕事がないと思っていました。しかし映像の画像認識は事情がまったく違います。同じ「推論」でも、要求されるCPUとGPUのバランスはワークロードによって大きく異なることがわかりました。
Round 4: 要件の再交渉 → 12台ならドロップゼロ
犯人が分かれば打ち手も決まります。CPU側の負荷を削りにいきました。
- det_size(検出器の入力解像度)を640→320に: 前処理コストが激減し、推論単体スループットは26.8→52.1fpsへ約2倍。ただし検出器に渡す解像度を落とすので、遠くの小さい顔は取りこぼしやすくなるはずです(どの程度落ちるかは今回測っていません。後述します)
- 判定頻度を毎秒5回→3回に: ターゲットは数秒はカメラに映り続けるので毎秒3判定で実用十分、という要件の再交渉。必要スループットは75→45fpsへ
| 段階 | 構成 | 実効fps | 60秒間でのドロップ率 | 判定 |
|---|---|---|---|---|
| Round 1 | 15台・det640・5fps・ワーカー1 | 20.6 | 71.8% | × 20fpsの壁 |
| Round 2 | 15台・det640・5fps・ワーカー3 | 28.9 | 60.8% | × 29fpsの壁 |
| Round 4 | 15台・det320・3fps・ワーカー3 | 44.3 | 1.4% | △ ほぼ成立 |
| 安全ライン | 12台・det320・3fps・ワーカー3 | 36.0 | 0.00% | ○ 完全成立 |
※Round 1の行は書き直し前のスクリプトによる測定です(書き直し後は19.9fps)。
15台はドロップ率1.4%で「ほぼ」成立(E2E遅延 p50=101ms / p95=897ms)。ただし検知漏れが作戦の失敗に直結する要件なので、ドロップ0%にこだわって台数の限界を探ると——今回の60秒間のテストでは、12台でドロップゼロ、E2E遅延は p50=45ms / p95=137ms。カメラに映ってから0.14秒後には「野崎がいる」と判定できる計算です。15台構成ではp95が900ms近くまで伸びていたので、台数を3台減らしたことで遅延のばらつきも大きく改善しています。
なお、ワーカーを4本に増やすと逆に悪化しました(推論p50: 55.8ms → 76.5ms)。4 vCPUに対してデコードスレッドと推論ワーカーが多すぎ、切り替えのオーバーヘッドが勝ったものと考えられます。このマシンでの最適解は推論ワーカー3本でした。並列度は多ければ良いわけではない、という教科書どおりの結果も添えておきます。
6. まとめ:「推論向け」という言葉には二種類ある
GPUに詳しくない人間が実際に手を動かして学んだことを、持ち帰れる形で3つ残しておきます。
① 「推論だからCPUは少なくていい」とは限らない。
「GPU推論ならCPUはそれほど必要ない」という私が持っていたイメージは、今回の映像認識ワークロードには当てはまりませんでした。映像の画像認識は、デコード・リサイズ・NMS・顔アライメントと、GPU計算の前後にCPUの仕事がびっしり詰まっています。同じ推論でもリソースの要求プロファイルが違う。ワークロードの名前(学習か推論か)だけでサイジングを決めるのは危険でした。
② 映像系なら、GPUのグレードより先にvCPU数を見る。
今回、CPUが90%以上埋まっている状態でもGPU使用率は70%止まりでした。この状態でGPUを上位モデルに変えても、先に詰まっているのはCPU側なので効果は期待できません。幸い各社とも「GPU 1枚のままvCPUだけ増やす」プランを用意しています(Akamaiなら x1 Small→Medium で4→8 vCPU、$0.52→$0.67。AWSならg6.xlarge→g6.2xlarge、GCPならg2-standard-4→8。いずれも同じ構図です)。GPUを増やす前に、CPU側の階段を1段上がる。 これが今回のワークロードの正解でした。
③ 効くパラメータは det_size と判定頻度。
det_sizeを640→320にするだけでスループットは約2倍。判定頻度を5fps→3fpsにすれば要求は3分の2。ハードを増強する前に、まずここを疑う価値があります。ただし断っておくと、det_sizeを下げれば遠くの小さい顔は取りこぼしやすくなります。今回はその精度低下を定量化していません。「12台まで捌けた」という結果はあくまで処理性能上のものです。ターゲットを漏れなく顔認識できることまで確認したわけではありません。 実運用では速度と検出率のバランスを実データで測る必要があります。
そして結論。シンシーの15台監視網は、4 vCPU + GPU 1枚のノード1台では「12台まで」。 15台完走には、vCPUを倍にするか、複数エッジノードに分散するかが有力な選択肢になりそうです。ノードの分散は、2章で挙げた検知漏れリスクの低減とも同じ方向を向いています。カメラ群の近くに小さな推論ノードを分散配置し、ヒットしたクリップだけを中央へ送る——可用性・コスト・スケーラビリティの答えが同じアーキテクチャに収束するのは、素人目にも気持ちのいい結論でした。
積み残した宿題
- NVDECを使ったデコードのGPUオフロード(2基が丸ごと遊んでいたので)
- det_sizeを下げたときの検出精度の定量評価
- 8 vCPU構成での15台完走の確認
- 音声「別班」キーワード検知の追加
- 他社の同クラス構成(L4 + 4 vCPU)での追試
特に最後は、本来なら同条件で測るべきでした。今回は社内で借りられた環境の都合でAkamaiのみです。もし他社環境で同様の検証をされた方がいれば、ぜひ結果を教えてください。
おわりに
最後に、顔認識による人物の追跡は、日本では個人情報保護法上の要配慮に直結する技術です(だからこそドラマでは"極秘"に設置されていたわけですが)。実在の人物の識別・追跡に適用する場合は利用目的の特定や本人への通知等の法的整理が必須であり、本記事の構成をそのまま実運用に流用することは想定していません。あくまでドラマの設定を題材にした技術検証としてお楽しみください。
そして、シンシーの監視網がクラウドで作られていたとしたら——構築担当者はきっと、私と同じところで詰まっていたはずです。
本記事はTBS系日曜劇場「VIVANT」の設定を題材にしたファン考察であり、TBSおよび制作関係者とは一切関係ありません。記事の内容は筆者個人の検証によるものです。
Akamai Cloudについてはこちらの記事をご覧ください。
Akamai Cloudとは何かをわかりやすく解説