Perplexity 是我近两年一直在跟的 AI 搜索产品所以看到“Perplexity CEOPerplexity 搜索在任意算力水平下均为最佳”这个说法时我的第一反应不是去争“有没有吹牛”而是拆一下这句话背后的技术策略。在任意算力水平下都是最佳这句话如果按字面理解肯定站不住脚算力差 10 倍模型容量和响应速度不可能一样。但如果你把它理解成“在同样算力条件下用更聪明的检索和更高效的推理拿到更好结果”那这就是一条很明确的搜索产品路线。这篇文章我打算按实际落地的顺序拆先解释这句话到底在争什么再讲 AI 搜索和算力、token、模型、数据、场景之间的关系然后给出低算力、中等算力、高算力三种环境下怎么验证“是否最佳”最后把判断标准和排查思路列清楚。适合正在选型 AI 搜索方案、做检索增强产品、或者单纯想搞懂算力预算该怎么花的人。1. 先理清这句话的分量它不是性能参数是产品策略1.1 CEO 的说法本质是在争夺“效率优先”心智Perplexity 的产品逻辑不是用一个超大模型回答所有问题而是先检索实时网页把相关内容拉回来再交给大模型做归纳和引用。这个流程对算力的消耗远低于从零训练一个巨型模型也低于把几十亿参数模型直接用于开放问答。所以“在任意算力水平下均为最佳”这句话实际上是在传递三个意思我们的搜索效果不依赖“你分给我多少 GPU”。我们更擅长用较少的推理资源拿到高质量答案。在算力受限时我们的系统架构会比直接堆模型参数的方式更稳。这三点能不能成立取决于实现层有没有做好检索质量、上下文压缩、缓存复用和模型调度。它不是一句能靠发布会定论的承诺。1.2 为什么搜索比聊天更吃“效率工程”聊天类 AI 的场景相对简单用户输入一句话模型基于已有知识生成回复。搜索类 AI 多了一个链路先搜再读再整合再引用。多出来的这几个环节每一步都在消耗时间、token 和算力。如果你用过一个搜索结果总在变、引用的网页打不开、同一个问题回答前后不一致的 AI 搜索工具你会理解我说的“效率工程”有多重要。搜索类产品的关键指标不只是“答得对不对”还包括“答得快不快”“引用是否可追溯”“同样的算力能支撑多少并发”。所以 CEO 选择在算力这个问题上做文章本质上是在告诉大家Perplexity 的价值不在模型参数比别人大而在同样一块显卡、同样一次 API 调用、同样一批 token 预算下我能把结果做得好。1.3 这句话适合谁去参考如果你是普通用户可以把它当作选型参考不用太较真。如果你是开发者或技术负责人需要评估团队是否自建 AI 搜索或者是否要接入 Perplexity 这类服务那这句话值得当作线索去验证。验证方法也很直接把你的搜索词样本、上下文长度、并发规模放到不同算力环境下测试比较延迟、引用质量、失败率。这个流程我后面会详细拆。2. 拆开核心概念算力、token、模型、数据、场景分别影响什么2.1 “算力是什么”先讲清楚算力通俗讲就是单位时间内能完成多少次计算。硬件上的体现是 GPU、CPU、NPU 的浮点运算次数或整数运算次数常见指标有 TOPS、TFLOPS、FLOPS。软件上的体现是跑一个模型或一批任务需要多长时间。但 AI 搜索对算力的消耗不是均匀的。检索阶段可能是 CPU 和内存为主读取索引、排序、过滤生成阶段才是 GPU 为主加载模型、跑推理、生成 token。很多团队只盯着 GPU忽略检索和日志模块的 CPU 与内存开销最后整体延迟仍然很高。在算力规划时至少要分三块看训练或微调算力。推理算力。检索、索引、缓存、向量数据库等周边系统算力。“任意算力水平下均为最佳”这种话在现实中应该被理解为在给定预算下把这三种算力怎么组合最合理。2.2 token 是搜索的成本和速度单位token 是模型处理文本的最小单位中文大约一个汉字算一个到两个 token。AI 搜索的成本和延迟核心就是看一次请求产生多少输入 token 和输出 token。一次 AI 搜索请求包括用户查询。搜索结果片段。被压缩后的网页正文。系统提示词。模型生成的最终答案。如果你的系统不筛选网页直接把所有抓取内容全部塞进上下文那一次请求的输入 token 会非常大。算力消耗上升、响应延迟拉长、成本翻倍效果还不一定更好。好的 AI 搜索系统会做“上下文压缩”先粗筛出相关段落再按相关度排序只把精华部分传给模型。这比换一块更大的 GPU 更实在。2.3 模型、数据、场景三者的关系模型决定基础理解能力数据决定检索质量场景决定参数怎么调。模型层面大参数模型不一定适合搜索。搜索场景更看重指令跟随、信源判断和摘要能力。有些小参数模型配合良好的检索库在特定领域内效果不输大模型。数据层面如果索引库质量差排在前面的结果全是低质页面再强的模型也归纳不出正确答案。早期我在做垂直搜索时一直以为效果差是模型不够好后来发现是数据清洗没做好索引库里重复内容太多。场景层面同一个搜索系统接入客服问答、科研检索、代码搜索或新闻摘要需要的算力和参数完全不同。客服问答可以限制上下文长度科研检索需要更长的引用段落代码搜索需要额外的语法解析这些都是场景带来的额外算力成本。3. 在三种算力预算下分别怎么验证“是否最佳”3.1 低算力环境先跑通再看上限低算力环境指个人电脑、低配云主机或只有 CPU 的环境。这里不适合跑大模型但很适合验证检索链路。建议按这个顺序做先用现成的模型 API 测试搜索效果不自己部署模型。把搜索词范围收窄到 50 条以内。只保留前 10 个搜索结果片段控制上下文长度。记录每次请求的响应时间、输入输出 token 数、引用链接是否有效。在低算力环境下判断“是不是最佳”看三个点能否在 5 到 10 秒内返回答案、答案是否有引用支撑、同一问题多次查询结果是否稳定。如果你只依赖 API没有本地模型那“算力”主要影响并发能力和成本。单条查询能跑通不代表 100 个并发也能跑通。低算力环境下更多是验证产品逻辑而不是性能瓶颈。注意低算力环境跑通了只能说明方案可行不能说明方案可上线。上限评估要放到更高配置或云服务上做。3.2 中等算力环境搜索质量比推理速度更值得调中等算力环境可以理解为有一张消费级显卡或一块入门级专业卡显存 8GB 到 24GB。这个阶段可以本地部署一个 7B 到 14B 参数模型用来做归纳和摘要。这个预算下最值得做的是把检索系统做好。我的经验是二八法则在这里非常明显检索质量提升 20%最终答案质量可能提升 80%。具体操作建议建立向量索引把文档切成段落用嵌入模型转成向量存入向量数据库。混合检索同时做关键词匹配和向量相似度匹配再把结果合并去重。相关性重排用一个轻量重排模型对候选结果打分只把前 5 到 10 条传给大模型。控制上下文按字符数或 token 数设置上限超出的部分分段处理。在中等算力下如果出现答案太慢的问题先不要急着换显卡。先检查是不是传给模型的文本太多或者检索阶段没有设超时时间。这两个问题比模型算力更常见。3.3 高算力环境并发、延迟、成本同时压测高算力环境包括多卡服务器、企业级推理集群或云上的大规模算力池。到了这一步单条查询的性能已经不是最大的问题真正的挑战是并发和成本。你需要关注的参数并发数同时有多少个请求在跑。QPS每秒能处理多少个查询。P95 延迟95% 的请求在多少毫秒内完成。token 吞吐每秒生成多少个输出 token。失败率超时、报错、空回复的比例。成本/千次查询每个查询的 API 费用或资源折旧。高算力环境下的优化重点不是“能不能跑”而是“每单位算力产出多少有效答案”。同样 100 万 token 预算有的系统能回答 8000 个问题有的只能回答 3000 个差距就在上下文压缩、缓存和数据质量。如果你的团队自建搜索服务我建议设立每周固定观察项延迟曲线、缓存命中率、检索召回率、用户反馈中“答案与问题无关”的占比。这四个指标比单独看 GPU 利用率更能反映搜索系统的健康程度。4. 判断搜索质量的核心参数和验证标准4.1 延迟、质量、成本、稳定性四件事要分开看绝大多数 AI 搜索争议都是因为把四件事混在一起谈。延迟从用户提交问题到返回答案的总耗时。包括网络传输、检索、模型推理、输出生成。用户对这个指标最敏感超过 10 秒基本算失败。质量答案是否准确、完整、有引用、可验证。质量受模型能力和检索质量共同影响不能只归因于模型。成本一次查询消耗的 token、GPU 时长、API 费用。成本过高时小团队需要限制上下文长度或改用更小的模型。稳定性同一个问题在多轮测试中是否给出稳定结果并发高时是否会超时或报错检索结果是否有波动。在对比两类方案时不要只比“哪家答得更准”。要把同样 1000 条测试问题的延迟分布、引用正确率、失败率一起列出来。4.2 一个可复用的测试集构建方法判断“任意算力下最佳”这种说法最好的方法就是自己做一个固定测试集。测试集可以包含事实类问题比如“某产品发布的具体日期”。比较类问题比如“A 和 B 两个方案的区别”。时效类问题比如“最近一周发生的事件”。长尾类问题你的目标用户的真实搜索词。模糊类问题用户表达不清但意图明确的问题。每类准备 20 到 50 条总共 100 到 200 条。同一套测试集在不同算力环境和不同搜索产品上各跑一遍。记录结果时给每条回答打三个标签答案可用性是否解决了用户问题、引用质量引用是否真实且相关、稳定性再次查询结果是否一致。这套方法不需要复杂框架一个表格就能落地。但它能很大程度上过滤掉营销话术。4.3 遇到“答案不好”时的排查顺序如果测试结果不理想按下面的顺序排查先看检索环节搜索结果里是否包含正确来源如果检索结果本身就没有正确答案模型再大也白搭。再看上下文被压缩后的文本是否保留了关键信息上下文太长会稀释模型注意力太短会丢失事实。然后看模型换成同类但参数更小的模型答案是否反而更稳定有时候小模型在指令理解上更简单直接。最后看提示词系统提示词有没有要求模型“只依据给定内容回答”搜索场景必须加上这条否则模型会脑补。很多搜索效果差的问题都不是模型不够强而是检索返回了错误内容或者没有限制模型只能基于检索结果作答。注意不要在排查一开始就换大模型。先用小样本对比不同检索策略很多时候问题出在数据侧。5. 从开发实践看AI 搜索的落地路径5.1 想自建 AI 搜索技术栈怎么选自建 AI 搜索的基本组件有四块数据摄取支持网页抓取、文档上传、数据库同步。索引构建把数据切成段落生成向量写入向量库。检索服务提供关键词检索、向量检索、混合检索接口。答案生成调用大模型把检索结果重排后生成最终答案。选型时最值得纠结的不是模型品牌而是向量数据库和检索框架。向量库决定召回效率和扩展性检索框架决定你能多快完成相关度调优。常用的开源组件包括 Elasticsearch、Milvus、Qdrant、Weaviate 等不同项目需求差异很大不盲目推荐某一个。如果你只需要验证搜索效果直接用云厂商提供的向量数据库更快。5.2 调用 API 和本地部署怎么选这里有一条分界线如果你只是做产品验证或中小规模业务先接现成的 AI 搜索 API别上来就自建。选择条件建议数据量小于十万条文档优先用 API。业务需要完全私有化或数据不能出内网再考虑本地部署。本地部署时如果只有 CPU优先考虑量化模型加轻量检索。如果团队没有专门的算法工程师本地部署要慎重模型调优和故障排查成本很高。很多团队觉得本地部署省钱但把 GPU 采购、运维、模型调优、并发扩容都算进去往往不如 API 划算。先 API 验证再逐步把稳定的业务拆出来自建是比较稳妥的路径。5.3 处理长文档和批量任务时要特别注意AI 搜索的长文档处理是常见的算力黑洞。一个几十页的 PDF如果全部塞进上下文token 消耗会很大。最佳实践是先做文档解析拆成章节和段落只检索与问题相关的段落。批量任务的核心是任务队列。不要让批量请求一次性全部发出去先控制并发数。建议从 1 个并发开始跑确认没有报错再逐步调高到 5、10、20。当连续出现超时或失败时把并发调回低位看日志定位原因。批量任务的命名和输出目录也要提前约定。文件名建议包含任务 ID 或时间戳方便排查是哪一批任务出错。输出格式统一为 JSON 或 CSV并保留原始输入 ID便于后续做质量分析。6. 资源规划、成本控制与日常排查清单6.1 算力规划从最小可用开始而不是从理想配置开始网上经常能看到“显卡 TOPS 算力表”“租算力平台对比”“算力中心机柜面试问题”这类内容。它们背后其实都指向同一个问题到底该买多少算力。我的建议是不要让配置推导需求而要让需求推导配置。先明确三个数日均查询量。单条查询的平均 token 消耗。目标响应时间。这三个数确定后再反推需要多大吞吐、多少显存、多少并发。以消费级显卡跑 7B 模型为例单卡可以支撑几个到十几个并发但响应时长可能在 2 到 5 秒之间。如果目标并发是 100就需要多卡或上云。不要一上来就买最高配。先用小样本测试记录实际 token 数和耗时再用公式估算。6.2 成本控制四个容易被忽略的支出点检索请求费用如果调外部搜索或网页抓取接口每次检索都会产生费用。嵌入模型费用构建索引时要对全部文档做向量化文档量大时这笔费用不低。索引更新费用文档频繁更新时反复向量化的成本会累积。缓存存储为了降低重复请求成本你需要缓存常见问题和答案缓存存储本身也要钱。预算里至少预留 10% 到 20% 给测试和调参不要把所有预算都花在正式流量上。6.3 日常排查清单我整理了一份排查顺序遇到搜索类问题时按这个顺序走效率最高看日志服务有没有报错报错发生在检索阶段还是生成阶段看输入用户的问题是否被正确解析特殊字符、超长文本有没有限制看检索结果返回的网页或文档片段相关度如何是否包含正确答案看上下文传给模型的片段长度是否合理有没有截断关键信息看模型输出是否遵循了“只依据引用内容作答”的指令看资源占用CPU、内存、GPU 利用率是否异常有没有内存泄漏看并发状态会不会是并发数超过上限导致超时这套链路适用于从个人 Demo 到生产环境的绝大多数 AI 搜索问题。不要一看到效果差就怪模型百分之六七十的情况下问题出在前面几环。7. 关于“任意算力下均为最佳”的最终判断7.1 这句话在什么情况下是成立的如果你的评估标准是“同样的算力条件下谁能用更少资源拿到更好的搜索答案”那这句话在某些应用场景下是可能成立的。尤其是短查询、低延迟、强制引用、快速摘要这类场景良好的检索和上下文管理比单纯堆模型参数更有效。在这类场景里Perplexity 代表的搜索路线确实是一个对算力更友好的方向。7.2 它不可能覆盖所有边界“任意算力水平”是理想化表达。极端低算力下比如只有 CPU 且内存不足 8GB任何现代大模型搜索都难言最佳极端高算力下如果允许无限推理和超长上下文更大的模型也有翻身的机会。好的工程判断不是全盘接受或全盘否定而是找到自己的场景属于哪一种。你的数据、查询类型、并发规模、成本预算决定了哪家方案最适合你。7.3 最后一点经验选 AI 搜索方案不要被“最佳”“第一”“最强”这类词带着走。真正值得参考的是这个方案在不同算力下的表现曲线它的延迟、成本、引用质量、稳定性是不是都在你能接受的范围内。我自己每次评估新方案时都会先拿 50 条典型问题跑一遍记录结果再决定要不要深入。这些判断标准比 CEO 在发言里的一个论点更可靠。如果你这几天也在折腾 AI 搜索建议先把算力拆成检索、推理、周边系统三块把测试集固定下来再拿十几个问题做对比。做完这些你自然就知道“最佳”这个说法的实际分量了。