Sonar API 官方价：每百万 token 输入输出各 1 美元，另按每千次请求加收 5-12 美元

Perplexity 的 Sonar 系列 API 有一张公开牌价：基础 Sonar 模型按 token 计费，每百万 token 输入与输出各 1 美元；在此之上还要按请求计费，每千次请求加收 5-12 美元，具体落点随模型档位浮动。数字出自 Perplexity 官方定价文档。对监测自建者，这张价目单的意义超出一家厂商——它把「调一次带搜索增强的回答到底多少钱」拆成了两段明码，是整个自建成本测算里最常被引用的基准价。

两段式计价怎么读

Sonar 的账单由两部分相加。第一段是 token 费：你的提问与答案文本按每百万 token 的单价结算，基础 Sonar 的输入输出同价。第二段是请求费：每次成功调用按次收费，与答案长短无关——这一段常被忽略，但在监测场景里它往往才是大头，因为监测的特点是问题短、调用频繁，文本量小而次数多。

读这张价目单还要注意档位浮动。5-12 美元的千次请求区间对应的是 Sonar 家族的不同档位：基础档落区间下沿，更强的推理与搜索档位往上走。给自建项目做预算时，先确定你要的答案质量对应哪一档，再取那一档的单价算账——拿基础档的单价去预算高级档的用量，是最常见的成本估算翻车方式。

两段式计价对监测场景还有一个提示：控制成本的重点在请求费而非文本量。监测的提问天然短促，答案文本的 token 费用占比有限；真正随规模线性上涨的是调用次数本身。想压预算，先压采样频率与引擎数量，再考虑换更便宜的档位——顺序反过来，效果通常很差。

这张价目单的用途：自建成本测算的基准

自建 AI 可见度监测的成本模型，第一步就是拿公开牌价搭骨架：提问集条数、引擎数量、采样频率、每轮采样次数，四个变量相乘就是月调用量，再乘单价就是月成本。本站按这套口径做过一个完整的推算示例，含区间解释与分层降本方案，见自建监测示例成本数据卡。工程路线的选择——开源面板、无服务器脚本还是完整管线——见Aperture 开源监测工具卡与llm-visibility-tracker 工具卡。

牌价之外的隐性成本也要进表：瞬态失败的重试消耗、失败队列的补跑、以及调用量上来之后必然要做的分层采样改造。这些不改变单价，改变的是乘数——重试率与采样策略才是自建成本真正的调节阀。

拿这张价目单做测算时还有一条经验：先用小规模试跑校准乘数。提问集条数、重试率、单次回答的实际 token 消耗，三项都与纸面估算有出入，跑一轮小样本把实际值回填进模型，预算区间会立刻收紧——这比事后调账便宜得多。

API 牌价买不到的东西：口径等价性

这张价目单还有一个容易被跳过的边界：它计价的对象是 API 回答，而 API 回答与网页端用户看到的回答并不等价。模型版本、区域路由、账号状态都可能造成两边答案与引用的差异——你按 API 牌价采到的数据，测的是「API 入口的 Perplexity」，不自动等于「网页端用户的 Perplexity」。

等价性还会随时间漂移：厂商调整检索上游、换模型版本、改界面引用形态，都会让同一个 API 口径测出的曲线出现台阶。所以自建者的账本要有两页——一页记钱，一页记口径变更；只记钱不记口径的成本表，半年之后就失去解释力。两个入口的取舍原理见API 监测与 UI 监测对比卡，引擎的取用机制背景见Perplexity 引擎档案。

因此在预算表之外还要有一张口径表：记录用的哪个档位、哪个区域、什么采样节奏，模型版本变更时重跑基线。同样的钱，花在口径稳定上比花在调用量上更值——基线断一次，前面省的钱都补不回来。若你在权衡整条管线是自建还是外采，完整的决策框架见自建还是供应商决策卡。无论选哪条路，这张公开牌价都值得留在你的测算表里——它是这个市场上少有的、把「一次带检索增强的回答」拆出明码的参照系，任何监测报价单都可以拿它对表。