Needle - Gemini Tool Callingを蒸留した2600万パラメータモデル
(github.com/cactus-compute)- 2,600万パラメータのオープンソースのツール使用（tool use）モデルで、スマートフォン・スマートウォッチ・メガネのような小型コンシューマーデバイスで動作するよう設計
- ツール呼び出しは推論ではなく検索と組み立て（クエリ→ツール名マッチング→引数抽出→JSON出力）であるため、大規模モデルは不要だという観察から出発
- Simple Attention Networkアーキテクチャを採用し、モデル全体がattentionとgatingのみで構成、MLPは一切なし
- Encoder 12層 + Decoder 8層、cross-attentionで接続
- d=512, 8H/4KV, BPE=8192
- Gemini 3.1を**蒸留（distill）**して生成され、16 TPU v6eで200Bトークンの事前学習（27時間）、2Bトークンの関数呼び出しデータで後続学習（45分）
- プロダクションでCactus推論エンジン上にてprefill 6,000 tok/s, decode 1,200 tok/sの速度を達成
- 単一呼び出しの関数呼び出しベンチマークでFunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350Mを上回る
- ただし対話環境では、これらのモデルのほうがより広い汎用性を持つ
- FFNがなくても外部の構造化知識にアクセス可能なすべてのタスク（RAG, ツール使用など）へ一般化可能
- 事実情報が入力として与えられれば、FFN重みに記憶しておく必要はない
needle playgroundコマンドでWeb UI上から独自ツールのテストとワンクリックのファインチューニングが可能で、Mac/PCでのローカルファインチューニングにも対応- 学習データセットはGeminiで合成され、タイマー・メッセージング・ナビゲーション・スマートホームなど15のツールカテゴリを含む
- MITライセンス、Pythonベース、重みおよびデータセット生成過程をHugging Faceで完全公開
2件のコメント
日本語でもうまくいくでしょうか..?
Hacker Newsのコメント
ツール使用モデルの識別能力について、何か例やデータがあるのか気になる
例としては「サンフランシスコの天気はどう？」のようなもので、渡されるツールは
tools='[{"name":"get_weather","parameters":{"location":"string"}}]'程度10年以上前に、SPARQLと知識グラフでこの種の問題を処理できるもの[1]を作ったことがある
本当に気になるのは、曖昧性の処理がどれほどうまいかという点
「明日10時にコーヒーでも飲みながら会おう」のようなメッセージや、「これ保存して」のような命令を送ったときに、数百個とまではいかなくても数十個ある候補ツールの中から「予定追加」という動作を選べるのか知りたい
[1] https://github.com/nlothian/Acuitra/wiki/About
プロンプトは「上司に遅れると連絡しないと」で、結果は
20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}]だったメールのツールは使われず、2〜3通り別の聞き方もしたが似たようなものだった
Googleの対応を心配しなくていいのか気になる
Googleは蒸留の試みに対して、「生徒モデルの性能を低下させうるリアルタイムの先制防御」で対応しているとされている
検知されていたなら、意図的により間抜けだがもっともらしいGeminiの亜種を食わされていた可能性もある: https://cloud.google.com/blog/topics/threat-intelligence/dis...
ただ、このモデルは小さく、ツール使用だけに特化しているので、トークン使用量の面ではモデル全体を蒸留しようとする人たちにまったく及ばない可能性が高い
自然言語で引数を任意指定できるコマンドラインプログラムのようなものが作れるようになるかもしれない
もちろん、「パース」のために14MBと追加計算を含めることに反対する人は多いだろうし、みんながやり始めたらかなりまずいかもしれない
それでも、今や可能になったという点は本当に興味深い
プログラムの使い方を理解するように微調整したモデルを同梱できる
たとえば
> toolcli what can you doはtoolcli --help summaryを実行し、toolcli add tom to teamfutz groupはtoolcli --gadd teamfutz tomになる、といった具合ただし、同じ課題は依然として残っている
“needle playground” のライブデモを公開するとよさそう
サイズが小さいので、小さなVPSのどこかで動かすコストもかなり安そうに思える
それでも誰にでもできるし、ノートPCでそのまま動かすのも簡単
VPS経由も試してみるつもり
「検索タスクにはFFNは不要だ」という観察が興味深い
知識が文脈内にあるなら、そのタスクではFFN重みが冗長だという主張に近い
複数回の呼び出しにまたがって状態を追跡しなければならないマルチターンのツール呼び出しにも一般化できるのか、それともそこで破綻するのか気になる
単発の呼び出しは簡単なケースだ
興味深いし、初期のClaude Code利用時に見た観察とも一致する
Sonnetはより多くの文脈を集めようとしてツールを素早く呼ぶことが多く、Opusは手持ちの文脈で問題を解こうとしてより長く推論することがあった
そのせいで重複した関数が大量に生まれ、開発も遅くなったが、新しいモデルであるGPT-5.5とOpus 4.6ではこの問題は減っているように見える
私の結論は、「より愚か」、つまりより小さなモデルの方がエージェント実行シェルとして優れている可能性があり、少なくとも多くの問題では、より安く速く回すうえで現実的かもしれないということ
Geminiが長い連続のツール呼び出しを特にうまくこなすとは感じなかった
実際のCodexやClaude Codeのセッションのように、ユーザーの問いの合間に長いツール呼び出しチェーンがある痕跡を蒸留したら面白そうだ
個人的には、32GBのM2 MacBook Proのような環境で簡単に動かせて、ツール呼び出し強化学習を主目的にした、もう少し大きいモデルがあるとよいと思う
KimiやQwenのようなオープンウェイトモデルは近づいてきているが、小型デバイス向けに必要な量子化で性能がかなり落ちるように見える
最近のエージェントフレームワーク流行は愚かで、その大半はLLM企業の売上を増やすために存在していると思う
LLMは概して有用性が限られているが、1回のツール使用と組み合わせると、はるかに有用で信頼できるものになる
私はopenrouter APIの上に、ごく特定の作業向けツール群を自作して使っている
ボタンを押すとLLMが有用な仕事を1つする、という方式であって、ボタンを押したあとLLMが5分間ツール呼び出しをループしながら正しい順序で処理してくれることを期待する方式ではない
複数のツール呼び出しが必要なら、コード側で決定的につなぐ
Aの出力を確認してからBまたはCへ進めるので、はるかに信頼性が高く、時間とトークンの効率もよい
エージェントループは巨大な詐欺に近いと思う
なぜ私たちが何とかして「動くようにする」ために苦労しなければならないのか分からない
Google、MS、Meta、OpenAIなどは今や自分たちの道具をそれとなく「Intelligence」と呼ぼうとしていて、しかも「Artificial Intelligence」ですらないのに、ならばなぜ知的でもなく、なぜ動かないのか
1兆ドル超の投資が入ったのに、なぜ私たちは今なお、スロップ生成機が半分は有効な出力を出すように最高の呪文や設定を考えなければならないのか
一部の技術リーダーたちが、自分たちの奇妙な「文明」構想の中で私たちを従わせると露骨に脅しているというのに
私たちのより良い頭脳の使い道は別にあり、魔法の神託の無力な補助役へと自分を貶めるべきではない、という気持ちだ
「モデルが外部知識ソースに依存する限り、トランスフォーマーネットワークからMLPを完全に取り除ける」というCactus実験の結果がおもしろい
ちょうど今日、私の学生の1人もこれを裏づける研究結果を発表した
QwenからMLPを取り除くと、モデルはなお入力に対する変換作業はできたが、知識は失われた
MとBの違いがあまりにも紛らわしい
0.026Bと書くことを提案する
最近のLLM開発者が十億単位のモデルにより慣れているとしても、この表記は有効だ
期待している、素晴らしい仕事だ
Gemma4 Edgeモデルはエージェント用途に向いていると約束されていたが、私が試したすべてのテストでは本当にがっかりだった
最も基本的なツール使用シナリオですら失敗する
Needleについてツール使用ベンチマークを回したことがあるのか、あるいは予定しているのか気になる
もしあるなら、リポジトリに結果を追加してほしい
アラーム設定と買い物リスト追加を今試してみたが、Siriよりうまくできた