Tiny LLM OSS 2026：Needle・SmolLM・Gemma・Phi比較

2026年8月14日更新。データは各プロジェクトの公式モデルカード、リポジトリ、ライセンス、実行ドキュメントを確認しています。

Needleの公式リポジトリでは、26Mパラメーターのオンデバイス向けモデルとして紹介されています。Needle公式リポジトリが示すこのサイズ感からも、Tiny LLM OSS 2026の選定では「一番賢いモデル」を探すより、処理内容に合うモデルを先に絞るのが正解です。超小型の専用ツール呼び出しならNeedle、軽量な汎用文章処理ならSmolLM、より強い推論や長文処理ならGemmaまたはPhiを選び、最後は実機で確かめてください。

この記事が向いている人

移動アプリやエッジ機器に小型モデルを組み込みたいエンジニア向けです。Macで微調整と評価を行いたい個人開発者や、端末処理とクラウド処理の境界を設計するAIアーキテクトにも役立ちます。

最初に用途を4つへ分ける

4つのプロジェクトは、同じベンチマーク表だけで順位を付けられません。Needleは文章を自然に生成するチャットモデルというより、入力内容を決められたツール呼び出しへ変換するルーターです。公式資料でも、OpenAI互換形式のツール定義を渡して関数呼び出しを生成する用途が中心です。

一方、SmolLMは軽量な汎用言語モデルの系列です。公式リポジトリではSmolLM3-3Bを、オンデバイス実行を意識した3Bクラスのモデルとして説明しています。SmolLM公式リポジトリでは、学習データや微調整用リソースも公開されています。

GemmaとPhiは、より幅広い文章生成、要約、分類、推論に向きます。たとえばGemma 3の公式モデルカードは、1Bや270Mから27Bまで複数サイズを掲載し、サイズによってコンテキスト上限も異なると説明しています。Gemma 3モデルカードやPhi-4-mini-instructの公式モデルカードを確認し、比較対象のバージョンを固定してください。

Tiny LLMはツール呼び出しに使えますか。

使えます。ただし、汎用チャットの延長として考えるのではなく、許可するツール名、引数、拒否条件を限定した構造化出力モデルとして設計します。天気取得、照明操作、カレンダー登録のようにツール集合が固定されているなら、モデルの小型化による利点が出やすくなります。

比較表で候補を先に絞る

この表はモデル名だけでなく、入力形式、出力制約、実行経路、配布条件を含めて判断するためのものです。NeedleとSmolLMを「軽いから同じ」と扱わないことが重要です。

第二段階：サイズではなく実メモリーを確認する

モデルカードに書かれたパラメーター数、ダウンロードした量子化ファイルの容量、推論時の実メモリーは別の数字です。推論時には重みだけでなく、ランタイム、トークナイザー、コンテキストキャッシュ、入力バッファー、アプリ本体のメモリーも必要になります。

Needleの公式リポジトリでは、26Mパラメーターと小型端末向けの実行を掲げていますが、これは「どの端末でも同じ速度で動く」という意味ではありません。量子化形式、CPUやGPUのカーネル、入力長、ツール定義の数で結果は変わります。専用ランタイムを採用する場合は、対応するバインディングとビルド条件も確認してください。

Phi-4-mini-instructは公式モデルカード上で3.8Bパラメーター、128Kトークンのコンテキスト長と記載されています。長いコンテキストを扱えることと、スマートフォンで快適に動くことは別問題です。保存容量だけでなく、初回ロード時間、生成中の発熱、バックグラウンド復帰後の安定性まで測定する必要があります。

NeedleとSmolLMは、どちらがスマートフォン向きですか。

端末操作や固定された関数呼び出しが中心ならNeedleです。短い要約、分類、入力補助、簡単な対話ならSmolLMを候補にします。スマートフォン向けでも、文章を自由に生成する機能へNeedleを採用すると、モデルの目的と実装が噛み合わなくなります。

第三段階：ツール呼び出しを同じ条件で検証する

ツール呼び出しの比較では、成功回数だけを記録してはいけません。次の3種類を同じ入力セットで確認します。

1. 許可されたツールを正しい名前で呼べるか。
2. 存在しないツールを拒否、または空の結果として返せるか。
3. 必須引数の欠落、型違い、範囲外の値を検出できるか。

Needleは、公式サンプルでツール定義を渡し、関数名と引数をJSON形式で出力する流れが示されています。ただし、構文が正しいJSONでも、引数の意味まで正しいとは限りません。実際のアプリでは、モデル出力をそのまま実行せず、スキーマ検証と権限確認を必ず挟みます。

Gemmaには、専用のFunctionGemmaのような関数呼び出し向けモデルもあります。公式モデルカードは、FunctionGemmaを汎用対話モデルではなく、特定の関数呼び出しタスク向けに微調整する基盤として説明しています。FunctionGemmaモデルカードを確認し、通常のGemmaと同じ評価軸で扱わないでください。

第四段階：文章性能はタスク別に採点する

要約、分類、短い対話、制約付き推論を分けて評価します。1つの総合点で順位を決めると、Needleのような専用モデルが不当に低く見えたり、逆に大きな汎用モデルが端末機能に過剰採用されたりします。

評価用データには、実際の入力長と日本語の表現を含めます。特に日本語対応は、モデルカードに対応言語が書かれているだけでは不十分です。固有名詞、敬語、短い命令文、混在した英数字を含む入力で、誤認識と再試行回数を記録してください。

