Google Cloud Compute Engine 是什么，虚拟机实例应该如何选择

Google Cloud Compute Engine并不只是一个“租服务器”的产品。

它提供的是一套完整的基础设施计算平台：用户通过API或者控制台创建虚拟机，指定CPU、内存、GPU、磁盘和网络等资源，Google Cloud负责底层物理服务器、虚拟化、数据中心网络以及计算资源的调度。用户看到的是一台可以安装操作系统、运行数据库、部署网站或者执行AI任务的虚拟机，但这台机器背后实际上连接着一整套云数据中心基础设施。

这也是理解Compute Engine最重要的入口。

一台云端虚拟机并不等于一台被完整切走的物理服务器。Google Cloud通过虚拟化把底层硬件资源抽象成VM，再根据不同机器系列、区域、可用区以及硬件平台提供不同的计算能力。用户购买的也不是某块固定CPU，而是某一种资源配置和相应的服务等级。

Compute Engine的核心不是“虚拟机”三个字，而是资源抽象

传统服务器采购的逻辑比较简单。企业购买一台物理服务器，CPU、内存、硬盘和网卡都属于这台机器，然后由企业自己负责操作系统、虚拟化、网络和硬件维护。

Compute Engine改变了这套关系。

用户创建一个实例时，可以选择机器类型、CPU和内存规格，再根据工作负载增加GPU、Local SSD、Persistent Disk或Hyperdisk等资源。Google Cloud负责底层物理硬件和云平台的运行。

目前Compute Engine已经形成多种机器系列，包括通用型、计算优化型、内存优化型、存储优化型、网络优化型以及GPU加速型等。Google Cloud甚至提供专门面向AI和HPC的加速器实例。

因此，“Compute Engine性能怎么样”其实不是一个完整的问题。

真正应该问的是：使用哪一种机器系列、什么CPU平台、多少内存、什么存储、什么网络、是否需要GPU，以及这些资源之间是否匹配。

vCPU不等于一颗完整的物理CPU

云计算中最容易被误解的概念之一就是vCPU。

vCPU是虚拟机看到的处理器资源单位，它并不简单等于一颗独立的物理CPU芯片。

不同机器系列的vCPU与底层CPU核心、SMT线程以及物理主机资源分配方式有关。Google Cloud的部分机器系列明确规定，一个vCPU对应一个硬件线程；某些新一代机器则关闭SMT，让一个vCPU对应完整CPU核心。

因此，同样是16个vCPU，不同机器系列之间不能直接认为性能相同。

这也是为什么云服务器不能只比较“CPU数量”。

CPU架构、频率、缓存、内存带宽、NUMA结构以及实例所在机器系列都会影响最终性能。

对于数据库、编译、科学计算等CPU密集型任务，选择计算优化型实例可能比简单增加vCPU数量更加有效；对于内存数据库或者大型缓存系统，则可能更应该选择高内存配置。

Google Cloud实际上已经把这些需求拆成不同的机器家族，而不是要求用户用一套实例配置解决所有问题。

GPU服务器和普通VM是两套不同的性能逻辑

Compute Engine可以把GPU提供给虚拟机使用，但GPU并不是“把一块显卡插进普通电脑”这么简单。

目前Google Cloud提供从NVIDIA T4、L4、A100、H100、H200到B200、GB200、GB300等不同级别的GPU机器配置。A100属于A2系列，H100和H200分别出现在A3系列的不同机器类型中，而更新的A4、A4X系列则面向更高端的AI计算。

这意味着原来文章中用“N1-standard-16加4张A100”作为今天AI服务器的典型案例已经不合适。

N1确实仍然可以连接部分GPU，但Google Cloud已经提供专门的A2、A3、A4等加速器优化机器系列。A2 Ultra直接使用A100 80GB；A3系列则提供H100和H200等GPU配置。

对于AI任务，选择GPU实例时不能只看GPU型号。

还要看GPU数量、显存容量、显存带宽、GPU之间的互联方式、CPU内存、网络带宽以及存储吞吐量。

因为AI训练真正运行起来以后，GPU并不是孤立工作的。

数据需要进入GPU，多个GPU之间需要交换数据，分布式训练还需要跨服务器通信。GPU本身再快，如果数据供应链跟不上，实际性能也可能大幅低于理论峰值。

