MiniCPM5-1Bを本格検証：656 MiBの小型LLMは日本語・コード・ゲーム生成に使える？

MiniCPM5-1Bは、約10.8億パラメータの小型言語モデルです。公式GGUFのQ4_K_Mは実ファイル656.19 MiB、Q8_0でも1,100.09 MiB。スマートフォンや小型PCを含むローカル実行を意識したサイズですが、「読み込めるほど軽いこと」と「日本語・コードを正確に処理できること」は別です。

そこで今回は、通常課題ではMiniCPM5-1BのQ4_K_MとQ8_0を、RTX 4070搭載Windows PCのGGUF／Ollama・Thinking無効条件で検証しました。ゲーム生成では約16条件のシューティングを対象に、安全確認後はlocalhost上の実ブラウザで、クリック、キー入力、時間経過、ゲーム進行まで確認しました。

比較対象は同じ1B前後のQwen3.5-0.8BとLFM2.5-1.2B-Instructです。

先に結論

• 軽さは本物：MiniCPM5-1B Q4のモデルファイルは656.19 MiB。4K設定の短文生成では、RTX 4070上の追加VRAMピークが847 MiBでした。
• ただし「物理2GB GPUで確認済み」ではない：計測PCはモデル未ロード時のGPU総使用量が約2.0 GiBで、Q4の4K短文生成時も2,871 MiB（約2.80 GiB）。120K入力では追加4,469 MiBまで増えました。
• 日本語と推論は不安定：今回の通常課題では、MiniCPMのQ4/Q8とも厳格合格は0/30。書式を除いて内容だけを見る機能合格も少数でした。
• 短いJavaScript修正とTool Callingには可能性：Q8はJavaScript修正を3/3で実行成功。Tool CallingはQ4/Q8とも正式な呼び出しと引数生成を6/6で通しましたが、ツール結果を使う最終回答はQ4が0/6、Q8が3/6でした。
• 複数条件のゲーム生成は未成立：約16条件のシューティングは、今回の生成・修正条件では実ブラウザ上のプレイ成立を確認できませんでした。ただし、複数機能を統合するストレステストの結果であり、簡単なゲーム生成全般を否定するものではありません。
• 長いcontextと長文検索能力は別：MiniCPMは約115K prompt tokensを処理できた一方、中央に置いた識別子の取得にはQ4/Q8とも失敗しました。

結論として、用途を軽量なツール振り分けや、検証器付きの限定処理に絞るなら検討価値があります。

「2GBで動く」の意味を分ける

SNSでは「2GBで動く」と一言で表現されがちですが、少なくとも次の値は分ける必要があります。

1. GGUFモデルファイルの容量
2. モデルをロードしたときの追加VRAM
3. Windowsやブラウザを含むGPU総使用量
4. コンテキスト（モデルが一度に参照できる入力範囲）を長くしたときのKVキャッシュ増加
5. システムRAMとOllamaプロセスのWorking Set

今回のQ4は、ファイル656.19 MiB、4K時の追加VRAMピーク847 MiBでした。ただし、RTX 4070上での増分が2 GiB未満だったという意味であり、物理2GB GPUでの動作確認ではありません。

また、同じQ4でも追加VRAMは32Kで1,619.5 MiB、120Kで4,469 MiBまで増えました。「モデル本体が小さい」ことだけで必要メモリは決まりません。

検証環境と使用モデル

• OS：Windows 11 Pro build 26200
• CPU：Intel Core i7-9700K（8コア / 8スレッド）
• RAM：約31.94 GiB
• GPU：NVIDIA GeForce RTX 4070 12GB
• NVIDIA Driver：610.62
• Ollama：0.32.0

「実ファイル容量」はインストール一式の総容量ではなく、ローカルで確認した主要モデルblob／GGUFの実測値です。Qwenの約873M、Q8_0、988.04 MiBはOllama配布物のローカル値で、公式モデルカードの表記とは分けています。

LFMのOllamaメタデータには128,000と表示されましたが、比較上限にはLiquid AI公式モデルカードの32,768を採用しました。使用したのは一般のInstruct版であり、別モデルのLFM2.5-1.2B-JPは未検証です。

評価方法：形式と実動作を分ける

