SLM（Small Language Models）のエッジ展開とは、クラウドのAPIに依存せず、デバイスやオンプレミスのサーバー上で軽量な言語モデルを直接動作させる実装手法である。 ネットワークが不安定な製造現場、データを外部に出せない金融・医療の環境、API課金を抑えたい高頻度処理——こうした制約下では、数十億パラメータ規模のSLMをローカルで動かす構成が現実的な選択肢になる。

本ガイドは、エッジでSLMを動かしたいエンジニア・技術担当者を対象に、モデル選定と量子化、ランタイムの導入、推論パイプラインの構築、そして本番でつまずきやすいトラブルの対処までを、手順に沿って解説する。読み終えたとき、自社の環境でどのモデルをどう動かすかの判断軸が持てる状態を目指す。

SLMは「小さいLLM」ではなく、限られたリソースで動かすことを前提に設計思想が異なるモデル群だ。まずLLMとの違いを整理し、なぜリソース制約のある環境でSLMが選ばれるのかを押さえておく。

一般にLLMは数百億〜数千億パラメータを持ち、高性能なGPUと大容量のVRAMを前提とする。対してSLMは概ね1B〜10B（10億〜100億）パラメータ規模で、量子化すれば一般的なCPUや小型GPU、場合によってはシングルボードコンピュータでも動作する。

この差は推論速度とコストに直結する。クラウドのLLM APIはネットワーク往復とキュー待機のオーバーヘッドが加わるため、入力から最初のトークンが返るまでの時間（TTFT）が環境により大きくぶれる。ローカルのSLMはネットワークを介さないため、モデルとハードウェアが噛み合えば応答が安定し、オフラインでも止まらない。

ただしパラメータが小さいほど、複雑な推論や長文の一貫性、多言語性能は低下しやすい。「速くて軽い」と「賢い」はトレードオフであり、用途に対して十分な品質が出る最小のモデルを選ぶ、という発想がエッジ展開の出発点になる。

エッジでSLMが選ばれる背景には、クラウドLLMでは満たしにくい3つの要件がある。

1. データ主権とプライバシー: 入力データが外部APIに送信されないため、個人情報や設計図、契約書などを扱う業務でも情報がデバイス内に留まる。機密データを扱う現場で決定的な利点になる。
2. オフライン動作と低レイテンシ: 工場・倉庫・店舗・車載・離島など、通信が不安定または存在しない環境でも動作する。ネットワーク障害がそのままサービス停止にならない。
3. コスト構造の転換: API従量課金は処理量に比例して増えるが、ローカル実行はハードウェアの初期投資後は限界費用がほぼゼロに近づく。トークン量の多い定常処理ほど有利になりやすい。

これらは「あれば嬉しい」ではなく、要件として満たさなければプロジェクトが成立しないケースが多い点が重要だ。逆に、たまにしか使わない高度な処理であれば、無理にエッジ化せずクラウドを併用したほうが合理的なこともある。

エッジ向けに公開されている主なSLMは、開発元ごとに性格が異なる。

• Microsoft の Phi 系: 小規模ながら推論やコード生成に強く、限られたパラメータで高い品質を狙った設計。
• Google の Gemma 系: 軽量で扱いやすく、ドキュメントや周辺ツールが充実している。
• Alibaba の Qwen 系: 多言語（日本語を含む）対応と幅広いサイズ展開が特徴で、用途に合わせた規模選択がしやすい。
• Meta の Llama 系の小型版: エコシステムが大きく、量子化済みモデルの配布やツール対応が早い。

モデルを選ぶ際は、パラメータ規模だけでなくライセンスを必ず一次ソースで確認する。商用利用の可否や、利用規模に応じた追加条件はモデルごとに異なり、後から問題になりやすい。日本語を主に扱うなら、日本語データで学習・評価されたモデルかどうかも品質を大きく左右する。

展開作業に入る前に、ハードウェア・ソフトウェア・ネットワークの3点を棚卸ししておく。ここを曖昧にしたまま進めると、後工程でメモリ不足や互換性エラーが噴出し、手戻りが発生する。

必要なリソースはモデル規模と量子化方式で大きく変わるが、目安として整理する。

