LLMをゼロから学ぶOSSにMiniMindが選ばれる理由｜nanoGPT比較

LLM の仕組みを理解したいと考えて transformers や trl、peft のサンプルコードに手を伸ばすと、十数行で学習が終わってしまうことがあります。動いたことは分かるものの、トークナイザの学習からアテンションの計算、損失関数、そして後訓練までのどこで何が起きているのかは、ライブラリの内側に隠れたままです。

かといって、すべてをゼロから書こうとすると別の壁にぶつかります。事前学習から教師ありファインチューニング、さらに強化学習までを個人が用意できる GPU で完走できる教材は、そう多くありません。定番の nanoGPT は GPT-2 の再現を主眼にしており後訓練は守備範囲外ですし、同じ作者の nanochat は一気通貫である代わりに 8×H100 を前提としています。「学びたい範囲」と「用意できる計算資源」の両方を満たす選択肢は意外と限られます。

その中間を埋める位置にあるのが、本記事で扱う MiniMind（GitHub: jingyaogong/minimind）です。64M パラメータという極小サイズに割り切り、コアアルゴリズムをすべて PyTorch ネイティブで実装することで、単一の NVIDIA 3090 クラスの GPU でも事前学習から強化学習までを通せる設計になっています。LLM を自作してみたいエンジニアにとっては、「学べる範囲の広さ」と「GPU 1 枚で完走できる現実性」を同時に満たす候補にあたります。2026 年 9 月時点で 60,960 スターを集めており、この領域では nanoGPT・nanochat と並ぶ規模のプロジェクトです。

本記事では、MiniMind の公式 README・公式サイト・公開されているソースコードの記載に基づいて、モデル構成・学習コスト・学習パイプラインのカバー範囲・類似 OSS との違い・採用前に把握しておくべき制約を整理します。記載内容はすべて公開ドキュメントの読み解きであり、筆者による実行・環境構築などの動作検証は行っていません。数値やコードはいずれも公式ドキュメントからの引用として、出典を明記しながら進めます。

MiniMindとは｜2時間・約3元で64MのLLMをゼロから学習するOSS

抽象化フレームワークに隠れた実装を自分の手に戻す

MiniMind は、GitHub 上の公式リポジトリで公開されている、超小型言語モデルをゼロから学習するためのオープンソースプロジェクトです。リポジトリの説明文は「Train a 64M-parameter LLM from scratch in just 2h!」であり、公式サイトでも「MiniMind - Train LLMs from Scratch」というキャッチが掲げられています。

README のプロジェクト紹介で示されている問題意識は明快です。transformers / trl / peft のような高度に抽象化されたインターフェースに頼ると、開発者が内部実装から隔離されてしまう、という点にあります。そのため MiniMind ではコアアルゴリズムをすべて PyTorch ネイティブで実装し、1 行ずつコードを読みながら学習の全工程をたどれるようにしています。主線の最小構成は、おおよそ GPT-3 の 1/2700 という規模です。

タイトルにある「2 時間」「約 3 元」は、条件付きの数値である点に注意が必要です。README の注記では、「2 時間」は SFT（教師ありファインチューニング）ステージを単一の NVIDIA 3090 で 1 epoch 回した際の実測時間、「3 元（約 3 人民元）」は同じ時間帯の GPU レンタル費用を指すと明記されています。誰のどの環境でも 2 時間で終わるという意味ではなく、「軽量データセットを使えば個人の GPU 1 枚でもこの程度の桁で回せる」という目安として読むのが妥当です。この数値の内訳は、後述するモデル構成と学習コストの節で表として整理します。

リポジトリ基本情報

記事執筆時点（2026 年 9 月 14 日）の GitHub API 取得値は次のとおりです。

採用検討でまず確認したいのは、プロジェクトが現在も生きているかどうかです。この点について MiniMind は、アーカイブ済みではなく、他リポジトリのフォークでもなく、最終 push が 2026 年 9 月 10 日と記事執筆時点の直近にあたります。ライセンスも Apache-2.0 が明示されており、ライセンス未設定のリポジトリにありがちな利用条件の曖昧さはありません。ただし学習データセットの扱いは本体ライセンスと別枠であり、この点は後ほど制約の節で改めて触れます。

