株式会社ホコサキ

14MBで動くLLM「needle」をエッジデバイスで使い倒す

天京祐輔
天京祐輔
14MBで動くLLM「needle」をエッジデバイスで使い倒す

エッジデバイスでLLMを動かすと聞いて、「どうせ数GBのモデルをギリギリ動かすやつでしょ」と思いませんでしたか。
そのイメージを一度リセットしてほしいのが、この記事の出発点です。

needleは 14MB のバイナリ1つで動き、フルセッションを 28MB のRAM で完結させます。
Raspberry Pi 5では500トークン/秒超のデコード速度が出るという公式値も出ています。

なぜそのサイズが成立するのかという技術的な納得感を先に整理してから、実際に手元で動かす手順へ進みます。
最後には「このタスクはエッジで完結させる／このタスクはクラウドに投げる」という判断軸を自分で引けるようになることをゴールにしています。

なぜ14MBに収まるのか——量子化・蒸留・アーキテクチャの三重奏

通常のLLMがなぜ大きいかを先に整理しておきます。
FP32（32ビット浮動小数点）で学習したモデルは、1パラメータあたり4バイトを消費します。
7Bパラメータのモデルなら、重みだけで単純計算28GBになります。
FP16に落としても半分の14GB。
これがスマートフォンやマイコンに乗らない理由です。

needleがこの壁を突破できた理由は、3つの技術が重なっているからです。

1つ目は量子化の方法論の違いです。
一般的な量子化は「学習済みのFP16モデルを後から2bitや4bitに丸める」という事後処理です。
ところが小さいモデルで事後量子化を2bitまで押し込むと、品質が大きく崩壊するという問題があります。

Needle 2（45Mパラメータ）が採用するCactus Quants（CQ2-bit）は、学習の最初から2bitで訓練する アプローチです。
重みだけでなく、アクティベーションとKVキャッシュも含めて2bit精度で訓練するため、デプロイ時のモデルが訓練時のモデルと同一になります。
「後から圧縮して品質が落ちる」という問題が構造的に起きない設計です。

なお、needleには初代（26Mパラメータ）とNeedle 2（45Mパラメータ）という2つのバージョンがあり、どちらも14MBというファイルサイズになっています。
パラメータ数が異なるのに同じサイズになるのは、量子化方式が違うからです。
初代はINT4量子化、Needle 2はCQ2-bitという、より積極的な2bit量子化を採用しています。
パラメータ数が増えても、1パラメータあたりのビット数をさらに削ることでサイズを維持しているわけです。

2つ目は知識蒸留です。
大きな先生モデルが問題を解くとき、「この答えが正解だが、こっちの答えも30%くらいありえる」という確率分布ごと出力します。
生徒モデルはその分布を模倣しながら学ぶため、単に正解ラベルだけを学ぶより効率よく知識を吸収できます。
この仕組みによって、はるかに小さいパラメータ数でも実用的な精度を引き出せます。

3つ目がアーキテクチャの選択です。
一般的なTransformerはAttentionとMLPの両方を持ちます。
MLPブロックはパラメータ数の大部分を占める「重い」コンポーネントです。
Needle 2のベースとなるSimple Attention Networkは、このMLPを持たないアテンション専用の軽量設計になっています。

MLPの代わりに使われているのがWalsh-Hadamard変換という固定の行列演算です。
「固定」というのがポイントで、この変換は学習で調整するパラメータを一切持ちません。
Walsh-Hadamard変換はフーリエ変換の一種で、入力の各次元を高速に混ぜ合わせる線形変換です。
計算コストがパラメータ数に依存しないため、追加の重みなしに特徴変換を行えます。
「学習パラメータを増やさずに表現力を確保する」という設計の核心がここにあります。

量子化・蒸留・アーキテクチャ、この3つが重なって初めて14MBが成立します。
どれか1つを外すと、このサイズ感は崩れます。
「小さいから性能を妥協した」ではなく、「小さくするための設計を最初から選んだ」というのがneedleの本質です。

needleの立ち位置——「汎用会話」ではなく「ツール呼び出し」に振り切ったモデル

needleのサイズ感がどれほど異質かを確認するために、他の軽量モデルと並べてみます。

  • Phi-3 mini：3.8Bパラメータ、量子化後でも2GB前後
  • Gemma 2B：2Bパラメータ、量子化後で約1.5GB
  • LFM2.5 230M：230Mパラメータ、needleの約5倍のサイズ
  • FunctionGemma 270M：270Mパラメータ、needleの約6倍のサイズ
  • Needle 2：45Mパラメータ、14MB・28MB RAM

