ハクソク

世界を動かす技術を、日本語で。

Show HN: Cactus Needle 3: 8-29MB自動化モデルはDeepSeek V4 Flashと互換性があります

2026年9月18日原文(cactuscompute.com)

概要

  • Needle 3 は、2層から20層まで選べる小型AIモデル。
  • ツール呼び出し ・ 構造化JSON出力 に特化し、チャット機能は非搭載。
  • モバイル・組み込み端末 でも動作可能な軽量設計と高速推論。
  • 多言語対応 ・ ファインチューニング ・ 信頼度スコア など実用機能を搭載。
  • 幅広いプラットフォーム にプリビルドエンジンを提供。

Needle 3の特徴

  • インテリジェンスラダー モデルは2層（2L）から20層（20L）までのサブネットワークを持ち、用途や端末性能に合わせて選択可能。1つの重みセットで全深度対応。

  • ツール呼び出し自動化 アプリが公開する関数群から、ユーザーリクエストに最適なツールを自動選択し、引数も自動で埋め込み。

  • 構造化抽出 任意のテキストから事前定義したスキーマに沿って型付きデータを抽出。デコード文法により常にパース可能なJSONを生成。

  • テキスト埋め込み 同じモデルから文ベクトルを出力し、ローカルでの検索・マッチング・ルーティングを実現。

  • 適用例 ・スマートホーム：音声命令で複数デバイスを一括操作 ・ロボット：細かい指示の実行 ・スマートフォン：端末内アクションの自動化 ・ウェアラブル：通知の構造化解析 ・ARグラス：オフラインでのナビ・検索 ・自動車：会話ベースの車内操作 ・パソコン：自然言語によるローカル操作

モデル設計と性能

  • ラダー型ネットワーク 各層が独立したサブネットワーク。4Lモデルはタスク固有ファインチューニングでDeepSeek V4 Flash相当の性能を実現。

  • 超軽量バイナリ 9～29MB（CQ2ビット）のバイナリ生成。29M～121Mパラメータ。

  • 高速推論 Raspberry Pi 5で最大4,000トークン/秒のデコード、最大10,000トークン/秒のプリフィル。

  • 専用MLP（Monarch Hadamard MLP） 高効率なパラメータ設計でO(d√d)コストの完全非線形変換を実現。

  • 多言語対応 英語・フランス語・スペイン語・ドイツ語・オランダ語・イタリア語・ポーランド語に対応。

ツール設計と使い方

  • Pythonパッケージ提供 Hugging Faceから推論エンジンを一度取得すれば即利用可能。

  • 関数デコレータ 関数シグネチャで引数型、docstringで説明、run()で実行。モデルが自動で呼び出し・引数設定・結果返却。

  • パターンルーティング 正規表現でリクエストとツールを厳密にマッチング。catch-all設計や誤ルーティング防止も可能。

  • 構造化抽出 Pydanticモデルを渡してextract()を呼ぶだけで型付きオブジェクトを取得。

  • 信頼度スコア付与 全レスポンスに信頼度スコアを付与。閾値未満は抑制、閾値以上で自動実行やユーザー確認を分岐。

  • ツール設計のポイント ・1アクション1ツール ・説明は具体的に ・enum値はユーザー発話に合わせる ・必須引数にデフォルト値を設定 ・トリガー（正規表現）で確実なルーティング

  • ファインチューニング LoRAで20Lベースを微調整し、任意のサブネットワークを4ビット量子化して再利用可能。

Cactus Platformとデプロイ

  • Cactus Platform データセット、量子化、評価設計、ファインチューン、データセット管理を一括提供。独自インフラで完結。

  • デプロイ手順 1MB未満のエンジンとneedle3.cact重みを同一フォルダに配置。needle buildでプラットフォーム別エンジンと重みを自動取得。

  • 対応プラットフォーム ・macOS ・Linux（x86_64, ARM64, ARMv7, RISC-V, MIPS32） ・Windows（x64, ARM） ・Android ・iOS, tvOS, watchOS ・WebAssembly（ブラウザ、WASI）

まとめ・開発者へのメッセージ

  • Needle 3 はチャット型AIではなく、 自動化・構造化出力 に特化した超軽量AI。
  • 小型端末・組み込み機器 向けに最適化され、 幅広いプラットフォーム で利用可能。
  • ツール設計・ファインチューン によるカスタマイズ性と、 高性能・高速推論 を両立。
  • コミュニティからのフィードバック を歓迎し、今後も機能拡張・多言語化を継続予定。

Hackerたちの意見

俺の考えだけど、小さいモデルがLLMに勝てるっていう怪しい主張が増えると、役立つイノベーションが見落とされちゃうと思うんだ。リソースの要件よりも大事なのは、一般的なLLMがうまくやってることをそのモデルが全く試みることすらできないってことを強調することだよ。つまり、俺が自分で気づかなくて済むように、明確にアンチユースケースを教えてほしいな。

└

いい指摘だね！Needleはタスク特化型モデルで、バレット6でも狭いタスクに特化して訓練されてるって強調されてるけど、もうちょっとわかりやすくできるかも？

└