LLMをゼロから学ぶOSSにMiniMindが選ばれる理由

MiniMind が同種の自作 OSS の中で選ばれる理由は、README の記述を整理すると 3 本の柱に集約できます。いずれも「小さいから簡単」という話ではなく、「学習目的を達成するために意図的に選ばれた設計」として説明されている点が特徴です。

PyTorchネイティブ実装で抽象化レイヤーを挟まない

1 つ目は実装方針です。MiniMind はモデル定義から各学習アルゴリズムまでを PyTorch ネイティブで書き切っています。LoRA は peft ではなく model/model_lora.py と trainer/train_lora.py による独自実装であり、DPO や PPO、GRPO といった強化学習系のアルゴリズムも trl に依存せず trainer/ 配下に個別のスクリプトとして実装されています。

これは利便性を捨てる選択でもありますが、「アルゴリズムの中身を読んで理解する」という目的に対しては合理的です。モデル本体の実装は model/model_minimind.py にまとまっており、RMSNorm や SwiGLU、RoPE といった構成要素がどう組み合わさっているかを 1 ファイルで追えます。

なお README では、ライブラリに依存しないことと、エコシステムと断絶することは別の話として整理されています。学習済みの重みは transformers 形式に変換でき、llama.cpp / vllm / ollama / Llama-Factory との互換性や、OpenAI API 互換の簡易サーバが提供されている点も挙げられています。学習は自前実装で理解し、推論は既存エコシステムに乗せる、という使い分けが想定されています。

導入は README の「第 0 步」に示された次のコマンドから始まります。

# 克隆仓库、安装依赖
git clone --depth 1 https://github.com/jingyaogong/minimind
cd minimind && pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple

出典: https://github.com/jingyaogong/minimind

事前学習から強化学習まで1リポジトリで完結する

2 つ目は、カバーする学習工程の広さです。trainer/ ディレクトリには、次のスクリプトが並んでいます。

トークナイザの学習から Agentic RL までが同じリポジトリ内に、同じ実装方針で並んでいる点が MiniMind の特徴です。後ほど類似 OSS との比較で触れるとおり、この「後訓練まで含めた守備範囲」が nanoGPT との最大の差分にあたります。

学習データ・公開モデル・デモまで揃っている

3 つ目は、学習を始めるための周辺リソースが揃っていることです。各ステージ用の学習データは収集・蒸留・クリーニング・重複除去を経た形で公開されており、ModelScope のデータセットページおよび HuggingFace から取得できます。学習済みモデルも HuggingFace のモデルコレクションで公開されており、自分で学習する前に出力の傾向を確認することもできます。

README に掲載されている公開モデルの一覧は次のとおりです。現行の主線は minimind-3 系列で、2025 年 4 月の大更新時に minimind-v1 系列の保守は終了しリポジトリから外された旨が更新履歴に記載されています。

推論側も既存ツールに寄せてあり、README には次のような起動例が示されています。

# ollama
ollama run jingyaogong/minimind-3
# vllm
vllm serve /path/to/model --served-model-name "minimind"

出典: https://github.com/jingyaogong/minimind

MiniMind-3のモデル構成と学習コストの目安

採用可否の判断で最も具体的な材料になるのが、モデル構成と学習にかかる時間・費用です。ここでは README の「模型」「实验」章の記載を整理します。

Qwen3生態に整合させたDecoder-Only構成

主線の minimind-3 は Transformer の Decoder-Only 構成で、transformers / llama.cpp / ollama / vllm への変換を意識して Qwen3 系の構成に整合させてあります。採用されている主な要素は次のとおりです。

• Pre-Norm + RMSNorm
• SwiGLU 活性化関数
• RoPE（回転位置埋め込み）。YaRN による長文外挿をサポート
• q_heads=8、kv_heads=4、max_position_embeddings=32768、rope_theta=1e6

README 掲載のパラメータ表は次のとおりです。

この d_model=768, n_layers=8 という配分について、README は工学的なトレードオフとして説明しています。浅いネットワークは学習が速く、一方で d_model を小さくしすぎるとモード崩壊を招きやすい、という両側の制約からの折衷です。あわせて MobileLLM の知見（パラメータ数を固定するなら深さが幅より効く）を引きつつ、d_model < 512 では埋め込み次元が細すぎる弊害が拡大し、d_model > 1536 では幅を広げるより層数を増やす方が有利、という整理が示されています。

