云原生 AI 应用部署模型服务也要按普通服务治理一、AI 应用不是 Kubernetes 特权用户很多 AI 应用一部署就开始特殊化镜像巨大、启动慢、内存暴涨、日志没有结构、探针随便写、资源限制不敢设。理由听起来都合理模型要加载、推理要资源、冷启动就是慢。但生产环境不吃理由。模型服务也是服务必须被治理。云原生 AI 应用部署的第一原则是把模型当成普通服务先管起来健康检查、资源限制、滚动发布、日志指标、灰度回滚一个都不能少。特殊能力可以有特殊待遇不能无限开。二、部署链路从镜像到可观测flowchart LR A[模型与代码] -- B[构建镜像] B -- C[部署到 K8s] C -- D[探针与资源限制] D -- E[流量灰度] E -- F[指标与告警]这条链路里最容易偷懒的是探针。AI 服务的 readiness 不能只看端口开没开要看模型是否加载完成、依赖是否可用、预热是否结束。否则刚启动就接流量第一波请求会直接变成事故。三、Deployment 示例资源和探针别省apiVersion: apps/v1 kind: Deployment metadata: name: ai-infer spec: replicas: 2 template: spec: containers: - name: server image: registry.example.com/ai-infer:20260702 resources: requests: cpu: 2 memory: 8Gi limits: cpu: 4 memory: 16Gi readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 20 periodSeconds: 5资源限制不是摆设。没有 requests调度器不知道该把 Pod 放哪没有 limits异常请求可能拖垮节点。AI 服务更要讲资源边界因为它消耗通常比普通后端更狠。四、工程边界冷启动要被产品知道AI 服务启动慢不只是运维问题也是产品问题。扩容后多久可用发布时是否会抖低峰缩容后首个用户是否等待这些都会影响体验。团队要把冷启动写进容量策略保留热副本、预拉镜像、提前加载模型、灰度观察指标。取舍方面热副本成本高但延迟稳定缩到很低省钱但冷启动伤体验。不同业务要不同策略。内部批处理可以省在线交互就别太抠。云原生不是只会省资源它也要保护体验。还要把模型版本纳入发布记录。镜像版本、模型权重、Prompt 模板、运行时参数都可能影响输出。一次质量波动不能只查代码 commit。AI 应用的发布对象比普通服务更多治理也要更细。日志也要结构化。至少记录 request_id、model_version、prompt_version、input_tokens、output_tokens、latency_ms、error_type。不要把用户原文全量打进日志但关键元数据必须有。否则线上延迟升高或成本暴涨时团队根本不知道是模型变慢、Prompt 变长还是请求量变了。还要给推理服务设置优雅关闭。Pod 被滚动更新时应先停止接新流量等待当前推理完成或超时再退出。AI 请求可能比普通接口更长直接杀进程会让用户看到半截回答。云原生部署不是只写 YAML也要让应用配合生命周期。五、总结云原生 AI 应用部署先按普通服务治理资源、探针、灰度、日志和指标做扎实。模型服务可以特殊优化但不能逃离生产规则。