Yutori、ブラウザエージェントの推論アーキテクチャを公開：100Kの長い入力と短いツール出力、プレフィックスキャッシュでステップ当たりのコストを削減

YutoriとTogether AIは、Navigatorブラウザエージェントの本番推論設計を新たに公開し、コンピューター操作モデルの負荷特性が一般的なチャットサービスとは大きく異なることを明らかにした。エージェントは各ステップでブラウザ画面を取得し、新しいスクリーンショットと操作履歴全体をコンテキストに追加したうえで、マウス、キーボード、またはJavaScriptツールのアクションをモデルに出力させる。1件のタスクは10～15分続くことがあり、数十回のモデル呼び出しが発生する。入力は数千tokenから約100K tokenまで増加する一方、出力は通常ごく短いため、主なボトルネックは長文のデコードではなく、繰り返されるprefillにある。

[Together AIの技術事例](https://www.together.ai/customers/yutori)によると、同社のサービスはvLLMを基盤としてプレフィックスキャッシュを有効化している。隣接するステップ間では会話履歴の大部分が完全に同一であるため、理論上は以前に計算したKV cacheをそのまま再利用し、最新の画面とアクション結果だけを再処理できる。ただし、スケジューラーがキャッシュの所在を認識していなければ、リクエストがGPU間を移動した際にキャッシュヒットが失われる。このため、ブラウザエージェントのステップごとのレイテンシは、平均token/sだけでは評価できない。

プラットフォームは同時に、ワークロードを2種類に分けている。バックグラウンドで動作するScoutsではバッチスループットと1回当たりのコストを重視し、ユーザーが待機しているインタラクティブエージェントではテールレイテンシを厳格に制御する必要がある。そうでなければ、ブラウザセッションがタイムアウトする可能性がある。Togetherは、Navigatorが同等のフロンティアソリューションと比べてステップ当たり2倍高速で、推論コストは4～5分の1であり、99.9%のSLAを提供すると主張している。しかし、GPUの型番、バッチ戦略、キャッシュヒット率、完全なコストベンチマークは公開されておらず、現時点では独立した再現ができない。

モデル面では、YutoriはNavigatorに対し、合成データと実在するWebサイトのデータを用いて教師ありファインチューニングと強化学習を行ったとしている。[Navigator n1.5の公式情報](https://yutori.com/blog/introducing-n1-5)では、Online-Mind2Webの人手評価における成功率が97.3%だったと報告されている。ただし、Webサイトは継続的に変化しており、オンラインベンチマークもログイン状態、地域、ページのバージョンによる影響を受けやすい。エンジニアリングチームが次に注視すべきなのは、ベンダーが公表する平均速度だけではなく、キャッシュの分離、スクリーンショットデータの保存、テナント間のKV漏洩防止、そしてWebサイトの改修後における実タスクの失敗率である。