小規模モデル向けの大規模クラスター — ダニエル・スヴォナヴァ (Superlinked)
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00レビュアー：デニス・RQ
00:00:12よし、始めましょう。
00:00:14声は聞こえていますよね。
00:00:15自分の声は確かに聞こえています。
00:00:19近くに来てくれた方にはTシャツを差し上げます。
00:00:21本当ですよ。
00:00:22ここにTシャツが詰まった袋があります。
00:00:25質問してくれた方にもあげます。
00:00:26最後に質疑応答の時間があると思うので、
00:00:28質問してくれた方にもTシャツを差し上げます。
00:00:31それから、このスライドの背景にあるものが何か当たった方にも、
00:00:35同じくTシャツを差し上げます。
00:00:39わかる方はいますか？
00:00:42これは何を可視化したものでしょうか？
00:00:44この背景にある画像です。
00:00:49いませんか？
00:00:50Transformerモデルを見たことがある人は？
00:00:55そうです、位置エンコーディング（Positional Encoding）です。
00:00:57素晴らしい。
00:00:58そちらの方、Tシャツ獲得です。
00:00:59さて。
00:01:00本日は主に小型オープンソースモデルの性能がいかに向上したか、そしてそれらを独自のクラウドで多数運用する際に生じるユニークな課題について話します。
00:01:15本日紹介内容はすべてオープンソースで、
00:01:19自作・自律運用が可能です。
00:01:20コマンドを1つ実行するだけで、スタック全体を自分の管理下に置くことができます。
00:01:26プロプライエタリなコンポーネントは一切含まれていません。
00:01:31それでは進めていきましょう。
00:01:33よし。
00:01:34よし。
00:01:35これで大丈夫ですね。
00:01:36さて。
00:01:37スモールモデルについてです。
00:01:38スモールモデルとはどういう意味でしょうか？
00:01:40人によって捉え方は様々ですが、私としては「2〜3世代前のNVIDIA製ハードウェアで動くモデル」と考えています。
00:01:49モデル全体が1台のGPUに収まるため、運用・サービングが非常に容易です。
00:01:56そうしたGPUは入手しやすく、価格も手頃です。
00:02:01「スモールモデルだと、出力精度において何らかのトレードオフがあるのでは」と思う方が大半でしょう。
00:02:10今回の講演で、特定のタスクにおいては最先端（Frontier）と同等以上の性能を発揮し、明確な恩恵も得られるとお見せできればと思います。
00:02:22何桁もの大幅なコスト削減に加え、レイテンシやスループットの大きな改善も期待できます。
00:02:35これは私たちがよくお見せするチャートの1つです。
00:02:38Artificial Analysisの知能指数の推移を示したグラフです。
00:02:42あまり語られませんが、検討すべきオープンソースモデルには分類が存在します。
00:02:49GLM 5.2などのように、パラメータ数が例えば7,500億レベルに達する最先端のオープンソースモデルがある一方で、
00:02:57大型モデルや最先端モデルを少し後追いする形で、小型のオープンソースモデルが存在します。
00:03:04最先端領域は最近成長が鈍化していますが、小型モデルは急速に追いついてきています。
00:03:10トップ層では性能が収束・飽和傾向にあり、スモールモデルが進化を遂げているのです。
00:03:16例えばQwen 3.6 27Bなどは、GPT-5.1に近い性能を誇ります。
00:03:23つまり、GPT-5.1で動かしているワークフローやパイプラインがあれば、
00:03:29それをスモールモデルに移行して、先ほど挙げたメリットをすべて享受できます。
00:03:35もはや「単なる小規模モデル」ではありません。
00:03:38重要なのは、これらのスモールモデルを「どう活用するか」です。
00:03:44270億パラメータのQwen 3.6を「何でもプロンプトで指示できる万能モデル」として扱うべきではありません。
00:03:53そうではなく、汎用モデルのワークロードからタスクを切り分けるアプローチが必要です。
00:04:00そしてタスクごとに、どのオープンソースモデルが最も適しているかを特定します。
00:04:05評価を実施し、必要に応じてファインチューニングや適応化を行います。
00:04:08こうすることで、本番環境に投入できる適切な品質に到達させることができます。
00:04:15こちらは9種類ものモデルを活用した、契約書レビュー用エージェントの例です。
00:04:20小規模モデルに移行すると、ワークロードやエージェントでこのような構成が見られるようになります。
00:04:281つのAPIや1つのモデルに数多くの異なるリクエストを送りつける代わりに、
00:04:36複数のモデル群を活用する方が良いと気づき始めるでしょう。
00:04:38すると課題は「インフラ担当者を困惑させずにこれらをどう提供するか」になります。
00:04:45しかも、これは運用するエージェントのほんの一例に過ぎません。
00:04:48社内にはこのようなものが10個ほどあるかもしれません。
00:04:51つまり、インフラの適用範囲が拡大していくわけです。
00:04:57先ほど挙げた多様なタスクのそれぞれに対応するオープンソースモデルが、すでに存在しています。
00:05:05OCRから文書応答、画像ラベリング、SQL生成、コードレビューまで、
00:05:14それらのタスク向けに微調整や学習がなされたオープンソースモデルが存在します。
00:05:19例えばベトナム語の領収書OCR用に学習されたモデルは、その分野のデータを最も多く学習しています。
00:05:28誰かが時間をかけて可能な限りのデータを収集してくれたのです。
00:05:32その特定タスクにおいて、そのモデルは他のほぼ全てを凌駕します。
00:05:35Hugging Faceには、そうしたモデルが数千、数万と存在しています。
00:05:41すべて揃っており、基本的に無料で、多くが許容的なライセンスです。
00:05:46モデルはすでに揃っており、そこはボトルネックではありません。
00:05:50私たちは2024年からオープンソースAIについて話し続けてきました。
00:05:56しかし、今のところまだ本格的な普及には至っていません。
00:05:59企業で導入されている場合も、「オープンソースAI＝AWS Bedrock」のような状況です。
00:06:05しかしBedrockのモデルカタログを見ると、利用できる種類がかなり限られています。
00:06:14それらのモデルは古く、最新技術から2〜3年遅れていることも少なくありません。
00:06:19またBedrockでファインチューニングを行っても、作成された成果物を所有することはできません。
00:06:25そのため、自社の真の強みとして活用することが難しく、
00:06:29Bedrockのインフラ上でしか配信できないままになります。
00:06:32一方、vLLMやSGLangなどのオープンソースインフラで小規模モデルを運用する場合、
00:06:41特定のモデルやハードウェアの組み合わせにチューニングされているわけではない点に注意が必要です。
00:06:48自力でチューニングを行う必要があります。
00:06:51これらのツールには、チューニングやパラメータ探索、トラフィック調整の手順書が付属しています。
00:07:00ツールを採用しようとするたびに、終わりなき研究プロジェクトのようになります。
00:07:05そのため、単に導入してエンジニアリング作業を進めれば
00:07:101週間後に高性能な配信インフラが完成する、というものではありません。
00:07:14そんなに簡単にはいかないのです。
00:07:15これこそが、オープンソースツールに典型的な課題です。
00:07:19要するに、自作しなければならない部分が多すぎるのです。
00:07:21さらに、小規模モデル用に調整されていない点に加え、多数の異なるモデルを使用するトラフィック構造が、
00:07:32推論クラスタにおける従来の前提を覆してしまうのです。
00:07:37通常、1つの大型モデルを配信する場合の課題は「どう複数のGPUにモデルを分散させるか」です。
00:07:44ワーカーのKVキャッシュなどの状態を把握するルーターを上位に配置し、
00:07:51「このリクエストはこのワーカー群へ送る」といったトップダウンのルーティング判定を行います。
00:07:59非常にトップダウン形式な構成です。
00:08:01しかし、小さく高速なリクエストが大量にある場合、このルーティングが瓶首となります。
00:08:09ルーターが保持するワーカーの状態情報が少し古くなってしまい、ワーカーを十分に活用できません。
00:08:16各ワーカーのローカルキューの負荷を完全に平衡化するための決定を、上位で事前に行うのが難しいためです。
00:08:26小さなリクエストが大量に存在するからです。
00:08:29小規模モデルとこうしたトラフィックに対してvLLMやSGLangのルーターを試してみましたが、
00:08:37継続的な負荷のもとでGPU利用率を20%〜30%以上に上げるのは非常に困難でした。
00:08:44ルーティングのボトルネックにより、バッチサイズが適切に形成されないことが原因です。
00:08:51第3の課題として、小規模モデルではLoRAなどのモデル適応が極めて効果的である点です。
00:08:57そのため、処理すべきトラフィックには次のような相談が含まれてきます。
00:09:03「LoRAが10個あるのですが、現在の基盤でどう運用すればいいですか？」
00:09:08あるいは「昨晩作成した独自のファインチューニングモデルを本番環境で配信したい」といった要望です。
00:09:14これらのLoRAやカスタムモデルをデプロイするための、AIエンジニアとインフラ担当者の間の対話には
00:09:21多くの時間が必要となります。
00:09:24組織の速度を最も低下させる要因は、こうした調整のやり取りなのです。
00:09:30理想的には、インフラエンジニアもAIエンジニアもそれぞれの業務に専念し、
00:09:37日常業務において毎回話し合う必要がない状態が望ましいです。
00:09:41互いの作業を妨げないようにするためです。
00:09:45しかし小規模モデルにおけるモデル適応のニーズは、この関係を崩し、多くの手戻りを発生させます。
00:09:51そして、それが問題なのです。
00:09:54これが、多数の小型モデルを扱う際の課題です。
00:09:58「クラスターをどう構築し、いかに効率よく配信するか」という。
00:10:02私たちはしばらくこの問題に取り組んできました。
00:10:05自己紹介が遅れましたが、Superlinkedのダニエルです。
00:10:09サンフランシスコに拠点を置くVC出資の企業です。
00:10:13ここ数年、AIを活用した検索・文書処理システムやエージェントを構築してきました。
00:10:20最大の課題は常に推論にあり、特に先ほど説明した問題でした。
00:10:26そのため試行錯誤を重ね、多様な環境で大規模かつ広範な小型モデル群を運用するためのクラスター構成を探求してきました。
00:10:37何が利用できるかわからないような環境で、他のプラットフォームと共にデプロイする必要があるからです。
00:10:44どんな環境であれ、L4や小規模なGPU枠の確保は容易なため、小型モデルなら扱いやすくなります。
00:10:52そこで、私たちが最終的に到達したクラスター構成について少し説明します。
00:10:58ちなみに、これはすべてApache 2.0の完全なオープンソースです。
00:11:03そのまま持ち出してパッケージ化すれば、すぐに推論スタートアップになれます。
00:11:08制御プレーンからGPU上で動作する部分まで、すべてオープンソース化されています。
00:11:14出し惜しみは一切していません。
00:11:18構成としては、基本的にゲートウェイが存在します。
00:11:21振り分け先を事前決定するルーターの代わりに、リクエストを解析してメタデータを付与するゲートウェイを配置しています。
00:11:30そしてリクエストを共有キューおよびサイドチャンネルに投入します。
00:11:36これについては後ほどもう少し詳しく説明します。
00:11:37ワーカーにデータを押し出すのではなく、ワーカー側がその中央キューからデータを取りに行きます。
00:11:44この方法により、ワーカーのリソースを高効率で活用できます。
00:11:47ワーカーのセットアップ（スライドがあると思います）では、異なるモデルアーキテクチャの複雑さを
00:11:57Pythonの要件競合などが起きない一貫したワーカー群に集約する方法を解説します。
00:12:03これが全体のトポロジーです。
00:12:06そして、これがリクエストのライフサイクルです。
00:12:11ここからいくつかポイントをピックアップします。
00:12:15OpenAIのAPI標準で好ましくない点の一つに、base64エンコードされたJSONがあります。
00:12:25小規模モデルや高スループットには向きません
00:12:28そのため 全体でバイナリ形式のMessagePackを使用しています
00:12:31これにより マルチモーダルデータもAPIゲートウェイ経由で渡せます
00:12:37「バイナリデータは別で リクエストはここ」といった分離はありません
00:12:42画像や動画などのバイナリ読み込みに クラウドストレージへのアクセス権限も不要です
00:12:48すべてエンコードして ゲートウェイ経由で送信します
00:12:53ゲートウェイは重いデータを分離し 内部キューの詰まりを防ぐため クラウドストレージに一時退避させます
00:13:021メガバイトを超えるようなリクエストを分割し バックエンドでクラウドストレージを活用します
00:13:09ユーザー側はデータをAPI層に送るだけで済み クリーンなインターフェースが保たれます
00:13:19スタック全体はRESTベースで ゲートウェイもワーカーもREST ローカルのソケット経由で各種ランタイムに接続します
00:13:30ランタイムには PyTorch、Candle、SGLang があります
00:13:35最適化については後述しますが どのランタイムを使用する場合でも
00:13:43そこで実行されるコードが 最も効率的になるよう担保しています
00:13:47そのために 自動リサーチ・ループを備えています
00:13:50リクエストのライフサイクルは このような流れになります
00:13:54重要なポイントは リクエストを最初に受けるゲートウェイに 処理をさせすぎないことです
00:14:05処理が多すぎると ボトルネックになってしまうからです
00:14:07リクエスト全体をパースすることすら 避けるべきです
00:14:09パケットを確認してデータの概形を把握し アノテーションを行ったら
00:14:16数百台のGPUを持つワーカー群が キューの状態を見てデータを取得します
00:14:25キューには NATS JetStream を使用しており 秒間100万リクエストを処理できます
00:14:32これがボトルネックになることは まずありません
00:14:35理想としては 各コンポーネントを通過する際に シリアライズやデシリアライズを行わないことです
00:14:42これは極めて基本原則的な考え方です
00:14:45このアニメーションは 集中型キューの概念を示しています
00:14:51トップダウン型のルーターが ローカルキューを完璧に調整しようとするのは ほぼ不可能です
00:15:01キューを集中化し ワーカー自らがバッチの処理コストを予測して
00:15:09バッチを構築するタスクを引き受けることで 効率を大幅に向上させられます
00:15:15補足ですが 実際に取り組み始めると 最適なバッチサイズにするために 共有キューから何件取得すべきか予測するのは 非常に難しいと分かります
00:15:30そのため、キューに一部を戻せるような仕組みが必要になります。
00:15:35「少し取りすぎた」と気づいたときにです。
00:15:37少し取得しすぎたと気づいた場合ですね。
00:15:39そして、それはネットワークホップになります。
00:15:40つまりそれが課題となります。そこでローカルに複数のGPUを持つマシン向けに
00:15:46特別な最適化を行っています。1台のマシンの複数GPU上で動作するローカルプロセスが
00:15:59キューと多少調整をやり取りできるという利点を活かした、
00:16:03マシンローカルなキューイング要素を追加しています。
00:16:11ネットワーク経由だと数ミリ秒の余分なレイテンシが加わってしまうため、
00:16:16マルチGPUマシン上にワーカーを同居させる場合にのみこれを行います。
00:16:19ここで話しているのは5%程度の差ではありません。
00:16:22キューを集中化することで、クラスタの処理量が2倍になるのです。
00:16:25ですから非常に重要なポイントです。先ほど3つのランタイムについて触れました。
00:16:33基本的には、例えばエンコーダー専用モデルの場合、
00:16:38自分たちでPyTorchのコードを記述します。
00:16:39それを最適化し、自動探索ループでさらに調整します。
00:16:42Candleについても同様です。
00:16:45少し前からCandleを試し始めました。
00:16:47まだPyTorchの性能には遠く及びません。
00:16:54そのため、ややリサーチ段階のプロジェクトと言えます。
00:17:01単純に依存関係の問題で、PyTorchを含むワーカーのDockerイメージは約12GBあります。
00:17:08一方で、Candleを静的リンクしたワーカーバイナリはその10%程度です。
00:17:13コールド状態からの立ち上げや、多数のマシンへのイメージ読み込みを重視する場合、
00:17:1512GBから1GB程度に削減できるのは大きな違いを生みます。
00:17:20これがCandleを採用した動機ですが、
00:17:25PyTorchと同等の性能を出すのは非常に困難です。
00:17:34そしてSG-Langは、基本となる基準ラインとして使用しています。
00:17:37先ほど説明したパラメータの最適なチューニングを行えば、
00:17:43少なくともSG-Langと同等以上の性能を出す必要があります。
00:17:54ここにいくつかの数値データがあります。
00:17:57例えば、SG-LangをソケットおよびRustのサイドカーでラップすると、
00:18:00単体のSG-Langの性能を上回ることができます。
00:18:04これはネイティブのSG-Langが行わないバッチ処理側での工夫によるものです。
00:18:07もちろんSG-Lang自体にも同様の処理を実装することは可能でしょう。
00:18:11SG-Langにカスタムプラグインなどを開発して組み込めば、
00:18:16同じロジックをSG-Langのコアサーバーに組み込めるため、
00:18:22我々の性能に並ぶことができるはずです。
00:18:28しかしそれでは、SG-Langでしか動作しない専用コードを開発することになります。
00:18:32小型モデルから得られた教訓は、ランタイムが非常に多様であるということです。
00:18:36特定のランタイム1つに固執したくはありません。
00:18:47現在、多様なモデル用にパラメータ化したアダプターが約50種類あります。
00:18:53そのため、根底にあるこのような複雑さに対処する必要があります。
00:18:57特定のランタイム向けにプラグインを大量に作るのが正解ではないでしょう。
00:19:01何らかの抽象化が必要であり、それが我々の場合はRustのサイドカーという構想とソケットです。
00:19:05ここからは具体的な数値についてお話ししますが、ベンチマーク用語として
00:19:09「ニー（屈曲点）」という概念があります。サーバーへのトラフィックを増やし、
00:19:12スループット要求を高めていくと、
00:19:17それに伴ってスループットが直線的に伸びていく段階があります。
00:19:20しかしある時点で、要求を増やしてもそれ以上伸びなくなるポイントに達します。
00:19:23推移は平坦化し、レイテンシが悪化します。
00:19:32これを「ニー」と呼んでおり、飽和点を示すため
00:19:34これはRTX Pro 6000で測定した数値です
00:19:37レイテンシを損なわずに得られる最大性能のポイントと言えます。
00:19:46比較的控えめなハードウェアや各種小型モデルで
00:19:52どのような性能が可能か、一例をご紹介します。
00:19:56これはRTX Pro 6000で計測した結果です。
00:20:01主にNVIDIA L4、A100、RTX Pro 6000、H100などの
00:20:05ラインナップを使用して検証しています。
00:20:12OpenAI APIのテキスト埋め込みリクエストを送っていると想像してください。
00:20:171基のGPUで毎秒50万トークンを投入し、ベクトルを取得できるとしたらどうでしょう。
00:20:26そうですよね？
00:20:28イメージが湧いてきたでしょうか？
00:20:31それほど大規模でもない1基のGPUに毎秒50万トークンを投入し、
00:20:38検索システム用のベクトル埋め込みを得られるのです。管理されたエンドポイントに投入して何桁も高い費用を払うのとは大違いです。
00:20:49そうですよね？
00:20:50これらの呼び出しのレイテンシは、わずか数十ミリ秒ほどに抑えられます。
00:20:55CohereやOpenAIなどのAPIを使うと、数百ミリ秒はかかりますよね。
00:21:02これは決して難解な技術ではありません。
00:21:03数基のGPUと周辺インフラを整えるだけで、大幅なコスト削減と劇的なレイテンシ改善、比較的容易な運用が実現できます。
00:21:17オープンソースや小型モデルを始めるなら、埋め込みモデルはまさに絶好の第一歩です。
00:21:26しかし、可能性はそれにとどまりません。
00:21:27例えば、固有表現抽出（NER）を検討したいとしましょう。
00:21:33マルチベクトル検索や、テキスト・構造化出力などの生成処理も考えられます。
00:21:42タスク特化型の生成モデルなら、一番下のデータにある通り、1基のGPUで毎秒数千トークン、例えば毎秒500トークン以上の出力が得られます。
00:21:58合成データの生成や、ファインチューニングや評価のためのアノテーション生成を行うなら、管理されたエンドポイントは使わないでください。
00:22:11プロセスを自社でコントロールできるため、理想的なタスクです。
00:22:14品質の検証も自ら行えます。
00:22:16自社インフラ上のオープンソースモデルに最適な用途と言えます。
00:22:20GPU周辺のインフラが適切であれば、GPUの数に応じて線形にスケーリングします。
00:22:31小型モデルの提供に関するもう一つのアイデアは、通常のようにモデルごとにワーカープールを用意しないことです。
00:22:44ワーカーやノードのセットがあり、GPUを搭載して立ち上げ、モデルを事前ロードします。
00:22:51パラメータが数千億もあるモデルだと、読み込みに何十分もかかります。
00:22:55そして「やっとロードが終わった、これでワーカープールができた」と満足するわけです。
00:22:59この考え方は、小型モデルにはあまり適していません。
00:23:02はい、手短にいきます。
00:23:04残り時間はどれくらいですか？
00:23:066分超過しています。
00:23:07ああ、6分超過ですね。
00:23:08分かりました。
00:23:09了解です。
00:23:10同じGPUにモデルを詰め込む方が高速です。
00:23:12一部のモデルを固定しつつ、メモリ使用状況に応じて遅延ロードと破棄を行う仕組みについてのお話です。
00:23:26この2つをどう組み合わせるかを考える必要があります。
00:23:28自動研究（Auto-research）についても少し触れておきます。
00:23:32新しいモデルのサポート追加や性能向上のための自動研究ループを備えています。
00:23:39数値をさらに向上させるため、自動研究ループに給餌する計測用の社内ツールを多数構築しました。
00:23:47そして最も重要なのは、モデルのサポートを出荷する時点でチューニングが完了している点です。
00:23:53「これからパラメータ探索をしよう」とはなりません。
00:23:55クラスター全体のエンドツーエンド設定があらかじめ同梱されています。
00:24:00これが自動研究ループの構成です。
00:24:03ハーネスを構築してループを実行するメタループが存在します。
00:24:08さらに、動作状況を把握するためのダッシュボードも用意されています。
00:24:12そのための専用UIも構築しました。
00:24:15その成果の一つとして、わずか80セントで訓練したLoRAがあり、概念実証においてドイツ法律文書の検索精度を18%向上させました。
00:24:27以上になります。
00:24:29このように小型モデルは優れています。
00:24:30デプロイや提供も比較的容易です。
00:24:32実際にははるかに安価で高速です。
00:24:35スマートな選択と言えます。
00:24:36こちらのQRコードから、先ほどご紹介したクラスターのGitHubリポジトリにアクセスできます。
00:24:43ぜひスターをお願いします。
00:24:44セルフホスティングをお楽しみください。
00:24:45ありがとうございました。
00:24:46ありがとうございました。
00:24:47ありがとうございました。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video