17.7GBのQ4_K_Mを見て、「24GB GPUなら余裕、16GBでも少し工夫すれば動く」と考える人は多いでしょう。

‍

前半は条件付きで正しく、後半は注意が必要です。

推論時に使うメモリは重みだけではなく、KVキャッシュ、計算用バッファ、ランタイム、OSや画面出力まで含むからです。

‍

IBMのGranite 4.2 30Bは、長文、コード、企業利用を意識した約30B規模のDenseモデルです。

‍

公式ドキュメントではGranite 4.2系列がネイティブ128Kコンテキストに対応し、30Bは512Kまで拡張可能とされています。

ライセンスはApache 2.0です。

オープンな30Bを自社環境で試したい企業にとって魅力的ですが、最大文脈長を常用するには重み以上のメモリ設計が必要になります。

‍

本稿は、公式GGUFのファイル容量を起点に、16GB・24GB・32GBでどの量子化から始めるかを整理します。

さらに、NVIDIA向けのNVFP4／MXFP4とApple Siliconで語られるMLXを同列に扱わず、対応ランタイムを含めて選ぶ視点を示します。

表中の容量は公式値、推奨構成は公開情報と一般的な推論メモリの構造を踏まえた編集上の判断です。

Granite 4.2には複数サイズがあり、30Bは大きなDenseモデルです。

‍

MoEのように一部の専門家だけを選んで計算する構造ではないため、推論時には基本的に全重みを扱います。

量子化後のファイルが17.7GBなら、モデルの主要部分だけでそれに近いメモリを使うと考えるのが出発点です。

‍

企業導入で注目される理由は、長文仕様、コードや文書タスク、Apache 2.0という組み合わせにあります。

Apache 2.0は商用・研究用途で広く使われるライセンスですが、モデル出力の正確性、個人情報、第三者の権利までIBMが保証するものではありません。

導入組織はライセンス表示と利用ポリシーを別々に確認する必要があります。

‍

公式ドキュメントは系列全体で128Kをネイティブコンテキストとし、30Bは512Kへの拡張を示しています。

「ネイティブ」は学習・設計上の基準、「拡張」は追加設定で到達し得る上限と理解するとよいでしょう。

512K入力で常に同じ品質が出る、あるいは単一GPUに収まるという保証ではありません。

検索拡張生成なら、文書全体を詰め込む前に検索精度とチャンク設計を改善する余地があります。

‍

モデルカードやHugging Faceの表示では、量子化リポジトリのパラメータ数が元モデルと異なる見え方をする場合があります。

例えばNVFP4の保存表現を元のDenseモデルの規模変更と解釈してはいけません。

形式は重みの表現方法であり、別の17Bモデルになったわけではありません。

記事では「30B Denseの量子化版」と説明するのが安全です。

公式GGUFリポジトリには、10.9GBのQ2_Kから58.6GBのBF16まで選択肢があります。

精度を上げるほどファイルは大きくなり、通常は量子化誤差が減ります。ただし、実際の品質はタスクに依存します。

コード補完、JSON出力、長い日本語文書の要約では、同じ量子化でも失敗の種類が違うため、業務に近い評価セットで比べる必要があります。

16GBでQ3_K_Lの15.3GBを選ぶと、ファイルは数字上収まっても残りは約0.7GBです。

GPUドライバ、計算用バッファ、KVキャッシュを考えれば、全レイヤーをVRAMへ載せる余白はほぼありません。

Q3_K_Mの14.1GBも長文には慎重さが必要です。

動かすだけならCPUオフロードや一部レイヤーの分割ができますが、転送が速度を下げる可能性があります。

‍

24GBではQ4_K_Mの17.7GBが品質と余白の均衡を取りやすい候補です。

一方、Q6_Kは24.0GBなので、ファイルがVRAM容量と一致しても実運用には収まりません。

32GBではQ6_Kが候補になりますが、31.1GBのQ8_0は同じ問題を抱えます。

製品の公称VRAMを「モデルファイルを置ける箱」とだけ捉えず、処理中の余白を先に引くべきです。

‍

Macのユニファイドメモリでは、CPUとGPUが同じ領域を共有します。

32GB Macでも32GBすべてをモデルへ渡せるわけではありません。

macOS、画面、他のアプリが使う分を差し引き、メモリプレッシャーとスワップを監視します。

NVIDIA GPUの32GB VRAMと、Macの32GBユニファイドメモリを同じ欄で性能比較するのは適切ではありません。

16GB VRAMではQ3_K_Mを短い文脈で試すのが現実的です。

‍

Q4が必要なら、一部をCPUへオフロードする構成になります。

モデルを完全にGPUへ載せた場合より速度が落ちる可能性があるため、短いコード補助や分類など、待ち時間を許容できるタスクで評価します。

Q2は余白を作れますが、品質低下が目的の仕事に耐えるかを確認してください。

‍

24GBの第一候補はQ4_K_Mです。8Kから始め、32Kへ伸ばした時のピークVRAMと初回応答時間を測ります。

Q5_K_Mは20.8GBで重み以外の余白が狭くなるため、短文で品質差が明確な場合だけ採用する考え方が堅実です。

24GBだからQ6を選ぶ、という決め方は避けます。

‍

32GBではQ5_K_MまたはQ6_Kから始められます。

