机器学习推理成本减少45%!Ray+Karpenter 在科技初创公司的落地实践
Vannevar Labs 是一家专注于国防技术的初创公司,成功利用 Ray 和 Karpenter 在 Amazon EKS 上,将机器学习(ML)推理成本削减了45%。该公司致力于开发先进的软件和硬件,以支持包括海上监视、虚假信息干扰以及非传统情报收集在内的各种国防任务。
Vannevar Labs 通过机器学习技术处理来自数据接收系统的信息,并执行搜索和摘要等用户驱动的任务。凭借一系列多样化的模型,包括微调的开源模型和自主训练的模型,该公司启动了一项优化机器学习推理工作负载的任务。这项优化旨在提升其机器学习基础设施的部署速度、可扩展性和成本效率。
本文将探讨 Vannevar Labs 在使用 Amazon EKS、Ray 和 Karpenter 时采取的方法、面临的挑战以及实施的解决方案,这些措施不仅使成本降低了45%,还显著提升了性能。
01/ 整体情况
在 Vannevar Labs,实施了一项全面的优化策略,以解决机器学习模型部署和性能方面的一些关键挑战。通过采用 Ray Serve 实现标准化的模型服务,使用 Karpenter 进行灵活的实例选择,并引入 Fractional GPU 技术,显著提升了系统的可扩展性、弹性和资源利用率。
此外,Vannevar Labs 将单一的大型集群拆分为针对特定模型的专用集群,从而提高了部署效率。为确保最佳性能,还构建了一个强大的监控系统,使用 Prometheus、Grafana 和 Sentry 进行实时监控。同时,还利用 Istio 实现了高级流量管理,帮助 Vannevar Labs 实现平滑过渡和负载测试。
最终达成以下改进结果:
1.部署时间减少:从 3 小时缩短至 6 分钟。
2.可扩展性提升:部分 worker 组可在短至 2 分钟内完成扩容。
3.弹性增强:worker 组更频繁地缩容,在需求低谷期显著节约成本。
4.整体成本降低:推理成本减少 45%。
5.资源利用率提高:当 GPU 容量未充分利用时,将 CPU 工作负载运 行在 GPU 型 EC2 实例上,提升了整体 EKS 集群的利用率。
6.流量管理优化:通过 Istio 改进了流量路由和负载测试能力。
02/采用 Ray Serve 实现标准化推理
Ray Serve 是一个可扩展的模型服务库,用于构建在线推理 API。Vannevar Labs 选择使用 Ray Serve 来标准化机器学习推理流程,为处理推理请求提供更结构化和高效的方法。通过 KubeRay 在 Amazon EKS 上部署了 Ray 集群。
将 Ray Serve 部署在 Kubernetes 上,结合了 Ray Serve 的可扩展计算能力与 Kubernetes 的运维优势。有关在 Kubernetes 上实现 Ray Serve 的更多信息,请参阅:
https://docs.ray.io/en/latest/serve/production-guide/kubernetes.html
优化实例选择:采用 Karpenter
在初始实施阶段,Vannevar Labs 为每种类型的模型创建了独立的 Karpenter 节点池(NodePool)。每个节点池仅限于一些针对特定使用场景优化的 Amazon EC2 实例类型。还使用污点(Taints)和容忍(Tolerations)机制将模型分配到不同的节点池。
例如,CPU 密集型模型运行在容忍 CPU 节点池的 Pod 中,该节点池只部署 C5 EC2 实例,而不使用基于 GPU 的 EC2 实例。
经过测试后,Vannevar Labs 决定采用单一节点池策略,放弃了使用污点和容忍机制调度 Pod 的方法。相反,选择提供准确且全面的信息给 Ray、Kubernetes 和 Karpenter 调度器,让它们有能力优化 EKS 集群的计算效率和成本效益。
例如,对于需要 GPU 的 Pod,Vannevar Labs 实施了节点亲和性(Node Affinity)策略,以确保正确的 GPU 类型可用。
在嵌入模型的 Pod 配置中,Vannevar Labs 为一个知名标签(Well-Known Label)添加了节点亲和性,以指定 GPU 的名称,如下所示,并允许 Karpenter 自动配置适合的 EC2 实例大小。
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: karpenter.k8s.aws/instance-gpu-name operator: In values: - t4
对于仅需 CPU 的 Pod,Vannevar Labs 明确指定不需要 GPU,从而允许 Kubernetes 将这些 Pod 调度到已部署但 GPU 使用率较低的节点上,而无需授予它们对 GPU 的访问权限。
这种方法使其能够在已有的 GPU 型 EC2 实例上运行 CPU 密集型任务,从而最大化资源利用率,同时减少所需的 EC2 实例数量。
resources: limits: nvidia.com/gpu: "0"
CloudPilot AI (www.cloudpilot.ai )在 Karpenter 的基础上对节点选择功能进行智能化升级。在选取实例的过程中,除了价格因素外,还将网络带宽、磁盘 I/O、芯片类型等因素纳入考虑范围内,通过智能算法选出兼顾成本和性能的实例类型,以减少资源浪费,增强应用稳定性。
使用 Fractional GPU
一个关键的优化措施是在 Ray 中引入 Fractional GPU。通过仔细分析使用模式,Vannevar Labs 能够将多个 Ray actor 和任务打包到 Kubernetes Pod 中,从而显著提高 GPU 的利用率。
嵌入模型会根据输入文本计算对应的向量。Vannevar Labs 使用 Fractional GPU 来运行该模型,而上一代 NVIDIA T4 GPU 的性能已足以满足其需求。
cpus: 1.0 gpus: 0.2 memory: 2Gi minReplicas: 1 maxReplicas: 80 gpuType: "t4" }
优化 Pod 调度与 GPU 使用
为了应对性能和成本挑战,Vannevar Labs 将三个模型从基于 CPU 的推理迁移到基于 GPU 的推理。这一转变显著提升了推理速度和资源效率,将延迟降低了最多 100 倍,同时将所需副本数量减少了 20-50 倍。尽管 GPU 型 EC2 实例的单价较高,但由于所需的 EC2 实例数量减少,整体成本反而降低了。
在模型迁移至 GPU 运行的初期,团队遇到了许多问题,包括内存错误、多 GPU 型 EC2 实例的使用不足,以及整体 GPU 利用率较低。
以下 Kubernetes 节点资源已通过 NVIDIA 的 Kubernetes 设备插件注释为扩展资源。
这使 Vannevar Labs 能够在请求资源时同时指定 CPU 和内存,并依赖 Kubernetes 调度器将 Pod 分配到具有可用 GPU 的节点上。该方法还为 Pod 提供对特定 GPU 的独占访问权限。
Karpenter 同样依赖类似的机制,当有需要 GPU 的待调度 Pod 时,它会自动启动基于 GPU 的 EC2 实例。
kind: Node metadata: labels: karpenter.k8s.aws/instance-gpu-count: '8' karpenter.k8s.aws/instance-gpu-manufacturer: nvidia karpenter.k8s.aws/instance-gpu-memory: '16384' karpenter.k8s.aws/instance-gpu-name: t4 karpenter.sh/capacity-type: on-demand kubernetes.io/arch: amd64 kubernetes.io/os: linux node.kubernetes.io/instance-type: g4dn.metal status: allocatable: cpu: 95690m ephemeral-storage: '246305030964' hugepages-1Gi: '0' hugepages-2Mi: '0' memory: 387183588Ki nvidia.com/gpu: '8' pods: '737' capacity: cpu: '96' ephemeral-storage: 268423148Ki hugepages-1Gi: '0' hugepages-2Mi: '0' memory: 395848676Ki nvidia.com/gpu: '8' pods: '737'
使用 Fractional GPU
在新部署基础设施的支持下,Vannevar Labs 开始为每个模型创建专用的 EKS 集群。这包括为每个模型创建定制化的 Docker 镜像,而不是使用一个大型的 all-in-one 镜像。
专属镜像的大小从 2 GB 到 12 GB 不等,相较于之前的 25 GB all-in-one 镜像,这一调整显著缩短了 Pod 的启动时间,并带来了可观的成本节省,根据镜像大小不同,加载时间减少了 50% 到 90%。
使用专用镜像的一个关键优势是降低了网络 ingress 成本。此前的 all-in-one 镜像并未包含模型权重或 Python 包,因此 Ray 在容器初始化期间需要从外部下载这些内容。虽然模型权重大多存储在 Amazon S3 上,主要影响加载时间,但 Python 包的下载对成本影响更大。
每次新的 Ray 工作节点启动时,都会通过 pip 安装所需的 Python 环境,导致从 PyPI 大量下载数据,网络 ingress 流量费用占了月度 AWS 账单的主要部分。
专用镜像包含了模型权重和所需的 Python 环境,从而无需在容器初始化期间从公网下载内容。这大幅减少了网络 ingress 流量及其相关成本。
实施全面监控
Vannevar Labs 建立了一套监控系统,用于确保性能评估和资源分配的准确性。Grafana 仪表板会自动为每个 EKS 集群配置,提供监控和告警功能。这些仪表板包括用于可视化 CPU 和内存使用情况的面板,能够帮助其准确确定资源需求。
Vannevar Labs 将资源限制设置为略高于观测到的最大值,并新增了一个面板,用于跟踪因内存使用过高而被 Ray 删除的 actor 事件。
此外,还在模型代码中加入了监控功能,将 500 状态码和未捕获的错误报告到 Sentry。这些措施可以在资源约束不足时及时发出警报,从而能够针对每个模型进一步优化资源分配。
这样的监控方式不仅确保了良好的性能,还避免了资源过度分配,提高了整体效率。
模型在24小时内的CPU使用率
模型 24 小时内的内存使用量
CloudPilot AI (www.cloudpilot.ai )通过机器学习算法可以预测超过7500个实例的中断事件,并且提前 120 分钟通知用户。并且还能将相应的应用自动迁移到更稳定的实例上。保障服务稳定性,同时解放运维团队的时间。
目前 CloudPilot AI 已开放30天免费试用,复制上方地址至浏览器即可尝鲜
使用 Istio 增强流量管理
Vannevar Labs 通过 Istio 的虚拟服务(Virtual Service)将推理请求路由到新的 Ray 集群。尽管 Vannevar Labs 将单一的 Ray 集群拆分为针对每个模型的独立集群,虚拟服务提供了一个统一的网关,使客户端的迁移过程更加简单。
此外,还配置了流量管理,使请求可以同时发送到现有的 EKS 集群,并镜像到实验性 EKS 集群进行负载测试。这种流量管理策略既保证了现有系统的稳定运行,又为测试新集群性能提供了支持。
03/结论
通过使用 Amazon EKS、Ray、Karpenter 和 Istio,Vannevar Labs 极大地改进了机器学习推理基础设施,将部署时间从 3 小时缩短到仅 6 分钟,大幅提升了应对需求激增的能力,同时推理成本降低了 45%。
Vannevar Labs 的下一步计划包括通过与 Ray 项目团队合作,进一步增强与 Kubernetes 的集成,透明地向 Kubernetes 暴露扩容数据。此外,还计划围绕 Mountpoint for Amazon S3 和其他存储相关的改进进行第二轮优化,以进一步提升性能并降低成本。
本案例展示了结合 Amazon EKS、Ray、Karpenter 和 Istio 等现代云技术优化机器学习推理工作负载的强大能力。通过仔细分析需求、使用合适的工具并持续优化解决方案设置,企业可以在部署速度、可扩展性和成本效率方面实现显著改进。
推荐阅读
posted on 2025-01-15 15:35 CloudPilotAI 阅读(25) 评论(0) 编辑 收藏 举报
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek-R1本地部署如何选择适合你的版本?看这里
· 传国玉玺易主,ai.com竟然跳转到国产AI
· 揭秘 Sdcb Chats 如何解析 DeepSeek-R1 思维链
· 自己如何在本地电脑从零搭建DeepSeek!手把手教学,快来看看! (建议收藏)
· 我们是如何解决abp身上的几个痛点