Reflection AIがオープンウェイトモデル「Beam」を発表、総パラメータ数は5010億

Reflection AIは、エージェント型コーディング(agentic coding)や長期的なタスク向けのオープンウェイト(open-weight)モデル「Beam」を発表しました。このモデルは、コードの保守、ツールの利用、結果の解釈、複数ステップのワークフローの完了といった用途に対応しています。Beamのオープンウェイト公開により、開発者や研究者は、ランタイム、デプロイ環境、カスタマイズのプロセスを制御できます。

Reflectionのミッションは、オープンなモデルのウェイト(weights)、公開された研究、オープンソースソフトウェアを通じて、インテリジェンスをオープンにし、すべての人が利用できるようにすることです。ReflectionのAIスタック全体は、モデル、コアソフトウェア、本番インフラ、アプリケーションに及びます。Beamは、ソフトウェアエンジニアリングやエージェント型システムを構築する開発者にこのアプローチをもたらします。

Beamのモデル構成とチェックポイント形式

Beamは、ソフトウェアの問題の解決、コードの修正、ツールの呼び出し、中間結果に基づく行動のためのスパースMixture-of-Expertsモデルです。総パラメータ数は5010億、アクティブパラメータ数は230億で、Reflectionは有効コンテキスト長を100万トークンと報告しています。

Beamのデプロイ方法は、制御とスケーリングの要件に合わせて選びます。Beam 1.0は、数値精度の異なるBF16、FP8、NVFP4のチェックポイント形式で提供されています。AWSマネージドのJumpStartコンテナ構成でモデルをデプロイすることもできますし、AWS環境でSGLangまたはvLLMを使ってモデルを調べたりカスタマイズしたりすることも可能です。

Reflection AIが発表したオープンウェイトモデルのBeamは、総パラメータ数が5010億であり、マルチGPUでのデプロイが必要になります。この5010億という総パラメータ数は、チェックポイント(checkpoint)のストレージ、ウェイトのメモリ、シャーディング、並列化のあり方を左右します。一方、アクティブパラメータ数は230億であり、これはトークンごとの計算量に影響します。

BF16はウェイトのメモリ要件が最も大きいため、ウェイトとランタイムオーバーヘッドに十分な合計GPUメモリを持つマルチノード構成を計画します。BeamをFP8チェックポイントで動かす場合は、NVIDIA H100 GPUを搭載する`ml.p5.48xlarge`、またはH200 GPUを搭載する`ml.p5e.48xlarge`と`ml.p5en.48xlarge`を使います。モデルをNVFP4で動かす場合は、NVIDIA B200 GPUを搭載する`ml.p6-b200.48xlarge`を使います。

Reflection Beamのデプロイメントにおけるサイズ見積もりでは、チェックポイントのストレージ、ウェイトのメモリ、KVキャッシュ(KV cache)、コンテキスト長、バッチ処理、ランタイムのオーバーヘッド、およびサポートされる並列化を考慮する必要があります。デプロイメントのサイズ見積もりでは、1レプリカ分のウェイト・KVキャッシュ・ランタイムのオーバーヘッドのメモリを計算し、その見積もりは負荷テストで確認します。また、デプロイ時にはイメージ転送、ウェイトのダウンロード、シャードのロード、およびランタイム初期化にかかる時間を見込む必要があります。Path 1のデプロイメントサンプルは、バリアント対応の1つのコマンドでBF16、FP8、NVFP4のモデルIDをサポートします。サポートされるインスタンスタイプ、リクエストスキーマ、デプロイコマンド、およびクリーンアップコマンドの正は、サンプルのREADMEとPythonファイルです。

Beamへのアクセスは、Amazon SageMaker JumpStart、またはHugging Face上のBeam 1.0のチェックポイントリポジトリのいずれかを通じて得る必要があります。利用にあたっては、モデル利用規約への同意、AWS Command Line Interface(AWS CLI)、およびPython 3.11以降が必要です。デプロイには、サポートされているBeamの構成に対応したGPUのクォータとキャパシティが必要であり、リリース済みのチェックポイント、ランタイム、並列レイアウトが、選択したインスタンスタイプをサポートしているかを確認する必要があります。また、必要なアクセラレーテッドインスタンスをサポートするAWSリージョンを選ぶ必要があります。サービスクォータと利用可能なキャパシティを確認し、可能であればオンデマンドキャパシティを使用するか、スケジュールされた作業にはSageMakerトレーニングプランを短期リザベーションとして使うことができます。前提条件として、選択したSageMakerのデプロイ方法と、それを支えるAWS Identity and Access Management(IAM)、ネットワーク、ストレージのリソースに対する権限を持つAWSアカウントが必要です。

