本文へ移動

Nemotron 3.5 Bolt E4BはVRAM 6GBで約58 tok/s

【PR】この記事にはアフィリエイトリンクを含みます。実測に使った機材と、実測していない機材は、リンクごとに区別して記載しています。

この記事の測定結果 llama-server の生成の中央値と、8問×3回の間の VRAM の最大(GPU 全体。画面表示分を含む)です。

Nemotron 3.5 Bolt E4B Q4_K_M(公式)

58.048 tok/s

llama-server・中央値

全層GPU 43/43 単位がGPU

読み込み前 2,246 測定中の最大 5,702 VRAM 6,144 MiB

Nemotron 3.5 Bolt E4B UD-Q4_K_XL(Unsloth)

55.191 tok/s

llama-server・中央値

全層GPU 43/43 単位がGPU

読み込み前 1,495 測定中の最大 5,259 VRAM 6,144 MiB

Nemotron 3.5 Bolt E4B UD-Q3_K_XL(Unsloth)

55.738 tok/s

llama-server・中央値

全層GPU 43/43 単位がGPU

読み込み前 1,486 測定中の最大 4,435 VRAM 6,144 MiB

4GB(4,096 MiB)未満だったのは llama-server 単体の量です。画面表示を含む GPU 全体では、3つとも 4,096 MiB を超えました。

GPU
VRAM 6GB の GPU(6,144 MiB)。画面表示もこの GPU
CPU・メモリ
12th Gen Intel(R) Core(TM) i3-12100
実行環境
llama.cpp b12005(llama-server と llama-bench)

同じVRAMの他のモデルと比べる →

結論

名前に「4GB」が入った Nemotron 3.5 Bolt E4B を、画面表示と兼用の VRAM 6GB の GPU で実測した結果です。量子化は3つ、条件は llama.cpp(b12005)の llama-server、文脈設定4096。

  • 3つとも全層(43/43 層)が GPU に載った。llama-server 単体の共有 GPU メモリは各 128 MiB で、判定は「少量」
  • 4GB(4,096 MiB)未満だったのは llama-server 単体の量。専用メモリの最大は約2,900〜3,700 MiB
    • 画面表示を含む GPU 全体は約4,400〜5,700 MiB で、3つとも 4,096 MiB を超えた(元の値は VRAM の節)
  • 生成は約55〜58 tok/s(llama-server の中央値)。いちばん速いのは公式の Q4_K_M
  • 同じ8問を3回ずつ(24本)解かせた正答は、Q4_K_M・UD-Q4_K_XL が各15本、UD-Q3_K_XL が13本。指定条件まで合格は 12・12・10本
  • 思考 ON(Q4_K_M)は正答18本、指定条件まで合格は11本。答えまでの中央値は OFF 2.255秒、ON 11.035秒

DFlash(投機的デコード)は、はみ出しが出たため未測定。

検証環境と条件

項目内容
GPUVRAM 6GB の GPU(6,144 MiB)。画面表示もこの GPU。ドライバ 610.88
CPU12th Gen Intel(R) Core(TM) i3-12100
RAM34,136,092,672 bytes
OSWindows 11(10.0.26300)
実行環境llama.cpp b12005(llama-server と llama-bench)
測定日2026年11月1日夜〜2日 0時台

モデルは次の3つの GGUF(サイズと SHA256 の一致を確認済み)。

量子化配布元ファイル名・サイズ
Q4_K_M公式(NVIDIA)Nemotron-3.5-Bolt-E4B-Q4_K_M.gguf
6,180,446,208 bytes
UD-Q4_K_XLUnslothNVIDIA-Nemotron-3.5-Bolt-E4B-UD-Q4_K_XL.gguf
5,060,482,240 bytes
UD-Q3_K_XLUnslothNVIDIA-Nemotron-3.5-Bolt-E4B-UD-Q3_K_XL.gguf
4,219,133,120 bytes

モデルカードによると、Gemma-4-E4B-it をもとに NVIDIA が追加学習したモデル。読み込みログの表示は3つともパラメータ数 7.52 B。

