ステップ3.5 フラッシュ – オープンソースの基盤モデル、高速で深い推論をサポート

96日前原文(static.stepfun.com)

概要

Step 3.5 Flash は、最先端のオープンソースAIモデルとして高い推論力と効率性を実現
Mixture of Experts（MoE）構造 でパラメータ数を抑えつつ高密度な知能を発揮
コーディング・エージェント用途 に特化し、長文コンテキストも効率的に処理
ツール連携・自律的なワークフロー管理 で実用的な業務自動化を実現
他の主要モデル（GLM-4.7, DeepSeek, Kimi, Gemini, Claude, GPT-5.2）と比較しても高得点

Step 3.5 Flashの特徴と性能

総パラメータ数196B で、実際に活性化するのは 11Bパラメータ/トークン のMoEアーキテクチャ
推論・コーディング・エージェントタスク で高いスコアを記録
- 推論：97.3（PaCoRe時99.9）
- コーディング：74.4
- SWE-bench Verified：74.4%
- Terminal-Bench 2.0：51.0%
3-way Multi-Token Prediction（MTP-3） により、 100～300トークン/秒 の生成速度を実現
256Kコンテキストウィンドウ をサポートし、 3:1 Sliding Window Attention（SWA） で計算コストを抑制
ローカル展開可能、Mac Studio M4 MaxやNVIDIA DGX Spark等の高性能コンシューマー機器で動作

他モデルとの比較

GLM-4.7 （355B）、 DeepSeek V3.2 （671B）、 Kimi K2.5 （1T）などの大規模モデルと同等以上のスコア
Gemini 3.0 Pro、 Claude Opus 4.5、 GPT-5.2 xhigh といったプロプライエタリモデルとも競合
平均スコア （8ベンチマーク平均）：Step 3.5 Flash（81.0）、GLM-4.7（78.5）、DeepSeek V3.2（77.3）、Kimi K2.5（80.5）、Gemini 3.0 Pro（80.7）、Claude Opus 4.5（80.6）、GPT-5.2 xhigh（82.2）

実用事例とツール連携

ツール連携能力 が特徴で、80以上のMCPツールを統合し株式投資分析を自動化
- 市場データ集約、テクニカル指標計算、カスタムメトリクス生成、クラウド連携による通知・保存を一括管理
Pythonコード実行 をChain-of-Thought推論に統合し、AIME 2025（99.8）、HMMT 2025 Nov.（98.0）等の論理・数学系ベンチマークで高得点
Tactical Weather Intelligence Dashboard ：WebGL 2.0によるリアルタイム3D気象可視化
Three.js Procedural Ocean Engine ：高精度CGレンダリング、PBR・フラクタル波形・レイトレーシング
Agentic Workflow Take In ：日常データ処理業務の自動化、ワークフロー生成・検証・変換・レポート出力
Epic Solar System Simulation ：3Dインタラクティブな太陽系シミュレーション
Autonomous Business Intelligence Engine ：CSV解析から多シナリオ予測、エラー訂正、データ可視化まで一貫処理
Autonomous Large-Scale Repository Architect ：大規模コードベースの依存関係解析・Wiki自動生成
Beyond Vibe Coding ：Claude Code等の先進エージェントフレームワークでの自律的問題解決力

Step 3.5 Flashの実用的知能密度

ベンチマーク性能だけでなく、実運用での堅牢性と信頼性 を重視
ツール連携（Tool-use） が静的モデルを動的エージェントへ進化させる鍵
Think-and-Actシナジー により、コマンド実行に留まらず、意図整合性と適応的推論を実現
大規模ツールセットでも高精度なオーケストレーション とクロスドメイン対応力を発揮

まとめ

Step 3.5 Flash は、 高密度知能・高速推論・長文対応・ツール連携・ローカル展開 を兼ね備えた、次世代オープンソースAIモデル
多様な実用シナリオ での高度な自律性と安定性を実証
他の大規模・プロプライエタリモデルと比較しても競争力のあるパフォーマンス

Hackerたちの意見

