巨大MoEはローカルで動くか【「収まる」と「使える」を実測で線引き】

「Tencent Hy3（Hunyuan 3、総295B/アクティブ21B）」「Xiaomi MiMo-V2.5（総310B/アクティブ15B）」——2026年、数百BクラスのオープンウェイトMoE（混合エキスパート）モデルが相次いで公開されました。SNSでは「MoE構造＋GGUF量子化なら、家庭機材でも動く余地がある」という主張をよく見かけます。本当でしょうか。当サイトが積み上げてきた178件・5機材の自前実測データベースを使い、この主張を3つの要素に分解して検証し、「メモリに収まる」と「実用速度で使える」の間に実測で線を引きます。

話題の主役：2026年に登場した数百B級オープンMoE

Tencent Hy3（Hunyuan 3）は、総パラメータ295B・アクティブ21Bの MoE モデルです（192エキスパートからtop-8を選択。根拠: Hugging Face 公式モデルカード）。ライセンスはApache 2.0。2026年7月上旬頃に公開され、その後まもなく llama.cpp 本流に hy_v3 アーキテクチャ対応がマージされました（PR #25395、2026年7月14日頃）。これを受けて、コミュニティ量子化（GGUF）で128GB級のMacでIQ1_M量子化を実行できたという報告も出ています（コミュニティによる実測であり、当サイトの実測ではありません）。

補足: コミュニティの一部では「アクティブ約15B」という表記も見られますが、これはエキスパートの数え方の違いによるものです。本記事では公式モデルカードの値（アクティブ21B）を採用します。

Xiaomi MiMo-V2.5（表記は「V」とハイフンが正式。「MiMo 2.5」は通称）は、総パラメータ310B・アクティブ15Bの MoE モデルです（256の routed expert からtoken毎に8個を選択。根拠: Hugging Face 公式モデルカード / 公式サイト）。ライセンスはMIT、最大コンテキストは100万トークン。2026年4月下旬頃の公開です。

MiMo-V2.5 には見落としやすい注意点があります。公式にはテキスト・画像・音声・動画を扱うネイティブ・マルチモーダルモデルですが、unsloth等が配布しているコミュニティGGUFは現状テキスト専用です。llama.cpp側で画像・音声入力はまだ未対応のままで（issue #22469）、「GGUF化された＝フル機能でローカル実行できる」わけではありません。ローカルで動くのは、公式モデルの一部機能だけです。

Hy3・MiMo-V2.5に共通するのは、「総パラメータは数百B級だが、生成時に動くのはその一部（アクティブパラメータ）だけ」というMoE構造です。SNSなどでは、この構造とGGUF量子化を根拠に「工夫すれば家庭機材でも動く」という主張がよく語られます。当サイトはこの2モデル自体を実測していません（後述「この実測の限界と読み方」を参照）が、MoEの効き方・メモリの壁・量子化の効果という"原理"の部分は、当サイトが保有する178件・5機材の実測データベースで検証できます。以下、順に見ていきます。

検証すること——「MoE×GGUF×量子化で動く」論を3つに分解する

「MoE構造＋GGUF量子化なら家庭機材でも動く」という主張は、分解すると3つの要素でできています。

1. MoEは本当に効くのか——総パラメータが大きくても、アクティブパラメータが小さければ実用速度が出るのか。
2. 「はみ出しロード」は現実的か——メモリに載りきらない分をCPU/RAM/SSDへ逃がす（オフロード・スワップ）運用は、実用に足るのか。
3. 量子化はどこまで前提なのか——「動く」という報告の多くは、実際にはどの量子化レベルの話なのか。

この3要素それぞれを、当サイトの実測データで確認します。先に断っておくと、Hy3・MiMo-V2.5そのものはどちらも当サイトの保有機材の射程外（総パラメータ295B・310B級で、フル精度はもちろんQ4級でも当サイト保有機材の最大48GB〈A6000〉には収まらないと見込まれます）のため、この2機種を直接計測したものではありません。本記事が検証するのは、これらのモデルを含む「巨大MoEが家庭機材で動く」論を支える3つの原理そのものです。原理をより小さいスケールの実測で確かめ、その延長線上で「収まる」と「使える」の境界がどこにあるかを整理する、という構成になります。

STEP 1収まる

ある量子化レベルで、総パラメータ（アクティブパラメータではない）がメモリに載るか。MoEでも判定基準は変わりません。

↓

STEP 2使える＝収まった上で、次の3つを満たすこと

