SLM（スモール言語モデル）とは？

パラメータ数がわずか38億の小型AIモデルが、その約20倍の規模を持つ700億パラメータのモデルに匹敵するタスク処理精度を示す。この事実が示すように、現在の生成AI開発の最前線では「モデルの巨大化（LLM）」から、実用性とコスト効率を極限まで高めた「スモール言語モデル（SLM：Small Language Models）」へのシフトが急速に進んでいます。メモリ帯域の物理的限界やインフラコスト、データ主権といった厳しいビジネスの制約を打破する現実的な選択肢として、SLMの実践的な価値が再評価されています。

1. スモール言語モデル（SLM）とは？LLMとの構造・スペックの決定的な違い

1-1. パラメータ数と計算リソースの圧倒的差異

SLMとLLMの物理的な最大の違いは、モデルを構成する「パラメータ数」と、それを稼働させるために必要なハードウェアスペック（特にGPUのVRAM容量）にあります。この規模の差は、システム設計における動作要件（メモリフットプリント）に決定的な違いを生み出します。

例えば、パラメータ数が38億（3.8B）のMicrosoft「Phi-3-mini」や、NTTが開発したパラメータ数70億（7B）の「tsuzumi（軽量版）」は、4-bit量子化などの圧縮技術を適用することで、実行に必要なVRAM容量を数GB〜十数GB程度にまで抑制できます。これにより、一般的なコンシューマー向けGPU（NVIDIA GeForce RTX 4090など）を搭載したオンプレミス環境や、ネットワークから遮断されたエッジAI（スマートフォンやPCのローカル環境）での稼働が可能になります。

一方、数千億パラメータを持つLLMをオンプレミス環境で運用する場合、NVIDIA H100（VRAM 80GB）などのエンタープライズ向けGPUを複数枚連結したクラスタ構成が不可欠となり、ハードウェアの調達・維持に数千万円規模の初期投資が発生します。LLMとSLMの決定的な違いの根幹は、この物理的なパラメータ数がもたらす、必要計算リソースの圧倒的な差にあります。

比較項目	SLM（スモール言語モデル）	LLM（大規模言語モデル）
代表的なモデル例	Microsoft Phi-3-mini (3.8B) NTT tsuzumi (軽量版: 7B) Meta Llama-3 (8B)	GPT-4 (推定1.8T) Meta Llama-3 (70B) Google Gemini 1.5 Pro
パラメータ数	10億〜200億（1B〜20B）	700億〜数兆（70B〜数T）
動作に必要なVRAM容量 (推奨値)	約2GB〜40GB ※量子化によりコンシューマーGPUやモバイル端末で動作可能	約140GB〜数TB ※ハイエンドGPUを複数台連結したクラスタ環境が必須
主な動作環境	エッジAI、ノートPC、スマートフォン、一般的なオンプレミスサーバー	クラウドデータセンター、大規模GPUクラスタ
推論コスト削減効果	極めて高い（高額なクラウドAPI利用料や専用GPUの維持費を不要にできる）	低い（リクエスト数に比例してAPI利用料やクラウドインフラ費が膨大化する）

1-2. SLMが実現する「ミリ秒単位」の推論高速化

リアルタイムな対話応答が求められるカスタマーサポートの自動応答システムや、車載デバイスなどのエッジAI環境において、SLMは「ミリ秒単位」の極めて低いレイテンシ（遅延時間）を実現します。モデルの軽量化が推論速度の劇的な短縮を可能にする理由は、主に「メモリ帯域幅のボトルネック解消」と「キャッシュ効率の向上」という2つの物理的メカニズムに基づいています。

第一に、大規模言語モデルの推論処理（特に1トークンずつ逐次生成する自動回帰プロセス）は、プロセッサの演算性能ではなく、メモリからデータを転送する速度が全体の処理速度を決定する「Memory-bound（メモリ帯域制限）」の特性を持ちます。

例えば、700億パラメータ（70B）のLLMを16ビット浮動小数点数（FP16）で処理する場合、1トークンを出力するたびに約140GBのモデルデータをGPUメモリからプロセッサへと転送する必要があります。毎秒2.0TBのメモリ帯域幅を持つNVIDIA H100を使用した場合でも、データ転送だけで物理的に約70ミリ秒の時間を要します。これに対し、38億パラメータ（3.8B）のPhi-3-miniを4-bit量子化（データサイズ約2.2GB）して実行する場合、データ転送量は約60分の1に削減されます。これにより、メモリからの読み出し時間が極小化され、最初の1文字目が出力されるまでの時間（Time to First Token: TTFT）を10〜30ミリ秒クラスにまで短縮できます。

