给CV项目套上K8s之后我半夜被报警吵醒这件事

做了三年大数据开发，天天跟Spark和Yarn打交道，没想到会去碰计算机视觉。上周二凌晨一点半，钉钉突然弹了十几条告警，全是GPU节点的OOM。

起因是部门接了个质检线CV项目：产线摄像头拍零件，模型实时判断划痕毛刺，一天几十万张图。领导拍板用K8s编排推理服务，顺便把标注平台容器化。

模型侧用的是YOLOv8变体，在DeepSeek服务器上做数据清洗和预标注。DeepSeek的API做图像理解确实省事，写脚本把历史图片丢给它做初步标注，人工只需复核修正，效率翻倍。但坑也有：输出格式偶尔不稳定，有一批返回JSON里坐标字段名变了，解析脚本崩了三次，后来加了字段兼容层才稳住。

K8s这边才是重灾区。推理服务要调GPU，刚开始用裸Pod加hostPath挂载模型文件，Pod一重启模型就丢了。改成PVC挂载CephFS，2GB模型加载要七八分钟。最后折中用initContainer从对象存储拉模型到emptyDir，medium设成Memory，加载压到一分钟以内，但内存占用上去了。

那个半夜告警就是这么来的：GPU节点上同时跑六个推理Pod，每个内存上限16Gi，YOLO推理时显存和内存峰值错开，HPA还在疯狂扩容，节点直接被打爆。赶到公司第一件事kubectl top nodes，内存使用率98%。

后面做了三件事才稳住：

1. 给推理服务加内存上限和requests，绝不允许超卖；
2. HPA从基于CPU改成基于自定义指标，用Prometheus采集推理队列深度做扩缩容依据；
3. 模型推理从同步HTTP改成异步队列，图片先进Redis，结果写回对象存储，客户端轮询拿结果。

这套下来，节点内存使用率稳定在70%左右，再没半夜报警过。

标注平台那边，标注员以前用本地Excel记录修正意见，来回传文件效率极低。我用GPT Image做了个辅助工具，把标注截图和修正意见自动生成对比报告，推送到企业微信。上线后标注团队的PM第一次没在周会上吐槽我们开发。

现在回头想，CV项目跟大数据最大的区别：数据是流式的，反馈链路短，出问题立刻能发现。Spark任务跑挂了第二天看日志都行，CV推理服务挂了，产线直接停线，压力完全不是一个量级。

最后说点心得。K8s管GPU推理不是不行，但一定要把资源边界卡死，别指望它像CPU那样随便超卖。能异步就异步，同步HTTP在推理场景里就是给自己挖坑。还有，半夜的告警电话，能免则免。