• メモリ（RAM/VRAM）: 量子化済みモデルでは「ファイルサイズ＋推論時のオーバーヘッド（KVキャッシュ等）」分が必要になる。INT4量子化した3B級モデルならおよそ2〜3GB、7B級なら4〜6GB程度が一つの目安だが、コンテキスト長を伸ばすほどKVキャッシュが増える点に注意する。
• CPU/GPU: GPUがなくてもCPU推論は可能だが、コア数とメモリ帯域が速度を決める。AVX2などのSIMD命令への対応有無で体感が変わる。小型GPUやNPUが使えるなら活用する。
• ストレージ: モデルファイルに加え、変換中間ファイルやログの余裕を見て、モデルサイズの2〜3倍を確保しておくと安全だ。

数値はあくまで一般的な目安であり、実際の必要量は対象モデルとコンテキスト長で必ず実測すること。「平常時は動くがピーク時に溢れる」を避けるため、最大負荷を想定して見積もる。

エッジデバイスはOSもアーキテクチャも多様なため、ランタイムが対象環境に対応しているかを先に確認する。

llama.cpp系のランタイムはLinux・Windows・macOSに加え、ARM搭載のシングルボードや組込みLinuxでもビルドできることが多い。ONNX Runtimeは各種アクセラレータ（CPU・GPU・NPU）向けのExecution Providerが分かれているため、使いたいハードに対応するProviderがあるかを確認する。

Pythonを使う場合は、デバイス上のPythonバージョンと依存ライブラリ（数値計算ライブラリやランタイムのバインディング）の互換性も見落としやすいポイントだ。組込み環境ではPythonを載せず、C/C++のネイティブ実装で動かすほうが安定することもある。本番と同じOS・同じアーキテクチャで事前検証する——これが互換性トラブルを避ける一番の近道になる。

エッジ展開の動機の多くは「データを外に出さない」ことにある。だからこそ、ネットワークとセキュリティの前提を明文化しておく。

完全オフラインで運用するのか、モデル更新やログ送信だけ限定的に通信を許すのかで、構成は変わる。オフライン前提なら、モデルファイルや依存パッケージをどう配布・更新するか（USB・社内ミラー・限定的なダウンロード窓口など）を運用設計に含める必要がある。

また、ローカルで動くからといって安全とは限らない。推論サーバーのエンドポイントへのアクセス制御、入力のサニタイズ、モデルファイルの改ざん検知などは別途必要だ。社内のセキュリティポリシー（持ち出し可能なデータ範囲、監査ログの要件）と矛盾しないかを、関係部門と早い段階ですり合わせておくと、後の承認プロセスで止まりにくい。

ここからは実際の手順に入る。最初の工程は、用途に合うモデルを選び、エッジで動くサイズまで量子化することだ。ここでの判断が、後段の速度と品質をほぼ決める。

「とりあえず一番賢いモデル」を選ぶとエッジでは破綻する。用途に必要な最小限の能力から逆算する。

• 定型の分類・抽出・要約: 比較的小さいモデル（1B〜3B級）でも実用になりやすい。タスクが狭いほど小型で足りる。
• 対話・文章生成・簡単な推論: 7B級が品質と軽さのバランスを取りやすい中心帯。
• コード生成や複雑な多段推論: 小型では精度が落ちやすく、用途によってはエッジ単独ではなくクラウドとの併用（重い処理だけ外部）を検討する。

選定では、候補を2〜3個に絞り、自社の実データで小さく試すことが欠かせない。公開ベンチマークの順位は参考になるが、扱う言語・ドメイン・プロンプト形式が違えば結果は変わる。最終的な可否は、本番に近い入力での実測で判断する。

量子化は、モデルの重みをFP16などからINT8・INT4へと低ビット化し、サイズとメモリを圧縮する技術だ。

おおまかに言えば、INT8は精度劣化が小さく安全側、INT4はサイズを大きく削れるが劣化が出やすい。多くの実装では「まずINT4（4bit）で試し、品質が足りなければINT8に上げる」という進め方が効率的だ。

