AI API 燒錢燒到手軟？資深工程師教你 WordPress 串接的 Rate Limit 破解與成本控制術

嗨，我是 Eric。這兩年最讓我這個資深工程師感到興奮，同時也感到「錢包在淌血」的技術，絕對非 AI 莫屬。從 OpenAI 的 GPT-4 到 Google 的 Gemini，再到 Anthropic 的 Claude，我們在 WordPress 專案中導入這些強大的 LLM 模型來做自動客服、內容生成，甚至是自動化標籤系統，效果真的沒話說。

但是，現實總是骨感的。當你的網站流量稍微起來一點，或者你寫的迴圈稍微不小心一點，兩大惡夢就會接踵而來：429 Too Many Requests (Rate Limit) 和 月底那張驚人的 API 帳單。

「明明測試時都好好的，怎麼上線就掛掉？」、「為什麼我只跑了幾百篇文章的摘要，信用卡就刷了幾百美金？」

別擔心，這不是你一個人的問題。今天這篇文章，我要把我們在浪花科技實際運用在客戶專案中的「AI API 防爆與省錢心法」全部分享給你。我們會從快取策略、錯誤重試機制，講到模型路由（Model Routing）的經濟學。

為什麼你的 API 總是噴 429 錯誤？

在深入解決方案之前，我們先搞清楚敵人是誰。AI 服務供應商（如 OpenAI）通常會有兩種限制：

• RPM (Requests Per Minute)：每分鐘允許的請求次數。
• TPM (Tokens Per Minute)：每分鐘允許消耗的 Token 數量。

在 WordPress 的環境中，最常見的情況是：你寫了一個批次處理程式（例如用 WP-Cron 或是 Action Scheduler），想要一次性幫 WooCommerce 的 500 個商品生成 SEO 描述。如果你的程式碼是「同步」且「無間隔」地執行，大概在第 50 個商品時，你的 API Key 就會被暫時封鎖，噴出 HTTP 429 錯誤。

第一道防線：智慧快取 (Smart Caching)

這是我看到新手最常犯的錯誤：重複問 AI 一樣的問題。

如果你的使用者在你的首頁 Chatbot 問了「你們的營業時間是幾點？」，而五分鐘後另一個使用者問了同樣的問題，你為什麼要再付一次錢給 OpenAI？

在 WordPress 中，我們可以使用 Transients API 甚至是更高效的 Redis Object Cache 來儲存 AI 的回應。這不僅能省錢，還能讓使用者感到「秒回」的快感，因為根本沒經過 API。

實戰代碼：封裝快取層

這段程式碼展示了如何在發送請求前，先檢查是否有快取。這是我在開發外掛時的標準起手式：

function roamer_get_ai_response( $prompt ) {
    // 1. 建立快取 Key，使用 MD5 將 prompt 雜湊化，確保 key 不會過長且唯一
    $cache_key = 'ai_resp_' . md5( $prompt );

    // 2. 檢查是否有快取 (預設存活 24 小時)
    $cached_response = get_transient( $cache_key );

    if ( false !== $cached_response ) {
        // Eric 小囉嗦：如果有快取，直接回傳，這可是幫客戶省錢的關鍵！
        return $cached_response . ' (Cached)';
    }

    // 3. 如果沒有快取，才真的去 Call API
    $api_response = roamer_call_openai_api( $prompt ); // 假設這是你的 API 呼叫函式

    if ( ! is_wp_error( $api_response ) ) {
        // 4. 將結果寫入快取，設定 1 天 (DAY_IN_SECONDS)
        set_transient( $cache_key, $api_response, DAY_IN_SECONDS );
    }

    return $api_response;
}

光是加上這一段，對於常見問題類型的 Chatbot，或是重複性高的內容生成任務，就能節省 30% ~ 50% 的 API 費用。

第二道防線：指數退讓 (Exponential Backoff)

即使有了快取，當你要大量處理資料時，還是會撞到 Rate Limit。這時候，千萬不要直接讓程式 die() 或是拋出例外讓使用者看到亂碼。

