Cactus：把量化、推論與雲端分流打包成一支行動端 AI 引擎

它解決什麼問題，寫給誰看

Cactus 瞄準的痛點很具體：在手機、手錶、智慧家庭裝置與機器人上跑生成式 AI，不是單純把模型縮小就行。記憶體頻寬、延遲、工具呼叫的可靠性，以及「模型答不出來時怎麼辦」這些問題，傳統的 llama.cpp 或 ONNX Runtime 並未一次給足。Cactus 把量化、kernel、計算圖與推論引擎綁在一起，並提供 OpenAI 相容的 API，讓開發者用類似伺服器端的方式呼叫本機模型。它的目標使用者是那些需要端側推論，但又不想從零拼接量化工具與執行環境的工程師。README 特別提到 Liquid、Gemma、whisper、parakeet 與 Qwen 系列，顯示它鎖定的是多模態與語音場景，而非純文字聊天。

四層架構：從引擎到 kernel 的分工

Cactus 的架構圖清楚畫出四層：最上層是 Cactus Engine，提供 OpenAI 相容的文字、語音與視覺 API；往下是 Cactus Graph，負責零拷貝計算圖；再來是 Cactus Kernels，針對 Apple、Samsung、Pixel 等裝置的 CPU/GPU 撰寫；底層是 Cactus Quants，採用自訂的 rotation-based 量化。這個分層的意義在於，上層 API 不直接碰張量運算，而是透過計算圖間接呼叫 kernel。Engine 的 C API 一次呼叫 cactus_complete 就能涵蓋聊天、工具呼叫、語音轉錄與 RAG，回傳的 JSON 裡有 cloud_handoff 欄位，表示是否動用雲端模型。Graph 層的設計強調 zero-copy，但 README 沒有解釋具體如何避免拷貝，這點在實際整合時需要看原始碼才能確認。

Cactus Quants：旋轉加碼本的混合精度量化

量化是 Cactus 最特別的部分。它自稱是 rotation-and-codebook quantization，支援 4-bit 到 1-bit，並提供混合精度版本 CQ3.26 與 CQ2.54，意思是不同張量可能用不同位元寬度。從 README 的準確度表格看，CQ4 在 ARC-E、HellaSwag、WinoGrande 上幾乎與 F16 持平，甚至 HumanEval 略高（57.11 對 54.88）。但 CQ2.54 在 GSM8K 掉到 22.00，CQ2 更是接近 0.40，這說明低於 3-bit 時推理能力崩壞。對比之下，BFCL 系列（工具呼叫）在 CQ2.54 仍維持 82.25 到 52.50，顯示工具呼叫對低精度的容忍度比數學推理高。這個結果暗示：混合精度不是萬靈丹，你得根據任務類型選擇位元寬度，而不是一味追求最低 bit。

實際指令：從安裝到跑模型

入門路徑很短。macOS 上先執行 brew install cactus-compute/cactus/cactus，然後 cactus run 就會啟動預設模型。想換模型，可以用 cactus convert [HF-Name] 轉換任何 HuggingFace 模型，或 cactus download [HF-Name] 下載官方預先轉好的權重。cactus run [HF-Name] 會自動下載或轉換。內建的 cactus benchmark 指令支援 --ios 與 --android 參數，可測量 LLM、VLM、語音轉錄與記憶體使用。C 程式碼範例顯示，初始化只需指定權重資料夾與文字檔路徑（用於自動 RAG），接著傳入 JSON 格式的 messages 與 options。回傳結構包含 prefill_tps、decode_tps、ram_usage_mb 這些欄位，方便開發者直接從回應中取得效能數據。Python 套件與 Swift、Kotlin、Flutter、React Native、Rust 綁定都存在，但 README 未說明各綁定的成熟度。

效能數據背後的限制

