02-inference / wave 1 / status: published / 更新日: 2026-06-15

ollamaで120Bローカル実行|gpt-oss/nemotron実測

要約

総パラメータ120B級のMoEモデル2本が、総31BのDenseモデルを生成速度で逆転した。 MSI EdgeXpert(GB10 / 128GB UMA)+ ollama 0.30.7の実機計測で、短プロンプト時の生成速度はgpt-oss:120b = 36.41 tok/s、nemotron-3-super:120b = 21.66 tok/sに対し、gemma4:31b(Dense)は10.54 tok/sにとどまった。さらに比較対象として追加計測したgemma4:26b(MoE・活性3.8B)は63.76 tok/sで最速、llama3.3:70b(Dense 70B)は4.75 tok/sで最遅となり、5モデルの生成速度は活性パラメータの小さい順に並んだ(最速と最遅で約13倍差)。「生成速度は総パラメータ数ではなく、活性パラメータ × メモリ帯域273GB/sで決まる」という原理の実証である。ollamaで120Bをローカル実行したい読者、GB10機でのMoEとDenseの速度差を実測値で確認したい読者に向けて、導入手順・運用設定・実測値(計5モデル10 run)をまとめる。

検証環境(GB10 / 128GB UMA)

主役の検証モデルは以下の3本。120B級2本が「容量勝負」、31B Denseが「速度の対照」という構図である。

• ※1: ollamaのタグ名は「120b」だが、OpenAI公称の総パラメータは117B(活性5.1B)。MoE層をMXFP4(4.25bit/param、パラメータの90%超)で量子化した配布版で、コンテキストは128K(ollama library公称)。
• ※2: ollamaのタグ名は「31b」だが、ollama library公称の総パラメータは30.7B(Denseのため活性=総)。配布版の量子化フォーマットは公称未確認。

さらに、活性パラメータと生成速度の関係を序列の両端まで広げて確認するため、比較対象として2モデルを2026-06-15に追加計測した。gemma4:26b(同系のMoE。ollama library公称で総25.2B / 活性3.8B、Q4_K_M)と、llama3.3:70b(Dense 70B、Q4_K_M)である。前者は「活性パラメータが最小のMoE」、後者は「最大のDense」として、本記事の速度序列の両端を担う。

• nemotron-3-superのコンテキスト長は、ollama配布版が256K、ネイティブのモデル本体は最大1M(いずれも公称)。

65GB・87GBという巨大なモデルが個別に丸ごとGPUメモリへ載るのは128GB UMAならではだが、合算152GBとなるため2本の同時常駐は不可である(公称SIZEからの単純計算)。この点は後述の運用設定で触れる。

検証内容

ollamaで120Bをローカル実行する手順

導入はNVIDIA公式Playbook記載のワンライナーで完了する(ARM64のままで動作)。OS側の準備は初期セットアップを参照されたい。

# 導入(NVIDIA公式Playbookのワンライナー)
curl -fsSL https://ollama.com/install.sh | sh

# モデル取得
ollama pull gpt-oss:120b
ollama pull nemotron-3-super:120b
ollama pull gemma4:31b

# 計測(--verbose で eval rate 等の統計を表示)
ollama run gpt-oss:120b --verbose

# ロード状況とメモリ占有の確認
ollama ps

本記事のtok/sは ollama run --verbose が表示する eval rate(生成)/ prompt eval rate(プロンプト処理)の値である。これはollama APIの公式メトリクス eval_count / eval_duration × 10^9(時間はナノ秒)と同じ定義として扱い、数値の定義はAPIメトリクスを正とする。なお --verbose フラグ自体は公式ドキュメント上の明記を確認できていない(2026-06-11時点)。

計測条件は「短プロンプト(入力19〜73トークン)」と「長プロンプト(入力7,090〜68,360トークン)」の2条件 × 5モデル。コンテキスト長はgpt-oss:120bとllama3.3:70bを131072、nemotron-3-super:120b・gemma4:31b・gemma4:26bを262144に設定した。

運用設定の要点(計測前に押さえるべき4点)

