Granite 4.2の3B・8B・30B、自分の機材にはどれが合う？

IBMが公開するGranite 4.2の推論モデルは3B、8B、30Bのサイズがあり、すべてdense構造です。入力に応じて一部の専門家だけを選ぶMoE¹ではなく、密なパラメーター経路を使います。3モデルともthinking modeとtool callingに対応し、Apache 2.0ライセンスで公開されています。共通機能に対応していても、必要なメモリや問い合わせへの適合性が同じとは限らないため、各モデルを試します。

最初の比較では、返品期限、開封状況、付属品の条件を見つけて1～2文で答えるよう頼みます。同じ質問と原文を3B・8B・30Bに渡し、必要な条件を落としたか、根拠にない内容を加えたか記録します。この小さな作業を固定すると、モデル名や応答速度ではなく仕事に影響する差を見られます。

短い規定文から返品期限と条件を探させ、チームが実際に使う表現を反映した質問を10個、同じ順序で用意します。回答ごとに必須条件の抜けや、原文にない断定がないか記録します。IBMのモデルカードには韓国語が試験言語として含まれていますが、社内の商品名・略語・古い案内文まで検証済みという意味ではありません。

たとえば社内用語の「付属品セット」を別の商品と解釈するなら、同じ表現を複数の質問に含めて誤りが繰り返すか確認します。担当者は回答の根拠文を案内の原文と照合します。3Bが必要条件を安定して拾い、修正負担も小さいなら、大型モデルへ移る必要はまだないかもしれません。結果が曖昧なら質問と基準回答を保存し、次の候補にもそのまま使います。

IBMは8Bと30Bについて、コード編集、ターミナル、検索などのツールを使うエージェント作業を追加学習したと説明しています。返品問い合わせでは、根拠の検索、要点整理、回答案作成のどの段階で止まるか確認します。ツール使用の学習はカスタマーサポートアプリへの自動接続を意味しないため、各段階の入力と結果を調べます。

実行環境がモデルのチャットテンプレートとtool call²形式に対応し、検索やチケット作成ツールへのアクセス権限も別途設定されている必要があります。同じ問い合わせを8Bと30Bに渡し、実行環境が理解できる形式で呼び出されるか、ツール実行後に根拠が回答へ反映されるか確認します。モデルがツール使用を提案することと、実行環境が実際に検索することは別の段階です。

BF16³の重み1つを2バイトとして計算すると、300億個の重みには30,000,000,000×2=60,000,000,000バイト、約60GBが必要です。4bitで単純計算すると約15GBです。どちらも重みだけの理論上の下限であり、モデルの実行に必要な総メモリではありません。

実行中は形式の付加情報、buffer、文脈に応じて増えるKV cache⁴、OSや他のアプリの使用量も加わります。そのため、24GBの機器で4bitファイルを開けるというだけで、長い問い合わせ文書まで余裕を持って処理できるとは判断しません。実際のモデルファイル、実行環境、問い合わせの長さを決め、普段のアプリを開いた状態で検索から回答完了まで動くか試します。CPU⁵ offload⁶により実行は完了しても遅くなる場合があるため、メモリ使用量、log、最初のtoken⁷、完了時間も確認します。

IBMは基本文脈128Kと512Kへの拡張を案内しています。長い入力には実行ツールの拡張設定とメモリ余裕が必要です。短い返品案内は全体を入力できますが、複数の規定を含む長いファイルでは無関係な部分も処理し、回答開始が遅れる場合があります。

入力が長いほど最初の回答前に処理するtokenが増え、KV cacheにも影響します。複数ページから開封・付属品・期限の条件を探すなら、全文入力と関連箇所だけを検索して渡す方法を比較します。検索では文脈を減らせますが例外を見逃すことがあるため、選ばれた箇所に担当者が必要とする根拠が含まれているか確認します。質問と根拠文を固定し、最初のtokenまでと回答生成の時間を分けて記録すると、入力範囲や実行設定を調整する材料になります。

Granite 4.2にはthinking、non-thinking、短く考えるlow-effort modeがあります。規定の一文から条件を探す作業と、複数の例外が関わる問い合わせでは必要な推論が異なります。モデルと質問を固定し、modeだけを変えて、回答が重要な条件を保つか、所要時間とともに比較します。

BF16の原版と4bit変換版ではメモリや品質の条件が同じではありません。変換ファイルは配布元や量子化⁸方式で異なるため、ファイル名だけから回答品質や速度倍率を決めません。model ID、ファイル形式、実行環境、文脈長⁹、thinking mode、同じ10件の問い合わせを記録し、どの条件を変えたか残します。品質や時間が変わったとき、量子化・mode・実行設定のどれが要因か調べられます。

3Bが短い問い合わせには十分でも複合条件を繰り返し落とすなら、同じ質問で8Bが誤りを減らすか確認します。実際にツールを使う作業が8Bで止まり、30Bで根拠と結果が改善するなら、そのモデルに必要なメモリ構成を検討できます。3モデルの差がサポート業務の結果を変えないなら、大型機器を必要とする理由も明確ではありません。

最終比較にはmodel ID、ファイル形式、実行環境、文脈長、mode、質問セット、修正が必要だった回答を記録します。韓国語の用語、tool calling、長い文脈のどれが不足しているか分かれば、機器交換より案内文の整理や検索方法の改善が適切な場合もあります。一般的な機器速度表をGranite 4.2専用の測定結果として扱わず、実作業で繰り返す失敗が大型モデルで減るか確認して選びます。