SLMディスティレーションとは？大規模LLMから小型特化モデルを作る方法

SLM ディスティレーションとは、大規模言語モデル（LLM）が学習した知識を、より小型の言語モデル（SLM）へ効率よく転移させる技術です。知識蒸留（Knowledge Distillation）の一手法として、2015 年に Hinton らが発表した論文を起点に発展し、近年は 7B パラメータ以下の SLM を業務特化モデルとして構築する用途で広く活用されています。

本記事は、オンプレミスやエッジ AI 環境へのプライベート AI 導入を検討しているエンジニア・アーキテクト向けに執筆しています。読み終えると、次の 3 点を体系的に理解できます。

結論: SLM ディスティレーションは、大規模 LLM の知識を小型モデルへ転移させる技術であり、プライベート AI 構築の中核手法です。

知識蒸留（Knowledge Distillation）の概念を LLM に適用したこの手法は、2015 年に Hinton らが提唱した原理を基盤とします。

「ナレッジトランスファー（Knowledge Transfer）とナレッジディスティレーション（知識蒸留）は同じ意味だ」と最初は考えがちですが、実際にはディスティレーションはナレッジトランスファーの一実装手法であり、目的・手続き・出力物が明確に異なります。

両者の主な違いは以下のとおりです。

• ナレッジトランスファー: 人・組織・システム間で知識を移転させる概念全般を指す広義の用語。ドキュメント化、研修、モデルの重みコピーなども含まれる
• 知識蒸留（ナレッジディスティレーション）: ティーチャーモデルの出力分布（ソフトラベル）を使い、スチューデントモデルを訓練する具体的な機械学習手法。Geoffrey Hinton らが 2015 年に発表した論文「Distilling the Knowledge in a Neural Network」（arXiv:1503.02531）で定式化された

蒸留の核心は「ソフトラベル」にあります。通常の教師あり学習では正解クラスに 1、それ以外に 0 を割り当てるハードラベルを使います。一方、蒸留では LLM が出力する確率分布全体（例:「猫:0.7、犬:0.2、虎:0.1」）をそのまま学習信号として使うため、クラス間の類似関係といった暗黙的な知識もスチューデントモデルへ伝わります。

この違いが実装上の判断に直結します。

知識蒸留（Knowledge Distillation）では、大規模な LLM を「ティーチャーモデル」、軽量化された SLM（Small Language Model）を「スチューデントモデル」と呼びます。両者の役割は明確に分かれており、ティーチャーは知識の供給源、スチューデントはその知識を受け取り実用環境で動作する存在です。

ティーチャーモデルの主な役割は次のとおりです。

• 入力に対して「ソフトラベル」（各トークンの確率分布）を生成する
• 正解・不正解だけでなく、クラス間の類似関係まで含む豊かな情報を提供する
• スチューデントが模倣すべき「暗黙の知識」を確率分布に乗せて伝える

スチューデントモデルの主な役割は次のとおりです。

• ティーチャーのソフトラベルを教師信号として学習し、同様の出力分布を再現する
• パラメータ数を抑えながら、特定タスクでティーチャーに近い精度を達成する
• オンプレミスやエッジ環境など、リソース制約のある環境で推論を実行する

判断軸として重要なのは、タスクの汎用性です。広範なドメインをカバーしたい場合はティーチャーに大規模オープンウェイトモデルを選び、社内文書や特定業務に絞るならティーチャーの出力から生成した合成データ（Synthetic Data）で集中的に学習させるほうが効率的です。

スチューデントの学習では、ティーチャーの出力確率分布と正解ラベルの両方を損失関数に組み込む「蒸留損失」が使われます。

「SLM と LLM は同じ Transformer ベースなのに、なぜここまで動作が違うのか」と戸惑うエンジニアは少なくありません。両者の差異を理解することが、ディスティレーション設計の出発点になります。

最も根本的な違いはパラメータ数です。LLM は数百億から数千億のパラメータを持つのに対し、SLM はリサーチノートにある通り 7B（70 億）パラメータ以下を主な対象とする研究が多く、モデルサイズが桁違いに異なります。

アーキテクチャ上の主な相違点は以下の通りです。

• レイヤー数とヘッド数: LLM は Transformer のブロック数・アテンションヘッド数ともに大きく、表現力が高い。SLM はこれらを大幅に削減してメモリフットプリントを抑えます
• コンテキストウィンドウ: LLM は長文脈を扱えるよう広いコンテキストウィンドウを持ちますが、SLM では縮小されるケースが多く、長い会話履歴や文書の処理に制約が生じます
• MoE（Mixture of Experts）の採用有無: 大規模モデルでは推論コストを抑えるために MoE 構造を採用するものがありますが、SLM では Dense Model（密結合モデル）構成が主流です

