🦿
100ms以内で動作するVLAモデルの実車適用

anonamename
2026/03/26に公開
自動運転
VLA
tech
 はじめにチューリングのVLAチームでエンジニアをしている横井です。経済産業省およびNEDOが推進するプロジェクト「GENIAC」第3期の支援のもと、自社で開発したVLM「Heron」を土台に将来の走行軌跡を出力する 自動運転VLAモデル「DriveHeron」 をチームで開発しました。本記事では、DriveHeronを自動運転システムに統合し、リアルタイムで車両を制御できるようにした取り組みを紹介します。
https://youtu.be/bv90MHM74IY

 E2EモデルからVLAモデルへ自動運転で難しいのはカメラに映る情報を解釈し、交通規範や状況に照らして次の行動へ落とし込むことです。単なるパターン認識ではなく、何が起きていて何を優先すべきかという判断を含みます。画像から直接制御（あるいは軌跡）を出力するE2E（End-to-End）自動運転は有望なアプローチですが、完全自動運転まで視野に入れると補完が必要になる可能性があります。


自動運転AIの進化と展望

ロングテールでは必要な判断が知識や規範に寄る：

工事規制、誘導員の合図、暗黙の譲り合いなど、同じ見た目でも状況の意味が違い、取るべき行動が変わります。これらはデータで学べてもカバーすべき例外が膨大で分布外の状況で破綻しやすい課題があります。

外部のルール・指示・標識の意味を扱いづらい：

交通標識や路面表示は単に検出するだけでなく「この標識が今のシーンで何を要求しているか」を理解して行動に反映する必要があります。E2Eでも可能ですが、意味の取り扱いが暗黙になりやすく、学習・評価・改善が難しくなります。

失敗したときに何が理解できていなかったかが見えにくい：

E2Eは挙動としては出力できますが、どの規範・どの意図判断で誤ったのかが切り分けにくく、改善サイクルが回りづらいことがあります。
我々は、VLM（Vision-Language Model） を土台に視覚情報を言語空間の知識と接続しながら最終的な行動まで一気通貫で扱う VLA（Vision-Language-Action） にも取り組んでいます。VLMを使う狙いは、LLMが持つ
交通規範や一般常識に基づく推論
指示・標識・文脈の言語的な解釈
CoT（Chain-of-Thought）による段階的な推論（状況→意図→行動）
これらを活かして、困難なエッジケースでも賢い運転ができることを期待しています。E2Eの強み（直接最適化・シンプルな出力）を保ちつつ、弱点になりやすい部分を言語知識で補完することを目指しています。
今年のCESやGTCでNVIDIAが発表したAlpamayoもこうした方向性を後押しする事例です。Alpamayoは、映像・走行履歴・ナビゲーションなどを入力として走行軌跡を生成するreasoning-based VLAを中核に据えつつ、データセットやシミュレータまで含めた開発基盤です。走行軌跡だけでなくreasoning（行動を選ぶまでの中間的な言語表現）も扱うことでエッジケースの複雑な状況に対し、より因果的な判断を取り込もうとしています。


Alpamayo-R1のモデルアーキテクチャの概要図

 自動運転VLAモデル「DriveHeron」Heronは画像と言語を同じ枠組みで扱えるVLMです。運転では
画像を見て状況を説明する
標識や工事規制、誘導員などを言語で解釈する
「今進んでよいか」「どう注意すべきか」といった問いに答える
といった視覚と言語にまたがる理解が重要になります。ただしVLMの出力はテキストであり、そのままでは自動運転の制御に接続できません。車両を動かすにはステアリングや加減速などに変換可能な走行計画が必要です。
DriveHeronは、Heronを「自動運転基盤モデル」へ拡張したものです。ポイントは2つです。
1) 出力を将来軌跡（trajectory）にする
DriveHeronの出力は走行軌跡です。軌跡を出力にすることで、後処理で車両の制約を満たすように調整し、制御入力（ステアリング、アクセル、ブレーキなど）へ変換できます。必要に応じて最適化ベースの手法（例：MPC: Model Predictive Control）を用いることもできます。
2) 推論を0.1秒（100ms）以内に収める
DriveHeronは、社内で運用しているE2Eモデルと同様に、リアルタイム制御を前提に設計しました。モデル単体の速さだけでなく、前処理・推論・後処理・周辺連携まで含むパイプライン全体を、10Hz（100ms周期）の制御ループに収めることを重視しています。


HeronからDriveHeronへの発展イメージ

 モデルアーキテクチャ（VLM + trajectory head）DriveHeronは、Heron-NVILA-Lite-1B-hf などのVLMをバックボーンとして利用し、運転向けの入力（カメラ画像＋車両状態）から将来の走行軌跡（trajectory）を出力します。


DriveHeronのアーキテクチャ概念図

 trajectory headtrajectory headは目的に応じて設計の自由度があります。

回帰型（regression）：線形層などの軽量なheadで軌跡を連続値として直接予測する。構造がシンプルで推論が速い

生成型（diffusion / flow matching）：複数候補の軌跡を生成でき、性能向上の余地が大きい一方、Diffusion Transformerなどの反復計算を伴うため、推論レイテンシが大きくなりやすい
自動運転に限らず、近年のVLAは生成型がメインストリームです。生成型も検証しましたが、実車適応を前提にすると (1) レイテンシ と (2) 数値誤差（低精度推論時の出力乖離） がボトルネックになりました。特に後者は、推論を高速化するためにFP16/BF16へ低精度化した際、FP32推論と比べて出力の乖離が大きく、出力軌跡が乱れるという問題です。生成型はサンプリングや反復更新（diffusionのステップ等）によりこの乖離が累積しやすく、制御ループに組み込むとリカバリが難しくなります。以上から最終的なDriveHeronでは、単発推論で連続値を直接出力する回帰型のtrajectory headを採用しました。

 モデルの入出力入力：