• コンテキスト長: ollamaのデフォルトは4096トークンと小さい。変更経路は3つ — (a) サーバ起動時の環境変数 OLLAMA_CONTEXT_LENGTH=8192、(b) CLIで /set parameter num_ctx 4096、(c) APIリクエストのoptionsに "num_ctx": 4096。
• keep_alive: モデルはデフォルトで応答後5分間メモリに保持される。-1 で無期限常駐、0 で即時アンロード、手動アンロードは ollama stop <model>。サーバ全体は OLLAMA_KEEP_ALIVE で設定でき、個別リクエストの指定が優先される。
• 同時常駐は不可: 前述のとおり65GB + 87GB = 152GB > 128GBで、120B級2本の切り替え運用が前提になる。なおollama公式ブログはGB10を「120GBのVRAMにモデル全体が収まる」と表現しており、128GB UMAのうちGPUが使える容量の目安となる。
• drop_caches: UMA固有の既知挙動として、cudaMemGetInfo が割当可能メモリを過少報告する(SWAP回収分が未計上)。大型モデルのロード前には、公式の回避策として以下を実行する。

sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'

また nvidia-smi のMemory-Usageが「Not Supported」と表示されるのはGB10では正常な挙動であり、ロード中モデルの占有は ollama ps で確認する。

実測結果(tok/s)

結論から示す。短・長どちらの条件でも、生成速度は「gemma4:26b > gpt-oss:120b > nemotron-3-super:120b > gemma4:31b > llama3.3:70b」と、活性パラメータの小さい順に並んだ。 最速のgemma4:26b(活性3.8B)= 63.76 tok/sと最遅のllama3.3:70b(Dense 70B)= 4.75 tok/sでは約13倍の差がついた(短プロンプト)。以下、主役の120B級3モデルに比較対象2モデルを加えた5モデルで示す(太字が生成速度)。

短プロンプト(入力19〜73トークン)

短プロンプト実行中のDGX Dashboard(System Memory)

長プロンプト(入力7,090〜68,360トークン)

長プロンプトの入力トークン数はモデル間で異なる(gemma4:26b=7,090 / gpt-oss:120b=58,426 / nemotron-3-super:120b=68,360 / gemma4:31b=53,331 / llama3.3:70b=7,668)。prompt tok/s(prefill)はこの入力長差の影響を強く受けるため横比較は参考程度とし、本記事では主に生成tok/sを比較する。

長プロンプト実行中のDGX Dashboard(System Memory)

gpt-oss:120bは58,426トークンの入力を含むrunでも合計3m29.9sで完了しており、長文のプロンプト処理(prefill)は実用的な速度だった。なお短プロンプト時のprompt tok/sは入力が20〜73トークンと極小のため、オーバーヘッドの影響が大きい参考値と思われる。

表の注記:

1. メモリ使用量は、推論実行中にDGX Dashboardの System Memory に表示された値を記録した(システム全体のメモリ使用量であり、ollamaプロセス単体の値ではない)。
2. ollama ps のSIZE(65GB / 87GB / 23GB)はモデル本体のGPU占有、上表のメモリ使用量はシステム全体の値である。差はKVキャッシュやOS・常駐プロセスの使用分を含むためと思われる(内訳は未確認)。なお比較対象のgemma4:26b / llama3.3:70bは ollama ps のSIZEを取得していない。
3. 比較対象2モデルの量子化はQ4_K_M(ollama show で確認)。主役3モデルとは量子化フォーマットが異なるため、生成速度の比較は「活性パラメータ × 量子化ビット幅」の両者を踏まえて読む必要がある(いずれも約4bit級)。
4. nemotron-3-superの長プロンプト時のみload durationが6m8.144711858sと突出していた(他の5 runはいずれも1秒未満: 217.979946ms〜409.904843ms)。原因は未特定。

考察

生成速度は「活性パラメータ × 帯域273GB/s」で決まる

トークン生成(decode)は1トークンごとに活性な重みをすべてメモリから読み出すため、メモリ帯域が律速になる。Denseのgemma4:31bは毎トークン全パラメータを読む。モデル占有は ollama ps で23GBなので、公称帯域からの単純試算では 273GB/s ÷ 23GB ≒ 11.9 tok/s が理論上限となり、実測10.54 tok/s(上限の約89%)はこれとよく整合する。この試算は公称帯域とモデル重みの読み出しのみを想定しており、KVキャッシュの読み出しや実効帯域は考慮していない点に注意されたい。

一方MoEは毎トークン活性分しか読まない。gpt-oss:120bの活性は5.1B(MXFP4)で、総パラメータがgemma4の約3.8倍でも毎トークンの読み出し量ははるかに小さい。実測の序列 36.41 > 21.66 > 10.54 が活性 5.1B < 12B < 30.7B の順とそのまま一致したことは、この原理の実証といえる。原理の詳細はなぜ31Bが120Bより遅いのかで掘り下げる。