これらの制約はそのままディスティレーションの難しさにつながります。ティーチャーモデルが持つ豊かな中間表現を、層数が少ないスチューデントモデルへ圧縮して転移させなければならないためです。

結論: コスト・プライバシー・エッジ展開の3要件が重なり、SLMディスティレーションへの関心が急速に高まっている。

クラウドAPI依存からの脱却、オンプレミス運用でのデータ主権確保、そしてエッジデバイスへの軽量モデル展開という3つのニーズが同時に顕在化しています。各H3では、それぞれの背景と具体的な活用文脈を詳しく掘り下げます。

生成 AI の活用が広がる一方で、「社内データをクラウドに送りたくない」という声は現場で根強く残っています。医療・金融・製造など規制の厳しい業種では、個人情報や営業機密を外部 API に渡すこと自体がコンプライアンス上のリスクになるケースが少なくありません。

最初は「クラウド API を使いながらプロンプトで制御すれば十分」と考えがちですが、実際にはデータ送信ログの監査義務や契約上の制約が壁になり、オンプレミスまたはプライベートクラウドへの完全内製化を選ぶ組織が増えています。SLM ディスティレーションは、この要件に応える有力な手段です。

プライベート AI をオンプレミスで運用する際の主な課題は以下の通りです。

• 推論コスト: 大規模モデルをそのままオンプレミスで動かすには高性能 GPU サーバーが必要で、調達・維持コストが高くなる傾向があります
• レイテンシ: 社内システムとのリアルタイム連携では、クラウドへの往復遅延が許容されない場面があります
• データガバナンス: ログや推論履歴を自社管理下に置くことで、監査や GDPR・業界規制への対応が容易になります

SLM ディスティレーションを使えば、大規模モデルの知識を 7B パラメータ以下の小型モデルに凝縮できるため、既存のオンプレミスサーバーや GPU 1〜2 枚の環境でも実用的な推論が可能になります。クラウド依存を断ちながら、業務特化の精度を維持できる点が、この手法が注目される核心的な理由です。

SLM ディスティレーションの恩恵が最も顕著に現れるのが、エッジ AI への展開場面です。

ディスティレーションで得られた小型モデルは、クラウド API に頼らずオンデバイスで推論を完結させられます。これにより、ネットワーク遅延の排除・通信コストの削減・データのオンプレミス完結という三つの利点が同時に得られます。製造ラインの異常検知や医療現場でのリアルタイム判定など、レイテンシとプライバシーの両方が求められる用途で特に有効です。

GPU コストの観点では、次の条件分岐が判断の基準になります。

• 推論を大量かつ継続的に行う場合: クラウド GPU の従量課金は積み上がりやすく、7B 以下の SLM をオンプレミスの小型 GPU（例: NVIDIA A100 の代わりに T4 クラス）で稼働させるほうがトータルコストを抑えられる傾向があります。
• 推論頻度が低い PoC 段階の場合: クラウド API をそのまま使い、SLM への移行は本番化の直前に行うほうが開発コストを節約できます。

学習（ディスティレーション）フェーズ自体も、ティーチャーモデルの推論をオフライン合成データとして事前生成しておくことで、スチューデントモデルの学習に必要な GPU 時間を圧縮できます。大規模な GPU クラスタを常時確保せず、スポットインスタンスやバースト利用で賄えるケースも報告されています。

「ディスティレーション、ファインチューニング、量子化の3つが並んでいるとき、どれから手をつければいいのか」と悩む現場は少なくありません。それぞれの目的と適用フェーズを押さえておくと、判断がしやすくなります。

まずファインチューニングは、既存モデルのパラメータを追加学習で更新し、特定ドメインへ適応させる手法です。モデルのサイズ自体は変わらないため、「精度を上げたいが、規模はそのままでよい」という場面に向いています。量子化（Quantization）は、重みの数値精度を下げることで（たとえばFP32からINT8へ）、推論時のメモリ使用量と計算コストを削減します。モデルの構造は維持したまま軽量化できるのが特徴です。そして知識蒸留は、大きなティーチャーモデルの出力分布を手がかりに、より小さなスチューデントモデルを一から訓練する手法で、モデルの規模そのものを圧縮できる点で他の2つとは性質が異なります。

