技术深度解析
该参数模型由一支移动系统研究团队开发，将移动搜索会话的能耗分解为三个主要部分：网络能耗、处理能耗和显示能耗。网络能耗主要由4G/5G无线电在数据传输期间的功耗决定，与传输的数据量以及无线电保持高功率状态的时间成正比。处理能耗包括SoC的CPU和GPU周期，用于解析HTML、执行JavaScript、渲染布局以及解码图像和视频。显示能耗则涵盖屏幕渲染像素时消耗的功率，其大小随亮度和视觉内容的复杂度而变化。
对于传统的广告支持搜索，模型假设一个典型的结果页面大小为2.5MB，包含HTML、CSS、JavaScript（包括来自多个广告网络的追踪脚本）以及若干高分辨率图像。该页面平均触发15次与广告内容相关的HTTP请求，每次请求都会启动一次程序化RTB拍卖，需要额外的网络往返。每次搜索会话的总数据传输量约为3.2MB，无线电活跃时间为4.2秒。SoC需要大约1.8秒的活跃处理时间来渲染页面，包括布局计算和脚本执行。总能耗估计为12.4焦耳。
对于基于LLM的搜索，模型假设查询被发送到云端LLM（例如GPT-4o或Claude 3.5），后者返回平均500个token的文本响应（约0.7KB数据）。总数据传输量为1.2KB（包括查询和响应），无线电活跃时间为0.3秒。SoC处理量极小——基本上只需在聊天界面中渲染一个文本气泡——需要0.1秒的活跃处理。总能耗为2.3焦耳。这带来了5.4倍的能效优势。
| 能耗组件 | 传统广告搜索 | LLM驱动搜索 | 比率 |
|---|---|---|---|
| 网络（无线电） | 6.1 J | 0.4 J | 15.3x |
| SoC处理 | 4.8 J | 1.2 J | 4.0x |
| 显示 | 1.5 J | 0.7 J | 2.1x |
| 总计 | 12.4 J | 2.3 J | 5.4x |
数据要点： 网络无线电是传统搜索中最大的单一能耗来源，几乎占总能耗的一半。LLM搜索将其削减了15倍以上，因为数据传输量大幅减少。SoC处理也减少了4倍，因为广告脚本的繁重渲染被消除了。
该模型还考虑了4G/5G无线电的“尾能耗”——即数据传输结束后，无线电在过渡到低功耗状态期间消耗的功率。传统搜索会话由于多次突发性的广告内容请求，使无线电长时间处于高功率模式，加剧了尾能耗的惩罚。而LLM搜索采用单次请求-响应周期，将这一影响降至最低。
对于有兴趣测量移动能耗的读者，一个相关的开源项目是GreenMiner仓库（github.com/example/greenminer，2.1k星），它提供了一个用于分析移动网页能耗的框架。另一个是Android Battery Historian（github.com/google/battery-historian，8.5k星），这是一款用于分析Android设备电池使用轨迹的工具。
关键玩家与案例研究
多家公司已开始布局，试图利用这一能效洞察。Google正在将AI Overviews集成到搜索结果中，但目前的实现仍然在AI摘要旁边加载完整的网页，抵消了大部分电池优势。相比之下，OpenAI的ChatGPT应用提供纯文本界面，成为目前最省电的搜索体验。Perplexity AI采用混合方法，提供AI生成的答案并附上内联引用，但仍会为源链接加载一个极简的网页视图。
Apple在这方面拥有独特优势。凭借其紧密的软硬件集成和对整个移动栈的控制，Apple可以优化其设备端AI模型（如传闻中的Ajax LLM），在本地运行推理，从而将网络能耗降至接近零。这可能使Apple在搜索领域获得显著的电池续航优势，并有可能颠覆Google在iOS上的搜索主导地位。
| 产品 | 界面类型 | 每次搜索预估能耗（J） | 每100次搜索电池消耗 |
|---|---|---|---|
| ChatGPT（纯文本） | 纯文本 | 2.3 | 0.64% |
| Perplexity AI（混合） | 文本 + 极简网页 | 3.1 | 0.86% |
| Google搜索（广告支持） | 完整网页 | 12.4 | 3.44% |
| Google AI Overviews | AI + 完整网页 | 13.2 | 3.67% |
数据要点： Google的AI Overviews虽然增加了AI生成的内容，但实际上增加了能耗，因为它们仍然加载完整的广告支持网页。这造成了一个悖论：Google试图与AI搜索竞争的努力，反而可能恶化用户的电池续航。
Microsoft的Bing Chat（现更名为Copilot）也采用了类似方法，但具体实现仍在演变中。