Recursive Flint v1.0：その大半を自身の研究ループで構築した40Bコーディングモデル

最も興味深い一文はRecursive Flint v1.0のリリースの中で、ベンチマークスコアではない。それは、Eureka Machineと呼ばれる自動研究システムがほぼすべての段階に貢献する中で、小規模チームが4か月足らずで400億パラメータのコーディングモデルをゼロから構築したとRecursiveが述べている箇所だ。Flintは、強力なローカルコーディングモデルとして公開されている——合計398億パラメータ、トークンあたり約25億がアクティブ、Apache 2.0、ラップトップでも無理なく動く。しかしこのリリースは、別の命題の最初の公開テストでもある。モデルを構築するプロセス自体を大部分自動化できるという命題だ。どちらの読み方も発表に含まれている。あなたが再現できるのは、そのうちの一方だけだ。

Flintは2026年10月21日にApache 2.0で公開され、重みはHugging Face上でRecursiveSI/flintとして提供された。これは、元SalesforceチーフサイエンティストのRichard Socherが設立したラボRecursiveの最初のモデルであり、登場したのは4日前だ——制作したラボの外ではほとんど何も検証されていないほど最近のことである。

Recursiveが実際にリリースしたもの

4つのリポジトリであり、1つではありません。メインのチェックポイントリポジトリにはBF16の重み、設定、トークナイザー、チャットテンプレート、SGLang配信キットが含まれており、2026年10月21日14:20 UTCに作成されました。その隣には3つの量子化ビルドがあり、いずれも同じ日の午後に作成されたものです。int4 safetensorsビルド、int4 GGUF、NVFP4 GGUFです。以下のサイズは発表によるものではなく、各リポジトリ自身のファイル一覧から取得したものです。

• BF16リファレンス — 37ファイルで合計79.59 GB。H200またはB300をお持ちで、希釈されていないモデルを求めている場合に使うファイルです。

• NVFP4 GGUF — 22.86 GB。これは「ラップトップで動く」という主張を文字どおり実現するビルドであり、ほとんどの人が実際にダウンロードするのはこれだ。

• int4 GGUF — 25.99 GB。名目上は同程度のビット幅にもかかわらず、NVFP4 ファイルより大きくなっています。ディスク容量だけを基準にこの2つから選ぶなら、NVFP4 に軍配が上がります。

• int4 safetensors — 22.58 GB、GGUF ではなく safetensors チェックポイントを必要とするサービングスタック向け。

Recursiveは、自社の低ビット学習と4ビット出力ヘッドを16ビットモデルへ向けて蒸留し直すことで、フル精度から0.7ポイント以内に収まると主張している。その数字はRecursive自身のもので、Recursiveの評価で測定されたものだ。ファイルサイズはそうではない——誰でもリポジトリから読み取れる。

4つの数値と、それぞれが測定しているもの

Recursiveは今回のリリースに合わせて一連のスコアを公開したが、それらについて理解すべき最重要点は、すべてがRecursive自身のハーネス内で生成されたものだということだ。第三者が再実行したものは一つもない。Artificial Analysisのインデックス――この種のモデルにとって通常の独立した審判役――には、Flintのエントリーが一切存在しない。

• SWE-bench Verified — 74.2%。多くの読者が認識するベンチマークで、モデルが実際のGitHub issueを解決できるかどうかを測る。Recursiveはこれを、インターネットアクセスを一切使わずにmini-swe-agent経由で実行し、少なくとも5回の試行にわたるpass@1を、temperature 1.0、top-p 0.95、top-k 20で平均した。

• SWE-bench Pro v2 — 89.7%。「v2」に注意してください。これは他のラボが公開している SWE-bench Pro と同じベンチマークではなく、この2つの数値を互いに差し引くことはできません。この区別は見た目以上に重要で、Flint が通常の SWE-bench Pro を報告するモデルと比較されるたびに、この問題は繰り返し発生します。

• Terminal-Bench 2.1 — 54.9%。ここでRecursiveは、異例なほど誠実で、異例なほど不格好なことをした。インターネットを有効にした状態でTerminus 2を実行し、その後、ウェブ検索によって得られた解答はすべて失敗として数えたのだ。このハンデは意図的なものであり、同時に、このスコアが、そのルールなしで算出されたTerminal-Benchの数値とは直接比較できないことも意味している。

• LiveCodeBench v6 — 80.3%。競技プログラミング向けのベンチマークであり、エージェント型ではないため、4つの中でハーネスの選択に対する感度が最も低い。

• IFBench — 89.2%。指示追従性は、小型モデルが通常最初に後退する分野です。

Recursiveが実際に示している主張は、その対象範囲が示唆するよりも狭い。Flintは、SWE-bench Pro v2、Terminal-Bench 2.1、SWE-bench Verifiedにおいて、総パラメータ数500億未満のMixture-of-Expertsモデルの中で首位だ。これは特定のモデルクラスに関する主張であり、絶対的な主張ではない。同程度の規模のDenseモデルは、構造上この主張から除外されている。まさにそのため、DenseモデルであるQwen3.8 27Bが同じグラフに登場し、Recursive自身の6テスト平均でより高いスコアを記録している。Recursiveはそれを公表した。公表したことには評価が値する。

Eureka Machineの主張は、モデルよりも長く残る部分です。