UD-Q4_K_XL は混合量子化で、起動ログの file type は「Q5_K - Medium」と表示されました。

  • llama-server:全層 GPU(-ngl 99、3つともログで 43/43 層)、文脈設定4096、flash attention 有効、同時1件
  • 思考 OFF が基本。チャットテンプレートの思考の切り替え(enable_thinking)と、OFF になることを3つとも起動時に確認
  • 生成条件:temperature 0.2、top_p 0.95、top_k 40、min_p 0、repeat_penalty 1.0。max_tokens は 1024(思考 ON は 3072)
    • 前回の LFM3-1.7B・MiniCPM5-2B と同じ条件。モデルカードの推奨(temperature 1.0・top_p 0.95)ではない
  • 8問の文面は前回記事と一致を確認済み。シード 11・23・37 で各課題3回
  • 量子化ごとの手順:30秒待機 → llama-bench → 30秒待機 → llama-server 起動 → 暖機 → 24本の回答 → 停止
    • Q4_K_M だけ、停止の前に同じ起動のまま思考 ON の24本
  • llama-bench:全層 GPU(-ngl 99)、flash attention 有効、4スレッド、3回
  • q7(Python)・q8(JavaScript)のコードは別の Linux 機でテスト
    • ネットワークなしの隔離環境で、解答ごとに使い捨てのフォルダ
    • 1本あたり実時間10秒・メモリ 1GiB などの上限付き
    • テストは前回の LFM3-1.7B と同じファイル(SHA256 一致)
  • VRAM の記録方法は VRAM の節

用語

  • tok/s:1秒あたりに生成するトークン数。トークン(モデルが文章を扱う単位)の区切り方はモデルごとに違う
  • 正答:今回の採点基準で、内容が合っていると判定した回答。q7・q8 はテストの全件合格が条件
  • 指定条件まで合格:正答のうち、出力の形式や課題で求めた説明も基準を満たした回答
  • 答えまでの秒数:リクエストを送ってから応答が全部返るまで。読み込みと暖機のあとに測定
  • GPU 全体:画面表示などを含む、GPU 全体の VRAM 使用量(nvidia-smi)
  • llama-server 単体:llama-server のプロセスが使う専用 GPU メモリ(Windows のカウンタ)
  • 共有 GPU メモリ:GPU がメインメモリ側に確保した分。手順では、この量で VRAM からのはみ出しを判定

速度

生成は公式の Q4_K_M がいちばん速く、3つとも 55〜58 tok/s 台。入力の処理はほぼ同じです。

量子化llama-server 生成(tok/s)入力の処理(tok/s)ロード
Q4_K_M58.048(57.137〜58.343)227.89246.421秒
UD-Q4_K_XL55.191(53.391〜55.44)227.31145.705秒
UD-Q3_K_XL55.738(55.279〜56.049)228.35145.426秒
量子化llama-bench pp512(tok/s)llama-bench tg128(tok/s)
Q4_K_M265.463 ± 4.07558.58 ± 1.106
UD-Q4_K_XL264.557 ± 6.70656.308 ± 0.595
UD-Q3_K_XL264.125 ± 4.62956.684 ± 1.033
  • llama-server の列:応答に含まれる値の中央値(各24本、すべて正常終了)。かっこ内は最小〜最大
  • llama-bench:pp512 は512トークンの入力処理、tg128 は128トークンの生成。値は3回の平均±標準偏差
  • ロード:llama-server の起動から応答できるまで。同じモデルの bench 直後の値で、OS のファイルキャッシュは未制御
  • ファイルが最も大きい Q4_K_M が、生成はいちばん速い
  • UD-Q4_K_XL と UD-Q3_K_XL の生成はほぼ同じ
  • 思考 ON の速度は「思考 ON の損得」の節

VRAM と「4GB」の中身

4GB(4,096 MiB)未満だったのは llama-server 単体の量です。画面表示を含む GPU 全体では、3つとも 4,096 MiB を超えました。

