小型言語モデル（SLM）は、決まったパラメーター数以下のモデルを指す厳密な規格ではなく、対象業務に必要な品質を保ちながら、手元のCPU・GPU・メモリで継続運用できる比較的小規模な言語モデルです。選定の要点は「小さいか」ではなく、同じ入力条件で大型候補と比べたときに、重要な誤りを増やさず、応答時間と資源上限を守れるかにあります。本稿を読み終えた時点で、候補モデルを採用、限定採用、見送りのいずれかへ振り分けられる状態を目指します。
業務判断に使えるSLMの定義
SLMの「small」は相対語です。数十億パラメーターでもスマートフォン向けには重く、複数GPUを備えた社内サーバーでは小さい候補になり得ます。そのため、本稿では、モデルのパラメーター数だけでなく、重みの精度、最大入力長、同時要求数、画像・音声の有無、推論エンジンを含めて小型かどうかを決めます。
たとえば3.8Bのモデルを4bit化しても、長い文書を同時に多数処理すればKVキャッシュが膨らみ、16GBのVRAMへ収まらない場合があります。逆に、短い分類を1件ずつ処理するならBF16のままでも運用できることがあります。
現行一次情報を見ると、MicrosoftのPhi-4-mini-instructは3.8Bパラメーター、128Kトークンのコンテキストを持ち、メモリ制約や待ち時間制約のある用途を想定しています。ただし同じモデルカードは、規模に由来する事実知識の限界と、個別用途での評価が必要であることも明記しています[2]。
またGoogleのGemma 4はE2Bから31Bまで複数規模を用意し、E2BとE4Bでも総パラメーター数と実効パラメーター数を分けて示しています[1]。この例からも、名称の「mini」や「E2B」だけで必要資源を断定してはいけません。
本稿での定義は「対象業務の必須品質を満たす候補のうち、許容する実行環境で最小の総資源を使うモデル」です。パラメーター数は入口の情報であり、採用結果ではありません。
選定を誤らせる四つの思い込み
小型モデルの検討では、端末で起動した瞬間に評価を終えたり、公開ベンチマークの総合点だけで業務品質を代替したりしがちです。しかし、抽出対象の項目名が似ている、否定文が混ざる、入力が長くなるといった条件は、一般ベンチマークから読み取れません。
さらに、オープンウェイトであることと、用途・再配布・派生モデルの条件が無制限であることは同義ではありません。候補ごとにモデルカード、ライセンス本文、利用規約、配布元を保存する必要があります。
| 思い込み | なぜ危険か | 評価時の訂正 |
|---|---|---|
| パラメーター数が少なければ必ず速い | 量子化方式、GPUカーネル、入出力長、バッチ処理で速度は変わる | 共通の機器・エンジン・入力長でTTFTと生成速度を測る |
| コンテキスト上限まで実用的に使える | 長文ほどKVキャッシュと待ち時間が増え、精度も一様には保たれない | 通常長、p95長、許容上限の三段階で資源と品質を記録する |
| ローカル実行なら情報管理は完了する | モデル取得、ログ、監視、バックアップ先から情報が外へ出る余地がある | 通信先、保存先、権限、削除手順をデータフローで点検する |
| 総合正答率が高ければ自動化できる | 重大誤答が少数でも、契約・金額・個人情報の処理では受け入れられない | 重要項目をハードゲートにし、平均点と別に不合格を判定する |
「小さいモデルは能力が低い」と一括りにするのも適切ではありません。入力形式が安定した分類、定型項目の抽出、候補文の短い要約では、用途を絞ったSLMが合格する可能性があります。一方、最新事実を根拠付きで答える、複数文書の矛盾を解く、法的判断を確定するといった仕事は、モデル規模にかかわらず検索・検証・人の承認を要します。
能力の有無ではなく、許可する入力範囲と出力の使い道を先に線引きしてください。
モデルがメモリを使う仕組み
推論時の主な消費先は、モデル重み、KVキャッシュ、一時的な活性値、推論エンジンが確保する作業領域です。重みだけの理論量は「パラメーター数×1パラメーター当たりのビット数÷8」で概算できます。3.8Bを例にすると、BF16なら約7.08GiB、8bitなら約3.54GiB、4bitなら約1.77GiBです。
これは3.8×109に2、1、0.5バイトを掛け、230で割った想定計算であり、実際のファイルやVRAM使用量ではありません。尺度やゼロ点などの量子化メタデータ、埋め込み、未量子化層、ランタイム領域が追加されます。
重みの理論量（GiB） = パラメーター数 × ビット数 ÷ 8 ÷ 1,073,741,824例: 3.8BをBF16で保持 3,800,000,000 × 16 ÷ 8 ÷ 1,073,741,824 = 約7.08GiB実機の必要量 = 重み + KVキャッシュ + 活性値 + エンジン領域 + 安全余裕
KVキャッシュは入力と出力のトークン数、層数、ヘッド構成、データ型、同時処理数に左右されます。Phi-4-mini-instructのモデルカードが示す128Kという上限は、128Kを日常設定にする指示ではありません[2]。業務文書のp95が6,000トークンなら、まず8,192程度で検証し、切り詰めや分割で要件を満たせるか確認します。同時要求を1から8へ増やしたときに待ち行列が伸びるなら、モデルを小さくするだけでなく、最大入力長、最大出力長、同時実行数の制限も候補です。
CPUのメインメモリとGPUのVRAMも分けて読みます。GPUへ全層を載せられない構成ではCPUへ一部を逃がせますが、メモリ転送が増えて応答が遅くなる可能性があります。端末内実行を選ぶ際は「ロードできた」を合格にせず、OSや他アプリを動かした状態でピーク使用量に20％以上の余裕が残るかを確認します。
この20％は本稿の運用提案であり、モデル提供者の保証値ではありません。
SafetensorsとGGUFの境界
モデル形式は、同じモデルを別名で保存しただけとは限りません。Hugging Face系の配布で使われるSafetensorsは、テンソルを安全かつ高速に保存するための形式で、部分読み込みにも対応します。公式文書は「pickleと対比して安全な単純形式」と説明しています[3]。
通常は設定ファイル、トークナイザー、チャットテンプレートと組み合わせ、TransformersやvLLMで読み込みます。重みが複数ファイルに分割されていても、リポジトリ全体のrevisionを固定すれば再現性を確保できます。
GGUFはllama.cpp系で使う単一ファイル中心の配布形式です。llama.cppの公式READMEは、他形式を変換してGGUFへ格納し、1.5bitから8bitまでの整数量子化を扱えること、CPU・Metal・CUDA・Vulkanなど複数バックエンドを持つことを示しています[4]。
端末配布には扱いやすい一方、誰がどの原版から、どの量子化設定で作ったかが不明なGGUFを採ると、品質差の原因を追えません。
| 利用場面 | 第一候補 | 保存する識別情報 | 見送る条件 |
|---|---|---|---|
| GPUサーバーで複数利用者へAPI提供 | Safetensorsと公式トークナイザー | モデルID、40桁revision、各ファイルのSHA-256、推論エンジン版 | 対象アーキテクチャがエンジンで未対応 |
| PCやエッジ端末で単体実行 | 出所を追えるGGUF | 原版ID、量子化名、変換ツールのbuild、GGUFのSHA-256 | 変換元・ライセンス・チャットテンプレートが不明 |
| 学習や追加学習も行う | Safetensorsの原版と別管理のアダプター | 学習コード、データ版、乱数、ベースrevision、アダプターhash | 量子化済み配布物しか残っていない |
llama.cppは更新頻度が高く、2026年7月30日時点のリリース一覧ではbuild b10184が確認できます[5]。評価記録に単に「最新版」と書くと翌日に構成が変わるため、build番号とコミットを固定します。vLLMなど別のエンジンへ同じGGUFを持ち込めるかは個別確認が必要です。
形式の互換性を推測せず、対象エンジンの対応表と起動ログで確定してください。
適する業務と大型モデルへ渡す境界
SLMが力を発揮しやすいのは、入力と出力の形を狭く定義でき、誤りを機械的または短時間で検出できる仕事です。問い合わせの担当部署分類、注文書からの固定項目抽出、禁止語の一次検知、検索クエリの書き換えなどが候補になります。生成した文章をそのまま外部公開するより、候補を作って人が選ぶ工程の方が、重要な誤りを閉じ込めやすくなります。
RAGを併用する場合も、検索結果に答えがないときは回答しない規則を評価セットへ入れます。
| 処理 | SLMへ渡せる条件 | 大型モデルまたは人へ渡す条件 |
|---|---|---|
| 文書分類 | 分類先が20以下で、複数正解と対象外を定義済み | 新カテゴリ、複数部門の責任競合、信頼度が閾値未満 |
| 定型抽出 | 元文の該当箇所を併記し、型検査が通る | 金額・日付・契約当事者の欠落、原文に候補がない |
| 短い要約 | 社内下書きで、出典文へ戻れる | 対外発表、法的解釈、複数文書の矛盾解消 |
| ツール呼び出し | 読み取り専用で、引数を許可リスト検証する | 送信・削除・発注・権限変更を伴う |
SLM・4bit量子化・vLLM・3年TCOを同じ選択肢として比べない
「SLM、4bit量子化、vLLMのどれを選ぶか」という問いには、比較する層が混在しています。SLMはモデル規模の選択、量子化は重みの表現精度、vLLMは推論サーバー、3年TCOは構成全体の費用評価期間です。まず業務品質を満たすモデルを決め、次に量子化による品質差とメモリ差を測り、最後に同時処理を支える配信方式と運用費を比べます。
| 判断対象 | 何を変えるか | 品質の見方 | GPUメモリの見方 | 同時処理への影響 | 3年TCOへの主な影響 |
|---|---|---|---|---|---|
| SLM | モデル自体の規模と能力 | 同じ業務評価セットで大型候補と比較 | 重み、KVキャッシュ、実行時領域を実測 | 一要求の使用量が下がれば余力が生まれるが、エンジンと入力長にも左右される | 必要機器、電力、評価・再学習、難案件の外部委譲費 |
| 4bit・8bit量子化 | 同じモデルの重み表現 | 非量子化版または8bit版との差分を案件別に測定 | 重み領域は減らせるが、KVキャッシュや一時領域まで同率には減らない | 空いた容量で複製数を増やせる場合があるが、対応カーネルと負荷試験が必要 | 機器費を抑える可能性と、品質再評価・互換性確認の工数 |
| vLLM | 要求の待ち行列、バッチ処理、モデル配信 | モデル品質は変えず、TTFT・TPOT・失敗率を別に測定 | モデルに加え、キャッシュ設定と同時要求時のピークを測定 | 実トラフィックの到着分布でスループットとp95遅延を確認 | サーバー、監視、更新、待機容量、障害対応の運用費 |
| 3年TCO | 技術ではなく比較期間と費用範囲 | 品質未達の案は、安価でも比較対象から除外 | 必要台数と更新余力を金額へ換算 | ピーク時の追加容量と待ち時間の損失を含める | 初期費、36か月の運用費、移行・終了費を合算 |
3年TCOの比較式：初期機器・構築費 ＋ 36か月分の電力・設置・ライセンス・監視・保守費 ＋ 評価・移行・終了費 ＋ 大型モデルやクラウドへ回す例外処理費。クラウド案も、API料金だけでなくネットワーク、監視、人の確認、移行費を同じ範囲で数えます。
品質、GPUメモリ、同時処理、TCOを一つの点数へ早くまとめると、品質未達を低価格で相殺してしまいます。最初に業務品質の最低線、次にp95遅延と同時数、最後に三年間の費用という順で足切りし、残った構成だけを比較してください。vLLMの公式ベンチマークCLIはTTFT、TPOT、ITL、E2E遅延を分けて測定できます[6]。
小型言語モデルが向かないケース
誤答一件が重大な損失へ直結し、回答根拠を別手段で確認できない業務には向きません。医療・法務・与信などの最終判断、公開前の事実確認を省いたニュース生成、自由入力からの自動送金は本稿の対象外です。また、要求品質を文章にできない、代表データを用意できない、モデルのライセンスと出所を確定できない場合は、サイズ比較へ進まず検証を見送ります。
限定採用という選択肢もあります。たとえば通常案件の70％をSLMで下書きし、信頼度が低い30％を大型モデルへ回す構成なら、全件を大型モデルへ送るより資源を抑えつつ、難しい案件を無理に処理させずに済みます。ただし70％は説明用の想定値です。実際の振り分け率は、評価セットで「SLM合格かつ自動検知可能」となった件数を総件数で割って求めます。
再現可能な実機評価の準備
比較結果を再利用するには、モデル以外の条件を固定します。推奨する最小単位は、OS、CPU、GPUとVRAM、RAM、ドライバー、推論エンジン、モデルrevision、形式、量子化名、入力・出力長、同時数、温度、乱数です。電源モードやバックグラウンド負荷も速度へ影響するため、測定中は同じ状態にします。
端末向けとサーバー向けを一つの順位表へ混ぜず、それぞれの配備先で合否を出してください。
| 項目 | 端末配備の記録例 | 共有APIの記録例 |
|---|---|---|
| OS・実行系 | Windows 11 24H2、llama.cpp b10184 | Ubuntu 24.04 LTS、Python 3.12、vLLM 0.23.0 |
| 機器 | RAM 32GB、RTX 4060 Ti 16GB、ドライバー番号を記録 | RAM 64GB、NVIDIA GPU 24GB、CUDA・ドライバー番号を記録 |
| モデル | 承認したGGUF、量子化名、SHA-256 | microsoft/Phi-4-mini-instruct、Safetensors、revision SHA |
| 生成条件 | 入力512/4096トークン、出力128、同時数1 | 入力512/4096、出力128、同時数1/4/8 |
| 品質条件 | temperature 0、同一プロンプト、同一評価120件、JSONスキーマ検査あり | |
この表のGPUや件数は、読者が記録方法を再現するための想定例であり、必要性能の保証ではありません。実際の候補が画像入力を使うなら画像の枚数と解像度を追加し、RAGなら検索結果の件数と総トークン数を固定します。
モデル配布ページの更新で重みが差し替わる可能性を避けるため、取得時にrevisionとSHA-256を残し、再評価なしでmainへ追従しない運用にします。
# 実行前に残す識別情報の例MODEL_ID=microsoft/Phi-4-mini-instructMODEL_REVISION=<承認した40桁コミットSHA>ENGINE=vllm==0.23.0INPUT_LENGTHS=512,4096OUTPUT_LENGTH=128CONCURRENCY=1,4,8DECODING=temperature_0EVAL_SET=slm-routing-ja-v1.0
メモリ・速度・品質を同じ入力で測る
測定は、ウォームアップ前後を混ぜずに行います。モデルをロードしていないアイドル時、ロード直後、短文単発、長文単発、最大同時数の五点でCPU RAMとVRAMのピークを記録します。速度は、最初のトークンまでの時間（TTFT）、一出力トークン当たりの時間（TPOT）、出力トークン毎秒、要求毎秒を分けます。vLLM 0.23.0の公式ベンチマークCLIもTTFT、TPOT、ITL、E2Eをパーセンタイル対象として扱うため、この区分ならサーバー記事の測定結果と接続できます[6]。
単発利用ではp50だけでなくp95 TTFTを見ます。共有サーバーでは同時数1、4、8で各100件以上を流し、失敗数と待ち時間を加えます。生成速度が高くても、同時数4で待ち行列が増え続けるなら容量不足です。測定結果には入力長と出力長の分布を添えます。短い入力だけで得た毎秒トークン数を、長文処理の性能として掲載してはいけません。
品質セット120件の想定内訳は、分類40件、固定項目抽出30件、根拠付き短答30件、対象外・拒否20件です。正解が一つに定まる分類は正答数÷40、抽出は必須フィールド単位の適合率と再現率、短答は二名の評価者が0〜2点で採点します。拒否20件では、答えてはいけない入力へ回答した件数を数えます。
顧客名、金額、否定、単位を誤るケースは重大誤答として別集計し、総合点で相殺しません。
| 測定項目 | 合格条件の例 | 候補A | 候補B |
|---|---|---|---|
| VRAMピーク | 最大負荷でも搭載量の80％以下 | 実測値を記入 | 実測値を記入 |
| p95 TTFT | 同時4件・通常入力で1.5秒以下 | 実測値を記入 | 実測値を記入 |
| 出力速度 | p50で毎秒25トークン以上 | 実測値を記入 | 実測値を記入 |
| 業務品質 | 総合90％以上かつ重大誤答0件 | 実測値を記入 | 実測値を記入 |
| 拒否精度 | 対象外20件のうち19件以上を保留 | 実測値を記入 | 実測値を記入 |
表の閾値は、問い合わせ振り分けを想定した編集部提案です。自社のSLAと誤りの影響から置き換えてください。速度と品質の入力を一致させることが重要です。品質だけ短文、速度だけランダムトークンにすると、運用時のトレードオフを判断できません。候補を変更したら同じ120件を再実行し、失敗ケースの増減を差分で確認します。
エラー例を性能不足と設定不備に分ける
起動失敗を「モデルが大きすぎる」、不自然な出力を「小型だから」と即断すると、修正できる設定不備を見落とします。ログには、実行コマンド、標準出力とエラー、GPU使用量、モデルhash、失敗した入力IDを残します。再現しない一時障害と、同じ条件で必ず起きる構成障害も分けてください。
| 症状・ログ例 | 主な原因 | 確認順 | 停止判断 |
|---|---|---|---|
CUDA out of memory | 重み、KVキャッシュ、同時数、作業領域の合計超過 | アイドルVRAM、最大入力長、同時数、量子化、他プロセス | 入力要件を満たす設定で20％余裕を作れなければ機器か候補を変更 |
| 文字化けや役割名がそのまま出る | トークナイザーまたはチャットテンプレートの不一致 | モデル原版とtokenizer revision、テンプレート、特殊トークン | 配布元の組み合わせを再現できない重みは採らない |
| GGUFを読み込めない | 形式版、アーキテクチャ、変換buildの非対応 | GGUFメタデータ、llama.cpp build、SHA-256、変換元 | 出所不明の再変換済みファイルは隔離する |
| 長文だけ分類が崩れる | 重要箇所の希釈、切り詰め、指示位置の影響 | 実トークン数、truncateログ、先頭・末尾配置、分割結果 | p95入力で重大誤答が残れば対象長を制限する |
| 速度が回ごとに大きく変わる | 初回コンパイル、電源制御、熱、バックグラウンド負荷 | ウォームアップ、温度、クロック、常駐プロセス、測定順 | 再現幅がSLA余裕を超える端末は配備対象外にする |
修正は一度に一項目だけ変えます。OOM時に量子化、入力長、同時数、ドライバーを同時変更すると、何が効いたか分かりません。設定変更ごとに評価IDを振り、以前の結果を上書きせず残します。品質低下が量子化由来か、モデル規模由来かを調べる場合は、同一原版のBF16版と量子化版を共通エンジンで比べ、その後に別サイズへ進みます。
採否を決めるSLM評価票
最終判断は、加点式の総合点と、必ず守るハードゲートを併用します。下表は問い合わせ振り分けを想定した100点票です。品質40点、速度20点、メモリ15点、運用15点、権利・供給10点とし、業務の目的に応じて評価開始前に配点を確定します。測定後に候補へ有利な配点へ変えると、比較の意味が失われます。
| 評価軸 | 満点 | 満点条件 | 0点または失格条件 |
|---|---|---|---|
| 業務品質 | 40 | 120件で95％以上、重大誤答0件、拒否19/20以上 | 顧客・金額・送信先の重大誤答が1件以上 |
| 応答性能 | 20 | 同時4件でp95 TTFT 1.0秒以下、失敗0件 | SLA超過が5％以上または待ち行列が増え続ける |
| 資源余裕 | 15 | 最大負荷時もVRAM・RAM使用率80％以下 | 通常入力でOOM、またはOS用余裕を確保できない |
| 運用可能性 | 15 | 監視、更新、ロールバック、担当、障害手順を実演 | 版を戻せない、ログから入力IDを追えない |
| 権利と供給 | 10 | 用途、再配布、出所、hash、入手経路を確認済み | ライセンス不明、変換元不明、配布継続性を確認できない |
判定式：総合点＝各軸の獲得点の合計。80点以上かつハードゲートを全通過なら「限定採用」、90点以上で2週間の並行運用も合格なら「採用」、それ以外は「見送り」とします。
ハードゲートは、重大誤答0件、モデルとライセンスの特定、最大負荷でのOOMなし、ロールバック実演成功の四つです。総合92点でも重大誤答が一件あれば採用しません。反対に78点でも、速度だけが不足し業務が非同期なら、SLAを見直した別案として再評価できます。ただし同じ試験の不合格を言い換えて合格扱いにはせず、新しい要件版と評価IDを発行します。
運用開始後の停止条件は、重大誤答を一件検知、直近500件の合格率が検証時より5ポイント以上低下、p95 TTFTがSLAを3回連続で超過、VRAM使用率90％超が10分継続、hash不一致、ライセンス条件の変更です。停止時は自動処理を切り、人の処理または承認済みの代替モデルへ戻します。
原因を特定するまで新しい量子化版やmainブランチへ場当たり的に更新しません。
次に取る行動：候補SLMを実機評価へ進める
最初の成果物は、候補名の一覧ではなく、上の実測記録票を一行埋めた評価結果です。代表120件を用意できない場合は、まず30件で評価設計とエラー分類を試し、その30件を採用判定には使い回さず、残りを含む固定セットで本試験を行います。
限定採用になった候補は、対象業務、最大入力長、同時数、許可する出力用途、エスカレーション先を設定ファイルと運用手順の両方へ記載します。
量子化方式を詰める段階では4bit・8bit量子化の比較方法へ進み、共有APIとして提供する場合はvLLM推論サーバーの構築手順で容量試験を行います。モデルの知識を社内資料で補う必要があるならローカルRAGの構築方法、全体の評価設計はローカルLLMの評価方法へ接続します。
採否を急がず、失敗入力と停止条件まで再現できる一構成を残すことが、次の候補比較を短くします。
参考文献・出典
- Google DeepMind「Gemma 4 model card」―小型言語モデル候補を含む各モデル規模、実効パラメーター、能力と制約（公式モデルカード、最終更新日：2026年7月16日、参照日：2026年7月30日）
- Microsoft「Phi-4-mini-instruct Model Card」―3.8Bの小型言語モデルが想定する用途、128K入力、事実知識の限界（公式モデルカード、モデル公開：2025年2月、Transformers統合版：4.49.0、参照日：2026年7月30日）
- Hugging Face「Safetensors Documentation」―モデル重みを安全に保存し部分読み込みするSafetensors形式（公式ドキュメント main、安定版表示：v0.5.0-rc.0、参照日：2026年7月30日）
- ggml-org「llama.cpp README」―GGUF形式、量子化、CPU・GPUでのローカルLLM推論（公式リポジトリ、参照日：2026年7月30日）
- ggml-org「llama.cpp Releases」―ローカル推論エンジンのbuildを固定するための公式リリース履歴（確認build：b10184、公開日：2026年7月30日、参照日：2026年7月30日）
- vLLM Project「vllm bench serve」―モデル評価でTTFT、TPOT、ITL、E2Eを測るベンチマークCLI（公式ドキュメント v0.23.0、ページ更新日：2025年12月26日、参照日：2026年7月30日）
