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 池化、推理质量可观测性、成本透明计量——每一项都比之前做的任何事更有挑战。但平台化建设的规律是一致的：基础设施不需要漂亮话，被痛点推着走是最好的路线图。