AWSでのデプロイ経路と事前準備、手順

Reflection AIが発表したエージェント型コーディング向けのオープンウェイトモデルであるBeamをAWSにデプロイする方法には、いくつかの経路があります。フルマネージドな方法としては、Amazon SageMaker JumpStartのJumpStartリアルタイムエンドポイント(real-time endpoint)から始めることができます。Kubernetesを運用せずに、AWSマネージドのモデルパッケージ、エンドポイント、呼び出しAPIを使いたい場合は、このJumpStartリアルタイムエンドポイントを使用します。モデルカタログから管理されたHTTPSエンドポイントまで最短で進みたい場合は、まずAmazon SageMaker JumpStartリアルタイムエンドポイントを使うPath 1を利用します。

JumpStartリアルタイムエンドポイントの方法は、モデル、コンテナ、エンドポイントをマネージドなデプロイワークフローにまとめます。一方、HyperPod Inferenceの方法は、クラスターとサービングランタイムを公開するため、分散実行、キャッシュ、ルーティング、スケーリングを制御できます。HyperPod Inferenceでは、開発や実験にはHugging Face Hubからバージョンを固定したBeamのリビジョンをデプロイし、本番デプロイとモデルキャッシュにはチェックポイントをAmazon S3またはAmazon FSxにコピーします。また、HyperPod Inferenceは、マネージドの階層型KVキャッシュ(tiered KV caching)とインテリジェントルーティングもサポートしており、これらは2026年に導入されたAmazon SageMaker Inferenceの機能に含まれます。HyperPod Inferenceでは、ウェイトをノードローカルの、高速SSD向けの規格であるNVMeのストレージにプリロードし、サービングイメージを事前にプルできるモデルキャッシュとイメージキャッシュを利用できます。HyperPod Inference Gatewayは、OpenAI互換のインターフェースを提供し、リクエストをレプリカ間でルーティングします。

分散GPUインフラに対してKubernetesネイティブな制御が必要な場合は、Amazon SageMaker HyperPod Inferenceを使用します。Amazon Elastic Kubernetes Service(Amazon EKS)でオーケストレーションされるAmazon SageMaker HyperPodクラスター上で、AWSマネージドのコンテナとモデル構成を使いたい場合は、HyperPod Inference上のJumpStartを利用します。HyperPodの方法では、BeamはAmazon SageMaker JumpStart、Hugging Face Hub、またはオプションのAmazon Simple Storage Service(Amazon S3)ミラーから取得できます。分散ワーカーは、AWSマネージドのJumpStartコンテナか、カスタムのSGLangまたはvLLMランタイムを使用します。サービングイメージ、ランタイム引数、量子化、分散実行を制御する必要がある場合は、HyperPod Inference上でSGLangまたはvLLMを使います。

Reflection Beamは、提供開始時点で、US East (N. Virginia)とUS East (Ohio)のAmazon SageMaker JumpStartで利用できる。継続的な課金を避けるため、テストが終わったらリソースを削除してください。

カスタムランタイムを使う場合は、BF16、FP8、NVFP4のいずれかのチェックポイントを選びます。一方、Path 1（Amazon SageMaker JumpStartのリアルタイムエンドポイント）の手順は、サンプルリポジトリのクローン、SageMaker JumpStartデプロイメントサンプルディレクトリへの移動、Python仮想環境の作成と有効化、サンプルの依存関係のインストール、そしてFP8向けの範囲を限定したデプロイ・呼び出し・クリーンアップのライフサイクル実行です。この最後の手順のコマンドを使用すると、FP8エンドポイントをデプロイして短いリクエストを送り、レスポンスを出力し、エンドポイントをクリーンアップします。別のチェックポイントバリアントを選択するには`bf16`または`nvfp4`を指定しますが、`--variant`を省略した場合はNVFP4がデフォルトとなります。エンドポイントを稼働させ続けたい場合には、READMEのPython関数を使用します。HyperPod Inferenceでデプロイ成果物を準備する際は、HyperPod Inferenceのデプロイメントサンプルに記録されているAmazon SageMaker JumpStartのモデルリリースを使います。