公式ベンチマークでは、FunctionGemma 270MやLFM2.5 230Mと互角の結果を出しながら、サイズは5〜70倍小さいという結果が出ています。
「同等の精度をより小さいモデルで出せる」ということは、それだけ制約の厳しいデバイスへの適用範囲が広がるということです。

ただし、needleが「何でもできる小さいモデル」だという誤解は防いでおきたいです。
needleが得意なのは、single-shot function calling・JSON構造化抽出・デバイス操作コマンドの解釈 という、入出力が明確に定義されたタスクです。
「このセンサー値を見て適切なAPIを呼んでください」「このユーザー発話をJSONに変換してください」という用途では十分な精度が出ます。

一方で、複雑な推論・長文要約・多段階の対話といった汎用会話タスクは苦手です。
45Mパラメータという規模を考えれば当然で、「ツール呼び出しに特化した小さなエージェント」として捉えるのが正確です。

Pythonが使えない組み込み環境向けには、コミュニティ実装のneedle-rsという選択肢もあります。
Rust + WASMで動き、バイナリサイズは258KBです。
ブラウザ・Cloudflare Workers・Node.jsでも動作するため、Pythonホイールが届かない環境への道筋として覚えておく価値があります。

ローカルPCで5分以内に動かす——インストールから推論実行まで

ビルド不要で、pipコマンド1つで完結します。

pip install cactus-needle

推論エンジン本体はHugging Faceから初回実行時に自動でキャッシュされます。
C++のビルドチェーンを用意する必要はなく、公式リポジトリには「There is nothing else to build」と明記されています。
動作確認済みのPythonバージョンは公式READMEで確認してください。

ツールの記述方法は3種類（デコレータ・辞書・クラス）ありますが、まず動かすなら デコレータ方式 が一番シンプルです。

from cactus_needle import Needle

needle = Needle()

@needle.tool
def get_weather(city: str) -> str:
    """指定した都市の現在の天気を返す。city は都市名（例: Tokyo）。"""
    # 実際にはAPIを叩く処理を書く
    return f"{city}: 晴れ、気温22度"

result = needle.run("東京の天気を教えて")
print(result)

needle.run()が呼ばれると、モデルがツール一覧を見て「どのツールを・どの引数で呼ぶか」を判断し、実際に関数を実行して、その結果をフィードバックしながら最終応答を返します。
このループが1回のrun()の中で完結するのがneedleの設計思想です。

ここで docstringの品質が精度に直結する という点は強調しておきたいです。
needleはツールの説明文を読んで呼び出しを判断するため、docstringが雑だと誤ったツールを選んだり、引数の解釈がずれたりします。
「何をする関数か」「引数に何を渡すべきか」を具体的に書くだけで精度がかなり変わります。
上のサンプルのように、引数の型と使用例をdocstringに入れておくのが実務上のコツです。

もう1つ、キャッシュパスについて。
推論エンジンはHugging Faceのデフォルトキャッシュディレクトリに保存されます。
CI環境やコンテナで動かすときはキャッシュの場所を意識しておかないと、毎回ダウンロードが走って遅くなります。
HUGGINGFACE_HUB_CACHE 環境変数でパスを固定しておくと安心です。

Raspberry Pi相当の環境で動かすときの現実

Raspberry Pi 5での500トークン/秒超という公式値は、エッジ推論の文脈では驚異的な数字です。
28MB RAMで完結するという設計が効いていて、OSのページングやスワップが起きにくく、推論中に他のプロセスとメモリを取り合う場面が少ないのが理由です。
Pi上で他のサービスと同居させながら推論を走らせる構成でも、メモリ競合のリスクが低いのは実運用上の大きなメリットです。

ARMアーキテクチャへのインストールは、基本的にx86と同じpipコマンドで動きます。
ただし環境によってはwheelが提供されていないケースもあるため、インストール後に以下で動作確認をしておくのが無難です。

# インストール確認
pip install cactus-needle
python -c "import cactus_needle; print(cactus_needle.__version__)"

# 推論速度の簡易計測
python - <<'EOF'
import time
from cactus_needle import Needle

needle = Needle()

@needle.tool
def echo(text: str) -> str:
    """入力テキストをそのまま返す。text は任意の文字列。"""
    return text

