4、计算资源优化（下）：容器化改造与资源限制，Serverless 架构的成本优势，GPU 资源调度与共享
4.1 容器化改造：从“大锅饭”到“小份菜”
说实话，很多团队做容器化改造，初衷都是“别人都在做，我也要做”。但真正落地后才发现，容器化本身不省钱，省钱的是你如何用它来管资源。
我见过最典型的场景：一台物理机跑一个 Java 应用，内存给了 32G，实际只用 8G。剩下的 24G 就这么空着，谁也不敢动。为什么？因为怕业务高峰期扛不住。这就是典型的“大锅饭”思维——资源给你了，你用不完是你的事，但你不能让我不够用。
容器化改造的核心，说白了就是把“大锅饭”变成“小份菜”。每个容器只拿自己够用的资源，剩下的资源可以给别的容器用。这样整体利用率就上去了。
核心收益：
- 资源利用率从 20%-30% 提升到 60%-80%
- 部署密度提升 3-5 倍
- 弹性伸缩能力从小时级降到秒级
4.2 Requests 和 Limits：别让容器“饿死”也别让它“撑死”
容器化改造中最容易踩的坑，就是 Requests 和 Limits 的设置。我刚开始做 Kubernetes 时，也犯过“全给 Limits 设很大”的错误。结果呢？节点资源被撑爆，Pod 被 OOM Kill，业务直接挂了。
Requests 是什么？ 它是容器启动时“保证能拿到”的资源量。调度器会根据这个值来决定把 Pod 放在哪个节点上。
Limits 是什么？ 它是容器“最多能用”的资源量。超过这个值，容器会被限制甚至杀掉。
我曾经踩过的坑：
有一次，我把一个 Java 应用的 Requests 设成了 2C4G，Limits 设成了 4C8G。结果节点上跑了 3 个这样的 Pod，每个 Pod 实际只用了 1C2G。但调度器以为每个 Pod 需要 2C4G，所以节点上还有大量空闲资源，却调度不了新的 Pod。这就是典型的“资源碎片”问题。
我的建议是：Requests 和 Limits 不要设成一样。Requests 按实际使用量的 80% 来设，Limits 按峰值的 120% 来设。这样既能保证资源不浪费，又能应对突发流量。
一个小技巧：
用 VPA（Vertical Pod Autoscaler）跑一段时间，它会根据历史数据推荐合理的 Requests 和 Limits 值。我习惯先用 VPA 跑一周，再手动调整。
4.3 Serverless 架构：按需付费的“真香”体验
你想想看，如果你的业务有明显的波峰波谷，比如白天流量大、晚上流量小，或者工作日忙、周末闲，那用传统方式就是“全天候烧钱”。
Serverless 架构的好处就在于：你不用为闲置资源付费。没有请求时，函数根本不运行，也就不会产生费用。
我在项目中遇到过这样一个场景：一个数据处理任务，每天凌晨跑一次，每次跑 10 分钟。如果用一台 4C8G 的 ECS 来跑，一个月要花 500 多块。但换成 Serverless 函数，每次执行只花几毛钱，一个月下来不到 20 块。这就是“真香”体验。
Serverless 的成本优势体现在：
- 零闲置成本：没有请求时，不产生任何费用
- 细粒度计费：按实际执行时间和内存消耗计费，精确到毫秒
- 自动弹性：流量从 0 到 10 万 QPS，自动伸缩，无需人工干预
- 运维成本低：不用管操作系统、补丁、扩容等琐事
适用场景：
- 定时任务、批处理作业
- API 网关后端、Webhook 处理
- 事件驱动型任务（如文件上传后处理）
- 低频访问的微服务
但 Serverless 也不是万能的。如果你的业务是持续高并发、长连接、或者对冷启动敏感，那 Serverless 可能并不适合。嗯，这里要注意：冷启动延迟是 Serverless 的硬伤，一般会有 100ms-1s 的延迟，对延迟敏感的业务要慎重。
4.4 GPU 资源调度与共享：让每一块 GPU 都物尽其用
GPU 有多贵，做 AI 的同学都懂。一块 A100 就要十几万，如果利用率只有 30%，那简直是暴殄天物。
我见过最夸张的情况：一个团队买了 8 块 V100，每块 GPU 上只跑一个模型训练任务，训练完了就空着。我问他们为什么不共享？他们说“怕互相影响”。
其实，GPU 共享技术已经很成熟了。主要有几种方式：
- MIG（Multi-Instance GPU）：NVIDIA 官方技术，可以把一块 A100 切分成最多 7 个独立实例，每个实例有独立的显存和计算单元
- vGPU：通过虚拟化技术，把一块 GPU 分给多个虚拟机使用
- 时间片调度：多个任务轮流使用 GPU，适合推理场景
- 显存隔离 + 计算共享：每个任务分配固定显存，计算资源按需分配
我的实践经验：
在 Kubernetes 中，我习惯用 Volcano 或 Hamid 来做 GPU 调度。它们支持 GPU 共享、显存隔离、优先级抢占等功能。比如，一个推理服务只需要 2G 显存，但整块 GPU 有 16G，那就可以把剩下的 14G 分给其他任务。这样一块 GPU 能同时跑 5-6 个推理服务，利用率从 20% 提升到 80%。
GPU 共享的注意事项：
- 训练任务对显存要求高，建议用 MIG 做硬隔离
- 推理任务对延迟敏感，建议用时间片调度，避免争抢
- 混合部署时，要设置好 QoS 等级，保证高优任务不受影响
我曾经踩过的坑：
有一次，我把一个训练任务和一个推理任务放在同一块 GPU 上，没做显存隔离。结果训练任务把显存吃光了，推理任务直接 OOM，线上服务挂了。后来我改用 MIG 做硬隔离，才彻底解决这个问题。
4.5 本章知识体系
下面这张图，是我梳理的本章核心逻辑。你可以把它当作一个“决策地图”：
4.6 总结
计算资源优化，说白了就是三件事：让资源不浪费、让成本不虚高、让性能不妥协。
容器化改造是基础，把“大锅饭”变成“小份菜”；Requests/Limits 是精细化管理，别让容器“饿死”也别让它“撑死”；Serverless 是极致弹性，不为闲置资源买单；GPU 共享是硬核技术，让每一块 GPU 都物尽其用。
我个人的习惯是：先做容器化，再调 Requests/Limits，然后看业务场景决定是否上 Serverless，最后才考虑 GPU 共享。因为 GPU 共享的技术门槛最高，风险也最大，需要充分的测试和灰度。
嗯，这一章的内容就到这里。记住：优化不是一蹴而就的，而是一个持续迭代的过程。每优化一步，成本就降一点，这就是运维的价值所在。