处理云原生 AI 应用部署：模型服务也要按普通服务治理这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

云原生 AI 应用部署：模型服务也要按普通服务治理

一、AI 应用不是 Kubernetes 特权用户

很多 AI 应用一部署就开始特殊化：镜像巨大、启动慢、内存暴涨、日志没有结构、探针随便写、资源限制不敢设。理由听起来都合理：模型要加载、推理要资源、冷启动就是慢。但生产环境不吃理由。模型服务也是服务，必须被治理。

云原生 AI 应用部署的第一原则，是把模型当成普通服务先管起来：健康检查、资源限制、滚动发布、日志指标、灰度回滚，一个都不能少。特殊能力可以有，特殊待遇不能无限开。

二、部署链路：从镜像到可观测

flowchart LRA[模型与代码] --> B[构建镜像]B --> C[部署到 K8s]C --> D[探针与资源限制]D --> E[流量灰度]E --> F[指标与告警]

这条链路里最容易偷懒的是探针。AI 服务的 readiness 不能只看端口开没开，要看模型是否加载完成、依赖是否可用、预热是否结束。否则刚启动就接流量，第一波请求会直接变成事故。

三、Deployment 示例：资源和探针别省

apiVersion: apps/v1kind: Deploymentmetadata:name: ai-inferspec:replicas: 2template:spec:containers:- name: serverimage: registry.example.com/ai-infer:20260702resources:requests:cpu: "2"memory: 8Gilimits:cpu: "4"memory: 16GireadinessProbe:httpGet:path: /readyport: 8080initialDelaySeconds: 20periodSeconds: 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 应用部署，先按普通服务治理：资源、探针、灰度、日志和指标做扎实。模型服务可以特殊优化，但不能逃离生产规则。