TPU则是另一条路线

Google Cloud还提供TPU，但TPU不能简单理解成“Google自己的GPU”。

TPU是Google专门设计的机器学习加速器，其软件栈、编译器和框架支持方式与NVIDIA CUDA生态不同。

对于已经建立在JAX、TensorFlow等Google生态上的机器学习工作负载，TPU可能非常有吸引力。但如果一个团队长期依赖CUDA、CUDA库以及NVIDIA GPU生态，把GPU程序直接搬到TPU上并不是简单更换实例类型的问题。

这涉及算子支持、编译器、模型代码以及分布式训练方式。

所以GPU和TPU的选择，本质上不仅是硬件性能比较，也是软件生态和开发成本的比较。

Persistent Disk不是服务器里的普通硬盘

Compute Engine的存储系统也不能按照传统PC的“硬盘”来理解。

Persistent Disk属于网络连接的持久化块存储，数据独立于VM实例生命周期，可以在实例删除或者重新创建之后继续保留。Google Cloud目前还提供Hyperdisk，用于更高性能、可配置的持久化块存储。

这和Local SSD完全不同。

Local SSD物理连接在承载虚拟机的服务器上，因此可以提供非常低延迟和较高吞吐的临时存储性能，但它不是用来保存必须长期保留的数据。

尤其是GPU实例，Google明确提醒，主机维护等情况下Local SSD上的数据可能无法恢复，因此它更适合缓存、临时数据、scratch space以及中间处理文件，而不是数据库核心数据。

这也是云服务器设计中的一个基本原则：

持久化数据和高速临时数据应该分开。

数据库的数据文件、重要业务数据适合放在持久化存储；训练数据缓存、中间文件和临时计算结果则可以考虑Local SSD。

AI工作负载为什么越来越重视Hyperdisk

随着AI模型越来越大，传统“CPU加GPU加一块普通磁盘”的架构越来越难满足数据吞吐需求。

模型训练和推理需要不断加载模型权重、训练数据以及中间文件。如果GPU已经非常昂贵，却因为数据加载速度不足而等待，那么昂贵的GPU计算资源就没有得到充分利用。

Google Cloud已经针对机器学习场景提供Hyperdisk ML，用于提高数据读取吞吐并减少GPU等待。Google官方资料明确把它定位为适用于机器学习和模型服务的存储，并强调通过更高吞吐减少GPU空闲时间。

这说明AI服务器的存储问题已经从“需要多少GB”逐渐变成“每秒能给多少数据”。

网络实际上也是计算资源的一部分

在普通网站服务器上，网络带宽通常只是一个辅助指标。

但在分布式AI训练中，网络可能直接决定系统扩展效率。

假设一台机器里面有8张GPU，每张GPU都在进行计算。训练过程中，不同GPU需要交换梯度、参数或者其他中间数据。如果GPU之间通信速度跟不上计算速度，那么GPU数量增加以后，性能不会按照GPU数量线性增长。

跨服务器训练时问题更加明显。

此时数据不仅要在GPU之间移动，还需要经过服务器网络。因此，网络带宽、网络延迟以及RDMA等能力都可能影响训练效率。

这也是为什么Google Cloud针对高性能计算和AI基础设施提供高带宽网络能力，而不是所有VM都共享一个固定的“10Gbps网络”。

不同机器类型的网络上限差异可以非常大。例如当前C4A系列不同规格的默认出口带宽从最高23Gbps一直扩展到更高等级，大型实例还可以支持Tier_1网络带宽。

因此，分布式AI部署中不能看到GPU数量就结束选型。

GPU、显存、GPU互联和网络必须一起考虑。

为什么“GPU利用率70%以下就要优化”不是正确规则

原稿提出GPU利用率低于70%就应该检查数据加载，这种说法过于机械。

GPU利用率是一个观察指标，不是故障阈值。

一个推理服务可能因为请求量不足而GPU利用率只有30%，但延迟和成本都完全正常。

另一个训练任务即使GPU利用率长期达到90%，也可能因为显存容量不足、通信等待或者计算效率问题而没有达到最佳吞吐量。

因此，工程人员真正关心的是GPU利用率与实际吞吐量之间的关系。

