AI 中台建设中的模型管理：从单模型到模型市场的演进

AI 中台建设中的模型管理从单模型到模型市场的演进一、当模型数量突破两位数手工管理体系的崩塌AI 中台在起步阶段团队往往只维护两三个模型——一个通用对话、一个代码生成、或许再加一个文生图。这个时期用 Git 仓库管理模型配置、手动部署、靠 Wiki 记录版本号似乎都能运转。但当一个平台需要支撑业务方接入 30 个以上的模型时这套管理体系会以肉眼可见的速度崩盘。核心痛点集中在三个问题上。首先是配置碎片化。每个模型的推理参数、资源配额、加速引擎版本散落在不同的 YAML 文件和运维文档里一个参数的变更可能被漏同步到 5 个环境。其次是版本一致性。A 团队升级了 vLLM 版本B 团队还在用旧版同一个模型在测试环境和生产环境表现不一致排查半天发现是底层推理引擎版本差异造成的。第三是所有权混乱。模型镜像从谁那里继承的、安全补丁更新谁负责、SLA 由哪个团队兜底——这些问题在模型数量少的时候不算事一旦规模化就变成定时炸弹。基础设施不需要漂亮话需要的是可复现、可审计、可追溯的管理体系。模型管理表面上看是 DevOps 问题本质上是工程治理问题。二、模型元数据中心化从散落文档到单一事实来源模型管理的核心命题是建立一个单一事实来源Single Source of Truth。我们把所有模型的元信息聚合到一个中心化注册表里每个模型有一个唯一标识符携带以下核心信息模型名称与版本号、推理框架类型及版本vLLM/TGI/TensorRT-LLM、资源配置GPU 类型/数量/显存/副本数、推理参数max_tokens/temperature/top_p 默认值、模型权重的存储路径对象存储 Bucket/Prefix、安全合规标签数据分级/是否涉及 PII、负责人/所属团队/升级窗口。这个注册表的实现没有追求花哨的框架。用 PostgreSQL 存结构化元数据模型权重文件统一挂到对象存储上前端搭一个轻量级的 Go Gin 管理界面。关键不在技术栈而在强制约束所有模型的部署、扩缩容、版本升级必须经过注册表的校验。注册表里没有记录的模型不允许被调度器拉起。这个架构的核心思想是注册表即真相。调度器不信任任何外部输入只信任注册表里的数据。任何没有通过注册表录入的模型不会在任何集群上被调度运行。这个约束虽然粗暴但在实践中最有效。三、模型市场的产品化封装让业务方自服务注册表解决了运维层面的治理问题但业务方仍然需要一个界面来发现和申请模型。这就引出了模型市场的设计。模型市场的核心功能包括三个层次。第一层是模型目录展示所有已上架的模型带搜索、标签过滤和使用场景描述。第二层是接入流程业务方选择模型后系统自动生成 API Key 和调用文档不需要人工审批但在后台自动注入配额和限流策略。第三层是监控与计费每次调用自动打点Token 消耗、延迟分位数P50/P99、错误率都实时可见成本按业务线拆分。在实现上模型市场本质上是一个 API 网关的扩展层。我们基于 Envoy 做了两层代理外层根据 API Key 做认证和限流内层根据请求中的model参数动态路由到对应的推理服务实例。这里有个值得注意的设计决策我们不把路由逻辑放在模型市场里而是通过配置下发到网关。模型市场只负责管理元数据和权限网关独立负责流量转发——职责分离故障域隔开。Go 后端的关键代码结构大致如下// ModelRegistry 定义模型注册表的核心接口 type ModelRegistry interface { // Register 注册一个模型校验必填字段 Register(ctx context.Context, model *ModelMeta) error // List 列出所有已上线的模型支持标签过滤 List(ctx context.Context, filter ModelFilter) ([]*ModelMeta, error) // GetByID 根据模型 ID 获取元数据 GetByID(ctx context.Context, modelID string) (*ModelMeta, error) // UpdateStatus 更新模型状态上线/下线/灰度 UpdateStatus(ctx context.Context, modelID string, status ModelStatus) error } // ModelMeta 模型元数据——注册表的单一事实来源 type ModelMeta struct { ID string json:id validate:required Name string json:name validate:required Version string json:version validate:required Framework string json:framework validate:required,oneofvllm tgi tensorrt-llm triton GPU GPURequirement json:gpu Replicas int json:replicas validate:min1,max20 InferenceParams InferenceConfig json:inference_params Owner string json:owner validate:required DataClass string json:data_class validate:required,oneofpublic internal restricted CreatedAt time.Time json:created_at UpdatedAt time.Time json:updated_at }注册接口在执行写入前做三层校验必填字段完整性、GPU 资源是否在当前集群可调度范围内、模型权重文件在对象存储中是否真实存在HEAD 请求验证。任何一层失败都直接拒绝注册不让脏数据进入系统。四、大规模管理的边界这套方案解决不了什么这套中心化注册 模型市场的方案并不是银弹。其适用边界和局限性需要清醒认知。第一多租户隔离是一个明显的短板。当前设计基于共享集群通过 Namespace 和 ResourceQuota 做软隔离。如果业务方对数据安全有强隔离需求如金融行业的私有化部署这套方案无法替代独立的单租户集群。第二模型权重的增量更新没有覆盖。当模型权重文件达到数百 GB 级别时全量重新上传会显著拉长上线时间但增量更新的实现复杂度远高于此处的投入产出比——我们在实践中选择了接受全量上传的代价。第三模型市场的权限模型目前还比较简单API Key 粒度的访问控制如果需要更细粒度的某个业务线只能使用某个模型的某个版本这样的控制需要引入 RBAC 层这不在当前版本的设计范围内。另外值得指出的是这套方案为每个模型固定分配 GPU 副本适合推理流量相对稳定的场景。如果流量波动剧烈、需要在多个模型之间弹性共享 GPU 池那么模型市场的计费方式和调度策略需要重新设计。这个方向我们已经在下一阶段规划中但当前版本不做。五、总结从单模型管理到模型市场核心变化不是代码量的增长而是治理范式的迁移——从依赖个人记忆和文档流转过渡到依赖自动化约束和结构化元数据。落地建议分三步走。第一步先建立模型元数据的中心化注册表强制所有新模型必须注册这是代价最小、收益最大的动作。第二步在注册表基础上构建 CI 流水线实现镜像的自动构建和一致性升级消除手工操作带来的版本漂移。第三步在稳定性验证通过后上线模型市场的前端界面让业务方自助查找和接入模型同时完善配额和限流策略。关键判断标准当一个模型从申请到上线的时间从几天缩短到几十分钟且全程不需要运维人员介入时可以认为模型管理基础设施初步建成。