Face Swap API 比較：WaveSpeed、Segmind 與 Replicate

挑選 face swap API，真正影響開發體驗的往往不是展示頁上的一張完美成品，而是計費方式、影片支援與工作佇列處理。如果你想要可預期、容易串接的圖片或影片流程，WaveSpeedAI 是最穩妥的起點；需要更多控制選項可看 Segmind；想比較不同模型，則適合從 Replicate 開始。

先用這張表看懂三條路線

以上價格是 2026 年 9 月 27 日查閱公開頁面時的資料。Replicate 的數字是模型頁面上的估算，並非保證費率；Segmind 的每次生成費用，則是依 GPU 使用時間推算。

先釐清產品裡的「face swap API」到底指什麼

專用 API 通常由單一供應商定義完整的介面、計價單位與工作生命週期。Replicate 這類模型市集則統一了模型執行方式，但每位作者仍可自行決定輸入、輸出、硬體與預估成本。因此，所謂「Replicate 定價」本身並不是一個有意義的單一數字。

在比較畫面品質之前，先確認以下五項合約細節：

1. 媒體單位：只支援圖片，還是也包含影片、GIF 或即時處理。
2. 完成方式：同步回應、輪詢、webhook，或同時提供多種選項。
3. 臉部選擇：最大臉部、自訂索引、明確座標，還是一個來源臉對應一個目標臉。
4. 計費單位：按圖片、秒數、GPU 秒，或模型執行時間計費。
5. 結果處理：結果 URL 能保留多久、是否需要下載，以及刪除政策為何。

這些細節會直接決定 API 是否適合你的應用程式。消費型工具可能做出很有說服力的效果，卻完全沒有可供開發者依循的 API 合約。在一則真實使用者的 Reddit 討論中，發文者便排除了沒有 API 的推薦方案，並表示自己測試出的結果更像是混合身分，而不是明確替換成另一張臉。

值得考慮的三種 face swap API 路線

WaveSpeedAI：按輸出計費，最容易上手

WaveSpeedAI 的圖片 face-swap 文件採用 REST prediction 流程，輸入來源圖片與目標圖片後取得 prediction ID，再透過輪詢查詢狀態。公開圖片價格為每次 $0.01。它的影片 face-swap 文件則加入影片輸入與參考臉部圖片，並提供 target_index 和 target_gender 參數，用來選擇目標臉部。

影片價格為每計費秒 $0.01，最低計費 3 秒。因此，5 秒工作起始成本約為 $0.05，60 秒工作則約為 $0.60，尚未計入帳戶層級的調整。WaveSpeedAI 的pricing API可以在送出工作前，依輸入內容計算價格。

如果你要的是小巧、容易估算的整合流程，WaveSpeedAI 是合理選擇：送出媒體、保存 prediction ID、輪詢狀態，最後下載結果。不過，單位價格無法反映身分保留效果，仍要用實際姿勢與遮擋情境測試。

Segmind FaceSwap v4：控制選項多，但按 GPU 時間計費

Segmind FaceSwap v4接受 source_image 與 target_image，並透過 swap_type 支援臉部與頭部替換。API 同時提供同步與非同步路由、seed 參數、JPEG／PNG／WEBP 輸出格式，以及可選的 base64 回應。除了 HTTP API，文件也提供 Python SDK 的用法。

Segmind 列出的 Cost Efficient 費率約為每 GPU 秒 $0.0015，估算每次生成約 $0.15；Fast 則約為每 GPU 秒 $0.0072，估算每次生成約 $0.60。由於最終費用取決於實際執行時間，單純用固定的每張圖片價格來比較並不完整。Segmind 的計費文件指出，失敗請求不會收費；同步回應會提供 x-cost，非同步指標則會公開成本資訊。

如果臉部／頭部模式、可重現的 seed，或硬體選擇比固定的每張圖片預算更重要，Segmind 會更合適。

Replicate：用模型市集尋找合適方案

Replicate 的 face-swap collection彙整了不同作者提供的模型。它不是一個只有單一品質等級的 face-swap 端點。這次查閱的模型頁面中，有圖片模型估算每次約 $0.00022，也有約 $0.0064 與約 $0.012 的模型；另有一個影片模型標示每次約 $0.14。實際收費仍會隨執行時間與輸入內容變化。

Replicate 讓你不用自行配置 GPU，就能測試多個模型；但每個模型都要另外確認維護狀態、授權、輸入輸出格式、硬體、以及商業使用條件。如果團隊能固定模型版本並持續監控，Replicate 很適合拿來做原型；若更重視成本預估與支援的一致性，專用供應商會更簡單。

