AI 平台一年回顾从零到支撑百个模型服务的得与失一、起点与现状用数据描述一年间的变化AI 平台的迭代开始于一个简单的目标为业务方提供稳定的大模型推理服务。起点的技术栈是一台 GPU 服务器 vLLM 手工启动 Nginx 反向代理。一年后平台支撑了近百个模型服务实例覆盖文本生成、文本理解Embedding/Reranker、文生图、语音识别等多种模型类型日均推理请求量稳定在千万级。平台在这一年里经历了从手工运维到全自动化、从单集群到多集群、从无模型管理到注册表模型市场的演进。基础设施的每一层都在这张审计表里有明确的交互记录这场演进没有宏大叙事每一步都是被具体的运维痛点推着走的。模型数量多了就建注册表GPU 类型杂了就拆多集群部署效率低了就上 CI/CD 灰度流水线。基础设施不需要漂亮话做决策的依据只有一个当前的瓶颈是否不解决就会影响业务稳定。二、做得对的三件事复盘核心正确决策回顾一年间做的无数决策有三件事站在今天来看仍然成立值得体系化沉淀。第一强制模型注册表。这是早期投入最少、长期收益最大的单一决策。一个中心化的元数据存储看似只是 CRUD 系统但它回答了平台最根本的问题集群里跑了哪些模型、谁来负责、用了多少资源。没有注册表之前这些信息散落在运维人员的脑子和 Slack 聊天记录里。注册表上线后调度器、网关、监控、计费系统全部基于这份元数据工作——它成了平台所有自动化行为的真相源。第二基础镜像标准化。如果没有在中期强制推行标准基础镜像今天平台面临的安全漏洞修复成本会让人窒息。标准化让一个 CVE 修复从排查 40 个服务用哪个镜像、有没有打补丁变成修复一个基础镜像 全量滚动更新复杂度从天降级到小时。更隐蔽的收益是版本一致性——所有服务的 CUDA 版本、推理框架版本完全统一彻底消灭了测试环境正常、生产环境异常的镜像版本差异问题。第三平面分离的网络架构。把南北向流量客户端到平台和东西向流量服务间调用治理分开是一个在初期看来为架构完整性多做的事情但经过高并发场景验证后证明了价值。当南北向流量因为某个促销活动突然暴增 5 倍时推理链路内部的服务间调用 P99 延迟纹丝不动——因为两个平面互不干扰。这种稳定性不是调参数能调出来的是架构设计层面给的保障。三、该做得更好但没做到的三件事复盘技术负债平台有很多当初应该做但没有做、或者做得不够好的事情。这些技术负债每天都在积累未来某个时间点必须偿还。第一多租户资源隔离。当前平台基于共享集群 Namespace 做逻辑隔离不同业务线的模型服务运行在同一集群、共享 GPU 资源池。在业务方数量不超过 10 时问题不大但当业务方超过 30 时单业务方出现 Bug 引发的 GPU 显存泄漏会影响同节点上其他业务方的服务稳定性。至今没有投入资源做强隔离原因是强隔离独立集群或硬多租户带来的额外 GPU 资源和运维成本在当前阶段难以获得认可。但这个问题不会自动消失——随着业务方数量和规模的增长隔离缺失的代价会线性上升。第二模型权重的增量更新。当模型权重文件达到上百 GB 时每次版本迭代全量下载和加载的时间成本越来越高——从 3 分钟膨胀到 15 分钟以上。增量更新Delta Update的技术方案是成熟的对象存储的版本化 仅下载差异块但一直因为当前可以忍受的优先级排到了后面。基础设施的债务不会自动偿还——这部分时间成本每个月都在浪费只是没有被放到账单上。第三跨集群的统一监控。随着集群数量从 1 个增长到 3 个监控数据分布在不同的 Prometheus 实例中。排查一个跨集群调用的全链路延迟时需要手动对三个 Grafana Dashboard 的时间线。Prometheus Federation 的技术方案已有文档但实施过程中遇到的标签冲突和存储膨胀问题没有彻底解决目前还处于半手工统计状态。四、前瞻明年最重要的三个基础设施命题从当前平台的技术负债和业务发展趋势来看接下来一年最重要的三个命题已经明确。第一是 GPU 池化与模型级弹性伸缩。当前每个模型服务固定分配 GPU 副本即便低峰期也持有资源。GPU 池化意味着所有 GPU 组成一个虚拟资源池模型服务按需从池中申请和释放 GPU。实现方式上更倾向于 Kubernetes 之上的调度层封装如 Volcano而非侵入式的 GPU 虚拟化方案如 MIG 或 vGPU因为后者对推理框架的兼容性和性能折损还需要更充分的验证。第二是推理质量的可观测性。当前平台的可观测性覆盖了基础设施指标延迟、QPS、错误率、Token 消耗但对于推理输出质量模型是否产生幻觉、输出是否与期望偏离、安全合规审查缺乏系统性监控。这需要引入 LLM-as-a-Judge 模式和自动化评测流水线将质量指标和可用性指标放在同样的监控面板上。第三是成本向业务方透明的计量和计费体系。当前平台的成本以集群总 GPU 费用的形式呈现无法回答A 业务线和 B 业务线各自占了多少成本这个问题。需要从 Token 级别的计量开始建立每个 API Key 到 GPU 消耗的精确映射把成本从技术团队转移到业务方推动业务方自己有动力去优化 Prompt Token 使用量和缓存策略。五、总结一年间平台从一台 GPU 服务器演进到支撑百个模型服务的工程化平台。核心收获强制模型注册表是一切自动化的基石、基础镜像标准化是安全治理的根本解法、平面分离是稳定性保障的架构前提。主要遗憾多租户隔离一直搁置、模型权重增量更新优先级不足、跨集群监控数据分散。接下来的三个重点方向——GPU 池化、推理质量可观测性、成本透明计量——每一项都比之前做的任何事更有挑战。但平台化建设的规律是一致的基础设施不需要漂亮话被痛点推着走是最好的路线图。
AI 平台一年回顾从零到支撑百个模型服务的得与失一、起点与现状用数据描述一年间的变化AI 平台的迭代开始于一个简单的目标为业务方提供稳定的大模型推理服务。起点的技术栈是一台 GPU 服务器 vLLM 手工启动 Nginx 反向代理。一年后平台支撑了近百个模型服务实例覆盖文本生成、文本理解Embedding/Reranker、文生图、语音识别等多种模型类型日均推理请求量稳定在千万级。平台在这一年里经历了从手工运维到全自动化、从单集群到多集群、从无模型管理到注册表模型市场的演进。基础设施的每一层都在这张审计表里有明确的交互记录这场演进没有宏大叙事每一步都是被具体的运维痛点推着走的。模型数量多了就建注册表GPU 类型杂了就拆多集群部署效率低了就上 CI/CD 灰度流水线。基础设施不需要漂亮话做决策的依据只有一个当前的瓶颈是否不解决就会影响业务稳定。二、做得对的三件事复盘核心正确决策回顾一年间做的无数决策有三件事站在今天来看仍然成立值得体系化沉淀。第一强制模型注册表。这是早期投入最少、长期收益最大的单一决策。一个中心化的元数据存储看似只是 CRUD 系统但它回答了平台最根本的问题集群里跑了哪些模型、谁来负责、用了多少资源。没有注册表之前这些信息散落在运维人员的脑子和 Slack 聊天记录里。注册表上线后调度器、网关、监控、计费系统全部基于这份元数据工作——它成了平台所有自动化行为的真相源。第二基础镜像标准化。如果没有在中期强制推行标准基础镜像今天平台面临的安全漏洞修复成本会让人窒息。标准化让一个 CVE 修复从排查 40 个服务用哪个镜像、有没有打补丁变成修复一个基础镜像 全量滚动更新复杂度从天降级到小时。更隐蔽的收益是版本一致性——所有服务的 CUDA 版本、推理框架版本完全统一彻底消灭了测试环境正常、生产环境异常的镜像版本差异问题。第三平面分离的网络架构。把南北向流量客户端到平台和东西向流量服务间调用治理分开是一个在初期看来为架构完整性多做的事情但经过高并发场景验证后证明了价值。当南北向流量因为某个促销活动突然暴增 5 倍时推理链路内部的服务间调用 P99 延迟纹丝不动——因为两个平面互不干扰。这种稳定性不是调参数能调出来的是架构设计层面给的保障。三、该做得更好但没做到的三件事复盘技术负债平台有很多当初应该做但没有做、或者做得不够好的事情。这些技术负债每天都在积累未来某个时间点必须偿还。第一多租户资源隔离。当前平台基于共享集群 Namespace 做逻辑隔离不同业务线的模型服务运行在同一集群、共享 GPU 资源池。在业务方数量不超过 10 时问题不大但当业务方超过 30 时单业务方出现 Bug 引发的 GPU 显存泄漏会影响同节点上其他业务方的服务稳定性。至今没有投入资源做强隔离原因是强隔离独立集群或硬多租户带来的额外 GPU 资源和运维成本在当前阶段难以获得认可。但这个问题不会自动消失——随着业务方数量和规模的增长隔离缺失的代价会线性上升。第二模型权重的增量更新。当模型权重文件达到上百 GB 时每次版本迭代全量下载和加载的时间成本越来越高——从 3 分钟膨胀到 15 分钟以上。增量更新Delta Update的技术方案是成熟的对象存储的版本化 仅下载差异块但一直因为当前可以忍受的优先级排到了后面。基础设施的债务不会自动偿还——这部分时间成本每个月都在浪费只是没有被放到账单上。第三跨集群的统一监控。随着集群数量从 1 个增长到 3 个监控数据分布在不同的 Prometheus 实例中。排查一个跨集群调用的全链路延迟时需要手动对三个 Grafana Dashboard 的时间线。Prometheus Federation 的技术方案已有文档但实施过程中遇到的标签冲突和存储膨胀问题没有彻底解决目前还处于半手工统计状态。四、前瞻明年最重要的三个基础设施命题从当前平台的技术负债和业务发展趋势来看接下来一年最重要的三个命题已经明确。第一是 GPU 池化与模型级弹性伸缩。当前每个模型服务固定分配 GPU 副本即便低峰期也持有资源。GPU 池化意味着所有 GPU 组成一个虚拟资源池模型服务按需从池中申请和释放 GPU。实现方式上更倾向于 Kubernetes 之上的调度层封装如 Volcano而非侵入式的 GPU 虚拟化方案如 MIG 或 vGPU因为后者对推理框架的兼容性和性能折损还需要更充分的验证。第二是推理质量的可观测性。当前平台的可观测性覆盖了基础设施指标延迟、QPS、错误率、Token 消耗但对于推理输出质量模型是否产生幻觉、输出是否与期望偏离、安全合规审查缺乏系统性监控。这需要引入 LLM-as-a-Judge 模式和自动化评测流水线将质量指标和可用性指标放在同样的监控面板上。第三是成本向业务方透明的计量和计费体系。当前平台的成本以集群总 GPU 费用的形式呈现无法回答A 业务线和 B 业务线各自占了多少成本这个问题。需要从 Token 级别的计量开始建立每个 API Key 到 GPU 消耗的精确映射把成本从技术团队转移到业务方推动业务方自己有动力去优化 Prompt Token 使用量和缓存策略。五、总结一年间平台从一台 GPU 服务器演进到支撑百个模型服务的工程化平台。核心收获强制模型注册表是一切自动化的基石、基础镜像标准化是安全治理的根本解法、平面分离是稳定性保障的架构前提。主要遗憾多租户隔离一直搁置、模型权重增量更新优先级不足、跨集群监控数据分散。接下来的三个重点方向——GPU 池化、推理质量可观测性、成本透明计量——每一项都比之前做的任何事更有挑战。但平台化建设的规律是一致的基础设施不需要漂亮话被痛点推着走是最好的路线图。