整理すると、ドメイン適応が目的ならファインチューニング、既存モデルをそのまま速く・軽くしたいなら量子化、大規模モデルの能力を小型モデルへ移植したいなら知識蒸留、という使い分けが基本になります。

また、これらの手法は互いに排他的ではありません。蒸留で小型化したスチューデントモデルに対して、さらにファインチューニングでドメイン適応を施し、最後に量子化で推論コストを削る、という組み合わせは実際によく取られるアプローチです。精度・速度・サイズを同時に最適化したい場合は、この重ね掛けを検討する価値があります。

結論: ディスティレーション成功の鍵は、学習開始前の準備段階にある。

ティーチャーモデルの選定、合成データの品質管理、MLOps パイプラインの整備という3つの準備が、スチューデントモデルの最終品質を左右します。

ティーチャーモデルの選定は、ディスティレーション全体の品質を左右する最初の意思決定です。最初は「最も高性能なクラウド API モデルをティーチャーに使えばよい」と考えがちですが、実際にはオープンウェイトモデルをローカル環境で動かすほうが、ライセンス・コスト・データ主権の三点でバランスが取りやすいケースが多いです。

選定の主な判断軸は以下の 3 点です。

• タスク適合性: ティーチャーモデルが対象ドメイン（法務・医療・製造など）に関する十分な知識を持っているか確認する。汎用モデルで対応できない専門領域では、同ドメインで追加学習済みのモデルを選ぶことが有効です
• ライセンスの互換性: 生成したソフトラベルや合成データを商用利用する場合、ティーチャーモデルのライセンスが許諾しているかを事前に確認する。オープンウェイトモデルでもライセンスによって商用利用に制限がある場合があります
• 推論コストと出力速度: ソフトラベル生成には大量のサンプルを処理するため、推論スループットが低いモデルはパイプライン全体のボトルネックになります

オープンウェイトモデルを活用する実践的なアプローチとしては、LLaMA 系（7B / 13B / 33B / 65B）のような段階的なサイズ展開が参考になります。まず 13B クラスをティーチャーとして使い、7B 以下のスチューデントへ蒸留するという構成は、GPU コストを抑えながら品質を維持しやすい設計です。

ティーチャーモデルが高品質でも、学習データが貧弱であれば蒸留の効果は大きく損なわれます。実務では社内データだけでは量が不足するケースが多く、合成データ（Synthetic Data）の活用が不可欠になります。

合成データの生成には、主に以下の 2 つのアプローチが使われます。

• ティーチャー自身による生成: ティーチャーモデルに多様なプロンプトを与え、回答とソフトラベルを同時に出力させる方法。ドメイン特化の質問テンプレートを用意することで、業務に即したデータを効率よく収集できます
• 既存コーパスの変換: 社内マニュアルや FAQ を LLM に渡し、質問・回答ペアへ変換する方法。元データの著作権・機密性を事前に確認することが重要です

品質管理では、生成データをそのまま使うのは避けるべきです。具体的なフィルタリング基準として、次の観点を設けることが推奨されます。

• 一貫性チェック: 同じ質問に対してティーチャーが矛盾した回答を返していないか検証する
• ハルシネーション（Hallucination）スクリーニング: 事実確認が難しい主張を含む行を除外する
• 多様性の確保: 類似サンプルの重複を減らし、スチューデントモデルが偏った分布を学ばないようにする

条件分岐の観点では、ドメインが狭く社内データが十分にある場合は変換アプローチが低コストで効果的ですが、新規ドメインや社内データが乏しい場合はティーチャー生成を主軸に据えて多様なプロンプトを設計するほうが精度向上につながりやすいです。

「ティーチャーモデルの推論環境とスチューデントの学習環境を別々に用意しなければならないのか」——ディスティレーション初挑戦の現場では、こうした疑問が最初の壁になりがちです。

MLOps パイプラインの設計では、大きく次の 3 層を整備します。

• データ層: 合成データの生成・フィルタリング・バージョン管理。フィーチャーストアや DVC などのデータバージョン管理ツールを用いると、品質変更の追跡が容易になります
• 学習層: ティーチャーモデルによるソフトラベル生成ジョブと、スチューデントモデルの学習ジョブをパイプラインとして分離します。GPU メモリが限られる場合は、ティーチャー推論を先行バッチ処理してラベルをキャッシュしておく方法が有効です
• 評価・デプロイ層: 評価指標の自動計算、モデルレジストリへの登録、オンプレミスまたはエッジ環境へのデプロイを CI/CD フローに組み込みます

