Step 3.5 Flash – 高速推論を支援するオープンソースLLM

 (static.stepfun.com)
20 ポイント 投稿者 GN⁺ 2026-02-20 | 2件のコメント | WhatsAppで共有
  • 1960億パラメータのうち110億のみを有効化する疎なMixture of Experts構造により、高速推論とリアルタイムなインタラクションを支援
  • 毎秒最大350トークンの生成速度と256Kコンテキストウィンドウを実現
  • SWE-bench Verified 74.4% により、コーディング・エージェントベンチマークで安定した性能を示し、ローカル環境(Mac Studio M4 Max, NVIDIA DGX Spark) でも実行可能
  • ツール活用ベースの推論とマルチエージェントオーケストレーションを通じて、金融、データ分析、研究自動化など実務シナリオで高い信頼性と実行力を実証
  • 強化学習ベースのMIS-PO最適化手法により長期推論の安定性を確保し、高性能モデルと比べて低コストでフロンティア級の推論・行動能力を提供

モデル概要と性能

  • Step 3.5 Flashは高速推論とエージェント機能を組み合わせたオープンソースベースのfoundation modelで、平均ベンチマークスコア81.0を記録
    • GLM-4.7(78.5)、DeepSeek V3.2(77.3)、Kimi K2.5(80.5)など主要モデルより高い平均スコア
  • 疎なMoE構造により196Bのうち11Bパラメータのみを有効化し、効率的な計算でリアルタイム対応が可能
  • MTP-3ベースで通常利用時は100〜300 tok/s、コーディング作業時は最大350 tok/sの生成速度を達成
  • SWE-bench Verified 74.4%、Terminal-Bench 2.0 51.0% により、長期的なコード・エージェント作業で安定した性能を確保
  • 256Kコンテキストウィンドウを3:1 SWA構造で実装し、長い文脈でもコスト効率を維持

実際の活用事例とツール活用

  • ツールベース推論(tool-augmented reasoning) により、数学・コーディング・データ分析などで性能が向上
    • Python実行を統合した場合、AIME 2025(99.8)、HMMT 2025(98.0)、IMOAnswerBench(86.7)などで向上したスコアを記録
  • 株式投資シナリオでは80個以上のMCPツールを組み合わせ、データ収集・分析・通知の自動化を実行
  • Autonomous Business Intelligence EngineはCSV処理から予測までを自動化し、データ品質の差(1.6倍)を特定
  • Large-Scale Repository Architectは大規模コードベースを分析し、設計パターンと実装の詳細を結び付ける専門Wikiを生成

研究およびエージェント性能

  • ResearchRubricsベンチマークで65.3%を記録し、Gemini DeepResearch(63.7)、OpenAI DeepResearch(60.7)を上回るスコア
    • 単一のReActベースループで、計画・検索・検証・作成のプロセスを実行
  • Claude Code環境でデータ分析ベンチマーク39.6%を達成し、GPT-5.2(39.3)をわずかに上回る
  • Multi-Agent Frameworkを通じて、Master Agentが検索・検証・要約エージェントを調整し、構造化された結果を生成
  • Cloud-Device SynergyによりStep-GUIと連携した場合、AndroidDaily Hardベンチマークで57点(単独40点比)を記録

アーキテクチャと技術的特徴

  • Sparse MoEバックボーンにより、グローバル容量(196B)とトークンごとの計算量(11B)を分離し、推論コストと速度を最適化
  • Sliding-Window Attention + Full Attention(3:1) 構造により、長い文脈の処理でも効率を維持
  • Head-wise Gated Attentionにより情報の流れを動的に制御し、数値安定性を確保
  • NVIDIA Hopper GPU上で350 tok/sのデコードスループットを達成
  • INT4 GGUF量子化モデルにより、ローカル推論(20 tok/s, 256Kコンテキスト) を支援