通常課題は10問をseed 11 / 23 / 37で3回ずつ、各モデル30試行です。

• 日本語：情報抽出、障害告知、要約
• 構造化：2種類のJSON生成
• 推論：制約充足と計算3問
• コード：Python生成とJavaScript修正
• temperature 0.2、top_p 0.95、context 4K
• 通常課題はThinking無効、新規会話で実行

明示したtemperatureとtop_pは比較条件として揃えた値で、各社がモデルカードで示す推奨生成条件ではありません。量子化、chat template、Ollamaパッケージ固有の既定値も完全には同一ではないため、素のモデル能力ランキングではなく、今回の配布物とランタイムを含む比較として読んでください。

ゲーム生成の初回試験はNo Think、temperature 0.4、コンテキスト8,192で実行しました。1回修正はNo Think、temperature 0.4、コンテキスト16,384、最大出力8,192です。

評価は2段階に分けました。

• 厳格合格（strict）：指定内容に加え、JSONのみ、コードのみ、文字数などの出力形式も完全に守る
• 機能合格（functional）：Markdown fenceなど外側の軽微な違いを除き、内容が正しい、またはコードがテストを通る

Tool Callingは「正式なtool callとして解釈されたか」「関数名と引数が正しいか」「ツール結果を使った最終回答が正しいか」を別々に判定。ゲームは危険APIを静的検査し、CSP（外部通信を遮断するブラウザ設定）を適用したうえで、localhost上の実ブラウザからStart／Restartのクリック、Spaceや移動キー、R、時間経過、敵や障害物、スコア、終了・再開まで実操作しました。

通常課題の結果

これはモデル全体の万能ランキングではなく、今回の固定課題・量子化・Ollama環境での結果です。ただし、1B前後のモデルへ「短いから簡単だろう」と日本語やJSONを無検証で任せる危険性は見えます。

日本語：Q8化しても安定しなかった

MiniCPM Q4は日本語9試行すべて機能不合格、Q8は1/9でした。Q4には日付・会場・持ち物の語を残した出力もありましたが、「日時」の欄に持ち物を入れるなど項目対応が崩れており、抽出成功には数えていません。Q8の情報抽出では会場と持ち物を拾えても開始時刻の「14:30」を落とす例があり、障害告知ではプロンプトや条件そのものを繰り返しました。

Q8で機能合格した1件は、変更日、料金、自動移行不可、申込が必要という4要件を保持した要約です。ただし、3 seedの小規模検証で成功はこの1件だけであり、「Q8にすれば日本語が安定する」とはいえません。

比較モデルも安定せず、Qwenは原文にない日付を作る例、LFMは原文にない年を追加する例がありました。正確な日本語抽出には、入力根拠との照合や上位モデルへのフォールバックが必要です。

JSON・推論：部分的な成功にとどまる

構造化出力では、LFMがチケット情報のJSON化を3/3で厳格合格しました。MiniCPM Q8は同じ課題を1/3で機能合格しましたが、もう一方の注文JSONでは全モデルが失敗。金額・型・キー構造を同時に守れない例が目立ちました。

推論3問×3 seedでは、監査後の機能合格は4モデルとも0/9です。途中に正しい数字が含まれていても、結論が途切れた出力や矛盾した説明は合格にしていません。

コード：Q8の短いJavaScript修正は3/3成功

コード課題は、Python関数の新規実装と、JavaScriptのaverage関数修正の2種類です。危険APIを含まないことを確認してから、Python／Node.jsでテストを実行しました。

MiniCPM Q8はJavaScript修正を3 seedすべてで4/4テスト通過。コードフェンスを付けたため厳格判定では不合格ですが、機能としては動きました。Qwenも同課題で2/3成功しています。

一方、Pythonの新規実装は全モデルで機能合格なし。MiniCPM Q4もコード課題0/6でした。短いバグ修正の候補にはなっても、今回の課題範囲では、複数条件を含む実装を無検証の一発生成で任せられる根拠は得られませんでした。

ツール呼び出し（Tool Calling）：呼び出し成功と最終回答は別

MiniCPMはQ4でも、Ollamaが正式なtool callとして解釈できる形式を6/6で出し、関数名と引数も6/6で一致しました。ここは通常の日本語・推論課題より明確に良い部分です。

