从虚拟机到GPU池化：云计算这十年的三次底层重构

2015年我还在帮客户搭私有云，OpenStack 折腾一晚上，凌晨两点盯着 Horizon 界面等一台实例起来。那时候大家嘴里的“云计算”，本质上还是“虚拟机的另一种叫法”。谁能想到十年之后，我们讨论的已经变成“GPU 池化”“函数级计费”和“AI 工作负载感知调度”。这十年云计算演进，绝不是工具链的简单更迭，而是从资源抽象、交付模型到运维哲学的底层重构。

这篇文章我不想写成编年史，更想以从业者的体感，复盘 2015–2025 这个周期里真正改变我们做事方式的关键节点，同时把适合新手的理解和踩过的坑讲清楚。如果你正在做架构设计、运维平台，或者刚入行想建立对云计算的系统认知，这篇内容应该能帮你少走不少弯路。

1. 2015–2019：容器与编排，把“资源管理”变成“配置管理”

1.1 虚拟机与容器的分水岭

2015 年前后，主流的云交付方式还是 VM。你申请一台 4C8G 的机器，要等镜像注入、网络配好、安全组刷新，运气好几十秒，运气差几分钟。VM 的好处是隔离性强，但缺点在规模化以后特别明显：分发颗粒度太大，交付周期偏长，包一层 Guest OS 还带来性能开销和补丁维护量。

容器真正引起关注，不是因为“轻量”这个标签，而是它把不可变交付变成了默认事实。镜像一旦构建，里面的代码、依赖、运行时全被固化，启动一个容器只需几十毫秒级。我印象最深的是一个内部测试环境，原先每天要创建 30 多台虚拟机做集成测试，成本高、回收困难；改成容器后同一个集群可以在 10 分钟内跑完整个测试矩阵，脚本也没以前那么臃肿。这个对比，你要亲自动手才能感受到差距——不是快 10% 的快，是效率模型都换了。

不过容器早期也藏着一个暗坑：存储和网络都太简陋。数据放本地盘，容器一删就没了；端口映射只能靠宿主机随机分配，服务发现得自己写。这也是 Kubernetes 能从一堆编排器里跑出来的重要原因——它不只是把容器管起来，还把 ConfigMap、Service、Volume 这些“配套环境”做成了声明式的资源。

1.2 Kubernetes 赢在“声明式控制循环”而不是功能多

2017 年左右，大家都在选型：Swarm、Mesos、Kubernetes。Swarm 上手简单，Mesos 擅长超大规模物理机资源调度，K8s 早期用起来是真复杂。但 K8s 有个东西是另外两家没有的——声明式 API 加控制循环。

你把期望状态写进 YAML，控制器不断对比实际状态，有偏差就调回去。这个模式一开始被不少人当成“曲线救国”，后来被证明是运维自动化的最佳抽象。我见过很多团队，刚开始不习惯写清单文件，总想在容器启动后跑几条命令“修正”环境，结果越修正越乱。后来老老实实把配置全部搬进 manifest，反而流程顺了，回滚也只需要kubectl apply上一版文件。

从具体的岗位变化来看，这个阶段催生了“云原生运维工程师”这样一个角色。以前运维干活靠堡垒机和脚本库，现在核心能力变成了：写清楚资源配置、设计好弹性策略、通过 Operator 扩展平台能力。这也是为什么我看新简历时，会特别关注候选人有没有亲手写过自定义 Controller——能写出 Controller，才算真正理解 Kubernetes 不是“容器仓库”，而是一台不断趋近声明状态的“自动修正器”。

1.3 私有云与 OpenStack 的退场逻辑

2015 年 OpenStack 几乎是私有云代名词，但到了 2019 年，多数企业的自建私有云项目开始收缩。原因很直接：你能用 OpenStack 把虚拟机管起来，但没法用 OpenStack 把“升级、补丁、版本兼容”的复杂度管起来。版本一升级，各个组件互相踩依赖，社区版运维成本甚至高过公有云账单。那时候很多运维调侃：OpenStack 最好的使用方式，就是别自己装。

这不是说私有云没有存在价值。合规要求高的行业、边缘站点、混合架构的数据驻留场景，仍然需要私有云形态。只是十年前的逻辑是“私有云更省”，后来的真实账本是：只有规模大到能分摊固定成本，私有云才划算。如果你现在还在做私有云选型，我的建议是优先看基于 Kubernetes 的云原生栈，或者云厂商的专有云产品，别再从 IaaS 裸机起步搭一套完整平台了，那条路的时间成本大概率超出预期。