• ① オフロード・スワップが発生していない
• ② 実用速度で生成できる（当サイトの目安は10 tok/s前後）
• ③ その量子化レベルでの品質低下が用途に見合う

この2段階の基準は、続く実測パートと結論で一貫して使います。「収まる」を満たしても「使える」とは限りません。

① MoEは本当に効くのか——実測で確認する

MoEの主張はシンプルです。総パラメータが大きくても、生成時に動く「アクティブパラメータ」が小さければ、速度は小さいモデル並みに出る。これを、CPU推論の非力なエッジ機（Raspberry Pi 5）と、GPUワークステーション（A6000）の両方で確かめます。

まずRaspberry Pi 5 8GB（CPU推論のみ）で、LFM2.5 8B（総8.5B・アクティブ約1B・MoE）と、同じ「8B級」の密（dense）モデル5種を比較します。いずれもQ4_K_M量子化・ollama 0.31.1・2026-07-15計測で条件を揃えています。

• LFM2.5 8B（A1B・MoE）8.84
• Llama3/3.1系8B派生3種（Llama3.1・Swallow・ELYZA-JP）2.00
• LLM-jp-4 8B（thinking）1.94
• Granite 3.3 8B Instruct1.88

密モデル5種の平均（1.964 tok/s）に対しMoEのLFM2.5 8Bは約4.50倍、個別比較では約4.42〜4.70倍速い。Llama3/3.1系8B派生3種は、近縁アーキテクチャ・同等パラメータ数のモデルで同値（2.00 tok/s）を観測（CPU推論はアーキテクチャと総パラメータ数の影響を強く受ける）。

LFM2.5 8B（MoE）は、同クラスの密モデル5種の平均（1.964 tok/s）に対して約4.50倍、個別モデルとの比較では約4.42〜4.70倍の速度が出ています。密モデル3種（Llama 3.1 8B・Swallow・ELYZA-JP）が揃って2.00 tok/sという同一値なのは不自然に見えるかもしれませんが、3種ともLlama 3／3.1系の近縁な8B派生モデル（パラメータ数もほぼ同一）であり、CPU推論の速度はアーキテクチャと総パラメータ数の影響を強く受けるため、その近さと整合的な結果と考えられます。

次にA6000 48GB（GPU）で、Qwen3 30B（A3B＝総30.5B・アクティブ3B・MoE）と、総パラメータが近い密モデルQwen2.5 Coder 32B（32.8B）を比較します（2026-07-14計測・ollama 0.31.2）。

• Qwen3 30B A3B（MoE・Q4_K_M）160.64
• gpt-oss 20B（MoE・MXFP4・参考）132.82
• Qwen3 30B A3B（MoE・Q8_0）124.31
• Qwen2.5 Coder 32B（密・Q4_K_M）29.76

総パラメータはQwen2.5 Coder 32Bの方がやや大きい（32.8B）にもかかわらず、MoEのQwen3 30B A3B（Q4_K_M）は約5.4倍速い。gpt-oss 20Bは量子化形式（MXFP4）・入力トークン数が異なるため参考値。

総パラメータはQwen2.5 Coder 32Bの方がわずかに大きい（32.8B）にもかかわらず、MoEのQwen3 30B A3Bは約5.4倍速く生成できています。参考値のgpt-oss 20B（MoE・アクティブ3.6B）も、Qwen3 30B A3Bとアクティブパラメータがほぼ同水準で、速度も近い水準（132.82 tok/s）です（ただし量子化形式がMXFP4とQ4_K_Mで異なり、入力トークン数も揃っていないため、この2機種間の比較は目安にとどめます）。

今回の2比較では、MoE側が明確に速く、「アクティブパラメータが小さいほど速い」という仮説と整合する結果でした。ただし、これはあくまで「メモリに載った後」の話です。次の実測が示すのは、その手前——載るかどうかの壁です。

② 「はみ出しロード」の現実——オフロードとスワップは当サイト基準で"動いている"と扱わない

「メモリに載りきらなくても、あふれた分をCPUやRAM、SSDに逃がせば一応動く」——これを本記事では「はみ出しロード」と呼びます。当サイトの計測プロトコルでは、この状態を"実用的に動いている"とはみなしません。実測でどうなるかを見ていきます。

まずRTX 4060 Laptop（VRAM 8GB）でのオフロード検出。当サイトは計測前に必ず ollama ps で PROCESSOR 列を確認し、「100% GPU」でなければ計測を実行せず「実行不能」として記録するというプロトコルを採用しています。実際に2件、この検出でベンチ未実施のままSKIPになりました。