「4GB」はモデル名(リポジトリ名)にある語で、モデルカードに VRAM の必要量としての説明はありません。この記事の 4,096 MiB は、実測値と比べるための線です。

  • GPU 全体:測定の外側で1秒おきに記録した nvidia-smi(同じ PC)。区間は測定ログの時刻で切り出し
  • llama-server 単体:Windows のパフォーマンスカウンタ(PDH)の、プロセス単位の値
  • NVML の値は、nvidia-smi との照合差が 177.422 MiB で基準の 128 MiB を超えたため、手順どおり不使用

GPU 全体(画面表示分を含む)

3つとも 6,144 MiB に収まりました。残りがいちばん少ないのは Q4_K_M。

Nemotron 3.5 Bolt E4BのQ4_K_M・UD-Q4_K_XL・UD-Q3_K_XLで、llama-server起動前の待機から8問×3回の終了までのGPU全体のVRAM使用量の推移。VRAM 6GBのGPU(上限6,144 MiB)で、外部のnvidia-smiで1秒おきに記録。画面表示分を含む。
GPU 全体の VRAM 使用量(外部の nvidia-smi、1秒おき、画面表示分を含む)。横軸は llama-server 起動からの秒数。点線は 4,096 MiB、破線は 6,144 MiB。Q4_K_M は思考 ON の区間を除く。
量子化待機8問×3回中の最大(増加)残り
Q4_K_M2,246 MiB5,702 MiB(+3,456)442 MiB
UD-Q4_K_XL1,495 MiB5,259 MiB(+3,764)885 MiB
UD-Q3_K_XL1,486 MiB4,435 MiB(+2,949)1,709 MiB
量子化bench 直前の待機llama-bench 中の最大(増加)残り
Q4_K_M2,488 MiB5,634 MiB(+3,146)510 MiB
UD-Q4_K_XL2,238 MiB5,602 MiB(+3,364)542 MiB
UD-Q3_K_XL1,497 MiB4,793 MiB(+3,296)1,351 MiB
  • 待機:llama-server 起動直前30秒の中央値(下の表は llama-bench 直前30秒)
  • 最大:区間の最大値
  • 増加:直前の待機の中央値との差
  • 残り:「6,144 MiB−最大」
  • 待機の値が量子化ごとに違う。画面表示などの使用量が測定中に変わったため、比べるときは増加も見てください
  • Q4_K_M の待機区間は 1,798〜2,248 MiB で、途中で上がった(図の左端の段差)
  • UD-Q4_K_XL の待機は、bench 直前の 2,238 MiB から llama-server 直前には 1,495 MiB に下がった
  • llama-server 停止後は 1,490〜2,238 MiB に戻った

「4GB」未満だったのは llama-server 単体

単体の専用メモリは3つとも 4,096 MiB 未満。いちばん大きいのは、ファイルが中間の大きさの UD-Q4_K_XL でした。

量子化専用メモリの最大共有 GPU メモリの最大判定
Q4_K_M3,468.887 MiB128 MiB少量
UD-Q4_K_XL3,746.891 MiB128 MiB少量
UD-Q3_K_XL2,944.883 MiB128 MiB少量
  • 値は8問×3回の区間の最大(Windows のカウンタ、llama-server のプロセス単位)
  • 判定:共有 GPU メモリの量による、はみ出しの手順上の区分(なし/少量/あり)
  • GPU 全体の増加(上の表)は、単体の専用メモリに近い量だった
  • ファイルの大きさと単体の VRAM は、順番が一致しない。Q4_K_M よりファイルが小さい UD-Q4_K_XL のほうが、単体では大きい
8問×3回の実行中のVRAMのピークを量子化ごとに並べた棒グラフ。GPU全体(起動前の待機と起動後の増加)と、llama-serverプロセス単体の専用メモリの最大。4,096 MiBと6,144 MiBに線。
8問×3回の実行中のピーク。灰色は起動前の待機(画面表示など)、色は起動後の増加、斜線は llama-server 単体の専用メモリの最大(Windows のカウンタ)。
Q4_K_Mのllama-serverが起動を終えた時点の画面。専用GPUメモリ5,649 MiB、共有GPUメモリ452 MiB(GPU全体、Windowsのカウンタ)と、n_ctx = 4096のログ。
Q4_K_M の起動完了時点(2026年11月2日 0時12分)の値。表示は GPU 全体の専用 5,649 MiB・共有 452 MiB で、llama-server 単体の共有 GPU メモリは 128 MiB。