start = time.perf_counter()
result = needle.run("hello と返してください")
elapsed = time.perf_counter() - start

print(result)
print(f"elapsed: {elapsed:.3f}s")
EOF

この計測スニペットはトークン数を正確にカウントするものではなく、「手元の環境でざっくり感触をつかむ」ためのものです。
まず動くかどうかの確認にはこれで十分です。

Pi 4の1GBモデルなど、メモリが厳しい環境では注意点があります。
needleの推論自体は28MBで完結しますが、Pythonインタープリタ・OSのバックグラウンドプロセス・他のサービスが積み重なると合計でメモリが逼迫します。
スワップを有効にしておくことと、推論を走らせるタイミングで不要なプロセスを落とす運用上の工夫が現実的な対策です。

Pythonホイールが届かない、もっと制約の厳しい組み込み環境——たとえばESP32-S3のようなマイコンや、バイナリ配布が必要な環境——では、needle-rs（WASM・258KB）が現実的な選択肢になります。
Rustのエコシステムで動くため、Pythonランタイムそのものが存在しない環境でも推論を組み込めます。

エッジで完結させるか、クラウドに投げるか——4軸の判断フレーム

エッジ推論とクラウドLLMは「どちらが優れているか」という話ではなく、「どちらが要件に合っているか」という設計の選択です。
判断を分ける軸は4つあります。

レイテンシ要件 が最初の軸です。
クラウドAPIへのラウンドトリップは、ネットワーク状況に関わらず数百ミリ秒のオーバーヘッドが乗ります。
現場端末でのリアルタイムコマンド解釈や、ウェアラブルでの即時フィードバックのように「100ms以内に応答が必要」という要件がある場合、クラウドへの往復は構造的に間に合いません。
needleならネットワーク遅延をゼロにできます。

オフライン要件 が2つ目の軸です。
工場の現場・地下・船上・山岳エリアなど、安定したインターネット接続を前提にできない環境は思った以上に多いです。
クラウドAPIは接続が切れた瞬間に止まりますが、オンデバイス推論は通信状態に依存しません。

プライバシー要件 が3つ目の軸です。
医療・金融・製造の現場では、入力データをクラウドに送ること自体がコンプライアンス上の問題になるケースがあります。
オンデバイス推論なら、センサー値・音声・フォーム入力といったデータが端末の外に出ません。
データの持ち出しが構造的に起きない設計は、「送信しない設定を入れた」と後から説明するより、はるかに信頼性が高いです。

タスクの複雑度 が4つ目の軸です。
ここがneedleの限界と直結します。
シングルショットのツール呼び出し・JSON抽出・デバイスコマンド解釈は得意ですが、複数ステップの推論・長文要約・コード生成といったタスクは45Mパラメータでは力不足です。
タスクが複雑になるほど、クラウドLLMの出番になります。

「エッジで完結すべき」典型例は、工場の現場端末でのフォーム入力補助（センサー値を見て適切なフィールドにマッピングする）や、ウェアラブルデバイスでの音声コマンド解釈（「アラームを5分後にセット」をAPIコールに変換する）です。
逆に「クラウドに任せるべき」典型例は、複雑な契約書の要約・多段階の推論が必要な診断支援・コードレビューといったタスクです。

二択で悩む必要がない場合もあります。
Cactus Computeが提供する Cactus Hybrid は、エッジ推論を基本としながら、モデルが「自分では答えられない」と判断したときだけクラウドにフォールバックする設計パターンです。
プライバシーとレイテンシを守りながら、クラウドLLMの表現力も活用できる構成です。

needleが向いているプロジェクトの輪郭を一言でまとめると、「入出力が明確に定義されていて、レイテンシかオフラインかプライバシーのいずれかに厳しい制約がある」ユースケースです。
IoTデバイスのコマンドインタープリタ・現場端末の入力補助・ウェアラブルのエージェント機能——こういった用途でクラウドAPIへの依存を減らしたいと思っているなら、needleは試す価値のある選択肢です。
まず手元のPCで動かして、docstringの書き方と推論速度の感触をつかんでから、ターゲットデバイスに持ち込む順番で進めるのが現実的です。

株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
needleのようなエッジ推論の組み込みから、クラウドLLMを使ったシステム設計まで、実務ベースでご相談に乗れます。
気になることがあれば、お気軽に お問い合わせ からどうぞ。