Recursive Flint 必要スペック早見表

Recursive Flint は、Recursive（Hugging Face の組織名 RecursiveSI）が公開した、総40B・活性約2.5BのオープンウェイトMoEモデルで、4bit量子化なら重みは約23〜26GB、動かすのに必要なメモリは24〜30GB前後。 24GBのGPUに全部載せるには3bit級（UD-IQ3_XXS）まで下げる必要があり、12GBのGPUでもエキスパートをCPU側に逃がせば動いたという報告がある。256Kトークンの全コンテキストを使うなら、Recursiveは48GB以上のメモリを推奨している。

Flintは2026年10月21日に公開され、ライセンスはApache 2.0。既存モデルの派生ではなく、ベースモデルなしでゼロから学習されたテキスト専用モデルで、知識のカットオフは2026年6月とされている。本記事では、公開されているファイルサイズと第三者の実測報告から必要スペックを整理する。ベンチマークの多くは開発元の公表値で、独立した検証はまだ少ない点にも注意してほしい（2026年10月23日時点）。

手元のGPU・Macで動くかをすぐ確かめたい場合は、モデル・量子化・コンテキスト長を選ぶだけで必要VRAMを試算できるVRAM計算ツール（無料・登録不要）も用意している。Flintもモデル一覧から選択できる。

「必要メモリの目安」のうち1〜2bit・3bit・Q6・Q8の値はコミュニティの推定、UD-Q4_K_XLの27.4GBは実測、それ以外で「未確認」としたものはファイルサイズ以外に裏付けとなる数字を確認できていない。コンテキストを長くするほどKVキャッシュ分のメモリが増えるため、表の値はあくまで下限に近い目安と考えてほしい。

Flintはdecoder-only構成のMoE（Mixture of Experts）で、総パラメータは39.8B、1トークンあたりに実際に計算へ使われるのは出力ヘッドを含めて約2.5Bである。49層のうち2層が通常（dense）層、47層がMoE層で、MoE層には256個のルーティング対象エキスパートがあり、トークンごとに6個が選ばれ、これに共有エキスパート1個が加わる。語彙数は150,144。

注意層は長文対応のために工夫されている。49層のうち35層はスライディングウィンドウ注意（窓幅513トークン）、残り14層が全体を見るfull attentionで、クエリヘッドは32、KVヘッドは4、ヘッド次元は128。KVヘッドが少なく、ほとんどの層の窓が狭いため、長いコンテキストでもKVキャッシュが膨らみにくい設計といえる。

ここで押さえておきたいのは、速さとメモリは別問題だという点だ。活性が約2.5Bなので1トークンあたりの計算量と読み出す重みは小さく、生成速度は2.5B級のモデルに近くなる。一方で、どのエキスパートが選ばれるかはトークンごとに変わるため、重みは40B分すべてをメモリ上に置く必要がある。「40Bなのに2.5B並みに軽い」のは速度の話であり、必要メモリは40B級のままである。

MoEをローカルで動かすときに混乱しやすいのが、「活性パラメータが少ない＝メモリも少なくて済む」という誤解だ。実際には、活性2.5Bという数字は1トークンあたりの計算量を示すだけで、ファイルサイズや必要メモリを決めるのは総パラメータの39.8Bである。GPUに載り切らない分をRAMに置く構成でも動くのは、使われるエキスパートが一部に限られるためで、その代わりにRAMとVRAMの間の転送が速度のボトルネックになる。12GBのGPUで毎秒46トークンという報告は、この仕組みのおかげで成り立っている。

コンテキスト長の扱いにも注意がいる。公式モデルの上限は262,144トークンで、Recursiveは512Kまで触れつつも256K以下を推奨している。これは入力できる量の上限であって、その長さで精度が保たれるという保証ではない。長文を読ませる用途では、実際のタスクで精度を確認してから使ってほしい。

ユニファイドメモリのMacは、GPUメモリの壁を気にせず40B級のMoEを載せやすい。MarkTechPostは、全262Kコンテキストを使う最低ラインとして48GBのApple Silicon（M4 Pro・M5 Pro・M5 Max）を挙げており、4bitの重みは約23GBとしている。Recursiveも全コンテキストには48GB以上を推奨している。

速度については、開発元がM4 Pro搭載のMacBook Proで毎秒125トークン超（Recursive独自エンジンrec使用）と公表している。コミュニティの報告では、Mac miniでINT4・1Kコンテキストが毎秒122.6トークンで、同じ利用者が測ったQwen3.6-35B-A3Bの4bit（毎秒91.5トークン）より速かった。いずれも短いコンテキストでの値で、長文では下がると考えるのが妥当だ。

32GBのMacは、重みだけなら約23〜26GBで入るものの、macOS自体とKVキャッシュの余裕がほとんど残らず、長いコンテキストには厳しい。短いコンテキストの試用なら現実的だが、実用にはメモリ48GBを勧める。なお、Q5以上の量子化は32GBのMacには現実的でない。