Reflectionは、BeamのウェイトをApache 2.0ライセンスでHugging Face経由で公開しています。Beam 1.0には、BF16、FP8、NVFP4のチェックポイントバリアントがあります。これらの形式は、メモリフットプリントとハードウェア互換性が異なります。

Reflection Beamのデプロイ成果物を準備する際は、デプロイ結果と性能結果を再現できるように不変な入力を使います。トークン、生成されたシークレット、非公開のモデルID、レジストリの認証情報、および未公開の結果は、リポジトリに入れないでください。

Amazon SageMaker HyperPod Inferenceのデプロイメントサンプルでは、リリース済みマニフェスト、モデルとイメージの識別子、サポートされるランタイムバージョン、コマンドの正はサンプルのREADMEとその設定ファイルです。HyperPod Inferenceを使う前に、HyperPod Inference Operatorと必要なアドオンを備えた、EKSオーケストレーションのHyperPodクラスターへの`kubectl`アクセスを設定する必要があります。また、Amazon SageMaker HyperPodでモデルキャッシュが有効な場合、Inference Operatorは対象ノードを選択したウェイトとサービングイメージで事前にウォームします。実行時には、Inference GatewayとEndpoint Pickerが各リクエストを、JumpStartマネージド、SGLang、vLLMのいずれかの適切なレプリカに振り分けることができます。あわせて、クラスターの仮想プライベートクラウド(VPC)、サブネット、セキュリティグループ、選択したBeamとランタイムの成果物へのアクセスが必要で、モデルキャッシュを有効にする場合はローカルのNVMe容量も必要です。選択したリポジトリが認証を求める場合は、分離したHugging Faceのアクセストークンを使います。

コードでインフラを管理するワークフローでは、Amazon SageMaker HyperPodのサンプルにあるリリース済みのJumpStart設定を使います。デプロイ設定の前に、reflection-beam-jumpstart.yamlのマニフェストテンプレートを確認できます。手順4(JumpStart設定のデプロイ)で使うヘルパーは、リリース済みの`JumpStartModel`リソースを生成して適用し、値を埋め込んだリリース値はディスクに書き出しません。カスタムランタイムを使う場合は、公開されているBeamの、コミットを識別するSHA値とイメージダイジェストを、サンプルのリリース設定に保持します。クラスターがアップストリームのイメージをプルできない場合、または組織が承認済みレジストリを要求する場合に限って、リリースされたイメージをプライベートなAmazon Elastic Container Registry(Amazon ECR)リポジトリにミラーリングします。

提供経路の選択、デプロイ手順、性能の測定

HyperPod Inferenceでの提供経路の選択では、ワークロードが特定の推論ランタイムや設定を必要としない限り、Amazon SageMaker JumpStartから始めます。Amazon SageMaker JumpStartは、AWSが管理するコンテナとモデル設定を使い、ランタイムの保守を減らしたい場合に利用します。Amazon SageMaker JumpStartを使う場合、利用者が管理するのは、Beamのモデルバージョン、サポートされるインスタンスタイプ、エンドポイント設定、スケーリングポリシーの選択です。Amazon SageMaker JumpStartはコンテナ統合の作業を減らしますが、Amazon SageMaker HyperPodはクラスターのキャパシティ、スケーリング、およびオブザーバビリティの制御を保持します。SGLangまたはvLLMは、カスタムのランタイム引数、パーサー、量子化、並列化など、特定の推論ランタイムや設定が必要な場合に使います。この場合、利用者は、サポートされるランタイムイメージ、モデルリビジョン、パーサー設定、分散実行の設定を固定(pin)します。