税率計算課題（T1）のスキーマは「10%は数値10として渡す」と明確化した後の結果です。初期の曖昧なスキーマを使ったMiniCPM Q4の診断3件は比較から除外しました。また、MiniCPM公式がTool Callingで案内するSGLangのminicpm5 parserではなく、今回はGGUF／Ollama経路を評価しています。

ただし、ツールが返した合計金額や在庫数を最終回答へ正しく反映できるとは限りません。意味上正しい最終回答はQ4が0/6、Q8が3/6、Qwenが6/6、LFMが5/6でした。LFMのうち2件は¥2728や2,728 yenと正しい値を返しましたが、日本語の「円」という指定表現には一致しなかったため、厳格欄と意味欄を分けています。Tool Callingを使うなら、呼び出しだけで成功扱いにせず、最終回答の検証まで必要です。

ゲーム生成：約16条件のシューティングを実ブラウザで検証

最初に使ったプロンプトは、800×600 Canvas、左右移動、Space射撃、敵の定期出現と下降、衝突、スコア、ライフ、Game Over、2種類の再開、完全初期化、外部依存禁止、自動開始など、約16条件を同時に求めるシューティングゲームでした。これは単純なゲーム作成ではなく、複数機能を一度に統合するストレステストです。

完全HTMLを抽出できた初回候補は次のとおりです。

さらに、初回の静的マーカーフィルターで実ブラウザ確認から漏れていたMiniCPM Q8の2件も再抽出しました。Restart、左右移動、Space、R、待機を実操作しましたが、プレイヤー、敵、スコア進行を伴うゲームにはなりませんでした。これにより、静的キーワードだけで除外していた実ブラウザ確認漏れを修正しました。

約16条件シューティングの1回修正結果

一次生成で観測した不具合を渡し、量子化版と比較モデルに1回だけ修正させました。

ここでの1/9は成功率ではなく、1候補に対する実画面9項目のチェック得点です。MiniCPM Q8修正版とLFM一次生成はいずれも、Canvasなどの表示だけを欠陥付きで1点としたもので、移動、射撃、敵、得点、ライフ、再開は成立せず、ゲーム判定はFAILです。

MiniCPM Q8修正版は800×600のCanvasとRestartボタンまでは表示しました。しかしプレイヤー、HUD、敵はなく、左右とSpaceは無反応。Restartを押すと説明文をCanvasへ描画した後、ctx.moveBy is not a functionで停止しました。

LFM修正版はUnexpected identifier 'justifyContent'の構文エラーで白画面。実際にArrowLeft、ArrowRight、Space、Rを入力しても画面ハッシュは変わらず、Restartボタンも存在しませんでした。完全HTMLを得られなかった2件はゲーム生成としては不成立ですが、画面操作できないため、9項目のブラウザ得点には算入していません。

公開ベンチマーク17.9と中国語命令の追加A/B

Artificial Analysisの2026年5月26日付評価では、MiniCPM5-1B Non-reasoningが当時のIntelligence Indexで17.9を記録しました。17.9は正答率17.9％や日本語性能の点数ではなく、BF16で測った英語・テキストのみの複合指標です。日本語、GGUF量子化、Ollama、ゲーム完成率を直接示さず、中国語命令の優位を証明する値でもありません。6月15日には評価セットと重みがv4.1へ変更されたため、公開時点のスナップショットとして扱います。

命令言語による差を見るため、通常課題および前節の約16条件シューティングとは別の短い課題で、Q8_0を各3シード追試しました。

この追加A/Bでは、DATA、schema、コード、必須の日本語ラベルを共通にし、同一シード・各課題内の同一生成条件で命令文だけを切り替えました。最小クリックゲームは前節の約16条件シューティングとは別課題です。今回のQ8・3シードでは、中国語命令でコードと最小クリックゲームの機能合格が増えましたが、JSONは改善せず、追加A/Bの通常4課題では厳格書式が両方0/12、最終日本語の事実保持は日本語命令より低下しました。したがって中国語化は万能な改善策ではなく、コードや最小UI生成でテストと日本語検品を前提に追加検証する候補です。詳細な日中A/Bは別記事で扱います。

速度とVRAM