第二に、SLMは「KVキャッシュ（Key-Value Cache）」のメモリ占有量を劇的に削減します。トランスフォーマーベースのモデルは、文脈を維持するために過去のトークンの計算結果（KVキャッシュ）をVRAM上に保持します。パラメータ数が膨大なLLMでは、長文のコンテキストを処理する際、KVキャッシュだけで数十GBのメモリを消費し、メモリのページング（退避処理）が発生して遅延の原因になります。一方、パラメータ数が少ないSLMであれば、KVキャッシュ自体のサイズも小さいため、GPUのオンチップキャッシュや高速なL1/L2キャッシュ領域内に多くのデータを収めることができます。この結果、キャッシュミスが最小限に抑えられ、高頻度な並行リクエストが発生するシステム環境下でも、遅延のブレがないミリ秒単位の応答性能を維持することが可能になります。

2. 実在する主要SLMのスペックと技術特性【Phi-3 / tsuzumi / Llama 2 7B】

自社ビジネスに言語モデルを導入する際、LLMとSLMの違いを最も端的に示す指標が、パラメータ数の削減に伴う計算リソース要件と推論性能のトレードオフです。現在、実用に耐えうる主要なSLMのスペックを整理することで、インフラ環境や処理要件に適したモデル選定の判断材料が得られます。

項目	Microsoft Phi-3-mini (3.8B)	NTT tsuzumi (7B / 超軽量版 0.6B)	Meta Llama 2 7B
パラメータ数	38億（3.8 Billion）	70億（7 Billion） / 6億（600 Million）	70億（7 Billion）
主なライセンス	MIT License	商用利用（個別契約・提供プランによる）	Llama 2 Community License
得意な言語	多言語（英語中心、日本語対応）	日本語（最高峰の処理能力）、英語	多言語（英語中心）
MMLUスコア	68.8%	（英語ベンチマーク非公開 / 日本語性能でGPT-3.5を凌駕）	45.3%（Baseモデル）
主な提供形態	オープンソース、クラウドAPI	オンプレミス、プライベートクラウド、API	オープンソース

2-1. Microsoft「Phi-3」が示した小型モデルの限界突破

Microsoftが開発したPhi-3-miniは、38億という極めて少ないパラメータ数でありながら、従来のLLMに匹敵する推論性能を達成したモデルです。Microsoftが公開した技術論文「Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone」によると、Phi-3-miniはMMLU（Massive Multitask Language Understanding）ベンチマークで68.8%を記録し、パラメータ数が約2倍であるLlama 2 7B（45.3%）や、さらに規模の大きいMixtral 8x7Bをも上回るタスク処理能力を実証しました。

この限界突破を可能にした技術的アプローチが、「高品質な教育用データ（合成データを含む）によるトレーニングの最適化」です。Microsoftの研究チームは、子供向けの絵本や基礎的な教科書から、厳選されたWebデータ、さらに大規模LLM（GPT-4など）を用いて生成した論理的思考を促す「合成データ（Synthetic Data）」を学習パイプラインに投入しました。これにより、ノイズの多い一般的なWebスクレイピングデータへの依存を減らし、小さなニューラルネットワークでも効率よく高精度な内部表現を獲得させることに成功しています。

この軽量設計は、オンプレミス環境の構築が難しいスマートフォンや車載システムなどのエッジデバイス上でもネイティブ動作するエッジAIの実現に直結します。iPhone 14のA16 Bionicチップ上において、Phi-3-miniは完全にオフラインの状態で1秒あたり12トークン以上のテキストを生成できることが確認されており、クラウドへのネットワーク通信が発生しないため、遅延の極小化と大幅な推論コスト削減を両立する有力な選択肢となります。

2-2. NTT「tsuzumi」が強みとする日本語処理とオンプレミス対応

