AsyncLLM、大規模言語モデルを汎用非同期エージェントへ

導入

多くのLLMエージェントは、入力を受け取り、推論し、返答またはツール呼び出しを実行し、その後で次の入力を待つというサイクルで動いている。この方式はチャットや短い自動化処理には向いているが、環境から情報が継続的に入ってくる場面では制約になる。音声アシスタントは前の発話を処理しながら新しい音声を受け取る必要があり、ロボットは周囲を観察しつつ次の動作を計画しなければならない。監視システムも、前の分析が終わるまで新しいイベントの受信を止めるわけにはいかない。

Yandex ResearchのオープンソースフレームワークAsyncLLMは、このような非逐次的な処理をより一般的な形で実現しようとする。論文「LLMs are General Asynchronous Agents」では、非同期性を特定タスク向けのアーキテクチャやAPIの外側にある制御だけに任せず、LLMの推論そのものに組み込む考え方が示されている。

主なポイント

• 推論内部で並行処理を行う。 AsyncLLMは複数のAPIリクエストを同時に発行するだけのラッパーではない。複数の推論プロセスを並行して動かし、更新途中の状態を互いに参照できる。
• コルーチンでエージェントを表現する。 エージェントはPythonのasync/awaitコルーチンの集合として定義できる。観察、分析、メモリ更新、行動などを別々のコルーチンに分け、イベント、ロック、キューで連携させる。
• キャッシュブロックを共有状態に使う。 各コルーチンはキャッシュブロックへ書き込み、キャッシュビューを通じて参照するブロックを選ぶ。これにより、すべての推論で完全なコンテキストを読み直すことなく情報を共有できる。
• 複数のモデル構成に対応する。 Mini-SGLangを基盤とする推論エンジンは、コルーチン間のリクエストをまとめて処理する。報告された実装は、フルアテンション、Gated DeltaNet、マルチモーダルM-RoPEモデルをサポートする。
• 実演ではタスク専用学習を使わない。 研究チームは、Qwen 3.xモデルをストリーミング動画理解、ゲーム、監視で非同期に動作させた。中心にあるのは、個別のタスクを再学習することではなく、推論の組み立て方を変えることである。

意義と課題

既存のエージェントシステムでは、並行性をアプリケーション層が担当することが多い。アプリケーションが複数のリクエストを起動しても、各モデル呼び出しは依然として逐次的に進むため、コンテキストの再送、状態同期、待ち時間が問題になりうる。AsyncLLMは並行性を推論の基本的な抽象化として扱い、複数の推論の流れが変化し続ける共有メモリを利用できるようにする。

この設計は、継続的な動画分析、リアルタイム監視、インタラクティブな環境と相性がよい。たとえば、ひとつのコルーチンが映像ストリームを受け取り続け、別のコルーチンが時間をかけて判断し、さらに別のコルーチンが異常への対応を担う、といった構成が可能になる。すべての処理を毎回ひとつの列に並べる必要はない。

一方で、非同期化すれば常に高速化するわけではない。共有状態の衝突、古くなった計画の中断、コルーチン間の計算資源の配分は、実運用で解決すべき課題として残る。並行する推論が増えれば、調整と安全管理の重要性も高まる。

AsyncLLMは、リアルタイムエージェントの問題をすべて解決する完成品というより、設計の方向性を示す取り組みだといえる。LLMを「すべてを読み、一度考え、出力する」単一ループではなく、新しい情報を受け取りながら観察、推論、行動を協調させるシステムとして捉え直す点に意義がある。

出典：Hugging Face Daily Papers