스크립트
00:00:00皆さん、こんにちは。CorviのSitan Shuです。本日は垂直的
00:00:19モビリティについてお話しします。少し大層なタイトルを付けましたが、要するに
00:00:26Corviで構築している推論プラットフォームについてです。小規模から大規模なモデル、
00:00:30様々な種類のワークロードに対応します。簡単に自己紹介をしますと、
00:00:384ヶ月ほど前にCorviに入社し、推論部門全体を統括しています。それ以前は
00:00:44AWS Annapurna Labsで学習領域を担当し、さらにその前は
00:00:49SambaNovaで推論と学習を手掛けていました。この分野にはかなり長く携わっています。
00:00:56本日の流れとしては、まず私たちが提示する消費モデル（利用形態）
00:01:00について説明し、そこからプラットフォームを常に刷新し続けなくても済むよう
00:01:04どのような設計に導き出したのか、そして推論提供向けプラットフォームの強化を
00:01:09いかに継続しているかを解説します。また、なぜパフォーマンスがそこまで重要なのか
00:01:14についてもお話しします。先ほど議論されたテーマと一部重複する点もあるかと思います。
00:01:20消費モデルについて。大きく分けて2つの主要な消費モデルがあります。1つ目はサーバーレスです。
00:01:29これは顧客や利用者が、ハードウェア自体の管理を心配する必要がなく、
00:01:35クラスタ管理やオーケストレーションなどを一切気にする必要がないモデルです。
00:01:40APIやUI経由でアクセスし、トークン単位で支払うだけでモデルの推論を利用できます。
00:01:47ここでの最大のポイントは、カタログで提供するモデルの種類、つまり利用者が
00:01:54選択できるモデルの幅広さです。デディケーテッド（専用）について話してからサーバーレスに戻ります。
00:02:01サーバーレス側に独自の要素があるためです。私たちが提供するデディケーテッド推論サービスは、
00:02:05どのハードウェアを使用して実行するかを正確に把握したい顧客向けですが、
00:02:11モデルのデプロイ自体は顧客に依存します。当社のサービスやオーケストレーション層を使いますが、
00:02:18モデルのデプロイは顧客次第です。プラットフォーム側でそれらの機能を配信する
00:02:25機能や設定（ノブ）を提供する限り、モデルのパフォーマンスも顧客に委ねられます。サーバーレスの話に戻ると、
00:02:30興味深い点の一つとして、一般的なサーバーレスモデルでは「ノイジーネイバー（近隣トラブル）」問題が発生します。
00:02:38例えば全員がまったく同じモデルに一斉アクセスした場合、背後のキャパシティ次第では
00:02:43タイムアウトが頻発する可能性があります。そこで、サーバーレス側に備えているもう一つの機能が
00:02:48「プロビジョニング済みスループット」と呼んでいるものです。顧客として自身のトラフィック傾向を把握しており、
00:02:55それを事前にお知らせいただければ、裏側で専用の帯域を確保することができます。
00:03:00スループットやSLAが維持されている限り、具体的にどのようなハードウェアで
00:03:04稼働しているかを意識する必要はありません。
00:03:07これもサーバーレス側の機能であり、課金はトークン単位のままですが、
00:03:12ノイジーネイバー問題に遭遇せずに済むことが担保されます。
00:03:19現在見られるいくつかの異なる種類のワークロードや、そのプロファイル（形状）について簡単に触れます。
00:03:27それらの比率は絶えず変化していますが、エージェント型（Agentic）は
00:03:32非常に高い割合を占めています。エージェント型とチャットは極めて類似しており、通常は入力シーケンス長が
00:03:39非常に長く、出力シーケンス長は短くなります。しかし、エージェント型とチャットの最大の違いは、
00:03:43エージェント型におけるマルチターン（複数回のやり取り）が超低レイテンシである点です。チャットの場合、
00:03:50ユーザーからの応答を受け取ると、人間が回答を読んでから返答するためラグが生じます。
00:03:56そうした違いが存在します。そしてその大きな違いは、最終的に
00:04:01KVCache管理に関連するアプローチへと変換されます。これら2つはいずれもリアルタイム処理ですが、もう1つのリアルタイム型は
00:04:09音声や動画であり、一定のストリーミングかつレイテンシに極めて敏感です。エージェント型やチャット
00:04:16においては、要件の大部分がスループットの観点であり、レイテンシほどではありませんが、リアルタイムの
00:04:23音声や動画は絶対にレイテンシが最優先されます。次にバッチ処理ですが、バッチはSLAがかなり
00:04:32ゆるやかです。数秒から数分、顧客によっては数時間単位になることもあります。
00:04:37「10〜12時間の処理枠をくれれば投入できるだけ投入するから、
00:04:44手が空いた時に処理してくれればいい」というスタンスです。これらのバッチワークロードが、
00:04:52スタックにおける設計上の選択肢を決定する際の要件としてどう関わってくるか説明します。
00:04:59これら4つの異なるワークロードプロファイルを想像してみてください。時間軸の中で、
00:05:04基盤となるインフラの利用率を最大化するために、それぞれの特性をどう組み合わせるかというゲームが必要になります。
00:05:12現在のスタック構造の全体像について説明し、
00:05:19リクエストフローを順を追ってご案内します。サーバーレスとデディケーテッドの双方において、画面右側を
00:05:24見ると、プラットフォーム側ではコントロールプレーンに移動して
00:05:31認証、レート制限、使用状況の追跡などを行い、適切に課金できるようにしています。
00:05:37また、締結されたSLAに違反していないか確認するための可観測性（オブザーバビリティ）も備えています。
00:05:45プラットフォームの基盤として、超ハイレベルな構成図に示している通り、
00:05:52vLLM、SGLang、TensorRT-LLMといった異なる推論エンジンがありますが、ここには後ほど触れる詳細が多々あります。
00:06:00さらにその下層にある、緑色で示されている部分は様々なハードウェアコンポーネントです。
00:06:09つまり、プラットフォームはワークロードを複数世代のGPU、
00:06:15特に私たちが使用しているNVIDIA GPUの各世代へと適切に分散・共有できる十分な性能が必要です。
00:06:21いくつか例を挙げてみましょう。アプリやJupyter Notebook、あるいは
00:06:31エージェントなどを介してクライアント側からリクエストが発生したとします。それがゲートウェイに到達します。
00:06:36ゲートウェイに到達すると、コントロールプレーンで言及した通り、認証などを
00:06:42経由しますが、その後サーバーレスかデディケーテッドかに分岐します。サーバーレスの場合、
00:06:48従量課金制となるため、ここではトークンの使用量が監視されます。トークンの具体的な中身ではなく、
00:06:53使用量のみです。当社はZDR（データ保持ゼロポリシー）を維持しているためです。
00:06:59マルチテナントかプロビジョニング済みかによりますが、プロビジョニング済みの場合は、
00:07:05ルーター配下において、プロビジョニング済みスループットを購入した顧客向けの
00:07:12明示的なデプロイを直接ターゲットにする必要があると判断します。マルチテナントの顧客には別のデプロイが用意されます。
00:07:17ここで特にルーターが重要になります。なぜならルーターは
00:07:26KVCacheを意識したルーティング判断を行う責任を負っているからです。なぜそれが重要かというと、ワークロードプロファイルの
00:07:31議論の際にも触れたように、エージェント型のユースケースは通常、入力シーケンス長が
00:07:39極めて長く、入力シーケンスの大部分（企業や顧客によりますが
00:07:44およそ80〜90％）が、様々なリクエスト間で共通しているからです。
00:07:51そのため、その部分のプレフィル（Prefill）を再度計算したりやり直したりする意味はありません。
00:07:57プレフィルは非常に計算負荷が高く高コストなため、キャッシュをヒットさせればさせるほど
00:08:04コストを削減できます。どこでもトークン価格を見ると、通常の入力トークン価格と
00:08:11キャッシュされた入力トークンの格安な価格が分かれているのはそのためです。ですからキャッシュは極めて重要に
00:08:18なってきます。ハードウェアをどのように分割したいかの根本的な部分は、プラットフォーム上の選択肢に完全に依存しており、
00:08:26当社はどちらの構成も可能な機能を提供しています。ユースケースが求めるならばプレフィルとデコードの選別（Disaggregation）を行い、
00:08:31不要であれば行わない、といった選択です。プレフィルとデコードの分離は、あらゆるユースケースで安価に済むわけではないからです。
00:08:41別のリクエストフローも見てみましょう。デディケーテッド顧客の場合にどうなるかを確認します。
00:08:48デディケーテッド顧客も同様に、適切な分離環境で設定された専用ゲートウェイを経由します。
00:08:55課金はトークンベースではなく、GPU時間あたりの使用量に基づきます。
00:09:03プライベートゲートウェイであるため、ノイジーネイバー問題は発生せず、他者が進入することはありません。
00:09:09ルーターのロジックは同じで、非常に類似したリクエストがあれば、キャッシュに最大限ヒットさせます。
00:09:18そして、割り当てられた専用GPU上で顧客が行うデプロイに応じて、
00:09:24プレフィルとデコードの分離を行うかどうかを決定できます。また、使用するエンジン（
00:09:29vLLM、SGLang、TensorRT-LLMのどれか）を選択できます。そして予約したリソースの全体量に応じて、
00:09:35クラスタ全体にスケール可能な単一のデプロイにするか、
00:09:42複数モデルを扱う複数のデプロイ構成にするかを決定できます。
00:09:47ここでのルーターについて一つ言及しておきたいのは、
00:09:54異なるゾーンやリージョンにまたがるヘテロジニアス（異種混在）なキャパシティも
00:09:59サポートされているという点です。これを跨いでロードバランシングを行うのはかなりの難題です。
00:10:04そのため、私たちが採る優先順位としては、まずKVCacheの局所性（Locality）、次により負荷の低い環境へのフォールバックとなります。
00:10:16以上がその説明です。もう一つお話ししたいリクエストフローがあり、
00:10:21図からは少し見えにくいかもしれませんが、バッチワークフローについて取り上げます。
00:10:25バッチワークフローの場合、実際に行うのは顧客が保有する基盤キャパシティ（
00:10:31例えば同じデディケーテッド推論の顧客）において、米国の日中はリアルタイム
00:10:37ワークロードを稼働させ、夕方から夜間にかけてはバッチワークロードを走らせたい場合、一定時間後に同じリソースを
00:10:43バッチ処理用にスケジュール変更できます。そのためAPI内にスケールアップや
00:10:51スケールダウンのタイミングを指定する機能を提供しており、スケールダウン可能との指示があれば
00:10:56縮小を行い、夜間のバッチ処理用にリソースを開放します。
00:11:05KVCache側の最適化についてはかなりお話ししてきましたが、少し繰り返させてください。
00:11:10ここが最も興味深いポイントの一つだからです。キャッシュヒット率を上げられれば上げるほど、
00:11:19最も高コストな プリフィルのコストを回避できます
00:11:26エージェント型ワークロードの 複数ターンにわたるKVキャッシュの再利用や
00:11:31ターン間においても 入力シーケンス長には同様のプリフィルが多く含まれます
00:11:38チャットワークロードを考えると KVキャッシュのオフロードが極めて重要になります
00:11:43なぜなら チャットではユーザーのやり取り（ターン）の間に
00:11:49大きなレイテンシが生じるからです 会話データを完全に破棄してしまうと
00:11:57同じチャットで次に質問した際 処理に少し時間がかかってしまいます
00:12:02完全に破棄してプリフィルをやり直す代わりに 採用されている手法として
00:12:08独自技術のほか 外部ではLMCacheやMooncakeなどが知られています
00:12:17KVキャッシュを帯域幅の広いストレージにオフロードし
00:12:21多くのプリフィルを保存しておくことで 該当する会話の要求が届いた際
00:12:28すぐにHBMへと読み込めるようになります
00:12:37性能向上レバーについて言及しておくと 先ほど話したPD分離のほか
00:12:41量子化や推測デコーディング（Speculative Decoding）が挙げられます
00:12:48並列化の度合いや戦略を慎重に選ぶことが 非常に重要となってきます
00:12:54私たちが注力してきた2大レバーは NVFP4への量子化と推測デコーディングです
00:13:01お客様のデータセットに合わせて 受理長（Acceptance Length）を高めるための
00:13:07ドラフトモデル（Speculator）を学習させる機能も提供しています
00:13:12これにより出力スループットが大幅に向上します 処理は非同期で行われます
00:13:20非同期でデータを受け取り 学習させ 必要に応じて環境へデプロイします
00:13:26ここに3つのスクリーンショットがあります これは
00:13:32私のチームメンバーがこの1ヶ月間で行った成果です
00:13:39Kimi 2.6や2.7のリーダーボードで迅速に上位を獲得したことが分かります
00:13:46前回のセッションの話に戻りますが「ベンチマークは信用できるのか？」という点で
00:13:52GLMについてはOpenRouterの結果を掲載しています Artificial Analysisは特定の負荷で測定しますが
00:13:58OpenRouterは実際のユーザーのトラフィックに基づいています
00:14:05Weights & Biasesとありますが 約1年前に買収した弊社のサービスです
00:14:09当社のデプロイメントによる速度は Fireworks Fastにかなり近いことが窺えます
00:14:16ですが ここで最も強調したいのは 性能最適化のための基盤技術です
00:14:21最終的にお客様へ提供したいのは 優れたコストパフォーマンスの恩恵だからです
00:14:27そのため この最適化が極めて重要になってきます
00:14:36簡単におさらいすると これまでお見せしてきたのは単一プラットフォームです
00:14:44サーバーレスと専有型の2つの利用モデルを提供しており
00:14:49サーバーレス内でも従量課金とプロビジョニング済みスループットの2通りがあります
00:14:53そして スタック全体の性能最適化を通じて相乗効果（成果）を生み出しています
00:15:01以上となります ご清聴ありがとうございました
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기