最近机缘巧合、莫名其妙，玩起了 GPU 的东西。算法同学要求又高，裸跑 GPU 是不可能的，要 K8s。被逼只好开始研究这个高级东西，断断续续前前后后历时半年的样子，掌握了个大概。今天整理下下。

Device Plugin

K8s 的设计真的太美了，插件化 + Informer 简直就是完美的设计。只要兼容 API 接口协议，理论上均可接入 K8s 中（不推荐大家因为轮子而去造轮子，社区 & 默认的组件已经可以覆盖很多公司的需求了）

Kubernetes provides a device plugin framework that you can use to advertise system hardware resources to the Kubelet. Instead of customizing the code for Kubernetes itself, vendors can implement a device plugin that you deploy either manually or as a DaemonSet .

device plugin 确实可以帮助插入很多设备，但是对于 GPU 来说仅仅是是 K8s 可以识别设备，并完成如下两件核心的事情

• 资源启动上报 & 监控
• 支持 Pod 的调度

如上显而易见的优势明显，再没有复杂的驱动安装，资源浪费等问题，全部基于 K8s 的管理 & 调度统一解决了这些问题，算法工程师 or 算法科学家 跑 Job 即可。

Device Plugin 是否完美无缺

• GPU 资源的调度工作，实际上都是在 kubelet 上完成的
• 只能处理 GPU 数量
• 根据整个集群的设备进行全局调度
• Allocate 和 ListAndWatch 的 API 去增加可扩展的参数无效

是否需要 GPU 切分使用、简单性能提升

• 其实如果业务使用，适当切分确实可以提升资源利用率，但是带来的性能是否会跌，就有待考证了
• 多卡并行使用，这个东西拉，需要算法工程师调整 Code & 使用姿势的
• 显存为优化的根本，不管是推理还是训练，显存越大能装载的数据越多，对于单位时间里面可以完成的任务明显就是越多，最最最简单的方案，扩显存、调步长瞬间肉眼可见的效率提升

工具推荐

• 国货 Arena
• 德国 Riseml（公司已经不存在了），也是可惜
• 过于复杂的 kubeflow

参考文献

• Device Manager Proposal
• Kubernetes GPU管理与Device Plugin机制
• Device 插件
• 设备插件

写在最后

• 工具有些事情可以做做
• 调度方案太多，用好默认的再去思考使用谁家的
• 单卡、多卡、虚拟化可以弄的
• 数据加载可以优化
• 云上的话，Spot 用起来