LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守を受託

SLM(小規模言語モデル)とは何か——パラメータ規模で捉える定義

SLM(Small Language Model、小規模言語モデル)とは、パラメータ数を数億〜十数B(ビリオン)程度に抑えた言語モデルを指す呼び方です。AWSのブログでは、SLMを「デコーダーのみ、またはエンコーダー・デコーダー構成のコンパクトなトランスフォーマーモデルで、通常は200億パラメータ未満」と説明しています^*1。ただしこの線引きは固定的なものではなく、対象範囲は徐々に広がっていると同じ記事内で補足されています^*1。

オープンモデルの例として、Googleは軽量なオープンモデル群Gemmaを公開しており、クラウドサーバーからノートパソコン・モバイル端末まで幅広いハードウェアで動作すると説明しています^*7。Microsoft Researchも2023年12月12日、27億パラメータのPhi-2について、学習データの質を高める手法でパラメータ規模を抑えつつ高い性能を狙う開発方針を公表しました^*8。これらはいずれもオープンに公開されたモデル群の一例であり、本稿では特定モデル同士の優劣を比較するものではありません。

大規模LLMとの使い分け——コスト・レイテンシ・データ管理・特化タスク

大規模LLMは汎用的な対話や複雑な推論に強みがある一方、SLMは限られた種類の処理を繰り返し実行する場面に向いています。NVIDIAは2025年8月29日公開のブログで、コマンド解析や構造化データの出力生成、要約作成のような「反復的で予測可能な特化タスク」にSLMが適していると位置づけています^*2。

コスト面では、NVIDIAの研究チームが2025年に公開した見解の中で、小規模なモデルを軸に据える運用は大規模モデルに比べて経済的だと述べています^*3。同チームは検証例として、あるモデルの組み合わせでは大規模モデル単体の運用より大幅に安価だったと報告していますが、この数値は特定条件下での一例であり、すべての用途に当てはまるとは限りません^*2。

レイテンシとデータ管理の観点も重要です。AWSは、金融・医療・通信のような規制業界では国内でのデータ保持が求められる場合があり、情報セキュリティ要件への適合や製造現場でのリアルタイムな機器診断のような即時応答が必要な場面で、オンプレミスやエッジでのSLM運用が選択肢になると説明しています^*1。クラウドAPI経由の大規模LLMでは、通信経路を挟む分だけ応答に時間がかかりやすく、データを外部に送信する前提そのものが管理上の制約になる企業も存在します。

したがって使い分けの軸は、汎用性が必要か特化タスクで十分か、応答速度をどこまで求めるか、データを外部に出せるかどうかの三点に整理できます。特定タスクの精度が実務上足りるかどうかは、想定業務でのテストを通じて確認する進め方が現実的です。

SLMを軽量化する考え方——ファインチューニング・蒸留・量子化

SLMを実務で使えるレベルに仕上げる際は、複数の軽量化・特化手法を組み合わせるのが一般的です。ここでは代表的な三つの考え方を整理します。

量子化について、Hugging Faceのドキュメントは「モデルの重みをより低い精度で保存することで、読み込みと利用時のメモリ要件を下げる」技術だと説明しています^*4。重みは本来32bit浮動小数点(fp32)で保持されますが、16bit(fp16・bf16)や、int8・int4のような整数表現まで精度を落とす手法も選べるとされています^*4。

知識蒸留は、大規模で複雑な教師モデルから、小規模で構造がシンプルな生徒モデルへ知識を転送する技術です^*5。NVIDIAは2024年8月14日公開のブログで、層をまるごと落とす深さ方向のプルーニングと、ニューロン・アテンションヘッド・埋め込みチャネル単位でのプルーニングを組み合わせる方法を紹介しました^*5。同社の検証では、この手法で作成したLlama-3.1-Minitron 4Bが、ゼロから学習した場合に比べてMMLUスコアが向上し、学習に用いるトークン量も数十分の1程度に抑えられたと報告されています^*5。

三つの手法は互いに排他的ではなく、組み合わせて使う設計が一般的です。自社の用途に必要な精度と、動かす基盤の性能制約を突き合わせながら、どこまで軽量化するかを決めていく進め方になります。

SLMを動かす基盤——オンプレGPU・エッジ・小規模インスタンス

SLMはパラメータ規模が小さい分、動かす基盤の選択肢も広がります。AWSのブログでは、オンプレミスやエッジでの実行を選ぶ理由として、データ主権・情報セキュリティ・低レイテンシの三点を挙げています^*1。とりわけ製造現場でのリアルタイムな機器診断のように、応答の速さが業務品質に直結する場面で、エッジ側での推論が検討材料になります^*1。

Googleが公開するGemmaも、クラウドサーバーだけでなく手元のハードウェアやモバイル端末、組み込み機器上でも動作するように設計されています^*7。すべての処理を端末内で完結できれば、機密性の高い情報をクラウドへ送信せずにアプリケーションを構築できる余地が生まれます^*7。

基盤の選び方は、大きく三つに整理できます。第一は、社内のオンプレミスGPUサーバーで継続稼働させる方式。第二は、工場や店舗の現場に置いたエッジ機器上で完結させる方式。第三は、クラウド上の小規模インスタンスで、必要なときだけ起動する方式です。いずれを選ぶかは、想定するリクエスト量、レイテンシ要件、データを外部に出せるかどうかによって変わってきます。

RAGとの組み合わせ方——不足する知識を外部データで補う

SLMはパラメータ数が少ない分、内部に保持できる知識量にも制約があります。この制約を補う代表的な手法がRAG(Retrieval Augmented Generation、検索拡張生成)です。AWSは、RAGを「大規模言語モデルに社内文書のような外部データを組み合わせる技術」と定義し、モデルに固有ユースケースへ対応するための文脈を与える手法だと説明しています^*6。