インフラ面では、NVIDIA A100 クラスの GPU が理想ですが、PEFT（パラメータ効率型ファインチューニング）や LoRA を組み合わせれば、より小型の GPU でも学習が可能なケースがあります。オンプレミス運用を前提とする場合は、モデルのアーティファクトと学習データを外部クラウドに送出しない設計を最初から組み込むことが重要です。

結論: 実装は「ソフトラベル生成 → スチューデント学習 → 評価・整備」の 3 ステップで進める。各工程の順序と品質管理が最終モデルの精度を左右する。

準備が整ったら、具体的な実装フェーズへ移ります。ティーチャーモデルからのソフトラベル生成、PEFT・LoRA を活用したスチューデントの学習、そして評価とモデルカード整備という 3 つのステップを順に解説します。

ソフトラベルの生成は、ディスティレーション全体の品質を左右する最重要ステップです。

最初は「ティーチャーモデルのハードラベル（正解クラスのみ）をそのまま使えばよい」と考えがちですが、実際はソフトラベル（各トークンの確率分布）を使うほうが、スチューデントモデルの汎化性能が大きく向上します。ハードラベルは正解以外の情報を捨ててしまうのに対し、ソフトラベルにはティーチャーモデルが学習した語彙間の意味的な近さや曖昧さが凝縮されているためです。

ソフトラベル生成の基本手順

• 温度パラメータ（Temperature）を設定する: 出力確率分布を温度 T で平滑化します。T=1 では元の分布のまま、T>1 にすると低確率トークンにも情報が乗り、スチューデントが学習しやすくなります。Hinton らの原論文（arXiv:1503.02531）でも T を大きくすることで転移効率が上がると報告されています。
• ロジットを保存する: 推論時に最終層のロジット（softmax 前の生スコア）をファイルや特徴量ストアに書き出します。トークンごとの確率分布として保持することで、後続の学習ステップで KL ダイバージェンス損失を計算できます。
• バッチサイズと推論コストを見積もる: 大規模なコーパスを処理する場合、ティーチャーモデルの推論コストが想定外に膨らむことがあります。合成データを活用して推論対象を業務ドメインに絞り込むと、コストと品質のバランスが取りやすくなります。

ソフトラベルを用意したら、次はスチューデントモデルの学習フェーズです。フルパラメータの再学習は GPU コストが高いため、実務では PEFT（パラメータ効率型ファインチューニング）の代表手法である LoRA を組み合わせるのが一般的です。

LoRA は重み行列に低ランクの差分行列を追加するアプローチで、更新対象パラメータを全体の数パーセント程度に絞れます。これにより、7B クラスのスチューデントモデルでも、コンシューマー向け GPU 1 枚で学習を完結させられるケースがあります。

学習設定の判断軸として、次の条件分岐が実務で役立ちます。

• ドメイン特化データが豊富な場合: LoRA ランクを高め（例: rank=64）、学習エポック数を増やして専門知識を深く吸収させる
• データ量が限られる場合: ランクを低く抑え（例: rank=8〜16）、過学習を防ぐために早期停止と検証ロスのモニタリングを徹底する

損失関数はソフトラベルに対する KL ダイバージェンスとハードラベルに対するクロスエントロピーを組み合わせる構成が標準的です。両者の比率を調整するハイパーパラメータ（温度スケーリングの温度 T など）は、検証セットの性能を見ながら調整します。

学習中は以下の点を継続的に監視してください。

「蒸留は終わった、あとはデプロイするだけ」と思ったとき、評価フェーズを省略するのが最も多い失敗パターンです。スチューデントモデルの品質は、ティーチャーモデルとの比較評価なしに担保できません。

評価の主要指標

• タスク精度: 対象業務のベンチマーク（QA・分類・要約など）でティーチャーとスチューデントのスコアを比較する
• ハルシネーション（Hallucination）率: 事実確認が必要なドメインでは、誤答率を別途測定する
• レイテンシ・スループット: エッジ AI やオンプレミス環境での推論速度を実測し、要件を満たすか確認する
• コンテキストウィンドウ（Context Window）対応: 長文入力での精度劣化がないかをテストする

評価データは学習に使用していないホールドアウトセットを用意することが基本です。合成データ（Synthetic Data）のみで評価すると、実運用との乖離が見えにくくなるため、実業務に近いサンプルを一定数含めることが推奨されます。

モデルカード（Model Card）の整備

評価が完了したら、モデルカードに以下を記録します。