手順としては、(1)対象モデルの重みを取得し、(2)量子化ツール（llama.cppのquantizeや各種ライブラリ）で目的のビット幅に変換し、(3)変換前後で同じ入力を流して出力を比較する、という流れになる。

重要なのは、量子化後に必ず品質を評価することだ。劣化の度合いはモデルとタスクに依存し、「INT4で何ポイント落ちる」と一律には言えない。自社のタスクで許容範囲かを、量子化のたびに確認する。

エッジで動かすには、配布形式をランタイムが読める形に変換する。代表的なのがGGUFとONNXだ。

GGUFはllama.cpp系のランタイムが扱う形式で、量子化情報を含めて1ファイルにまとまり、CPU推論やシングルボードでの取り回しが良い。変換はllama.cppの変換スクリプトでモデルをGGUF化し、続けて量子化する流れが一般的だ。

ONNXはフレームワーク非依存の標準形式で、ONNX Runtimeを通じてCPU・GPU・NPUなど多様なアクセラレータに展開できる。各社のNPUを使いたい場合はONNX経由が現実的なことが多い。

どちらを選ぶかは「使うランタイムとハードウェア」で決まる。CPU中心・シングルボードならGGUF、専用アクセラレータを活かすならONNX、という整理が出発点になる。変換後は必ず実機で動作と出力を確認し、変換時に精度や特殊トークンの扱いが崩れていないかを検証する。

モデルが用意できたら、それを動かすランタイムをデバイスに導入する。ここではインストール、再現性の確保、アーキテクチャ別の注意点を扱う。

llama.cppはソースからビルドする方式が基本だ。リポジトリを取得し、対象ハードに合わせたビルドオプション（CPUのSIMD有効化、GPU/Metalバックエンドの指定など）を付けてコンパイルする。ビルド済みバイナリやバインディングが配布されている場合は、対象アーキテクチャと一致するものを使う。

ONNX Runtimeは、使用するExecution Provider（CPU・CUDA・各種NPU向け）に対応したパッケージを導入する。Pythonならパッケージ管理ツールで該当ビルドを入れ、ネイティブで使うなら対応ライブラリをリンクする。

どちらの場合も、インストール直後に最小のサンプル推論を1回通して、ランタイム単体が正しく動くことを確認してから先に進む。ここを飛ばすと、後で問題が起きたときにモデル側かランタイム側かの切り分けが難しくなる。

エッジ展開で地味に効くのが、環境の再現性だ。1台のデバイスで動いた構成が、別ロットのデバイスや更新後のOSで動かない、という事態は珍しくない。

Docker（または互換のコンテナランタイム）でランタイム・依存ライブラリ・モデルの配置をイメージに固めておけば、「動く状態」をそのまま横展開できる。ベースイメージとライブラリのバージョンを固定し、モデルファイルはイメージに同梱するかボリュームでマウントするかを運用方針に合わせて選ぶ。

ただしコンテナには軽いオーバーヘッドがあり、GPU/NPUを使う場合はホスト側ドライバとの連携設定が必要になる。リソースが極端に限られた組込み環境では、あえてコンテナを使わずネイティブに固める判断もある。再現性と軽さのどちらを優先するかで選ぶ。

エッジデバイスはARM（シングルボードや組込み、一部のサーバー）とx86が混在する。アーキテクチャが違えばビルド成果物もチューニングも変わる。

x86では、AVX2やAVX-512といったSIMD命令を有効にしてビルドすると推論が速くなる。ARMでは、NEONなどへの対応や、ボードによってはNPUアクセラレータの活用が鍵になる。

落とし穴は、x86でビルドしたバイナリやコンテナイメージをそのままARMに持ち込んでしまうことだ。アーキテクチャが一致しないと起動すらしない。コンテナを使う場合はマルチアーキテクチャ対応のイメージを用意するか、対象アーキテクチャ上でビルドする。**「本番と同じアーキテクチャでビルド・検証する」**を徹底すれば、この種のトラブルはほぼ防げる。

ランタイムが動いたら、実用に耐える推論パイプラインに仕上げる。プロンプト設計、応答方式、メモリ管理の3点が、エッジでの体感品質を左右する。

