エージェント向けフロンティアAI推論クラウド — Byung-Gon (Gon) Chun (FriendliAI)
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00それでは始めましょう。皆さん、こんにちは。ご参加いただきありがとうございます。最終日の夕方という時間帯にお越しいただき、本当に感謝しております。
00:00:25Friendly AIの創業者兼CEOのGonです。本日は「エージェンティック推論（Agentic Inference）」についてお話しします。何が変わったのか、なぜ重要なのか、そしてエージェント向けに推論クラウドをどう再構築したかについて説明します。
00:00:40本題に入る前に、Friendly AIについて簡単に紹介させてください。Friendly AIは、エージェントのための最先端AI推論クラウドです。
00:00:50大規模で、より速く、より安く、そしてより高い信頼性を提供します。私たちはソウル大学の研究チームから誕生し、その研究におけるルーツが今も私たちの原動力となっています。
00:01:02私たちは、今や業界標準となった推論最適化技術である「Continuous Batching（連続バッチ処理）」を考案したチームであり、私たちのORCA研究は、広く使われているオープンソースフレームワークのvLLMにも大きな影響を与えました。
00:01:15現在、私たちはサンフランシスコに本社を置き、ソウルのチームとともに、最先端推論のスケールアップに向けてグローバルに展開しています。
00:01:24ご存じの通り、2026年はエージェントが本格的に商用利用される年であり、これは2つのトレンドが合流したことで加速しています。
00:01:331つ目は、エージェントの爆発的な普及です。AIエージェントは、ソフトウェア、業務運用、ナレッジワークの全般において飛躍的な導入を牽引しています。
00:01:452つ目は、オープンウェイトモデルが最先端（Frontier）レベルに達し、エージェントの経済性を高めたことです。能力面で商用のフロンティアモデルに対抗できるようになり、よりはるかに低いトークンコストで最先端品質のエージェントを運用できるようになりました。
00:02:00オープンウェイトモデルが、こうした実践的なエージェントワークフローに十分対応できるレベルに達していることをお見せしましょう。
00:02:13ここでは、コーディングエージェントを使ってタワーディフェンスゲームを作成するというまったく同じタスクを、2つのモデルに与えました。
00:02:19左側はFriendly AI上で稼働しているオープンウェイトモデルのGLM 5.2です。右側はAnthropicのOpus 4.8です。
00:02:29重要なのは、出力が完全に一致していることではありません。両者ともに実用可能なレベルでタスクを完了させている点です。
00:02:38多くのエージェントワークフローにおいて、オープンウェイトモデルは品質の基準値をクリアしていますが、経済面では大きな差があります。
00:02:49同じタスクを実行した場合、Opus 4.8は約1.50ドルかかります。一方、Friendly AI上のGLM 5.2は0.27ドルであり、5.6倍も安くなります。
00:03:03これこそが、先ほどお話しした可能性です。オープンウェイトモデルを使えば、ほんのわずかなコストでフロンティアレベルの品質を持つエージェントを利用できます。
00:03:12しかし、モデルのコストは全体の一部に過ぎません。エージェントを実際に高速かつ信頼性の高いものにするには、推論スタック自体を変革する必要があります。
00:03:22では、エージェントワークロードの内部で実際に何が起きているのかを見ていきましょう。
00:03:28まず、ワークロードの変化について見ていきます。かつてはチャット用途が主流でした。
00:03:34基本単位は「リクエスト」でした。人間が質問し、モデルが回答し、それを人間が読みます。
00:03:41レイテンシとは「1つの応答をいかに速く得るか」でした。しかし、エージェントは異なります。基本単位は「タスク」です。
00:03:491つのタスクには多数のモデル呼び出しやツール呼び出しが含まれ、自律的にしばらく実行される場合があります。
00:03:58そのため、ユーザーは単一リクエストのレイテンシをそこまで気にしません。
00:04:04ユーザーが気にするのは、タスク全体が「いつ完了するか」です。
00:04:08つまり、個々のリクエストだけでなく、タスク全体を最適化する必要があるのです。
00:04:16エージェントのワークロードを詳しく見てみましょう。エージェントは複数のタスクで構成されるセッションを実行します。
00:04:23各タスクは通常、ループ処理で動きます。まず「計画」を立てますが、これには通常LLMの呼び出しを伴います。
00:04:29次にツールを呼び出すなどの「実行」を行います。その後、結果を「観察」してコンテキストに追加します。
00:04:38そしてタスクが完了するまでこれを繰り返します。
00:04:41つまり、LLMの推論と、1つ以上の非LLMツールの実行を絶えず交互に行っているのです。
00:04:50そのため、LLM呼び出しの間にギャップが生じます。また、エージェントはサブエージェントを生成して並列実行することもあります。
00:05:01エージェントの入力もチャットとは全く異なります。こちらのグラフは、社内で日常的に使用しているGLM 5.2でのコーディングエージェント実行時の、プロンプトと完了トークン長の分布を示しています。
00:05:15これらは非常に長いです。観察結果が毎回コンテキストに追加されていくため、タスクが進むにつれて肥大化していきます。
00:05:25ここで重要なパターンがあります。連続するエージェントのステップでは、通常、膨大な接頭辞（プレフィックス）が共有されます。
00:05:32毎回その同じプレフィックスを再計算していては、すでに完了した作業に膨大な計算資源を浪費することになります。
00:05:40つまり、これこそがエージェント型推論における最大の機会の一つなのです。
00:05:46では、エージェントはどれほど多くのトークンを消費するのでしょうか？
00:05:49ディープリサーチのような、長時間を要するタスクの例を見てみましょう。
00:05:53 Friendly AI上のGLM 5.2を使用し、Kilo Codeの環境でvLLMのSpeculative Decodingフレームワークについて解説を作成しました。
00:06:02ここには複数の段階があり、各段階は複数の推論とツール呼び出しを実行するサブエージェントで構成されています。
00:06:12そのため、数十から数百回もの推論ステップが実行され、数分から数時間に及ぶこともあります。
00:06:19そして共有コンテキストは、実行中ずっと増大し続けます。
00:06:23ユーザーにとって重要なのは、単一トークンや個々の呼び出しのレイテンシではありません。
00:06:28重要なのは「タスクがいつ完了するか」です。
00:06:35つまり、エージェント推論は単にリクエスト数が増えただけのチャットではありません。
00:06:39まったく別の問題なのです。コンテキストは時間とともに増大します。
00:06:43ツールの処理がモデル呼び出しの合間に挿入されます。
00:06:46モデル呼び出しの回数は入力に依存します。
00:06:49そのため、固定されたリクエストレートを前提に計画を立てることはできません。
00:06:55そして真の指標は、単一リクエストのレイテンシではなく、エンドツーエンドのタスクレイテンシなのです。
00:07:02では、どのようにそれを実現するのでしょうか？その背景にある主要なエンジニアリング技術をご紹介します。
00:07:23こちらが私たちの設計思想を示すエンジニアリングマップです。
00:07:27エージェントのワークロードを中心に、スタックをレイヤーごとに構築しました。
00:07:33本日解説する主要な柱は4つあります。
00:07:37プレフィックスキャッシュ、Key-Value（略してKV）キャッシュ管理、キャッシュ認識型ルーティング、そしてエージェント認識型最適化です。
00:07:48もちろんその下層には、長文コンテキストに対応するSparse Attentionのようなモデル層の最適化や、
00:07:56エラー削減技術、高速カーネル、高信頼性サービングなどが不可欠となります。
00:08:02今回は、この4つの柱に焦点を当てます。
00:08:05まずはプレフィックスキャッシュから始めましょう。
00:08:09エージェントのステップ間で大きなプレフィックスが共有されるため、プレフィックスのKVを一度計算してキャッシュします。
00:08:17以降のステップでは、キャッシュされたKVを再利用し、新しいサフィックス（接尾辞）のみを処理します。
00:08:23キャッシュからの読み込みはプレフィルの再計算より大幅に低コストなため、
00:08:27最初のトークン生成時間（TTFT）が改善し、各ステップの計算量を削減できます。
00:08:33エージェントでタスクが長く実行されるほど、この価値は高まります。
00:08:41しかし、キャッシュが機能するのは、KVキャッシュがメモリ内に収まり、効率的に移動できる場合のみです。
00:08:48そのため、強固なKVキャッシュ管理が必要です。
00:08:52高度なメモリ管理を活用して、各GPUメモリにより多くの有効コンテキストを詰め込みます。
00:08:59また、KV量子化を用いてメモリフットプリントを削減します。
00:09:04GPUメモリ、ホストメモリ、ディスクにわたる階層型キャッシュを使用し、GPUの制限を超えた拡張を可能にしています。
00:09:13さらに分散キャッシュを採用することで、単一インスタンス内だけでなく、複数のレプリカ間で1つのプレフィックスを共有・配信できます。
00:09:26グローバルなクラスタ規模では、ルーティングが非常に重要になります。
00:09:29単純なロードバランサはGPUクラスタ全体に均等にリクエストを分散させますが、これではキャッシュの局所性が破壊されてしまいます。
00:09:38グローバル規模の「キャッシュ認識型ルーター」は、よりスマートな処理を行います。
00:09:42適切なプレフィックスをすでにキャッシュしているPodにリクエストを送信することで、重いプレフィル処理を単なる1回のキャッシュヒットへと変換します。
00:09:51同時に、特定のPodがボトルネックにならないよう、負荷の分散も行います。
00:09:58この例では、キャッシュの局所性を維持するため、タスクAの2つのリクエストが同じPod 1にルーティングされています。
00:10:08次の要素は「エージェント認識型最適化」です。
00:10:11これこそが、エージェント推論における次なるフロンティアです。
00:10:16現在の多くのシステムは、個々のLLM呼び出しをそれぞれ独立したものとしてスケジューリングしています。
00:10:21その呼び出しが一連のエージェントプログラムの一部であることを理解していません。
00:10:27しかし、オプティマイザがエージェントレベルの文脈を把握していれば、より優れた判断を下せます。
00:10:33例えば、適切な処理の中断（プリエンプション）、次に起こりそうなステップのコンテキストの投機的プレフィル、エージェントレベルの文脈に基づくより的確なキャッシュ破棄の判断などです。
00:10:48単一の呼び出しを速く見せるだけでなく、エンドツーエンドのタスクレイテンシを短縮することが目的なのです。
00:10:58これらをすべて組み合わせることで、大きな成果が得られます。
00:11:01ここでは、同じモデルGLM 5.2とKilo Codeを使用して、シンプルなモバイルゲームを作成しています。
00:11:07Friendly AIのモデルAPIと、有名な別の推論プロバイダーで同じタスクを実行しました。
00:11:14ご覧の通り、エージェントに特化したクラウド設計のおかげで、Friendly AIは同じタスクをエンドツーエンドでより迅速に完了できます。
00:11:24では、これによって実践的に何が可能になるのでしょうか？
00:11:29より強固な本番環境向けエージェントスタックです。
00:11:32すでにお使いのお好みのエージェントをご用意ください。
00:11:35そこに、Friendly AI上で提供されているGLM 5.2、Minimax、Kimiといった最先端のオープンウェイトモデルを組み込みます。
00:11:43モデルは最高峰の能力と優れた経済性を提供します。
00:11:49そしてFriendly AIは、本番環境で求められるスピード、信頼性、エンドツーエンドのタスクパフォーマンスを提供します。
00:11:56品質、速度、信頼性、コストの組み合わせが、実用性と経済性を兼ね備えた本番運用エージェントを実現するのです。
00:12:06Friendly AIは現在、AIネイティブのスタートアップからグローバル企業まで、数々の本番開発チームを支えています。
00:12:15ここで2つの事例をご紹介します。
00:12:20Kiloは数百万人のユーザーを抱える、大人気のAIコーディングエージェントツールです。
00:12:27LGは、エレクトロニクスからヘルスケア、エネルギーまで幅広い事業を展開するグローバル企業です。
00:12:35まったく異なる企業ですが、求めているものは同じです。
00:12:39高速で信頼性が高く、費用対効果に優れたエージェント推論です。
00:12:45クライアントであるKiloからの推薦文が、すべてを物語っています。
00:12:50「過去1年間、Kilo Codeはオープンおよび商用モデルをホストする複数の推論プロバイダーをテストしてきました。
00:12:56他のサードパーティプロバイダーや開発元のZhipu AIからの直接利用と比較したGLM 5の分割テストにおいて、
00:13:05Friendly AIは一貫して7倍高速であり、エラー率も大幅に低い結果を示しました。
00:13:12現在、Friendly AIはKiloのスタックにおける中核コンポーネントとなっています」
00:13:17また、皆さんのスタックに最適な形で導入することができます。
00:13:23「Model API」は最も迅速に開始できる方法です。
00:13:26サーバーレスAPIを通じて主要なフロンティア・オープンウェイトモデルを利用できます。
00:13:29「Dedicated Endpoints」は、商用ワークロード向けにSLAが保証された専用の独立デプロイメントを提供します。
00:13:36そして「BYOG（Bring Your Own GPU）」を使えば、自社のインフラ上でFriendlyの推論スタックを実行できます。
00:13:44同一のスタックを、3つの展開方法で提供しています。
00:13:49まとめとして、覚えておくべき3つのポイントがあります。
00:13:53第一に、最先端のオープンウェイトモデルにより、本番エージェントの経済的なスケールが可能になります。
00:13:59第二に、エージェントは単に呼び出し回数が増えただけのチャットではありません。
00:14:03エージェント推論では、先ほど述べた課題に対応しつつ、エンドツーエンドのタスクレイテンシを最適化する必要があります。
00:14:10第三に、Friendly AIはまさにこの世界のために構築された推論クラウドです。
00:14:16高速で信頼性が高く、コスト効率に優れたエージェント推論を提供します。
00:14:23ご清聴ありがとうございました。
00:14:25エージェントを構築されている方は、ぜひ本日Friendly AIで最先端オープンウェイトモデルをお試しください。
00:14:30Friendly AIなら、わずか数分で利用を開始できます。
00:14:34ありがとうございました。
00:14:35セッション後も会場におりますので、お気軽にお声がけください。
00:14:37ありがとうございました。
00:14:38重ねてお礼申し上げます。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video