- RTX 5090（32GB）: UD-Q4_K_XL（25.1GB）が余裕を持って載る。llama.cpp b11825・Q4で、生成毎秒約145.7トークン、プリフィル毎秒3,433トークン（atomicagent.ioの検証）。
- RTX 3090・RTX 4090（24GB）: UD-Q4_K_XLは載らない。UD-IQ3_XXS（14.5GB）はRTX 3090に全載せできたというコミュニティ報告がある。3bit級になるぶん品質は下がりうるが、その差を測った独立データは確認できていない。
- RTX 3060（12GB）: UD-Q3_K_XLをVRAM 12GB＋RAM 16GBで、エキスパートをオフロードして256Kコンテキストで動かし、生成毎秒約46トークン、プリフィル毎秒約675トークンという報告がある（X上のコミュニティ投稿で、第三者による再現は未確認で、モデルの種類や量子化によって結果は変わる）。
- 本番運用: 公式のSGLangキットでは、1レプリカあたりB300またはH200を1基としている。

どの構成でも、長いコンテキストを使うときはKVキャッシュ分の余裕を見込む。迷ったら、まず上のVRAM計算ツールで自分のコンテキスト長を入れて試算するとよい。

対応ランタイムは、SGLang（公式キット）、vLLM、Docker Model Runner、llama.cpp、Ollama、LM Studio、Jan。ローカルで手軽なのはllama.cppかOllamaだ。

llama.cppの場合は、Flint対応（PR #30928）を含むビルドb11825以降が必須で、古いビルドでは読み込めない。起動は llama-server -hf unsloth/flint-GGUF:UD-Q4_K_XL で、モデルの取得まで自動で行われる。Ollamaでは ollama run hf.co/unsloth/flint-GGUF:UD-Q4_K_XL で実行できる。Ollamaの公式タグ flint:40b（23GB）も報告されているが、本記事では動作を確認していない。LM StudioとJanは、GUIからGGUFを検索して取得できる。

推奨のサンプリング設定は temperature 1.0・top-p 0.95・top-k 20。難しい問題では、出力トークンの上限を32,768以上にしておく。KVキャッシュはf16かq8_0を使い、q4_0にするとコードの品質が落ちたという報告がある。

公式・Unsloth・LM Studio配布のGGUFは、チャットテンプレートの問題でllama.cppのツール呼び出しが壊れるという報告がある。terelabs/flint-GGUFは修正済みのテンプレートを同梱しているので、エージェント用途ではそちらが選択肢になる。

開発元が公表した主な結果は次のとおり（BF16／NVFP4の順）。Terminal-Bench 2.1は54.9／53.7、SWE-bench Verifiedは74.2／74.1、SWE-bench Pro v2は89.7／88.5、LiveCodeBench v6は80.3／80.8、IFEvalは95.1／94.6で、量子化による低下はごくわずかとされている。ただしこれは開発元の自己申告値である。

独立した小規模エージェント検証では、Flintは18回中12回が成功し、同じ環境のOrnith 1.5 35B-A3Bは18回中14回だった（Flintの使用VRAMは22.8GB）。サンプル数が小さいので優劣の断定はできない。関連モデルの必要スペックは、Ornith 1.5 の必要スペック記事とQwen 3.8 27B の必要スペック記事にまとめている。

なお、テストではFlintが作業を終えていないのに成功と報告し、PLACEHOLDERを書き込むだけの場面があったとの指摘がある。エージェントに任せる場合でも、成果物は自分で検証する前提にしてほしい。日本語の対応については、公式には明記されていない。

ダウンロード前に性能を確かめたいなら、OpenRouterの recursive/flint-v1.0:free が使える。2026年10月22日時点で入出力とも無料（0ドル）、レート制限あり、ツール呼び出しと推論に対応している。無料提供はいつ終わるかわからないため、継続利用の前提にはしないほうがよい。

- メモリ不足（OOM）: 量子化を一段下げる、コンテキスト長を短くする、KVキャッシュをq8_0にする、エキスパートをCPU側にオフロードする、の順で試す。UD-Q4_K_XLは131Kコンテキストで27.4GBを使うので、24GBカードでは載らない。
- モデルが読み込めない: llama.cppのビルドがb11825未満の可能性が高い。Flint対応のPR #30928を含むビルドに更新する。
- ツール呼び出しが動かない: GGUF側のチャットテンプレートの問題が報告されている。terelabs/flint-GGUFの修正版テンプレートを試す。
- 速度が出ない: llama.cppのPRに含まれる適応的な活性スケーリングが、推論を10〜30%遅くするという報告がある。ビルドの更新で改善する可能性はあるが、未確認。
- 出力の品質が荒い: KVキャッシュのq4_0を避ける。サンプリングは temperature 1.0・top-p 0.95・top-k 20 に合わせる。