VLM Run Gateway、OCR・動画・視覚モデルのAPIを統一。ただしモデル名だけでは推論の同等性を保証できず

VLM Runは9月4日、オープンウェイトのOCR、汎用VLM、物体検出、セグメンテーション、姿勢推定などのモデルを単一のOpenAI互換エンドポイントに集約する[Gateway](https://www.vlm.run/gateway)を公開した。アプリケーションはChat Completions SDKをそのまま利用し、`base_url`、モデル名、画像・動画・文書の入力だけを変更できる。さらに、エージェントが視覚機能をツールとして呼び出せるMCP serverも提供する。現在公開されているカタログには21種類のモデルが掲載され、それぞれの入力形式、コンテキスト長、料金が示されている。

このサービスが対処するのは、テキストモデルAPIでは見えにくくなりがちなマルチモーダルルーティングの問題だ。同一のモデルIDでも、実際には異なる量子化形式、vLLM／SGLangのパラメーター、画像前処理に対応している場合がある。テキストのベンチマークでは表面化しない量子化誤差が、小さな文字のOCR、表の座標、空間的関係では大幅に増幅される可能性がある。このため公開チームは、同名のエンドポイントを同等と見なすのではなく、具体的なモデルとサービング設定を選択可能な実行ターゲットとして扱うとしている。

動画も、互換性における別の欠落部分だ。チームは[Hugging Faceの技術解説](https://huggingface.co/blog/vlm-run/introducing-gateway)で、テストした主要なルーティングプロバイダーの8割以上が動画のネイティブ入力を処理できず、サンプリングFPSを制御できるものはさらに少なかったと述べている。一方、Gatewayではクライアントが動画モデルと処理方法を指定できる。文書処理パイプラインでは、レスポンス契約を統一することで、汎用VLM、特化型OCR、小型モデルの間でA/Bテストを行う際の統合コストも削減できる。

ただし、現時点ではホスティング型のゲートウェイであり、ルーティングと推論環境全体を自ら再現できるオープンソースのランタイムではない。公式が掲げる毎秒3,000超の出力tokenといった数値には、ハードウェア、バッチサイズ、ページ解像度、精度条件の完全な情報が付随していない。また、「同じAPIをサポートする」ことは、異なるモデル間で座標、Markdown、ツール出力のセマンティクスが一致することを意味しない。導入前に、エンジニアリングチームは元画像とモデルバージョンを保存し、中国語の縦書き、繁体字、表、低解像度スキャンを対象とする独自の回帰テストセットを構築するとともに、データ保持、リージョン別デプロイ、障害時のリトライポリシーを確認すべきだ。