マルチモデルのエージェント型ビジョンパイプラインを、人間のオペレータが行動できる速度で応答させるためのレイテンシ設計ノート。
ビジョンモデルのデフォルトのデプロイは、リクエスト・レスポンス型である。画像が届き、モデルが結果を返し、呼び出し側がその結果に対して何らかの処理を行う。このアーキテクチャが成立するのは、ループ内の人間が結果をリアルタイムで待っていないからだ。検査レポートは翌日に読まれ、監査は来週行われる。
しかし、我々が関わるデプロイのうち、こうした形に当てはまらないものが増えてきている。ドローンが橋の上をホバリングし、オペレータは次の飛行指示が必要だ。次の地点へ移る前に、である。工場ラインは毎秒 30 フレームでカメラに被写体を供給しており、1 フレームで見逃した欠陥は永久に見逃したことになる。フィールドエンジニアが装置キャビネットにスマートフォンを向け、カメラが動くのに合わせてオーバーレイが更新されることを期待する。
本ノートは、サブ秒応答が要件となったときに何が変わるのか、そしてそのアーキテクチャ上のコストは何かについて記したものである。
明文化されたレイテンシバジェット
最適化が意味を持つためには、まずバジェットを明示する必要がある。インタラクティブな検査パイプラインに対しては、エンドツーエンドの応答を 1 秒以内 に収めることが有用な目標となる。これは、フレームがセンサを離れてから、最初に利用可能な応答がオペレータに届くまでの時間で測定する。我々はこのバジェットをおおむね次のように分解している。
- キャプチャと転送：50-150 ms
- 専門スカウト（検出 / セグメンテーション / OCR / 深度、並列実行）：100-300 ms
- スカウト出力と取得済みコンテキストに対する VLM アナリストの推論：300-500 ms
- ジャッジによる一貫性チェックと判定の発出：50-150 ms
この数値が成立する運用条件について。このバジェットは、ストリーミングを前提とした構成を記述している。アナリストは型付きのスカウト出力（生の 4K 画像ではなく）を読み、プロンプトは短く保たれ、出力はトークン単位で消費され、UI は完全な応答が完了する前に部分的な判定を提示する。ハードウェアは定常状態の推論ホストであり、アナリストモデルはメモリ上に常駐、システムプロンプトはプレフィックスキャッシュ済み、ビジョンエンコーダは事前ウォームアップ済みである。これらの条件下で、典型的な産業シーンに対して本番ハードウェア上で計測した値は、上記のバジェット内に収まっている。
これが Platform で動作する唯一の構成というわけではない。アナリストが高解像度のフル画像に対してオープンワールド推論を行わなければならない場合（コーナーケース検出に関する我々の取り組み のように）、レイテンシはミリ秒ではなく秒のオーダーになる。二つのバジェットが共存しているのは、それぞれが異なる問題に適用されるからだ。本ノートで対象とするのは、人間がフレームごとのオーバーレイを待っているインタラクティブな検査経路である。
以下に述べるアーキテクチャ上の判断は、このバジェット内に収まるために 我々が下したものだ。非同期バッチ処理ではデフォルトで正解だった選択のすべてが、ストリーミング処理においては誤った選択であった。
境界ではなく、すべてのレイヤでのストリーミング
レイテンシ設計における最大の誤りは、「ストリーミング」を入力側の性質として捉えることである。音声フレームをストリーミングで取り込んでも、発話全体が揃ってから書き起こし、書き起こしが完了してから推論し、推論トレースが完了してから生成する、というパイプラインでは、オペレータが知覚できる形でのレイテンシ削減はまったく実現できていない。出力までの総時間は、最も遅いレイヤのバッチ境界に、その後ろのすべてのレイヤの所要時間を加えたものになる。
真に低レイテンシなパイプラインは、すべてのレイヤ でストリーミングする。
- キャプチャはスペシャリストへストリーミングされる。フレームは N 件のバッチではなく、到着次第スカウトモデルに流れ込む。スカウトはフレーム単位で結果を発出する。
- スペシャリストはアナリストへストリーミングする。スカウト出力は、推論バッチの終端ではなく、安定した瞬間に型付きレコードとして発出される。VLM アナリストは部分的なスカウト状態に対して推論を開始する。
- アナリストはジャッジへストリーミングする。VLM の出力はトークン単位で消費され、ジャッジ層は散文本体が生成し終わるのを待つのではなく、引用可能な主張が発出された時点で一貫性チェックを開始する。
- 判定はオペレータへストリーミングされる。UI は単語ごと、チップごとに更新される。これにより、オペレータは残りが生成されている間に、判定のうち高信頼度の部分に対して行動できる。
これは、リアルタイム音声認識システム [1] やストリーミング LLM サービングスタック [2] が依拠するのと同じアーキテクチャ原理を、マルチモデルのビジョンパイプラインに適用したものである。この方式を成立させる性質（トークンあたりレイテンシの上限化、ストリーミングに適した KV cache 管理、結果のインクリメンタルなレンダリング）はビジョン固有のものではない。これらは LLM サービング系の知見に由来し、アナリストを vLLM [3] 上でホストし、server-sent-event チャネル経由でレンダリングすることで、我々はそれを継承している。
三層のストリーミングパイプライン（キャプチャ、スペシャリスト／アナリスト、ジャッジ／レンダリング）。各層はリクエスト・レスポンスではなく、連続的なデータフローに対して動作する。
レイテンシが実際に蓄積する場所
「モデルが遅い部分だ」という直感は、我々の設定ではほぼ常に誤りである。実際に遅い部分は、典型的な寄与度の順に次のとおりだ。
1. フレーム転送。高解像度画像をセンサから推論ホストへ移すこと自体が、ドローン上の 4G モデムや帯域に制約のある産業用 Ethernet 上では決して些末ではない。我々はハードウェアアクセラレーションされたエンコードをエッジに押し下げ、推論ホストでデコードする。コーデックは最適圧縮比ではなく、次 のフレームの I フレーム間隔に合わせて調整する。
2. モデルのウォームアップとロード。ロード直後の最初の推論呼び出しは、定常状態と比べて劇的に遅い。我々はスペシャリストをメモリ上で常時温め、GPU コンテキストをピン留めし、アナリスト用に KV cache を事前確保する。どれも華やかではないが、いずれも欠かせない。
3. 並列で済む処理を直列に組んでしまうこと。同一フレームに対する検出、セグメンテーション、OCR、深度の各処理にはデータ依存関係がない。これらを直列に走らせるのは、能動的に防がなければ起きてしまう失敗である。スケジューラはバッチ効率に寄せたデフォルトを取りがちで、我々はそれをレイテンシ側にオーバーライドする。
4. 同期バリア。素朴なアナリスト層の実装は、推論を開始する前に すべての スカウトの完了を待ってしまう。レイテンシに配慮した実装は、完了したスカウトに対して推論を行い、残りは「保留中のエビデンス」として表現し、それらが到着した時点で判定を更新する。これを安全たらしめているのは下流のジャッジ層だ。保留中のエビデンスが到着するか、明示的に省略されるまでは、判定の発行を許さない。
5. モデルそのもの。確かに、ここも遅い。ただし、上記の四点が解消されると、実際の GPU 時間はバジェット内で意味のある割合を占めるものの、支配的な要因になることはほとんどない。
意図して選んだアーキテクチャ上のトレードオフ
紙の上では奇妙に見えるが、本番環境で効果を発揮した選択をいくつか挙げる。
エンドツーエンドではなく、パイプライン。多段パイプライン（キャプチャ → スペシャリスト → VLM → ジャッジ）を、生フレームを取り込んで判定を発するエンドツーエンドモデル一つに置き換えたい、という誘惑は繰り返し現れる。エンドツーエンドモデルは、紙の上ではレイテンシ面で有利だ。ところが実運用では、各ステージを独立にウォーム、スケジュール、デグレード可能であるという理由から、パイプラインアーキテクチャの方がタイトなレイテンシバジェット内に収めやすかった。エンドツーエンドモデルは、最も遅いエンドツーエンド経路にレイテンシを結合させてしまう。同じトレードオフは音声アーキテクチャにも現れており（パイプライン構成の STT-to-LLM と、Moshi [4] や GLM-4-Voice [5] のようなエンドツーエンドの speech-to-speech モデルの対比）、その結論はそのまま転用できる。
境界付きコンテキストのアナリスト。VLM アナリストは、利用可能なエビデンス全体ではなく、タイトに境界付きのコンテキストウィンドウで動作する。コンテキストのトークンが増えるたびにレイテンシが増し、追加した一トークンが判定を変えることは稀だ。我々はスカウト出力と取得済みのコンテキストパックチャンクを関連度で事前ランク付けし、積極的に絞り込む。削りすぎたケースを拾うのはジャッジ層の役割である。
アナリスト上での投機的デコーディング。VLM のアナリスト出力には draft-then-verify デコーディング [6] を用いる。呼び出しあたりの計算量が小幅に増える代わりに、テールレイテンシが意味のある幅で減少する。この手法には、高速かつターゲットモデルとおおむね整合したドラフトモデルが必要だ。整合の質は、ドラフトモデル単体の絶対的な能力よりも重要である。
すべてキャンセル可能に。パイプラインの各ステージはキャンセルトークンを受け付ける。新しいフレームが現在のものを上書きしたとき（ドローンが移動した、カメラがフォーカスし直した）、古いフレームに対する下流の処理は無駄に消費されるのではなく、即座に停止される。これは後付けで導入するよりも、最初から設計に組み込む方が容易であり、組み込みでの設計を推奨する。
我々が やらない こと
魅力的でありながら、我々が避けてきたか、あるいは撤退した選択をいくつか挙げる。
speech-to-decision（あるいは video-to-decision）型のエンドツーエンドモデルを主経路として用いない。いずれはそこに到達するだろうが、現時点ではパイプラインアーキテクチャの方が、観測可能性、および個別コンポーネントを残りのシステムを変更せずに差し替えられる能力の両面で優位にある。我々はステージ間のインターフェースを十分に整理し、将来エンドツーエンドモデルが妥当性を獲得した時点で差し込めるようにしている。
特定のハードウェアターゲットに過剰適合させない。特定の GPU SKU に依存したレイテンシバジェットは、供給が変わった瞬間に失効するバジェットだ。我々はまずストリーミングと並列性を前提にアーキテクトし、現行ハードウェアへのチューニングは二番目に置く。
オペレータの反応時間より速い領域まで追わない。応答時間がオペレータの知覚・行動時間を十分に下回ったあとは、追加のレイテンシ設計は逓減し、他のバジェット（精度、監査の網羅性、コンテキストパックの幅）を侵食し始める。問うべきは「もっと速くできるか」ではなく、「オペレータに必要なのは速さなのか」である。
オープンな課題
- 負荷下のテールレイテンシ。定常状態の数値は良好だ。バースト的な負荷下（複数オペレータが並列に検査、複数ドローンが同時飛行など）では、テールレイテンシはスループット指向のサービングスタックが示唆するよりも急速に劣化する。テナントごとの事前ウォームとアドミッションコントロールは助けになるが、一般解は未解決である。
- フレーム間の整合性。フレームごとに判定を発出するパイプラインは、各判定が個別には正しくても、視覚的にちらつく出力を生み出すことがある。スムージングが通常もたらすラグを導入せずにフレームをまたいで平滑化することは、未解決の設計問題だ。
- 適切なサブ問題に対するエンドツーエンドモデル。低レベル知覚や、密結合の音声・映像融合のようなサブタスクでは、エンドツーエンドモデルが優位に立つ可能性が高い。エンドツーエンドのサブコンポーネントと、パイプライン型の全体アーキテクチャとの間のインターフェースは、現在試作中の領域である。
References
- Google Cloud Speech-to-Text V2. Streaming recognition. cloud.google.com/speech-to-text/v2/docs
- OpenAI. Realtime API documentation. platform.openai.com/docs/guides/realtime
- Kwon, W. et al., Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. arxiv.org/abs/2309.06180
- Défossez, A. et al., Moshi: a speech-text foundation model for real-time dialogue. Kyutai. github.com/kyutai-labs/moshi
- GLM-4-Voice. End-to-end voice model. Zhipu AI. github.com/THUDM/GLM-4-Voice
- Leviathan, Y. et al., Fast Inference from Transformers via Speculative Decoding. Google Research. arxiv.org/abs/2211.17192