起動ログの buffer

Q4_K_M では、CPU 側の model buffer が GPU 側(CUDA0)より大きい値でした。どのテンソルが CPU 側に置かれたかは、ログでは未確認です。

量子化CUDA0 modelCPU 側 modelKV(CUDA0)compute(CUDA0)
Q4_K_M3,023.053,536104132.02
UD-Q4_K_XL3,298.981,952104132.02
UD-Q3_K_XL2,496.61,787104132.02
  • 単位は MiB。server.log の buffer 行の値
  • CUDA_Host は3つとも 47.03 MiB(output 1.00+compute 46.03)
  • GGUF 内の per_layer 系の重み(per_layer embedding など)は、Q4_K_M で 3,049,784,320 bytes(2,908.501 MiB)
    • UD-Q4_K_XL と UD-Q3_K_XL は各 1,640,498,176 bytes(1,564.501 MiB)
  • CPU 側の値との関係は、個々のテンソルの置き場所をログで確認していないため断定しない

自分の PC に当てはめる

GPU 全体の最大は「待機+増加」。この PC では、増加が単体の専用メモリに近い量でした。別の PC で同じになるかは未測定のため、次の手順は目安です。

  1. 起動前に、画面表示などで使われている量(待機)を確かめる
  2. 待機に、使う量子化の単体の専用メモリ(上の表)を足し、GPU の容量に収まるかの目安にする
  3. 起動後に、GPU 全体の使用量と共有 GPU メモリを確かめる
  4. 文脈設定を4096 から変える場合は、この記事の値の範囲外(未測定)

品質: 同じ8問を3回ずつ解かせた

3つの量子化で合否が分かれたのは、q7 の2本だけ。ほかの課題は3つとも同じ結果でした。

  • q1 抽出JSON:お知らせから日付・時刻・場所などを取り出して JSON で出す
  • q2 要約:図書館の夜間貸出の記事を、40字以内の3行に要約する
  • q3 条件つきの文:システム障害のお知らせを、150字以内・です・ます・必須の4項目つきで書く
  • q4 注文JSON:注文文を JSON にし、合計金額(9,800円)も計算して入れる
  • q5 計算:りんごとみかんの代金から10%引いた支払額(3,960円)を求め、考え方も書く
  • q6 推論:3人の傘の色を、手がかりから当て、考え方も書く
  • q7 Python:英単語を数えて上位 n 個を返す関数を書く(テスト5件)
  • q8 JavaScript の修正:平均を返す関数のバグの原因を1〜2文で説明して直す(テスト8件)
  • 採点:q7・q8 はコードのテスト、q1・q4 は値と形式の機械判定
  • q2・q3・q5・q6 と q8 の説明は、決めておいた基準による1本ずつの理由つき判定。完全な機械採点ではない

llama.cpp・思考 OFF(量子化3つ)

課題Q4_K_MUD-Q4_K_XLUD-Q3_K_XL
q1 抽出JSON3(3)3(3)3(3)
q2 要約0(0)0(0)0(0)
q3 条件つきの文0(0)0(0)0(0)
q4 注文JSON0(0)0(0)0(0)
q5 計算3(3)3(3)3(3)
q6 推論3(3)3(3)3(3)
q7 Python3(3)3(3)1(1)
q8 JavaScript3(0)3(0)3(0)
合計15(12)
/24
15(12)
/24
13(10)
/24

数字は3回のうちの正答数、かっこ内は指定条件まで合格した数。72本すべて最終回答が正常に返り、採点から外した回答はない。

  • q1・q5・q6 は3つとも指定条件まで 3/3。q5 は9本とも 3,960円に到達
  • q8 はコードが9本ともテストに通ったが、説明まで含めると0本

間違えたところ

9本とも落ちたのは q2・q3・q4。q7 は UD-Q3_K_XL の2本だけが誤り、q8 は説明が基準に届きませんでした。