• ティーチャーモデルの名称・バージョン
• 学習データの出所と合成データの割合
• 評価指標と達成値
• 既知の限界（対応外のドメイン・言語など）
• ライセンスと利用制限

モデルカードは、AIガバナンスや社内監査への対応にも直結します。

結論: ディスティレーションの失敗は、品質劣化・トークンずれ・推論精度低下の3パターンに集約される。事前に対策を知ることで手戻りを防げる。

実装を進めると、ハルシネーションの増加やトークン分布のずれなど、特有の問題が顕在化しやすいです。各 H3 では代表的な失敗パターンとその回避策を具体的に解説します。

ディスティレーション後のスチューデントモデルで最初に直面しやすい問題が、ハルシネーション（Hallucination）の増加です。ティーチャーモデルが持つ「曖昧さを保ったまま答える能力」が、蒸留の過程で十分に転移されないケースが報告されています。

最初は「スチューデントモデルの規模を大きくすれば解決する」と考えがちですが、実際はデータ品質の改善と評価ループの強化のほうが効果的なことが多いです。モデルサイズを増やすよりも、ティーチャーが生成したソフトラベルの信頼スコアでデータをフィルタリングし、低品質なサンプルを除外するアプローチが品質劣化の抑制につながります。

ティーチャーモデルとスチューデントモデルの語彙（ボキャブラリ）が一致していない場合、ソフトラベルのトークン確率分布をそのまま転移できないという問題が生じます。BPEトークナイザー（Byte-Pair Encoding Tokenizer）はモデルごとに語彙サイズや分割ルールが異なるため、同じ単語でも異なるトークン列に変換されるケースが少なくありません。

この問題が起きやすい典型的な状況は次の通りです。

• ティーチャーが 32,000 語彙のトークナイザーを使い、スチューデントが 16,000 語彙を使う場合、確率マッピングに欠損が生じる
• 日本語・多言語ドメインでは、英語中心で学習されたトークナイザーが漢字や仮名を細かく分割しすぎ、1 文字が複数トークンになるケースがある
• 専門用語（医療・法律・製造など）が未知トークン（UNK）扱いになると、ソフトラベルの情報量が大幅に落ちる

対処の判断軸として、ティーチャーとスチューデントが同系列のトークナイザーを共有している場合は確率分布を直接利用できますが、異なるトークナイザーを使う場合はトークン列の再アライメント処理か、ソフトラベルではなくハードラベル（正解ラベル）ベースの蒸留へ切り替えることを検討してください。

実装上の注意点をまとめます。

「蒸留後のモデルが長い文書を渡すと急に回答品質が落ちるのはなぜか」と疑問に思った経験はないでしょうか。これはコンテキストウィンドウの縮小が引き起こす典型的な問題です。

ティーチャーモデルは数万トークンに及ぶコンテキストウィンドウを持つケースがありますが、スチューデントモデルはパラメータ数の削減に伴い、扱えるトークン数も制約されやすくなります。学習時に短い入力シーケンスのみでソフトラベルを生成した場合、スチューデントモデルは長距離依存の推論パターンを十分に習得できません。

具体的に問題が起きやすい場面は以下のとおりです。

• 複数ドキュメントの横断参照: 前半の文脈を後半の回答に活かす必要がある要約・Q&A タスク
• マルチステップ推論: CoT（思考連鎖）を伴う問題で、途中の推論ステップが切り捨てられるケース
• 長文の社内ドキュメント検索: RAG と組み合わせた際にチャンクサイズがウィンドウ上限を超えるケース

回避策として有効なアプローチを以下に示します。

• 蒸留用データセットに長い入力サンプルを意図的に含める。

Q1. ディスティレーションとファインチューニングはどちらを先にすべきか？

原則として、ディスティレーションを先に行い、業務ドメインに特化した小型モデルを作ってから、タスク固有のファインチューニングを重ねる順序が推奨されます。ディスティレーションでティーチャーモデルの汎用知識を転移させた後、少量の高品質な業務データでファインチューニングすることで、精度とコストのバランスが取りやすくなります。ただし、既存のオープンウェイトモデルがベースとして十分な場合は、ディスティレーションを省略してファインチューニングのみで対応するケースもあります。

---

Q2. ローカル LLM と SLM ディスティレーションはどう使い分けるか？

