スマホやスマートウォッチ、ロボット、車載機器のような、電力もメモリも限られた端末で動くAIは、ここ数年ずっと「できること」を広げてきました。ただし、端末内で動かす以上、巨大なモデルをそのまま載せるのは難しい。Cactus Computeが公開した「Needle 3」は、その制約に真正面から向き合ったモデルです。本文では、8〜29MBの単一バイナリで、モバイル上の tool call ではサイズ10倍のモデルを上回り、抽出タスクでは2〜3倍大きいモデルに並ぶと主張しています。しかも、単なるチャット用途ではなく、機器操作や情報抽出、埋め込みまでを一つの仕組みでこなす点が売りになっています。
元記事によると、Needle 3 は mobile、wearables、robots、smart home、automotive、microcontrollers など、小さな端末向けに作られた foundation model です。中核にあるのは Simple Attention Network という独自アーキテクチャで、モデル全体は 8〜29MB の単一バイナリとして配布されます。Cactus は、一般的な雑談性能を多少犠牲にする代わりに、端末上での tool call と structured extraction に強く振っている、と説明しています。
できることは大きく三つです。ひとつ目は tool calls で、アプリが公開した関数の中から適切なものを選び、ユーザー発話から各引数を埋めます。たとえば「2つのことを頼めば2回の呼び出しを順番に返す」「該当するツールがなければ推測せず空のリストを返す」といった挙動を掲げています。ふたつ目は structured extraction で、請求書、予約、通知、フォームのような雑然とした文章から、型付きのフィールドを返す用途です。解読用 grammar により、出力が必ずパースできるとしています。三つ目は text embedding で、文をベクトル化し、端末内検索やマッチング、ルーティングに使えるというものです。
記事には具体的な利用例も並びます。スマートホームでは「寝室を暗くして施錠して」で、ハブを介さずオフラインで2つの関数呼び出しを行う。ロボットなら「キッチンだけ掃除して寝室は残して」といった指示を動作列に変える。スマホでは写真アルバム作成、サイトを開く、画面を暗くする、ファイルから契約書を探す、といった端末操作をそのまま実行する。wearables では通知を、カード利用なら merchant・amount・date に、メッセージなら返信候補に、苦情なら sentiment flag に整形する。AR glasses では近くの検索やナビをネットワークなしで行い、automotive では車内からの操作を長い会話でも維持できるように tool set を固定する、といった具合です。
性能面では、Needle 3 の「intelligence laddering」を強く押し出しています。全レイヤーが小さなサブネットワークとして機能し、2層から20層までを選べる設計です。小さいものは 9〜29MB の CQ2-bit binary として出力され、Raspberry Pi 5 上で decode 400〜4k tokens/s、prefill 1〜10k tokens/s を出せるとしています。学習には 360B tokens の proprietary structured dataset を使ったとも書かれています。図の説明では、Needle 3 は mobile tool calls で「サイズ10倍のモデル」を上回り、extraction では「2〜3倍大きいモデル」に並ぶと主張し、比較対象には DeepSeek V4 Flash も含まれます。さらに、4層のサブネットワークを downstream task で1 epoch fine-tune すると DeepSeek V4 Flash を上回るケースがある、と述べています。
実装面では、Python package を入れればよく、tool はデコレータで定義できます。Pydantic model を渡して抽出する例も載っています。confidence score による gating もあり、スコアが低ければ suppressed_calls に回し、ツールの実行を止める仕組みです。要するに、端末上で動く小型モデルを、単なる「小さいLLM」ではなく、関数呼び出し・抽出・埋め込みの実務エンジンとして売っているのが Needle 3 です。
この発表で面白いのは、モデルを小さくしたこと自体より、用途の切り方がかなり割り切れている点です。Needle 3 は、自由形式の長文会話で人間っぽく話す汎用チャットモデルを目指していません。むしろ、端末内で必要になる「関数を呼ぶ」「項目を抜き出す」「近いものを探す」という、かなり実務的な仕事に絞っている。ここが筋がいいと思います。端末AIで本当に欲しいのは、雑談の巧さより、誤作動しにくく、通信なしで、毎回同じように動くことだからです。
ただし、これは「万能な小型AIが来た」という話ではありません。元記事でも general chat capacity を trade していると明言しています。つまり、できることを増やしたというより、できることを狭く深くした。その代わりに、スマートホーム、車載、ウェアラブルのような、失敗がそのまま使い勝手に直結する領域で勝負しているわけです。私はこの方向性のほうが、端末AIとしては現実的だと思います。端末に載るモデルに必要なのは「何でもできること」ではなく、「間違えると困る作業を安定して任せられること」だからです。
サイズの話も印象的です。8〜29MBというのは、最近のAIニュースの感覚からすると驚くほど小さい。しかも、単に圧縮しただけではなく、2層から20層までの「intelligence ladder」を用意し、同じ重みから深さの違うサブネットワークを切り出せる設計です。これは、1つの巨大モデルを無理やり縮めるのではなく、最初から「端末ごとに使える深さが違う」ことを前提に組んでいるように見えます。
この発想は、スマホ、watch、車、microcontroller を同列に扱うならかなり合理的です。必要な計算量もメモリもバラバラだからです。全部に同じモデルを配るのは無駄が大きいし、用途ごとに別モデルを作るのも保守が重い。Needle 3 はその中間を狙っていて、同じ binary の中から端末に合う深さだけを使う。ここにプロダクトとしての強さがあります。もちろん、ベンチマークの条件や比較方法は吟味が必要ですが、それでも「1本の重みを配って、端末に応じて深さを変える」という設計は、エッジAIの配布と更新の面でかなり扱いやすいはずです。
Needle 3 が強調する mobile tool calls は、いまの端末AIのかなり本質的な部分です。ユーザーが本当に欲しいのは、文章を作ることより、アラームを設定する、照明を消す、目的地を入れる、通知を要約する、といった「操作」だからです。しかもそれは、クラウドに飛ばさず端末内で完結したほうが速くて安全です。記事が、スマートホーム、車載、wearables を例に並べているのは偶然ではないと思います。どれも、レスポンスの速さと個人情報の閉じ込めが価値になる領域です。
一方で、tool call に強いモデルは、裏返すと tool の設計に強く依存します。記事でも、説明をうまく書くこと、trigger を適切に設定すること、tool の数を増やしすぎないことが重要だと述べています。これはつまり、モデル単体の能力だけではなく、周辺の API 設計やスキーマ設計が成否を決めるということです。私はここがかなり重要だと思います。AIが賢くなるほど、実は開発者に求められるのは「モデルを当てること」より「モデルに迷わせない設計」だからです。Needle 3 は、その方向をかなり正直に突き詰めているように見えます。
元記事は DeepSeek V4 Flash との比較を前面に出していますが、実際の競争相手は単純に「大きいモデル」だけではないと思います。端末AIの現場では、軽量なルールベース、専用NLP、OS標準のアシスタント、あるいはクラウドに逃がす別系統の処理が、すでに役割を分け合っています。Needle 3 のようなモデルが本当に効いてくるのは、その中間を取りにいく場面でしょう。つまり、ルールだけでは取りこぼすが、巨大LLMを呼ぶほどでもないケースです。
さらに、この記事が示しているのは「クラウドに依存しないこと」が単なるプライバシー訴求ではなく、製品の信頼性そのものになる、ということでもあります。電波が不安定でも動く、車内でも会話が途切れない、watch で通知を即座に構造化できる。こうした価値は、派手なデモより地味ですが、実際の採用ではかなり強いはずです。私は、Needle 3 は汎用AIの勝負ではなく、端末AIを「実用品」に寄せるための設計例として読むのが正しいと思います。派手さはあるのに、狙いはかなり実務的です。
参考: Needle 3 - 8-29 MB foundation model for tiny devices | Cactus
