如果你的 AI 工作流每一步都要查網頁，搜尋等待和重搜次數會一路累積。Perplexity 9 月 24 日公布 Fast Search，以 Photon 檢索服務提供較快的搜尋路徑，並表示 95% 的搜尋結果可在 230 毫秒內返回。
對正在接 API 的開發者，先測哪些任務可以穩定找到來源，比直接把所有查詢切到新模式更有用。Fast Search 的低價有明確計費單位，速度數字也只描述搜尋環節。 以下先分開 Search API 與 Agent API，再用一萬次請求的假設案例算重搜成本；本文未實際呼叫付費 API。
fast 與 web 怎麼選？先確認你接的是哪個 API
依Fast Search 文件，直接呼叫 POST /search 時，加入 "search_type": "fast" 即選擇新路徑；省略這個欄位則使用標準 web。它回傳的資料格式與標準搜尋相同，max_results 支援 1 到 20。官方將 fast 放在日常代理迴圈、大量檢索與低延遲需求，將少見、困難或語意模糊的問題留給 web 評估。
例如，你可以把查詢內容設成「某個套件的官方最新穩定版本」，先確認是否找到對的產品、官方頁面和日期。如果需求變成「同名的三套工具在不同授權條件下怎麼選」，需要的來源範圍就不同；這時不能只因第一筆結果回得快，就認定整個研究任務已經完成。
截至 9 月 28 日，官方價格頁列出的費率如下，金額均為美元：
| 使用路徑 | 標準 web | Fast Search |
|---|---|---|
| Search API，每千次成功請求 | 5 美元 | 1 美元 |
| Agent API 的 web_search，每千次工具呼叫 | 2.5 美元 | 1 美元 |
Search API 按成功的 POST /search 請求計費，一個請求最多可含五個查詢，仍算一個計費單位；成功但沒有結果也會計費，無效、限流或上游失敗的請求不收費。這個 API 沒有另外加上 token 費用。若你自己再把結果送進另一個模型，那個模型的費用仍要自行納入。
Agent API 則是在代理工作中呼叫 web_search，工具費與模型 token 費分開。Agent API 文件也提醒，工具的 search_type: "fast" 和 Agent API 的 fast preset 是兩個設定；沒指定搜尋類型時，可能承接 preset 的設定，不能直接套用 Search API 的預設規則。
如果使用 SDK，先檢查版本。Fast Search 文件針對 Python 0.43.4／0.43.5 的直接 Search API 範例使用 extra_body={"search_type": "fast"}，因為直接傳入該值會被套件驗證擋下；TypeScript 0.38.5 也有型別尚未跟上的說明。遇到本機參數錯誤，先核對套件與文件，避免誤以為搜尋服務本身不支援。
一萬次查詢能省多少？把重搜和來源品質一起算
假設你的系統一個月送出一萬次成功的 Search API 請求，且每次都只送一個查詢。全用 web，搜尋費是 50 美元；全用 fast，則是 10 美元。這只是依目前牌價計算的範例，尚未包含其他模型、頁面擷取或應用程式運行費。
再假設每次先用 fast，其中 20% 因找不到足夠來源而另送一次 web 請求，搜尋費就變成 10 美元加 10 美元，共 20 美元。它仍比全用 web 低，但已不是只看單價得到的 10 美元。重搜的等待時間也會增加，所以應一起記錄最後完成任務所花的時間。
我會先挑一小批真實問題，包含常見事實、少見產品、同名對象和繁中在地資訊。每題用相同的日期範圍、地區與來源限制，比較 fast 和 web；若兩邊送出的查詢本身不同，就很難知道差異究竟來自搜尋模式還是提問方式。
檢查結果時，除了第一筆來源是否相關，也要看它能否支持你要回答的那一句話。例如查「支援台灣的方案」，全球產品介紹頁未必包含台灣資格；找到品牌官網仍不等於找到答案。記下需要改問、補查或人工確認的原因，才能建立適合自己工作流的切換規則。
最後分開量搜尋等待、讀取網頁、模型整理，以及人工查證。官方的 230 毫秒數字不包含你整段流程的所有成本，也不是本站重現的台灣延遲成績。先把一個固定任務測完整，再決定哪些查詢採用 fast、哪些直接走 web，或在資料不足時停止回答。
還在設計 API 工作流，可接著看 AI API 串接入門；如果你只是想在網頁版查資料，則回到 Perplexity 使用指南，不需要為這次 API 更新重做一般使用流程。