強化学習フレームワーク

  • Metropolis Independence Sampling Filtered Policy Optimization(MIS-PO) を導入
    • 重要度サンプリングの代わりに二値フィルタリングで不安定なサンプルを除去
    • truncation-aware value bootstrappingとrouting confidence monitoringにより長期推論を安定化
  • この構造は、数学・コーディング・ツール活用全般において継続的な自己改善を可能にする

ベンチマーク比較

  • Step 3.5 FlashはReasoning、Coding、Agenticの3領域でバランスの取れた上位圏の性能を示す
    • AIME 2025: 97.3 / HMMT 2025: 98.4 / LiveCodeBench-V6: 86.4
    • τ²-Bench: 88.2 / BrowseComp-ZH: 66.9 / ResearchRubrics: 65.3
  • デコードコストは128Kコンテキスト基準で1.0xであり、DeepSeek V3.2(6.0x)、Kimi K2.5(18.9x)より効率的

制約と今後の方向性

  • トークン効率: Gemini 3.0 Proと比べて同等品質により長い生成が必要
  • 専門性の統合: 汎用性と専門性を効率よく組み合わせるためのon-policy distillation研究を進行中
  • エージェント型RLの拡張: 専門業務・研究レベルの複雑な作業へRL適用を拡大予定
  • 運用安定性: 長期対話やドメイン切り替え時に、反復推論や混合言語出力が生じる可能性あり

配布とアクセシビリティ

  • OpenClawプラットフォームと統合されており、簡単なインストールとモデル登録で利用可能
  • APIプラットフォーム(英語版/中国語版)、Web・モバイルアプリ(iOS/Android) から利用可能
  • Discordコミュニティを通じてアップデートとサポートを提供

関連記事

2件のコメント

 
sftblw 2026-02-20

このモデル、かなりいいですね。
環境が整っていて llama.cpp で回してみる方は、下のスレッドのコメントにあるプロンプトを別途適用する必要があります。そうしないと、開きの <think> がなく、途中に </think> だけがぽつんと出てくる問題があります。
https://huggingface.co/stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S/…

llama-server \  
  オプション省略 \  
  --jinja \  
  --chat-template-file パス/step3p5_flash_chat_template.jinja
 
