云原生 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 资料来源索引并在发布前将具体来源贴到对应断言之后。
云原生 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 资料来源索引并在发布前将具体来源贴到对应断言之后。
