上个月在一个客户的运维群里看到两句对话印象特别深“又有任务在排队了谁偷偷占了整块 A100”“我约了两天的卡还没轮到老板催着出测试结果。”这种场景在 GPU 集群里太常见了。大模型这波浪潮推进了两年多真正跑 AI 业务的团队基本都撞上了同一堵墙GPU 够不够是一回事设备到了之后能不能高效用起来是另一回事。大家手里的 GPU 越来越多但集群的 GPU 利用率、调度效率、成本支出往往都不忍细看。所以看到“阿里云 ACK 新升级打造智算时代的现代化应用平台”这个消息时我并没有把它当成一次普通的版本更新来读。AI 工作负载正在从“能跑”走向“跑好”这个阶段容器平台的核心矛盾已经变了Kubernetes 不能再只当一个“跑容器的平台”它得变成一个真正“调度算力的平台”。这篇文章不打算复述官方新闻稿而是结合我在客户现场看到的真实问题以及 ACK 现有能力的实测体验聊聊智算时代容器平台应该长什么样这次升级到底解决了什么以及如果你想把手里的 AI 工作负载真正跑稳、跑省有哪些配置值得第一时间用起来。1. 智算时代的“分水岭”为什么传统容器平台先扛不住了1.1 大模型工作负载和普通微服务的本质差异先搞清楚一个底层问题AI 负载和传统微服务对容器平台的诉求完全是两个物种。传统微服务是 CPU/内存密集、无状态、可以随意横向扩缩容的。一个订单服务扛不住了replicas 从 3 拉到 30几十秒搞定。这类负载对调度的要求很简单IP 够用、端口不冲突、CPU 和内存按 requests/limits 分清楚就行。Kubernetes 原生的调度器干这个活已经非常成熟。但 AI 负载不一样。训练任务一跑就是几小时甚至几天对 GPU 算力和显存有硬性要求还涉及多机多卡通信推理任务则是延迟敏感线上流量一会儿高峰一会儿低谷GPU 分配多了浪费钱分配少了影响用户体验。更麻烦的是GPU 在 Kubernetes 里的初始定位非常“外设化”——kubelet 上报一个nvidia.com/gpu的资源数量调度器看到是几块卡就按整卡分配既不感知显存也不感知算力切分。这就导致了几个我们在客户现场反复看到的痛点GPU 利用率低。一块 80G 显存的卡上面跑了个 12G 的小模型推理任务剩下的 68G 全闲着。高峰期又排了一堆任务拿不到卡。看起来集群很忙实际上算力浪费非常夸张。排队靠人肉。我见过不止一个团队的协调群天天有人问“那块卡用完了吗”“我今天能不能插个队”。没有队列调度没有配额管理GPU 资源成了“谁嗓门大谁先用”。显存碎片化。没人能准确说出每张卡还剩多少显存调度器只知道卡的数量不知道卡的“剩余容量”。任务调度基本靠猜猜错了就 OOM。运维复杂度爆炸。驱动版本、CUDA 版本、不同型号 GPU 混布、节点故障后任务能不能自动恢复每一个问题都能让运维同学掉头发。当这些痛点同时爆发传统 K8s 平台的边界就显露出来了。这不是某个参数调不对的问题而是调度模型和资源模型从根上就不适配。1.2 所谓“智算现代化”到底现代化在哪这次 ACK 升级给我最明显的感觉是阿里云不再把容器平台单纯定位成一个“Kubernetes 托管服务”了而是试图把它做成一个能承载 AI 全生命周期的“算力底座”。换句话说升级的核心不是功能堆叠而是资源观的转变。过去我们看一个集群看的是节点数量、Pod 数量、CPU 水位。但现在要看的是一套更立体的指标GPU 卡的使用率、显存分配率、排队任务量、有效算力产出、单次训练任务的成本。从“管容器”到“管算力”这个转变表面上只是语义变化实际影响的却是调度器、弹性策略、成本核算、可观测性等一整套体系。举一个最简单的例子。以前申请 GPU 资源写的是nvidia.com/gpu: 1意味着“你要一整张卡”。但如果平台支持显存粒度的调度你写的是aliyun.com/gpu-mem: 12意味着“我可以在这张 80G 的卡上和其他任务共享”。同样是调用一次 API底层分的是卡还是显存决定了集群资源利用率的天花板。这就是为什么我说这次升级的关键词不是“新增功能”而是“资源模型升级”。2. 从“编排容器”到“调度算力”ACK 升级到底动了哪里2.1 调度器升级让 GPU 像 CPU 一样精细化分配ACK 在 GPU 调度上做的最核心的一件事是把资源切分的粒度从“整卡”细化到了“显存/算力”。这套能力在 ACK 里落地为 GPU 共享调度加 cGPU 隔离的组合方案。简单说GPU 共享调度负责“分”cGPU 负责“隔离”。调度器可以根据任务申请的显存大小把一张物理卡切给多个 Pod 用而 cGPU 在驱动层面对每个 Pod 的显存和算力做限制防止某个任务把显存吃完导致整卡 OOM。这两个能力缺一不可——只分不隔离共享就是灾难只隔离不分又没法提高利用率。从使用角度部署一个共享 GPU 任务的 YAML 大致长这样apiVersion: apps/v1 kind: Deployment metadata: name: gpu-share-inference spec: replicas: 2 selector: matchLabels: app: gpu-share-inference template: metadata: labels: app: gpu-share-inference spec: containers: - name: inference image: registry.cn-hangzhou.aliyuncs.com/your-ns/llm-server:v1 resources: limits: aliyun.com/gpu-mem: 12注意这里用的是aliyun.com/gpu-mem而不是nvidia.com/gpu。告诉调度器这个任务只需要 12G 显存。调度器会去找一张剩余显存足够的卡把任务放上去同时用 cGPU 给它画好“显存边界”。对 AI 推理这类负载来说这个模式非常实用因为大部分小模型的显存需求只在 8G-16G 之间完全没有必要独占一张 A100。2.2 队列与配额把“谁嗓门大谁先用”变成“按优先级调度”GPU 集群最大的浪费不是“没用”而是“用了但没排好”。很多团队的现状是任务随便提交抢占靠吼优先级靠关系。ACK 这次在调度层面加入了更完整的队列调度和分层配额能力思路和传统 HPC 里的 Slurm 很像把资源放进队列队列设置优先级任务按配额和权重排队执行。这个设计对平台团队特别有价值。比如数据部门要跑日常训练算法部门要跑实验业务部门要跑推理。你可以给三个部门各划一个配额池高峰期的空闲算力可以共享但遇到资源争抢时推理任务的优先级永远高于临时实验。这套机制一旦运转起来运维排障群里关于“谁占了卡”的争吵会少一大半。值得注意的是有了队列调度后“排队”不再是贬义词。过去平台团队看到一堆 Pod Pending 就紧张总以为是调度出了问题其实在算力供不应求的智算场景里排队是正常的关键是排队信息要透明——让用户能看到自己的任务排在什么位置前面有多少任务预计还要等多久。这也是现代化应用平台应该提供的基本体验。2.3 算力与数据协同单集群里的“就近调度”思路训练和推理场景还有一个常被忽视的问题数据访问。大模型训练要读海量样本数据推理服务要加载模型权重如果数据和计算节点离得远网络带宽就成了瓶颈。ACK 在升级中强调算力与数据的协同调度目的就是让 Pod 被调度到离数据最近、带宽最充足的节点上减少训练任务等待数据的时间。实际落地时这通常需要配合缓存加速组件来实现。比如把热数据缓存到集群内部的并行文件系统训练任务读取时不再每一次都打到远端 OSS而是命中本地缓存。这个优化对训练性能的提升往往比换一块更贵的 GPU 还要明显——算力资源的利用率很大程度上取决于喂给它的数据速度。如果你是平台负责人建议在设计 ACK 集群时就把数据加速链路规划好而不是等训练任务跑得慢了再来补课。3. 弹性与成本把 GPU 账单打下来的实用配置3.1 四层弹性组合缺一不可智算场景的流量曲线有一个显著特征不稳定。大促前模型预热、白天业务高峰、夜间离线批处理不同时间段对算力的需求差异极大。如果集群按峰值容量常备资源成本根本扛不住如果按平均值配置高峰期又必然出问题。ACK 这套弹性体系其实是可以叠加的四层伸缩容器层HPA根据 CPU、内存、GPU 利用率或自定义指标扩缩容 Pod 副本数。定时层CronHPA根据业务规律在固定时间点预先扩容比如每天早上 8 点前把推理副本从 2 拉到 8。节点层Cluster AutoscalerPod 因资源不足 Pending 时自动弹出新的 ECS 节点加入集群Pod 释放后自动缩容节点。Serverless 层ECI突发的、短期的算力需求直接弹性创建 ECI Pod不占用集群节点用完即走。这里我特别想强调 CronHPA 的价值。很多团队过度依赖指标驱动扩容但指标驱动的缺点是“滞后”——等利用率上去了再扩容服务已经扛了十几分钟的顶。而大部分 AI 业务是有明显时间规律的把预测性策略和反应性策略结合起来体验会好很多。一个典型的 CronHPA 配置如下apiVersion: autoscaling.alibabacloud.com/v1 kind: CronHorizontalPodAutoscaler metadata: name: inference-cronhpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: gpu-share-inference jobs: - schedule: 0 8 * * * targetSize: 8 - schedule: 0 23 * * * targetSize: 2配置完这个策略早上 8 点系统自动把推理服务从 2 个副本撑到 8 个晚上 11 点再缩回来。业务高峰还没到算力已经提前就位了。3.2 抢占式实例与节省计划省钱的两个主力成本这块ACK 所在的计算生态里有几个非常实用的工具值得认真配置。抢占式实例的核心逻辑是用“可被回收”换“便宜”价格通常只有按量付费的 20%-30%。对 AI 推理这类无状态、支持优雅退出、可以快速重新拉起的负载特别友好。配置方式也很简单直接在节点池里设置使用抢占式实例同时设置价格上限。当 Pod 所在的抢占式节点被回收前系统会发出抢占通知应用可以做优雅退出新 Pod 会自动调度到其他可用节点。节省计划则适合那些基础算力需求稳定的场景。比如你的推理服务常年稳定占用 4 张卡与其按量付费不如买一份承诺消费的节省计划折扣力度会明显优于按量付费。我见过不少团队把抢占式实例和节省计划搭配使用基础容量用节省计划兜底弹性部分用抢占式实例冲高两种策略各司其职账单下降空间非常可观。3.3 成本可视化先知道钱花哪了才能省钱很多团队的问题是集群跑了大半年每张 GPU 卡每个月花多少钱、哪个业务线用的是大头、哪部分资源是“闲置浪费”完全是一笔糊涂账。没有成本数据支撑任何省钱动作都像蒙眼射箭。ACK 的成本分析功能可以按命名空间、按标签、按部门去看资源费用分摊。建议从一开始就给业务 Pod 打上部门、环境、应用三层标签比如teamalg、envprod、appllm-api。这样月底复盘时一眼就能看到算法部门的训练任务花了多少、测试环境的 GPU 有没有忘了关、某个闲置应用是不是白占了一块卡。我在实际项目中遇到过一个很有代表性的例子某个团队测试环境的 GPU 节点因为忘了缩容连着跑了一个月费用比生产环境还高。这其实就是成本可观测性的价值——不是你没有浪费而是你还没看见浪费在哪。4. 算力之外现代化应用平台还缺哪几块拼图4.1 微服务治理AI 应用也是微服务逃不掉流量治理这道坎聊完算力还得回到“应用平台”本身。一个现代化的应用平台不可能只顾着 GPU 调度微服务治理、可观测性、安全合规这三块拼图一个都不能少。AI 应用在架构上通常是微服务形态入口网关、鉴权服务、模型推理服务、向量数据库、Prompt 管理服务每个组件独立部署通过 API 相互调用。当服务数量多到一定程度流量治理就变成了刚需——某个推理服务出现毛刺能不能自动摘流量新版本模型上线能不能先切 10% 的流量灰度验证服务之间的超时、重试、熔断怎么配置这些能力最成熟的落地载体是服务网格。阿里云的服务网格 ASM 与 ACK 可以无缝集成不需要改业务代码在控制平面配置 VirtualService 和 DestinationRule 就能实现按权重灰度、按请求头路由、熔断限流等策略。对 AI 业务来说最实用的场景就是模型版本升级的流量灰度先让新模型接收 10% 的线上请求观察推理质量和延迟稳定后逐步把流量切到 100%有异常随时回滚。这个流程对在线推理服务的平滑演进至关重要。4.2 可观测性GPU 推理任务的排障靠的不只是日志传统微服务排障看日志三件套就够了错误日志、慢日志、调用栈。但 AI 负载的排障维度更多GPU 利用率曲线、显存水位、推理延迟分位数、排队任务数、模型加载耗时、GPU 卡温度、通信带宽。任何一个指标异常都可能导致训练中断或推理超时。所以现代化 AI 应用平台的观测体系应该是“指标 日志 链路”三位一体的。Prometheus 负责指标采集阿里云 SLS 负责日志汇聚链路追踪负责把一次用户请求从前端网关到后端推理服务的调用链串起来。三套数据打通后排障效率会完全不一样。举一个真实场景用户在线上反馈“查询变慢”如果只有单机日志排查起来就像大海捞针。但如果你能看到链路追踪数据发现瓶颈发生在模型推理服务调用这个环节再看这个服务的 GPU 利用率和显存指标发现显存已经占满导致 GPU 算力争抢问题定位就完成了。这就是可观测性对智算平台的价值——它把“看不见摸不着”的算力问题变成了可视化的图表和链路关系。4.3 安全加固镜像、权限、审计一个都不能省安全这部分很多团队在建设初期会选择性忽视直到出了事才想起来补。容器平台的安全体系至少有三层需要搭起来镜像安全镜像仓库 ACR 的镜像扫描能力可以扫描出漏洞和高危组件建议在 CI 流水线里就把扫描结果作为发布阻断项。严重漏洞的镜像禁止部署而不是等上线后再发现。权限安全ACK 的 RAM 与 RBAC 双重权限模型可以做到“一个人一个权限范围”。尽量实践最小权限原则——算法工程师只管自己的命名空间运维只管理节点和系统组件平台管理员才有集群级别的所有权限。审计安全开启集群的操作审计日志谁在什么时间改了什么配置、删了哪个资源全都留痕。这个能力平时看似没用出安全事件或者需要复盘变更时它就是唯一的线索来源。还有一个经常被忽略的细节镜像签名和验签。给官方镜像打上签名部署时校验签名能有效防止镜像被篡改后投毒。在供应链安全日益重要的背景下这个机制应该尽早用起来。5. 把一套 AI 推理服务跑上 ACK完整实操路径5.1 集群规划和节点池划分前面讲了很多原理最终还是要落到“怎么跑起来”。我以一个常见的 LLM 推理服务为例走一遍从零上 ACK 的完整路径。第一步是集群规划。我的建议是不要混部——把 CPU 节点和 GPU 节点分成不同的节点池原因很简单CPU 节点会被各种业务 Pod 占用缩容时容易因为“节点上有非 DaemonSet Pod”而缩不动GPU 节点池专门跑 GPU 负载扩缩容策略可以单独配置。节点池规划参考系统节点池2 台 4C8G跑 CoreDNS、监控采集等系统组件应用节点池按业务需要配置跑无状态 API 服务GPU 节点池按 GPU 型号规划开启自动弹性配置抢占式实例普通实例和抢占式实例建议放在不同的节点池便于控制和调度分离5.2 部署 GPU 推理服务的 YAML 要点部署推理服务时最核心的路径有两条整卡独占或显存共享。小模型推理建议走显存共享大模型推理如果需要稳定的显存和算力建议整卡独占避免和其他任务互相干扰。整卡独占的 YAML 很简单关键就一行resources: limits: nvidia.com/gpu: 1完整版apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference labels: app: llm-inference team: alg env: prod spec: replicas: 2 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference team: alg env: prod spec: nodeSelector: node-pool: gpu containers: - name: inference image: registry.cn-hangzhou.aliyuncs.com/your-ns/llm-inference:v1.2 resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8000 env: - name: MODEL_NAME value: Qwen2.5-7B-Instruct - name: MEM_FRACTION value: 0.8这里有两个实战细节nodeSelector把 Pod 固定调度到 GPU 节点池MEM_FRACTION0.8控制模型推理框架的显存使用上限避免因为框架预分配显存过大导致部署失败。如果要做显存共享把 resources 换成resources: limits: aliyun.com/gpu-mem: 16后面再配合 cGPU 插件即可。需要特别注意的是GPU 共享模式容器里要设置NVIDIA_VISIBLE_DEVICES确保容器看到的是从逻辑显存切出来的设备而不是整卡。5.3 配置弹性伸缩策略部署完成后紧接着就是配置弹性伸缩。我的推荐做法是“CronHPA 保底 HPA 应对突发”CronHPA 定义业务高峰副本数的下限比如工作日上午 8 点到 22 点维持 8 个副本。HPA 在 CronHPA 基础上根据 GPU 利用率或推理延迟指标做进一步扩缩应对流量突刺。节点池开启 Cluster Autoscaler当所有 GPU 节点率和显存都满了自动弹出新的 GPU 实例。这里容易踩一个坑HPA 和 CronHPA 如果直接叠加两个控制器会互相打架。在 ACK 里推荐使用 CronHorizontalPodAutoscaler 把定时策略和指标策略统一管理或者用 HPA 控制器自身支持的behavior字段做扩缩容行为的精细化控制。千万不要分别在控制台里各建一个 HPA 和 CronHPA 指向同一个 Deployment。服务创建好后配套创建 Service 和 Ingress。对外统一走 Ingress 网关内部服务间调用走 ClusterIP Service 或者直接启服务网格做精细化流量管理。5.4 压测与验证别上了生产才发现配置不对经验不足的团队经常忽略压测这一步直接上生产结果线上流量一来各种配置问题集中爆发。我的建议是上线前至少做一轮压测重点验证四件事性能是否达标单副本 QPS、P95 延迟在什么水位能不能满足业务要求。弹性是否灵敏把压测流量调到超过当前副本数的承受能力观察 CronHPA/HPA 是否按预期扩容节点池是否及时弹出节点。调度是否合理Pod 扩容后是否均匀分布在 GPU 节点上有没有出现多个副本挤在同一张 GPU 卡上的情况。故障恢复是否正常手动 kill 一个 Pod观察是否能自动重建并重新调度新 Pod 拉起后流量是否自动恢复。压测工具可以选择 k6、ghz 这类开源压测工具或者阿里云 PTS。压测的指标建议统一采集到 Prometheus方便后面持续观察和对比。5.5 我踩过的几个坑写出来帮你省时间最后分享几个真实踩坑记录每一个都是花了不少时间才解决的。坑一GPU 共享没开 cGPU显存泄漏导致节点不稳定。最初以为只要调度器能分配显存就行结果多个 Pod 共享一张卡后某个任务的显存使用超出边界直接把整卡打挂。后来给节点池安装并启用了 cGPU 插件容器内存和显存边界都清晰了问题消失。结论共享调度必须搭配隔离能力两者都要开。坑二Cluster Autoscaler 弹出 GPU 节点很慢甚至弹不出来。有段时间 GPU 实例库存紧张按量付费的 GPU 节点经常提示库存不足Pod 一直 Pending。后来把节点池的实例规格扩展到多个可用区并开启了“多规格优先”策略弹不出来的问题明显缓解。另外建议把抢占式实例和按量实例放在不同的节点池按量实例作为兜底免得抢占式实例被回收后服务直接没资源。坑三镜像太大冷启动拉取要十几分钟。大模型镜像经常几个 G 甚至十几个 G节点首次调度上去拉镜像就要大半天。解决办法有两个一是用 ACK 的镜像缓存能力提前把常用镜像预热到节点二是把模型权重和推理代码分离模型通过数据卷挂载而不是打进镜像。这样代码镜像只有几百兆模型文件走缓存数据卷冷启动时间从十几分钟降到两分钟以内。坑四升级节点池内核后GPU 驱动不匹配。某次对 GPU 节点做系统升级重启后驱动加载失败nvidia-smi看不到显卡集群正常但 GPU 资源不能用。排查后发现是内核版本和驱动版本不匹配。解决方式是固定节点池的系统镜像版本关闭自动升级需要升级时先在测试节点验证驱动兼容性再分批灰度。这个坑属于“平时不遇到遇到就是事故”的类型提前做好镜像版本管理非常重要。最后聊两句如果把 ACK 这次升级放到更大的背景里看它其实是整个云计算行业在智算时代集体转型的一个缩影。从分容器到分算力从管微服务到管 GPU 队列从看 CPU 水位到看成本分摊这套转变几乎是所有做云原生平台的团队都要面对的新课题。我个人在实际使用中的体会是容器平台的价值不再取决于它能跑多少 Pod而是取决于它能帮你省多少钱、提多少效、降低多少运维事故。ACK 这次升级把方向指得很明确——把算力和应用放在同一个平面上统一调度和管理。剩下的事情就是看每个团队能不能把手里的工作负载真正迁移过来并且把弹性、成本、可观测这些配套能力都用满。以上这些实操配置和经验都是我在实际项目里验证过、也踩过坑之后沉淀下来的。如果你正在规划 AI 业务上云可以参考着把节点池、GPU 共享、弹性伸缩和成本标签这几件事先搭起来再逐步完善其他能力。