GN⁺ 2026-02-20
Hacker News のコメント

  • ここ数か月で出た LLM の中でも、最も過小評価されているリリースの1つだと思う
    ローカルで 4-bit quant 版（Step-3.5-Flash-GGUF）を試したが、Minimax 2.5 や GLM-4.7 よりも優れていた（GLM は 2-bit しか使えなかった）
    主な特徴は次のとおり

    • コンテキスト効率が非常に高い。128GB の Mac で 256k コンテキスト全体、または 128k の2ストリームを同時に実行できる
    • M1 Ultra での速度も良好（36 t/s tg、300 t/s pp）で、コンテキストが大きくなっても速度低下が緩やか
    • agentic coding に最適化されており、Claude Code と互換性があるように訓練されているようだ。Codex だけはパッチ編集ツールの問題で例外
      200B パラメータ級モデルの中で、CLI ハーネス上で実際に使い物になる初のローカルモデルだ。pi.dev と一緒に使っているが、最高の体験だった
      欠点としては 無限推論ループのバグ がある（関連 issue）
      StepFun は ACEStep（音楽生成モデル）も作っている会社のようで、ComfyUI のドキュメントにも言及がある
    • Qwen3 Coder Next を OpenCode と一緒に試したが、かなりよく動いた
      たまにツール呼び出しを間違えるが、Qwen が提案した temperature=1 設定では停止しない
      Nemotron 3 Nano はツール利用が不十分で、ほとんど shell tool しか使わない傾向があった
      全体として agentic open weight モデル は、慣れていないツールをうまく呼び出せない傾向がある
    • M3 Ultra（512GB RAM）で OSS モデルを回すのが、Claude や Codex のサブスクより経済的なのか気になる
      こういう計算をした人がいるのか知りたい
    • 無限推論ループの問題が、推論エンジンの変更で解決できるのか気になる
      自分としては、モデルの重み自体を修正しないといけない問題に思える
    • MLX 版で動かした人がいるか知りたい。理論上はもっと速いはずだが、いろいろな版を落とすのはためらう
    • gpt-oss 120b や 20b も Codex と問題なく動いた

  • 最近「Walk or drive to the carwash」トリックの**推論過程（reasoning）**を興味深く読んだ
    関連リンク: gist, stepfun.ai の会話

  • Terminal-Bench 2.0 で 51.0% を取ったとのことだが、それが本当に「安定した長期タスク処理能力」を保証するのかは疑問

    • 51% という数字だけでは大きな意味はない。この種のベンチマークは絶対スコア基準なので、100% が人間レベルを意味するわけではない
      リーダーボードを見ると最高点は 75% なので、51% は SOTA の約 ⅔ の水準
    • そのスコアは Gemini 3 Flash と近いが、実際にはモデルよりも エージェント構成 のほうがスコアに与える影響が大きいようだ
    • TerminalBench は名前と違ってターミナルとはほとんど関係なく、実態としては ランダムなツール文法テスト に近い
      モデルが単にコマンドフラグを暗記しているだけかもしれない

  • 試してみたが、幻覚（hallucination） がひどかった。「ポケモンチャンピオンデッキを探して」のような簡単な質問でも不正確だった
    Opus 4.6、Deepseek、Kimi は予想どおりうまく動いた

    • 実運用には中規模モデルを使うほうがよいと思う
    • Gemini のようなモデルは 検索機能 を積極的に使うため、より速く正確だった可能性がある

  • 最近公開されたモデルで、Mixture of Experts（MoE） 構造を使い、1トークンあたり 196B のうち 11B だけを有効化する
    Kimi K2.5 や GLM 4.7 より多くのベンチマークで優勢
    128GB マシンでも 4-bit quant 版を実行可能（参考リンク）

    • ベンチマークでの優位が実際に意味を持つのかは疑問。自分は 指示追従、長文脈推論、非幻覚性 をより重視する
    • Q4_K_S（116GB）、IQ4_NL（112GB）、Q4_0（113GB）のどれがより良いのか気になる
      モデルページ 参照

  • 最近のモデルはベンチマークスコアは高いが、同時に トークン使用量の急増 を伴っている
    本当のブレークスルーには 電力効率 の問題を解決する必要がある

    • 単にトークン数だけでなく、トークンあたりのエネルギー効率（tokens/joule） も重要
      MoE 構造を効率的に使えるかどうかが、tokens/joule と tokens/sec の両方に影響する

  • SWE-bench Verified は悪くないが、もっと良い SWE ベンチマーク が必要
    公平なベンチマークを作るには継続的な実行コストが高くつく
    「ライブベンチマーク」という概念は良いが、最新モデルを十分に反映できていない

  • パラメータ数より tokens per dollar/sec のほうが重要な指標だと思う
    上位モデルはローカル推論をサポートしていないからだ

    • オープンソースモデルなら、セルフホスティング を考える人にとってはパラメータ数も重要
    • パラメータ数は依然として モデル性能のおおまかな指標 ではある
      たとえば Qwen3 0.6b は tok/dollar は優秀だが、大半の用途には不足する
    • このモデルは 3,000ドル未満のマシン でもローカル実行できる点に意味がある

  • 簡単なテストでいくつか観察した

    1. 出力トレースが非常に冗長で、LinkedIn スタイルのように段落が短かった
    2. ホスト版のトークン出力速度が非常に高かった
    3. 指示追従性と出力品質 が Opus 4.5 など主要モデルより優れていた

  • グラフの x軸が反転 していて混乱した

    • 自分も同感。なぜそうしたのかわからない
    • おそらくグラフをより良く見せたかったのだろうが、実際にはそうなっていない