ローカル LLM はオープンウェイトモデルをそのままオンプレミスや自社サーバーで動かす方法で、導入の手軽さが利点です。一方、SLM ディスティレーションは特定業務に特化した独自モデルを構築するアプローチであり、推論速度・コスト・プライバシーの観点でさらなる最適化が求められる場面に向いています。まずローカル LLM / SLM 導入比較 — クラウド API に依存しない AI 活用で既存モデルを評価し、精度・速度が要件を満たさない場合にディスティレーションへ進む判断が現実的です。

---

Q3. ディスティレーションに必要な GPU リソースはどの程度か？

スチューデントモデルのパラメータ規模によって大きく異なります。7B パラメータ以下の SLM を対象とする場合、学習フェーズでは NVIDIA A100 相当の GPU が一般的に使われます。LoRA や QLoRA などの PEFT 手法を組み合わせることで、フルファインチューニングと比べてメモリ使用量を大幅に抑えられる傾向があります。推論フェーズでは、量子化（Quantization）を適用すれば一般的なサーバー GPU でも運用できるケースが報告されています。

---

Q4. 合成データだけでディスティレーションは成立するか？

ティーチャーモデルが生成した合成データのみでも学習は可能ですが、品質管理が不十分だとハルシネーション（Hallucination）が増加するリスクがあります。実務では、合成データに少量の実データや人手でレビューしたサンプルを混在させる手法が品質安定に効果的とされています。合成データの生成条件（温度パラメータやプロンプト設計）を記録し、モデルカード（Model Card）に明記することで再現性と透明性を確保することが重要です。

---

Q5. ディスティレーション済みモデルの継続的な品質維持はどうすればよいか？

本番運用後は、AIオブザーバビリティ（AI Observability）の仕組みを組み込み、出力品質の定期モニタリングを行うことが推奨されます。業務データの分布が変化した場合は、ティーチャーモデルで追加の合成データを生成し、差分ファインチューニングで対応するサイクルが有効です。MLOps パイプラインに評価・再学習フローを組み込んでおくことで、モデルの陳腐化を継続的に防ぐことができます。

最初はファインチューニングから始めようとするケースが多いですが、実際はディスティレーションを先に行うほうが、最終的な精度と効率の両面で有利になるケースが多いです。

理由は学習の「起点」にあります。ファインチューニングはベースモデル（Foundation Model）が持つ知識をそのまま活用しますが、スチューデントモデルがそもそも小さい場合、ベースモデル単体では業務タスクに必要な知識の密度が不足しがちです。ディスティレーションによってティーチャー LLM のソフトラベルを先に学習させておくと、スチューデントモデルの表現力が底上げされ、その後のファインチューニングがより効果的に機能します。

推奨する順序は以下のとおりです。

• Step 1 — ディスティレーション: ティーチャー LLM からソフトラベルを生成し、スチューデントモデルに汎用的な知識を転移させる
• Step 2 — ファインチューニング（PEFT / LoRA）: ドメイン固有データで追加学習し、業務タスクへの特化を図る
• Step 3 — 量子化（Quantization）: エッジ AI やオンプレミス環境向けにモデルサイズをさらに圧縮する

ただし、すでに十分な規模のオープンウェイトモデルをベースにする場合は、ディスティレーションを省略してファインチューニングのみで目標精度に達することもあります。

両者は「既製品を使うか、専用品を作るか」という軸で考えると整理しやすいです。

ローカル LLM は、オープンウェイトモデルをそのままオンプレミスやエッジ環境で動かすアプローチです。追加学習なしですぐに利用でき、汎用的な質問応答や要約タスクには十分な性能を発揮します。一方、SLM ディスティレーションは特定ドメインの知識や出力スタイルをスチューデントモデルへ転移させるため、初期構築コストがかかる代わりに業務特化の精度が得られます。

判断の分岐点は次のように整理できます。

• 汎用タスクで即時稼働が必要な場合はローカル LLM をそのまま採用する
• 特定ドメイン（法務・医療・製造など）で高精度が求められる場合は SLM ディスティレーションで専用モデルを構築する
• 推論コストやレイテンシを極限まで削りたいエッジ AI 用途では、ディスティレーション済みの小型モデルが有利になる傾向があります

PoC 段階ではローカル LLM で要件を検証し、精度や応答速度が基準を満たさない場合にディスティレーションへ移行するという段階的アプローチも有効です。最初からディスティレーションに着手すると、合成データ生成や MLOps パイプラインの整備に工数がかかりすぎるリスクがあります。

なお、両手法は排他的ではありません。ローカル LLM をティーチャーモデルとして使い、そこからディスティレーションで小型モデルを派生させる構成も実用的な選択肢です。