注目したいのは語彙数 6,400 という値です。Yi の 64,000、Qwen2 の 151,643、Llama 3 の 128,000 といった一般的な LLM と比べると 1 桁以上小さい設定です。これは小さいモデルほど埋め込み層と出力層が全体のパラメータに占める比率を左右してしまうためで、語彙を絞ることでモデル本体に割けるパラメータを確保する狙いがあります。なお README は、トークナイザの再学習は重み・データ形式・推論インターフェース・エコシステム互換性を同時に劣化させるため非推奨としています。

MoE版はネイティブPyTorch実装のオーバーヘッドを織り込む

minimind-3-moe は同じ構造の FFN を MoE 化したもので、Qwen3-MoE 風の構成から shared expert を除いた設計です。デフォルトは 4 experts / top-1 routing と、MoE としてはかなり控えめな設定になっています。

この控えめさには理由が説明されています。README は、experts を増やすと同規模の dense モデルより実測速度が大幅に落ちると明記しており、その原因として、学習時にトークンを expert ごとにバケット分けして個別に forward するため、カーネルの起動・停止とスケジューリングのオーバーヘッドが重くなる点を挙げています。本格的に最適化するには Triton による独自カーネルや DeepSpeed-MoE、Megatron-LM のような kernel-fused 実装が必要になりますが、それはネイティブ PyTorch という普遍性を手放すことを意味します。その折衷として 4 experts / top-1 を選び、dense 比で約 50% 遅い程度に収めた、という整理です。

MoE 版を選ぶ場合は、「MoE の挙動を学ぶための実装であり、速度面のメリットを得るための実装ではない」という前提で見るのが適切です。

学習時間とコストの目安

README の「训练开销」章には、単一 NVIDIA 3090、レンタル単価およそ 1.3￥/h、7￥ ≈ 1 USD という前提での経験的な推定値が掲載されています。

これを合算すると、minimind-3 は pretrain_t2t_mini + sft_t2t_mini の 1 epoch で約 2.31 時間・約 3.0 元、minimind-3-moe は同じ構成で約 3.23 時間・約 4.2 元、と README にまとめられています。冒頭の「2 時間・3 元」はこの水準を指しています。為替による変動があるため日本円への換算は行いませんが、README 記載の 7￥ ≈ 1 USD という換算レートを当てはめれば、ドル換算での桁感はつかめます。なお README は、8×H100 のような高規格のマルチカード環境であれば総学習時間を分単位まで圧縮できるとも記載しています。

コストがこの水準に収まる前提として、データセットの選択が効いてきます。MiniMind の学習データは軽量版と主線版が分かれており、README は軽量版を推奨の必須項として示しています。

✨ が付いているのが README の推奨ファイルです。上記の時間・コスト表はいずれも _mini 系のデータを使った場合の値であり、10GB・14GB の主線データを使う場合は当然その分だけ時間もコストも伸びます。「まず一周させて全体像をつかむ」段階と「性能を追う」段階で使うデータを切り替える設計になっている、と理解しておくとよいでしょう。

MiniMindの学習パイプラインで手を動かせる範囲

ここからは、各学習ステージで具体的に何を追えるのかを、スクリプト名と対応づけて整理します。自分が学びたい範囲がカバーされているかを照合する材料として読んでください。学習は原則 trainer/ ディレクトリ配下で実行する旨が README に記載されています。

事前学習と教師ありファインチューニング

必須の 2 ステップは事前学習と SFT です。README に示された実行コマンドは次のとおりです。

cd trainer && python train_pretrain.py

出典: https://github.com/jingyaogong/minimind

cd trainer && python train_full_sft.py

出典: https://github.com/jingyaogong/minimind

事前学習の出力は out/pretrain_*.pth（* はモデルの dimension、既定は 768）、SFT の出力は out/full_sft_*.pth として保存されます。複数枚の GPU がある場合は DDP による単機マルチカード学習に対応しており、次の形式で起動します。

torchrun --nproc_per_node N train_xxx.py

出典: https://github.com/jingyaogong/minimind

