ローカルLLMを選ぶとき、「大きなモデルを小さなGPUに載せられる」という話は魅力的です。ただし、ファイルが小さくなる仕組みと、仕事に必要な能力を保てるかは別に確かめる必要があります。今回取り上げるMAPLEは、その二つを考える具体例です。
MAPLEはGoogle公式の新モデルではなく、Gemma 4を基にした第三者の研究・配布物です。作者の速度と品質の数字を、そのまま本誌の検証結果にはしません。公開コードと配布情報を確認し、評価の読み方を解説します。日本語の会議要約や業務文書に使えるかは、別途確かめる必要があります。
何が公開されたのか：Gemma 4由来の約4.75GB GGUF
MAPLEの公開リポジトリは、MoEモデルの一部を選び直して保存量を減らす手法を説明しています。作者はGemma 4 26B-A4Bを基に、各層のエキスパートを128個から48個へ絞ったGGUFを配布しています。エキスパートは、人の専門家ではなく、モデル内部で入力に応じて使い分ける計算部分です。
Hugging Faceの公開履歴では、GGUF追加のコミットは2026年11月7日17:41:20 UTC、日本時間11月8日2:41:20です。本記事の確認時点で約13時間前。リポジトリ作成日時やHNへの投稿時刻を、モデルの公開時刻の代わりにはしていません。
| 区分 | 確認できた内容 |
|---|---|
| 基になったモデル | GoogleのGemma 4 26B-A4B-it。MAPLEは第三者による派生配布。 |
| 配布ファイル | gemma-4-26B-A4B-MAPLE-IQ2_XXS.gguf |
| 容量 | Hugging Face APIのtotalFileSizeは4,745,987,168バイト。約4.75GB、約4.42GiB。必要メモリー総量ではない。 |
| 用途・言語の表示 | 作者はPython・アルゴリズム・技術的推論向けと説明。モデルカードの言語タグは英語。 |
| 取得条件 | 確認時点で公開・非ゲート。モデルカードはApache-2.0と表示。利用・再配布時には実際のライセンス文書も確認。 |
容量と公開状態はHugging Face API、用途とライセンスの表示は配布元モデルカードで確認しました。比較の基準になるGoogleの元モデルカードと、派生物の説明を分けて読みます。元モデルの機能や評価を、そのまま派生物の保証にはできません。
量子化と枝刈りは、減らしているものが違う
量子化は、モデルが持つ数値を少ないビットで表す方法です。たとえば数値を細かく刻む代わりに粗く表せば、保存する量を減らせます。一方、枝刈り（pruning）は、計算に使う部分そのものを取り除く方法です。MAPLEは量子化された配布形式に加え、MoEのエキスパートを選んで残す処理を説明しています。
| 見方 | 量子化 | エキスパートの枝刈り |
|---|---|---|
| 何を減らすか | 数値一つを表す情報量 | 残しておく計算部分の数 |
| 簡単なイメージ | 数字を丸めて、少ない桁数で記す | 用途に合わせて、残す計算部分を選ぶ |
| 確認したいこと | 数値の粗さで出力がどの程度変わるか | 選定に使わなかった言語・仕事でも必要な能力が残るか |
上の表は概念を理解するための整理です。モデル内部に「日本語担当」が一つずつ明確に割り当てられているわけではありません。ある文章で使われなかった計算部分が、別の入力でも不要だと決まるわけではない、と考えるのが実務上のポイントです。
公開された選定コードは、層ごとの使用回数などを読み、スコア順で48個を選びます。ある校正用データでよく使われた部分を残す処理なので、そのデータと実際の用途の違いを確認したくなります。日本語の敬語、固有名詞、短い会話、表の読み取りまで保てるかは、英語のコード課題だけでは分かりません。
「26B」「1.48BPW」「4.75GB」を同じ尺度だと思わない
配布名に残る26Bは、基になったモデルの名称です。確認時点の配布APIではGGUFのパラメーター総数として約109.5億が表示されています。元モデルの名称、枝刈り後の構成、保存ファイルの容量を一つの数字にまとめないことが大切です。
作者の「実効1.48BPW」という表現も、個々の重みがすべて1.48ビットで保存されているという意味には読み替えられません。BPWはbits per weight、重み一つ当たりのビット数を表す言い方ですが、枝刈り前後のどちらを分母にするかで解釈が変わります。量子化形式の名前だけで、元の26Bモデルと同じ能力が残るとは判断できません。
また、ファイル容量と実行時の必要メモリーも別です。推論では重みのほかに、会話の文脈を保持する領域や作業用領域などを使います。入力を長くした場合や複数の要求を同時に処理した場合まで「6GBなら足りる」と一般化しないでください。
作者の速度・品質の数字は、何を測ったものか
作者のREADMEには、RTX 4050 6GBのノートPCで、元の比較用配布物が6.9 tokens/s、MAPLEが45.4 tokens/sという報告があります。前者は30層中16層、後者は30層すべてをGPUへ載せた条件です。これは作者の報告で、本誌は速度を再現測定していません。
この比較には、モデル構成の違いだけでなく、GPUに載る範囲の違いもあります。「枝刈りだけで常に同じ倍率になる」「Macでも同じ速度になる」と結論付けないことが重要です。tokens/sは生成の速さであり、日本語の正しさや、入力を読み終えて最初の返答が出るまでの時間とは別の指標です。
より注意したいのは「品質93.8%」の読み方です。公開benchmark.pyを読むと、4課題に対して指定語が含まれる割合を計算し、その平均を表示しています。コード中にテスト用の文字列はありますが、この関数の採点経路では実行していません。また、元モデルのパス定義はあるものの、このループが呼び出すのは圧縮側だけです。
これは、リポジトリにある当該スクリプトを読んで確認した範囲の説明です。作者が別の試験を一切していないという断定ではありません。ただし、この公開コードだけを根拠に「業務の正答率93.8%」「元モデルの能力を93.8%保持」「日本語でも同品質」と紹介することはできません。
自分で確かめる教材：必要な単語が全部あっても、答えは間違い得る
モデルを取得しなくても、評価方法の違いは小さな教材で確かめられます。keyword-vs-correctness.pyをダウンロードし、Python 3のある環境で次を実行してください。標準ライブラリだけを使い、通信やモデル取得、LLMが生成したコードの実行はしません。
python3 keyword-vs-correctness.py誤った固定例: キーワード 100% / 4ケース合格 False正しい固定例: キーワード 50% / 4ケース合格 Trueこれは固定教材の結果であり、モデルの性能測定ではありません。教材では、入力を無視して同じリストを返す関数にも、必要なキーワードを含めています。一方、正しい結果を返す関数は別の書き方なので、一部の語を使いません。キーワードの数は簡単に測れますが、正しさの代わりにはならないことが分かります。4ケースを通ることも、あらゆる入力での正しさを証明するものではありません。
実際にモデルを試す場合の条件と進め方
作者はllama.cppでの実行を案内しています。公開スクリプトにはWindowsの固定パスが含まれるため、そのまま全OSで動く導入パッケージとは扱いません。llama.cpp自体にはCPU・Metal・CUDAなどのビルド手順がありますが、この派生GGUFと各環境の組み合わせは別途確認が必要です。本誌では対応するCLIを準備した推論試用は行っていません。
- 1配布ページでファイル名、更新履歴、利用条件を確認する。元モデルの説明と派生モデルの説明を分け、取得した版・ファイルのハッシュを記録する。
- 2Gemma 4対応のllama.cppを用意し、使用版とCPU/GPUの種類を記録する。具体的な起動引数は配布元READMEを確認し、長い文脈や並列処理から始めない。
- 3約4.75GBのダウンロードと、モデル以外のメモリー使用を見込む。無料で取得できることと、機材・電力・通信の費用が不要なことは別。
- 4機密情報を含まない短い課題で、ロードと返答を確認する。失敗時はメモリー不足、形式未対応、設定の不一致を区別し、動作成功を創作しない。
- 5日本語の業務に近い課題と正解条件を先に作る。同じ課題を比較対象にも与え、品質と速度を別の列へ記録する。
LLMが出したプログラムを評価する場合、内容を確認せず業務PCで実行してはいけません。必要なら隔離された検証環境で、ネットワークや実データへの権限を付けずに試します。これは本誌の評価手順案で、作者の速度報告を再現した手順ではありません。
日本の仕事で見るなら、速度より先に「落としてはいけない条件」を決める
| 試す用途の例 | 正解条件の例 | 別に記録するもの |
|---|---|---|
| 社内文書の短い要約 | 日付・担当・未決事項を保持。原文にない決定を足さない。 | 初回応答時間、出力完了時間、最大メモリー |
| 日本語からPythonのたたき台 | 仕様の通常例と境界例を満たす。不要な外部通信を追加しない。 | 生成速度と、レビューで直した箇所 |
| 手順書の言い換え | 禁止事項や例外を消さない。製品名を変えない。 | 再試行ごとの失敗傾向 |
この表は評価用の例で、MAPLEで成功した用途一覧ではありません。英語の技術課題に寄せて軽量化した配布物を、日本語の接客や要約へそのまま置き換える前に、必要な能力が残るかを確かめます。「小さくて速い」と「この仕事に適している」を分けるだけでも、導入判断は具体的になります。
ローカルLLMを比較するための小さな評価計画を作ってください。用途は日本語の短い業務文書の要約です。
機密情報を使わず、架空の文書を5件作り、各文書に正解条件を付けてください。日付、担当者の仮名、未決事項、禁止事項の保持を別々に採点します。
単語を含むだけで合格にせず、原文と矛盾していないか確認する基準を示してください。正解条件はモデルへ質問する前に固定します。
記録欄は、モデルとファイル版、実行ソフト版、機材、文脈長、生成設定、課題ID、条件別結果、失敗例、応答時間、メモリー使用量としてください。
未実行の結果を作らず、速度と品質を別々に整理してください。採点案は人が確認する前提です。確認日：2026年11月8日16時便。GitHub確認コミットは7960d5b、モデルカードはafe6a746。配布履歴・容量メタデータ・評価コードを確認し、固定Python教材の意図した失敗と成功を実行確認しました。モデル推論、速度、日本語品質は未実測です。公表された研究を、そのまま業務採用の推奨にはしていません。