q2 要約:9本とも不合格

  • 9本とも、夜間の時間(19〜22時)が入っていない
  • 9本とも、判断材料のトラブル件数と「来年度から本格導入するかを判断する」がそろわない
  • UD-Q4_K_XL と UD-Q3_K_XL の各1本は、IC カードで入館する点も欠けた
  • 今回選んだ要点での判定で、唯一の正しい要約という意味ではない

q3 条件つきの文:9本とも不合格(判断に迷い、厳しい側で判定)

障害の時刻・対象・原因を調査中であることは、9本とも正しい内容。落ちたのは次回の報告の書き方です。

  • 「復旧の目途が立ち次第」など、条件付きの報告になっていた
  • 目途が立たない場合も12時までに報告するのかが読み取れない
  • 意味の判断に迷うものは不合格とする規定で、内容も不合格

q4 注文JSON:合計金額が9本とも 7,820円

顧客名・品目・数量・単価は9本とも正しい。合計金額は正しくは 9,800円で、9本とも 7,820円と回答。思考 ON では3本とも正解でした(後述)。

q7 Python:UD-Q3_K_XL の2本が 4/5

不合格は UD-Q3_K_XL のシード23・37 の2本。どちらも同じテストケース top_words("a1b2 a", 5) で落ちました。

対象返り値
期待値[('a', 2), ('b', 1)]
UD-Q3_K_XL(シード23・37)[('a', 1), ('ab', 1)]
  • 空白で分けたあと英字だけを残す作りで、数字を単語の区切りとして扱っていない
  • 前回の LFM3-1.7B QAD 版 Q4_0(シード11・37)と同じテストケース・同じ返り値
  • 2本ともほかの4件は合格。シード11 は 5/5。時間切れや環境の失敗は0件

q8 JavaScript:コードは9本とも合格、説明まで含めると0本

修正したコードは9本ともテスト8件に全部合格。指定条件は3つとも 0/3 です。

  • 範囲外の添字で undefined が足される説明はあった
  • 空の配列で0を返す必要の説明が、コードの外にない(コード内の分岐だけでは説明とみなさない)

思考 ON の損得(Q4_K_M)

思考 ON で正答は15本から18本に増え、指定条件まで合格は12本から11本に減りました。答えまでの時間は大きく延びています。

同じ Q4_K_M の起動のまま、OFF の24本のあとに ON の24本を送信した結果です。

条件生成の中央値答えまでの中央値q1〜q6q1〜q8
思考 OFF58.048 tok/s2.255秒9(9)/1815(12)/24
思考 ON57.453 tok/s11.035秒12(11)/1818(11)/24
  • 24本とも正常に終了。長さの上限で止まった回答(length)は OFF・ON とも0本
  • ON の生成速度は思考の分を含む値で、最終回答だけの速度ではない
  • ON は24本とも思考の欄(reasoning_content)に文章があり、回答本文に思考の印はない
  • 例:q1 シード11 の出力トークンは OFF 80・ON 727、答えまでは 2.139秒・13.521秒
  • ON 区間の GPU 全体の最大は 5,721 MiB(+3,475)。単体の専用メモリ最大は OFF と同じ 3,468.887 MiB
課題思考 OFF思考 ON
q1 抽出JSON3(3)3(3)
q2 要約0(0)0(0)
q3 条件つきの文0(0)0(0)
q4 注文JSON0(0)3(3)
q5 計算3(3)3(2)
q6 推論3(3)3(3)
q7 Python3(3)3(0)
q8 JavaScript3(0)3(0)
合計15(12)
/24
18(11)
/24
  • q4 は ON で3本とも合格。合計金額 9,800円を正しく出した
  • q5 シード23 は答えと式は正しいが、説明の「10%(0.9倍)」で10%と90%を取り違え、指定条件は不合格
  • q7 は3本ともテスト 5/5。ただし3本ともコードブロックの囲みがなく、応答全体が素のコードだった
    • 課題の指定は「コードブロック1つだけを出力」で、指定条件は不合格。思考 OFF の q7 9本はすべてコードブロック1つ
  • q2・q3 は ON でも3本とも不合格。q8 の説明も OFF と同じく基準に届かない

DFlash(投機的デコード)は測れなかった

