Perplexity API Fast Search 对比默认 Web：该怎么选？

Perplexity API 该选 Fast Search 还是默认 Web？

边界清晰、可重复的任务选 Fast Search；漏掉一个来源就可能改变决策时，选默认 web。 Fast 胜在价格和延迟，默认 web 胜在检索质量和答案可用性。生产环境里的 Agent 应在两者之间智能路由，而不是把所有查询都塞进同一种模式。

Perplexity 的在线 Fast Search 指南建议日常 Agent 任务使用 fast，少见、困难或含义模糊的问题使用默认 web。本文的价格与厂商测量数据均于 2026 年 9 月 24 日对照 Perplexity 在线页面核验。

如果是独立开发者在做客服 Agent，常规文档与状态查询先走 fast，证据为空或质量偏弱时再升级到 web。一次默认 web 调用多出的 $0.004，在漏检会触发人工复核时微不足道；但对每天重复数千次的低风险查询而言，这笔溢价只会白白消耗预算。

如果是已获得融资、正在开发市场研究产品的创始人，涉及公司、政策和竞争格局的模糊问题应由默认 web 处理。已知来源核验、产品可用性检查和重复监控仍可交给 Fast。即使产品界面只有一个搜索框，背后的任务也分成两类检索需求。

如果是中型企业 CTO，采购、安全、监管和事故研究应继续使用默认 web，直到内部回放证明 Fast Search 仍能保留所需来源集合。请求便宜五倍，不代表总成本更低；如果分析师还要返工补齐证据，省下的钱很快就会被吃掉。

Perplexity Fast Search API：Photon 改变了什么

Fast Search 改变的是检索预算，不是端点或结果结构。 Perplexity 于 2026 年 9 月 24 日发布该模式，底层采用自研检索与排序引擎 Photon。在线 Fast Search 文档确认了调用方式：仍然使用同一个 POST /search 端点，返回同样按相关性排序的 results[] 数组，请求中只需增加 search_type: "fast"。

如果省略 search_type，Perplexity 会使用标准 web。这一点很重要：这里的“默认”并不是 Perplexity 消费者应用里的默认语言模型，而是 Search API 的标准检索模式。两种模式都会返回标题、URL、摘要，以及可选的发布日期和更新日期，供后续流程处理。

Photon 发布说明称，该引擎只读取查询所需的数据，让磁盘等待与其他工作并行，并采用批处理感知缓存；Perplexity 的官方架构图展示了请求如何经过 broker 和分片。这些工程设计解释了速度优势，但并未消除有意为之的排序取舍：Fast Search 消耗更少算力，同时牺牲一部分更广泛的检索质量。

Perplexity Photon 是底层引擎，不是第三种模式

Photon 是 Perplexity 搜索技术栈下的基础设施。API 仍然只有 fast、web 和单独的 people 搜索类型。开发者不能直接选择或部署 Photon，也不会因此拿到另一种响应对象。

当前 SDK 有一个现实限制。Perplexity 建议 Python 库 0.43.4 和 0.43.5 使用 extra_body={"search_type": "fast"}，因为直接校验会拒绝这个新值。TypeScript 示例在 SDK 0.38.5 中暂时用 "fast" as any 做类型断言，等待类型定义跟进。直接发送 HTTP 请求则不受这两项临时客户端限制。

Perplexity 搜索 API 成本：10,000 次请求 $10 对 $50

胜者：Fast Search。 Perplexity 在线价格表显示，原始 Fast Search 每 1,000 次成功请求收费 $1，默认 web 每 1,000 次收费 $5；Search API 不另收 token 费用。

统一口径后，账很简单：

• 10,000 次 Fast Search 调用： 10,000 × $0.001 = $10。
• 10,000 次默认 web 调用： 10,000 × $0.005 = $50。
• 差额： $40，也就是原始检索支出减少 80%。

这 $40 并不是 Agent 的全部成本。读取结果的模型、后续抓取、重试、校验和人工复核都发生在下游。只有当这批 10,000 次调用没有带来超过 $40 的额外工作量时，Fast 才是真正的赢家。

成功返回空结果也要付费

只要 POST /search 请求成功，即使 results[] 为空也会计费。按照当前计费规则，无效请求、触发限流的请求和上游失败不会收费。因此，空结果率不只是质量指标，也是预算指标。

批处理会改变账单，但不会改变质量判断

