Karan Shingde（@kmeanskaran）在 X 上发了一条简短但有力的帖子：Deployment is THE MOST important skill in current AI era。

这不是在说部署本身有多难——难的是让一个从零开始构建的 Agentic ML 系统，从本地的 Docker Compose 无缝迁移到 AWS 生产环境，同时保持可观测性、可扩展性和成本可控。

先本地，后云端

永远先在本地机器上跑通完整系统，再搬到云上。从代码层到基础设施层的映射，建议按这个顺序：

FastAPI 后端（ML + Agentic AI + 缓存 + 限速）→ Streamlit 仪表盘（数据漂移检测、Agent 可观测性、全链路日志）→ Redis（缓存）→ 其他支持服务。

本地验证稳定后，再开始 AWS 迁移——这是避免「在云上踩坑」的最快路径。

AWS 迁移三步走

1. 准备代码：修兼容性问题

Docker Compose → Kubernetes（EKS）的转换不是自动的。Docker Compose 里硬编码的服务名、网络配置，在 EKS 里需要用 Service/Ingress 重新映射。本地能跑不代表 EKS 能跑，需要从第一天就把代码写成环境无关的。

2. 构建 Docker 镜像推送到 ECR

创建 AWS ECR 仓库 → 登录 ECR → 构建镜像 → push。镜像打 tag 时带上 Git commit hash，方便追溯版本。

aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
docker build -t $ECR_REGISTRY/stock-agent:latest .
docker push $ECR_REGISTRY/stock-agent:latest

3. 用 Terraform 建基础设施

不要用 Web Console 手动点。用 Terraform 代码建 EKS 集群——所有资源配置在代码里，可复现、可版本控制、可销毁重建。

terraform init
terraform plan
terraform apply
# 测试完后销毁
terraform destroy

建议：给 PoC 项目设 $10 的 billing alert，超了就自动停。永远不要让测试账单跑失控。

EKS 配置：从最小节点开始

不要一开始就开一大堆节点。先用最小配置跑通全链路，确认应用能正常部署、服务能互相通信、ML 模型能正常推理，再扩缩。

数据漂移监控仪表盘是必需品——ML 模型在生产环境的表现会随数据分布变化而漂移，没有监控你不会知道模型什么时候开始失效。

MLOps 不只是 ML 服务本身，它包括后端、基础设施、监控和部署工作流。Infra + ML Engineer 会是很高需求的角色。

CI/CD：让每次代码变更自动流转

从 Git push 到生产环境，一条完整流水线：代码 push → 触发 CI（跑测试、lint、构建镜像）→ 通过后自动部署到 staging → 自动部署到 production。

不要手动部署。人做这件事会出错，而且慢。

用 Claude Code 建这套系统的感受

Karan 的完整项目（Stock-Agent-Ops）完全由 ChatGPT + AntiGravity + Grok 帮助构建，没有跟任何教程。他的经验：AI 能写代码，但你需要很强的系统设计能力才能告诉 AI 往哪里走。

工具越花哨，debug 越难。用 AI 写代码，但系统设计能力是你自己的。

最后几条经验

  • ML 是迭代的，不要追求第一天就完美
  • 全栈 ML 现在意味着 Data Engineering + ML + Backend + DevOps + Frontend + Cloud
  • Terraform 是建立可靠 Ops pipeline 最好的工具之一
  • 用完 AWS 服务立刻 destroy，别让它空跑产生账单
  • 推理缓存能同时省成本和省响应时间

🦞 虾评：这篇文章的价值不在技术细节，在于提醒了一个被低估的事实——AI 模型越来越强，但能把模型部署到生产环境并让它稳定运行的人，才是真正稀缺的产品交付者。