Cactus レビュー: スマホ・ウェアラブル向け推論エンジンの実力と境界線

Cactus が埋めようとしているのは「モデルを端末に置く」と「アプリから呼ぶ」の間の溝

オンデバイス推論の部品はすでに揃っています。量子化ツール、ARM 向けのカーネル、推論ランタイムはそれぞれ別のプロジェクトとして存在します。問題は、それらを組み合わせて iOS や Android のアプリに載せるまでの配線作業が、モデルごと・チップごとに発生することです。Cactus はこの配線を 1 つのリポジトリにまとめようとしています。README の構成図では、最上位に Cactus Engine（OpenAI 互換 API）、その下に Cactus Graph（ゼロコピーの計算グラフ）、Cactus Kernels（Apple や Samsung、Pixel 向けの CPU/GPU カーネル）、最下層に Cactus Quants（回転ベースの独自量子化）が積まれています。対象はスマートフォン、ウェアラブル、スマートホーム、ロボットです。想定読者は、クラウドに音声やテキストを送らずに推論を完結させたいアプリ開発者、あるいは通信が不安定な環境で動く機器を作るチームになります。

Engine と Graph の分離が意味するもの

Cactus Engine の入口は cactus_init と cactus_complete の 2 つです。cactus_init には重みフォルダのパス、自動 RAG 用のテキスト（ファイルまたはディレクトリ）、真偽値の 3 つを渡します。cactus_complete にはモデルハンドル、JSON 形式のチャットメッセージ、応答バッファ、そのサイズ、生成オプション、ツール定義 JSON、ストリーミングコールバック、ユーザーデータ、PCM 音声バッファ、そのサイズを渡す構成です。README の例では max_tokens と stop_sequences をオプションとして指定しています。応答は JSON で返り、success、cloud_handoff、response、function_calls、segments、confidence、confidence_threshold、time_to_first_token_ms、total_time_ms、prefill_tps、decode_tps、ram_usage_mb などのフィールドを含みます。ここで目を引くのは confidence と confidence_threshold が応答に含まれる点です。Cactus Hybrid はこの confidence を閾値と比較して、難しいクエリを自動的にクラウドへ回すと docs/cactus_hybrid.md に記載されています。つまり Engine の層は、端末内推論の結果だけでなく「これをクラウドに送るべきか」という判断材料まで返す設計になっています。Graph 側は別の抽象です。CactusGraph に対して input、matmul、transpose を繋ぎ、set_input でデータを流し込み、execute で評価し、get_output で取り出し、hard_reset で解放する流れが README に示されています。入力の Precision は FP16 と INT8 を混在させられるため、層ごとに精度を変える用途を想定していると読めます。Engine と Graph が別ドキュメントに分かれていること自体が、この 2 層を独立に使う前提の表れです。

CQ2 から CQ4 まで、量子化の段数で何が壊れるか

README の Output Quality 表は、Gemma-4-E2B-it を 3 シードで平均した数値をビット幅ごとに並べています。CQ4 は F16 とほぼ同等で、ARC-E が 73.80 から 73.73、HellaSwag が 46.93 から 47.07、HumanEval が 54.88 から 57.11 と、むしろ上がっている項目もあります。CQ3.26 は混合精度で、ARC-E は 74.20 と F16 を上回る一方、GSM8K は 73.67 から 66.20 へ下がります。CQ2.54 も混合精度ですが、ここから崩れ方が急になります。GSM8K は 22.00、HumanEval は 15.24、BFCL Parallel は 30.00 です。CQ2 はさらに厳しく、GSM8K 0.40、HumanEval 1.02、BFCL Simple 18.75 という値が並びます。この表から読み取れるのは、多段の推論とコード生成が先に壊れ、分類や常識推論は比較的持ちこたえるという順序です。ARC-E や HellaSwag が CQ2 でも 50.80 / 35.87 を保っているのに対し、GSM8K が 0.40 まで落ちる差は無視できません。量子化の段数を落とす判断は、モデル全体の平均スコアではなく、自分のタスクが表のどの行に当たるかで決める必要があります。

セットアップは brew と cactus コマンド 3 つで足りる範囲

Mac での導入手順は README に 2 ステップで書かれています。brew install cactus-compute/cactus/cactus を実行し、次に cactus run を叩くだけです。モデルの入手と変換は cactus download [HF-Name] と cactus convert [HF-Name] が担い、cactus run [HF-Name] はモデルが見つからなければ先にダウンロードまたは変換を行うと記述されています。HuggingFace の任意のモデルを cactus convert で変換できるとされますが、README 自身が experimental と注記しています。特にテストされているのは Liquid、Gemma、whisper、parakeet、Qwen の各ファミリです。ツール呼び出しを試す場合は cactus run Cactus-Compute/needle --tools my_tools.json という形式で、ツール定義は OpenAI の function-calling 形式、--tools を省略した場合はデモ用ツールセットが使われると書かれています。性能測定は cactus benchmark で、--ios または --android を任意で付けます。バインディングは Swift、Kotlin、Flutter、React Native、Python、Rust の 6 種類が用意されています。ここで注意したいのは、CLI の導入手順が Mac 向けにしか書かれていない点です。iOS と Android の実機測定は cactus benchmark --ios / --android で行う想定ですが、その前提となるホスト環境の構築手順は README の範囲では確認できません。

README のベンチマーク表をどう読むか