LLMはスイスアーミーナイフみたいなもんだ。これはコルク抜き。一般的なLLMができる他のタスク（ピザについての詩を書いて、これをRustに書き直して、バラ戦争の原因について教えて）には対応してない。このモデルがサポートしてるのは、非構造化テキストを構造化されたJSONコールに変換することだけで、それを低メモリ環境で素早くやること。

これでトイレのライトがつくのかなって思ったんだけど： 「トイレ行きたい」→ 音楽を流そうとする（「wee」はジャンルだから） 「トイレ行きたい行きたい」→ トイレで掃除機を始める 「トイレ行くよ」→ トイレをつけるって言うけど、具体的に何をするのかはよくわからない。 「トイレ行くけど見えない」→ トイレのライトをつけるべきだと考えて、再度トイレをつけることに。 「トイレ行くけどどこに行くかわからない」→ 理由は「'トイレ行く' → control_device with device 'コーヒーメーカー'（トイレはコーヒーメーカーを暗示）」 「トイレ行くけどどこに行くかわからない、暗すぎる」→ 「'暗い' → direction '暗い'; adjust_lights with brightness 100 for darker light」ってなって、リビングのライトを「暗く」することにしたけど失敗。 この時点で掃除機は暗いトイレにいて、リビングは100%の明るさで「wee」を流してる。まあ、コーヒーはあるけどね。

└

これありがとう、実はツールやその説明を編集できるんだよ。デモは「始めるための」プリセットに過ぎないけど、まだ推論の改善の余地はあるね！

└

ほぼ俺の経験と一致してる。> 'sleepy time'は寝ることを意味する → 'bedroom'の部屋で掃除を始める "DeepSeek 4 Flash grade"の主張はちょっと無理があるように思う。

└

このサイズのモデルに対して期待しすぎだよ。

└

ファインチューニングすればどうかな？

これに使えるアイデアがあるんだけど、どう思う？意味があると思う？アプローチについて何か意見があれば教えてほしいな。俺はOpenStreetMapの大ファンで、パソコンから編集するのが好きなんだ。携帯からだと、電話番号を正確に入力して確認するのがすごく面倒だし、Upredorの大きなリストから正しいフィールドを探して選ぶのも大変。一般的には、レストランを見つけて、看板があって、「現金のみ。電話番号はこれ。営業時間はこれ。」ってわかるといいんだけど、もし「この場所の情報を教えて」って携帯に話しかけるだけで、自動的に近くの場所を検出して、どの場所について話してるかもわかって、「じゃあ、提案してる変更はこれだよ、もしくはこれが差分になるよ」って言ってくれたらすごくいいよね。多分、20個くらいの一般的なキーに限定されると思うけど、料理の種類は最も一般的なものでマッチすればいいし、新しいのを作り出さないように。もちろん、これは大きな言語モデルができることだけど、デバイス上で動かせるのがもっといいし、安く済むと思う。

└

すごく理にかなってる！約20個のキーをフィールドとして1つのレコードを宣言して、料理と友達を一般的な値の列挙型にして、文法がセットの外の値を生成できないようにする。証拠のないフィールドは空で返ってくるから、出力はまさに差分になる。「どの場所か」を知るために、アプリ内の位置から近くのPOIをクエリして、候補名を列挙型フィールドとして渡すことで、Needleが推測するのではなく選ぶようにする。2つの注意点：テキスト入力なので、まずデバイス上でSTTが必要だし、営業時間の文法がリスキーな部分だから、フォーマットを説明に入れるか、生の時間をキャッチしてコードで正規化する必要がある。

「すべてのライトをオン/オフにする」と「トイレが暗すぎる」はうまくいったけど、それ以外の直接的じゃないのはダメだった。「寒すぎる」って言ったら、実際にサーモスタットを下げちゃった（「寒い」って言ったら…ライトを下げた？）！悪い反応の自信はかなり低かったから、デモにしきい値を追加する価値があるかも。もしかしたら、変なサーモスタットダウンバイアスがあるのかも？「暑くして」って言ったら、逆に下げちゃった（具体的には20から18に、もしくは試みたけど、UIはまだ20を表示してた）、自信は高かったけど。摂氏と華氏の混乱もあるかも。面白いコンセプトだけど、今はオーブンを操作させたくないな。ノートパソコンのデモは良かったけど、メールアプリを開こうとしたら、「メールをチェック」って言ったらエラーでブラウザが開いて、「メールを確認」って言ったら「email」ってテキストのメモができて、「メールを開く」って言ったら実際のブラウザで「https://api.email.com/v1/email」になったけど、「メールを開く」はうまくいった。で、「推論」はあまり信頼できないと思う？車の中では「'音量を上げて'は音量を下げることを意味する→ set_volume with lower value」ってなった。家では、推論はアラームをオフにしたいって正しく言ったけど、実際にはそれをやってくれなかった。

└

ありがとう、フィードバックめっちゃ助かるよ！いくつかはプレイグラウンドでのツール定義やトリガーに関係してた。今、更新したから、もっと信頼性が高くなったはず。ほんと、これはニードルが頑張ってツールリストを使いやすくした結果だね。理由についてだけど、主な機能はモデルがツールコールのレスポンスを生成する時に掴める言葉やキーワードを増やすことなんだ。これはSANモデルだから、既存のコンテキストにもっと基づく必要がある。

Hacker Newsで議論の続きを見る