有没有干净的方法定义跨GPU厂商、无需厂商配置的AI工作负载?
摘要
开发者探索如何将GPU工作负载抽象化,使其无需厂商专属配置即可在多家GPU供应商间运行,倾向于将工作负载定义与基础设施绑定解耦。
这个问题我思考已久,目前找到的解决方案要么只解决局部,要么引入额外复杂度。具体问题:我们希望GPU工作负载能在多家供应商之间运行,以保证可用性和成本优化,但为每个工作负载维护厂商专属部署配置不可持续。当某家供应商出现可用性问题或价格变动时,我们希望无缝迁移工作负载,而不是启动一个工程项目。
我调研过的方案:
- **K8s 多厂商节点池**:可行,但厂商专属配置藏在调度逻辑和GPU驱动安装里。所谓“可移植”实际意味着“每家厂商都要大幅改动”。GPU故障恢复也需要大量自定义逻辑,最终仍与厂商绑定。
- **Terraform**:解决了基础设施的可移植,却解决不了工作负载调度的可移植。你可以用Terraform在多家厂商开出节点,但仍需告诉每个工作负载去哪儿运行。
- **自定义抽象层**:我们自己写了一套,直到某家厂商改API就崩了。维护成本滚雪球。
从读到的资料看,真正可行的模式是:**把工作负载定义与基础设施绑定完全分离**,由调度层负责匹配。只声明工作负载需要什么,而非指定在哪运行;让调度器根据可用硬件决定放置位置。
好奇有没有人真落地过这套做法,实际运维长什么样?
相似文章
云GPU提供商将成为代理基础设施吗?
作者推测云GPU提供商是否将成为AI代理的底层基础设施,将其与电信行业的演变进行类比,并质疑市场整合。
使用云托管GPU运行AI
关于使用云托管GPU运行AI模型的文章,涵盖部署选项和注意事项。
如何实现真正的无服务器GPU(20分钟阅读)
Modal介绍了他们开发的四个关键要素,可在几秒而非几分钟内启动无服务器GPU推理副本,从而实现对多变AI工作负载的高效GPU分配。
针对短时LLM运行的云GPU存储费用高昂。你的工作流程是怎样的?
用户寻求针对短时LLM测试会话的成本效益云GPU工作流程建议,强调在运行之间保留环境时存储费用是主要痛点。
人们如何让OpenClaw/Hermes代理24/7运行而不耗尽API预算?
一位从业者寻求建议,希望在不产生高额API成本的情况下让AI代理24/7运行,询问本地模型、云GPU或托管API,并希望获得兼顾可靠性和推理质量的成本效益方案。