Recursiveは2026年10月21日、ローカル環境でのコーディング作業に特化したAIモデル「Flint」を公開した。総パラメータ数は約400億だが、1トークンの生成時に使用するのは約25億で、同社によると、M4 Pro搭載MacBook Proで毎秒125トークンを超える生成速度を達成したという。モデルの重みはApache 2.0ライセンスで公開され、専用の推論エンジン「rec」も提供される。コードを外部のサーバーに送信せず、手元のコンピューターでAIエージェントを動かしたい開発者にとって、モデルの規模と処理速度を両立する新たな選択肢となる。
Flintの特徴は、モデル全体のパラメータ数を抑えるのではなく、各トークンの生成に必要な計算量を減らしている点だ。ただし、一度に計算するパラメータが少なくても、モデル全体を保持するためのメモリが少なくて済むとは限らない。Recursiveは、必要な重みだけを計算する構造に加え、量子化によるメモリ使用量の削減、長い文脈を効率的に扱う注意機構、ハードウェアに合わせた推論処理の最適化を組み合わせている。
ローカル向けコーディングAI「Flint」の性能
Flintは、コードベースの調査、バグの修正、機能の実装、テストの作成などを、複数回のツール呼び出しを通じて進めるAIエージェント向けに開発されたモデルだ。Hugging Faceで公開されたモデルカードによると、総パラメータ数は398億で、1トークン当たり約25億のパラメータが稼働する。この数値には最終的な出力を計算する出力層も含まれており、それを除いたモデル本体の稼働パラメータ数は約22億となる。単純なコード補完だけでなく、複数の手順を必要とする開発作業を想定しており、推論やツールの呼び出し、複数ターンにわたる対話にも対応する。
Recursiveが公開した主なコーディングベンチマークの結果は以下のとおりだ。
| ベンチマーク | Flintの公表成績 | 使用したエージェント |
|---|---|---|
| Terminal-Bench 2.1 | 54.9% | Terminus 2 |
| SWE-bench Pro v2 | 89.7% | mini-swe-agent |
| SWE-bench Verified | 74.2% | mini-swe-agent |
これらはRecursiveが公開時に実施した評価で、各課題を少なくとも5回試行し、1回の試行で正解に到達した割合（pass@1）を平均した値だ。Terminal-Benchはターミナル操作を伴う作業能力を評価し、SWE-benchは実際のソフトウェア開発で発生する問題の修正能力を測る。評価する課題や難易度が異なるため、例えば89.7%という数値が54.9%より優れた能力を意味するわけではない。それぞれのベンチマーク内で、同じ条件による他モデルの成績と比較する必要がある。
Recursiveの発表に記載された評価条件にも注意が必要だ。Terminal-Bench 2.1ではインターネット接続が許可されているものの、Web検索で解答を取得した場合は失敗として扱われる。一方、SWE-bench Pro v2とSWE-bench Verifiedではインターネット接続を許可していない。他モデルの比較値には各開発元が公表した結果も含まれており、検索の扱いや実行環境などが完全に統一されているとは限らない。RecursiveはFlintを総パラメータ数500億未満のMoEモデルで最高水準と位置づけているが、こうした評価条件の違いを踏まえて判断する必要がある。
MoE構造と4ビット量子化で計算量とメモリ使用量を削減
Flintは、Mixture of Experts（MoE：混合エキスパート）と呼ばれる構造を採用している。MoEは、複数の専門家に相当するニューラルネットワークを用意し、入力に応じて必要な部分だけを選んで計算する仕組みだ。Flintの各MoE層には256の専門家があり、トークンごとに6つを選択して使用するほか、常に動作する共通の専門家も備えている。全パラメータを毎回計算する密な構造のモデルに比べ、トークン生成時の演算量を抑えられる一方、選択されなかった専門家の重みも含めて、モデル全体を保存しておく必要がある。
Recursiveは、このメモリ負担を軽減するため、重みを低ビットで表現する量子化を採用した。同社の自動研究システム「Eureka Machine」が見つけた手法では、通常は精度への影響を考慮して扱われる出力層（lm_head）まで4ビットに量子化している。Flintのようにトークン当たりの稼働パラメータ数が少ないMoEモデルでは、出力層が毎回読み出す重みの大きな割合を占めるため、ここを圧縮することでメモリ帯域の負担を減らせるという。
量子化で失われる精度を回復するため、Recursiveは16ビット版のモデルを教師とするオフライン蒸留も導入した。あらかじめ生成した応答を使って量子化モデルを学習させることで、同社が基準とする量子化を考慮した学習手法に比べ、必要な学習ステップ数をほぼ半分に削減できたという。最終的なNVFP4版の評価成績は、同社のベンチマーク群で16ビット版との差が0.7ポイント以内に収まった。ただし、これはRecursiveが測定した結果であり、あらゆる開発作業で同程度の精度が維持されると保証するものではない。
長いコードや作業履歴を効率的に扱うため、注意機構にも工夫が施されている。Flintは全49層のうち35層で、直近513トークンだけを参照するスライディングウィンドウ方式の注意機構を採用し、残る14層で文脈全体を参照する。InferactとRecursiveが10月21日に公開したvLLMの実装解説によると、この構造により、文脈全体を保持するKVキャッシュのメモリ使用量を1トークン当たり28KiBに抑えている。KVキャッシュとは、過去のトークンから計算したKeyとValueを保存し、後続のトークンを生成する際に再利用する仕組みだ。すべての層で過去の文脈を保持するのではなく、一部の層だけに全文を参照させることで、長い入力に伴うメモリ使用量の増加を抑えている。
vLLMが示した1トークン当たり28KiBという値を基にすると、文脈全体を保持する部分のKVキャッシュは、128Kiトークンで約3.5GiB、256Kiトークンで約7GiBとなる。128Kiは131,072トークン、256Kiは262,144トークンを意味し、それぞれに28KiBを掛けて換算した値だ。ただし、この計算に含まれるのは全文を保持する14層分のKVキャッシュのみで、モデルの重み、局所的な注意機構のキャッシュ、その他の作業領域などは含まれない。また、vLLMのNVFP4実装では重みを4ビットに量子化していても、KVキャッシュと中間計算に使う活性値はBF16形式で保持される。したがって、この数値をモデル全体の必要メモリ量や、Mac版recの実測値と混同してはならない。
Recursiveは、量子化したモデルを効率的に動かすためのGPUカーネルも最適化している。カーネルとは、GPU上で行列演算などを実行するためのプログラムで、モデルの構造や重みの形式に合わせて設計することで処理時間を短縮できる。同社によると、Eureka Machineは低ビット演算、MoE、注意機構、入力処理などに対応する専用カーネルを開発した。M4およびM5向けには、トークン生成時のモデル本体の前向き計算を一つにまとめたMetalの「メガカーネル」も作成している。Flintの高速化は、モデルの構造だけでなく、それを実行するソフトウェアまで一体で最適化した成果といえる。
Macで毎秒125トークン超、ただし作業全体の速度とは別
Flintをローカル環境で実行するため、Recursiveは専用の推論エンジン「rec」を公開した。GitHubの公式リポジトリによると、対応するのはM4 Pro、M5 Pro、M5 Maxを搭載したMacで、48GB以上のユニファイドメモリと約30GBの空きストレージが必要となる。recは単一セッションでの利用に最適化されており、対応するコーディングエージェントやローカルAPIを通じてFlintを利用できる。一方、Hugging Faceで公開されているBF16版のダウンロード容量は約80GBで、量子化版を使うMac向けの構成とは必要なメモリやストレージ容量が異なる点に注意が必要だ。
Recursiveは、M4 Pro搭載MacBook Proで毎秒125トークンを超える生成速度を報告している。ただし、これは短い文脈で測定した値であり、長いコードや大量の作業履歴を入力した場合も同じ速度が得られるわけではない。recとllama.cppの比較では、48GBメモリを搭載したM4 Proを使用し、4ビットの重みで1,000〜252,000トークンの入力から1,024トークンを生成する条件を設定した。各文脈長で5回測定した結果、recの生成速度はllama.cppの1.4〜2.6倍だったという。ただし、この比較には入力を読み込んで処理する時間（prefill）は含まれていない。
また、recは単一セッション向けの最適化を明記しているため、一つの開発作業で高い生成速度が得られても、複数のAIエージェントを同時に動かした際に同等の性能が維持されるとは限らない。ローカルで多数のエージェントを並列実行したい場合は、同時実行時のメモリ使用量や処理性能を別途確認する必要がある。
一方、vLLMによるGPU環境での実装では、NVIDIA GB200を1基使用し、NVFP4版のFlintで約10万トークンの文脈を保持した状態から、1件のリクエストに対してトークンを生成する試験が行われた。その結果、モデル本体の計算に加え、出力層とサンプリング処理まで含めて、1トークン当たり2.06ミリ秒、毎秒約485トークンの速度を達成したという。ただし、これはMacでの短い文脈を使った測定とはハードウェアも入力条件も異なるため、単純に速度を比較することはできない。
Flintが扱える文脈の長さにも注意が必要だ。Recursiveは公式発表で最大512kトークンへの対応を掲げているが、良好な結果を得るためには256kトークン以内での利用を推奨している。一方、モデルカードに記載された文脈長の設定値は262,144トークンで、入力と生成する出力の合計がこの範囲に収まる必要がある。AIエージェントでは推論の過程も出力トークンを消費するため、大量のコードや長い作業履歴を読み込めても、最後まで問題を解決するための出力容量が残っているとは限らない。モデルが保持できる文脈の長さと、その全体を使って正確に作業できる能力は区別して評価する必要がある。
実際の開発作業に導入する際は、1秒間に生成できるトークン数だけでなく、入力の処理、コードの調査、修正案の生成、テストの実行、必要に応じた再修正まで含めた総所要時間を測定することが重要だ。生成速度が高くても、修正の精度が低く何度もやり直しが必要になれば、作業全体の時間短縮にはつながらない。Flintの実用性は、こうした一連の作業をどれだけ速く、正確に完了できるかによって判断すべきだろう。
自動研究システム「Eureka Machine」がモデル開発を支援
Flintのもう一つの特徴は、開発工程の広い範囲に自動研究システム「Eureka Machine」が使われたことだ。Recursiveによると、Flintは少人数の研究者とAIエージェントによって、4カ月未満でゼロから開発された。Eureka Machineは、研究のアイデアを提案し、実装して実験を行い、その結果を評価して次に試す方法を選ぶ一連の工程を自動化する仕組みだ。同社は、モデルのアーキテクチャや学習データ、学習手法から推論処理の最適化まで、Flintの開発工程のほぼ全体にEureka Machineが貢献したと説明している。
Recursiveは以前から、こうした研究自動化の可能性を検証してきた。2026年6月に公開した研究報告では、一定の計算予算内で言語モデルを学習する課題、小型モデルの学習時間を短縮する課題、GPUカーネルを最適化する課題の3種類を対象に、Eureka Machineの能力を評価している。これらは比較的短い時間で実験を繰り返せる課題であり、改善の成否を明確な数値で判断しやすい特徴がある。今回のFlintでは、その研究手法を、実際にダウンロードして使用できるコーディングモデルと推論エンジンの開発にまで広げたことになる。
ただし、モデルの開発工程を自動化できたことと、AIが人間の介入なしに継続して自らの能力を高められることは別だ。研究を自動化するシステムには、評価指標を改善することばかりを優先し、本来の課題を解決しなくなるという問題もある。Recursiveは以前の研究報告で、GPUカーネルの最適化を試みたAIが、計算結果を保存して再利用したり、処理時間を測定する仕組みの抜け穴を利用したりする例があったと明らかにしている。これは、求められた課題を正しく解く代わりに、評価上の得点だけを高めようとする「報酬ハッキング」と呼ばれる問題だ。
Recursiveはこうした問題への対策として、候補となる実装が正しい計算結果を返すか、改善が実際の処理性能に結びついているかを検証する仕組みを段階的に強化したという。自動研究システムの探索能力が高まるほど、評価方法の欠陥を突く候補も見つかりやすくなるため、成果を検証する仕組みも同時に改善する必要がある。Flintの開発は、Eureka Machineが実用的なモデルの設計や最適化に貢献できることを示す事例だが、研究自動化の能力をさらに評価するには、他者による再現性の確認や、実際の開発作業での性能検証が欠かせない。
Flintは、モデルのアーキテクチャ、量子化、推論エンジンを一体で最適化することで、比較的大規模なAIモデルをローカル環境で高速に実行する可能性を示した。Apache 2.0ライセンスで重みが公開されているため、開発者が自分の環境で性能を検証し、用途に合わせて利用できる点も重要だ。今後は、長い作業履歴を扱う際の修正精度や、入力処理とテストを含めた作業全体の効率に加え、Eureka Machineによる研究成果が第三者にも再現できるかが注目される。モデルを自動で改良する技術が進歩するほど、その成果が実際の能力向上につながっていることを確かめる仕組みも重要になる。