長時間学習で気になるのが中断時の扱いですが、全学習スクリプトがチェックポイント保存に対応しており、--from_resume 1 を付けると進捗を自動検出して再開します。チェックポイントは ./checkpoints/ に <重み名>_<次元>_resume.pth の形式で保存され、GPU 枚数をまたいだ再開や wandb の同一 run の継続にも対応する、と README に記載されています。時間貸しの GPU を使う学習では実務上ありがたい設計です。

学習の可視化については補足が必要です。2025 年 6 月以降、中国国内から WandB へ直接接続できない事情があり、既定の可視化ツールは SwanLab に変更されています。API 互換があるため import wandb を import swanlab as wandb に置き換える程度で動く旨が記載されています。

なお README は SFT を「単なる対話整形」とは位置づけていません。14GB 規模の主線 SFT データを使う時点で、mid training 的な継続強化に近い工程として扱う、という整理が示されています。

LoRAと知識蒸留

任意ステップとして、LoRA と知識蒸留が用意されています。

LoRA は model/model_lora.py と trainer/train_lora.py による peft 非依存のフルスクラッチ実装です。README は CPU でも比較的軽快に回せると記載しており、出力は lora_xxx_*.pth として保存されます。学習後は scripts/convert_model.py の convert_merge_base_lora でベース重みと LoRA 重みをマージし、完全な重みとして書き出せます。LoRA の数式を追うだけでなく、マージ処理まで含めて実装を確認できる構成です。

知識蒸留は trainer/train_distillation.py が担当し、教師モデルの出力に対して SFT を行う黒箱蒸留と、教師の token 分布を KL ダイバージェンスで学習する白箱蒸留の双方を扱います。SFT 済みの重みを起点に CE + KL の混合損失・温度スケーリングを実装し、MoE と dense を組み合わせた蒸留、チェックポイント再開、分散学習にも対応しています。

RLHFとRLAIFを同じ枠組みで比較できる

MiniMind の後訓練まわりで特徴的なのは、PO 系アルゴリズムを個別に並べるのではなく、統一的な視点で整理している点です。README は各アルゴリズムを「策略項・優勢項・正則項」という 3 つのコンポーネントの実例化として同じ表に並べ、DPO / PPO / GRPO / CISPO の違いをコンポーネント単位で比較できるようにしています。アルゴリズム名を暗記するのではなく、どこが違うのかを構造で理解したい読者にとっては、この整理自体が学習材料になります。

README が自プロジェクトの弱点も含めて観察を書き残している点は、判断材料として価値があります。たとえば GRPO については、グループ内の報酬がほぼ同一になって学習信号が消える「退化グループ」問題が超小規模モデルでは顕在化しやすいと明記されています。

さらに踏み込んだ論点として、報酬希薄（Reward Sparsity）問題が挙げられています。0.1B 級のモデルでは候補となる回答がほぼ全滅して報酬が 0 付近に張り付き、優勢関数が消えて勾配が立たなくなります。そのため MiniMind では、rule-based の二値報酬や難度が高すぎるデータ（MATH500 等）を避け、連続値を返す model-based 報酬を採用しています。報酬モデルには InternLM2-1.8B-Reward をプロジェクトと同階層に配置して使う構成です。「小さいモデルで RL を回すと何が起きるか」を具体的な対処まで含めて追える教材は多くないため、この部分は MiniMind を選ぶ理由になり得ます。

Tool Callingと自適応思考

2026 年 3 月以降の更新で、独立していた train_reason.py は削除され、思考の有無は chat_template と <think> タグ、open_thinking スイッチで制御する設計に統一されています。open_thinking=0 では空の <think>\n\n</think> を注入して直答寄りに、open_thinking=1 では <think> の開始タグを先出しして明示的な思考を続けさせる、という仕組みです。CLI・OpenAI API 互換サーバ・WebUI の 3 経路すべてで切り替えられます。

Tool Calling については、sft_t2t / sft_t2t_mini の主線データにサンプルが混入済みのため、既定の full_sft 重みの時点で基本的な Tool Call が可能です。テストは scripts/eval_toolcall.py で行います。多輪の Tool-Use シナリオに対して GRPO / CISPO を適用する Agentic RL は trainer/train_agent.py が担当し、生成バックエンドは rollout engine として分離されているため切り替えが可能です（既定は torch、sglang server も利用可）。