drafter を付けて起動すると、共有 GPU メモリへのはみ出しが出ました。手順どおり速度・品質の測定は省略し、速くなるかどうかは未測定です。

DFlash は、モデルカードで投機的デコード用に案内されている drafter(下書きを出す側のモデル)。

  • 本体:Q4_K_M、上と同じ設定(全層 GPU、文脈設定4096)
  • drafter:dflash-NVIDIA-Nemotron-3.5-Bolt-E4B-Q8_0.gguf(398,892,256 bytes)
  • 追加の指定:--spec-type draft-dflash、--spec-draft-n-max 7、--spec-draft-ngl 99
  • モデルカードの手順例は BF16 の drafter で、今回とは別のファイル
構成・区間専用メモリの最大共有 GPU メモリの最大判定
drafter なし(8問×3回)3,468.887128少量
drafter 付き(読み込み)4,255.93654あり
drafter 付き(暖機)4,286.395892あり
  • 単位は MiB。llama-server のプロセス単位の値(Windows のカウンタ)
  • ロードは 60.75秒(drafter なしの Q4_K_M は 46.421秒)。どちらも起動時の実測で、ファイルキャッシュは未制御
  • 暖機区間の GPU 全体の最大は 5,649 MiB(直前の待機は 2,364 MiB)
  • 生成速度・品質・drafter の採択率は未測定
DFlashのdrafterを付けてllama-serverを起動した時点の画面。専用GPUメモリ5,536 MiB、共有GPUメモリ823 MiB(GPU全体、Windowsのカウンタ)と、llama-serverのログ。
DFlash の drafter を付けて起動し、はみ出しを確認した時点(2026年11月2日 0時32分)の値。表示は GPU 全体の専用 5,536 MiB・共有 823 MiB。プロセス単位の共有 GPU メモリは暖機後に 892 MiB。

前回の LFM3-1.7B・MiniCPM5-2B との比較

数字の上では、tok/s は前回の2モデルのほうが大きい結果です。条件とモデルの大きさが違うため、倍率や順位は付けません。

前回記事は「LFM3-1.7BをVRAM 6GBで実測|Q4_K_Mで約152 tok/s」と「MiniCPM5-2BをVRAM 6GBで実測|約115 tok/s、同じ8問で1Bより正答が増えた」。

  • モデルの大きさ:今回は総8B・実効4B(読み込みログの表示 7.52 B)、前回は 1.7B と 2B
  • トークナイザー:モデルごとに違うため、tok/s は「同じ文章を何倍の速さで出せるか」を表さない
  • llama.cpp の版:今回と LFM3-1.7B は b12005、MiniCPM5-2B は b11574。版による差は未確認
  • VRAM の観測:今回と LFM3-1.7B は外部の nvidia-smi で1秒おき、MiniCPM5-2B は測定の中で2秒おき。どれも GPU 全体
  • 待機:今回は 1,486〜2,246 MiB、LFM3-1.7B は 1,794 MiB、MiniCPM5-2B は 1,804 MiB
  • 採点:前回2モデルの数字は前回記事の値で、今回の基準での再採点はなし
構成生成の中央値(tok/s)GPU 全体の最大(増加)q1〜q8 正答(指定条件)/24
Bolt E4B Q4_K_M(今回)58.0485,702(+3,456)15(12)
Bolt E4B UD-Q4_K_XL(今回)55.1915,259(+3,764)15(12)
Bolt E4B UD-Q3_K_XL(今回)55.7384,435(+2,949)13(10)
LFM3-1.7B Q4_K_M(前回記事の値)152.133,045(+1,251)15(9)
LFM3-1.7B QAD 版 Q4_0(前回記事の値)152.012,991(+1,197)16(12)
LFM3-1.7B Q8_0(前回記事の値)107.083,806(+2,012)18(12)
MiniCPM5-2B Q4_K_M(前回記事の値)114.593,459(+1,655)13(7)
MiniCPM5-2B Q8_0(前回記事の値)81.204,395(+2,591)13(7)
  • VRAM の単位は MiB(GPU 全体、画面表示分を含む)。品質はどれも思考 OFF
  • q4 の合計金額は、前回の2モデルも思考 OFF で全部不合格。今回は思考 ON の3本だけ正解
  • q5 の計算は今回と LFM3-1.7B が全部正解、MiniCPM5-2B は全部不正解
  • q3 は MiniCPM5-2B が指定条件まで各 3/3、今回は9本とも不合格
  • q8 は3モデルとも、説明まで含めると0本