Perplexity 的多查询快速入门允许一个请求最多包含五个相关查询。成功的多查询请求只算一个计费单位，但每个查询仍计入速率限制。若每种模式分别将二十个查询合并为四个请求，总成本就是 $0.024；若把 40 个查询全部拆成单独请求，则是 $0.12。

不要用批处理比较单次调用延迟。包含五个查询的 payload 改变了单个请求的工作量，也掩盖了逐查询耗时。应先在每种模式下比较 20 次单查询调用，模式选择确定后再单独测试批处理。

Agent API 工具费率要单列预算

Agent API 工具价格表采用另一套标准价格：fast web_search 每 1,000 次调用 $1，标准 web 每 1,000 次调用 $2.50，另加所选模型的 token 费用。这不是原始 Search API 的 $1 和 $5 费率。虽然都用了“fast”这个词，Fast Search 也不等于 Agent API 中单独的 fast 预设。

之前的 Perplexity、Exa 与 Tavily 成本对比回答的是该买哪家服务。本文讨论的是更深一层的选择：已经把 Perplexity 接入技术栈后，该用哪种模式。

延迟对比：Fast 胜出，但要注意数据口径

胜者：Fast Search，依据是 Perplexity 自己的测量。 Perplexity 的官方延迟图显示，单次 Fast Search 调用的 p50 为 160 ms，p95 为 230 ms。但发布说明及在线 Fast Search 指南都没有给出可直接对照的默认 web p50 和 p95，因此不能诚实地报出两者的延迟倍数。

百分位比单个平均值更有意义。p50 是位于中间的请求；p95 表示 95% 的请求会在该阈值内完成。对于连续执行多次搜索的 Agent，长尾延迟往往比中位数更明显，因为只要一个工具调用拖延，整条计划就可能卡住。

因此，对延迟敏感的任务应优先交给 Fast，但生产环境的答案仍取决于具体工作负载。网络距离、过滤条件、请求结果数量、提取上下文、批处理和重试策略，都会影响 Agent 最终感受到的端到端耗时。厂商数据只能作为基线，不是对所有集成场景的服务等级承诺。

Mikhail Basyuk 从实践者角度给出的标准很准确：只有在任务所需相关性没有受损时，低于 250 ms 的 p95 才有价值。速度和证据应该出现在同一个仪表盘上。

覆盖能力对比：默认 Web 胜出

面对困难或模糊的研究问题，胜者是默认 web。 Perplexity 的内部检索图表显示，Fast Search 的相关性得分为 2.21，默认模式为 2.45，相差 0.24 分；答案可用性分别为 0.567 和 0.596，相差 2.9 个百分点。

相关性衡量排序后的材料是否切中查询，答案可用性则看检索结果是否提供了足以支撑答案的材料。Fast 返回得很快，却可能给下游模型留下更薄的证据集。因此，宽泛的政策问题、多公司对比或存在争议的主张，即使 fast 路径响应很快，也应该交给默认 web。

Perplexity 在另一张厂商汇总图中给出了看似相反的结果：在六项公开 Agent 基准和 3,554 个选定任务上，Fast 以估算的模型加搜索总成本 $59.73 得到 64.3%，默认模式则以 $187.60 得到 64.0%。厂商称，fast 配置便宜约 68%，整体任务质量相当。

两组结果并不冲突。整体 Agent 可以依靠模型知识、推理、重复调用来弥补检索不足，也可能只是因为选定任务并不会惩罚每一次来源缺失。面向合规或商业研究的原始检索系统，不能假设下游模型一定能补回缺失的文档。

更完整的 AI 搜索 API 指南对不同厂商采用同一条运营原则：购买能产出证据包、并通过下一道确定性检查的最低价检索档位。

Perplexity API 如何启用 Fast Search

把同一个请求发送两次，只改 search_type。 query、max_results、search_context_size、过滤器、区域和客户端位置都保持不变。在线 Search API 参考文档说明，web 是默认值，max_results 默认是 10，提取上下文大小默认是 high。比较时应显式设置后两项控制变量，避免未来 API 默认值变化影响回放结果。

下面这组请求可以直接运行：

set -euo pipefail
: "${PERPLEXITY_API_KEY:?Set PERPLEXITY_API_KEY first}"

QUERY='Which CRM has the stronger current EU data residency and audit-control evidence?'
COMMON=$(jq -nc --arg query "$QUERY" '{
  query: $query,
  max_results: 10,
  search_context_size: "high"
}')