Inference Speed の表は、LLM が 1k コンテキストの prefill と 100 トークンの decode、VLM が 256px 画像のエンコード時間と decode、Transcribe が 20 秒音声の end-to-end 処理時間、RAM が LLM ベンチ中のピーク値という条件で統一されています。README は speculative decode と MTP を使わない純粋な decode だと明記しています。数値は Mac M5 Max の 2964tps / 154tps から iPhone 15 Pro の 517tps / 26tps まで、端末間で大きく開きます。RAM は 633MB から 1348MB の範囲です。同じ表の下に、M5 Max での別モデルの数値として LFM2.5-VL-1.6B が 289toks/sec、Qwen3-1.7B が 155toks/sec、LFM2.5-VL-450m が 472toks/sec で画像エンコード 43ms、LFM22.5-VL-230m が 555toks/sec と記載されています。これらはすべて Cactus 側が公表した値であり、第三者の追試結果ではありません。判断材料として使うなら、自分の対象端末と対象モデルの組み合わせで cactus benchmark を回し、同じ桁が出るかを先に確かめるべきです。表に載っている端末は Mac と Apple 系が中心で、Android 実機の数値は README の表には現れません。Samsung や Pixel 向けのカーネルが Cactus Kernels に含まれると構成図には書かれていますが、その性能を裏付ける数値はこの README には提示されていません。

クラウド併用を前提にした設計と、その代償

Cactus は端末内で完結する推論エンジンではなく、hybrid edge-cloud を名乗っています。応答 JSON の cloud_handoff フィールドが真になるのはクラウドモデルが使われた場合で、その判定は confidence と confidence_threshold の比較で行われます。confidence_threshold はモデル依存の解決済み閾値だと README は説明しています。この設計には明確な代償があります。閾値を下回った時点でリクエストは端末の外に出るため、「データを端末から出さない」ことを要件にしている用途では、この経路を無効化するか閾値を調整する必要があります。README にはその無効化方法や閾値の設定キーが示されていないため、採用前に docs/cactus_hybrid.md と cactus_engine.h の該当箇所を読む必要があります。もう一点、cactus_init の第 2 引数が自動 RAG 用のテキスト（ファイルまたはディレクトリ）を受け取る点も見落とせません。RAG のインデックスをどこに保持し、どのタイミングで再構築するのかは README からは分かりません。端末内にベクトルインデックスを持つ以上、アプリのストレージ設計に影響します。

llama.cpp や MLX と何が違うのか

同じ領域の選択肢として llama.cpp があります。Cactus のトピックには llamacpp が含まれており、README もこの分野の隣接プロジェクトとして認識されていることをうかがわせます。両者の違いは抽象の置き方です。llama.cpp は GGUF 形式のモデルを読み込んでテキスト生成を実行するランタイムが中心で、量子化形式も GGUF 側の体系に従います。Cactus は自前の量子化（CQ2 / CQ3.26 / CQ2.54 / CQ4）を持ち、その上にゼロコピーの計算グラフを置き、さらに上に OpenAI 互換の API 層を載せる 4 層構成を取ります。テキストだけでなく音声（Parakeet-TDT-0.6B-CQ4 での transcribe）と画像（VLM の encode）を同じ Engine から扱う点も、llama.cpp をそのまま使う場合との差になります。ただし抽象が厚いということは、下位のカーネルや量子化を差し替える自由度が llama.cpp より小さい可能性があるということでもあります。独自量子化形式を採用している以上、既存の GGUF 資産をそのまま持ち込めるわけではありません。cactus convert による HuggingFace からの変換は experimental と明記されており、モデル資産の移行コストはこの経路に依存します。

ライセンス表記とメンテナンス負荷

リポジトリのライセンスは GitHub 上で NOASSERTION と表示されています。これは機械判定が既知のライセンス条項に一致しなかったという意味で、ライセンスが存在しないという意味でも、特定の条項を採用しているという意味でもありません。README にはライセンス条項への言及がなく、この記事の材料からは実際の条件を判断できません。商用利用や再配布を検討する場合は、リポジトリ直下の LICENSE ファイルと、同梱の各バインディング（bindings/swift、bindings/kotlin、bindings/flutter、bindings/react-native、bindings/python、bindings/rust）が個別の条件を持つかどうかを、法務判断の前に必ず読む必要があります。ここで法的助言はできません。メンテナンス面では、v2.0.1 が 2026-07-09、v2.1.0 が 2026-08-17、v2.2.0 が 2026-09-08 と、約 1 か月間隔でマイナー更新が続いていることがリリース履歴から読み取れます。追従コストを見積もる際は、Engine、Graph、Kernels、Quants のどの層に変更が入ったかで影響範囲が変わる点に注意してください。Engine の API 変更はアプリ側の呼び出しに直結しますが、Kernels の変更は通常、再ビルド以外の作業を要求しません。

編集部の結論

採用を検討すべきなのは、iOS / Android / Flutter / React Native のいずれかで動くアプリに、テキスト・音声・画像の推論を端末内で載せたいチームです。逆に、サーバー側の GPU で大規模モデルを回す構成や、量子化による精度劣化を許容できない用途には向きません。導入前に確認するのは 3 点です。第一に LICENSE ファイルの実際の文面（GitHub 上は NOASSERTION と表示されており、README からは条項を特定できません）。第二に、対象モデルが CQ4 と CQ3.26 のどちらで許容精度に収まるかを docs/cactus_quants.md の表で自炊確認すること。第三に、cactus benchmark --ios / --android を自分の実機で実行し、README の表の数値が自分の端末でも出るかを確かめることです。README のベンチマークはあくまで同プロジェクトが公表した値であり、第三者が再現した記録ではありません。

公式情報源

1. cactus-compute/cactus on GitHub
2. Issues
3. Project website
4. README
5. Releases