現在の画像フレームと過去フレーム（フロントカメラ）
車両状態（自車速度など）
Heron-NVILAでは入力画像をVision Encoderの入力解像度に合わせて、画像をタイルへ分割する前処理を行います（参考記事:日本語VLM「Heron-NVILA」公開 ─ Qwen2.5-VL-7B・Gemma3-12Bに匹敵する性能）。タイル数（＝画像トークン量の増加）はLLM側の計算量・レイテンシに直結します。このため、DriveHeronではタイル数を1に固定しています。
出力：
車両制御で扱える時間刻みに合わせた座標系で、将来の走行位置（x,y,z座標など）を複数ステップ先まで予測して出力します。

 モデルの学習DriveHeronでは人間の運転データから作成したtrajectoryをラベルとして用い、VLMとtrajectory headの両方を学習します。計算資源はGENIACの支援で確保したH200を複数ノード使用しました。また、trajectory学習に入る前にVLMを運転ドメインデータで事前学習することで、trajectory予測性能が向上しました。

 推論パイプライン車載での推論はモデルを1回呼べば終わりという単純な話ではありません。「データ整形→推論→安全な整形→制御系への受け渡し」までを一連のパイプラインとして成立させる必要があり、主に次の4ステップで構成されます。

前処理
センサ入力をモデル入力の形式に整える
画像のリサイズ・正規化
車両状態の整形、過去フレームのバッファリング


推論
モデルで推論して、将来軌跡を出力


後処理
出力軌跡の整形
異常値のガード（NaN/Infの検知、値のクリップなど）
後段で扱いやすい形への変換（補間・再サンプリングのための準備）


周辺連携
車両制御モジュールへ処理結果を渡す
可視化・ロギング

この4ステップの合計レイテンシが100msを超えると10Hz（100ms周期）の運転ループにモデルの推論が間に合わず、出力される軌跡は過去のセンサ情報に基づくものになります。

さらに更新が間に合わない間は車両側が直前の軌跡を継続して参照するため、操作が後追いになったり、更新タイミングで参照する軌跡が切り替わり、操作がカクつきやすくなります。

このため実車で安定動作させるには、前後処理を含む合計レイテンシを100ms以内に収めることが必要です。DriveHeronではTensorRTによる最適化とFP16の低精度推論により、2B（約20億パラメータ）のVLMでも前後処理を含めて100ms以内を達成しました。

 車載システムとの結合学習時のvalidationの数値が良くても、車載で同じ挙動になるとは限りません。センサの遅延・欠損、時刻同期のズレ、画質劣化、車両状態のノイズ、制御側の制約などオフライン評価では顕在化しない要因が多く、最終的な性能は実車で走らせて初めて分かる部分が大きいです。そのためDriveHeronでは、モデルを作って終わりではなく、車載にデプロイして走行し、ログを分析して改善するという次のようなサイクルを地道に繰り返しました。

車載デプロイ：推論エンジン（TensorRT）を更新し、車載環境で再現性を担保して動作確認

走行ログの収集：入力（画像・車両状態）と出力（軌跡）が後から追える形で記録

症状の切り分け：
モデル起因：特定状況で軌跡が破綻する、過敏または鈍感になる
パイプライン起因：同期ズレ、前処理差、低精度推論による乖離
制御起因：制御側の制約により、モデル出力どおりに追従できない


改善と再デプロイ：モデル／前後処理／インタフェースのどこを直すべきかを決め、次の走行で検証
このプロセスは一度うまくいったら終わりではなく、走行条件・車両状態が変わるたびに別の問題が出てくるため、試行錯誤の積み重ねが不可欠でした。地味だが致命的になり得る部分を一つずつ潰すことで、実車で安定動作する状態に近づけていきました。

走行実験では車両制御チームとの連携が不可欠で、症状共有、再現、原因分析、改善確認を一体で進める必要がありました。DriveHeronの実車安定動作には、車載制御・運用メンバーとの継続的な連携が必須でした。

また、DriveHeronでは車両制御とモデル推論を別マシンで分離する構成を採用しました。これにより、大規模モデルの推論負荷が制御系の計算資源を圧迫することを避けるとともに、異常時や緊急停止時にも制御側が安全に振る舞えるようにしています。実車で安定して動かすためには、モデル精度だけでなく、このようなシステム構成上の配慮も不可欠でした。

 おわりに本記事ではGENIAC第3期の支援のもと、VLM「Heron」を土台にした自動運転VLAモデル「DriveHeron」を車両制御に接続できる将来軌跡出力として設計し、10Hzの制御ループに間に合う形で車載システムとして成立させるまでの取り組みを紹介しました。

論文でのVLAの議論はモデル設計に焦点が当たりがちですが、実車適応を考えると、最適化した推論パイプラインを設計し、改善サイクルを回すことが重要です。「机上で動くモデル」と「実車で動くシステム」の間には想像以上に多くのハードルがあります。

現状のDriveHeronは「VLMを制御ループに接続して実車で回す」段階に到達したところで、言語の能力を十分に引き出せているとは言えません。加えて、より長い時系列やマルチカメラ入力を扱うための情報圧縮・学習手法も重要な課題であり、次の大きな挑戦になります。今後も引き続き、実車で成立する形を意識しながらVLAを改善していきます。