1.4 从实际扩容任务看交付效率的变化

为了更直观地展示这四年发生了什么，我列一张自己在真实项目里记录的对比表，前后都是给一套核心业务扩容 8 个节点：

这个表格不是为了说明工具谁好谁坏，而是想提醒大家：资源供给从“手工流程”变成“配置操作”以后，很多岗位的工作重心也变了。2015 年团队要养一个运维专门处理节点和网络；2018 年这部分精力已经释放给了业务稳定性设计和成本优化。

2. 2019–2022：Serverless 与托管化，让“弹性”成为一种默认可选项

2.1 为什么说 Serverless 不是一个营销词

Serverless 在国内热起来大概在 2019 年。它解决的问题很实际：不管你是虚拟机还是容器，只要实例活着，就要花钱。但真实业务流量有高峰和低谷，夜里 2 点的电商平台根本不需要跑几百个实例。函数计算这类形态，直接把计费单位改成“请求次数 × 执行时间”，没有调用就没有费用。

这个“按真实用量付费”的理念，才是 Serverless 最核心的竞争优势。它逼着应用把业务拆小，用事件去驱动，而不是让一个庞然大物永远苏醒在那里。很多朋友觉得 Serverless 只能跑轻量脚本，那是不了解平台后来的演进：异步长任务、流处理、音视频转码、消息消费，都能以函数或指标为基础单位承载。关键在于你的计算模型要适合拆分。

2.2 冷启动与有状态访问，避不开的两个坎

要玩好 Serverless，绕不开冷启动延迟。平台为你的函数准备好执行环境需要时间，第一次调用往往比后续调用慢很多。你可以通过保持实例预热、配置并发上限、精简运行时依赖来降低冷启动影响。按我的经验，依赖体积和启动延迟基本成正比，动不动把一个完整 SDK 全量引进去，冷启动时间会非常难看。

有状态访问是另一个常见误区。函数默认是无状态的，你的文件系统不是持久盘，新实例不一定复用旧内存。有的人把临时文件直接写本地目录，结果并发一高，任务错乱。正确的做法是把状态放 Redis、数据库或对象存储，本地只保留短暂缓存。设计原则不复杂：函数就像快餐店员工，每个订单无影无踪，却要服务好每一波顾客。

2.3 微服务和 FaaS 的结合方式

有人以为有了 Serverless 就再也不需要微服务了，其实两者是配合关系。长事务、强一致、复杂状态流转，交给微服务更合适；突发的瞬态事件、回调、异步消息处理，用函数效率更高。

我实测过的方案：核心交易链路保持微服务，订单创建后投递到消息队列，队列出发函数去做通知推送、积分计算、风控辅助判断。这样流量的毛刺被函数吸收，核心服务的扩缩容不会因为小幅冲击就频繁抖动。成本上也很直接：微服务只需扛住稳态 QPS，函数只对突发消息付费，整体开销比我以前把整条链路都常驻要省 30% 以上。

2.4 托管服务的选型判断：什么时候该“偷懒”

这几年云厂商把数据库、消息队列、缓存、日志都做成了托管服务。很多团队纠结：是自建 Kafka/Redis 集群，还是直接用云上托管版？我自己的评估标准很简单——自建成本是否为你带来不可替代的掌控力。

如果你有强溯源需求、复杂的二次开发、需要极细粒度内核参数调优，那自建合理。但大部分团队场景只是“想要一个大规模消息管道”，为一个通用需求背起运维整套集群的负担，并不划算。托管服务扩容方便、版本升级有人管、故障有 SLA，省下的时间完全可以投到业务代码里。

唯一要注意的是别被“托管”蒙蔽了可观测性。托管版虽然给你指标监控，但很多内部队列长度、磁盘 IO 细节未必透明。我建议在选型前把关键指标清单列出来，看平台是否能通过监控 API 暴露给你。否则出了问题，你只能对着平台工单等回应，那是真的难受。

3. 2022–2025：AI 工作负载进入云计算主赛道

3.1 从“容器调度”到“GPU 调度”的新命题

2022 年以后，大模型训练和推理需求爆发，云计算的核心资源从 CPU 转向 GPU。传统 Kubernetes 资源调度对 CPU/内存的抽象是透明的：你申请 16 核，调度器就给你分 16 核。但 GPU 不一样，它自带显存、算力拓扑、NVLink 连接关系，不能把它当成一个普通可枚举的整数资源。