ここでも README は限界を明示しています。Tool Call と明示的思考を同時に有効化すると、思考過程が安定して出力されにくいとされており、その理由として reasoning と tool call が同居する共同蒸留サンプルの不足が挙げられています。Tool Call データ自体も qwen3-4b で合成した約 10 万件で、ツールは時刻取得・数式計算・天気取得など約 10 種のモック中心です。README 自身が「汎化能力はまだ語れる段階ではない」と記しており、実用的な Agent を作るための土台ではなく、Agentic RL の学習ループを理解するための教材として捉えるべき部分です。

nanoGPT・nanochatとの違い｜類似OSSの選定軸

「LLM をゼロから学ぶ」というカテゴリには複数の有力 OSS があり、MiniMind を選ぶかどうかは他との比較で決まります。ここでは代表的な 5 リポジトリを並べます。

主要5リポジトリの比較

スター数と最終 push はいずれも 2026 年 9 月 14 日時点で GitHub API から取得した値です。

nanoGPT との違いは、後訓練の守備範囲にあります。nanoGPT は GPT-2 の再現に射程を絞った最小実装で、事前学習とファインチューニングが中心です。SFT 以降の後訓練（DPO / RLAIF / Tool Use / Agentic RL）はスコープ外に置かれています。MiniMind は「ゼロから書く」という思想を共有しつつ、後訓練の全工程を 1 リポジトリでカバーする点が最大の差分です。一方で、実装の簡潔さと英語圏での情報量は nanoGPT に分があります。更新頻度という観点では、nanoGPT の最終 push は 2025 年 11 月で、MiniMind より間隔が空いています。

nanochat との違いは、想定する計算資源です。nanochat はトークナイザ学習から RL までを一気通貫でカバーする点で MiniMind と射程が近いのですが、想定環境は 8×H100 を約 4 時間（約 100 ドル）です。単一 3090 での再現を主眼に置く MiniMind とはコスト前提が 1 桁以上異なります。ただし日本語での解説記事の量は nanochat のほうが厚く、日本語話者が学習を進める際の情報の入手しやすさという点では差があります。手元の GPU で完走したいなら MiniMind、多少コストをかけても英語圏の情報量に乗って進めたいなら nanochat、という切り分けになります。

litgpt との違いは設計思想そのものです。litgpt は抽象化された API から実運用向けモデルを回すレシピ集であり、「抽象を排してすべて自前で書く」MiniMind とは方向が逆を向いています。実務投入を急ぐなら litgpt、内部理解が目的なら MiniMind という棲み分けが自然です。

TinyLlama との違いはスケールです。1.1B を 3 兆トークンで学習するスケール志向のプロジェクトで、最終 push は 2024 年 5 月と更新が止まっています。2026 年時点の学習教材としての現行性は高くありません。

補足として、同じく「ゼロから書く」系に分類される llm.c は C/CUDA による低レイヤ実装で、学習対象がカーネルやメモリ最適化寄りになります。後訓練の網羅は目的としていないため、MiniMind とは学べる層が異なります。

目的別の選定軸

上記を、自分の目的に引き直すと次のように整理できます。

MiniMind が最も刺さるのは、「後訓練まで含めて自分で回したいが、用意できる GPU は 1 枚」という交点にいる読者です。逆にこの交点から外れる場合は、他の選択肢のほうが素直に目的を達成できます。

MiniMindを検討する前に押さえたい制約と向き・不向き

判断材料としては「できること」と同じ重みで「できないこと」が必要です。以下は README 自身が明記している限界を中心に整理したものです。

ドキュメントの主言語が中国語である。英語版 README は用意されていますが、日本語のドキュメントは確認できません。コードのコメントや Issue も中国語が中心のため、翻訳ツール併用を前提とした読み進めになります。本記事執筆時点で、日本語の詳細な解説記事も見当たりませんでした。

64M〜198M という規模の能力限界がある。README 掲載の評価でも、生成量やコード生成は健闘するものの、事実誤り（万有引力をアインシュタインに帰属させる、長江の説明を誤る等）が目立つと指摘されています。「小さくても実用的なチャットモデル」ではなく、「学習プロセスを完走できる最小構成」として見る必要があります。

