把开源 AI 基础设施扔进生产环境，比写 Demo 难上十倍

很多团队在做 AI 产品时，最容易掉进的坑就是把“跑通了 Demo”等同于“具备生产能力”。在本地用个 Python 脚本加载模型，和在生产环境下支撑高并发请求，中间隔着一座由运维、监控和成本控制组成的深山。

我目前在生产环境跑的一套组合是：推理层采用 vLLM 搭配 Triton，编排交给 K8s 和 KubeFlow，向量数据库用 Milvus，可观测性则依赖 Prometheus 和 Grafana 组合，数据管道由 Airflow 支撑。这套方案的逻辑在于每一个组件在社区中都有极高的活跃度，出问题时能快速找到解决方案。但代价显而易见：每个组件都像个“大爷”，需要单独地伺候和调优。

在实际运维过程中，我总结出一个核心原则：核心负载必须自控，边缘场景果断托管。以向量搜索为例，自建 Milvus 集群的维护成本极高，如果业务量没有达到某个量级，直接使用 Pinecone 或 Zilliz 这种托管服务能省掉大量时间。但推理服务不同，它直接决定了产品的用户体验。vLLM 的调度参数、Continuous Batching 的具体配置，这些细粒度的优化是任何托管服务都无法提供的，必须自己掌控才能压榨出 GPU 的极限性能。

回顾之前的踩坑经历，我建议大家避开两种陷阱。第一类是过度抽象的“全栈 AI 平台”，这类平台虽然上手快，但一旦出现性能瓶颈或诡异报错，由于屏蔽了底层细节，你根本无法定位问题。第二类是过于小众的基础设施工具，比如我之前尝试自建 Feature Store，结果在数据量激增后运维成本爆炸，最后不得不回归到最原始的 PostgreSQL + Redis 组合。教训就是：在生产环境下，基础设施的选型标准应该是“无聊、稳定、文档齐全”，而不是看 GitHub 上的 Star 数。

当项目从原型阶段进入生产阶段后，有三类问题会接踵而至，且极其痛苦。

首先是模型版本管理。在 Demo 阶段，加载一个权重文件就完事了。但在生产环境中，你需要构建一套完整的模型注册、灰度发布和快速回滚机制。一旦新版本模型在特定场景下出现幻觉或性能退化，如果没有成熟的灰度方案，整个业务线都会被拖垮。

其次是可观测性的维度升级。在开发阶段，我们习惯于看日志（Logs）；但在生产环境，你必须盯指标（Metrics）。GPU 利用率、请求延迟、吞吐量以及队列积压情况，这些指标之间存在复杂的关联。如果某个时间点延迟升高，你需要迅速判断是由于 KV Cache 命中率下降，还是因为请求队列积压导致的排队等待。

最后是成本失控。GPU 资源的碎片化占用是非常烧钱的。如果你不实现 Request-level（请求级）的精准计费，你根本无法分析出究竟是哪个业务模块在浪费资源，最后只能面对一张天文数字般的云账单发呆。

最近 MCP（Model Context Protocol）在社区非常火，但从生产工程的角度来看，我依然持谨慎态度。MCP 非常适合做 POC（概念验证）或内部工具，但在处理高并发、强一致性的线上流量时，它是否能扛住压力还缺乏足够的实战验证。目前大多数团队将其停留在内部工具阶段，真正敢将其推向生产环境的案例依然很少。