Needle2の使い方 45Mパラメータでスマホもラズパイも動くAI

兆パラメータをどう量子化するか、70Bをどうやって小さいGPUに載せるか。

そういう話ばかり追いかけていると、手元のRaspberry Piで結局何ができるのかは分からないままです。

そこに14MBのバイナリ1本で動くツール呼び出し専用モデルが出てきて、Hacker Newsで527pt集めていました。

パラメータ数は45M。

誤植を疑う数字ですが、中身を読んだら賢くする努力を意図的に捨てた設計でした。

45Mパラメータで世界知識を捨てるという逆張り

Needle 2は汎用の言語モデルではありません。

ツール呼び出し、デバイス操作、構造化抽出。

この3つだけをやるために作られています。

アーキテクチャはSimple Attention Networkという、フィードフォワード層を持たずアテンションだけで組んだ構成です。

27層で幅512、1トークンあたり70 MFLOPs、45Mのうち行列演算に効いているのは35M。

ここが面白いんですが、開発チームが出しているアテンションのみのTransformerを検証した論文には、フィードフォワード層を外すとパラメータを揃えた条件で約0.006 natsの差が出る、と書かれています。

そして重要なのは、その欠損が「パラメトリック想起」に局在するという結果の方です。

つまり、知識を重みから引っ張ってくる場面では確かに弱くなる。

逆に言えば、知識を文脈から受け取る使い方なら、この欠損はほとんど当たりません。

ツール呼び出しって、まさにそれなんですよね。

呼べる関数の一覧も、引数の型も、全部プロンプトの中にツール定義として書いてある。

モデルが世界知識を覚えている必要がない。

だから覚えさせるのをやめた。

45Mという数字は、削った結果ではなく最初から要らなかった分を積まなかった結果です。

14MBのバイナリがHacker Newsで527pt集めた理由

投稿したのはCactus ComputeのHenry Ndubuakuさん。

Show HNで527pt、コメントは182件つきました。

やることはシンプルで、テキストを入れるとJSONが出てきます。

ここで効いているのが、JSONスキーマからバイト単位の文法をコンパイルして、生成する全トークンをその文法で拘束している点。

構造が壊れた出力が原理的に出てこない作りです。

さらに実装として気持ちいいのが、この3つです。

• 大量のツールを宣言しても、検索ヘッドが1ターンにつき上位5個だけを展開する
• コンテキストは256トークンのスライディングウィンドウで、ツール定義はKVシンクとして固定される
• 全レスポンスに確信度スコアが付き、しきい値を切ってそれ以下はクラウドの大きいモデルへ回せる

小さいモデルを「頑張って賢くする」方向ではなく、小さいまま運用に乗せる方向で作り込まれている。

HNで刺さったのは性能の数字より、この割り切りの方だったと思います。

GitHub - cactus-compute/needle: 14MB foundation model for tiny devices; phones, wearables, smart home, and robots.

14MB foundation model for tiny devices; phones, wearables, smart home, and robots. - cactus-compute/needle

github.com

ラズパイ5で毎秒500トークン 3万円以下のスマホでも動く

公式が出しているデコード速度がこれです。

セッション全体のRAMピークが28MB。

この数字がヤバいところで、ESP32-S3のように外部RAMを積んだマイコンや、Cortex-M4/M7/M55のベアメタルまで実行対象に入ってきます。

x86-64、ARM64、ARMv7、RISC-V、MIPS32el、それとWebAssembly。

14MBという容量も、事後に圧縮して壊れかけているわけではありません。

CQ2ビット量子化を事前学習の時点から前提に置いて訓練しているので、2ビットで動くのが素の状態です。

事前学習115Bトークン、追加学習38Bトークン。

画面もクラウド接続も持たないスマートグラスやスマートスピーカーの中で、音声から動作への変換だけをローカルで完結させる。

この用途に必要な計算量が、実は28MBのRAMで足りていたという話になります。

pip install から playground まで一気に触る手順

入り口は2行です。

pip install cactus-needle
needle playground

これでブラウザ上のプレイグラウンドが立ち上がります。

CUDAを使うなら pip install "cactus-needle[gpu]"、Apple Siliconなら [metal] を付けるだけ。

Python側でツールを生やすのは @needle.tool デコレータ、構造化抽出は needle.extract() にPydanticモデルを渡す形です。

で、実運用に効いてくるのはここから先だと思っています。

needle generate-data --tools my_tools.json --num-samples 500 --output data.jsonl
needle finetune data.jsonl --epochs 10
needle build checkpoints/needle2.pkl --lora checkpoints/needle_lora.pkl --out my_needle.cact

自分のツール定義を渡すと学習データを生成してくれて、そのままLoRAで追加学習して単一ファイルに焼ける。

小さいモデルは用途に寄せて初めて戦力になるので、この生成コマンドがあるかどうかで手間が一桁変わります。

ライセンスはMITです。

FunctionGemmaやLFM2.5に勝つベンチと負けるベンチがある

ここは正直に並べます。

BFCL v4は負けています。

42.6%に対してLFM2.5が60.8%なので、差もそこそこ大きい。

Mobile Actionsも届いていません。

勝っているのはSeal-Tools系で、特にOOD、つまり学習時に見ていないツール構成を投げた条件で28.7%対17.0%と開いています。

未知のツールに対する食いつきが強い。

前提として、比べている相手は5倍から70倍のサイズで、しかも向こうはf16、こちらは2ビットです。

同じ土俵の勝負ではありません。

もう1つ読み方があって、Mobile Actionsの関数名だけの正解率は98.3%あります。

BFCL v4での整形済み出力率も93.4%。

呼ぶべき関数を選ぶところと形式を守るところはほぼ外さず、引数の中身を詰める段階で落ちている、という構図が見えてきます。

こういう用途はまだ巨大モデルのままでいい

HNのコメントに、実際に触った人の報告が上がっていました。

部屋を暖かくしてほしいと頼んだらサーモスタットを冷房モードに設定した。

玄関先の来客を締め出す指示を、デバイス名として解釈した。

開発側の回答も率直でした。

ツールの説明文が曖昧だと安定して失敗する。

実運用にはファインチューニングが要る。

スコープを狭く固定した環境が前提。

要するに、言われたことの意図を汲む部分は苦手です。

曖昧な自然言語から何をしたいのか推定する工程が挟まる用途は、素直に巨大モデルを置いておいた方がいい。

確信度スコアでクラウドに逃がす設計が最初から入っているのも、そこを自覚しているからだと思います。

逆に噛み合うのは、語彙がある程度固定されていて、ツールの数が数個から数十個で、外したときに上位モデルへエスカレーションできる場所。

工場の設備操作、車載、オフラインの家電制御あたりは相当ハマるはずです。

45Mが急に賢くなったわけではありません。

賢さを要求しない領域を切り出して、そこに専用機を置いた。

次に効いてくる設計変数は、モデルサイズではなくタスクをどこまで狭く切れるかの方だと思います。

Needle 2 - The 14 MB Agentic LLM for Tiny Devices | Cactus

An open 45M-parameter model for tool calling, device use, and structured extraction. Needle 2 runs as a 14 MB binary in 28 MB of session RAM.

cactuscompute.com