NTTが開発したtsuzumiは、パラメータ数70億（7B）の軽量版と、6億（0.6B）の超軽量版の2つのラインナップを持ち、日本語のニュアンスや表現に対する深い理解力を備えた国産SLMです。NTTのプレスリリースによると、tsuzumiは日本語のベンチマークにおいてGPT-3.5を上回る回答精度を記録しており、特に日本のビジネス文書、敬語表現、業界専門用語が混在する文脈理解で強みを発揮します。

技術的なアプローチとして、NTTが長年蓄積してきた「日本語自然言語処理技術」に基づく独自のコーパス構築と、学習用のトークナイザーの最適化が挙げられます。英語ベースのモデル（LlamaやPhiなど）を日本語で利用する場合、文字や単語の分割（トークン化）の効率が落ち、結果として推論スピードが低下し、コストが増加する問題がありました。tsuzumiは日本語処理に最適化されたトークナイザー設計を採用しているため、限られたハードウェア資源でも高速かつ低消費電力で稼働します。

さらに、tsuzumiは視覚情報理解（マルチモーダル機能）に対応しており、PDFやスキャンされた稟議書、グラフを含む技術文書を画像として入力し、その内容を正確に読み取って要約・構造化することが可能です。この特性により、機密性の高い財務データや顧客の個人情報を社外のクラウドに送信できない金融機関や自治体、製造業のクローズドなネットワークにおいて、オンプレミスAIとして安全に展開できます。1基のGPU（NVIDIA A100など）があれば十分に推論環境を構築・維持できるため、年間の運用コストをLLM利用時に比べて劇的に抑えることが可能です。

2-3. オープンソースSLM（Llama / Mistral）のカスタマイズ性

MetaのLlama 2 7Bや、Mistral AIが提供するMistral 7BをはじめとするオープンソースSLMは、特定のビジネスドメインに特化させた「カスタマイズ性」において、企業のIT戦略担当者から支持されています。ソースコードおよびモデルのウェイトが公開されているため、自社のプライベート環境や特定のローカルGPUサーバーに配備し、インフラを完全にコントロールすることが可能です。

実務上の大きな優位性は、LoRA（Low-Rank Adaptation）やQLoRAといったPEFT（パラメータ効率の良い微調整技術）を用いた「ファインチューニングの容易さ」にあります。たとえば、数万件の自社製品マニュアルや過去の顧客サポート履歴、業界特有のAPIスキーマを学習させる場合、数兆パラメータ規模のLLMでは、莫大な計算コストと時間がかかります。しかし、Llama 2 7BクラスのSLMであれば、単一の消費者向けGPU（例えばNVIDIA RTX 4090）や中規模のエンタープライズGPUを用いて数時間で追加学習（ファインチューニング）を完了させることが可能です。

このようにオープンソースSLMを自社専用にチューニングすることで、汎用LLMで課題となる「ハルシネーション（もっともらしい嘘）」を抑え、自社製品の技術仕様書に正確に沿った応答を生成する専用AIを自社アセットとして保有できるようになります。特定の専門業務にタスクを絞り込むことで、パラメータ数に比例するサーバー利用料やAPI呼び出し料を抑え、長期的な視点での推論コスト削減と独自のデータ主権の確保が可能になります。

3. 企業がLLMからSLMへシフトするべき3つの経済的・システム的メリット

3-1. TCO（総所有コスト）を劇的に下げる推論コスト削減効果

SLMの採用がもたらす最大の経済的メリットは、運用規模（スケール）が拡大した際のコスト曲線の抑制にあります。外部APIを利用するLLMは、リクエスト数に比例して累積的にランニングコストが増加しますが、自社ホストが可能なSLMであれば、ハードウェアのリソース上限まで固定費に近い形で運用可能です。

具体的なコスト構造の比較として、月間1億トークン（入力7,000万トークン、出力3,000万トークン）を処理する社内問い合わせチャットボットを運用する場合のシミュレーションを以下に示します。

比較項目	外部LLM（API利用：GPT-4o想定）	SLM（オンプレミス/クラウド自社ホスト：Phi-3-mini 3.8B想定）
初期構築費用	ほぼ不要（APIキー取得のみ）	サーバー調達またはクラウド環境構築（約150,000円〜）
月間従量課金/システム運用費	約120,000円（$800相当 ※1ドル150円換算）	約110,000円（AWS g5.xlargeインスタンス 1基の常時稼働費）
トラフィック増加時のコスト耐性	トークン量に比例して無制限に増加（月10億トークンで約120万円）	固定（GPUの処理限界まで月額料金は不変。上限を超えた場合のみインスタンス追加）
自社サーバー（RTX 4090等）導入時	不可（外部ベンダー依存）	初期機材費約400,000円、2年目以降の月間コストは電気代のみ（数千円）