这带来一系列实操变化。你要考虑 GPU 共享：一张 A100 80G 的卡，跑一个小模型推理可能只用 20G 显存，剩下资源闲着可惜。于是有了显存细粒度切分。可切分又带来隔离问题：显存放不下是小事，算力被邻居抢占、影响延迟才是大麻烦。我在生产环境看到过两个推理服务共享一张卡，流量一起来，两个服务相互拖垮。最后方案是给每个服务限定算力配额，相当于给 GPU 加上“CPU 限制”。

3.2 推理和训练场景，应该分开设计

AI 应用分为训练和推理两大类，它们对云计算的要求南辕北辙。

训练任务的特点是：周期长、资源密集、依赖拓扑感知。你需要多机多卡互联，NCCL 集合通信能跑满带宽，网络必须支持 RDMA 或者高性能 RoCE。训练作业还要频繁保存 checkpoint，存储系统如果跟不上，训练中断恢复的时间会变成灾难。我的建议是训练集群尽量用专业的高性能算力集群，不要临时把普通容器集群改造成训练环境，网络拓扑和调度策略都不匹配。

推理任务的特点：延迟敏感、流量波动大、单位请求成本要控住。这类场景更适合 Serverless 化的 GPU 推理。平台可以根据调用量自动拉起推理实例，低峰期缩到零。注意冷启动问题同样存在：模型加载进显存需要几十秒，你用自动伸缩时要预留缓冲池，否则流量一上来，前几百个请求会超时。

3.3 Operator 与资源抽象层的演进

Kubernetes 生态为了适配算力，到处都在做“自定义资源”。比如用 CRD 描述 GPU 分配策略，用 Device Plugin 让 kubelet 感知显卡设备，用 scheduler extender 做拓扑约束。这些抽象的核心目标只有一个：让用户不用关心“我的任务具体落在哪张卡上”，系统自动把算力安排好。

这其实是十年前 K8s 对 CPU 抽象思路的自然延续。但算力抽象比 CPU 抽象麻烦得多，因为 GPU 是“昂贵、不可超额售卖”的资源。一台 CPU 服务器你可以超卖 50% 不觉得有多大问题，GPU 超卖可能导致显存溢出和训练中断。所以好的算力调度系统，要能实时感知每张卡的显存使用、算力负载、链路状态，再结合任务优先级做抢占或排队。云计算的下一波竞争，很大程度会集中在谁能把这个调度做得更聪明。

3.4 运维工程师的新画像：算力成本顾问

以前运维工程师看 CPU、内存、磁盘，现在不少人开始关心 GPU 利用率、训练损失曲线、能否用 bfloat16 精度节省显存。这个变化就发生在近两三年。我认识很多朋友，原本是 K8s 管理员，因为公司开始做大模型，周末都在学 CUDA 和 PyTorch 分布式训练原理。

不是要每个人都变成算法工程师，但理解 AI 工作负载的“生命周期”变得很重要。训练任务占着资源不释放怎么处理？推理服务的扩缩容策略怎么设，才不会把 GPU 显存打爆？一个卡点训练失败重启，重试退避多久？这些问题的解决质量直接决定单次训练任务的真金白银消耗。懂算力成本的运维，慢慢变成了团队的“算力预算管理者”，话语权比以往高很多。我预测未来两三年，这类复合背景的人在市场上会更吃香。

4. 贯穿十年的三条主线：抽象、运维与成本

4.1 资源抽象层级不断升高

回看十年，云计算一直在做同一件事：把底层资源往更高层的抽象上搬。

最早抽象的是虚拟机，给你一台远程机器很“完整”，但你得关心它的操作系统、磁盘分区、补丁更新。后来抽象的是容器，把“完整机器”换成“一个进程的运行环境”，更重要是它可以标准化复制。再往后抽象的是函数，连运行环境生命周期都省了，给一段代码处理事件就行。到了 AI 时代，抽象的是“算力”，不只是 CPU 和 GPU 设备，还包括分布式通信拓扑、任务调度策略、成本和延迟的自动权衡。

这个趋势对个人发展的启示很直接：如果只会操作某一层抽象，天花板一定存在。真正值钱的，是理解抽象背后的资源模型、调度原则和失效模式。你会用 Docker 只是开始，搞懂容器网络和存储，才有一点不可替代性。

4.2 交付模式从“工具链”进化到“平台工程”

2015 年的运维，更像是在拼凑一堆工具。代码用 Git、部署用脚本、监控用 Nagios、日志用 ELK，每个环节贴着胶带跑。后来大家发现，真正解决效率问题的不只是“多一招”，而是把开发、测试、发布、运维的路径统一起来。平台工程于是出现。