どちらも「一部だけCPUにあふれた」状態で、遅いなりの数値は出せたはずです。しかし当サイトはこれを意図的に計測せず、全GPU常駐という基準を満たさないため「実行不能」というセルとして確定させています。低速でも動く数値を測ってしまうと、"動く"という主張を裏付けてしまいかねないためです（オフロード時の実際の速度は当サイトでは未計測です。関連記事: GPUが使われない・遅い時の対処）。

次にMac mini M4（16GBユニファイドメモリ）でのスワップ実測。Mistral Small 3（23.6B・密モデル）をQ4_K_Mで実行しようとしたところ、メモリを超過してSSDへのスワップが発生し、decode速度は0.18 tok/sまで落ち込みました（num_predict=256の生成完了まで約24.9分）。同じMac mini M4上で、メモリに収まる別モデルQwen3.5 4B（Q4_K_M）の実測値29.27 tok/sと比べると約1/163ですが、モデルも規模も異なるため、この倍率をスワップそのものによる減速率として一般化することはできません。この記録は当サイトの計測プロトコル上「実行不能」と判断され、content/benchmarks/の正式なデータセットには採用されていません（数値そのものはdocs/measurements/20260715-r5-newmodels.md §6に生ログとして記録されています）。

① 一部だけあふれる（オフロード）

RTX 4060 Laptop・Ministral 3 8B / Qwen3-VL 8B

ollama psが100% GPUでない→計測せず「実行不能」

② 全体があふれる（スワップ）

Mac mini M4・Mistral Small 3（23.6B）

0.18 tok/s（別モデルQwen3.5 4B実測比約1/163）→ DB不採用

③ 量子化前提で最初から載らない（F16の壁）

Pi5／Mac mini M4・Llama 3.1 8B（F16）

必要約17.3GBが機材メモリを超過→ロード未試行（理論値）

3つとも「動くことは動く」という主張の材料にされがちだが、当サイトはいずれも実用速度・正式データとしては扱っていない。

MoEであっても、この壁から逃れられるわけではありません。①で見たQwen3 30B A3B（総30.5B・アクティブ3B）は、Q4_K_Mでも重み全体の推定必要メモリが約20.21GBです。これはRaspberry Pi 5（8GB）・Mac mini M4（16GB）・RTX 4060 Laptop（8GB）のいずれにも収まらず、当サイトの実行可能性データでも3機材とも「載らない（理論値・未実測）」と判定されています（content/feasibility/raspberry-pi-5-8gb--qwen3-30b-a3b--q4-k-m.yaml ほか、同一の推定値20.21GBが3機材分記録されています）。MoEが節約するのは生成時の計算量であって、メモリに載せる重みの総量ではありません。アクティブパラメータが1〜3Bと小さくても、総パラメータが数百Bあれば、その全体をどこかに置く必要があります。

量子化を下げなかった場合の壁もあります。Llama 3.1 8B Instruct（8.0B）をF16（無圧縮）で動かすには、当サイトの試算で約17.3GBが必要です。A6000（48GB）では実際に43.12 tok/sで動作しますが（20260618-a6000-llama31-8b-f16.yaml）、Mac mini M4（16GB）・Raspberry Pi 5（8GB）はどちらもこの17.3GBに届かず、「載らない（理論値・未実測・ロード未試行）」と記録されています（content/feasibility/mac-mini-m4--llama-3.1-8b-instruct--f16.yaml、content/feasibility/raspberry-pi-5-8gb--llama-3.1-8b-instruct--f16.yaml）。これらの数値はいずれも実測ではなく机上の試算（confidence: low）である点は正直に書いておきます——だからこそ、誰もロードを試みていません。同じLlama 3.1 8BでもQ4_K_Mまで下げれば、ビット数に応じて必要メモリが縮むという量子化の一般的な性質から、F16（約17.3GB）の1/4程度まで下がると見られ、Raspberry Pi 5でも実際に2.00 tok/sで動作しています（③で詳述）。

まとめると、「はみ出しロード」には少なくとも3つの現れ方があります。①一部だけVRAMからあふれる（オフロード）→当サイトは計測せず対象外扱い（速度は未計測）、②メモリ全体を超過する（スワップ）→実測で0.1 tok/s台まで失速、③そもそも量子化を下げないと最初から載る見込みがない（F16の壁、理論値・ロード未試行）。②の実測は明確に非実用的な速度ですが、①・③は当サイトでは未計測のため、実際に動かした場合の速度は別途確認が必要です。