長文を重視するなら、量子化を一段下げてKVキャッシュへ余白を回す方が総合的に安定する場合があります。

Q8_0は31.1GBなので、短い比較ベンチマークには使えても、単一32GB GPUで長文を常用する構成としては余裕がありません。

表の開始値は保証値ではありません。

ランタイムのKVキャッシュ精度、バッチ、同時実行、GPUオフロード、ドライバで変わります。

同じプロンプトセットを使い

① ロード後の使用量

② 8K入力後のピーク

③ 生成中の速度

④ 32Kへ伸ばした時の増分

⑤ エラーやスワップの有無を記録

‍

ファイルサイズだけの早見表から一歩進み、増分を測ることが運用設計につながります。

KVキャッシュは、過去のトークンに関する注意機構の計算結果を保持し、次のトークン生成を効率化する領域です。

‍

一般にコンテキストが長くなるほどほぼ線形に増え、同時実行数を増やせばセッション分が必要になります。

重みの量子化が4bitでも、KVキャッシュが同じ4bitとは限りません。ランタイムの既定精度を確認してください。

‍

128Kは約13万トークンを扱える仕様ですが、日本語の文字数とトークン数は一対一ではありません。

PDFを大量に連結すると、本文以外のヘッダー、表、OCR誤りもコンテキストを消費します。

長文をそのまま入れる前に、文書の前処理、重複除去、検索、要約を組み合わせた方が回答精度と費用対効果を高めやすくなります。

‍

512Kは30Bで拡張可能とされていますが、実用には三つの検証が必要です。

第一にメモリへ収まるか

第二に初回応答までの時間が業務許容内か

第三に長い入力の必要箇所を正しく参照できるか

‍

最大長へ到達したこと自体は、中央部の情報を取り出せることや、事実関係を保てることを意味しません。

‍

KVキャッシュの正確な必要量は、モデル構成、層数、KVヘッド、精度、ランタイムで決まります。

記事で固定のGB数を断定するより、使用するソフトのメモリ表示とGPU監視ツールで8K、32K、128Kの増分を測る方が確実です。

測定値から線形性を確認し、安全マージンを加えて上限を設定します。

運用では入力最大値だけでなく、同時セッション数にも制限を設けます。

GGUFはllama.cpp系のエコシステムで広く使われ、CPU推論、GPUへの部分オフロード、複数OSでの検証に向きます。

‍

手元のPCでまず動作確認するなら分かりやすい入口です。

公式GGUFリポジトリに容量一覧があるため、メモリ計画も立てやすいでしょう。

‍

NVFP4とMXFP4は、低ビット浮動小数点表現を対応ハードウェアと推論ランタイムで効率よく使うための形式です。

‍

IBMはGranite 4.2 30BのNVFP4リポジトリを公開し、vLLMやSGLangの例を示しています。

ただしGPU世代やソフトウェア版によって対応状況が異なります。

「4bitだからGGUF Q4と同じ容量・速度・品質」とは考えず、公式の対応表と実行例を確認してください。

‍

MLXはApple Silicon向けのフレームワークです。

‍

コミュニティ量子化が見つかる場合でも、IBM公式配布か、変換者、元コミット、量子化方式、チャットテンプレートを確認します。

2026年8月28日時点の調査では、IBM公式の30B GGUFとNVFP4は確認できた一方、30Bの公式MLX配布は公開直前に再確認すべき項目です。

非公式版を本番へ入れる場合は、ハッシュと再現手順を保存します。

‍

形式選びは、使うハードウェア、ランタイム、必要な文脈、運用チームの保守能力で決めます。

‍

NVIDIA環境で対応条件を満たすならNVFP4／MXFP4、CPUや混載で柔軟性を優先するならGGUF、Apple SiliconでMLX対応版の出所を確認できるならMLXが候補です。

変換形式を変えるたびに、同じ評価セットとチャットテンプレートで品質を再確認します。

‍

企業利用では、モデルを動かすだけでなく、モデルカード、量子化ファイル、ランタイム、ドライバを一つの構成として版管理してください。

更新時にどこが変わったか分からなければ、精度低下や速度変化を追跡できません。

長文機能は魅力ですが、必要な情報だけを取り出す検索設計と、出典を回答へ残す仕組みを先に整える方が、監査可能性を高めます。

Granite 4.2 30Bの必要スペックは、「Q4が何GBか」だけでは決まりません。

‍

公式GGUFのQ4_K_Mは17.7GBなので16GB VRAMには重みだけでも収まらず、24GBでは短〜中程度の文脈を試せる余地があります。

32GBではQ5_K_MやQ6_Kが候補ですが、Q8_0は31.1GBのため長文用の余白が乏しくなります。

‍

128Kはネイティブ、512Kは拡張という仕様を、常用可能な文脈長と混同しないことが大切です。

まず8Kまたは16Kでタスク品質とメモリを測り、32K、128Kへ段階的に伸ばします。

品質差が小さいなら量子化を一段下げ、KVキャッシュと同時実行の余白を取る方が安定します。

‍

推奨の出発点は、16GBでQ3_K_M、24GBでQ4_K_M、32GBでQ5_K_M〜Q6_Kです。

これは保証ではなく、検証を始めるための基準です。

GGUF、NVFP4、MXFP4、MLXは対応環境が違うため、公式リポジトリとランタイム版を確認し、同じ日本語・コード・文書タスクで比較してください。