平台工程不是再多几个配置页面或门户，而是把环境创建、权限控制、发布审批、成本核算、可观测性这些能力用代码和 API 显露出来。开发人员通过一条流水线就能完成从提交代码到上线观测的闭环，不再需要满天飞找运维开权限。我在团队里推动过类似改造，最大的阻力不是技术，而是流程惯性。但只要把一条核心链路的体验做到极致，后面团队自然会跟着迁移。

4.3 成本模型从“预算灭火”走向 FinOps

十年前大家上云，算成本就是看云厂商官网的按量价格。真实账单下来，发现流量、存储、快照、日志等各种明细项让人发懵。这几年 FinOps 这个词开始流行，本质就是让云成本管理变成一种持续协作机制，而不只是财务和运维在月末对账。

我自己的成本优化路径总结为三步。第一步，先找出闲置和低利用率资源，包括晚上跑着没用的测试集群、很久没人访问的云盘快照，这通常能省下 20% 的成本。第二步，优化规格和付费模式，采购抵扣券或长周期承诺，能覆盖稳定负载的折扣空间。第三步，做精细的标签和计量，让每个业务部门知道自己的成本构成，决策前先看预算影响。

三个阶段互相递进，缺一不可。不要一上来就想设计一个多复杂的成本监控平台，先把手动账单看细比什么都强。

4.4 十年演进对照表

为了帮你快速建立整体感，我把十年分成三个阶段，做一个横向对照：

这张表不用背，但要体会背后的逻辑：每经过一次演进，你管理的对象离“业务语义”就更近一步，所以要求的能力也从“会敲命令”变成“会设计系统”。

5. 避开十年里最常见的选择误区

5.1 别把“上云”当成“把服务器放别人机房”

我见过太多团队，上云就是把原来的单体应用搬到云主机上。这样表面上用了云，其实只换了一个托管机房，弹性和可靠性一点没享受到。真正的上云，要按云原生的思路重新审视应用结构：无状态化改造、配置外置、日志集中化、依赖服务托管化。否则云平台提供再好的能力，在你这里也只是更贵的物理机。

5.2 别把“云原生”当成“必须拆微服务”

作为一种抽象思维，云原生不意味着摧毁所有单体服务。一个简单的 CMS 系统，硬拆成十几个微服务，只会把分布式复杂度引入业务价值很低的模块。我一般建议按“变更频率、伸缩需求、团队边界”三个维度判断是否拆分。核心流程、高并发模块、跨团队独立发布部分值得拆，纯粹的数据 CRUD 保持单体反而更好维护。

5.3 别只盯着计费价格，忽略隐性成本

很多人在总结十年上云经验时，最后会提到隐性成本。网络流量跨区费、日志存储长期累积、快照和镜像占用、忘记释放的公网 IP，这些杂项加起来往往比计算资源还高。建议从一开始就建立资源标签和预算告警，新资源不打好标签不能上线。这在团队小的时候看来有点形式主义，但规模大到一定程度，这是救命的。

5.4 新进入者怎么学这十年积累

如果你想进入云计算领域，又觉得十年演进信息量太大，我给你一个路径：

第一步，掌握 Linux、网络基础、虚拟化原理，这是底层底座。第二步，动手用 Kubernetes 部署真实应用，理解声明式和控制器模式。第三步，至少把一个云服务商的产品体系摸透，包括计算、存储、网络、容器、Serverless 都有什么能力，什么时候该用哪个模块。第四步，选择一条新方向深钻：算力调度、FinOps、云原生安全，任何一个方向都值得深耕。

这套路径不需要再去完整经历一遍 2015 年的手工时代，但你会通过理解抽象层级，明白今天这些工具到底解决了什么原始痛点。

写到最后的一点体会

这十年云计算演进的轨迹，对从业者最大的启示是：要学会把工作重心，不断从“资源管理”往“抽象设计”上移。整条技术路线的每一波变化，都在淘汰只会原地操作某一种资源的人，同时给理解资源本质的人更高杠杆。

对我来说，回头看，最值钱的不是当年记住了多少参数和命令，而是建立了一套判断方式：面对新需求时，先明确资源模型是什么，交付模型是什么，成本模型是什么。想清楚这三个问题，技术选型基本不会走偏。你不需要追每一个新出功能，但要始终保持对抽象层变化的敏感——下一个十年，一定还会出现新的抽象，把今天所谓的高门槛，变成未来默认的底座。