③ 量子化という前提——実測の大半はQ4_K_M

「MoEなら巨大モデルも動く」という主張には、たいてい明示されない前提があります。それは「量子化はQ4_K_M級まで下げる」という前提です。①②で見た数値も、ほとんどがQ4_K_M（4bit相当）での実測でした。同じモデルでも量子化を上げれば必要メモリも増え、速度は落ちます。

Llama 3.1 8B InstructをA6000（48GB・メモリに余裕があり全量子化が実行可能な環境）で量子化違いで揃えて比較すると、次のようになります（2026-06-18計測・ollama 0.30.8）。

Q4_K_MはF16の約2.6倍速い一方、必要メモリはビット数に応じて縮むという量子化の一般的な性質から、F16（約17.3GB）の約1/4程度と見られます（精度への影響は小さいことが別記事の実測で確認済みです。量子化はどれを選ぶを参照）。A6000上のQwen3 30B A3Bでも同じ方向でした。Q4_K_M（160.64 tok/s）はQ8_0（124.31 tok/s）の約1.29倍速く出ています。MoEは「アクティブパラメータの小ささ」で速度を稼ぎますが、量子化を下げるほど速いという傾向からは（少なくともこの1機材・1モデルの範囲では）免除されません。

この「Q4_K_M前提」がどれだけ支配的かは、当サイトのデータセット全体を見ても分かります。content/benchmarks配下の実測178件のうち、136件（約76%）がQ4_K_M量子化です（自前集計: quant: "Q4_K_M"の出現件数）。これは当サイトが何を計測対象に選んできたかの構成比であり、裏を返せば、当サイトの収載実測では136/178件が最初からQ4_K_M級まで圧縮したうえでの"動いた"であり、無圧縮や高精度量子化での話ではありません（外部の実行報告全体における量子化レベルの分布は、当サイトでは調査していません）。

ニュースで語られる巨大MoEの実行報告は、しばしばこの前提をさらに一段先まで攻めています。冒頭で触れたHy3のコミュニティ報告（128GB級MacでのIQ1_M実行）は、当サイトの標準であるQ4_K_M（4bit相当）よりもさらに強い圧縮です。IQ1_M級の量子化を当サイトでは計測していないため精度への影響を数値で示すことはできませんが、一般に量子化を強めるほど精度は低下する傾向があり（量子化はどれを選ぶで実測済みのQ4_K_M・Q8_0・F16の範囲でもこの傾向は確認されています）、Q4_K_Mよりさらに踏み込んだ圧縮では、その低下がどこまで許容範囲かは個別に確かめる必要があります。「メモリに収まった」ことと「量子化前と遜色ない品質で使える」ことは、別の問いです。

結論：「収まる」と「使える」の間に引ける線

3つの要素を検証した結果は、次のように整理できます。

• ①今回の2比較ではMoE側が速い——CPU推論のRaspberry Pi 5でもGPUのA6000でも、アクティブパラメータが小さいMoEは同クラスの密モデルより明確に速く動きました（Pi5で密5種平均比約4.50倍・個別比約4.42〜4.70倍、A6000で約5.4倍）。今回の2比較の範囲では、アクティブパラメータ仮説と整合する結果でした。
• ②オフロードは対象外、スワップは大幅失速——VRAMから一部あふれる「オフロード」は全GPU常駐基準を満たさないため当サイトでは計測せず対象外とし、メモリ全体を超える「スワップ」は実測で0.18 tok/sまで失速しました（別モデルであるQwen3.5 4B実測値の約1/163）。MoEであっても、重み全体を載せる必要があるという点は密モデルと同じで、Qwen3 30B A3B（アクティブ3B）も20.21GBという低confidenceの試算上、8〜16GB級の機材には収まらない判定です。
• ③量子化は前提であって特典ではない——「動いた」という当サイトの収載実測では、178件中136件・約76%がQ4_K_M級を前提にしており、無圧縮（F16）では、ビット数に応じて縮むという量子化の一般的な性質から、同じモデルでも必要メモリが約4倍に膨らむと見られます。

ここから、「収まる」と「使える」を分けて考える線を引けます。

• 収まる＝ある量子化レベルにおいて、モデルの総パラメータ（アクティブパラメータではない）がメモリに載ること。MoEであっても判定基準は変わりません。
• 使える＝収まった上で、①オフロード・スワップが発生しておらず、②実用速度（当サイトの目安は10 tok/s前後）で生成でき、③その量子化レベルでの品質低下が用途に見合うこと。