README 的效能表格列出從 Mac M5 Max 到 iPhone 15 Pro 的數據，例如 iPhone 15 Pro 的 LLM decode 是 26 tps，VLM 影像編碼需 1.15 秒。這些數字來自官方 benchmark，但沒有說明測試時的溫度、採樣參數或執行緒設定。表格下方的備註提到「1k-context prefill and decode for 100 runs on M5 Max」，暗示其他裝置可能只跑一次，這會讓比較失真。另外，所有數據都基於 Gemma-4-E2B-CQ4，這是一個 2B 模型，若你實際部署 7B 或更大模型，記憶體與延遲會完全不同。官方也承認 cactus convert 是 experimental，表示任意 HuggingFace 模型的支援並不保證。若你的目標裝置不在 Apple Silicon 或特定 Android 旗艦清單內，kernel 可能未優化，效能會打折。

雲端分流：以信心值決定何時上雲

Cactus 的 hybrid 模式是少見的設計。cactus_complete 的回傳 JSON 中有 cloud_handoff 欄位，以及 confidence 與 confidence_threshold，後者會依模型而異。這代表引擎會評估本機模型對回應的信心，若低於門檻，就自動改叫雲端模型。README 的範例中 confidence 是 0.8193，門檻 0.7，所以 cloud_handoff 為 false。這個機制對工具呼叫特別有用，因為本機小模型在複雜函式呼叫上容易出錯。但文件沒有說明雲端呼叫的延遲成本、失敗處理或隱私政策，若你的應用不能把資料送出裝置，這個功能就需要關閉或調整門檻。Cactus Hybrid 文件（cactus_hybrid.md）應有更多細節，但 README 只提到「route hard queries to the cloud automatically」。

替代方案：與 llama.cpp 的差異

最直接的替代方案是 llama.cpp，它同樣支援 ARM 裝置與多種量化格式，且授權為 MIT。差異在於 llama.cpp 是單一執行引擎，專注於 LLM 推論，沒有內建的 VLM 影像編碼、語音轉錄或雲端分流。Cactus 則把這些包成統一的 C API，並提供自己的量化格式（CQ），意味著你無法直接使用 llama.cpp 的 GGUF 權重，必須透過 cactus convert 轉換。若你只需要跑一個 Llama 模型，llama.cpp 的社群與工具鏈更成熟；但若你需要同時處理文字、影像與語音，Cactus 的整合度較高。另外，llama.cpp 沒有石墨計算圖層，它的執行是 immediate mode，而 Cactus Graph 允許你建構張量運算圖再執行，這對需要自訂前處理的 VLM 可能有利。

維護成本與授權疑慮

授權欄位是 NOASSERTION，這在 GitHub 上代表專案沒有宣告標準授權，使用前必須聯絡作者確認。對商業團隊這是重大風險，因為你不能假設它允許商用或修改。維護方面，最新版本 v2.2.0 於 2026-09-08 發布，v2.1.0 在一個月前，v2.0.1 在兩個月前，顯示釋出節奏穩定。但 README 沒有提供貢獻指南或開發文件，只有 API 文件連結。kernel 層支援多種裝置，代表每次 Apple 或 Qualcomm 推出新架構，都需要更新 kernel，這對小團隊是負擔。Python 套件與多種綁定存在，但沒有版本相容性說明，升級引擎時可能需同步更新綁定。

編輯結論

Cactus 適合需要在手機、穿戴裝置或機器人上執行 LLM、VLM 與語音辨識的團隊，尤其是那些想用單一 C API 涵蓋聊天、工具呼叫、RAG 與雲端分流的人。若你的專案只跑單一模型、不需要混合精度量化，或對非主流授權（NOASSERTION）敏感，則應先釐清授權細節再決定。採用前請驗證三件事：確認你目標裝置的 kernel 支援（例如 Apple Silicon 以外的 GPU）、用 cactus benchmark 在你自己的硬體上跑一次，並檢查混合精度量化（CQ3.26、CQ2.54）對你實際任務的準確度影響，因為 GSM8K 與 HumanEval 在 CQ2.54 以下急遽衰退。

官方來源

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