最近我一直在研究 local model，也在想要不要放一台機器在公司當備援。 原因很簡單，自己現在寫 code、做產品，真的太依賴 AI 了。如果哪天訂閱或 API 突然不能用，很多工作可能真的會直接卡住⋯ 所以我現在看 AI，會開始多想一層：模型背後的算力從哪裡來？工作可以放在哪裡跑？有沒有其他部署選擇？ 自己做 TermHive 這種多 agent 工具，還有之前做素材生成工具時，我都有在處理不同工具、服務怎麼接起來的問題。像素材生成流程裡，就加了多個服務的路由跟 CLI fallback，讓流程有其他路可以走。 做這些東西的時候，就會開始在意整個流程能不能持續跑下去，以及每一步到底需要多少模型能力。 像讀懂一個 repo、處理複雜的程式問題，跟「把這筆資料分到哪一類」「找出相關文件」「決定接下來走哪個流程」，需要的能力其實差很多，所以最近小模型、裝置端 AI 的進展，我覺得滿值得看。 Google 10/6 推出的 EmbeddingGemma 2，完整模型是 740M 參數，可以把文字、圖片、音訊等內容轉成向量，做語意搜尋與檢索。只處理文字時，用 270M 的模組就能上場，定位就是讓這些工作能在裝置端完成。 Liquid AI 10/7 也釋出了 d1-3B 跟實驗版 d1-omni-600M，走的是 decision model：用一次 forward pass 輸出選擇，專門處理分類、意圖判斷這類工作。 看到這些進展，我會想到的是：一個 agent 工作流程裡，有多少步驟可以拆出來，交給更輕量的模型處理？ 如果模型能把一件範圍明確的事情做好，那部署它需要的設備、成本和方式，就有機會跟著改變。 這也是我看 @Acurast 時，覺得有意思的地方。 它把分散在各地的手機接成運算網路，開發者提交任務，再由 Matcher 媒合任務需求跟設備資源，實際運算交給手機節點執行。 但要把工作交給別人的手機，光是有算力還不夠，設備的狀態也需要有辦法確認。 Acurast 會透過 Android Key Attestation、iPhone App Attest 這類硬體認證機制，檢查設備與 App 的狀態，也會持續排除認證被撤銷的節點。 我覺得任務調度、設備驗證、部署工具這些東西，才是手機算力能不能變成一項服務的關鍵。 它的開發文件也已經有 GGUF 模型的部署範例，示範在手機節點啟動 LLM 服務，提供相容 OpenAI 風格的 API。站在自己有在做 agent 工具的角度，這就給了一個可以研究怎麼接進現有流程的起點。 如果是我來挑第一批測試任務，我會先找能獨立執行、資料傳輸量不大、對即時性要求也沒那麼高的工作。 例如公開資料分類、批次文字處理、定期產生簡單摘要。先確認模型能把這些事做好，再去量從送出任務到拿到結果的時間，以及整體成本。 因為站在開發者的角度，最後一定會問：部署麻不麻煩？節點不在線時怎麼處理？失敗重試之後，時間和費用還划不划算？ 這些問題能解決，我才會考慮把更多工作放上去。 Acurast 主網今年 1 月已經上線，目前官方公布的累計接入規模超過 33 萬支手機。ACU 則參與部署費用、算力獎勵、質押跟治理，是這套網路運作的一部分。 而我接下來會關注的，就是這些設備能承接哪些實際工作，以及開發者用了之後，會不會繼續用。 我的判斷是，隨著更多小模型能把特定任務做好，手機這類設備可以參與的 AI 工作會變多。對 Acurast 來說，把這些能力整理成方便部署、穩定執行的服務，就是值得看的機會。 以前想到抽屜裡的舊手機，大概就是備用機。 現在至少多了一個值得研究的方向：它能不能成為某個 AI 工作流程裡，持續做事的一個節點。 有在做 AI、agent，或關注 DePIN 的，可以看看 Acurast 跟 ACU  Always DYOR。