コードでインフラを管理する方法でJumpStart設定をデプロイする場合、サンプルリポジトリをクローンしてHyperPod Beamディレクトリに入り、READMEに記載のローカル設定ファイルを作成します。その後、クラスターを変更する前にJumpStart設定を検証し、JumpStart設定をデプロイします。SageMaker StudioからHyperPod上にJumpStartでBeamをデプロイした後は、リリースされたJumpStartのリクエストスキーマでエンドポイントを呼び出す前に、デプロイのステータスを確認します。SGLangまたはvLLMでのデプロイでは、Beamをデプロイしてデプロイが終了状態になるまで待つコマンドの`sglang`を`vllm`に置き換えると、vLLMを使えます。このヘルパーは選んだ設定を検証し、レンダリングしたマニフェストをリリース値をディスクに書き出さずに適用し、固定のタイムアウトで待機し、デプロイが失敗した場合は診断情報を出力します。Amazon SageMaker StudioからAmazon SageMaker HyperPod上でBeamをデプロイする手順は、JumpStartモデルカタログを開き、All public modelsの中からBeamを選びます。次に、デプロイ先としてAmazon SageMaker HyperPodを選び、クラスターとKubernetesの名前空間を選択します。最後に、エンドポイント名を入力してDeployを選びます。JumpStartのエンドポイントを呼び出すときは、リリース済みのモデルのリクエストスキーマを使います。SGLangまたはvLLMの場合は、Amazon SageMaker HyperPod Inferenceのデプロイメントサンプルに含まれる、範囲を限定したスモークテストを使います。

想定する同時実行数とレイテンシ目標を定め、そのうえで、計測したワークロードの挙動に基づいてレプリカ、キャッシュ、ルーティング、オートスケーリングを設定します。SGLangまたはvLLMでデプロイしたエンドポイントを呼び出す手順は、サンプルのクライアント依存パッケージをインストールし、推奨される開始時のサンプリング設定で、プライベートなヘルスチェックと短いリクエストを実行することです。vLLMでデプロイした場合は、ヘルスチェックと短いリクエストを実行するコマンドの `sglang` を `vllm` に置き換えます。認証付きのInference Gatewayを使う場合は、HyperPod InferenceのデプロイメントサンプルのREADMEにあるベアラートークン(bearer-token)の手順を使います。性能の測定では、各サービング経路を、想定する同時実行数で、代表的なコーディングとツール利用のリクエストを繰り返して試験します。性能試験では、Beamのモデルバージョン、イメージダイジェスト、インスタンスタイプ、数値精度、コンテキスト長、並列化、サービング引数、キャッシュ状態、試験の繰り返し回数を記録します。リクエスト成功率、最初のトークンが出るまでの時間(time to first token)の中央値(p50)と95パーセンタイル(p95)、出力トークン1つあたりの時間(time per output token)、エンドツーエンドのレイテンシ、集計した1秒あたりの出力トークン数を測定し、それらの測定結果をもとに、バッチサイズ、KVキャッシュの割り当て、レプリカ数、オートスケーリング、モデルとイメージのキャッシュを調整します。数値精度または量子化を変更した後は、出力の品質を再確認します。認証情報は、ソースコード、マニフェスト、コマンド履歴に残さないでください。

テスト後のリソースのクリーンアップ

Amazon SageMaker JumpStartのリアルタイムエンドポイントをクリーンアップするには、Amazon SageMaker JumpStartのデプロイメントサンプルのREADMEにあるクリーンアップ手順に従います。Amazon SageMaker HyperPod Inference上のJumpStart、SGLang、またはvLLMをクリーンアップするには、HyperPod InferenceのデプロイメントサンプルのサンプルのREADMEにあるクリーンアップ手順に従ってください。

このウォークスルー用に専用で作成したHyperPodクラスターまたはAmazon EKSクラスターは削除してください。使っていないキャッシュ済みのウェイト、ミラーしたアーティファクト、ロードバランサー、ロググループ、一時的なIAMロール、および取得した推論データも削除する必要があります。

サービングコンテナを管理せずにKubernetesネイティブなインフラ制御が必要なときは、JumpStartと組み合わせてAmazon SageMaker HyperPod Inferenceを使います。カスタムランタイムが必要なときは、SGLangまたはvLLMを選択できます。デプロイの際は、Amazon SageMaker JumpStartのデプロイメントサンプルまたはHyperPod Inferenceのデプロイメントサンプルを使い、その手順に従います。Reflection Beamは、エージェント型コーディングとマルチステップのタスク向けに設計されたオープンウェイトモデルです。