掲載されている評価は厳密なベンチマークではない。README は、掲載している比較が体験参考であり、サンプル数が限られた主観的な比較である旨を自ら明記しています。他プロジェクトとの優劣を判断する材料としては扱えません。

強化学習は報酬希薄問題と隣り合わせである。前述のとおり、0.1B 級では rule-based の二値報酬や難度超過データが機能しにくく、連続値を返す model-based 報酬を選ばざるを得ません。この制約を理解せずに他タスクへ流用すると、学習が進まない原因を特定しにくくなります。

Agentic RL には「アライメント税」が観察されている。README の総括によれば、Agent-CISPO 版は軽量 Agent / ToolUse タスクで full_sft を明確に上回る一方、事実性の安定性が下がり幻覚が増えたとされています。ある能力を伸ばすと別の能力が落ちる、というトレードオフが実データとして記録されている点は学習材料になりますが、「後訓練を重ねるほど良くなる」という期待では臨めません。

MoE 版には実装上のオーバーヘッドがある。ネイティブ PyTorch 実装である以上、kernel-fused な MoE 実装と比べた速度差は前提として受け入れる必要があります。

すべての段階の重みが継続公開されるわけではない。README は、公開重みは実際の release が正であり、DPO / PPO / GRPO / CISPO / Agent / LoRA 等すべての段階の重みが継続的に公開・保守されるとは限らない旨を注記しています。特定段階の学習済み重みを前提にした計画は立てにくい点に注意が必要です。

ライセンスは本体とデータセットで分けて考える。リポジトリ本体は Apache-2.0 ですが、学習データセットの二次利用条件はこれとは別です。README は公開版のデータ出所・処理経路が Apache-2.0 や CC-BY-NC-2.0 等のライセンス要件に適合することを確認済みと記載していますが、CC-BY-NC 系が含まれる以上、商用利用を想定する場合は各データセット側のライセンスを個別に確認する必要があります。学習目的での利用と、成果物を商用で使う場合とでは、確認すべき範囲が変わります。

まとめ｜MiniMind採用判断のチェックリスト

MiniMind は、「LLM の内部実装を、事前学習から後訓練まで自分の手で通して理解する」という目的に対して、個人が用意できる計算資源の範囲で完走できるよう設計された OSS です。60,960 スター・最終 push 2026 年 9 月 10 日という数値が示すとおり、プロジェクトとしても現在進行形で保守されています。

採用するかどうかは、次の 5 問で判断できます。

1. 学習の目的は「内部実装の理解」か、それとも「実運用モデルの構築」か。前者なら MiniMind、後者なら litgpt のようなレシピ集が近道です。
2. 使える GPU は 1 枚か、複数か。1 枚で完走したいなら MiniMind、8×H100 級を用意できるなら nanochat も選択肢に入ります。
3. 学びたい範囲は事前学習までか、後訓練までか。事前学習中心なら nanoGPT で十分です。DPO・GRPO・Agentic RL まで追いたいなら MiniMind が候補に残ります。
4. 中国語のドキュメントを許容できるか。英語版 README はあるものの、Issue やコメントを含めた情報源は中国語が中心です。
5. 成果物を商用利用する可能性があるか。ある場合は、本体の Apache-2.0 とは別に、使用する学習データセットのライセンスを個別に確認してください。

1・2・3 で MiniMind 側に寄り、4・5 の条件をクリアできるなら、MiniMind は現時点で有力な選択肢です。逆にいずれかで引っかかる場合は、比較表に挙げた他の OSS を先に検討したほうが遠回りになりません。まずは公開されている学習済みモデルで出力の傾向を確認し、そのうえで pretrain_t2t_mini + sft_t2t_mini の 1 epoch を回してみる、という順序が、投じるコストを抑えながら判断材料を増やす進め方になります。

なお、MiniMind には視覚モーダルの MiniMind-V、Omni マルチモーダルの MiniMind-O といった派生プロジェクトも公開されています。マルチモーダルへの発展を見込むなら、同じ実装方針で拡張できる点も評価材料に加えられます。

関連情報

自社での LLM 活用や機械学習基盤の構築をご検討中の方は、お問い合わせフォームからご相談ください。要件が固まっていない構想段階からのご相談にも対応しています。