最近、新しいモデルが数週間前にリリースされたよ。「Mixture of Experts (MoE)アーキテクチャで、トークンごとに196Bのパラメータのうち11Bだけを選択的にアクティブにする」んだって。Kimi K2.5やGLM 4.7よりも多くのベンチマークで勝ってる。負けてるのは少数派だね。追記：128GBのマシン、例えばGB10 [1]、AI Max+ 395、またはMac Studioで動かせる4ビットの量子化もあるよ。[1] https://forums.developer.nvidia.com/t/running-step-3-5-flash...

└

Kimi K2.5やGLM 4.7よりも多くのベンチマークで勝ってる。これって本当に意味あるの？例えば、俺はエージェントタスクに特化した特定のベンチマークは無視する傾向があるんだよね。だって、それは俺の使い方じゃないから。指示に従うこと、長い文脈の推論、ハルシネーションがないことの方が、俺には重要なんだ。

└

Q4_K_S @ 116 GB、IQ4_NL @ 112 GB、Q4_0 @ 113 GB これらの中で技術的にどれが一番いいの？

すごくハルシネートするから、使うときは注意が必要だよ。シンプルな「Xポケモンのチャンピオンデッキを探して」や「Yデッキはどう機能するの？」ってテストしてみたけど、Opus 4.6、Deepseek、Kimiは期待通りに良いパフォーマンスだった。

└

後者のモデルがSearchを使ってる可能性はあるかな？ Stepfunが完璧だとは言わないけど（全然そうじゃないし）。特にGeminiは驚くほど多くSearchを使ってて、めちゃくちゃ速いよ。

└

知識よりも実行のために中くらいのサイズのモデルを使うかな。

効率にもっと焦点が当たるのはいいね。最近の新モデルのリリースは、特定のベンチマークで大きなジャンプを伴ってるけど、掘り下げてみると、ほぼいつもその結果を出すためにトークンの使用量が大幅に増えてる（あ、Google Deep Thinkのことね）。AIが本当に変革的になるためには、電力の問題を解決する必要がある。

└

トークンの使用量だけじゃなくて、高コストのトークン使用についてもね。トークン/ジュールの観点では、すべてのトークンが同じわけじゃないから。MoEアーキテクチャを効率的に使うことは、トークン/ジュールやトークン/秒に影響を与えるよ。

SWE-bench Verifiedはいいけど、もっと良いSWEベンチマークが必要だね。公平なベンチマークを作るのは大変だし、継続的に運営するにはお金もたくさんかかる。最近のモデルで十分に動いてる「ライブ」ベンチマークはあまりないから、どのモデルが勝ってるのかの良いイメージを得るのは難しい。ライブベンチマークのアイデアは素晴らしい！毎日、数千のGitHubの問題がPRで解決されてるよ。

└

ターミナルベンチ 3.0を手伝って！ https://docs.google.com/document/d/1pe_gEbhVDgORtYsQv4Dyml8u...

パラメータの数は、俺的にはあまり関係ない指標だと思う。トップモデルはローカル推論をサポートしてないし、もっと重要なのはドルあたりのトークン数や秒あたりのトークン数だよ。

└

オープンソースモデルだから、セルフホストしたい人には関係あるでしょ。

└

だって、$3k以下のマシンでこのモデルをローカルで動かせるから。

└

パラメータの数はモデルの能力の指標にはなるよね。Qwen3 0.6bを使えば、驚くほどのトークン/ドルやトークン/秒を達成できる。ただ、ほとんどのユースケースにはあまり向いてないけど。

ターミナルベンチ 2.0で51.0%、洗練された長期タスクを揺るぎない安定性で処理できることを証明。ターミナルベンチについては何も知らないけど、51%のスコアが洗練された長期タスクでの「揺るぎない安定性」を保証するとは思えないな。

└

そのスコアはジェミニ 3 フラッシュと同等だけど、結果をスクロールしてみると、スコアはモデルよりも使ったエージェントにかなり影響されてるみたい。

└

51%だけじゃあまり意味がないよね。こういうベンチマークは通常、カーブで評価されないし、100%が資格のある人間のパフォーマンスレベルになるようにキャリブレーションされてない。超人のベンチマークを設計すれば、10%が人間のパフォーマンスレベルになることもある。https://www.tbench.ai/leaderboard/terminal-bench/2.0を見たら、現在の最高スコアは75%で、51%は⅔ SOTAってことになるね。

└

