雲端算力貴到哭？2026 組合式 AI (Composable AI) 實戰：用邊緣運算與 SLM 打造企業彈性大腦

組合式 AI（Composable AI）的核心想法，是別再把所有問題都丟給雲端那顆最大的腦。Token 帳單之所以失控，常常是因為連「分類一張發票」這種小事都動用了旗艦模型；把任務拆開，讓邊緣運算上的 SLM 消化八成的日常工作，雲端只留給真正的難題，成本曲線馬上不一樣。這篇談企業怎麼搭出這顆彈性大腦。

到了 2026 年，單純依賴「一個超大模型打天下」的時代已經結束了。現在矽谷和台灣技術圈最熱門的關鍵字，絕對是 **組合式 AI 架構 (Composable AI)**。這不只是一個潮詞，它是我們這些工程師為了幫老闆省錢（同時也為了讓系統跑得更快）所找出的生存之道。

今天這篇文章，我不談虛的，我們來聊聊如何透過邊緣運算（Edge Computing）與小型語言模型（SLM）的搭配，在 WordPress 架構下實作一個聰明的 AI 路由系統。

什麼是組合式 AI (Composable AI)？為什麼 2026 年非用不可？

簡單來說，Composable AI 就像是把 AI 模型當成樂高積木。你不再將所有的請求都丟給昂貴的 GPT-5 或 Gemini 3 Ultra，而是根據任務的難度，動態分配給最適合的模型。

試想一下，如果你的客戶只是問：「你們營業時間是幾點？」，你需要動用一個參數高達數兆的超大模型來回答嗎？這就像是用核彈在打蚊子，既浪費算力又浪費錢。在 2026 年的架構思維中，我們將 AI 拆解為：

• 雲端巨型模型 (Cloud LLM)： 負責複雜推論、創意寫作、程式碼生成。例如：OpenAI GPT-5, Gemini 3。
• 邊緣小型模型 (Edge SLM)： 負責個資過濾、簡單問答、情感分析、格式轉換。例如：Llama 4-8B, Phi-5 (在本地伺服器或 NPU 上運行)。
• 協調器 (Orchestrator)： 這是大腦中的大腦，負責判斷請求該去哪裡。

組合式 AI 的三大優勢

作為工程師，我們在導入新架構時，通常是為了這三個目標：

1. 成本控制： 將 60% 的簡單流量導流到本地端免費的開源 SLM，雲端 API 費用直接腰斬。
2. 資料隱私： 敏感資料（PII）在邊緣端就被 SLM 處理或遮蔽，根本不出內網，這對金融與醫療客戶至關重要。
3. 低延遲： 邊緣運算不需要等待網路來回傳輸，簡單任務幾乎是毫秒級回應。

架構設計：邊緣運算資源如何配置？

在 WordPress 的環境中，我們要如何實現這種 **組合式 AI 架構 (Composable AI) 的興起：企業如何彈性配置邊緣運算資源** 的願景呢？我們不能指望 WordPress 本身去跑模型（PHP 會哭的），我們需要的是一個「混合架構」。

我目前的慣用架構是這樣的：

• 應用層 (WordPress)： 負責接收使用者請求，並作為協調器 (Router)。
• 邊緣運算層 (Local Microservice)： 在同一台主機或內網伺服器上，跑一個 Python Container (FastAPI)，掛載量化過的小型模型 (Quantized SLM)。
• 雲端層 (External API)： 當任務太難，邊緣層搞不定時，才 Call 出去。

2026 年的硬體紅利

現在的伺服器，甚至是 Mac mini M4 Pro，都已經具備強大的 NPU。這讓在本地跑一個 7B 或 13B 參數的模型變得非常輕鬆，甚至不需要昂貴的 A100 顯示卡。我們只需配置適量的 RAM (32GB 以上推薦) 和 NVMe SSD，就能構建一個高效的邊緣節點。

實戰：在 WordPress 中實作 AI 智慧路由 (AI Router)

這段程式碼的核心邏輯是：當使用者輸入訊息時，先由本地的輕量級分類器判斷「意圖」。如果是簡單意圖，直接本地處理；如果是複雜意圖，再轉發給 OpenAI。

雖然 2026 年我們有更強的 Agentic IDE，但基本的 Code 邏輯還是要懂。以下是一個支援經典編輯器的 PHP 範例：

PHP 實作範例

class Roamer_AI_Router {

    private $local_api_url = 'http://localhost:8000/v1/chat/completions'; // 邊緣運算節點
    private $cloud_api_url = 'https://api.openai.com/v1/chat/completions'; // 雲端節點
    private $openai_key = 'YOUR_OPENAI_KEY';