固定プロンプトをtemperature 0、top_p 1.0、seed 42、最大192 tokensで実行し、warmupを除いて各モデル5回測定したdecode速度です。VRAMはGPU全体の使用量を0.2秒間隔で取得し、モデル未ロード時との差と測定中ピークを記録しました。

MiniCPM Q4は全5回で上限192 tokensまで生成してdone_reason=length。Q8とQwenも「1～64」の指示に対して0～63を返し、正答したのはLFMだけでした。tok/sは1秒あたりの生成トークン数であり、回答品質の点数ではありません。tokenizerと実際の出力token数も異なるため、近似的な比較です。

OllamaプロセスのWorking Setピークは約115～150 MiBでした。ただしWindowsのWorking Set／Private Bytesは、GPUメモリやマップされたモデル全体を示す値ではありません。PC搭載RAMは31.94 GiBですが、本記事ではこのプロセス値を「モデルが必要とするRAM」とは表現しません。

4K・32K・120K：処理できても思い出せない

長文の中央へ一意な識別子を置き、その文字列だけを返すneedleテストを、temperature 0、top_p 1.0、seed 42、最大32 tokensで行いました。正誤は完全一致で判定しています。

MiniCPMは115,115 prompt tokensをAPIエラーなく評価しましたが、Q4/Q8とも識別子は返せず、生成は32-token上限でdone_reason=lengthとなりました。120K時の追加VRAMピークはQ4が4,469 MiB、Q8が4,823 MiBです。

「最大context 131,072」は入力と生成を合わせた最大文脈長の目安であり、どの位置の情報でも正確に取り出せる保証ではありません。長文RAGやログ分析で使うなら、チャンク分割、検索、再ランキング、回答照合が前提です。

MiniCPM5-1Bを使うなら、向いている構成

以下は今回すべてを直接測定した実績ではなく、観測したTool Callingや短いコード修正の傾向から考えられる利用設計案です。導入前に用途別評価が必要です。

• スキーマを固定した軽量Toolルーター
• 大型モデルへ渡す前の一次分類や振り分け
• JavaScriptなど短い修正案の生成と自動テスト
• 用途別テストで精度を確認済みの定型処理
• 出力検証器と再試行を組み込んだローカルエージェント

避けたい用途は次のとおりです。

• 正確さが必要な日本語の抽出・要約
• 無検証の金額計算やJSON生成
• 長文をそのまま渡すだけの検索・QA
• 多数の仕様を同時に満たすゲームを、一発生成・無検証で完成品扱いする運用
• 生成HTMLを検査せず、そのまま公開・実行する運用

まとめ

MiniCPM5-1B Q4は656.19 MiBと非常に小さく、RTX 4070の4K設定では追加VRAM847 MiB、decode速度293.52 tok/sを記録しました。Q8も1,100.09 MiB（約1.07 GiB）に収まり、ローカルへ置きやすいモデルです。

一方、今回の日本語・JSON・推論ではQ8化しても安定せず、120K入力を処理できてもneedle取得には失敗しました。コードはQ8の短いJavaScript修正、Tool Callingは正式な呼び出し生成に光る部分がありますが、最終回答の検証が欠かせません。約16条件のシューティングも成立しませんでしたが、複数機能を同時に求めるストレステストの結果であり、「MiniCPM5-1Bはゲームを作れない」とまでは結論づけません。

「軽いから何でも任せる」のではなく、狭い役割、機械的な検証、失敗時のフォールバックをセットにする。MiniCPM5-1Bの現実的な使い方はそこにあります。

参考リンク

• OpenBMB MiniCPM5-1B 公式モデルカード
• OpenBMB MiniCPM5-1B-GGUF
• OpenBMB MiniCPM GitHub
• MiniCPM Ollamaデプロイ手順
• MiniCPM llama.cppデプロイ手順
• Qwen3.5-0.8B 公式モデルカード
• Qwen3.5-0.8B Ollama配布ページ
• Liquid AI LFM2.5-1.2B-Instruct 公式モデルカード
• LFM2.5-1.2B-Instruct-GGUF
• Ollama Tool Calling ドキュメント

検証結果は今回のハードウェア、Ollamaバージョン、量子化、固定プロンプト、指定seedに依存します。モデル一般の能力や、他ランタイムでの性能を保証するものではありません。