【超軽量】たった8〜29MB！DeepSeek V4 Flash級の性能を叩き出す自動化モデル「Cactus Needle 3」が凄すぎる

Hacker Newsの皆さん、CactusのHenryです。数週間前にNeedle 2を投稿した際、スレッドでいただいた貴重なフィードバックのおかげで、素早く「Needle 3」をリリースすることができました。ぜひ皆さんの感想を聞かせてください！主な特徴は以下の通りです。1) 自動化（ツール呼び出しと構造化JSON出力）: Needleは意図的にチャット機能を搭載していません。小規模モデルで汎用的な性能を確保するのは難しいため、ツール呼び出しと構造化JSON出力に特化しました。定義したツールに適合しない場合は空のリストが返ります（デモでお試しいただく際の注意点です）。2) インテリジェンス・ラダリング: 2層から20層までの全レイヤーが単独でデプロイ可能なサブネットワークとなっており、2bit量子化により2500万〜1億2100万パラメータを8〜29MBのバイナリに凝縮。Raspberry Pi 5ではデコード時で最大4,000トークン/秒、プリフィルで最大10,000トークン/秒を叩き出します。3) Monarch Hadamard MLP: 密なFFNを3つの学習可能なMonarch因子ペアに置き換えました。O(d²)の計算量が必要だった4倍拡張MLPに対し、O(d√d)で同等の非線形変換を実現しています。4) 性能: モバイル操作（スマホのコマンド実行）において、20層モデルは86.0というスコアを記録。LFM2.5 1.2B（82.4）やQwen3.5 0.8B（76.0）、Appleのオンデバイスモデル（57.6）を上回りました。詳細はリンク先をご覧ください。5) 多言語対応: 英語、フランス語、スペイン語、ドイツ語、オランダ語、イタリア語、ポーランド語に対応し、今後も拡大予定です。6) ファインチューニング: 特定のタスクに限定すれば、たった4層でもDeepSeek v4 Flash級の性能を引き出せます。本番環境への導入前に調整を行うユーザーが非常に多いです。7) トリガー機能: ツール呼び出しの精度向上のため、ケースインセンシティブな正規表現による判定ゲートを追加しました。8) 信頼度スコア: すべての応答にキャリブレーションされた信頼度スコアを付与。しきい値に基づき、自動実行か、ユーザーへの確認か、あるいはより大きなモデルへのエスカレーションかを判断できます。9) 対応プラットフォーム: macOS、Linux（x86-64, ARM64, ARMv7, RISC-V, MIPS32）、Windows（x64, ARM）、Android、iOS、watchOS、tvOS、ブラウザ（WebAssembly）、WASIコンポーネントと幅広くサポート。いつも応援ありがとうございます！感想やフィードバックをぜひお寄せください。

思うんだけど、「小さなモデルがLLMを凌駕する」っていう怪しげな主張が増えすぎると、本当に有用なイノベーションまで見過ごされてしまうんじゃないかな。

リソース要件よりも重要なのは、汎用的なLLMなら余裕でできることを、このモデルが「どうしてもできないこと」を明確にすることだと思うよ。

要するに、わざわざ自分で試して確かめる手間を省けるように、アンチ・ユースケース（不向きな使い方）をはっきり教えてほしいな。

これで風呂の電気をつけられるか試してみたんだけどさ：

「おしっこしたい」 -> 「wee（おしっこ）」は音楽ジャンルでもあるから音楽を流し始める

「おしっこ、おしっこしたい」 -> 風呂場で掃除機をかけ始める

「トイレに行ってくる」 -> 「トイレをオンにする」って言われるんだけど、それが何を意味するのか正直よくわからない

「トイレに行ってくる、何も見えない」 -> 「風呂場の電気をつけるべき」という推論はするのに、結局また「トイレをオンにする」を選択する

「トイレに行ってくる、どこへ行くのか見えない」 -> 推論結果が「『トイレに行ってくる』 -> device 'coffee maker'（コーヒーメーカー）でcontrol_device（トイレはコーヒーメーカーを意味する）」ってなっちゃう

「トイレに行ってくる、暗すぎてどこに行くのか見えない」 -> 「『暗い』 -> direction 'dark'；adjust_lightsで明るさを100に」となって、リビングの電気を「暗く」しようとして失敗する

結局、掃除機は真っ暗な風呂場にいるし、リビングは100%の明るさで「wee」の曲が流れてる状態だよ。せめてコーヒーは飲めるみたいだけどね。

これのユースケースで一つアイデアがあるんだけど、筋が通っているか、それともこういうアプローチについてどう思うか意見が聞きたいな。

僕はOpenStreetMapの熱心なファンで、PCから編集するのが好きなんだ。スマホからだと、電話番号を正確に入力してチェックしたり、Upredorにある膨大なリストから適切なフィールドを見つけて選択したりするのがすごく面倒でさ。

大まかな流れとしては、レストランの看板を見て「支払いは現金のみ。電話番号はこれ、営業時間はこれ」って情報があるとしよう。スマホに向かって「ねえ、この場所の情報を入れて」って話しかけられたら最高だよね。現在地から付近の場所を自動検出し、今どの店について話しているかを特定した上で、「あなたが追加しようとしている変更はこれだね、あるいは入力した情報から差分を作るとこうなるよ」と教えてくれる感じ。キーは、あらかじめ定義された20個程度の一般的なものに限定してさ。例えばcuisine=xなら、勝手に新しい値を作るんじゃなくて、一番一般的なものにマッチさせる、みたいなね。