Microsoftが開発した「Phi-3-mini（38億パラメータ）」や、NTTが提供する「tsuzumi（70億パラメータ）」などのSLMは、コンシューマー向けのハイエンドGPU（NVIDIA RTX 4090など）や、安価なシングルGPUクラウドインスタンス（AWSのg5.xlargeなど）のメモリ内に完全に収まります。結果として、LLMからSLMへシステムを移行することで、中長期的なTCO（総所有コスト）を数割から最大90％以上削減することが可能になります。

3-2. オンプレミスAI・エッジAI化による完全なプライバシー保護

外部のLLM APIを利用する場合、どれほど厳格なプライバシーポリシーが提示されていても、自社のデータがインターネットを経由して外部サーバーを通過するというセキュリティ上の制約から逃れられません。特に、金融機関の個人情報、医療機関の電子カルテ、製造業の設計図面といった極秘データを扱う領域において、外部APIへのデータ送信はコンプライアンス上の大きな障壁となります。

例えば、ISO/IEC 27017などのクラウドセキュリティ基準や、FISC（金融情報システムセンター）安全対策基準への準拠が求められる金融システムでは、機密データの外部送信ログ監視だけで膨大な監査コストが発生します。SLMによる完全ローカル運用は、こうしたコンプライアンス監査に関わる工数を抜本的に引き下げます。必要なGPUメモリ（VRAM）が数GB〜十数GB程度で済むため、インターネットへの接続を物理的に遮断したイントラネット環境（エアギャップ環境）でも、完全にローカルで推論処理を完結できます。

さらに、スマートフォンのプロセッサや車載半導体、工場のIoTゲートウェイ（NVIDIA Jetsonシリーズなど）にSLMを組み込むことで、通信遅延（レイテンシ）をミリ秒単位にまで抑えたエッジAI環境が構築可能です。これにより、通信切断によるサービス停止リスクと、データ送信に伴う情報漏洩リスクの双方を完全に排除することができます。

3-3. 特定ドメインへのファインチューニング最適化

汎用LLMは幅広い知識を持つ一方で、社内特有のフォーマットや、難解な専門用語、業界固有の規則（コンプライアンス基準）に対して誤った情報を出力するハルシネーションを起こしやすいという弱点があります。LLMを特定の専門領域に適合させるためには膨大な計算資源が必要となりますが、SLMは限られたハードウェア資源でもLoRA（Low-Rank Adaptation）やQLoRAといったパラメータ効率の良い微調整技術（PEFT）を用いて、極めて短期間かつ低コストで適合させることが可能です。

一般的なファインチューニングのシステム構成は以下の通りです。

• データ準備層：特定のドメイン知識（医療ガイドライン、判例、社内の業務マニュアルなど）をPDFやテキストから抽出し、Q&A形式のインストラクションデータセットに変換。
• 学習層：ベースモデル（Phi-3やtsuzumi）のパラメータを固定したまま、LoRAアダプター（モデル全体の数％程度のパラメータ数）のみを、1台のRTX 4090等のGPUを用いて数時間で追加学習。
• 推論・実行層：学習済みアダプターをベースモデルに結合。必要に応じて、社内の構造化・非構造化データベースを検索するRAG（検索拡張生成）システムと組み合わせる。

Microsoftが公開したPhi-3の技術論文（Phi-3 Technical Report）によると、適切に高品質なデータでトレーニングされた38億パラメータのPhi-3-miniは、数十倍の規模を持つLlama 2（700億パラメータ）やMixtral 8x7Bなどのモデルを上回るベンチマークスコア（MMLUやMT-Bench）を、特定タスクにおいて記録しています。巨大な汎用モデルに高額な料金を支払い続ける必要はなく、ターゲットとなる業務領域に特化させたSLMを自社開発する方が、実務における回答精度と業務適合率を遥かに高く維持できることが証明されています。