冒頭のHy3（総295B・アクティブ21B）・MiMo-V2.5（総310B・アクティブ15B）にこの線を当てはめると、判定の焦点は「アクティブパラメータの小ささ」ではなく「総パラメータがどの量子化レベルでメモリに収まるか」になります。当サイトの実測レンジ（全58モデルのマスタ中、実測記録がある最大はMixtral 8x7Bの46.7B・A6000 48GBが上限）は両モデルの総パラメータを一桁下回っており、この2機種そのものの必要メモリを当サイトの実測から試算することはできません。なお、当サイトで実測できた最大パラメータのモデルもまたMoE（Mixtral 8x7B）だった点は、本記事の主題とも符合します。コミュニティが128GB級MacでIQ1_M級（当サイトの標準Q4_K_Mよりさらに強い圧縮）まで踏み込んで動かした報告は、あくまで1つの成功構成の一例であり必要最小の量子化を証明するものではありませんが、その報告の存在自体は「収まる」ために相当な圧縮が必要になりうる規模であることの傍証にはなります。「使える」かどうか——実用速度と量子化後の品質——は、それとは別に確かめる必要がある問いです。

• 当サイト実測上限（Mixtral 8x7B・A6000）46.7B
• Tencent Hy3（総パラメータ）295B（未計測）
• MiMo-V2.5（総パラメータ）310B（未計測）

当サイトが実測できた最大のモデル（Mixtral 8x7B・46.7B）でも、Hy3・MiMo-V2.5の総パラメータを一桁下回る。この2機種そのものの必要メモリは、当サイトの実測からは試算できない。

現実的な選択肢は、無理に1つの巨大MoEを押し込むことではなく、「収まる範囲で最良のモデルを選ぶ」か「小さいモデルを常駐させ、必要な時だけ大きいモデル・APIへ切り替える」ことです。お手元の機材とモデルの組み合わせで実際に収まるかは動くか診断で、常駐構成とエスカレーション方針の設計はルーティング方針プランナーで、他の機材・モデルの実測値は検証DB（178件・5機材）で確認できます。

この実測の限界と読み方

• Hy3・MiMo-V2.5そのものは未計測です。本記事は、この2機種を含む「巨大MoEが家庭機材で動く」論を支える3つの原理（MoEの速度効果・メモリの壁・量子化の前提）を、当サイトが実測できる規模（全58モデル中、実測記録がある最大は46.7B・Mixtral 8x7B・A6000 48GB）で検証したものです。総パラメータが一桁大きいモデルでも同じ原理が当てはまるはずだという推論であり、Hy3・MiMo-V2.5自体の実速度・実メモリ使用量を保証するものではありません。
• MoEの速度優位の要因を完全には切り分けていません。①の比較はモデルアーキテクチャ・学習手法も異なる別モデル同士の比較で、「アクティブパラメータの小ささ」以外の要因（アーキテクチャの実装効率など）が混ざっている可能性があります。Pi5の密モデル5種のうち3種（Llama 3.1 8B・Swallow・ELYZA-JP）はLlama 3／3.1系の近縁な派生モデルで、独立した5アーキテクチャによる比較ではありません。gpt-oss 20BとQwen3 30B A3Bの比較では、量子化形式（MXFP4 対 Q4_K_M）と入力トークン数も揃っていません。
• ①のPi5・A6000比較表の各値は、当サイトの標準プロトコル（後述）に基づく「2回平均」の実測です。n数は多くありません。傾向としては明確ですが、厳密な統計的検定を経たものではありません。
• RTX 4060 Laptopでの2件のオフロード検出（Ministral 3 8B・Qwen3-VL 8B）は、実行の可否を判定しただけです。オフロード時の生成速度・遅延は当サイトでは未計測で、「実行不能」は当サイトの採用基準（全GPU常駐でなければ計測しない）によるものであり、実測に基づく実用性の判定ではありません。
• 量子化速度比較（Q4_K_M対Q8_0）でのMoE検証は、Qwen3 30B A3Bという単一モデル・A6000という単一機材の結果です。他のMoEモデル・他機材でも同じ傾向が再現するかは未確認です。
• Mac mini M4のスワップ実測（0.18 tok/s）は1機材・1モデル・1回の記録です。再現性の検証（同一条件での再計測）は行っていません。またこの記録は当サイトの正式なベンチマークデータセット（content/benchmarks/）には採用されておらず、docs/measurements/の生ログ記録としてのみ残っています。
• F16・Qwen3 30B A3Bの必要メモリ推定値は理論値です。content/feasibility/のconfidence表記は「low」で、実際にロードを試みた結果ではありません。算出根拠はF16がapprox（パラメータ数からの機械的な試算）、Qwen3 30B A3BのQ4_K_Mはgiven（既知の値をそのまま採用した推定であり、パラメータ数からの計算ではありません）と異なり、いずれも実測不能な巨大な組み合わせについての理論値にとどまります。
• 低ビット量子化（IQ1_M等、Q4_K_M未満）の品質低下は当サイトでは未計測です。「メモリに収まった」という報告があっても、その量子化レベルでの実用品質は別途確認が必要です。
• 「実用速度」の基準（10 tok/s前後）は当サイトの目安であり、用途（チャットの黙読速度・コード生成・エージェントのバックグラウンド処理など）によって適切な基準は変わります。