你需要的是「優雅的重試」。我們採用的是指數退讓 (Exponential Backoff) 演算法。簡單說就是：第一次失敗等 1 秒，第二次等 2 秒，第三次等 4 秒，以此類推。給 API 伺服器一點喘息的空間。

實戰代碼：帶有重試機制的 API 請求

function roamer_safe_api_request( $url, $body, $max_retries = 3 ) {
    $attempt = 0;
    
    while ( $attempt < $max_retries ) {
        $response = wp_remote_post( $url, [
            'body'    => json_encode( $body ),
            'headers' => [
                'Content-Type'  => 'application/json',
                'Authorization' => 'Bearer ' . YOUR_API_KEY,
            ],
            'timeout' => 30,
        ]);

        // 檢查是否為 Rate Limit (429)
        if ( 429 === wp_remote_retrieve_response_code( $response ) ) {
            $attempt++;
            
            // 計算等待時間：2 的次方 (1s, 2s, 4s...)
            $wait_time = pow( 2, $attempt );
            
            // Eric 小囉嗦：這邊用 error_log 紀錄一下，方便除錯
            error_log( "API Rate Limited. Retrying in {$wait_time} seconds..." );
            
            sleep( $wait_time );
            continue;
        }

        // 如果不是 429，或是成功，直接回傳結果（讓上層處理其他錯誤）
        return $response;
    }

    return new WP_Error( 'api_limit_exceeded', '已達最大重試次數，請稍後再試。' );
}

這段程式碼是我們內部標準庫的一部分，它能極大程度地減少因為瞬間流量高峰導致的任務失敗。

第三道防線：模型路由 (Model Routing) 與成本控制

這是 2025 年最重要的觀念。以前我們只有 GPT-4 可以選，現在選擇多得像便利商店的飲料。

「殺雞焉用牛刀」是成本控制的核心。請記住以下原則：

• 簡單任務 (錯字檢查、情感分析、簡單分類)：使用 GPT-4o-mini 或 Google Gemini Flash。這些模型的成本幾乎是頂級模型的 1/20 甚至更低，速度卻極快。
• 複雜任務 (創意寫作、邏輯推理、程式碼生成)：才使用 GPT-4o 或 Claude 3.5 Sonnet。

在你的 WordPress 程式碼中，不要把 model name 寫死。建議在後台做一個設定頁面，或者寫一個簡單的 Router 函式：

function roamer_select_ai_model( $task_complexity ) {
    switch ( $task_complexity ) {
        case 'simple':
            // 用便宜又快的模型
            return 'gpt-4o-mini'; 
        case 'complex':
            // 用聰明但貴的模型
            return 'gpt-4o';
        default:
            return 'gpt-4o-mini';
    }
}

進階技巧：使用 Queue (佇列) 非同步處理

如果你的應用場景是「使用者填寫表單後，AI 自動生成一份 PDF 報告寄給他」，這絕對不能在前端同步執行。因為 AI 生成可能需要 30 秒，PHP 的 max_execution_time 早就超時了，使用者也會以為網站壞掉。

這時候，你需要 WordPress 內建的神器：Action Scheduler。

將 AI 請求放入背景佇列，讓 Worker 在背景慢慢跑。這樣不僅使用者體驗好，我們還能控制 Worker 的併發數量（Concurrency），主動避免觸發 API 的 Rate Limit。

結論：技術是為了服務預算

身為工程師，我們很容易沉迷於「能夠串接最新最強的模型」，但 Eric 必須提醒你，在商業專案中，「能夠穩定運行且符合成本效益」才是真正的技術實力。透過快取機制、指數退讓重試、以及聰明的模型選擇，你才能駕馭這些強大的 AI 工具，而不是被帳單駕馭。

如果你在 WordPress 整合 AI 的過程中遇到了效能瓶頸，或者是 API 架構設計上的難題，歡迎隨時找我們聊聊。我們處理過非常多高併發的 AI 應用場景，相信能給你最實戰的建議。

立即聯繫浪花科技，打造你的 AI 智慧網站