企业官网建设流程全解析

模型服务十大坑：从 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端点区分"进程存活"和"模型就绪"。

坑 3：GPU 显存碎片——重启才有效

推理服务长时间运行后，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 的结果不同。原因有三：

1. 浮点精度差异：不同 GPU 架构（A100 vs H100）的浮点计算精度不同。
2. CUDA 版本差异：不同 CUDA 版本的内核实现不同。
3. 随机种子未固定：模型内部有 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。

解法：监控四组指标：

三、避坑全景图

四、总结：模型服务运维的核心原则

1. 内存管理优先：显存比 CPU 内存更难管理，并发控制是第一道防线。
2. 冷启动要专门处理：不要用默认健康检查配置，按模型加载时间定制。
3. 结果一致性要验证：模型不报错不代表结果正确，回归测试必须自动化。
4. 排队和拒绝要配合：有队列就有拒绝策略，否则排队会变成雪崩。
5. 监控维度要全覆盖：资源利用率只是其中一个维度，延迟、质量、排队同样重要。

踩坑不是丢人，踩了同样的坑两次才丢人。把这份清单贴到值班室的墙上，比什么方法论都管用。

基础设施不需要漂亮话，能稳定跑比什么都重要。