模型服务十大坑：从 OOM 到推理结果漂移

模型服务十大坑从 OOM 到推理结果漂移基础设施不需要漂亮话。模型服务上线那天团队觉得终于可以松口气了。实际上上线才是问题的开始。过去半年我们在模型服务运维上踩了至少十个坑每一个都让值班工程师在凌晨被叫醒。这篇文章把这些坑列出来不是吓唬人是让你提前知道哪里有雷。一、背景模型服务的运维难度为什么比普通服务高模型服务和普通微服务的核心区别在于它同时消耗大量计算资源、有不可预测的内存行为、且输出结果本身可能出问题而不报错。普通服务 OOM 的时候进程直接崩溃监控立刻告警。模型服务 OOM 之后可能进入一种半死状态进程还在但推理已经开始返回乱码。这种隐性故障比显性故障更危险。二、十大坑逐一拆解坑 1推理服务 OOM——不是模型太大是并发太高模型权重占的内存是固定的真正把内存撑爆的是并发请求的中间状态。每个推理请求都会产生 KV Cache请求越多、上下文越长KV Cache 占的内存越大。实测数据一个 7B 模型在单 GPU 上权重占 14GB但 50 个并发请求的 KV Cache 就能额外吃掉 8GB。如果 GPU 总显存 24GB看起来够用但加上框架开销和 CUDA 内核缓存实际可用只有 20GB 左右。解法设置最大并发数限制超过限制的请求排队而不是直接进推理。用 Continuous Batching 管理活跃请求完成一个请求立即释放其 KV Cache。坑 2模型加载超时——冷启动比想象中慢模型权重从磁盘加载到 GPU 显存7B 模型需要 3-5 秒70B 模型需要 30-60 秒。如果加上初始化和预热推理冷启动时间还要再加 10-20 秒。Kubernetes 默认的健康检查超时是 1-3 秒。模型服务还没加载完就被 K8s 杀掉重启进入无限重启循环。解法把 startupProbe 的initialDelaySeconds设为模型加载时间的 2 倍periodSeconds设为 5 秒以上。不要用 readinessProbe 来检测模型加载状态用专门的/health/ready端点区分进程存活和模型就绪。坑 3GPU 显存碎片——重启才有效推理服务长时间运行后GPU 显存会出现碎片化。现象是显存总量显示还剩 6GB但新请求分配 2GB 的 KV Cache 时报 OOM。这是因为 CUDA 的内存分配器在反复分配和释放后产生了碎片虽然总量够用但没有连续的 2GB 空间。解法定期每 6-12 小时做一次优雅重启利用 Kubernetes 的 Pod 滚动更新机制。在低峰期执行用 preStop hook 等待当前请求完成再退出。坑 4动态 Batching 死锁——请求互相等动态 Batching 的原理是把多个请求合并成一个 Batch 一起推理提高 GPU 利用率。但如果等待时间设置不合理可能出现新请求一直在等凑 Batch旧请求的超时时间已经到了结果所有请求都超时失败。解法设两个参数——最大等待时间max_wait_time和最大 Batch 大小max_batch_size。先到先凑凑到最大 Batch 就推理凑不到就等最大等待时间。不要只设一个条件。坑 5推理结果漂移——模型没变结果变了这是最隐蔽的坑。模型权重完全一样硬件环境也一样但两次推理同一个 Prompt 的结果不同。原因有三浮点精度差异不同 GPU 架构A100 vs H100的浮点计算精度不同。CUDA 版本差异不同 CUDA 版本的内核实现不同。随机种子未固定模型内部有 Dropout 和采样随机性。解法生产环境固定 CUDA 版本、固定随机种子、做推理结果回归测试。每次模型部署前用标准测试集跑一轮推理输出结果和基准对比差异超过阈值就阻断上线。坑 6预处理不一致——训练和推理的数据处理不一样训练时做了一次标准化推理时忘了做或者做了但参数不一样。比如训练时图片 resize 到 224x224推理时 resize 到 256x256。模型不会报错但输出精度会悄悄下降。解法预处理逻辑和模型权重绑定发布放在同一个 Docker 镜像里。推理服务的预处理代码要从训练代码仓库直接复制不要手写一遍。坑 7流式响应断连——客户端以为结束了LLM 推理常用 SSE 流式输出。但网络中间层nginx、CDN可能有超时设置推理如果超过 30 秒还没完成中间层直接断开连接。客户端收到一个不完整的响应以为模型出问题了。解法确认从客户端到推理服务全链路的超时设置nginx 的proxy_read_timeout至少设为 120 秒。SSE 流中定期发送心跳注释: keepalive\n\n防止中间层误判为连接空闲。坑 8模型版本回滚失败——权重文件太大Kubernetes 的滚动回滚速度取决于镜像拉取速度。模型服务的镜像动辄 10-50GB回滚一次要等 5-10 分钟拉取旧版本镜像。如果当前版本已经出了严重问题5 分钟的回滚时间意味着持续故障。解法把模型权重和推理框架分开。框架镜像 1GB权重用 PVC 或对象存储挂载。回滚只需要切换权重目录的软链接秒级完成。坑 9请求排队雪崩——限流不是拒绝推理服务在高峰期排队是正常的。但如果排队策略不对可能出现雪崩排队请求越来越多每个请求的等待时间越来越长客户端超时重试又增加更多请求。解法排队要有两个限制——最大队列长度和最大等待时间。超过队列长度直接拒绝返回 429超过等待时间也拒绝。宁可拒绝一部分请求也不要让所有请求都等到超时。坑 10监控盲区——只看 GPU 利用率不够GPU 利用率 100% 不代表服务健康。可能模型在疯狂推理但输出全是乱码也可能所有请求都在排队等待凑 Batch。解法监控四组指标指标组具体指标告警阈值性能推理延迟 P50/P99P99 2s质量推理成功率 95%资源GPU 显存使用率 85%排队队列深度和等待时间深度 50 或等待 10s三、避坑全景图四、总结模型服务运维的核心原则内存管理优先显存比 CPU 内存更难管理并发控制是第一道防线。冷启动要专门处理不要用默认健康检查配置按模型加载时间定制。结果一致性要验证模型不报错不代表结果正确回归测试必须自动化。排队和拒绝要配合有队列就有拒绝策略否则排队会变成雪崩。监控维度要全覆盖资源利用率只是其中一个维度延迟、质量、排队同样重要。踩坑不是丢人踩了同样的坑两次才丢人。把这份清单贴到值班室的墙上比什么方法论都管用。基础设施不需要漂亮话能稳定跑比什么都重要。