Amazon SageMaker AIとAmazon BedrockでvLLMを使用して数十のファインチューニングモデルを効率的に提供

Amazon SageMaker AI および Amazon Bedrock で vLLM を用いて、数十のファインチューニング済みモデルを効率的に提供 複数のカスタム AI モデル、特に最近の Mixture of Experts (MoE) モデルファミリーを実行している組織や個人は、個々のモデルが専用コンピューティングエンドポイントの容量を飽和させるのに十分なトラフィックを受けない場合に、アイドル状態の GPU 容量に対して支払いを行うという課題に直面することがあります。この問題を解決するため、私たちは vLLM コミュニティと連携し、GPT-OSS や Qwen などの人気のあるオープンソース MoE モデルに対する Multi-LoRA (Multi-Low-Rank Adaptation) 提供のための効率的なソリューションを開発しました。Multi-LoRA はモデルをファインチューニングするための一般的なアプローチです。モデルの重み全体を再トレーニングするのではなく、Multi-LoRA では元の重みを凍結したまま、モデルの層に小さく学習可能なアダプターを注入します。Multi-LoRA を用いると、推論時には複数のカスタムモデルが同じ GPU を共有し、リクエストごとにアダプターのみを入れ替えるだけで済みます。例えば、5 人の顧客それぞれが専用 GPU の 10% しか利用していない場合でも、Multi-LoRA を用いれば単一の GPU から提供でき、5 つの未活用 GPU を 1 つの効率的に共有される GPU に変換できます。 本記事では、vLLM における Mixture of Experts (MoE) モデル向けの Multi-LoRA 推論の実装方法について説明し、私たちが行ったカーネルレベルの最適化を紹介するとともに、この取り組みから得られるメリットをご紹介します。本記事全体を通じて、GPT-OSS 20B を主要な例として使用します。 これらの改善点は、バージョン 0.15.0 以降のローカル vLLM デプロイメントですぐに利用可能です。マルチ LoRA サービングは now、GPT-OSS、Qwen3-MoE、DeepSeek、Llama MoE を含む MoE モデルファミリーで動作します。また、私たちの最適化は、Llama3.3 70B や Qwen3 32B などの密型モデルに対するマルチ LoRA ホスティングの改善にも寄与しています。Amazon 固有の最適化により、vLLM 0.15.0 と比較して追加的なレイテンシ改善が実現され、例えば GPT-OSS 20B では、Output Tokens Per Second (OTPS)（モデルが出力を生成する速度）が 19%向上し、Time To First Token (TTFT)（モデルの出力生成開始までにかかる待ち時間）が 8%短縮されます。これらの最適化を活用するには、LoRA カスタマイズ済みモデルを Amazon SageMaker AI または Amazon Bedrock でホストしてください。 vLLM における MoE モデル向けのマルチ LoRA 推論の実装 vLLM における MoE モデル向けのマルチ LoRA 推論の初期実装について詳しく掘り下げる前に、最適化の根拠を理解するために重要な MoE モデルと LoRA ファインチューニングに関する背景情報を提供します。MoE モデルには、エキスパートと呼ばれる複数の専門化されたニューラルネットワークが含まれています。ルーターが各入力トークンを最も関連性の高いエキスパートに割り当て、その出力をその後集約します。このスパースアーキテクチャでは、1 トークンあたりにモデルの全パラメータの一部のみが活性化されるため、計算リソースを抑えながら大規模なモデルを処理できます。詳細な可視化については、以下の図 1 を参照してください。 各エキスパートは、トークンの隠れ状態を2段階で処理する小さなフィードフォワードネットワークです。まず、gate_up ![](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/02/23/image-1-4.png) 図 1: MoE-LoRA モデルの動作を、隠れ状態次元 4096、中間表現次元 11008、LoRA ランク r = 32 の例を用いて示したものです。 各エキスパートには 2 つの重み射影があります: gate_up この実装を vLLM に統合することで、H200 GPU 上で GPT-OSS 20B を用いたマルチ LoRA サービングが可能となり、詩ベースのベンチマークである Sonnet データセットにおいて、入力長 1600、出力長 600、同時実行数 16 の条件下で、26 OTPS と 1053 ms の TTFT を達成しました。これらの結果を再現するには、vLLM GitHub リポジトリのリリース 0.11.1.rc3 にある PR をご確認ください。本ブログの後半では、これらのベースライン有効化数値からパフォーマンスをどのように最適化したかを示します。 vLLM におけるマルチ LoRA 推論性能の向上 初期実装を確定した後、NVIDIA Nsight Systems (Nsys) を用いてボトルネックを特定したところ、fused_moe_lora が問題であることが判明しました。 実行最適化 初期の実装では、マルチ LoRA の TTFT はベースモデルの TTFT（すなわち GPT-OSS 20B の公開リリース版）よりも 10 倍高く（悪く）ありました。プロファイリングの結果、Triton コンパイラが入力長に依存する変数をコンパイル時の定数として扱ってしまい、fused_moe_lora cuModuleLoadData do_not_specialize Figure 2: Fused_moe_lora のプロファイリング結果 プロファイリングにより、fused_moe_lora についても明らかになりました。 シャープとエクスパンドカーネルは直列で実行されるため、初期の実装では 2 つのカーネル実行間にバブル（アイドル時間）が発生していました。カーネル実行をオーバーラップさせるために、Programmatic Dependent Launch (PDL) を実装しました。PDL を用いることで、依存するカーネルはメインのカーネルが完了する前に起動を開始でき、シャープカーネルが実行されている間にエクスパンドカーネルが重みを共有メモリと L2 キャッシュにプリフェッチできます。シャープカーネルが完了した時点で、エクスパンドカーネルはすでに重みを読み込んでおり、即座に計算を開始できます。 また、LoRA に対する CudaGraph を用いたスペキュレティブ・ディコーディング（推論）のサポートを追加し、ベースモデルとアダプターで異なる CudaGraph がキャプチャされてしまう vLLM の問題を修正しました。CudaGraph は GPU 演算シーケンスをキャプチャして GPU カーネルのオーバーヘッドを削減するために使用されるため、効率性に重要です（例：カーネルを単一ユニットとして扱う）。その結果、CPU オーバーヘッドとこれらのカーネル起動遅延を低減できます。当社の実行最適化により、OTP は推論なしで 50/100 から推論ありでも 50/100 に改善され、GPT-OSS 20B のデフォルト設定における TTFT（Time To First Token）は 150 ms に改善されました。本ブログの残りの部分では、スペキュレティブ・ディコーディングを有効にした状態での数値を報告します。 カーネル最適化 Split-K は、細い行列の負荷分散を改善するためのワーク分解戦略です。LoRA shrink では xA を計算します。 GPU スケジューラーは、複数のスレッドグループを同じ出力要素に割り当て、異なる出力要素のスレッドグループを同時に実行します。lora_shrink の場合も同様です。 また、shrink および expand LoRA カーネルから不要なマスク処理とドット積演算を削除しました。Triton カーネルは固定サイズのブロックでデータをロードしますが、行列の次元がこれらのブロックサイズに均等に割り切れない場合があります。例えば、BLOCK_SIZE_K が... 最後に、LoRA 重みの加算をベースモデルの重みとの結合を LoRA expand カーネルに統合しました。この最適化により、カーネル起動オーバーヘッドを削減できます。これらのカーネル最適化により、GPT-OSS 20B で 144 OTPS および 135 ms の TTFT を達成できました。 Amazon SageMaker AI および Amazon Bedrock 向けのカーネル設定のチューニング Triton カーネルでは、ブロックサイズ（BLOCK_SIZE_M など）などのパラメータの調整が必要です。 デフォルト構成が標準的な融合 MoE に最適化されている MoE LoRA カーネルは、マルチ LoRA サービングにおいて性能が低いことが判明しました。これらのデフォルト設定には、LoRA インデックスに対応する追加グリッド次元や、複数のアダプターによる複合スパース性が考慮されていません。このボトルネックに対処するため、ユーザーがカスタムチューニング済み構成をフォルダパスの提供によりロードできるようにサポートを追加しました。詳細については、vLLM LoRA Tuning ドキュメントをご覧ください。私たちは 4 つの fused_moe_lora をチューニングしました。 結果と結論 vLLM コミュニティとの協力により、GPT-OSS、Qwen3 MoE、DeepSeek、Llama MoE などの MoE モデルに対するマルチ LoRA サービングを実装し、オープンソース化しました。その後、最適化を適用した結果、vLLM 0.15.0 における GPT-OSS 20B の OTPS（秒間出力トークン数）は vLLM 0.11.1rc3 と比較して 454% 向上し、TTFT（初回トークンまでの時間）は 87% 短縮されました。一部の最適化、特にカーネルチューニングや CTA スウィッシングは、Qwen3 32B の OTPS が 99% 改善されるなど、密結合モデルのパフォーマンスも向上させました。これらの成果をローカル環境でのデプロイメントで活用するには、vLLM 0.15.0 以降を使用してください。Amazon Bedrock および Amazon SageMaker AI で利用可能な Amazon 固有の最適化により、GPT-OSS 20B の場合、vLLM 0.15.0 と比較して OTPS が 19% 高速化され、TTFT が 8% 改善されるなど、モデル全体にわたって追加のレイテンシ削減を実現しています。Amazon 上でのカスタムモデルホスティングを開始するには、Amazon SageMaker AI のホスティングおよび Amazon Bedrock のドキュメントをご覧ください。 ![](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/02/24/gpt-oss20b-1.png) 図 3: GPT-OSS 20B のマルチ LoRA 推論における秒間出力トークン数（OTPS）および初回トークンまでの時間（TTFT）：1/vLLM 0.11.1rc3 での初期実装、2/vLLM 0.15.0 使用時、3/vLLM 0.15.0 に AWS カスタムカーネルチューニングを追加した場合。実験では、LoRA ランク 32 および並列ロードされた 8 個のアダプターを使用し、入力トークン数は 1600、出力トークン数は 600 としました。 謝辞 vLLM コミュニティの貢献者および協力者の皆様、Jee Li 氏、Chen Wu 氏、Varun Sundar Rabindranath 氏、Simon Mo 氏、Robert Shaw 氏ならびに、当チームメンバーの Xin Yang 氏、Sadaf Fardeen 氏、Ashish Khetan 氏、George Karypis 氏に対し、心より感謝申し上げます。 著者について

Amazon SageMaker AIとAmazon BedrockでvLLMを使用して数十のファインチューニングモデルを効率的に提供

背景や根拠まで確認しますか？

調べる

選ぶ

サイト