計測条件・出典

• 実測値（tok/s）は特記なき限り、ollama APIを介した実測・2回平均・num_predict=256・temperature=0という当サイトの標準計測プロトコルによるものです。この基準は/data・/labで公開している計測条件の説明、および実測パイプラインscripts/bench_llm.py（APIオプションに"temperature": 0を固定・計測基盤の稼働当初から一貫）で担保されています。なお各ベンチマークYAMLのnotes欄はこのプロトコルとは別の固定文（2回平均・num_predict=256・計測中の機器温度の最大値）であり、temperature=0はYAML単位では個別に記録されていません（レコードごとの検証ではなく、計測パイプラインの既定値としての裏付けです）。ランタイム（ollamaバージョン）・計測日は機材・モデルごとに個別記載しています。
• 機材のメモリ容量: Raspberry Pi 5 8GB（システムRAM共有・CPU推論のみ）、Mac mini M4 16GB（ユニファイドメモリ）、RTX 4060 Laptop 8GB（VRAM。システムRAMは別途32GB）、RTX A6000 48GB（VRAM）。出典: content/devices/raspberry-pi-5-8gb.yaml、content/devices/mac-mini-m4.yaml、content/devices/rtx-4060-laptop.yaml、content/devices/a6000-workstation.yaml。
• 「オフロード検出→SKIP」は、計測前のollama psでPROCESSORが「100% GPU」でない場合にベンチを実行せず記録する当サイトのプロトコルによるものです。
• 「スワップ→DB非採用」は、計測後の速度・所要時間からメモリ超過によるスワップと判断された場合に、正式なベンチマークデータセットへは反映せず、生ログ・調査記録（docs/measurements/）にのみ残す運用によるものです。
• content/feasibility/配下の数値は実測ではなく、必要メモリの理論値です。算出根拠はobservations[].detail内の自由記述にmem_basis=...という表記で含まれており、F16はパラメータ数からの概算（approx(F16=2B/param)）、Qwen3 30B A3BのQ4_K_Mは既知の値をそのまま採用（given(Q4_K_M)）しています。いずれもconfidence: low、evidence: spec、outcome: theoretical_noなどのフィールドで理論値であることが明示されています。
• 参照したデータセットのバージョンはv1.7.0（content/dataset-release.yaml）。ベンチマーク実測は178件・5機材（Raspberry Pi 5・Jetson Orin Nano Super・Mac mini M4・RTX 4060 Laptop・RTX A6000）、モデルマスタは58件です。
• 本文中の「当サイトの実測レンジ」の上限（46.7B）は、content/models/配下の全58モデルマスタのうち、content/benchmarks/に実測記録が存在するもののparams_b最大値を自前集計したものです（該当: Mixtral 8x7B、A6000・Q4_0実測 20260622-a6000-mixtral-8x7b-q40.yaml、decode 78.85 tok/s）。GLM-5.2（753B）は計測データ未取得、Llama 3.3 70B Instruct（70.6B）はモデルマスタのコメント（content/models/llama-3.3-70b-instruct.yaml）によれば2026-06-21のA6000検証でCPUオフロードが発生し2.17 tok/sという実用外の速度だったためcontent/benchmarks/には未収録としており、集計対象から除外しています。ただしこの経緯を裏付ける構造化ログ（ベンチマークYAML）は存在せず、記録はマスタのコメントのみです。
• 本文中の量子化比率（178件中136件・約76%がQ4_K_M）は、content/benchmarks/配下の全yamlファイルに対するquant: "Q4_K_M"の出現件数を自前集計したものです。