如果GPU利用率低，同时CPU、存储、网络或者数据加载线程存在明显等待，那么才需要继续寻找瓶颈。

如果GPU利用率不高，但吞吐量已经满足业务需求，也没有必要为了追求一个漂亮的百分比继续增加硬件。

云服务器的性能优化本质上是成本优化

Compute Engine最有价值的地方，并不是让用户永远拥有一台“最快的服务器”，而是让计算资源可以根据业务需求进行组合。

开发环境可能只需要一台低成本通用VM。

网站流量增加以后，可以扩大实例规格或者采用负载均衡和多实例架构。

数据库需要更高内存时，可以转向内存优化型机器。

AI推理需要GPU时，再增加GPU加速实例。

大模型训练则可能需要高端GPU、快速本地存储、高带宽GPU互联和高速网络组成完整的集群。

不同业务阶段需要的是不同的资源结构。

这也是云计算和传统服务器采购最大的商业差异之一。

传统模式下，企业购买服务器时往往必须提前判断未来几年需要多少计算能力；云计算则把一部分硬件投资转换成按使用量付费的运营成本。Google Cloud目前的Compute Engine采用按使用付费模式，同时提供不同的价格和承诺使用方案，具体成本还会受到机器类型、区域、GPU、磁盘和网络流量等因素影响。

但“云计算按需付费”也不是天然便宜。

如果一台高性能GPU服务器连续运行数月，累计成本可能远高于一次性采购部分硬件。云的优势在于弹性、部署速度、全球基础设施以及减少企业自行建设数据中心的负担，而不是保证每一种工作负载都比自建服务器便宜。

真正困难的是资源匹配

Compute Engine的选型最容易犯的错误，就是根据一个数字选择服务器。

CPU密集型任务看vCPU数量，可能忽略内存带宽。

数据库看内存容量，可能忽略磁盘延迟和IOPS。

AI任务看GPU型号，可能忽略显存容量和GPU之间的通信。

大数据任务看磁盘容量，可能忽略实际吞吐。

分布式系统看服务器数量，可能忽略网络带宽。

最终都会出现一个问题：某个组件性能很高，但系统整体性能并没有同步提高。

一台AI服务器真正的性能，是CPU、系统内存、GPU、显存、存储、PCIe、GPU互联和网络共同形成的数据通路。

例如模型训练时，训练数据可能从持久化存储进入CPU侧内存，然后通过I/O路径进入GPU显存，再由GPU完成计算。多GPU训练还需要在GPU之间同步数据，跨服务器训练则进一步增加网络通信。

任何一个环节的吞吐量低于其他部分，都可能成为瓶颈。

所以，Compute Engine真正值得研究的并不是“哪一个实例最快”，而是哪一种资源组合最适合自己的工作负载。

对于普通Web服务，重点可能是CPU、内存、磁盘和网络。

对于数据库，重点可能转向内存容量、存储延迟、IOPS和持久化能力。

对于AI推理，需要同时考虑GPU、显存、模型大小、批处理方式和请求延迟。

对于大型模型训练，则需要进一步考虑GPU数量、显存、GPU互联、网络、存储吞吐以及分布式训练框架。

Google Cloud把这些资源拆成不同机器系列和不同硬件平台，实际上就是为了让用户按照工作负载组合资源，而不是把所有计算任务塞进同一种虚拟机。

理解Compute Engine，最终不能停留在“它是一台云服务器”这个层面。

它更接近一个由计算、内存、加速器、存储和网络组成的可编程基础设施平台。虚拟机只是用户看到的接口，真正决定性能的，是虚拟机背后那套硬件资源如何组合，以及数据在这些资源之间如何流动。

这也是云计算进入AI时代之后发生的重要变化。过去选择云服务器，往往是比较几个vCPU和多少GB内存；今天面对AI、数据库和高性能计算任务，服务器已经越来越像一套完整的计算系统。GPU型号只是其中一个组成部分，显存、CPU内存、存储、互联和网络任何一个环节没有跟上，昂贵的计算资源就可能无法发挥出来。

因此，Compute Engine的真正价值不在于提供多少种虚拟机，而在于把数据中心里的复杂硬件资源抽象成可以按需组合、按需调度的基础设施。用户真正需要优化的，也不是某一个参数，而是整条从数据存储到计算结果输出的数据链路。