あなたのタスクには大規模言語モデル（LLM）が必要でしょうか。それとも小規模言語モデル（SLM）で十分でしょうか。どの段階からSLMでは不十分になるのでしょうか。そもそもSLMとは何を意味するのでしょうか。これらの疑問に答えるため、同じハードウェアで小規模言語モデルと大規模言語モデルを比較テストしました。
要点
日常的で明確に定義されたタスクでは、SLMとLLMの品質差は比較的小さいものです。今回のLLMとSLMの比較テストでは、日常的な作業における1.45 GiBモデルのスコアは15.33 GiBモデルとの差が6.5パーセントポイント以内に収まりましたが、抽出、コーディング、複数の制約を含む指示では、その差が大きく広がりました。
小規模言語モデル（SLM）とは？
小規模言語モデル（SLM）は、大規模言語モデル（LLM）と共通する多くのタスクを、はるかに少ないパラメータ数と計算資源で実行できるように設計されたAI言語モデルです。
SLMは厳密に定義された用語ではありません。LLMのパラメータ数が数百億から数千億に達することがある一方、SLMは数億から数十億程度です。例えば、LuらはSLMをパラメータ数が1億～50億のモデルと分類し、Guptaらはパラメータ数が10億～80億の範囲のSLMを調査しています。Wangらは、パラメータ数が100億までのモデルを小規模と分類する研究もあると明記しています。大まかな目安は次のとおりです。
- 超小型モデルのパラメータ数は10億未満
- 一般的なSLMのパラメータ数は約10億～70億
- 大きめのSLMのパラメータ数は約70億～100億超
SLMは、ノートPCやモバイルデバイスを含む小型のハードウェアでも、より高速に動作できるため、ローカル推論で特に役立ちます。
例えば、2025年のポジションペーパー「小規模言語モデルはエージェント型AIの未来である」は、毎回汎用LLMを呼び出すのではなく、反復的で専門性の高い呼び出しを小さなモデルに割り当てることを提唱しています。
SLMの例には、次のようなものがあります。
| モデル | パラメータ数 |
|---|---|
| Qwen3-4B | 4B |
| SmolLM3-3B | 3B |
| Gemma 3 4B IT | 4B |
| Phi-4-mini-instruct | 3.8B |
| Llama 3.2 3B Instruct | 3B |
SLMに対して、大規模言語モデル（LLM）とは？
SLMに対して、大規模言語モデル（LLM）は一般に、パラメータ数が数十億、または定義によっては数百億の言語モデルを指します。
前述のとおり、SLMとLLMの分類は厳密なものではなく、両者を分けるパラメータ数のしきい値に普遍的な合意はありません。
例えば、Minaeeらは主要なLLMをパラメータ数が数百億～数千億のモデルと説明していますが、Zhaoらはより広く、少なくとも数十億のパラメータを持つモデルと説明しています。
一般的な目安として、パラメータ数が3B、4B、7BのモデルはSLMと呼ぶことができます。70Bのモデルは通常LLMと呼ばれます。12B～20B程度のモデルは、SLMに分類されることもあれば、LLMに分類されることもあります。
小規模言語モデルと大規模言語モデルの主な違い
単純なタスクと複雑なタスクでの品質
単純で明確に定義されたタスクでは、SLMがはるかに大きなモデルに驚くほど近い性能を発揮することがあります。タスクで複数の処理を同時に行う必要がある場合、その差がより重要になります。
例えば、今回のテストでは、62件の日常的なタスクにおけるMiniCPM5-2B Q4のスコアは0.932で、Qwen3.8-27B Q4は0.997でした。しかし、より難しいタスク群では、それぞれ0.560と0.734に低下しました。特に差が大きかったのは、データの正規化と算術計算が必要な、不整形データからの抽出で、スコアは0.29対0.78でした。
| テスト | MiniCPM 2B | Qwen 27B | SLMの結果 |
|---|---|---|---|
| 日常的なタスク | 0.932 | 0.997 | Qwenのスコアの93.5% |
| 難しいタスク | 0.560 | 0.734 | Qwenのスコアの76.3% |
| 不整形データからの抽出 | 0.29 | 0.78 | Qwenのスコアの37.2% |
したがって、実用上の差は日常的な作業では小さいものの、推論、変換、厳密な要件を組み合わせたタスクでは、はるかに大きくなります。
規模だけが要因ではありません。LFM2.5-2.6B Q4は難しいタスク群で0.729を記録し、27BのQwenの0.734にほぼ並ぶ、そのスコアの99.3%に達しました。LFMは推論を無効にできなかった唯一のモデルだったため、トークン予算を10倍に設定しました。したがって、この比較はテストした構成での結果を示しています。パラメータ数だけではタスクの品質を予測できません。
必要メモリ量と量子化
言語モデルの必要メモリ量は、パラメータ数だけでは決まりません。一般に、小さなモデルほど必要なメモリが少なく、ノートPC、一般消費者向けGPU、そのほかのリソースが限られたハードウェアで動かしやすくなります。ただし、コンテキスト長とアーキテクチャによって、その利点は大きく変わります。
今回の測定では、MiniCPM5-2B Q4のVRAM使用量は、コンテキスト長4kで2,188 MiB、128kで7,520 MiBでした。これは3.4倍への増加です。実際、128kでの2BのMiniCPMは、4kでの9BのOrnithモデルよりも32%多くVRAMを使用しました。
| 比較 | VRAM |
|---|---|
| MiniCPM 2B、コンテキスト長4k | 2,188 MiB |
| MiniCPM 2B、コンテキスト長128k | 7,520 MiB |
| Ornith 9B、コンテキスト長4k | 5,714 MiB |
アーキテクチャによっても、コンテキスト長に伴うメモリ使用量の増え方が変わります。4kから128kの間で、MiniCPMのVRAM使用量は5,332 MiB増えた一方、LFM2.5-2.6Bの増加は2,108 MiBにとどまりました。つまり、パラメータ数が近いにもかかわらず、MiniCPMの増加量は約2.5倍でした。
量子化によってモデルの重みに必要なメモリをさらに削減でき、限られたハードウェアでも大きなモデルを実用的に動かせるようになります。実際には、パラメータ数は有用な出発点になりますが、本当にメモリに収まるかどうかは、コンテキスト長、アーキテクチャ、量子化によって決まります。
速度と応答時間
SLMは生成トークンごとに必要な計算量が少ないため、通常は高速です。この利点は、対話型アプリケーション、大量の処理を行うワークロード、ローカル推論で重要になります。
今回のテストでは、MiniCPM5-2B Q4は毎秒485トークンを生成し、Qwen3.8-27B Q4の毎秒79トークンに対して、デコードのスループットは6.1倍でした。また、9kトークンのプロンプトに対して最初のトークンを返すまでの時間は、2.61秒に対して0.39秒で、約6.7倍速くなりました。
| 指標 | MiniCPM 2B | Qwen 27B | SLMの優位性 |
|---|---|---|---|
| 生成速度 | 485 tok/s | 79 tok/s | 6.1倍高速 |
| 最初のトークンまでの時間、9kのプロンプト | 0.39秒 | 2.61秒 | 6.7倍速く到達 |
ただし、単純な毎秒トークン数が、必ずしもタスク完了までの速さにつながるわけではありません。LFM2.5-2.6Bは毎秒537トークンに達しましたが、ほかのモデルが2トークンで回答した分類プロンプトに対して、325トークンを生成しました。そのため、生成速度が高いにもかかわらず、回答にはより長い時間がかかりました。
したがって、実用的な比較では、単純な生成速度に加えて、応答全体にかかる時間と応答の長さも確認してください。
デンスモデルとMoEモデル
Mixture-of-Experts（MoE）モデルでは、パラメータ数の捉え方が単純ではなくなり、有効パラメータ数と総パラメータ数の違いが重要になります。デンスモデルはトークンごとにモデルの全パラメータを使用しますが、MoEモデルは一部のエキスパートだけを有効にします。これにより、MoEモデルは大きなモデルと同程度のストレージ容量を必要としながら、計算面でははるかに小さなモデルの特性を一部併せ持つことができます。
Ornith-1.5-35B-A3Bはその好例です。総パラメータ数は約35Bですが、トークンごとに有効になるのは約3Bです。今回のテストでは、デンスモデルのQwen3.8-27Bの毎秒79トークンに対し、毎秒287トークンを生成し、スループットは約3.6倍でした。
ただし、Ornithはコンテキスト長4kで20,780 MiB（20.29 GiB）のVRAMを使用し、今回のテストで4k時のVRAM使用量が最も大きいモデルでした。つまり、有効パラメータ数が3Bであることで高速になったものの、総パラメータ数が35Bであるため、保存と実行には依然として大きな容量が必要でした。
小規模モデルと大規模モデルを比較テスト
同じハードウェアと同じ推論環境で、9種類のモデル構成をテストしました。使用したマシンは、96 GBのVRAMを搭載したNVIDIA RTX PRO 6000 Blackwell Workstation Edition、28 vCPU、125 GBのシステムRAM、Ubuntu 24.04という構成です。Blackwellアーキテクチャ向けのCUDAサポートを有効にしてビルドした、現行のメインライン版llama.cppを実行しました。
LLMとSLMの品質比較では、2種類の作業に焦点を当てました。
- 1つは、小さなモデルがLLMの実用的な代替と見なされることの多い、日常的で構造化された作業です。分類、抽出、形式変換、提示された情報に基づく質問応答、書き換えが含まれます。
- もう1つは、乱雑な入力、計算、厳密な事実要件、実行可能なコード、複数の同時指示を加えることで、それらのタスクを意図的に難しくしたものです。
これにより、SLMがタスクを処理できるかどうかだけでなく、大きなモデルとの差がどこから広がり始めるかも測定できました。
日常的なタスク群は62件で、チケット分類24件、請求書からの抽出10件、形式変換8件、提示されたテキストだけに厳密に基づいて回答する質問12件、制約付きの書き換え8件で構成しました。難しいタスク群は12件で、不整形データからの抽出、事実要件付きの要約、ユニットテスト付きの標準ライブラリを使ったコーディング、6～8個の制約を同時に満たす指示追従を、それぞれ3件ずつ用意しました。
各モデルには、バイト単位で同一のプロンプトを与えました。品質テストでは、コンテキスト長16k、バッチサイズ1、temperature 0、seed 1234、FP16 KVキャッシュを使用し、投機的デコードは無効にしました。モデルが対応している場合は、推論を無効にしました。例外はLFM2.5-2.6Bです。サーバーフラグでもenable_thinking: falseでも推論が止まらなかったため、最終回答まで出力できるよう、トークン予算を10倍に設定しました。
品質評価では合計666件の回答が得られ、そのスコアをプログラムで算出しました。
テスト結果
各タスクのスコアは0～1に正規化しており、1はすべての自動チェックに合格したことを意味します。集計スコアは各タスク群に含まれる全タスクの平均なので、各タスクグループの寄与はテストケース数に比例します。
太字の2列は異なる難易度の結果をまとめたものです。日常は日常的な5つのタスクグループを、複雑は不整形データからの抽出、要件付き要約、テストによるコード検証、複数の制約を含む指示をまとめています。総合スコアが近い2つのモデルでも、失敗する作業の種類は異なる場合があるため、残りの列では、どのタスク種別が集計結果に影響しているかを示しています。
| 構成 | ファイル容量、GiB | 日常 | 複雑 | 分類 | 抽出 | 変換 | 提示情報に基づく質問応答 | 書き換え | 不整形データからの抽出 | 要約 | コード | 指示追従 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MiniCPM5-2B Q4 | 1.45 | 0.932 | 0.560 | 0.96 | 0.98 | 0.83 | 0.92 | 0.92 | 0.29 | 0.84 | 0.52 | 0.59 |
| LFM2.5-2.6B Q4 | 1.56 | 0.932 | 0.729 | 1.00 | 0.98 | 0.88 | 0.75 | 1.00 | 0.92 | 1.00 | 0.33 | 0.67 |
| Spark-X2.5-4B Q4 | 2.42 | 0.945 | 0.597 | 0.96 | 0.96 | 0.75 | 1.00 | 1.00 | 0.44 | 0.90 | 0.53 | 0.52 |
| Ornith-1.5-9B Q4 | 5.38 | 0.991 | 0.633 | 1.00 | 0.98 | 1.00 | 1.00 | 0.96 | 0.44 | 0.80 | 0.62 | 0.67 |
| Qwen3.8-27B Q4 | 15.33 | 0.997 | 0.734 | 1.00 | 0.98 | 1.00 | 1.00 | 1.00 | 0.78 | 0.80 | 0.73 | 0.62 |
| Ornith-1.5-35B-A3B Q4 | 20.22 | 0.968 | 0.605 | 0.92 | 1.00 | 1.00 | 1.00 | 1.00 | 0.36 | 0.80 | 0.62 | 0.64 |
| MiniCPM5-2B Q8 | 2.50 | 0.900 | 0.601 | 0.92 | 0.98 | 0.71 | 0.92 | 0.92 | 0.44 | 0.87 | 0.47 | 0.62 |
| Ornith-1.5-9B Q8 | 9.11 | 0.997 | 0.666 | 1.00 | 0.98 | 1.00 | 1.00 | 1.00 | 0.44 | 0.93 | 0.62 | 0.67 |
| Qwen3.8-27B Q2 | 9.15 | 0.984 | 0.738 | 1.00 | 1.00 | 1.00 | 0.92 | 1.00 | 0.69 | 0.90 | 0.73 | 0.62 |
日常的なタスクでは、差はそれほど顕著ではありませんでした。MiniCPM5-2B Q4は、はるかに小さいにもかかわらず0.932に達し、Qwen3.8-27B Q4の0.997に近い結果でした。
複雑なタスク群では、MiniCPM5-2B Q4とQwen3.8-27B Q4の差は広がり、0.560対0.734でした。
速度、メモリ、読み込み時間、エネルギー消費量
性能測定は別に行い、GPUを占有するモデルを常に1つだけにして、順番に測定しました。
プリフィル列はモデルがプロンプトを読み取る速度を示し、生成速度は回答を出力する速さを示します。また、9kトークンのプロンプトを入力してから最初のトークンが出るまでの時間を測定し、チケット分類の応答が完了するまでの全過程で、消費電力を5 Hzでサンプリングしました。
| 構成 | ファイル容量、GiB | 読み込み、秒 | プリフィル、tok/s | 生成、tok/s | VRAM 4k、MiB | VRAM 32k、MiB | VRAM 128k、MiB | TTFT 9k、秒 | J/タスク |
|---|---|---|---|---|---|---|---|---|---|
| MiniCPM5-2B Q4 | 1.45 | 1.04 | 24,909 | 485 | 2,188 | 3,392 | 7,520 | 0.39 | 67 |
| LFM2.5-2.6B Q4 | 1.56 | 2.00 | 28,399 | 537 | 2,354 | 2,830 | 4,462 | 回答なし | 265 |
| Spark-X2.5-4B Q4 | 2.42 | 2.00 | 17,911 | 335 | 3,426 | 4,462 | 8,014 | 0.57 | 118 |
| Ornith-1.5-9B Q4 | 5.38 | 3.00 | 11,555 | 218 | 5,714 | 6,638 | 9,806 | 0.85 | 150 |
| Qwen3.8-27B Q4 | 15.33 | 4.96 | 3,898 | 79 | 15,838 | 17,658 | 23,898 | 2.61 | 298 |
| Ornith-1.5-35B-A3B Q4 | 20.22 | 5.96 | 8,580 | 287 | 20,780 | 21,368 | 23,384 | 1.24 | 133 |
| MiniCPM5-2B Q8 | 2.50 | 2.00 | 26,368 | 388 | 未測定 | 未測定 | 未測定 | 未測定 | 未測定 |
| Ornith-1.5-9B Q8 | 9.11 | 3.01 | 11,806 | 154 | 未測定 | 未測定 | 未測定 | 未測定 | 未測定 |
| Qwen3.8-27B Q2 | 9.15 | 3.04 | 3,643 | 110 | 未測定 | 未測定 | 未測定 | 未測定 | 未測定 |
J/タスクは、チケット分類の応答が完了するまでにハードウェアが消費したエネルギーの実測値を示します。さまざまなワークロード全般のエネルギー消費量を表す指標ではありません。
MiniCPM5-2B Q4は、小さなモデルの実用上の利点を示しています。Qwen3.8-27B Q4と比べて、読み込みは4.8倍速く、最初のトークンの出力は6.7倍速く、生成は6.1倍速く、分類タスクのエネルギー消費量は4.4分の1でした。
小規模言語モデルで十分な場合
では、これらのテストから何が分かるのでしょうか。
タスクの範囲が明確で、出力を検証でき、実測したエラー率が許容範囲内であれば、通常はSLMで十分です。例えば、今回の日常的なタスク群では、チケットの振り分け、一般的な請求書項目の抽出、形式変換、提示された情報に基づく質問応答、明示的な制約に沿った書き換えがこれに該当しました。MiniCPM5-2B Q4は、これら62タスクで0.932を記録し、モデルファイルが10.6倍大きいQwen3.8-27B Q4との差はわずか0.065でした。
実際に、小規模言語モデルで特に高い信頼性を得られる用途には、3つの共通点があります。
- 入力と出力のスキーマが安定している。
- ルール、テスト、信頼度のしきい値によって失敗を検出できる。
- 既知の対応範囲を外れたリクエストを、大きなモデルや人に引き継げる。
より大きな言語モデルを使う価値がある場合
小規模言語モデルの限界は、タスクに複数の難しい要素が組み合わさっている場合や、誤った回答の検出と修正に大きなコストがかかる場合に現れます。そうした場面で、大規模言語モデルを使う価値が生まれます。
今回のテストでは、不整形データからの抽出と実行可能なコードの生成で、最も明確な改善が見られました。これらでは、モデルは見慣れた形式を再現する以上の処理を行う必要がありました。
複雑なタスクの集計スコアは、MiniCPMの0.560に対し、Qwen3.8-27B Q4では0.734に上がりました。特に差が大きかったのは、不整形データからの抽出で、スコアは0.78対0.29でした。また、ユニットテストで検証したコードでは0.73対0.52でした。
ローカル言語モデル（SLMとLLM）を実行できる環境
これらのモデルに対応する量子化版は、重み、KVキャッシュ、ランタイムに必要な空きメモリが十分にあれば、個人用のハードウェアで実行できます。ここで測定した速度は、今回のテスト用ワークステーション固有のものです。これらのモデルをローカルで実行するには、Atomic ChatのようなローカルAIアプリが必要です。Atomic Chatは、オフラインAIモデルのセットアップと実行を簡単にするために私たちが開発したオープンソースアプリです。Atomic Chatには、次の機能があります。
- 統合されたモデルカタログを通じて、Hugging FaceからGGUFモデルをダウンロードし、管理します。
- モデルとチャットするためのグラフィカルインターフェースを内蔵しています。
- TurboQuantによるKVキャッシュ圧縮に対応した、改変版llama.cppバックエンドをオプションで提供します。このバックエンドを選択すると、turbo3とturbo4の各モードでKVキャッシュのメモリ使用量を削減できます。turbo3はキャッシュの値を約3ビット精度で保存します。
- ローカルのOpenAI互換APIを提供し、ツールやエージェントをローカルで実行中のAIモデルに簡単に接続できます。
よくある質問
SLMはLLMの一種ですか？
広い意味では、そうです。SLMとLLMはどちらも、コンテキストを処理してトークンを生成する同じ系統のモデルに属します。これらの呼称は、互換性のない技術を指すものではなく、相対的な規模と導入・運用上のトレードオフを表しており、両者を分ける普遍的なパラメータ数はありません。
小規模言語モデルは常に高速ですか？
必ずしもそうではありません。通常、小さなモデルは転送する重みの量が少ないため、トークンをより高速に生成しますが、タスクにかかる時間はアーキテクチャと出力の挙動にも左右されます。今回のスループットテストでは、LFM2.5-2.6Bが毎秒537トークンで首位でしたが、推論を無効にできないため、単純な分類では、MiniCPM5-2Bで同じタスクを行った場合よりも遅く、エネルギー消費量も多くなりました。有用な比較指標は、生成速度だけでなく、利用可能な回答が得られるまでの総所要時間です。
大規模言語モデルはローカルで実行できますか？
はい。量子化、統合メモリ、複数GPU、CPUへの部分的なオフロードにより、重みが公開されている多くの大規模モデルを、個人用コンピューターやワークステーションで実行できます。ただし、快適に動作するかどうかは別の問題です。強い量子化は品質を低下させる可能性があり、オフロードは速度を大きく低下させる可能性があります。また、重みは依然としてKVキャッシュ、ランタイム、ほかのアプリケーションとメモリを共有する必要があります。
量子化するとLLMはSLMになりますか？
いいえ。量子化は同じ重みを低い精度で保存するもので、大きなアーキテクチャを小さくするものではありません。Qwen3.8-27B Q2の容量は9.15 GiBで、日常的なタスクのスコアは0.984と、Q4版の0.997に近い水準を維持しました。ただし、依然として27Bのモデルであり、生成速度は毎秒110トークンで、1.45 GiBのMiniCPM5-2B Q4の毎秒485トークンを下回りました。
有効パラメータ数が少なければ、MoEモデルは小規模ですか？
いいえ。有効パラメータ数は、Mixture-of-Expertsモデルのうち各トークンの計算に参加する部分の規模を示し、総パラメータ数は保存が必要な重みの数を決めます。Ornith-1.5-35B-A3Bの有効パラメータ数は約3Bでしたが、コンテキスト長4kで20,780 MiB（20.29 GiB）のVRAMを使用しました。そのため、トークンごとの計算量では小さなモデルのように、ストレージ容量では大きなモデルのように振る舞いました。
結論
今回の日常的なタスクのテストでは、小さなモデルは、テストした大きなモデルにほぼ匹敵する品質で日々の作業を処理しながら、実行も読み込みも速く、使用するハードウェアリソースはその一部で済みました。主なポイントは次のとおりです。
- 今回テストした日常的なタスク：MiniCPM5-2B Q4は、モデルファイルが約90%小さく、コンテキスト長4kでのVRAM使用量が86%少ない状態で、Qwen3.8-27B Q4の集計スコアの93.5%に達しました。測定した分類応答では、エネルギー消費量が78%少なくなりました。
- MiniCPM5-2B Q4は、Qwen3.8-27B Q4より6.1倍高速にトークンを生成し、今回の9kトークンのプロンプトでは0.39秒で最初のトークンを出力しました。
- 複雑なタスク：MiniCPM5-2B Q4は、Qwen3.8-27B Q4の集計スコアの76.3%、不整形データからの抽出スコアの37.2%に達しました。
- 大きなモデルがMiniCPMに対して最も明確な改善を示したのは、不整形データからの抽出と、テストで検証したコードでした。
- 日常的なタスクでは小さなモデルを標準とし、例えば出力が検証に失敗した場合に切り替えるなど、必要なときだけ大きなモデルに処理を引き継いでください。