4. 実業務への適用判断に使える「SLM vs LLM」選択基準チェックリスト

自社のシステム構築において、LLMとSLMのどちらを採用すべきかは、要求される要件によって明確に分岐します。モデルの選定ミスは、予期せぬAPI利用料の高騰や、ハードウェア性能不足によるシステムの遅延を招きます。技術選定の迅速な意思決定を支援するため、5つの判定基準を軸とした比較一覧を定義しました。

判定基準	SLM（スモール言語モデル）	LLM（大規模言語モデル）
応答速度（遅延）	10〜30ミリ秒クラスの低レイテンシ。リアルタイム応答やエッジAI処理に最適。	数百ミリ秒〜数秒。生成される回答の質は高いが、即時応答が必要なシステムには不向き。
予算制限	月間トークン消費量が多い場合、自社サーバー運用による大幅な推論コスト削減が可能。	API経由の従量課金が基本。リクエスト数に比例して運用コストが指数関数的に増加。
セキュリティ要件	完全なオンプレミスAI環境でのデプロイが可能。外部へのデータ流出リスクはゼロ。	一般に商用クラウドAPIを利用。厳格な業界規制（HIPAAやFISC等）を満たすための個別契約が必要。
ハードウェア制約	民生用GPU（例：NVIDIA RTX 4090）や、モバイルデバイスのCPU/NPUでも動作可能。	A100やH100など、エンタープライズ向けのハイエンドGPUサーバー群が必須。
要求される推論複雑度	単一ドメインの専門知識（金融、法律、社内規定など）に基づく情報抽出や分類。	多言語にまたがる複雑な論理思考、ゼロからアイデアを生み出すクリエイティブな執筆。

この「LLMとSLMの違い」をふまえ、自社の開発要件がどのユースケースに該当するかを以下の詳細なシナリオから判断してください。

4-1. 機密データを扱う社内ナレッジ検索（RAG）での選定基準

自社独自の規程、マニュアル、顧客対応履歴といった機密データを用いた検索拡張生成（RAG）を構築する場合、セキュリティと運用コストが最優先事項になります。この用途においてSLMは、極めて高い投資対効果（ROI）を発揮します。

たとえば、Microsoftが開発したPhi-3-mini（パラメータ数38億）や、NTTが開発した日本語特化型モデルtsuzumi（Light版：パラメータ数70億）は、適切にチューニングを施すことで、RAGにおけるコンテキスト理解と回答生成においてLLMと遜色ない精度を実現できます。Microsoftの技術レポートによると、Phi-3-miniは「MMLU」ベンチマークにおいて68.8%を記録しており、これは前世代の巨大LLMであるGPT-3.5に匹敵する性能です。

外部サーバーへのデータ転送が禁じられている金融業や医療機関、あるいは防衛関連プロジェクトでは、オンプレミスAIの導入が必須となります。130億パラメータ以下のSLMであれば、1枚のNVIDIA A10G GPU（ビデオメモリ24GB）を搭載したオンプレミスサーバーで高速に推論を実行できます。月間1,000万トークンを処理するRAGシステムを構築する場合、GPT-4o APIを利用すると月額で数十万円規模のランニングコストが発生し続けますが、SLMによるインハウス運用であれば、サーバーの電気代と初期設備投資のみにコストを抑えられ、劇的な推論コスト削減が達成できます。

4-2. オフライン動作や組み込みが求められるエッジデバイスでの選定基準

通信環境に依存しないオフラインでの動作や、物理的なハードウェアへの組み込みが必要なユースケースでは、SLMの採用が事実上の必須条件となります。これはエッジAIと呼ばれる領域であり、従来のLLMでは物理的に不可能な動作環境です。

スマートフォン、自動運転車、工場のFA（ファクトリーオートメーション）機器、スマート家電などにAIモデルを組み込む場合、利用可能なシステムメモリ（RAM）や消費電力に極めて厳しい制約があります。たとえば、38億のパラメータ数を持つPhi-3-miniは、INT4（4ビット量子化）を施すことで、モデルサイズをわずか約2.2GBにまで軽量化できます。これにより、一般的なスマートフォン（iPhone 15等）や、シングルボードコンピュータであるRaspberry Pi 5上のCPU、NPU（Neural Processing Unit）で毎秒10トークン以上の速度で直接推論を動作させることが可能になります。