nemotron-3-superは活性12B + MTPでもgpt-ossに届かず

NVIDIA公称では、nemotron-3-superはMTP(Multi-Token Prediction)による投機的デコードで「構造化生成において最大3倍」、スループットは「GPT-OSS-120B比2.2倍」とされる(ただし公称の計測ハードはGB10ではない)。しかし今回のGB10 + ollama 0.30.7では逆に gpt-oss:120b が上回った(36.41 vs 21.66 tok/s)。この条件下では活性パラメータの差(5.1B vs 12B)が支配的だった、というのが事実ベースの結論である。なおollama配布版でMTPが有効に働いているかは未確認であり、公称比との乖離の一因である可能性は否定できない(未検証)。また、ollama配布版(87GB)とHugging FaceのNVFP4チェックポイント(約67GB)はサイズが異なり、量子化の内訳も未確認である。NVFP4量子化フォーマット自体の挙動はNVFP4 on Blackwellの量子化フォーマット実測比較で扱う。同モデルの導入詳細はnemotron-3-superをEdgeXpertで動かすを参照。

長プロンプトではprefill高速・生成は低下

prefill(プロンプト処理)は入力トークンを並列処理できるため演算律速となり、帯域律速のdecodeとは挙動が異なる。実測でも長プロンプト時のprompt tok/sはgpt-ossで1589.68 tok/sに達した。一方、生成速度は3モデルとも短プロンプト時から低下した(gpt-oss 36.41→26.82、nemotron 21.66→19.18、gemma4 10.54→7.75)。コンテキスト蓄積に伴うKVキャッシュ参照の増加の影響と思われる(未検証)。低下率はnemotronが約11%と最小(他2モデルは約26%)で、attention層が一部に限られるハイブリッドMamba-Transformer構造によりKVキャッシュへの依存が小さいためと思われる(未検証)。

ollama公式のDGX Spark実測との比較は条件差に注意

ollama公式ブログ(2025-10-23、v0.12.6)のDGX Spark実測では、gpt-oss:120bのdecodeは41.14 tok/s(各テスト10回・temperature 0・出力500トークン・キャッシュ無効)だった。今回の36.41 tok/sより高い値だが、エンジンのバージョン(0.12.6 vs 0.30.7)・出力長・コンテキスト設定・キャッシュ条件がすべて異なるため単純比較はできない。同一条件でのエンジン間比較は推論エンジン横断ベンチで扱う。