適合正式環境的請求流程

不論選哪家供應商，整合方式都應該採用工作佇列，而不是讓網站請求一直同步等待：

1. 將 API key 保存在伺服器或 serverless 後端。
2. 確認來源與目標媒體可被存取，且符合文件中的限制。
3. 送出單一工作後，立即保存 task 或 prediction ID。
4. 使用有上限的指數退避進行輪詢；若供應商提供正式 webhook，也可以改用 webhook。
5. 進入終止狀態後就停止，不要只因本地請求逾時便重新送出工作。
6. 在供應商的 URL 過期前，將結果下載到自己控制的儲存空間。
7. 記錄供應商、模型／版本、輸入中繼資料、成本、狀態與失敗原因。

以下是一個使用文件所述同步端點的 Segmind 風格 Python 最小範例。它示範請求格式，也避免把密鑰放進瀏覽器程式碼：

import os
import requests

url = "https://api.segmind.com/v1/faceswap-v4"
headers = {"x-api-key": os.environ["SEGMIND_API_KEY"]}
payload = {
    "source_image": "https://example.com/source-face.jpg",
    "target_image": "https://example.com/target-photo.jpg",
    "swap_type": "face",
    "output_format": "jpg",
}

response = requests.post(url, headers=headers, json=payload, timeout=90)
response.raise_for_status()
result = response.json()
print(result)

如果是長時間執行的影片工作或非同步模型，請把最後的 print 改成保存 ID 並輪詢狀態。不要在讀過供應商目前的回應結構前，就把某個結果欄位寫死；模型市集不同模型之間，常常會使用不同欄位。

文件沒法告訴你的事：品質、失敗與資料處理

公開 API 頁面通常很擅長說明欄位，卻很難回答實際輸入下的換臉效果是否始終可信。在選定供應商前，先建立一組小型驗收資料：

• 一張光線充足、正面朝向鏡頭的肖像。
• 一張四分之三側臉照片。
• 一張低光源影像。
• 一張臉部部分被眼鏡、頭髮或手遮住的照片。
• 一段包含頭部移動的短影片。
• 一張多人合照，前提是你的產品需要選擇特定臉部。

將身分保留、邊緣融合、表情、光線一致性與失敗行為分開評分。對於身分替換功能來說，混合兩個身分的結果即使畫面很銳利，也應該視為失敗。

以下這則真實使用者回報，說明了為什麼穩定性也必須納入驗收測試；不過，它並不是這三家供應商的效能基準：

「它只運作了幾秒，之後就停止了。」— r/FaceFusion 的 u/willows80

另外也要查看供應商針對資料保留、刪除、同意、禁止用途與商業權利所訂的政策。即使供應商把臉部圖片稱為一般媒體，它們仍然屬於與身分密切相關的敏感資料。你的應用程式應取得每張上傳臉孔的使用許可、保存稽核紀錄，並阻擋冒充、騷擾與詐欺用途。在送出請求前就加入審核流程，而不是等到產生結果後才處理。

FAQ：face swap API 整合問題

face swap API 支援影片嗎？

有些支援，但並非全部都支援：WaveSpeedAI 提供按秒計費的影片端點，Replicate 列出支援影片的模型，而這次查閱的 Segmind FaceSwap v4 合約則以圖片為主。

Replicate 會比專用 API 便宜嗎？

有可能，但 Replicate 沒有統一價格；應該用同一組測試資料比較完成的輸出，以及實際產生的費用。

API 請求應該直接從瀏覽器送出嗎？

不應該。請把密鑰保存在受保護的後端，由後端送出媒體與請求，再將你自己的工作 ID 回傳給用戶端。瀏覽器端的 key 很容易被複製，並被用來消耗你的帳戶。

應該如何測試 face swap 品質？

讓所有供應商使用相同的來源與目標資料集，並評估身分保留、融合效果、姿勢、光線、遮擋、延遲，以及工作進入終止失敗狀態時的處理。一定要納入困難輸入；只有一張正面肖像，不能算是正式環境測試。

流程中應該加入哪些同意確認？

要求上傳者確認每張臉孔都已取得使用許可，並確認預定用途；接著將這份同意紀錄與工作一併保存。在儲存或發布結果前，先依照供應商條款，以及當地與肖像權、隱私和 deepfake 相關的規範進行檢查。

實際該怎麼選

想要簡單明確的圖片與影片價格，選 WaveSpeedAI；需要臉部／頭部控制與硬體選擇，選 Segmind；想探索不同模型，則選 Replicate。正式上線前，先用同一組驗收資料測試兩個候選方案，再比較完成工作的成本、身分保留效果與失敗率。