谷歌这轮 AI 豪赌很多人只看到了大模型和算力军备竞赛却忽略了一个关键问题当谷歌把资本开支疯狂押注在 AI 基础设施上时它最核心的现金牛业务——搜索引擎——正在被它亲手推动的 AI 体验一步步侵蚀。这篇文章不讨论股价涨跌也不做投资建议而是从技术架构、成本结构、产品形态和工程实施的维度拆解“At the altar of AI capex, Google is sacrificing the golden goose”这句话背后的逻辑以及对我们开发者、架构师和技术决策者意味着什么。1. 背景与核心概念一句话背后的技术博弈标题中的“AI capex”指的是 AI 相关的资本支出也就是谷歌在数据中心、TPU 芯片、网络带宽、能源合同等方面投入的巨额资金。“golden goose”金鹅则是一个经典比喻指的是一直下金蛋的鹅。在谷歌的语境里这只“金鹅”就是搜索广告业务——它每年为谷歌贡献数千亿美元收入是整个公司利润的基本盘。这句话真正想表达的是谷歌为了押注 AI 未来正在用搜索业务的短期利润去填一个深不见底的资本黑洞。而从技术视角看这场博弈远比表面复杂它至少包含三层冲突成本结构冲突传统搜索是“低边际成本 高广告毛利”而 AI 驱动的生成式搜索是“高算力成本 用户意图不确定性”。产品形态冲突AI Overviews 直接给答案用户不再点击蓝色链接这会逐步蚕食搜索广告位。战略时间冲突AI 基础设施是长期资产搜索收入是当期现金流两者之间存在巨大的时间错配。对技术人员来说真正值得关注的不是“谷歌会不会失败”而是当一个公司把自己最重要的现金牛业务作为实验场时技术决策会如何被资本周期影响我们自己在做 AI 功能落地时又会遇到哪些类似问题2. 资金到底烧在哪里AI 基础设施的物理现实2.1 数据中心算力的物理边界谷歌在 AI 时代的资本支出主要投向两大方向新建数据中心和升级现有数据中心。每个超大规模数据中心的建设成本通常以数十亿美元计其中包含土地、建筑、冷却系统、供配电、服务器机架、网络设备等。从技术角度看AI 数据中心和传统搜索数据中心的最大区别在于功耗密度传统 CPU 服务器单机柜功耗通常在 10kW 到 20kW 之间。搭载 H100/A100 级别 GPU 的机柜功耗可以轻松达到 40kW 甚至更高。液冷不再是可选项而是刚需。这意味着谷歌每建一个 AI 数据中心不仅要买 GPU还要改造电网接入、建设变电站、部署液冷循环系统。这些都是资本支出而且是沉没成本——一旦 AI 需求增长不及预期这些产能无法像软件一样快速缩容。2.2 自研芯片TPU 的规模效应与锁死效应谷歌很早就意识到 AI 算力不能完全依赖外部供应商因此投入大量资源自研 TPU。TPU 的优势在于推理场景下能效比高尤其适合 Transformer 架构的矩阵运算。但自研芯片是一把双刃剑优势单次推理成本可以比英伟达方案更低且在产能调度上有更高自主权。劣势软件生态、算子库、框架适配都需要自研团队持续维护。如果模型架构快速变化硬件迭代节奏未必跟得上。这种“规模效应 锁死效应”的组合是理解谷歌 AI capex 的关键。TPU 只有在超大规模部署下才能摊薄成本而超大规模部署又要求谷歌必须维持极高的 AI 利用率。否则闲置的 TPU 就是每天都在烧钱。2.3 训练与推理两种截然不同的成本模型工程上必须区分训练成本和推理成本。训练成本是一次性投入。训练一个大型语言模型需要数千甚至数万张加速卡连续运行数周到数月。改进算法、清洗数据、调整并行策略可以在不增加硬件的情况下降低训练成本。推理成本则是持续性的每处理一次用户请求都要重新跑一遍模型前向传播。Google 搜索引擎每天处理数十亿次查询如果每一次查询都变成一次 LLM 推理推理成本会呈指数级上升。这就是标题里“牺牲”的技术本质传统搜索的边际成本接近于零AI 搜索的边际成本却不再为零。当用户量越大亏损可能越严重这与互联网产品“边际成本递减”的基本假设产生了冲突。3. 搜索这个“金鹅”正在经历什么3.1 AI Overviews 与零点击搜索谷歌已经在搜索结果页顶部直接嵌入 AI 生成的摘要。用户不需要再向下滚动更不需要点击进入第三方网站。从用户体验角度这非常高效从广告商业模式角度这是一场地震。传统搜索的商业模式是用户输入关键词 - 展示自然结果广告位 - 用户点击 - 广告主付费。而 AI摘要的模式是用户输入问题 - AI直接给出答案 - 用户得到满足 - 无需点击。这种“零点击搜索”对广告收入的影响是直接的广告主只有在用户点击或浏览时才会付费如果用户根本不需要下滑页面广告展示价值就会降低。3.2 广告位与用户行为的迁移即使 AI 摘要没有完全取代广告它也在改变用户的注意力分配。以前用户可能通过多次搜索、浏览多页来筛选信息现在只需要一次问答。查询次数下降就意味着广告曝光次数下降。从工程角度这意味着搜索系统需要在“给出最佳答案”和“保持广告收入”之间做复杂的平衡。这不是一个简单的推荐系统问题而是一个涉及用户满意度、广告主回报率、长期留存率的动态博弈。谷歌如果完全偏向用户体验商业模型受损如果偏向广告用户会流向 ChatGPT 或 Perplexity。3.3 搜索质量的隐性风险大量使用 AI 生成摘要还会带来一个长期风险当用户不再点击原始网页内容的创作方就无法获得流量和收入小网站、独立博客、技术社区的内容生产动力会下降。当互联网上的人类原创内容减少AI 模型训练数据的“质量源头”也就萎缩了。这就像一个生态系统退化吃掉了小的生产者最终会饿死整个链条。这不是危言耸听而是已经在发生的内容生态迁移。谷歌在推动 AI 搜索的同时实际上也在消耗自己赖以生存的内容生态。4. 用代码与模型理解这场博弈光说概念不够我们用工程工具来量化一下这场“AI 重构搜索”的成本与收益博弈。下面给出几个实际可运行的示例。4.1 估算 AI 搜索的单次推理成本先来看一个最基础的 Python 示例估算 LLM 推理的单次成本。忽略掉复杂的并发和批处理因素只算毛利。# 文件路径estimate_cost.py # 用途估算单次 LLM 对话推理成本 def estimate_inference_cost( input_tokens: int, output_tokens: int, cost_per_1m_input: float 0.15, # 假设的输入 token 单价 cost_per_1m_output: float 0.60, # 假设的输出 token 单价 ): input_cost (input_tokens / 1_000_000) * cost_per_1m_input output_cost (output_tokens / 1_000_000) * cost_per_1m_output return input_cost output_cost # 模拟一次详细问答的 token 消耗 input_tokens 800 # 用户问题 检索结果拼接 output_tokens 500 # AI 生成的答案长度 cost estimate_inference_cost(input_tokens, output_tokens) print(f单次推理成本约为: ${cost:.6f}) print(f如果每天处理 10 亿次查询日成本约为: ${cost * 1_000_000_000:,.0f})运行结果会让人直观感受到“边际成本不再为零”的含义。当单次查询成本从接近于零的数据库检索变成几厘钱甚至几分钱的模型推理总成本会膨胀到非常夸张的量级。4.2 模拟零点击率对广告收入的影响接下来用一个简单的模型模拟“零点击搜索”对广告收入的影响。假设每个用户每天搜索多次其中一部分搜索进入 AI 摘要模式不再产生广告点击。# 文件路径simulate_zero_click.py # 用途模拟 AI 摘要对广告收入的侵蚀 def simulate_ad_revenue( daily_queries: int 10_000_000_000, avg_ads_per_page: float 3.0, click_rate: float 0.03, cost_per_click: float 1.0, ai_summary_ratio: float 0.0, ): daily_queries: 每日搜索量 avg_ads_per_page: 每页平均广告位数量 click_rate: 广告点击率 cost_per_click: 单次点击出价 ai_summary_ratio: 零点击搜索占比AI 直接给出答案 clickable_queries daily_queries * (1 - ai_summary_ratio) ads_clicked clickable_queries * avg_ads_per_page * click_rate revenue ads_clicked * cost_per_click return revenue base_revenue simulate_ad_revenue() print(fAI 摘要占比 0% 时日广告收入: ${base_revenue:,.0f}) for ratio in [0.1, 0.2, 0.3, 0.5]: rev simulate_ad_revenue(ai_summary_ratioratio) loss base_revenue - rev print(fAI 摘要占比 {ratio:.0%} 时日广告收入: ${rev:,.0f}日损失: ${loss:,.0f})这个模拟模型非常朴素但它清楚地展示了平台面临的两难AI 摘要越普及广告库存越缩减。这不是产品体验问题而是商业模式存亡问题。4.3 基础设施调度示例如何优化 AI 实例利用率面对高额的 AI 资本支出工程师能做的核心工作是提高资源利用率。下面是一个简单的 Kubernetes 资源配置示例展示如何为 AI 推理服务设置合理的弹性策略。# 文件路径ai-inference-deployment.yaml # 说明为 AI 推理服务配置弹性伸缩的示例需按实际环境调整 apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference spec: replicas: 2 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: containers: - name: inference image: your-registry/llm-server:latest resources: requests: nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1 --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: nvidia.com/gpu target: type: Utilization averageUtilization: 80这里的核心思路是在 GPU 资源池上设置弹性伸缩根据 GPU 利用率动态调整副本数。这样可以在低峰期释放资源在高峰期及时扩容避免为闲置算力付费。4.4 模型路由与缓存降低每请求成本的关键策略在实际工程中不必所有请求都调用最大的模型。可以设计一套路由逻辑# 文件路径model_router.py # 用途根据请求复杂度路由到不同大小的模型 def route_to_model(query: str) - str: 简单规则路由短查询走小模型复杂查询走大模型 if len(query) 20 and not query.startswith(how) and not query.startswith(why): return gemini-nano # 小模型低成本 elif len(query) 80: return gemini-pro # 中模型 else: return gemini-ultra # 大模型高成本 # 模拟线上请求 queries [ 天气, 如何用 Python 实现二分查找, 为什么大语言模型会出现幻觉以及如何从系统架构层面缓解幻觉问题, ] for q in queries: print(f查询: {q[:20]}... - 路由到 {route_to_model(q)})再加上缓存层高频的重复问题可以直接命中缓存完全不需要重新推理。这能显著降低平均推理成本也是目前不少 AI 应用降低成本的主流手段。# 文件路径cache_layer.py # 用途简单语义缓存示例键为归一化后的查询文本 import hashlib from functools import lru_cache def normalize_query(query: str) - str: # 实际工程中应做分词、去停用词、同义改写等这里只演示结构 return .join(query.strip().lower().split()) def cache_key(query: str) - str: return hashlib.md5(normalize_query(query).encode()).hexdigest() # 模拟缓存命中 cache {} def get_answer(query: str) - str: key cache_key(query) if key in cache: return f[缓存命中] {cache[key]} # 假设这里是调用 LLM 的代码 answer f模型生成结果: {query} cache[key] answer return answer print(get_answer(什么是 AI capital expenditure)) print(get_answer( 什么是 AI Capital Expenditure )) # 经过归一化处理后应该命中缓存5. 常见问题与工程师的排查思路将谷歌的 AI 资本开支困境映射到我们自己的工程实践中会发现很多团队在落地 AI 功能时会遇到类似的问题。下面梳理几个高频问题。问题现象常见原因解决思路AI 功能上线后服务成本飙升到不可承受没有对推理 token 做监控所有请求都走最大模型建立 token 级成本监控引入模型路由和缓存查询量暴增后GPU 资源不足延迟飙升弹性伸缩策略过于保守扩容速度跟不上流量配置 HPA 并预留 buffer 节点或使用 serverless 推理用户体验变好但广告收入明显下滑AI 摘要吃掉了点击流量广告库存缩减业务侧需要设计广告与 AI 摘要的混合展示位技术上需要精准测度用户意图一批 GPU 集群利用率长期很低资源预置过多业务需求预测不准引入利用率监控关闭闲置节点采用混合调度自研模型训练成本太高迭代周期过长数据清洗、并行策略、超参调优不到位先做小模型蒸馏与大模型微调避免频繁全量训练5.1 为什么“AI 功能越多利润反而越低”核心原因是推理成本与功能数量近似线性增长而广告收入与用户停留时长并不总是同步增长。如果产品经理只是不断增加 AI 功能点却没有同步设计商业化闭环成本和收入就会脱节。建议团队在开发新 AI 功能前先做一轮“成本影响评估”判断该功能的推理成本能否被用户留存或付费转化覆盖。5.2 如何判断一项 AI 投入是否值得可以用“增量收益/增量成本”来评估增量收益包括用户留存率提升、付费转化率提升、DAU 增长、任务完成时长降低等。增量成本包括GPU 资源、token 费用、人工标注、模型训练、运维复杂度。如果增量收益不能覆盖增量成本这个功能在商业上就是亏损的无论技术多酷炫。谷歌面临的困境恰恰是它的 AI 基础设施是长期投资而搜索广告的增量收益在短期内并不乐观。5.3 工程师如何应对“成本不可控”的恐慌成本不可控通常来自三个地方模型规模过大、调用频率过高、缓存命中率过低。建议建立以下监控指标每秒请求数QPS平均输入 token 数平均输出 token 数缓存命中率单日总推理成本这些指标应该像 CPU 使用率和内存使用率一样成为每个 AI 服务的标准观测项。6. 技术团队的应对策略与工程最佳实践谷歌的故事对技术团队最大的启示是AI 落地不是“追求最强模型”而是“在限制条件下做最优决策”。以下是工程实践中值得坚持的几条原则。6.1 成本可观测性是第一优先级如果团队无法回答“这个 AI 功能每天花多少钱”那么它就还没有达到生产可用状态。建议引入 token 粒度的成本追踪把每次请求的模型版本、输入长度、输出长度、缓存命中情况记录下来形成成本画像。# 文件路径cost_tracking.py import time import json class InferenceCostTracker: def __init__(self): self.records [] def record(self, model: str, input_tokens: int, output_tokens: int): record { timestamp: time.time(), model: model, input_tokens: input_tokens, output_tokens: output_tokens, input_cost: input_tokens * 0.15 / 1_000_000, output_cost: output_tokens * 0.60 / 1_000_000, } self.records.append(record) return record def daily_cost(self) - float: return sum(r[input_cost] r[output_cost] for r in self.records) # 使用示例 tracker InferenceCostTracker() tracker.record(gemini-pro, 1200, 600) tracker.record(gemini-nano, 200, 100) print(f当前累计成本: ${tracker.daily_cost():.6f})6.2 在可靠场景优先使用“确定性检索”而不是“生成式 AI”不是所有搜索需求都需要大模型。对于事实性查询、数据库查询、文档检索传统搜索引擎和向量检索已经能提供又快又便宜的答案。建议设计一个“意图分级器”只有需要推理、综合、解释的任务才路由到大语言模型。这正好也是谷歌搜索面临的问题如果所有查询都走 AI 生成成本不可控如果只对复杂查询走 AI则可以兼顾体验和成本。6.3 建立“模型路由 缓存 蒸馏”组合拳三个手段可以有效降低 AI 功能成本模型路由简单请求走小模型复杂请求走大模型。缓存高频请求直接命中语义缓存。模型蒸馏用小模型学习大模型的输出让日常推理尽量跑在小模型上。这三者组合通常可以将推理成本降低 50% 以上同时保证用户体验不会有显著劣化。6.4 基础设施弹性与集群调度AI 基础设施投入巨大如果不做弹性调度很容易形成空转资源。可以借鉴云原生思路通过 Kubernetes 调度、GPU 共享、潮汐混部、离线任务补峰等策略提高整个集群的利用率。当在线推理需求低时把 GPU 让给离线训练或数据预处理任务当高峰到来时再切回在线推理。6.5 组织协同让业务、算法、基础设施团队共用成本语言很多公司的“成本黑洞”不是技术造成的而是组织语言不一致导致的。业务团队只关心功能上线算法团队只关心效果指标基础设施团队只关心资源利用率大家没有统一的成本语言。建议建立“每千次调用成本”“每条有效回答成本”“单位转化成本”等共同指标让三个团队在同一个指标集上对话。6.6 安全边界与合规意识AI 功能一旦接入生产环境要注意数据合规和权限边界。推荐遵循最小权限原则审核日志必须保留涉及用户数据的请求必须脱敏。尤其当 AI 生成内容直接面向 C 端用户时要准备内容安全过滤和人工审核机制避免模型输出不可控内容。7. 什么样的 AI 基础设施投入才是健康的谷歌的例子让我们思考一个更深层的问题什么样的 AI 资本支出才是健康的从工程与商业结合的视角可以有以下几个参考维度资本支出必须对应可预期的需求增量而不是对未来的盲目押注。基础设施利用率应作为核心 KPI而不是“总算力规模”。新业务带来的毛利增量至少要覆盖为此投入的资本成本。AI 功能必须带来“不可逆的用户体验提升”而不是短暂的尝鲜。如果我们把自己的团队看成一个小型“谷歌”每一次 GPU 采购、每一次大模型接入、每一次 AI 功能上线都可以用这套框架自我检验。也许这才是技术人从这场资本盛宴中最该带走的东西。最后提醒一句无论做技术选型还是职业选择都要区分“资本支出推崇的宏大叙事”和“工程上可验证的边际收益”。真正值得长期投入的永远是那些能在成本、体验和商业回报之间找到可持续平衡的技术方案。如果你正在做 AI 功能落地或成本治理建议从本文的模型路由、缓存、成本追踪三个方向先开始动手它们带来的改善通常立竿见影。