もちろんLLMでもできるけど、オンデバイスで動けばもっと快適だし安上がりでいいよね。

「全ての電気をオン/オフして」とか「風呂場が暗すぎる」っていう直接的な指示はうまくいったけど、少しでも回りくどいとダメだったな。「寒すぎる」と言うと、実際にサーモスタットを下げてきた（「寒い」と言うと……なぜか電気を暗くした？）。悪い反応に対する信頼度はかなり低かったから、デモに閾値を設定したほうがいいかもね。

それとも、単にサーモスタットを下げたがる変なバイアスがあるのかな？「暑くして」と言っても下げてきたし（具体的には20度から18度になった、いや、UI上は20度だったから試みただけかな）。自信満々にね。あと、摂氏と華氏の混乱もあるかも。コンセプトはいいけど、今の段階でオーブンを制御させるのは怖いかもな。

ラップトップのデモはメールアプリを開こうとするまではうまく動いてたよ。「メールをチェック」はエラー付きでブラウザを開き続け、「メールを見る」だと「email」というテキストのメモが作られて、「メールを開く」だと実際のブラウザで「https://api.email.com/v1/email 」に飛ぶけど、「メール」を開くなら動く、みたいな。

それに「推論」もあんまり信頼できないよね？車の中で「音量を上げて（turn it up）」と言ったら、「音量を下げること」と解釈して、音量を下げるコマンドを送ってきたよ。家でも、アラームをオフにしたいっていう意図は正しく推論できてるのに、実際には実行してくれなかったりね。

いやあ、誰かがこれを開発しているのがすごく嬉しいよ。数ヶ月前に似たようなことを試してみたんだけど、結論としてモデルそのものと同じくらいデータセットが重要だと気づいたんだ。優れたデータセットを作るのは、新しいモデルアーキテクチャを構築するほど派手じゃないけど、本当に不可欠なことだからね。

例えば、ユーザーが発するあらゆるスマートホームの命令に対応したいだろ？スマートホームデバイスにはどんなものがあるのか、どんな言い回しで命令する可能性があるのか、全部網羅するのは大変だ。あと、Spotifyのようなサービスだと「The Beatles」や「Led Zeppelin」が何かなんて分からないし。アーティスト名や曲名だけで、スマートホームの全デバイスを合わせたのと同じくらいの難易度になり得るんだよ。

シンプルなアテンション・ネットワークはかっこいいし、パラメータ数を占有するMLPを削るのも理にかなってる。まあ、いくらか「世界の知識」は失うだろうけど、それは多分許容範囲だよね。

今日、ラベリング（ラベル付け）のために試してみたんだけど、そのタスクには全然ダメだったな。MNLIの方がマシだった。だから、このモデルのユースケースに完全に合致させる必要があると思う（29MBのパラメータならそれも予想通りだけどさ！）。もちろんラベリングが悪いユースケースだと言いたいわけじゃなくて、単なるデータポイントとしてね。

Jevが波紋を広げたせいで、みんな急に分類器やエンコーダ専用モデルに再注目し始めたよね。

理想的なモデルは、分類の質問に答えつつ、分類の回数が増えるごとにエンコーダ専用モデルへと蒸留されていって、コストがどんどん下がっていくような汎用LLM APIだな（つまり、分類器に処理をオフロードしていく感じ）。もし誰かがこれをサービスとして提供してくれるならぜひ教えてほしいよ。分類が必要な新しいプロジェクトごとに管理するコードが増えるのはもう懲り懲りだから。

あと、これを内部で完結できるモデルがあるなら最高だね。

すごくクールなプロジェクトだけど、もちろん完璧じゃないね。30MBのヒューリスティックなルールを詰め込むより、30MBのフレーズを家庭内の「完璧で正しい」制御に変更する機能にマッピングしてくれた方がうれしいな。「家を暖めて（暖房を上げる）」と言ったら、モデルは照明を「温かみのある明るさ」に変えてしまったよ。推論としては『「家を暖めて」 -> 照明を温かい光に設定。部屋の指定がないので、デフォルトの「リビング」を使用』だそうだけど。

これはNeedle 2からの確実な進歩だね。以前、Runescapeのデータベースサイト向けのツール呼び出しインターフェースでNeedle 2を使ったことがあるんだけど、残念ながら今のFunctionGemmaと比べると、僕の目的にはまだ少し能力不足かな。

   Model                            Correct tool shape    Exact arguments
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━
   FunctionGemma fine-tune, BF16       209/230 (90.9%)    196/230 (85.2%)
  ───────────────────────────────  ────────────────────  ─────────────────
   Needle 3 fine-tuned W4A8             74/230 (32.2%)     47/230 (20.4%)
  ───────────────────────────────  ────────────────────  ─────────────────
   Needle 2 fine-tuned W4               59/230 (25.7%)     43/230 (18.7%)

これがWebgpu用のシェーダーコンパイルとして @guggingface/kernels で実装されたら最高なんだけどな。

これ、めちゃくちゃクールだね。「家の温度を上げて、リビングの電気を消して」って同時に指示してみたら、すごく綺麗なJSONドキュメントが返ってきたよ。

WhisperやParakeetみたいな小さな音声認識モデルと組み合わせれば、車、船舶、住宅、PLC、産業用オートメーションといった、低電力環境でも驚くような実用的な使い方ができるはず。家庭用の太陽光・風力発電システムと組み合わせたら、かなり面白いことになりそうだ。