遅延（レイテンシ）の観点でもエッジ側でのSLM処理は優位です。自動運転における道路標識の瞬時の認識や、音声対話アシスタントのリアルタイムな応答には、ミリ秒単位の処理速度が求められます。クラウドを経由するLLMでは、ネットワーク往復遅延（RTT）だけで100〜300ミリ秒を消費しますが、ローカル環境で動作するSLMであれば、ネットワーク遅延ゼロで直接推論を実行でき、クリティカルな要件を満たすことができます。

4-3. 複雑な論理思考やクリエイティブな執筆が求められるタスクでのLLM優位性

一方で、特定の領域においては、どれだけSLMをファインチューニングしてもLLMの性能に届かない境界線が存在します。それが、「複雑な複数ステップの論理思考（マルチホップ推論）」や「広範な文化的背景を考慮したクリエイティブなコンテンツ制作」を要求されるタスクです。

例えば、新規ビジネスの競合分析から事業計画書をドラフトする、法的な契約書の問題点を多角的に洗い出す、あるいは多国籍市場に向けた製品の広告コピーをローカライズしつつ創出するといったタスクがこれに該当します。こうした作業には、数千億から数兆規模のパラメータ数を持つGPT-4やClaude 3.5 SonnetのようなLLMが持つ「創発的（Emergent）能力」が必要です。ベンチマークテスト「GSM8K（小学生レベルの算数文章題）」において、多くのSLMはファインチューニングを重ねても80%前後の正答率に留まりますが、最新のLLMは95%以上の精度で、複雑な数式の証明や高度なプログラミングのデバッグをシームレスに遂行します。

SLMは、限られた容量内に特定の知識やタスク（例えば「SQLクエリの生成」や「カスタマーサポートの定型文生成」）を圧縮して記憶させることには長けていますが、学習データに含まれない未知の課題に対する汎用的な推論能力は物理的なパラメータ数の制限に縛られます。したがって、業務要件が「定型業務の自動化」や「ルールベースに近い特定タスクの処理」に留まるのか、それとも「非定型で極めて高い柔軟性と創造性が求められる知的作業」であるのかが、LLMを使い続けるべきかどうかの最終的な分岐点となります。

5. 自社にSLMを導入・運用するための3ステップロードマップ

自社ビジネスや特定のローカル環境でSLMを実用化するためには、処理能力、インフラコスト、デプロイ先デバイスの制約から逆算した計画が必要です。開発チームが実作業に着手するための具体的な実装プロセスを、3つの段階に分けて解説します。

5-1. 1. ビジネス要件定義とモデル選定のステップ

最初のステップは、自社の業務要件に適したベースモデルの選定です。LLMとSLMの違いを評価する上で最も重要な基準は、タスクの複雑度とハードウェア制約のバランスです。月間1,000万トークン規模の社内文書要約を行うシステムにおいて、API経由の大規模モデル（LLM）からオープンソースのSLMへ移行する場合、インフラを自社でホストすることで大きな推論コスト削減が実現できます。

ベースモデル選定の具体的なToDoリストは以下の通りです。

• タスクの特定と切り出し： 高度な推論（複雑なコード生成など）が必要なタスクと、定型的なテキスト分類・要約・固有表現抽出などSLMで十分対応可能なタスクを分離する。
• ハードウェア制約の確認： オンプレミスAI環境やクライアントPC、スマートフォンなどのエッジデバイスで動作させる場合、利用可能なVRAM（GPUメモリ）またはシステムメモリの容量を上限として画定する。
• ライセンスの確認： 商用利用が可能であるかを確認する（Apache 2.0やMIT、独自商用ライセンスなど）。

モデル名	動作環境（デプロイ先）	推奨最小VRAM容量（量子化適用時）	想定される業務用途
Phi-3-mini (3.8B)	スマートフォン、タブレット、ノートPC等	約2.2GB（INT4量子化時）	ネットワーク切断環境下での現場入力支援、エッジ音声対話
tsuzumi 軽量版 (7B)	社内プライベートクラウド、オンプレミスサーバー	約4.5GB（INT4量子化時）	日本語ビジネス文書の処理、帳票や稟議書の画像認識を含むRAG
Llama-3 (8B)	中規模クラウドインスタンス、ワークステーション	約5.5GB（INT4量子化時）	多言語をまたぐ社内ドキュメントの要約、顧客メールの自動分類・起稿

