「3Bなら古いノートPCでも余裕で動く」と考えると、ローカルLLMでは判断を誤りやすくなります。
モデルのパラメータ数が小さくても、実行時にはモデル本体だけでなく、会話履歴を保持するKVキャッシュ、ランタイム、OS、場合によってはGPU側の作業領域も必要になるからです。
IBMが公開したGranite 4.2 3Bは、Granite 4.2ファミリーの最小モデルです。
公式説明では、3B、8B、30Bのdense reasoning modelが用意され、3Bはedge deploymentやresource-constrained environmentsを意識した位置づけです。
日本語を含む複数言語がテスト対象に入り、thinking、tool calling、structured JSONなどにも対応します。
この記事ではベンチマーク順位ではなく、「手持ちPCでどの設定から試すか」を判断できるようにします。
特に4GB、8GB、16GBという数字は、RAMなのかVRAMなのかで意味が大きく変わります。
以下では両者を分けて考えます。
Granite 4.2はIBMのオープンな言語モデル群で、3B、8B、30Bが公開されています。
3Bは約3.66Bパラメータの小型モデルで、OllamaではBF16版が約7.3GBとして配布されています。
一方、GGUFではQ4などの量子化を選ぶことでモデル本体の容量を大幅に抑えられます。
ここで30B版の記事と混同しないことが大切です。
IBM公式ドキュメントでは、Granite 4.2各モデルのネイティブコンテキストは128Kで、512Kへのlong-context extensionは30Bモデルについて記載されています。
したがって、3Bを低スペックPCで使う際に「512Kまで使える」ことを前提にメモリ計算するのは適切ではありません。
また、小型だから品質が一定というわけでもありません。
thinkingを有効にすると複雑な推論に向きますが、出力トークンが増えやすく、待ち時間も伸びます。
低スペック環境では、短いコンテキストと必要なときだけthinkingを使う方が扱いやすいでしょう。
GGUF量子化は、モデルの重みをより少ないビット数で表現し、必要メモリを減らす方法です。
数字が小さいほど軽量化しやすい一方、情報量も削られるため、品質低下との交換になります。
Q4にもQ4_K_S、Q4_K_Mなど複数方式があります。
ファイル容量だけで「Q4なら同じ」と考えず、配布元が推奨するタグとランタイムの対応を確認してください。
Ollamaではgranite4.2の3B向けに複数の量子化タグが公開されており、公式GGUFはHugging Faceからllama.cppで直接取得できます。
必要メモリは固定値ではありません。
そこで「最低○GB」と断定するより、モデル本体に加えて何が載るかを考える方が再現性があります。
4GB RAMのWindows PCでは、OS自体の使用量を考えると「3Bだから問題なく動く」とは言えません。
一方、4GB VRAM＋十分なシステムRAMなら、一部または多くの層をGPUへオフロードする構成が可能です。
同じ「4GB」でも結論が逆になる理由です。
llama.cpp系ランタイムでは、GPUがなくてもCPUでGGUFを実行できます。
古いノートPCでも起動できる可能性はありますが、快適さはCPU世代、コア数、メモリ帯域、量子化方式に左右されます。
GPUオフロードは、モデルの一部または全部の計算をGPUへ移す方法です。
VRAMに全モデルが収まらなくても、載る範囲だけGPUへ渡せるため、「VRAMがモデル容量より小さいからGPUは使えない」とは限りません。
ただしCPUとGPUをまたぐ構成では転送の影響もあり、全層GPU実行と同じ速度にはなりません。
初心者は、まず短いプロンプトで起動と応答を確認し、その後にコンテキスト長、GPUオフロード量、thinkingの有無を一つずつ変えると原因を切り分けやすくなります。
ローカルLLMでは、モデルファイル以外にKVキャッシュが必要です。
会話履歴や入力文が長くなるほど、この領域は増えます。
したがってQ4のモデル本体が数GBに収まっても、最大コンテキストを最初から確保すると、低メモリPCでは起動失敗やスワップの原因になります。
Granite 4.2 3Bは公式上128Kコンテキスト対応ですが、「対応」と「低スペックPCで128Kを快適に使える」は別です。
8GB RAMのPCで日常チャットをするなら、まず4K〜8Kなど現実的な長さから始め、必要に応じて増やす方が安全です。
長文資料を扱う場合も、いきなり最大値にせず、RAGや文書分割を含めて設計した方がメモリ効率を保ちやすくなります。
最も手軽なのはOllamaです。
公式ライブラリにはgranite4.2の3Bタグがあり、コマンドから取得して実行できます。
量子化を明示したい場合は対応タグを選びます。
LM Studioでは対応モデルを検索し、GGUFまたはApple Silicon向けMLX版を選択します。
モデルをロードする前にコンテキスト長とGPUオフロード設定を確認し、低メモリ環境では控えめな値から始めてください。
llama.cppを直接使う場合、IBM公式GGUFページにはHugging FaceからQ4_K_Mを指定してllama serve／llama cliで起動する例があります。
細かな設定を調整したい人には最も自由度があります。
導入後は「起動したか」だけで終わらせず、日本語で
① 短い要約
② 情報抽出
③ 簡単なコード
④ thinkingを使う推論の4種類を試してください。
用途によって最適な量子化は変わります。
8GB RAMのGPUなしPCなら、Q3〜Q4級、短いコンテキスト、thinkingを必要時だけ有効にするところから始めるのが現実的です。
16GB RAMならQ4を基準に、品質を上げたい場合にQ5〜Q8を比較しやすくなります。
4〜8GB VRAMを持つPCではGPUオフロードを使い、VRAMを使い切らない設定にすると安定しやすいでしょう。
失敗しやすいのは、
① モデル容量だけで必要メモリを決める
② 最大コンテキストを最初から設定する
③ RAMとVRAMを混同する
④ 量子化の品質差を確認しない
⑤ 1回の速度だけでPC適合を判断する
ローカルLLMは同じモデルでも設定で体験が大きく変わります。
PCを買い替える前に、まずQ4・短いコンテキストで実測し、速度不足なのかメモリ不足なのかを切り分けるのが合理的です。
Granite 4.2 3Bは、Granite 4.2の中では低スペックPCで試しやすいモデルです。
ただし「3Bだから4GB RAMでも快適」という意味ではありません。
GGUF量子化でモデル本体を小さくできても、OS、KVキャッシュ、ランタイム、コンテキスト長の余白が必要です。
最初の基準としてはQ4前後を選び、8GB RAMなら短いコンテキスト、16GBなら余裕を持って比較、GPUがあればオフロードを試す。
この順番なら、手持ちPCの限界を把握しやすくなります。
なお3Bの公式コンテキストは128Kであり、30B向けの512K拡張と混同しないようにしてください。
.png){kind=logo}