SLMはコンテキスト長が短めで、長文を詰め込むほど速度もメモリも悪化する。だからプロンプト設計は「短く、構造的に」が基本だ。

モデルごとに想定されたチャットテンプレート（システム・ユーザー・アシスタントの区切り方）があり、これを正しく使わないと性能が出ない。まずは対象モデルの推奨テンプレートに合わせる。

そのうえで、入力トークン数を常に意識する。不要な前置きや重複する指示を削り、必要なら入力を要約・分割してから渡す。RAGで外部知識を足す場合も、関連度の高い断片だけに絞ることで、トークン超過とノイズによる精度低下を同時に防げる。トークン数は「入力＋出力＋KVキャッシュ」がメモリを食う要因なので、上限を設計段階で決めておく。

応答の返し方は、用途で使い分ける。

ストリーミング応答は、生成したトークンを逐次返す方式で、対話UIのように「待たされ感」を減らしたい場面に向く。最初のトークンが早く出るため、総生成時間が同じでも体感は大きく改善する。

バッチ処理は、複数の入力をまとめて処理する方式で、夜間の一括分類や大量ドキュメントの要約のように、対話性より総スループットが重要な場面に向く。

エッジでは同時実行数がハードウェアの上限にすぐ達するため、「リアルタイム性が要るリクエスト」と「まとめてよい処理」をキューで分け、優先度をつけて流すと安定する。すべてを同期・即時で処理しようとすると、ピーク時にメモリと速度が破綻しやすい。

限られたメモリで安定運用するには、キャッシュの設計が効く。

• KVキャッシュ: 生成中の中間状態を保持する仕組みで、コンテキストが長いほど膨らむ。最大コンテキスト長を用途に必要な範囲に絞る、量子化対応のKVキャッシュを使う、といった対策でメモリを抑えられる。
• モデルの常駐: モデルのロードは重いため、リクエストごとに読み直すのではなく一度ロードして常駐させる。ただし複数モデルを常駐させるとメモリを圧迫するので、同時に載せる数を絞る。
• 応答キャッシュ: 同一・類似の入力が繰り返されるなら、結果をキャッシュして再利用すれば推論自体を省ける。

メモリは「ピーク時に溢れないか」で設計する。平常時に余裕があっても、長いコンテキストや同時実行が重なった瞬間にメモリ不足で落ちる、というのがエッジで最も多い失敗パターンだ。

最後に、本番投入後につまずきやすい代表的な問題と、その切り分け方をまとめる。多くは「事前検証で防げたはずの問題」が現場で表面化する形で起きる。

最も多いのが、起動時やロード時のメモリ不足（OOM）だ。原因は「モデルサイズの見積もり漏れ」か「実行時オーバーヘッドの軽視」のどちらかであることが多い。

対処は段階的に行う。(1)より低ビットの量子化（INT8→INT4）でモデル自体を小さくする、(2)最大コンテキスト長を縮めてKVキャッシュを減らす、(3)同時に常駐させるモデル数や同時実行数を下げる、(4)それでも足りなければ、より小規模なモデルに切り替える。

切り分けのコツは、コンテキスト長を最小にして1リクエストだけ流してみることだ。それで動くならメモリ設計（コンテキスト長・同時実行）の問題、それでも落ちるならモデル自体が当該ハードに対して大きすぎる、と判断できる。

「動くが遅い」場合は、どこで時間を使っているかを分解して特定する。

まず**TTFT（最初のトークンまでの時間）とトークン生成速度（tokens/sec）**を分けて測る。TTFTが長いならプロンプトが長すぎる・前処理が重い可能性が高く、生成速度が遅いならハードウェアのメモリ帯域や演算性能、量子化・ビルド設定が疑わしい。

チェック順序の目安は、(1)SIMD命令やGPU/NPUバックエンドが有効になっているか（ビルド設定の確認）、(2)CPU推論ならスレッド数が適切か、(3)コンテキスト長が無駄に長くないか、(4)他プロセスがCPU・メモリ帯域を食っていないか。

エッジでは、ソフト側の設定ミス（バックエンド無効・スレッド過不足）だけで数倍の差がつくことが珍しくない。ハードを増強する前に、まず設定を見直すと費用対効果が高い。