例えば、VRAMが16GB搭載されたNVIDIA RTX 4000クラスのワークステーションを1台用意できる場合、後述する量子化を行わずに動作させるベースモデルとしては、パラメータ数7Bから8B以下のモデル（tsuzumiやLlama-3-8Bなど）が適切な選択肢となります。

5-2. 2. ファインチューニングとドメイン適応のステップ

汎用のSLMを自社の専門用語や社内ドキュメントに適応させるため、ドメイン特化データを用いたファインチューニングを行います。SLMはLLMと比較してパラメータ数が少ないため、限られたハードウェア資源でも効率的な学習（LoRA：Low-Rank Adaptation）が可能です。例えば、コンタクトセンターの過去の対応履歴1万件（QAペア）を用いて学習する場合、フルパラメータのチューニングではなくLoRAを採用することで、計算資源を劇的に削減できます。

ファインチューニング準備作業のToDoリストは以下の通りです。

• 学習用データの収集とクレンジング： 社内マニュアルやFAQ、過去のログから、入力（Instruction）と出力（Response）のペアデータを最低でも2,000〜5,000件作成する。ノイズデータ（HTMLタグや不要な改行、個人情報）は正規表現や簡易スクリプトで完全に除外する。
• フォーマットの統一： 選択したベースモデル（例：Phi-3）が推奨するチャットテンプレート（<|user|>や<|assistant|>などの特殊トークン）に沿って、JSONL形式でトレーニングデータを整形する。
• LoRAハイパーパラメータの設定： 更新対象の重みを制御するランク（Rank: r）を「8」または「16」、スケーリング因子（Alpha）を「16」または「32」に設定し、ターゲットモジュールとしてSelf-Attention層の q_proj, v_proj を指定する。これにより、更新パラメータ数を全体の0.1%以下に抑え、VRAM 24GBクラスのGPU（A10GやRTX 3090/4090など）1枚で数時間のファインチューニングを可能にする。

この段階で、Hugging Faceの TRL (Transformer Reinforcement Learning) ライブラリに含まれる SFTTrainer を用いることで、コード数行でLoRAの実行スクリプトを記述できます。

5-3. 3. ローカル環境・エッジデバイスへのデプロイと評価ステップ

ファインチューニングされたSLMは、実用的な推論速度を得るために圧縮・量子化処理を行い、対象環境（オンプレミスAIサーバー、PC、エッジAI端末など）へデプロイします。そのままの浮動小数点数（FP16やBF16）では、エッジデバイスでの実行時にメモリ帯域がボトルネックとなり、1秒あたりの出力トークン数（Tokens Per Second）が極端に低下するためです。

デプロイと評価ステップの具体的なToDoリストは以下の通りです。

• 量子化によるファイルサイズとメモリ削減： llama.cpp などのオープンソースツールを用いて、モデルの重みを4bit（INT4、またはGGUFの Q4_K_M フォーマット）に量子化する。Phi-3-mini（3.8B）をINT4に量子化した場合、モデルサイズは約2.2GBまで圧縮され、8GBメモリのモバイルデバイスやシングルボードコンピュータ（NVIDIA Jetson Orin Nanoなど）でも秒間30トークン以上の高速動作が可能となる。
• 推論エンジンの選定と最適化：
  • Intel CPU環境で動かす場合は、OpenVINOフォーマットへ変換する。
  • NVIDIA製GPUを搭載したサーバーに展開する場合は、TensorRT-LLMを用いてビルド、またはONNX Runtime形式へ変換することで、推論時のスループットを最大化する。
• ハルシネーションとレスポンス精度の評価： ドメイン適応後のモデルに対し、学習データに含まれないテスト用質問を100件以上用意して検証する。生成された回答が社内事実に基づいているかを評価し、必要に応じてRAG（検索拡張生成）システムとの組み合わせを行う。

このように、モデルを軽量化（量子化）し、ターゲットハードウェアに最適化されたランタイム（ONNXやTensorRT-LLM）に載せるプロセスを経ることで、通信遅延のない、堅牢なローカルAI・オンプレミスAI運用環境が確立されます。

よくある質問（FAQ）