StepFun Step 5 Previewのオープンウェイト、エージェントモデル競争をデプロイメントへ移す
StepFunは10月15日、Step 5 Previewのオープンウェイトを2つの主要形式で公開し、APIプレビューだったものを、開発者が検証・デプロイできるモデルへと移行させた。同社はHugging FaceとModelScopeでBF16およびFP8のチェックポイントを公開し、コードと詳細な技術ブログも併せて提供した。
この動きが重要なのは、Step 5 Previewが軽量なローカルモデルとして設計されていないためだ。総パラメータ数は約6000億、トークンあたりのアクティブパラメータ数は270億で、最大100万トークンのコンテキストウィンドウをサポートする。フルスケールでの実行には、データセンター向けハードウェア、分散推論、慎重なメモリ管理が必要になる。
そのため、このリリースは有益な緊張関係を生む。StepFunはモデルウェイトを利用可能にした一方、実用上の制御は依然としてインフラに制約される。本当の競争は、単にオープンウェイトとクローズドAPIの対決ではない。チームが検証可能なウェイトを、長時間のタスクを完遂する信頼性とコスト効率を備えたエージェントに変えられるかどうかだ。
これは、DeepSeek、Qwen、Kimiなど、同じエージェントワークロードを巡って競合する他のオープンウェイト開発者にも圧力をかける。また、vLLM、SGLang、量子化、コンテキスト管理、マルチノードサービングにとって、インフラチームに厳しい新たな試験を突きつけることにもなる。
StepFun Step 5 Previewのオープンウェイトがデプロイ可能に
10月のリリースにより、Step 5 Previewはホスト型サービスの約束から、要件を満たすチームが自らの管理下で実行できるモデルへ変わった。
StepFunは当初、このモデルをエージェント的な作業のためのフラッグシップシステムとして発表した。初期のAPI提供後にオープンウェイト版を公開すると約束していた。10月15日、同社はモデルファイルとデプロイ手順を公開してこの約束を果たした。
公式のFP8 checkpointは、この規模のモデルをサービングする際のメモリ負荷を軽減することを目的としている。FP8は多くのモデル値を8ビット浮動小数点精度で保存し、BF16と比べてメモリ使用量を削減する一方、整数量子化より広い数値範囲を維持する。
StepFunは別途、BF16 checkpointも公開した。BF16は16ビット浮動小数点値を用い、一般に評価、適応、数値比較においてより保守的な基準を提供する。
これらのファイルはModelScope releaseからも入手でき、開発者に別の配布経路を提供する。これは特に、すでにModelScopeに依存したインフラやダウンロードワークフローを持つチームにとって重要だ。
2つのチェックポイントの違いは見た目のものではなく、運用上のものだ。StepFunは、BF16のランタイムオプションを設定してもFP8ウェイトがBF16に変換されるわけではないと警告している。チームは、提供する予定の精度に対応するチェックポイントをダウンロードしなければならない。
モデルカードには、vLLM、SGLang、スタンドアロンのTransformers実装向けの手順が含まれる。vLLMとSGLangはいずれも、OpenAI互換のインターフェースを通じてモデルを公開できる。そのため、既存アプリケーションはまったく新しいリクエスト形式を採用せずに接続できる。
それでも、デプロイには相当なエンジニアリングが必要となる。StepFunのリファレンス構成では、FP8チェックポイントをNvidia B300 GPU 4基、またはH200 GPU 8基に配置する。BF16構成では、B300 GPU 8基、またはH200 GPU 16基を搭載した2ノードを使用する。
これらの例は開始時の構成を示すものであり、すべてのワークロードに対する容量を保証するものではない。100万トークンのリクエストには、キー・バリューキャッシュ、ランタイムバッファ、同時実行シーケンスのためのメモリも必要だ。ウェイトはシステム全体のフットプリントの一部にすぎない。
BF16のドキュメントには、もう1つ重要な留保がある。StepFunによると、ファイルシャード化された完全なBF16変換および生成パスは、エンドツーエンドでの完全な検証をまだ受けていない。同社は、チェックポイントの形状、小規模な変換テスト、フルモデルのストリーミングウェイト推論を検証したとしている。
この注記は、リリースの信頼性を下げるどころか、むしろ高める。オープンなデプロイメントでは、マネージドAPIが隠し得る未完成のツールやスケーリング上の限界が露わになる。また、外部のエンジニアが障害を再現し、修正を提案することも可能になる。
したがって、このリリースは摩擦がないわけではないものの、意義深い。開発者は現在、モデルアーティファクト、サービング例、アーキテクチャの説明を手にしている。残る課題は、それらを利用できる運用環境を構築することだ。
StepFunがより狭く、より深いエージェントモデルを構築した理由
StepFunの中心的な賭けは、長時間でツールを多用するエージェントセッションでは、アクティブパラメータ数の多さよりも深い内部計算のほうが重要だという点にある。
Step 5 Previewは、スパースなmixture-of-expertsアーキテクチャを採用する。この設計では、ネットワークは多くの専門化されたパラメータ群を保持するが、ルーターが各トークンに対してその一部だけを有効化する。
モデルは総計約6000億のパラメータを持ち、トークンあたり270億のパラメータがアクティブになる。スパース活性化は、ネットワーク全体を各ステップに適用することなく、幅広い能力を維持することを目指す。ただし、完全なモデルを保持するためのストレージや通信の負荷をなくすわけではない。
StepFunはこのモデルを「narrow but deep」と表現する。92のTransformerブロックを備え、入力と出力の間により多くの逐次処理段階を配置している。同社は、深さが長いプロンプト処理における潜在的な多段階推論を助けると主張する。
この設計は、ソフトウェアエージェントの扱いにくい特性を標的にしている。コーディングエージェントは、ファイルを繰り返し読み、ツールの結果を受け取り、コードを編集し、テストを実行し、計画を更新する。その推論の多くは、可視化された推論テキストだけでなく、蓄積されたコンテキストを処理する間に行われなければならない。
より深いネットワークは、表現が発展するための層をより多く与える。しかし、深さは最適化も難しくする。StepFunは、モデルのスケールアップ中に数値の発散や勾配スパイクが発生したと報告している。
同社のtechnical architectureでは、3つの対応策を説明している。隠れ状態とその勾配をFP32で維持し、正規化スケールをFP32で保存し、きめ細かな勾配クランプを導入した。
StepFunによれば、FP32の隠れ状態により極端な活性化ピークはほぼ1桁低減された。同社は、この変更による学習オーバーヘッドは、従来のBF16処理と比べてわずかだったとしている。
正規化の変更は、BF16精度が不十分になり得る負の1付近の値に対処した。StepFunは、一部のチャネルが完全に抑制された状態と再び開かれた状態を交互に繰り返し、不安定な出力挙動を生んでいることを発見した。
勾配クランプは、層ごとの勾配値のうち0.00004パーセントだけを対象とした。StepFunによれば、これらのまれな値は中間層をまたいで増幅され、スパイクを生む可能性があった。それらをクリッピングすると、より滑らかな収束が得られたと報告している。
これらは同社が報告した学習時の観察であり、独立した再現結果ではない。それでも、その記載はこのブログを単なるベンチマーク発表より有用なものにしている。研究者は、これらの手法を他の深いモデルで観測される挙動と比較できる。
アテンション設計は、アーキテクチャ上の主張のもう半分を担う。Step 5 Previewは、3つの効率的なアテンション層ごとに1つのスパースなフルアテンション層を挿入する。効率的な層はゲート付きスライディングウィンドウアテンションを用い、各トークンが参照する直近領域を制限する。
フルアテンション経路には、StepFunがSparse GQAと呼ぶ方式を使用する。Grouped-query attention、すなわちGQAでは、複数のクエリヘッドがキーおよびバリュー表現を共有する。StepFunは、完全なシーケンスを読み込む代わりに、関連する履歴ブロックを取得する選択機構を加えた。
インデクサーはトークンを8個単位のブロックにまとめる。モデルは4,096トークンの予算、すなわち512ブロックに相当する量を選択する。StepFunによれば、ブロック統合によってインデックス作成と上位選択のコストは8分の1に削減される。
この機構は具体的な問題に対応する。標準的なフルアテンションは、トークンが拡大し続ける履歴と比較するため、シーケンスが長くなるほどコストが増大する。このコストは100万トークンでは困難なものになる。
スパース選択は、各演算で参照する履歴を減らす。しかし、どの選択器も後で重要だと判明する情報を見落とす可能性がある。StepFunは、選択した構成でのトークンカバレッジが78.06パーセントであり、より細かな参照構成の79.09パーセントと比較した結果を報告している。
この小さな報告上の差は設計を支持するが、アプリケーション品質を決着させるものではない。リポジトリ構造、ノイズの多いツール出力、数十万トークン離れた詳細情報は、異なる検索失敗を露呈させる可能性がある。
このアーキテクチャは、トレードオフを伴う効率化の仕組みとして捉えるのが最善だ。極端に長いコンテキストをより実現可能にする一方で、その判断を検証する必要がある別のコンポーネントを生み出す。
オープンウェイトと実際のエージェントインフラのコストが交わる
StepFunはモデルの検証・変更に対する障壁を下げたが、ハードウェア要件により、日常的なセルフホスティングは大半の個人開発者の手が届かないままである。
オープンウェイトは、APIにはない能力を提供する。チームは構成ファイルを検査し、サービングログを制御し、プロンプトの処理場所を選び、機密データを外部に送ることなくモデルの挙動をテストできる。
研究者は、異なるデコーディング設定の下で同じチェックポイントを評価できる。インフラエンジニアはカーネルを変更し、並列化を試し、新しい量子化を構築できる。規制対象の組織は、制御された環境内に推論を配置できる。
これらの利点は、エージェントシステムにとって重要だ。エージェントは機密性の高い資料に触れるためである。コーディングエージェントは、非公開リポジトリやデプロイメント構成を読み取る場合がある。ビジネスエージェントは、契約書、社内レポート、顧客記録、財務モデルを処理する可能性がある。
セルフホスティングは、こうしたワークフローに対してより強い運用上の制御をもたらす。ただし、それだけで安全になるわけではない。組織には依然として、アクセスルール、監査証跡、ツールの制限、プロンプトインジェクションへの防御、意図しない行為を監視する仕組みが必要だ。
最初の制約はメモリである。StepFunのリファレンスパスでは、FP8推論をB300 GPU 4基またはH200 GPU 8基に分散する。BF16では、その要件はB300 GPU 8基、または2ノードにまたがるH200 GPU 16基へと拡大する。
テンソル並列化は、モデル計算を複数のデバイスに分割する。エキスパート並列化は、mixture-of-expertsのコンポーネントを分散する。データ並列化は追加のリクエストスループットを支援できるが、サービングワークロードの異なる部分を複製または再分配する。
どの手法にも通信コストが伴う。性能は、インターコネクト帯域幅、集団通信、カーネルサポート、バッチ処理、そして有効化されるエキスパートの正確なパターンに左右される。起動コマンドが動作しても、効率的な本番サービスが保証されるわけではない。
コンテキストウィンドウも別の制約を生む。StepFunはサービング例で、入力と出力を合わせた上限を1,048,576トークンとしている。実際に利用可能な長さは、キー・バリューキャッシュに確保するメモリに依存する。
キー・バリューキャッシュは、それまでのトークンのアテンション情報を保存し、モデルが新しいトークンごとにシーケンス全体を再計算しなくて済むようにする。極端に長いコンテキストでは、このキャッシュが大きなメモリ消費要因になる。
チームは、コンテキスト長、同時実行数、レイテンシ、出力容量の間で選択しなければならない。非常に長いセッションを1件提供すると、多数の小規模リクエストを押し出す可能性がある。同時実行数を増やすと、最大シーケンス長を短くするか、より積極的なキャッシュ圧縮が必要になる場合がある。
StepFunは、MTP-3予測ヘッドによってエンドツーエンドの速度が約30パーセント向上するとしている。Multi-token prediction、すなわちMTPは、システムが複数のあり得る将来トークンを下書きし、それらをまとめて検証できるようにする。
同社はまた、BF16と同等の品質を維持しつつ、ネイティブFP8のMixture-of-Experts実行によってさらに約20%の性能向上を得られると報告している。これらの主張は、ハードウェア、プロンプト、同時実行レベル、エージェントフレームワークをまたいで外部から再現される必要がある。
StepFunはさらに、協調型エキスパート並列処理、CPUキャッシュへのオフロード、圧縮重みストレージ、FP8キャッシュトレーニングにより、有効キャッシュ容量が8倍から12倍に拡張されるとしている。この幅は、単一の単純なモデル設定ではなく、システムスタック全体を反映したものだ。
したがって実際の競争相手は、特定の1社ではない。重みが利用可能であることと、実運用可能なエージェント基盤との間にある隔たりだ。StepFunは第1層を開放した一方で、第2層の解決は導入者に委ねている。
この隔たりは、マネージドプロバイダーに競争余地を与える。クローズドAPIは即時利用、予測可能な統合、運用の外部委託を提供する。オープンウェイトのシステムは制御性、カスタマイズ性、ローカルデータ処理を提供するが、より大きな資本とエンジニアリング努力を必要とする。
大企業と推論プロバイダーは、最も早く自前ホスティングへ移行する可能性が高い。小規模チームは、モデルカードを検討し、コミュニティによる圧縮版を待ちながら、引き続きホステッドエンドポイントを利用できる。
このリリースは、開発者に調達判断のためのより明確な枠組みも与える。モデル品質とサービング経済性を分け、それぞれを自らのワークロードに照らして測定できる。ベンチマークスコアが高くても、許容できないレイテンシやインフラコストを補うことはできない。
ベンチマークの主張には依然として独立検証が必要
Step 5 Previewのリリースは本格的な評価を可能にするが、企業が選定したベンチマークだけでは本番環境での信頼性を確立できない。
StepFunはこのモデルを、ソフトウェアエンジニアリング、長期的な実行、専門知識業務、金融分野向けに位置付けている。これらは、会話の流暢さよりも1件の完了タスクが重要となり得る、高価値なエージェントワークロードと一致する。
同社によれば、Step 5 Previewはコード生成、バグ修正、リファクタリング、ドキュメント作成、パフォーマンス最適化で強い性能を示すという。モデル概要では、持続的なエージェント動作を示すことを意図した長時間実行例も提示している。
オープンなチェックポイントにより、これらの主張は検証可能になる。独立グループは固定ハーネスを実行し、トランスクリプトを保存し、デコーディング設定を比較し、失敗事例を公開できる。このプロセスは、マネージドなチャットインターフェースのスクリーンショットを比較するよりも有益だ。
ただし、ベンチマークの再現性を確保することは依然として難しい場合がある。エージェントのスコアは、利用可能なツール、プロンプトテンプレート、再試行ポリシー、時間制限、コンテキスト圧縮を含む、モデルを取り巻く足場に依存する。
モデルは、ベンチマーク固有のデータや評価器の弱点から利益を得る可能性もある。StepFunは、エージェントが意図された問題を解かずにタスク仕様を悪用するモデルハッキングについて率直に論じている。同社のデータパイプラインには、ハッキング防止チェックが含まれていると報告されている。
この認識は正しい問題を捉えているが、そのチェックが十分であることの証明にはならない。外部評価者は、成功した実行が狭いテストを通過するだけでなく、正確で保守可能な出力を生み出しているかを検証すべきだ。
長期的な評価では、さらに疑問が生じる。エージェントは単独のリポジトリタスクを完了できても、数時間にわたる作業では軌道を逸する可能性がある。行動を繰り返したり、正しい変更を上書きしたり、ツールの結果を誤読したり、コンテキスト圧縮後に前提を失ったりするかもしれない。
StepFunの強化学習システムは、継続時間、深度、識別性に焦点を当てている。継続時間は持続的な作業を測定し、深度は蓄積された状態変化を扱う。識別性は、タスクが成功したロールアウトと失敗したロールアウトを区別できるかを測定する。
同社は、ソフトウェアエンジニアリング、科学的推論、機械学習研究、専門業務にまたがる、挑戦的かつ検証可能な環境を100万件以上作成したとしている。この数値は構築された環境を示すものであり、固有の本番導入数ではない。
StepFunはまた、エンドツーエンドのロールアウトにおけるサンプルドロップ率が1%未満だと報告している。インフラ障害は最も長く困難な軌跡を除外し、学習をより容易なタスクへと静かに偏らせることが多いため、サンプル損失は重要だ。
これらの詳細は、StepFunがエージェント学習をシステム上の問題として扱ったことを示唆する。しかし、証拠は依然としてモデル開発者自身によるものだ。独立チームは、明示されたハードウェア、フレームワークのバージョン、評価予算のもとで結果を再現すべきである。
ライセンスについても同様の精査が必要だ。Hugging Faceはリポジトリのライセンスを「other」と表示している一方、StepFunはModel License 1.0をApache-2.0スタイルと呼んでいる。このライセンスには、モデルの利用、改変、配布に関する帰属表示および商用条件が追加されている。
このため、「オープンウェイト」という表現が正確だ。それは、標準的なオープンソースソフトウェアライセンスに関連付けられるものと同じ、無制限の権限がすべての利用に付与されることを意味しない。
組織は、派生物を配布する前、商用サービスを提供する前、あるいはモデルを顧客向け製品に組み込む前に、完全なライセンスを読むべきだ。重みへのアクセスと法的な許可は関連しているが、同一ではない。
セキュリティテストも同様に重要である。長時間稼働するエージェントは、より多くのファイルにアクセスし、より多くのツール呼び出しを行い、エラーの機会をより多く蓄積できる。持続性の向上は、有用性と誤った判断による潜在的影響の両方を増大させる。
したがって、モデルは段階的に評価すべきだ。チームは読み取り専用タスク、管理されたリポジトリ、合成レコードから開始できる。その後、権限違反、復旧動作、ツールの誤用、根拠なく導入された変更を測定できる。
開発者はFP8とBF16の出力も比較すべきだ。StepFunはネイティブFP8がBF16と同等の品質を実現するとしているが、小さな差異は長い軌跡の中で増幅し得る。1つのツール選択の変更が、その後のすべてのステップを別の方向へ導く可能性がある。
オープンリリースは、こうした実験を可能にする。ただし、答えが最初から好ましいものになるわけではない。
次の3つのシグナルがStep 5 Previewの影響を決める
このリリースが重要なものになるのは、独立した結果、より広範なサービング対応、持続的な実世界での採用が重みの公開に続く場合に限られる。
第1のシグナルは、再現可能なエージェント評価だ。独立研究者は、完全な実行ログとともに、コーディング、文書分析、金融、長文脈検索でStep 5 Previewをテストすべきである。
最も有益な比較では、エージェントの足場を一定に保つ。モデルには同一のツール、予算、プロンプト、再試行上限を与えるべきだ。評価者は、ハードウェア、精度、フレームワークのバージョン、コンテキスト設定を開示すべきである。
強力な独立結果は、狭く深いアーキテクチャが長期的な作業を支援するというStepFunの中核的主張を裏付けるだろう。企業の設定外で大きく性能が低下すれば、その主張は弱まり、足場による優位性へと注目が移る。
第2のシグナルは、インフラの成熟度だ。StepFunはすでにvLLM、SGLang、スタンドアロンTransformers向けの起動手段を提供している。次の試金石は、それらの経路がより簡単に、より高速に、よりポータブルになるかどうかだ。
チームは、安定したアップストリーム対応、追加のGPU構成、最適化カーネル、独立して保守される量子化版に注目すべきだ。また、BF16のファイルシャーディングワークフローが完全な検証を受けるかも確認すべきである。
成熟したデプロイメントスタックは、ダウンロード可能な重みと利用可能なサービスの距離を縮める。セットアップの失敗が続けば、このモデルは少数の専門オペレーターに集中したままとなる。
第3のシグナルは、実際のエージェント製品における採用だ。リポジトリのスター数やモデルのダウンロード数は関心を示すかもしれないが、ユーザーが重要な作業をモデルに委ねているかは示さない。
意味のある採用は、本番統合、反復利用、公開事例、測定可能なタスク完了を通じて現れる。また、レイテンシ、障害復旧、インフラ利用率に関する詳細な報告も生み出すだろう。
ここで競合他社は最も明確な圧力に直面する。DeepSeek、Qwen、Kimi、その他のオープンウェイト開発者は、フロンティア水準のエージェント性能を犠牲にせず制御を求める開発者を巡って競争している。
StepFunのリリースは、その対象者に評価すべき新たな本格的アーキテクチャを与える。同時に、技術情報開示への期待も高める。サービング手順、精度バリアント、アーキテクチャの詳細、再現可能な評価ガイダンスがなければ、チェックポイントは今や不完全に見える。
クローズドモデルのプロバイダーは、異なる試練に直面する。信頼性、安全システム、エコシステム統合、マネージドインフラによって、依然として優位に立てる。APIの利便性が、オープンウェイトによる制御性と検査可能性を上回る理由を示さなければならない。
開発者にとって当面の行動は、全面移行ではなく規律あるテストだ。代表的なタスクを選び、その完全な作業コンテキストを保存し、成功率、レイテンシ、介入頻度を比較する。
長時間のエージェント評価では、大量のログ、意思決定、ソース資料が生成される。検索可能なAIナレッジベースは、結果を最終スコア1つに還元せず、チームがその証拠を保持する助けとなる。
したがって、StepFun Step 5 Previewのオープンウェイトリリースは出発点である。ファイルは、同社がアクセスを提供するかどうかという点を決着させる。しかし、そのアーキテクチャが独立した条件下で勝つかどうかまでは決着させない。
今後数カ月は、誰が結果を再現できるか、誰がモデルを効率的に運用できるか、そして初期テスト後も誰が使い続けるかを注視したい。これらのシグナルが、Step 5 Previewがインフラになるのか、それとも印象的なチェックポイントのままなのかを明らかにする。