ベンチマークを取り除くと、より異例な話が残る。Recursiveは、自社の自動研究システムがアイデアを生成し、実験を実行し、その結果を使って次にどの実験を行うかを選んだと述べている。同社は、事前学習、事後学習、推論、量子化、ハードウェアカーネルにわたる貢献をそれに帰している。それらの貢献のうち3つは、アーティファクトと照合できるほど具体的である：

• {{1}}モデルの形状{{/1}}。設計は{{2}}35B-A3Bベースライン{{/2}}から始まり、{{3}}総パラメータ40B・アクティブ2.5B{{/3}}に落ち着いた。これは同じアクティベーションコストで総容量を増やす意図的な移行であり、推論にとって重要な意味で大きくなるのではなく、より疎になるということだ。

• 量子化。出力ヘッドを4ビット化し、16ビットモデルから自己蒸留して戻すことが、0.7ポイントという主張の裏にある手法であり、39.8Bモデルが22.86 GBの配布可能なビルドを持つ理由でもある。

• カーネル。RecursiveはM4およびM5チップ向けのMetalメガカーネルを書いた。スループットに関する主張を踏まえると、これはリストの中で最も意外性の低い項目であり、最も具体的な項目でもある。

Recursiveが明らかにしなかったのは、Eureka Machineが研究者の時間をどれだけ節約したかだ。この省略こそが論点のすべてだ。システムがモデル開発の大部分を自動化したという主張は、代替手段にどれだけのコストがかかったかを知って初めて意味を持つ——そして同社自身の説明はここで慎重だ。プロセスは完全に自律的ではなく、人間の監督下に置かれたままだ。この発表は、再帰的自己改善の証明としてではなく、初期の公開デモンストレーションとして読むべきだ。

4日間の実機テストで分かることと分からないこと

これまでFlintを最も本格的に外部から検証したのは『Wired』のウィル・ナイトで、48GBメモリのMacで動かし、ToDoアプリ、ウェブ調査ツール、小さな解説サイトを構築した。3つとも動作した。これは実際の成果であり、ベンチマークではない。3つのタスク、1台のマシン、1人によるものだ。

実際にこれを使う予定がある人にとってより有用な指標は、セッション開始時ではなく長時間にわたってスループットを測定したレビュアーから得られる。ある独立テストでは、短いプロンプトでは毎秒約110トークンだったものが、約115,000トークンのコンテキストでは毎秒約9トークンまで低下したと報告されている。これは5倍以上の劣化であり、エージェントが何かを書き込む前に大規模なリポジトリを読む場合に計画の基準とすべき数値だ。Recursiveの見出しとなる速度値——M4 Proで毎秒125トークン以上、64 GB RTX Sparkで150以上——は、明示的に短いコンテキストで測定されたもので、プリフィルは除外されている。

llama.cpp の GGUF パスには、チャットテンプレートに関する既知のバグもあります。量子化ビルドを読み込んで、モデルがまるで話が通じなくなったかのように振る舞う場合は、重みのせいにする前にテンプレートを確認してください。

本番経路をそれに賭けずに実行する

Flintはダウンロードであって、エンドポイントではありません。OrcaRouterはそれを提供しておらず、本記事のいかなる箇所も、当社が提供していると述べていると解釈すべきではありません。

それが変えるのは、試し方です。公開から4日しか経っていないオープンウェイトモデルを誠実に評価する方法は、すでに信頼しているモデルの隣で動かし、自分のリポジトリで比較することであり、入れ替えてうまくいくことを期待することではありません。すでに単一のAPI経由でホスト型モデルを呼び出しているなら、低リスクな形は、その経路をフォールバックとして残したまま、Flintに任せてもよいタスクをFlintに処理させ、本番環境で停滞に気づくのではなく、フェイルオーバーチェーンで、ローカルモデルが停滞するリクエストを拾わせることです。これはルーティングの判断であり、忠誠心の判断ではありません。

ダウンロード前に知っておくべきもう一つのこと：Flintは無料で実行できるが、無料で所有できるわけではない。22.86 GBのダウンロードが入場券であり、それを快適に扱えるマシンこそが本当のコストだ。トークン単位のホスト型モデルと比較して価格を考えるなら、ハードウェアの費用も見積もっておこう。

今後1か月の注目ポイント

Flintが優れた小型コーディングモデルとして記憶されるのか、それともより長い議論における最初のデータ点として記憶されるのかは、3つの事柄によって決まる。

一つ目は独立したベンチマーク実行です。Artificial Analysis または同等の中立当事者がそれを採点するまで、Flint を含むあらゆる比較は、あるラボの自己測定と別のラボの自己測定の比較にすぎません。二つ目は、長文脈スループットの問題が llama.cpp のアーティファクトなのか、エンジンの問題なのか、モデル自体の特性なのかという点です。これらの対処法は大きく異なります。三つ目は、Eureka Machine の貢献をそもそも評価できるのかという点です。Recursive はそのプロセスが人間の監督下にあると述べています。興味深い問いは、人間対エージェントの比率がどうだったかであり、それはローンチ記事が答えるようには設計されていない問いです。

今のところ、擁護できる要約は短い。Flintは、おそらくすでに手元にあるハードウェアで動く、本当に小さく、本当に速く、本当にオープンなコーディングモデルであり、誰も検証していないスコア群と、社外の誰も確認していない開発の経緯を伴っている。そのどちらの事実も、この話の核心だ。