TerminalBenchって名前が最悪だよね。ターミナルとはほとんど関係ないし、ランダムなツールの構文に過ぎない。モデルがランダムなツールのコマンドラインフラグを覚えてても、大半のタスクにはあまり役に立たないし。

このモデルをしばらく使ってるけど、すごく速いよ。考える時間はちょっとかかるけど、呼び出し回数は少ない。例えば、昨日エージェントにAPIのジェミニのクォータ制限を調べてもらったら、27秒で2回の呼び出しで済んだ。オーパス 4.6は33秒かかったけど、5回の呼び出しで考える時間も少なかった。

これはここ数ヶ月で最も過小評価されているLLMの一つかも。4ビット量子化でローカルテストした結果（https://huggingface.co/ubergarm/Step-3.5-Flash-GGUF/tree/mai...）、Minimax 2.5やGLM-4.7を含む他のすべてのLLMを上回った。ただし、GLMは2ビット量子化でしか動かせなかった。いくつかのハイライト：

コンテキスト効率が非常に良い：デフォルトでSWA、128GのMacで256kコンテキスト全体か、2つの128kコンテキストストリームを実行できる。
Macでの速度も良好。M1 Ultraでは36 t/s tgと300 t/s ppを記録。コンテキストが増えても速度が徐々にしか低下しない：100kのプレフィルでは20 t/s tgと129 t/s pp。
エージェントコーディング用にトレーニングされてる。クラウドコードと互換性があるようにトレーニングされてると思うけど、Codex以外の他のCLIハーネスでも問題なく動く（Codexはパッチ編集ツールが混乱させるから）。これはCLIハーネスで使える200Bパラメータ範囲の最初のローカルLLMだと思う。pi.devでたくさん使ってて、エージェントコーディングをするローカルLLMとしては最高の体験だった。ただ、いくつかの欠点もある：
非常に長い推論チェーンを生成することがある。
現在のリリースには、時々無限推論ループに入るバグがある： https://github.com/ggml-org/llama.cpp/pull/19283#issuecommen... これらの問題に対処する新しいリリースがStepFunから出るといいな。ちなみに、StepFunはACEStep（非常に良い音楽生成モデル）をリリースした会社みたい。少なくとも、StepFunはComfyUIのドキュメントに言及されてるよ。 https://docs.comfy.org/tutorials/audio/ace-step/ace-step-v1

└

このモデルのMLXバージョン試してみた？理論的にはちょっと速く動くはずなんだけど、複数のバージョンをダウンロードするのにはちょっと躊躇しちゃうな。

└

gpt-oss 120bや20bでもCodexと一緒にうまく動くよ。

└

推論エンジンの変更が無限ループの問題をどう解決するのか、ちょっと気になるな。素人の理解だけど、モデルの重み自体を修正しないといけないんじゃないかな？

└

Qwen3 Coder Next試してみた？ OpenCodeでテストしてみたけど、ハーネスと結構うまく動いてるよ。たまにツールの使い方を間違えることもあるけど、Qwenの提案した温度=1だと、引っかかることはないみたい。作業にかける時間もまあまあだし。Nemotron 3 NanoをOpenCodeで試したこともあるけど、なんか動くには動いたけど、ツールの使い方が全然ダメで、ほとんどシェルツールに頼りっぱなしだった。例えば、ファイルを編集するのにツールを使うんじゃなくて、シェルツールを使ってsedを実行するだけ。これが、限られたテストで気づいたエージェント型オープンウェイトモデルの主な問題だね。認識してないツールを呼ぶのにためらうみたいで、明示的に指示しないと使わない感じ。

└

M3 Ultraを512GBのRAMで買ってOSSモデルを使う方が、ClaudeやCodexにお金を払うよりも、来年か2年の間に安くなると思う？こういう計算した人いる？

いくつかの標準テストプロンプトを使った簡単なテストでの観察結果: 1) トレースがすごく冗長で、チャットやイライラする一文ずつの段落のLinkedIn投稿みたいな変なスタイルだった；2) ホスティング版のトークン出力率がすごく高かった；3) 指示に対する準拠と出力の質は、私が試した中での主要なモデル（例えばOpus 4.5）よりも良かった。

最近の「車洗いに歩いて行くか運転するか」ってトリックの理由を読むのが楽しかった！リンクはこれだよ: https://stepfun.ai/chats/213451451786883072

ハクソク