企业官网建设流程全解析

这次我们看一个不那么“手把手”但更值得技术人员关注的话题：Google 在 AI 资本支出上疯狂加码，会不会正在牺牲自家的“金鹅”。标题里的 golden goose 指的不是某个产品，而是 Google 搜索和广告这条贡献了绝大部分利润的现金牛业务。AI capex 则是围绕大模型建设的数据中心、芯片、能源和网络基础设施投入。这篇文章不做财报分析，而是从算力基建、模型部署、推理成本和工程实践四个角度拆解一件事：当一家公司把预算和工程资源同时压向 AI，核心业务会经历什么，技术团队又能从中学到什么。

文章会覆盖三块内容：第一，Google 为什么要重仓 AI，钱花在哪些地方；第二，这笔资本支出与搜索/广告业务之间为什么存在冲突，影响是怎么传导的；第三，从 AI 工程实践、模型部署、推理成本优化角度，给正在做类似决策的技术团队一组可落地的评估方法和工具。无论你是在做 AI 应用开发、AI 模型部署，还是负责公司内部的 AI 基建预算，这篇文章都值得往下看。

1. 核心信息速览

先把这次讨论的关键信息列出来，方便快速定位。

需要注意：本文涉及的具体资本支出金额、芯片参数和业务数据，均会采用保守表述。技术团队可以参考这里的评估框架，但实际数字必须以本公司的预算模型和测试环境为准。

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_b=7, tokens_b=140, hardware_flops=150, gpu_count=128, utilization=0.4, cost_per_gpu_hour=20, ) 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_size=8, avg_latency=2.0, target_qps=100, gpu_count=16, ) 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 推理优化优先级

推理成本过高时，按以下顺序排查：

1. 是否频繁生成重复文本：增加语义缓存
2. 是否使用了过长上下文：压缩提示词、精简对话历史
3. 是否可以用小模型替代：用任务蒸馏或微调
4. 是否可以做量化：INT8 / INT4 量化降低显存占用
5. 是否可以做投机解码：用小模型草稿 + 大模型验证

优化顺序不是绝对的，但方向是清晰的：先减少计算量，再优化硬件效率。

7. 常见问题与排查方法：AI 投入产出决策中的五个坑

这不是传统意义上的“报错排查”，而是技术团队在评估 AI 资本支出和模型部署时最常见的五个决策陷阱。

8. 从 Google 的赌注里，技术团队可以带走的四件事

Google 的 AI 资本支出决策是一面镜子，它映射出的不只是一家公司的战略，更是整个行业从“规则系统”向“生成式系统”迁移时的普遍困境。

第一，算力是新的稀缺资源，但算力不等于效果。很多团队拿到 GPU 后的第一反应是“跑一个更大的模型”，但更大的模型往往只带来小幅效果提升，而成本和延迟却成倍增长。更务实的路径是先把数据质量、评测体系、推理优化做好。

第二，模型部署不是一次性动作，而是持续的成本工程。模型上线只是开始，之后每一次 prompt 修改、上下文长度调整、量化策略变更，都会影响成本。技术团队必须有“成本可观测”的能力，否则 AI 项目迟早会被成本拖垮。

第三，新旧业务的资源博弈会长期存在。如果一个团队把所有人抽去做新项目，老业务就会出问题；但如果把资源全部留在老业务，又会被时代抛下。关键不是二选一，而是设置“收入增长”和“新业务探索”双目标，并定期复盘资源配比。

第四，基础设施投入要有“可逆性”设计。避免一次性锁死太多长期资源，尽量采用弹性算力、按量付费、混合云部署。这样即使战略调整，损失也可控。

9. 下一步：先跑通成本模型，再谈 AI 大改造

如果你现在正在规划 AI 应用开发或 AI 模型部署，不妨从这几步开始：

1. 梳理现有业务中“高频、重复、可量化”的任务
2. 为每个任务建立效果基线（人工成本、错误率、响应时间）
3. 选一个小模型做 PoC，跑通后再评估是否升级大模型
4. 建立模型推理成本监控面板，统计每次请求的 token、延迟和算力消耗
5. 用一个月的时间收集成本数据，再决定是否扩大投入

Google 的资本支出是百亿美元级的“大赌注”，但对大多数技术团队来说，AI 转型不需要一开始就豪赌。先用最小成本跑通一个业务场景，拿到成本数据，算清楚投入产出，再决定下一步。

这个思路看起来没有“All in AI”那么激进，但它更符合工程逻辑：先在真实数据上验证价值，再逐步放大投入。这样既不会被 AI 浪潮甩下，也不会因为盲目烧钱把核心业务拖垮。