この結果から言えること

  • VRAM 6GB の GPU をすでに持っている人:画面表示と兼用でも、3つとも全層 GPU で動いた
    • 速さなら公式の Q4_K_M。正答数は Q4_K_M と UD-Q4_K_XL が同じ
    • GPU 全体の余裕がいちばん大きいのは UD-Q3_K_XL。ただし q7 で2本落ちた
    • ファイルが小さい UD-Q4_K_XL でも、単体の VRAM は Q4_K_M より大きかった
  • 画面表示と兼用している人:表示などで使われる量が、そのまま GPU 全体に上乗せされる
    • 今回は待機の量が測定中にも変わった
    • 起動前に使われている量を確かめてから、量子化を選んでください
  • 思考 ON を使うか迷う人:今回の8問では正答が増え、q4 の合計金額は ON でだけ正解した
    • 答えまでの時間は大きく延び、q7 では形式の指定を外した
    • 応答の速さを優先するなら OFF が候補
  • 計算やコードを試したい人:q5 の計算は全部正解、q7・q8 のコードも多くがテストに通った
    • q8 の説明は基準に届かず、UD-Q3_K_XL の q7 には誤りが2本あった
    • 生成されたコードは、テストで確かめてから使ってください
  • LFM3-1.7B・MiniCPM5-2B を使っている人:tok/s は前回の2モデルのほうが大きい
    • q4・q5 など課題ごとの得手不得手も違うので、用途に近い問題で両方を試してから決めてください
  • より大きなモデルを試したい人:「4GB」の名前が付いた今回のモデルは 6GB でも全層 GPU で動き、より大きいモデルなら VRAM 12GB が次の段階
    【PR】RTX 3060 12GB での動作は、検証ラボでは未実測
    GIGABYTE GV-N3060WF2OC-12GD:Amazonで見る(未実測)/楽天市場で見る(未実測)/Yahoo!ショッピングで見る(未実測)
  • PCごと買い替えるなら:新品の BTO パソコンと、中古のゲーミング PC の2つの選択肢
    • どちらも、VRAM の容量と画面表示で最初から使われる量を確かめてください
    【PR】新品の BTO パソコン・中古のゲーミング PC とも、検証ラボでは未実測
    新品の BTO なら:【OZ GAMING】
    予算を抑えるなら中古:GP-ZEROで中古ゲーミングPCを見る

注意点と、測っていないこと

  • 検証環境の表の1台で、1晩・各条件1回の結果。llama.cpp も b12005 の1つの版だけ
  • 品質はこの8問・3つのシード・この採点基準での結果。3回は出力の揺れを見る繰り返しで、24個の別々の課題ではない
  • 量子化どうし、思考 OFF と ON の差は、統計的な差とは言えない
  • 文章の意味の判定は、判断が分かれそうなものを厳しい側(不合格)にした
  • 生成条件はモデルカードの推奨ではない(検証環境と条件の節)。推奨の条件での結果は未確認
  • 各節に書いた測定上の注意
    • q7・q8 は別の Linux 機でテスト(検証環境と条件の節)
    • VRAM の測り方(NVML は不使用)と、待機の値が量子化ごとに違う点(VRAM の節)
    • ロード時間は OS のファイルキャッシュ未制御(速度の節)
  • テンソルごとの置き場所(CPU 側か GPU 側か)は、ログで未確認
  • 文脈設定は4096 だけ。ほかの文脈設定・長い文章・Ollama での実行は未測定
  • 思考 ON は Q4_K_M だけ。DFlash は速度・品質とも未測定

書いた人

シュン

現役SE、ローカルAIラボ運営。AIコーディング・AIサービス比較・ローカルLLM・業務自動化を、実務目線で実際に使って検証・比較しています。

コメント

タイトルとURLをコピーしました