Gemma 3はテキストだけでなく画像入力にも対応するモデル系列ですが、画像処理を加えるとメモリーと実行経路が変わります。Phi-4-mini-instructは日本語を含む複数言語をモデルカードに掲載していますが、最終製品での精度は自分のデータセットで確認する必要があります。

第五段階：端末ごとの実行経路を決める

iOSとAndroidでは、モデルを取得できることと、アプリストアへ配布できることを分けて考えます。MacとLinuxでは、PythonやC++ランタイムで評価しやすくても、そのままモバイルアプリに移植できるとは限りません。

Needleはモバイル、ウェアラブル、スマートホームなどのエッジ用途を明確に掲げ、Swift、Kotlin、Flutter、React Native、Python、Rust向けの接続経路が公開されています。専用ランタイムを採用する前提があるため、最終アプリの言語とビルド環境を先に合わせてください。

SmolLMは、一般的な機械学習ライブラリや複数のローカル実行形式を試しやすい点が利点です。Phi-4-mini-instructにはONNX形式の配布もありますが、モデルファイルの容量、対応アクセラレーター、初期化処理を端末ごとに確認してください。Phi-4-mini ONNX版には、モバイル向けとGPU向けの構成が分けて掲載されています。

第六段階：微調整とライセンスを確認する

Macで微調整するなら、最初に「どのデータ形式で学習できるか」「出力形式を固定できるか」「評価用データを分離できるか」を確認します。Needleは専用ツール向けのデータを用意しやすく、少数のツールに特化する場合に計画を立てやすいモデルです。SmolLMは、研究用のデータセットや学習スクリプトを確認しながら、文章タスクの実験を進めやすい構成です。

ライセンスは「重みが公開されているから自由に配布できる」と決めつけないでください。NeedleのモデルカードはMITライセンスを掲げています。Phi-4-mini-instructもMITライセンスです。一方、Gemmaは専用の利用規約に従う必要があり、再配布時の通知や利用制限が定められています。Gemma利用規約を配布前に確認してください。

Macでは、どのTiny LLMを微調整しやすいですか。

専用のツール呼び出しを作るならNeedle、文章分類や短文生成を研究するならSmolLMが候補です。ローカルアシスタントとしての品質を優先する場合はGemmaやPhiを検討しますが、量子化後の実メモリー、評価時間、データ準備の負担を先に見積もってください。

導入目標ごとの最終選定

超小型ツールルーター

端末の照明、音量、センサー、簡単なアプリ操作を自然言語から呼び出すならNeedleが第一候補です。ツール数を絞り、未知の関数を拒否する処理をアプリ側へ実装してください。自由会話や長文要約まで1つのモデルに任せる構成には向きません。

モバイルの文章機能

入力補助、短い分類、メモの要約、定型的な文章変換ならSmolLMが扱いやすい候補です。Needleより汎用性を期待できますが、日本語の品質、長い入力、バッテリー消費は実機評価が必要です。

ローカルアシスタント

会話、要約、検索前処理、画像を含む入力をまとめて扱うならGemmaを検討します。配布や利用規約の確認が必要なため、社内検証と一般公開で同じ条件だと考えないでください。

小規模サーバー

複数ユーザーの問い合わせ、分類、推論、コード補助をまとめるならPhiが候補になります。単一端末の常駐モデルより必要なメモリーが増えやすいため、量子化方式と同時実行数を決めてからサーバー構成を設計します。

実機評価を5段階で進める

1. まず用途を「ツール呼び出し」「文章生成」「分類」「要約」に分離します。
2. 次にモデル名だけでなく、具体的な版、量子化形式、コンテキスト長を固定します。
3. Macで同じ入力セットを使い、出力品質、初回ロード、生成速度、メモリー使用量を記録します。
4. iOS、Android、Linuxなど最終端末で、発熱、スリープ復帰、オフライン状態、権限エラーを確認します。
5. 最後に、誤ったツール呼び出し、空出力、長文入力、通信復帰時のクラウド引き継ぎを含む受け入れ試験を行います。

端末向けモデルを選ぶときは、先にベンチマークの数字を並べるのではなく、合格条件を決めてください。たとえば「許可外ツールを実行しない」「指定形式以外のJSONを返さない」「スリープ復帰後も再初期化できる」といった条件です。

現在の構成がクラウドAPIだけに依存している場合、通信遅延、従量課金、機密データの送信、オフライン時の機能停止が問題になります。逆に、すべてを端末へ載せる構成では、モデル更新、端末ごとの性能差、アプリ容量、微調整後の配布管理が負担になります。

そのため、Needleを端末側のツール判定に使い、難しい質問だけをクラウドへ渡す構成や、SmolLM・Gemma・Phiを用途別に分ける構成が現実的です。複数バージョンをMacで微調整し、端末ごとの受け入れ試験まで行うなら、手元の開発機だけでなく、必要な期間だけ使えるMac環境を比較してください。日本向けのMac miniレンタル環境を使えば、モデル変換、微調整、複数版の評価を同じ作業環境で進めやすくなります。

長期間、同じモデルへ高負荷をかけ続けるなら自前のMacや専用サーバーが向いています。反対に、短期の微調整、モデル比較、端末別の検証、リリース前の再評価が目的なら、購入した機材を余らせるより、KvmkitのMac環境を必要な期間だけ使う方が、構成変更と検証サイクルを組みやすい選択です。