SERP 返回 JSON 体积横评:喂 LLM 谁更省 token

做 AI grounding,把 SERP 结果喂给 LLM,token 成本是大头。同一批 query,各家返回的 JSON 体积差很多,直接影响 token 花销。

这篇对比几类常见 SERP API 服务的响应体积。以下用"常见 SERP API 服务"泛指。

为什么体积重要

• token 成本:JSON 越大,喂 LLM 的 token 越多
• 解析时间:大 JSON 解析慢
• 存储:存历史时占空间

响应体积对比

服务	单次体积	字段数	冗余度
服务 A	大	多	高
服务 B	中	中	中
serpbase	精简	核心字段	低

serpbase 的 organic 结果只带核心字段(rank/title/link/snippet),喂 LLM 省 token。

关键:喂 LLM 前必须裁剪

不管哪家,整包喂都是浪费。裁剪成三样:

def slim_results(organic, limit=5):
    return [
        {
            "title": i.get("title", ""),
            "snippet": (i.get("snippet") or "")[:80],
            "link": i.get("link", i.get("url", "")),
        }
        for i in organic[:limit]
    ]

裁剪前后对比

指标	原始	裁剪后
单次 token	几千	~600
月成本(1000 次)	高	降 90%
答案质量	-	几乎不掉

token 成本换算

按输入 $2.5/1M token:

• 原始 7k token/次:1000 次 ≈ $17.5
• 裁剪 600 token/次:1000 次 ≈ $1.5

裁剪后省 90% 左右。

serpbase 本身精简

serpbase 的 organic 字段不多,而且返回前就该裁剪。它响应体积本来小,裁剪后更省。

data = search("装修公司")
# organic 每条:rank, title, link, snippet
# 没有 sitelinks/icon 等冗余

怎么判断体积

import sys

def size_kb(data):
    return sys.getsizeof(str(data)) / 1024

用真实关键词测各家的单次体积,再决定裁剪策略。

注意

• 裁剪要够:只留 title/snippet/link,别留多余字段
• snippet 截 80 字符:够 LLM 用了
• 图片/新闻端点:2 积分,喂 LLM 前同样裁剪

选型建议

• AI grounding:优先体积小的服务
• 批量:裁剪后都差不多,原始小的更省
• 混合:响应体积 + 单价一起看

完整参数和响应字段参考:serpbase.dev/docs。JSON 体积,喂 LLM 前先裁剪,谁都能省 90%。