    /**
     * 主處理函式
     */
    public function handle_request( $user_message ) {
        // 1. 先用規則或極輕量模型判斷複雜度
        $complexity = $this->assess_complexity( $user_message );

        if ( $complexity === 'simple' ) {
            return $this->call_edge_slm( $user_message );
        } else {
            return $this->call_cloud_llm( $user_message );
        }
    }

    /**
     * 評估複雜度 (這裡可以用簡單的關鍵字匹配，或呼叫本地的一個 Nano 模型)
     */
    private function assess_complexity( $message ) {
        // 簡單邏輯：字數少且包含特定關鍵字視為簡單任務
        if ( mb_strlen( $message )  'llama-4-8b-quantized',
            'messages' => array( array( 'role' => 'user', 'content' => $message ) ),
            'temperature' => 0.7,
        );
        
        // 模擬發送請求 (使用 wp_remote_post)
        $response = wp_remote_post( $this->local_api_url, array(
            'body'    => json_encode( $payload ),
            'headers' => array( 'Content-Type' => 'application/json' ),
            'timeout' => 5, // 邊緣運算要求低延遲
        ));

        return $this->process_response( $response, 'Edge (Local)' );
    }

    /**
     * 呼叫雲端模型 (昂貴、強大)
     */
    private function call_cloud_llm( $message ) {
        $payload = array(
            'model' => 'gpt-5-turbo',
            'messages' => array( array( 'role' => 'user', 'content' => $message ) ),
        );

        $response = wp_remote_post( $this->cloud_api_url, array(
            'body'    => json_encode( $payload ),
            'headers' => array(
                'Content-Type'  => 'application/json',
                'Authorization' => 'Bearer ' . $this->openai_key,
            ),
            'timeout' => 30,
        ));

        return $this->process_response( $response, 'Cloud (OpenAI)' );
    }

    private function process_response( $response, $source ) {
        if ( is_wp_error( $response ) ) {
            return 'Error: ' . $response->get_error_message();
        }
        $body = json_decode( wp_remote_retrieve_body( $response ), true );
        $answer = isset( $body['choices'][0]['message']['content'] ) ? $body['choices'][0]['message']['content'] : '';
        
        // Eric 的小囉嗦：在 Log 裡標記來源對於除錯和算錢很重要
        error_log( "[Roamer AI] Source: $source | Answer generated." );
        
        return $answer;
    }
}

這段程式碼雖然簡單，但它展示了 Composable AI 的精髓：「不把雞蛋放在同一個籃子裡」。透過 assess_complexity 這個函式（在真實場景中，這通常會是一個運作在 NPU 上的 Bert 模型），我們成功地攔截了那些不需要浪費 0.03 美金的簡單請求。

邊緣運算的挑戰：容器化與資源隔離

要在企業內部落地這種架構，最大的挑戰通常不是程式碼，而是維運 (DevOps)。你需要在本地伺服器上管理這些模型。

我強烈建議使用 Docker 來部署你的邊緣模型。利用 2026 年成熟的 AI 容器映像檔（如 Ollama 的 Docker 版），你可以限制容器的 CPU 和 RAM 使用率，避免 AI 模型在運算時把整台 Web Server 的資源吃光，導致 WordPress 前台卡頓。

• 資源限制 (Cgroups)： 設定 Docker 的 --cpus 和 --memory 參數。
• API 統一化： 確保你的本地模型輸出的 JSON 格式與 OpenAI 相容，這樣你在切換模型時，PHP 端幾乎不用改 Code。

結論：彈性才是未來的唯一解

技術發展到 2026 年，我們發現「算力」依然是稀缺資源。組合式 AI 架構不只是為了省錢，更是為了讓系統具備「反脆弱」的能力。當雲端 API 掛掉時（這事常發生，對吧？），你的本地 SLM 還能支撐基本的客服運作；當本地算力不足時，雲端又能隨時補位。

這就是我們身為工程師的價值：不是只會 Call API，而是懂得設計一個能適應各種狀況的強韌架構。

想了解更多關於如何優化 AI 成本與硬體配置嗎？這裡有幾篇我精選的文章推薦給你：

相關閱讀

• AI API 帳單炸裂？2026 資深工程師教你用「智慧路由」與「快取防禦」破解 Rate Limit 並省下 70% 成本
• 伺服器在燃燒？2026 機櫃級 AI 平台散熱革命：從氣冷退場到液冷霸權的技術生存戰
• 你的程式碼正在「裸奔」？2026 企業使用雲端 AI 輔助開發的資安生存指南：從地端模型到隱私防火牆