云原生 AI 平台一年建设路线图：从 MVP 到生产级
一、不是多了一个平台，是多了一类基础设施
一年前开始搭建内部 AI 平台的时候，团队手里只有三样东西：一个裸的 Kubernetes 1.26 集群、两台带 GPU 的物理节点、和一堆"先把模型跑起来再说"的需求单。当时的 MVP 可以用一句话概括——HTTP POST /v1/chat/completions，后面挂一个 vLLM 单实例，完事。
一年后的今天，这个平台承载了 7 个业务线、日均 580 万次推理请求、管理着 42 个 GPU 实例，并且刚刚通过了第二次全局故障演练：主集群宕机后，流量在 45 秒内全部切到灾备集群，P99 延迟恶化不超过 15%。
这条路线不是提前规划好的。它是被需求推着走出来的，每往前一步都是因为上一步已经撑不住了。这篇文章不讲"最好的做法是什么"，只讲我们实际做了什么、为什么这样做、踩了什么坑。
二、四个阶段：从跑起来到管得住
下面的时间线展示了平台四阶段的演进路径：
阶段一：MVP（第 1-2 月）
只有一个目标：让业务侧能通过 API 调用模型。技术栈极简——vLLM 单实例部署在 K8s 上，前面挂一个 NGINX Ingress，域名指向内网 DNS。没有多副本、没有弹性、没有监控面板。
这个阶段最重要的决策不是技术选型，而是不做的事情：不做模型训练，不做模型微调，不追求多框架兼容。先集中精力把推理服务跑稳，跑稳了再谈其他。
阶段二：服务化（第 3-5 月）
MVP 跑了两个月后，问题开始集中爆发。最典型的一个：业务 A 的批量推理任务打满了 GPU 显存，业务 B 的实时请求全部超时。资源隔离是刚需。
我们引入了 GPU 资源池化的概念——将 GPU 节点按业务特性分为实时推理池和离线批处理池，两块池子物理隔离。实时池挂在 API 网关后面，批处理池通过消息队列驱动。同时引入了多副本部署，每个模型至少保留 2 个 Pod 副本，分散在不同节点上。
这个阶段最大的教训是：GPU 调度和 CPU 调度完全不是一回事。Kube-scheduler 的默认调度策略根本不感知 GPU 显存的状态，一个推理 Pod 即使显存用满了，调度器也可能再塞一个进去。我们不得不使用 GPU Operator 的 device-plugin 机制，在 Pod 调度阶段引入显存容量过滤。
阶段三：生产化（第 6-9 月）
当日均请求量突破百万级别后，我们做了三件把平台推向生产级的事。
第一，基于自定义指标的 HPA。GPU 利用率作为扩缩容指标是完全错误的——推理场景下，GPU 利用率可以到 90% 以上，但显存不够就是不够。我们的 HPA 指标改为 inference_queue_depth（推理队列深度）和 request_p99_latency，从业务感知维度触发伸缩。
第二，多集群灾备。主集群在自建机房，灾备集群在公有云。两地通过 VPN 互联，推理网关层做 DNS 级故障切换。最关键的是：灾备集群的 GPU 实例平时不跑推理，而是跑模型版本的预加载和离线评测任务，保持显存预热状态。这样故障切换时不需要重新加载模型，切换时间从 5 分钟压缩到 45 秒。
第三，可观测性体系。推理服务的可观测性比常规 Web 服务复杂得多——除了常规的 RED 指标（Rate/Error/Duration），还需要监控 token 生成速率、KV Cache 命中率、显存碎片化程度。我们基于 Prometheus + Grafana + Loki 三件套搭建了统一观测面板，并在 Grafana 上做了按模型、按业务线、按 GPU 型号的三维度下钻视图。
阶段四：平台化（第 10-12 月）
最后一个阶段的核心思想是：平台不是运维工具，是产品。
我们做了租户隔离——每个业务线分配独立的命名空间和 GPU 配额，通过 ResourceQuota 和 LimitRange 双重限制。没有人可以"临时借一下"其他业务的 GPU，借了就要走审批流程。
CI/CD 集成方面，模型更新的灰度策略从"全量替换"改成"10%-50%-100%"三阶段灰度，每个阶段保持 5 分钟的观测窗口，任一台 Pod 的推理队列长度超标就自动回滚。
成本归因方面，我们给每个推理请求打上了业务标签和 GPU 型号标签，在网关层做 GPU 耗时的实时计算，月底按业务线出账单。这个能力的意义不仅在于"谁用得多谁付钱"，更在于让业务方开始自觉地优化 prompt 长度和调用频率。
三、一年下来最重要的技术选型
回顾整条路线，有几个选型是团队的共识，也有几个是争论后达成的妥协：
共识项：Kubernetes 作为编排底座是正确的决策。K8s 的声明式 API、Pod 生命周期管理、资源调度扩展能力，为 GPU 资源管理提供了统一的基础设施抽象。
共识项：vLLM 作为推理引擎是正确的。在生产环境下，vLLM 的 PagedAttention 机制对显存利用率的提升是实打实的——同样的 A100 80GB 显卡，vLLM 可以同时承载 3 个模型的推理请求，而原生 Transformers 只能跑 1 个。
妥协项：是否引入服务网格。Istio 的 sidecar 对 GPU Pod 的 CPU 和内存开销是感知级的——一个 GPU Pod 的 sidecar 要吃掉约 300MB 内存和 0.2 核 CPU。我们最终选择了更轻量的方案：推理网关层做流量治理，GPU Pool 内部保持原生网络，复杂度与收益之间选择了收益。
仍在犹豫的：模型量化要不要全量推。AWQ 和 GPTQ 量化可以把 int8 模型的显存占用降到 fp16 的 50%，但对推理质量的量化损失因模型和任务而异。目前我们对部分内部场景（文档摘要、代码补全）做了量化上线，效果可接受；但对面向客户的问答场景仍保持 fp16。
四、边界与权衡
这个路线图最大的假设前提是：GPU 资源是固定的，不做动态的云端 GPU 弹性扩容。现实中，公有云 GPU 实例的可用性波动很大——同区域、同实例类型、同一时刻，可能会出现"售罄"的情况。如果平台强依赖云端弹性 GPU，需要额外建设实例预热队列和跨区调度能力，复杂度至少翻一倍。
另一个边界是：这条路线目前只覆盖了推理场景。模型训练、微调、RLHF 等场景对 GPU 集群的要求完全不同——需要高速网络互联（InfiniBand/RoCE）、分布式存储、更复杂的调度策略。训练基础设施是一个完全不同的课题。
五、总结
一年时间，从"跑起来"到"管得住"，云原生 AI 平台的建设没有捷径。核心经验就三条：先搞清楚当前阶段最致命的痛点是什么，一个阶段只解决一个问题；GPU 资源管理的思维和方法论和 CPU 完全不一样，不能用 Web 服务的思维管推理服务；平台最终交付的不是 API，是可靠性、可观测性和成本透明度。
基础设施不需要漂亮话，它需要十二个月的持续投入和每次故障后的真实复盘。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。
