— エッジAI 実装の勘所 —

多カメラの映像解析を検討していると、必ず出てくるのが「このPC1台で何台のカメラを処理できますか」という質問です。答えを一言で言えば「条件によります」となってしまうのですが、それでは設計が進みません。

本記事では、この問いに自分たちで答えを出せるようにするために、マルチストリームAI処理の負荷がどこで決まるのかを分解して整理します。

1. なぜ「何台まで」に一意の答えがないのか

カメラ1台あたりの負荷は、少なくとも次の要素の組み合わせで決まります。

解像度（フルHDか4Kか）
フレームレート（何fpsで推論する必要があるか）
圧縮方式（H.264かH.265か、ビットレートはいくつか）
モデルの重さ（軽量な検出モデルか、セグメンテーションのような重い処理か）
同時に流すモデル数（1つの映像に検出と分類を重ねるか）

これらが1つ変わるだけで処理台数は倍にも半分にもなります。ですから、カタログの「最大○ch対応」という表記は、特定のモデル・特定の解像度・特定のfpsという条件下での数字だと理解する必要があります。条件が変われば結果も変わります。

2. 処理を4つの段に分解する

見積もりのために、映像1本あたりの処理を次の4段に分けて考えます。

デコード　圧縮された映像を画像フレームに戻す
前処理　リサイズ、色空間変換、正規化などモデル入力の形に整える
推論　NPU（またはGPU）でモデルを実行する
後処理・出力　検出結果の整形、閾値判定、描画、上位システムへの送信

重要なのは、①②④は主にCPUの仕事で、③だけがNPUの仕事だという点です。「NPUの性能が高いから多くのカメラを捌けるはず」と考えて設計すると、CPU側で頭打ちになります。実際、現場で「思ったほど台数が伸びない」というとき、ボトルネックは推論ではなくデコードにあることが少なくありません。

映像1本あたりの処理段。デコード・前処理・後処理はCPU、推論はNPU。ボトルネックは推論以外にも現れる

3. デコード負荷をどう扱うか

H.264やH.265の映像をソフトウェアでデコードすると、CPUに相応の負荷がかかります。1本なら問題にならなくても、10本、20本と増えれば、CPUコアがデコードで埋まってしまいます。

対処の選択肢は次のとおりです。

ハードウェアデコードを使う　CPUに内蔵された動画デコード機能（あるいは専用のデコーダ）を使えば、CPU負荷を大きく下げられます。同時デコード可能なストリーム数には上限があるため、その数字を確認します
推論するフレームだけデコードする　30fpsで入ってくる映像でも、推論が5fpsで足りるなら、全フレームをデコードする必要はありません。キーフレーム単位の間引きや、デコード段での間引きが効きます
カメラ側で調整する　解像度・fps・ビットレートをカメラ側の設定で落とせば、入り口の負荷そのものが減ります
非圧縮で受ける　産業用カメラをGigE VisionやUSB3 Visionで直結する構成なら、そもそもデコードが不要です（そのぶん帯域を使います）

接続規格ごとの帯域・ケーブル長の違いはカメラ選定と接続設計の記事で整理しています。

4. 必要なフレームレートを用途から決める

設計上、最も効果の大きい判断がこれです。「常に30fpsで推論する」という前提を疑うだけで、必要な性能は数分の一になります。

用途別に考えると、目安は次のように整理できます。

高速に動く対象の追跡・カウント　動きを追う必要があるため、比較的高いフレームレートが要ります
ライン上のワーク検査　トリガー信号に同期して必要なタイミングだけ推論する設計が可能です。連続処理そのものが不要になります
設備・エリアの状態監視　数fps、場合によっては1fps以下でも成立します。転倒や侵入のような事象は、秒単位の検知で十分なことが多いためです

ここで決めた「必要fps」に、カメラ台数を掛けた値が、システム全体で必要な推論スループット（推論回数/秒）になります。たとえば「10台 × 5fps = 50推論/秒」といった形です。この数字が、性能見積もりの基準線になります。

5. NPUの性能指標を実効値に翻訳する

NPUのカタログに載るTOPS値は、理論上の演算性能です。実際に「何推論/秒」出るかは、モデルの規模と入力解像度で変わります。したがって見積もりでは、TOPSではなく、対象モデルでの推論レイテンシまたはスループットの実測値を使います。

また、TOPSがどの単位の値なのかにも注意が必要です。たとえばAxelera AIのMetis® AIPUは214 TOPSという性能を持ちますが、これはAIPU単体の値であり、PC全体としての性能や消費電力とは別に考える必要があります（消費電力8〜15Wも同様にAIPU単体の値です）。Hailo-8であれば最大26 TOPS、mPCIe版は13 TOPSです。比較するときは同じ土俵の数字かを確認してください。

NPUの選び方そのものはNPUの選び方の記事で判断軸を整理しています。

6. マルチモデル・マルチストリームの実行

実務では、1本の映像に複数のモデルを重ねることがよくあります（人を検出してから、その領域に対して姿勢や属性を判定する、といった構成です）。この場合、映像1本あたりの推論回数は単純に増えます。

複数のAIコアを持つアーキテクチャでは、モデルやストリームを並列に割り当てられる設計になっているものもあります（Axelera AIのMetis AIPUは複数AIコアによるマルチモデル・マルチストリームの並列処理を特徴として挙げています）。ただし、並列に動かせることと、全体のスループットが台数分伸びることは別の話です。共有されるメモリ帯域やCPU側の前後処理がボトルネックになれば、そこで頭打ちになります。

7. 見積もりの手順

ここまでを踏まえて、実務での進め方をまとめます。

用途から必要fpsを決める　カメラごとに違ってもかまいません。合計の推論回数/秒を出します
入力側の負荷を出す　解像度・圧縮方式・本数から、デコードをハードウェアで賄えるか、間引きが必要かを判断します
対象モデルで実測する　カタログのTOPSではなく、自社モデル・自社解像度でのスループットを測ります
本番構成で通しで測る　全カメラを接続し、前後処理・描画・送信まで含めた状態で、CPU使用率とフレーム落ちを観察します
余裕を持たせる　CPU・NPUとも常時100%に張り付く設計にしない。将来のカメラ増設と、連続運転時の温度上昇による性能低下を見込みます

特に④は省略されがちですが、ここでしか出ない問題（ネットワーク帯域の不足、スイッチのバッファ、CPUの割り込み処理の偏り）があります。多数のIPカメラを1台に集約する構成では、PC側だけでなくネットワーク側の設計も同時に効いてきます。

おわりに

「1台で何カメラ捌けるか」に答えを出すための要点を整理します。処理はデコード・前処理・推論・後処理の4段に分かれ、NPUが担うのはそのうち1段だけであること。デコードはCPUを食うため、ハードウェアデコードとフレーム間引きが効くこと。必要fpsを用途から決め直すと、要求性能が大きく下がること。TOPSではなく対象モデルでの実測スループットで見積もること。そして本番構成の通し計測でしか見えない問題があること。

多カメラ構成の性能見積もりや、必要な構成のご相談は下記からお気軽にどうぞ。