gemma4:31bのsegfault(Issue #15318)は0.30.7で再現せず

DGX Spark(ARM64 + GB10)でgemma4:26b/31bがロード時にsegfaultするという報告(ollama Issue #15318、0.20.0時点の報告、2026-06-11現在もopen)があるが、今回のollama 0.30.7では再現せず、5万トークン超の長プロンプトを含めて正常に動作した。同一構成で再現に悩む場合は、まずollamaのバージョン更新を確認する価値がある。

まとめ

• 活性パラメータの小さい順に生成速度が並ぶ(5モデル一貫): gemma4:26b(活性3.8B)= 63.76 → gpt-oss:120b(5.1B)= 36.41 → nemotron-3-super:120b(12B)= 21.66 → gemma4:31b(31B)= 10.54 → llama3.3:70b(70B)= 4.75 tok/s(短プロンプト、ollama 0.30.7)。総パラメータ最大の120B級MoEが中〜上位の速度で、総70BのDenseが最遅という逆転が、5モデルで一貫した。
• 生成速度を決めるのは総パラメータではなく「活性パラメータ × 量子化ビット幅 × 帯域273GB/s」。同系のgemma4で見ると、MoEの26b(活性3.8B)はDenseの31b(活性31B)より約6倍速く、MoEとDenseの差が同系内でも明確に出た。最速のgemma4:26bと最遅のllama3.3:70bでは約13倍差。gemma4:31bの実測は公称帯域からの単純試算(≒ 11.9 tok/s)とも整合した。ただし量子化フォーマットはモデル間で異なる(MXFP4 / NVFP4 / Q4_K_M / 不明、いずれも約4bit級)ため、活性パラメータのみの厳密比較ではない点には留意。
• 128GB UMAだから65GB / 87GBの120B級が個別に丸ごと載る。ただし合算152GBで同時常駐は不可(公称値計算)、切り替え運用が前提。
• 長プロンプトでも序列は同じだった。入力トークン数がモデル間で異なる(約7千〜6.8万)ため prefill(prompt tok/s)の横比較はできないが、生成速度は短プロンプトと同傾向で、コンテキスト蓄積によりやや低下する(未検証)。
• gemma4:31bの既知のsegfault(Issue #15318)は0.30.7では再現しなかった。
• 消費電力・騒音は本計測では記録していない。実測は消費電力・騒音・発熱の実測を参照。

次に読む: 同一条件でollama以外のエンジンと比較する推論エンジン横断ベンチ、今回最速だったMoEの対抗馬を深掘りするnemotron-3-superをEdgeXpertで動かす。

取材メモ

(2026-06-11 調査。特記なきものは当日 WebFetch で本文確認済み。「initial-setup 調査で確認済み」と付記したものは同サイト initial-setup 記事の調査(同日)で確認済みのため再フェッチせず転記)

1. ollama の運用設定(コンテキスト長・ロード/アンロード・環境変数)

• デフォルトのコンテキスト長は 4096 トークン。変更方法は 3 通り: (a) サーバ起動時に環境変数 OLLAMA_CONTEXT_LENGTH=8192、(b) CLI で /set parameter num_ctx 4096、(c) API リクエストの options に "num_ctx": 4096。出典: https://docs.ollama.com/faq
• keep_alive: モデルはデフォルトで応答後 5 分間メモリに保持。API の keep_alive は “10m”/“24h” 形式・秒数・-1(無期限常駐)・0(即時アンロード)を受け付ける。サーバ全体は OLLAMA_KEEP_ALIVE で設定でき、個別リクエストの指定が優先。即時アンロードは ollama stop <model>。出典: https://docs.ollama.com/faq / https://docs.ollama.com/cli (ollama stop gemma4 の例)/ https://raw.githubusercontent.com/ollama/ollama/main/docs/api.md (デフォルト 5m)
• 複数モデル同時ロード: OLLAMA_MAX_LOADED_MODELS デフォルトは「GPU 数 ×3(CPU 推論時は 3)」。OLLAMA_NUM_PARALLEL デフォルト 1。並列リクエスト数に比例してコンテキストが増える(公式例: 2K コンテキスト ×4 並列 = 8K 分を確保)。メモリ不足時はリクエストがキューイングされる。出典: https://docs.ollama.com/faq
• OLLAMA_HOST: デフォルトは 127.0.0.1 ポート 11434。Linux(systemd)では systemctl edit ollama.service で [Service] に Environment="OLLAMA_HOST=0.0.0.0:11434" を追記 → systemctl daemon-reload → systemctl restart ollama。DGX OS も systemd 系のためこの手順が該当(実機での適用結果は実測パートで記録)。出典: https://docs.ollama.com/faq
• メモリ確認・削減: ollama ps でロード中モデルと GPU/CPU 配分(「100% GPU」等)を確認。Flash Attention と K/V キャッシュ量子化がメモリ削減手段として公式に言及されている。出典: https://docs.ollama.com/faq
• tok/s の計測(公式): API レスポンスのメトリクス 6 種(total_duration / load_duration / prompt_eval_count / prompt_eval_duration / eval_count / eval_duration、時間はすべてナノ秒)。生成速度の公式算出式は「eval_count / eval_duration × 10^9」。出典: https://docs.ollama.com/api/usage / https://raw.githubusercontent.com/ollama/ollama/main/docs/api.md
• 注意: ollama run --verbose(total duration / eval rate 等を表示)は実務で広く使われるが、公式ドキュメント(docs.ollama.com の cli・faq・api/usage、GitHub README)での明記は確認できず(2026-06-11 時点)→ 記事の実測は API メトリクス基準を主、—verbose 表示は補助として扱うのが安全。

2. gpt-oss:120b の一次情報(OpenAI)

• 総パラメータ 117B・活性 5.1B(ollama のタグ名は「120b」だが OpenAI 公称の総数は 117B — 数値の食い違いとして両方記録)。MoE 層を MXFP4 量子化することで「単一の 80GB GPU(NVIDIA H100 / AMD MI300X 等)に収まる」。ライセンスは Apache 2.0(商用可)。reasoning effort は low/medium/high の 3 段階。harmony レスポンス形式が必須(「使わないと正しく動作しない」と明記。ollama 配布版はテンプレート側で処理)。コンシューマ機での実行手段として公式 README が ollama を名指しで案内。出典: https://raw.githubusercontent.com/openai/gpt-oss/main/README.md / https://huggingface.co/openai/gpt-oss-120b
• ollama 配布版: MoE・MXFP4(4.25bit/param、パラメータの 90% 超が対象)・約 65GB・コンテキスト 128K。出典: https://ollama.com/library/gpt-oss (initial-setup 調査で確認済み)
• コンテキスト 128K の根拠は ollama library ページの公称。OpenAI 一次ソースでの 128K 明記は今回未確認(openai.com の発表ページが HTTP 403、GitHub README にも記載なし)。
• ollama は「ネット上の MXFP4 GGUF の一部は attention 層が q8_0 に再量子化されているが、ollama 版は意図どおり BF16 を維持」と明記(他所の GGUF とのベンチ差の説明材料になる)。出典: https://ollama.com/blog/nvidia-spark-performance

3. nemotron-3-super:120b の一次情報(NVIDIA)

• 総 120B・活性 12B の MoE × ハイブリッド Mamba-Transformer(Mamba-2 層 + 一部 attention 層 + MoE 層)。LatentMoE(トークンを圧縮してから expert に渡し「同一計算コストで 4 倍の expert を参照」)と MTP(Multi-Token Prediction)層による投機的デコード(構造化生成で「最大 3 倍の wall-clock 高速化」)を搭載。NVFP4 でネイティブ事前学習(latent projection・MTP 層・QKV/attention projection・embedding 等は安定性のため BF16/MXFP8 を維持)。出典: https://research.nvidia.com/labs/nemotron/Nemotron-3-Super/ / https://developer.nvidia.com/blog/introducing-nemotron-3-super-an-open-hybrid-mamba-transformer-moe-for-agentic-reasoning/ / https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
• コンテキスト長の食い違い: モデル本来の対応は「最大 1M トークン」(NVIDIA research ページ・HF モデルカードとも明記)。一方 ollama 配布タグの公称は 256K(initial-setup 調査で確認済み: https://ollama.com/library/nemotron-3-super )。記事では「ollama 版は 256K、ネイティブは最大 1M」と両方併記すること。
• ライセンス: NVIDIA Nemotron Open Model License、商用利用可。公開は 2026-03-10(research ページ。HF カードの日付は 2026-03-11)。出典: https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 / https://research.nvidia.com/labs/nemotron/Nemotron-3-Super/
• NVIDIA 公称スループット: 「GPT-OSS-120B 比 2.2 倍・Qwen3.5-122B 比 7.5 倍」(計測ハードは GB10 ではない点に注意。GB10 上で同比が出るかは本記事の実測対象)。RULER 1M コンテキストでも優位と主張。出典: https://research.nvidia.com/labs/nemotron/Nemotron-3-Super/
• HF の NVFP4 チェックポイントは約 67GB(safetensors)。最小ハードウェア要件に「1× B200 または 1× DGX Spark」と明記(GB10 機が公式の最小構成)。対応ランタイムは vLLM v0.20.0+ / SGLang / TensorRT-LLM v1.3.0rc12+ / Transformers。DGX Spark 向けの vLLM Docker 手順も記載。出典: https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
• NVIDIA 公式デプロイガイドに DGX Spark 専用構成「Config C — NVFP4, DGX Spark」あり: trtllm-serve 直接起動・max_batch_size: 4・MoE バックエンド CUTLASS。ollama より先のステップ(TensorRT-LLM 比較記事)の素材になる。出典: https://docs.nvidia.com/nemotron/latest/usage-cookbook/Nemotron-3-Super/AdvancedDeploymentGuide/README.html
• サイズの食い違い: ollama 配布版は約 87GB(initial-setup 調査で確認済み)に対し HF NVFP4 は約 67GB。ollama 版の量子化フォーマット内訳(どの層が何ビットか)は未確認 → 実機の ollama show で確認して記録すること。

4. GB10 / DGX Spark 固有(メモリ・性能・既知の不具合)

• ollama 公式の DGX Spark 実測ブログ(2025-10-23、ollama v0.12.6、ファームウェア 580.95.05、各テスト 10 回・temperature 0・出力 500 トークン・キャッシュ無効):
  • gpt-oss:120b(MXFP4)= prefill 1,169 tok/s / decode 41.14 tok/s
  • gpt-oss:20b(MXFP4)= prefill 3,224 tok/s / decode 58.27 tok/s
  • llama3.1:8b(q4_K_M)= prefill 7,614 tok/s / decode 38.02 tok/s
  • 注意: 2025 年 10 月時点の旧バージョンでの値。本記事の実測(2026-06 の ollama)との差分自体がネタになる。nemotron-3-super はこのベンチに含まれず、GB10 上の公式実測値は未確認。出典: https://ollama.com/blog/nvidia-spark-performance
• 同ブログは GB10 について「120GB の VRAM にモデル全体が収まる」と記載(128GB UMA のうち GPU 利用可能分の目安)。gpt-oss-120b は MXFP4 で全体がロード可能。出典: https://ollama.com/blog/nvidia-spark-performance
• ollama は NVIDIA と提携し GB10 でのアウトオブボックス動作を最適化済み(2025-10-13)。出典: https://ollama.com/blog/nvidia-spark (initial-setup 調査で確認済み)
• 導入は公式 Playbook のワンライナー(ARM64 のままで可)・API はポート 11434。出典: https://raw.githubusercontent.com/NVIDIA/dgx-spark-playbooks/main/nvidia/ollama/README.md (initial-setup 調査で確認済み)。同 Playbook に 120B 級のメモリ要件・tok/s 計測・ARM64 固有のトラブルシュートの記載はなし(2026-06-11 再確認)
• 既知の不具合(本記事の対照モデルに直撃): gemma4:26b/31b が DGX Spark(ARM64 + GB10、128GB UMA)で segfault しロード失敗する報告(ollama 0.20.0、「llama runner terminated: exit status 2」)。Issue は 2026-04-04 起票で 2026-06-11 時点 open・メンテナ応答なし。同一ハードで Nemotron 3 Super 120B / Qwen3.5 35B / Qwen2.5 72B は動作報告あり。→ 速度比較の対照に gemma4:31b を使う本記事では、実測時の ollama バージョンと再現有無を必ず明記。出典: https://github.com/ollama/ollama/issues/15318
• UMA 固有の既知挙動(initial-setup 調査で確認済み): cudaMemGetInfo が割当可能メモリを過少報告(SWAP 回収分が未計上)→ 大型モデルのロード前に sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches' が公式回避策。nvidia-smi の Memory-Usage は「Not Supported」表示が正常(プロセス別 GPU メモリは表示される)。出典: https://docs.nvidia.com/dgx/dgx-spark/known-issues.html
• メモリ見積もりの整理(出典つき公称値のみ): gpt-oss:120b 約 65GB(ollama library)+ nemotron-3-super:120b 約 87GB(ollama library)。両方の常駐は 65+87=152GB > 128GB のため不可(公称値からの単純計算)。KV キャッシュは「並列数 × コンテキスト長」に比例して増え、Flash Attention / KV 量子化で削減可能(ollama FAQ の一般則)。モデル別の KV キャッシュ容量(GB/トークン)の公式数値は未確認 → 実測で ollama ps の値を記録すること。

GB10 公称固定値(照合用・誤記防止)

• メモリ帯域 273GB/s / 128GB UMA / 推論最大 200B パラメータ(FP4)/ 1 PFLOP(FP4、sparsity 前提の理論値)。トークン生成は帯域律速のため、速度を決めるのは「活性パラメータ × ビット幅」: gpt-oss:120b は活性 5.1B(MXFP4)、nemotron-3-super は活性 12B(NVFP4)+MTP、対照の gemma4:31b は Dense 30.7B。MoE 120B 級が Dense 31B を上回る逆転の実測が本記事の核。

未確認事項(sources 非掲載 or 要実測)

• gpt-oss-120b のコンテキスト 128K の OpenAI 一次ソース明記(openai.com 発表ページが HTTP 403。2026-06-11 時点)。現状の根拠は ollama library ページのみ
• ollama 配布版 nemotron-3-super(約87GB)の量子化内訳(HF NVFP4 の約67GB との差の理由)
• ollama 版 nemotron-3-super で MTP(投機的デコード)が有効に働くか(公式記載なし。実測で要確認)
• ollama run --verbose の公式ドキュメント上の記載(見つからず。API メトリクスは公式記載あり)
• nemotron-3-super の GB10 上での公式ベンチ値(ollama 公式 Spark ベンチに含まれず)
• nemotron-3-super の総/活性パラメータの小数点精度の値(「120.6B/12.7B」は検索スニペットのみで本文未確認のため記事では 120B/12B を使用)