AWSが示す一般的なRAGの流れは次の通りです。まず社内文書をベクトル形式の埋め込みに変換し、ベクトルデータベースへ格納します^*6。次に利用者が自然言語で質問を送ります^*6。続いてオーケストレーターがベクトルデータベース内を類似検索し、関連する情報をプロンプトに追加します^*6。最後にモデルが、追加された文脈をもとに回答を生成します^*6。

この仕組みはSLMとの相性も良いとされています。AWSのブログでは、SLMの運用においてRAGとファインチューニングを組み合わせることで、誤った情報を減らしながらドメイン特化の精度を高められると指摘しています^*1。モデル自体を巨大化させなくても、外部の参照データを充実させることで実務上の精度を補える点は、SLM活用の実践的な選択肢になります。

オープンモデルの動向と選び方——優劣を断定しない見極め方

SLMの分野では、複数の組織がオープンな重みを持つモデル群を継続的に公開しています。Googleは軽量モデル群Gemmaを、テキストに加えて音声や画像入力にも対応する形で展開しており、モバイルやブラウザでの動作を想定した小さいサイズのバリエーションも用意しています^*7。Microsoft Researchも、学習データの質を高めることでパラメータ規模を抑えつつ性能を引き上げる開発方針を示しており、2023年12月12日公開のPhi-2はその一例です^*8。

これらはいずれも継続的に新しいバージョンが公開される分野であり、ある時点での性能比較がすぐに更新される可能性があります。本稿では特定モデルの優劣を断定することは避け、選定にあたって確認すべき一般的な観点を挙げます。第一に、想定タスクでの精度を自社データで検証できるかどうかという点です。第二に、ライセンス条件が商用利用や自社改変に適合しているかを確認します。第三に、動かす基盤(オンプレGPU・エッジ・クラウドインスタンス)でのメモリ・推論速度の実測値を押さえます。第四に、継続的なアップデートや脆弱性対応が期待できる開発体制かどうかです。

これらの観点を自社だけで評価し切るには、複数モデルの検証環境を用意する手間がかかります。外部の技術パートナーに評価そのものを依頼する企業も見られます。

導入の進め方と外注時の勘所——内製と外注の分かれ目

SLM活用を検討する際は、次のような順序で進めるのが一般的です。まず自社業務のうち、SLMで十分に対応できそうな特化タスクを洗い出します。次に候補となるオープンモデルを絞り込み、自社データで精度を検証する段階です。続いてファインチューニングやRAGを必要に応じて組み合わせ、実運用に耐える精度まで引き上げていきます。最後に、オンプレGPU・エッジ・小規模インスタンスのいずれで動かすかを決め、監視体制を整えたうえで本番運用に移します。

この一連の工程を内製で完結できるかどうかは、社内に機械学習エンジニアリングの知見がどれだけ蓄積されているかに左右されます。モデルの評価設計、ファインチューニングや量子化の実装、推論基盤の構築・監視まで、複数領域の専門性が求められるためです。

外注する場合は、依頼範囲の広さが選定の分かれ目です。モデル選定の評価設計だけを依頼するのか、ファインチューニングや量子化の実装まで含めるのか、本番稼働後の監視・改善まで一括で任せられるのかを、契約前にすり合わせておく必要があります。元請（プライムベンダー）として全体設計から実装・運用まで一貫して受託できるかどうかも、体制選びの判断材料になります。

。想定業務の特性や、動かす基盤の制約によって必要な工数は変わってきます。まずは対象業務の要件を整理したうえで、内製・外注の切り分けを検討する進め方が実務的です。

まとめ：SLM活用で押さえる3つの判断軸

本稿ではSLM(小規模言語モデル)の考え方を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、SLMはAWSの定義に沿えば通常200億パラメータ未満のコンパクトなモデルであり、特化タスクの反復処理に向いています^*1。第二に、量子化・知識蒸留・ファインチューニングを組み合わせることで、限られた基盤上でも実用的な精度を狙えます^*4*5。第三に、RAGと組み合わせて外部知識を補いつつ、オンプレ・エッジ・クラウドのどこで動かすかを、データ管理とレイテンシの要件から選ぶ判断が求められます^*6。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS Compute Blog「Running and optimizing small language models on-premises and at the edge」（2025年6月23日）（https://aws.amazon.com/blogs/compute/running-and-optimizing-small-language-models-on-premises-and-at-the-edge/）
2. *2　出典：NVIDIA Technical Blog「How Small Language Models Are Key to Scalable Agentic AI」（2025年8月29日）（https://developer.nvidia.com/blog/how-small-language-models-are-key-to-scalable-agentic-ai/）
3. *3　出典：NVIDIA Research「Small Language Models are the Future of Agentic AI」（https://research.nvidia.com/labs/lpr/slm-agents/）
4. *4　出典：Hugging Face「Quantization overview」（Transformers Documentation）（https://huggingface.co/docs/transformers/en/quantization/overview）
5. *5　出典：NVIDIA Technical Blog「How to Prune and Distill Llama-3.1 8B to an NVIDIA Llama-3.1-Minitron 4B Model」（2024年8月14日）（https://developer.nvidia.com/blog/how-to-prune-and-distill-llama-3-1-8b-to-an-nvidia-llama-3-1-minitron-4b-model/）
6. *6　出典：AWS Prescriptive Guidance「Understanding Retrieval Augmented Generation」（https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html）
7. *7　出典：Google AI for Developers「Gemma models overview」（https://ai.google.dev/gemma/docs）
8. *8　出典：Microsoft Research Blog「Phi-2: The surprising power of small language models」（2023年12月12日）（https://www.microsoft.com/en-us/research/blog/phi-2-the-surprising-power-of-small-language-models/）

Tweet