在华为云上跑 AI 服务，我踩过的 5 个坑

一、先说结论

把 AI 模型从"本地跑通"搬到"云端稳定服务"，中间的距离远比想象中长。不是模型不行，而是工程侧的细节一个接一个咬人。

我在华为云 ModelArts + CCE（云容器引擎）上折腾了小半年，踩了五个印象最深的坑。写出来，希望你少熬几个夜。

坑 1：镜像能跑，但冷启动要 3 分钟

现象：服务部署完，第一次请求要等 2~3 分钟才返回，之后就正常了。

根因：模型文件 4.2GB，放在镜像里，容器启动时要把模型从镜像层加载到内存。加上 Python 依赖里 transformers 首次加载会编译 tokenizer 缓存，雪上加霜。

解法：

• 模型文件从镜像中剥离，放到 OBS 对象存储，容器启动时通过 initContainer 拉取并挂载到空目录
• 预热：在 /health 接口里加一次 dummy inference，K8s 就绪探针触发首次加载
• 最终冷启动从 180s 压到 22s

💡 经验：模型文件永远不要 bake 进镜像。镜像负责"能跑"，模型负责"跑什么"。

坑 2：GPU 显存看起来够，但推理频繁 OOM

现象：单卡 A100 40GB，nvidia-smi 显示只用 18GB，但批量推理时随机 OOM。

根因：transformers 默认开启 KV Cache，且 PyTorch 的 CUDA 内存分配器会预留但不释放。nvidia-smi 看到的是预留值，实际可用碎片比显示值小得多。

解法：

• 设置 PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 减少碎片
• 推理服务加 --max-batch-size 上限，用 Prometheus 监控 gpu_memory_used_bytes 做弹性缩容
• 关键一步：在推理代码里加 torch.cuda.empty_cache() 的定时调用（虽然官方不推荐，但在高并发场景下实测有效）

坑 3：API 网关超时，长推理被无情截断

现象：前端调用推理接口，30 秒后返回 504，但后端日志显示 45 秒才跑完。

根因：华为云 API Gateway 默认超时 30 秒，而我的模型对长文本推理需要 40~60 秒。

解法：

• 短请求（< 30s）：直接同步返回，网关超时保持默认
• 长请求：改为异步模式——调用方 POST 任务 → 返回 task_id → 前端轮询 /result/{task_id} 或走 WebSocket 推送
• 网关层对异步接口单独配置 5s 超时（只等 task_id 返回）

💡 经验：AI 推理服务的 API 设计，从第一天就按"可能有长任务"来规划。同步/异步分流，比事后改架构轻松十倍。

坑 4：日志分散在 5 个地方，排查像大海捞针

现象：一次推理结果异常，我要同时看 ModelArts 训练日志、CCE 容器日志、API Gateway 访问日志、ELB 负载均衡日志、以及自定义的业务日志。5 个控制台来回切换，头秃。

根因：各服务日志各自为政，没有统一 TraceID 串联。

解法：

• 全链路接入 LTS（日志传输服务），所有组件日志统一打到同一 log group
• 在 API 入口生成 X-Request-ID，透传到推理服务、模型加载模块、OBS 读取层
• 用 LTS 的 SQL 查询功能，一条语句跨服务关联：*| SELECT * WHERE request_id = 'xxx'
• 推理耗时、token 数、GPU 利用率全部打点进 AOM（应用运维管理），做 Grafana 面板

排查时间从"半天起步"降到"5 分钟定位"。

坑 5：自动扩缩容永远慢半拍

现象：流量高峰来了，Pod 从 2 个扩到 8 个要 3 分钟，期间大量请求排队超时。流量下去了，Pod 又缩太慢，空烧钱。

根因：默认 HPA 基于 CPU/内存指标，而 AI 推理服务的瓶颈是 GPU 利用率和请求队列长度，这两个指标默认没接入。

解法：

• 自定义指标：暴露 /metrics 端点，上报 inference_queue_length 和 gpu_utilization
• HPA 配置同时基于三个指标：
  
  
  yaml

  
  

  
  

  metrics:
  - type: Resource
    resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 }}
  - type: Pods
    pods:
      metric: { name: inference_queue_length }
      target: { type: AverageValue, averageValue: "5" }
  - type: External
    external:
      metric: { name: gpu_utilization }
      target: { type: AverageValue, averageValue: "80" }

• 缩容侧设置 stabilizationWindowSeconds: 300，避免抖动式缩容

扩容响应时间从 3 分钟压到 45 秒，缩容不再"一降就弹"。

二、写在最后

在云上跑 AI 服务，最难的从来不是模型本身，而是模型之外的那一整层工程：镜像怎么打、流量怎么接、日志怎么串、资源怎么弹。

这五个坑，每一个都让我至少熬过一个深夜。但踩完之后回头看，其实都是同一件事：

AI 服务的稳定性 = 模型能力 × 工程成熟度。

模型决定上限，工程决定下限。两个都得抓。