这次我们看一个不那么“手把手”但更值得技术人员关注的话题Google 在 AI 资本支出上疯狂加码会不会正在牺牲自家的“金鹅”。标题里的 golden goose 指的不是某个产品而是 Google 搜索和广告这条贡献了绝大部分利润的现金牛业务。AI capex 则是围绕大模型建设的数据中心、芯片、能源和网络基础设施投入。这篇文章不做财报分析而是从算力基建、模型部署、推理成本和工程实践四个角度拆解一件事当一家公司把预算和工程资源同时压向 AI核心业务会经历什么技术团队又能从中学到什么。文章会覆盖三块内容第一Google 为什么要重仓 AI钱花在哪些地方第二这笔资本支出与搜索/广告业务之间为什么存在冲突影响是怎么传导的第三从 AI 工程实践、模型部署、推理成本优化角度给正在做类似决策的技术团队一组可落地的评估方法和工具。无论你是在做 AI 应用开发、AI 模型部署还是负责公司内部的 AI 基建预算这篇文章都值得往下看。1. 核心信息速览先把这次讨论的关键信息列出来方便快速定位。项目说明主题Google AI 资本支出AI capex与核心搜索/广告业务的资源权衡核心矛盾巨额 AI 基础设施投入是否正在侵蚀搜索/广告这条“金鹅”业务的短期回报基础设施方向数据中心、自研芯片TPU 系列、GPU 采购、电力与散热、网络带宽技术影响面大模型训练成本、推理成本、搜索产品改版、工程资源分配相关 AI 方向AI 大模型、AI 模型部署、AI 工程实践、AI 应用开发、AI 辅助编程工程关注点推理成本基线、容量规划、量化/蒸馏/缓存、TPU vs GPU 选型对技术团队的意义建立“算力投入产出”评估体系避免盲目堆参数和盲目上规模不确定项具体资本支出数字、芯片型号、各业务线成本拆分需以 Google 官方财报和公开报道为准需要注意本文涉及的具体资本支出金额、芯片参数和业务数据均会采用保守表述。技术团队可以参考这里的评估框架但实际数字必须以本公司的预算模型和测试环境为准。2. 为什么 Google 必须重仓 AI搜索护城河正在被生成式体验重塑先说结论Google 不是“想不想”投 AI而是“不得不”投。搜索是 Google 最成熟、利润率最高的业务但过去两年出现了两个结构性变化。第一用户习惯开始从“关键词匹配”转向“对话式获取答案”。第二生成式 AI 把传统搜索结果的“十条蓝色链接”变成了“一段完整回答 来源引用”这在信息获取效率上是另一种体验。对 Google 来说如果搜索产品不主动拥抱生成式体验用户就会被新兴的 AI 搜索产品分走。但问题在于拥抱生成式搜索需要付出代价。传统搜索的技术链路是“索引 排序 广告匹配”一次查询的边际成本很低。生成式搜索则是“检索 重排 大模型推理”每次查询都可能触发一次甚至多次大模型前向推理。后者在算力消耗上比前者高一个数量级。这就是 AI capex 压力的来源之一产品形态升级底层算力需求必然跟着升级。所以这里的“牺牲”不是说 Google 傻而是它把资源从“守成”转向“进攻”。搜索业务今天贡献大部分利润但 AI 被认为是决定下一个十年的入口。把手里的现金牛拿去喂养下一个技术周期是典型的“战略型资源再分配”。问题是再分配的速度和尺度是否合理。3. 资本支出到底花在哪数据中心、芯片、电力与推理集群AI 资本支出不是一个抽象概念它最终会变成一套可见的基础设施。从公开信息来看Google 的 AI 资本支出主要集中在以下几个方向。3.1 数据中心建设大模型训练和推理需要大规模 GPU/TPU 集群而集群必须放在有电、有网、有散热条件的数据中心里。数据中心建设周期长通常需要数年才能从动工到交付。这意味着资本支出一旦启动短期内很难因为业务波动而暂停。从工程角度看这属于典型的“先有物理设施后有软件生态”。模型可以快速迭代但机房和供电不行。数据中心一旦建起来要么满载运行要么承担闲置成本。这也是 AI 资本支出“不可逆”的原因之一。3.2 自研芯片与 GPU 采购Google 的算力策略和 OpenAI/Microsoft 不完全一样。Google 很早就布局了自研 TPU并在内部大规模使用。TPU 的特点是针对 TensorFlow/JAX 等框架做了深度优化在训练吞吐和能效比上有优势但它在软件生态、灵活性方面不如 NVIDIA GPU 通用。实际部署场景里Google 同时拥有 TPU 和 GPU 两种资源形成了混合算力池。对技术团队而言这给了一个重要的启发不要只押注单一算力架构而是要根据训练负载和推理负载的特点做混合调度。3.3 电力与散热大模型集群的能耗是传统数据中心的好几倍。高密度机柜意味着更强的电力配套、更复杂的液冷散热、更贵的运营成本。这部分成本经常被低估但在真实的 AI 工程实践中电力预算往往是决定一个训练任务能否长期运行的关键因素。3.4 推理基础设施训练只是资本支出的一部分推理才是长期成本的大头。一个模型训练完成之后每次被用户调用都会产生推理成本。如果产品是免费向用户提供生成式搜索那么每次用户提问都在消耗公司资源。用户规模越大推理成本越不可控。这也是 AI capex “持续烧钱”的根本原因训练是一次性投入推理是持续投入。模型越强、用户越多推理成本越高。4. AI 资本支出如何影响“金鹅”三条传导路径下面用工程化思维拆解“资本支出怎么传导到核心业务”不讨论股价只讨论业务运作。4.1 资源挤占工程团队聚焦 AI搜索团队被抽血大模型不是只有算力就能成它需要大量顶级工程师。Google 内部把许多搜索、广告团队的工程师调去参与 Gemini 和 AI 基础设施项目这必然影响原有业务的产品迭代速度。当一个企业把核心人才集中到新方向老业务就进入“防守状态”。短期看老业务还能靠惯性增长长期看当 AI 产品尚未形成稳定商业模式时老业务的增长放缓会直接影响公司整体现金流。这是典型的“新旧动能切换期”阵痛。4.2 产品形态变化AI Overviews 拉低了广告位效率生成式搜索把答案直接呈现在用户面前用户点击传统搜索结果的比例会下降。如果用户不再点那十条链接搜索广告的曝光和点击也会跟着受影响。这是“金鹅”受损最直接的一条路径产品体验越好传统广告模式越受伤。AI Overviews 本质上是在用业务利润换用户时间是一种“自损式创新”。如果 AI 搜索无法建立新的变现模式比如广告以引用/推荐形式融入生成结果那搜索业务的利润率会被持续稀释。4.3 成本结构变化每查询成本从“分”涨到“角”甚至更高传统搜索一次查询的边际成本非常低所以才可以支撑每天数十亿次免费查询。生成式搜索不同大模型推理需要消耗大量显存和计算资源每查询成本显著上升。如果用户搜索量不变仅替换一部分结果为生成式回答总成本就会明显增加。从 AI 工程实践的角度看这里最核心的指标是“单位查询算力成本”。技术团队在评估生成式产品时不能只看模型效果还要看单个请求的推理延迟单个请求消耗的 token 数量单次推理的 GPU 占用时长缓存命中率峰值并发下的扩容成本5. 从 AI 工程实践看训练成本、推理成本与容量规划这一部分是本文的重点。资本支出是公司层面的决策但落到技术团队就是一组非常具体的工程问题。5.1 训练成本的计算思路大模型训练成本主要取决于模型参数量、训练 token 数、硬件类型和集群规模。虽然不同框架的计算方式有差异但工程上可以抽象成一个粗略公式# 训练成本估算脚本示例实际参数需按硬件和框架调整 def estimate_training_cost( params_b: float, # 模型参数量单位十亿 tokens_b: float, # 训练数据量单位十亿 token hardware_flops: float, # 单卡有效算力单位TFLOPs gpu_count: int, # GPU 数量 utilization: float, # 算力利用率一般 0.3~0.5 cost_per_gpu_hour: float, # 单卡每小时成本单位元 ): # 参考 Chinchilla 法则训练 token 数约为参数量 20 倍附近 total_flops 6 * params_b * 1e9 * tokens_b * 1e9 # 转换为 TFLOPs total_flops_t total_flops / 1e12 # 集群总算力 total_tflops hardware_flops * gpu_count * utilization # 训练耗时小时 hours total_flops_t / total_tflops / 3600 # 训练成本 cost hours * gpu_count * cost_per_gpu_hour return hours, cost hours, cost estimate_training_cost( params_b7, tokens_b140, hardware_flops150, gpu_count128, utilization0.4, cost_per_gpu_hour20, ) print(f预估训练耗时: {hours:.1f} 小时) print(f预估训练成本: {cost:.1f} 元)这个脚本只是演示计算逻辑实际项目中需要用 profiling 工具拿到真实算力利用率再结合云厂商定价或自建机房的折旧成本来修正。训练成本的最大风险是“利用率过低”很多训练任务因为数据质量差、并行策略不当实际利用率只有 30% 左右大量算力被浪费。5.2 推理成本与容量规划推理成本比训练成本更值得关注因为它是持续发生的。容量规划的目标是在满足延迟 SLA 的前提下用最少的 GPU 支撑最多的并发请求。核心指标有三个吞吐量每秒处理的请求数延迟单次请求的 P50/P95 耗时成本效率每 1000 次请求消耗的 GPU 小时数下面给出一个简单的容量估算脚本# 推理容量估算脚本示例 def estimate_inference_capacity( max_batch_size: int, avg_latency: float, # 单次请求平均延迟单位秒 target_qps: float, # 目标每秒请求数 gpu_count: int, ): # 单 GPU 每秒可处理请求数粗略 per_gpu_qps max_batch_size / avg_latency total_qps per_gpu_qps * gpu_count hit total_qps target_qps return { per_gpu_qps: round(per_gpu_qps, 2), total_qps: round(total_qps, 2), needed_gpus: round(target_qps / per_gpu_qps 0.5), can_meet_target: hit, } result estimate_inference_capacity( max_batch_size8, avg_latency2.0, target_qps100, gpu_count16, ) print(result)容量规划不是一次性的而是要随着模型版本、量化方式、缓存命中率的变化持续调整。Google 这种量级的公司推理集群一定是弹性伸缩的而且会做大量缓存来降低重复请求的算力消耗。5.3 TPU vs GPU算力选型是长期工程问题对大多数团队来说直接买 TPU 不现实但理解 TPU 和 GPU 的差异对判断成本走势有帮助。TPU 适合大规模、确定形状相同输入输出维度的矩阵运算训练吞吐高、能效比好。GPU 在灵活性、通用生态、推理部署方面更有优势企业级应用和云原生部署工具链更成熟。Google 的策略是“混合调度”训练用 TPU推理用 GPU 或经过优化的 TPU 服务根据负载特征动态切换。对中小团队建议优先考虑 GPU 云实例先把业务跑通再根据成本数据决定是否引入专用芯片。不要为了技术情怀选型要用成本数据说话。6. 对技术团队的借鉴如何建立 AI 投入产出评估体系从 Google 的例子中技术团队可以总结出一套自己的 AI 投入产出评估方法。下面给出一个通用框架。6.1 先建成本基线在启动任何 AI 项目前先建立成本基线当前方案的单次调用成本当前方案的 P95 延迟当前方案的离线评估指标准确率、召回率、人工评分上线 AI 方案后这些指标能提升多少不要让“AI 更好”停留在感觉层面要把效果指标量化。{ project: customer_service_ai, baseline: { current_cost_per_query: 0.01, current_p95_latency: 3.0, current_resolution_rate: 0.6 }, ai_target: { target_cost_per_query: 0.05, target_p95_latency: 1.5, target_resolution_rate: 0.8 }, tolerance: { max_cost_increase_ratio: 5.0 } }6.2 按成本分层选模型不要所有任务都用同一个大模型。常见的分层策略简单任务分类、抽取、关键词生成用小模型或规则引擎中等任务摘要、改写、结构化输出用 7B-14B 开源模型复杂任务长文档分析、多轮推理、代码生成用旗舰模型通过模型路由可以在效果和成本之间取平衡。这也是很多 AI 应用开发团队的常用做法。6.3 推理优化优先级推理成本过高时按以下顺序排查是否频繁生成重复文本增加语义缓存是否使用了过长上下文压缩提示词、精简对话历史是否可以用小模型替代用任务蒸馏或微调是否可以做量化INT8 / INT4 量化降低显存占用是否可以做投机解码用小模型草稿 大模型验证优化顺序不是绝对的但方向是清晰的先减少计算量再优化硬件效率。7. 常见问题与排查方法AI 投入产出决策中的五个坑这不是传统意义上的“报错排查”而是技术团队在评估 AI 资本支出和模型部署时最常见的五个决策陷阱。问题现象可能原因排查方式解决方案“评测指标很高线上效果很差”离线测试集过拟合增加线上 A/B 测试建立离线 线上双层评测体系“推理延迟能接受但成本爆表”只测了低并发没测峰值压测峰值并发做容量规划和弹性伸缩“模型越换越大效果提升不明显”任务难度已饱和分析错误样本用更小模型 知识库/工具调用替代“算力利用率很低”数据加载和调度瓶颈用 profiler 查看 GPU 利用率优化 DataLoader、调大 batch size“预算批了但不敢上线”没有建立成本监控建立每请求成本监控面板上线前设置成本告警阈值8. 从 Google 的赌注里技术团队可以带走的四件事Google 的 AI 资本支出决策是一面镜子它映射出的不只是一家公司的战略更是整个行业从“规则系统”向“生成式系统”迁移时的普遍困境。第一算力是新的稀缺资源但算力不等于效果。很多团队拿到 GPU 后的第一反应是“跑一个更大的模型”但更大的模型往往只带来小幅效果提升而成本和延迟却成倍增长。更务实的路径是先把数据质量、评测体系、推理优化做好。第二模型部署不是一次性动作而是持续的成本工程。模型上线只是开始之后每一次 prompt 修改、上下文长度调整、量化策略变更都会影响成本。技术团队必须有“成本可观测”的能力否则 AI 项目迟早会被成本拖垮。第三新旧业务的资源博弈会长期存在。如果一个团队把所有人抽去做新项目老业务就会出问题但如果把资源全部留在老业务又会被时代抛下。关键不是二选一而是设置“收入增长”和“新业务探索”双目标并定期复盘资源配比。第四基础设施投入要有“可逆性”设计。避免一次性锁死太多长期资源尽量采用弹性算力、按量付费、混合云部署。这样即使战略调整损失也可控。9. 下一步先跑通成本模型再谈 AI 大改造如果你现在正在规划 AI 应用开发或 AI 模型部署不妨从这几步开始梳理现有业务中“高频、重复、可量化”的任务为每个任务建立效果基线人工成本、错误率、响应时间选一个小模型做 PoC跑通后再评估是否升级大模型建立模型推理成本监控面板统计每次请求的 token、延迟和算力消耗用一个月的时间收集成本数据再决定是否扩大投入Google 的资本支出是百亿美元级的“大赌注”但对大多数技术团队来说AI 转型不需要一开始就豪赌。先用最小成本跑通一个业务场景拿到成本数据算清楚投入产出再决定下一步。这个思路看起来没有“All in AI”那么激进但它更符合工程逻辑先在真实数据上验证价值再逐步放大投入。这样既不会被 AI 浪潮甩下也不会因为盲目烧钱把核心业务拖垮。