for MODE in fast web; do
  jq --arg mode "$MODE" '. + {search_type: $mode}' <<<"$COMMON" |
    curl -sS 'https://api.perplexity.ai/search' \
      -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
      -H 'Content-Type: application/json' \
      -o "$MODE.json" \
      -w "$MODE\tHTTP %{http_code}\t%{time_total}s\n" \
      --data-binary @-
done

本次发布流程没有可用的 Perplexity API 凭据，因此本文不声称测得任何延迟、覆盖率、空结果率或答案支撑结果。下面的方案只是一个小型配对检查，不是对 Perplexity 六项基准研究的复现。

测试集使用 20 个商业研究问题：10 个有明确权威目标的具体查询，以及 10 个需要多个来源的模糊问题。一组实用的固定问题可以覆盖当前 SaaS 价格、云服务限制、监管日期、支持国家、安全控制、近期文件、厂商对比、政策影响、总成本问题，以及正反双方都有可信证据的主张。

按单查询执行，这些 40 次成功的原始请求成本为 $0.12，尚不包括下游模型调用：20 次 fast 调用花费 $0.02，20 次默认 web 调用花费 $0.10。

真正需要比较的不是平均结果数。一堆质量偏弱的链接，可能还不如一小组一手来源。只有衡量有用覆盖和答案支撑，价格与延迟才有决策意义。

切换模式的真实成本

改请求体很简单，难的是改运营策略。 工作负载从默认 web 切到 fast，不需要迁移数据，也不用换端点，但检索行为、缓存标识、监控方式和故障处理都会随之改变。

缓存键必须包含 search_type。不能让缓存里的 fast 响应悄悄满足后续默认 web 请求，因为后者的调用方已经为更广的检索范围付费。上下文大小、结果数、过滤器、国家和语言也应纳入缓存键，道理相同。

每次请求及每条下游主张都要记录模式。否则，来源接受率下降时，看上去会像模型漂移或随机搜索噪声。路由器还要输出明确的升级原因，例如 empty_results、missing_primary_source、ambiguous_query 或 high_impact。

重试策略也要区分模式。在同一模式下重试超时请求属于可用性处理；从 fast 重试到 web 则是质量升级，同时会改变价格。这两种事件不应共用一个计数器。

哪些团队不该切换

以下情况不应把 Fast Search 设为全局默认：

• Agent 处理合同、监管、安全、金融、医疗信息或事故响应，漏掉来源会造成严重后果。
• 当前工作负载以模糊问题为主，需要的是来源多样性，而不是查询某个已知事实。
• 团队还没有证据验收标准，导致“更快”成为唯一可见的成功指标。
• 服务适配器或 SDK 拒绝新枚举值，团队又无法安全采用文档给出的变通方案或直接 HTTP 请求。
• 系统没有把成功但为空的响应与传输故障分开记录。
• 与每个答案本就需要的人工复核相比，默认 web 的溢价无关紧要。

更合适的迁移方式是按路由逐步上线：先把一类可重复任务移到 fast，保留 web 作为升级路径，比较被接受的证据后再扩大范围。

周一就做这件事

不要急着改全局默认值，先上线一条简单的搜索策略。 可重复、影响较低的查询路由到 fast；模糊或影响较高的问题路由到 web。然后把证据未通过变成自动升级条件，不要让系统悄悄交付一个证据薄弱的答案。

从上周的真实请求开始，不要使用人为设计的演示案例。选出 20 个能代表产品日常工作的请求，分为具体查询和模糊问题两组，再用上面的请求对逐一回放。如果 40 次单查询请求全部成功，测试的原始搜索费用是 $0.12。

周二复盘四项结果：请求延迟 p95、成功但为空的响应、有用来源覆盖和答案支撑得分。如果 fast 在具体查询组中守住证据门槛，就只迁移这一类任务；如果它在模糊问题组漏掉一手来源，无论汇总基准成绩如何，都继续保留默认 web。

这正是 Photon 带来的业务意义：它不是一个更便宜的全局开关，而是一套实用的搜索风险路由器。查询容错率高时，Agent 每 1,000 次调用花 $1；只有当更广的检索能避免代价更高的漏检时，才额外支付 $4。

常见问题

想把路由、验证和成本问题放进同一张工作表？下载 AI 商业工作流审计清单，周一就画出第一版搜索风险路由。