AI训推一体化轻量平台技术选型决策书

本次搭建企业内部AI训推一体化平台，核心服务算法团队完成模型训练、业务团队完成模型测评，实现训练-模型管理-自动部署全流程自动化。团队现状为：平台侧为Java技术栈，无专职K8s运维人员；算法侧精通PyTorch模型研发，无工程化与云原生运维能力，需规避复杂架构、高运维成本、不可控风险，确保平台稳定落地、权责清晰。

（二）核心目标

实现算法可视化提交训练、GPU资源共享隔离，多任务无抢占冲突
搭建统一模型管理中心，完成模型版本、权限、全链路轻量追踪
实现训练完成后自动部署推理服务，支撑业务快速测评
架构轻量易维护，无复杂组件，团队可自主运维、问题可快速解决
明确平台与算法团队边界，杜绝责任推诿，避免平台侧背锅

（三）团队约束

平台团队：Java技术栈，负责上层平台开发、流程调度、资源管控，无云原生深度运维能力
算法团队：精通PyTorch模型研发，负责模型代码、训练环境、模型效果，无K8s与工程化能力
基础设施：现有GPU服务器集群，无专属云资源，无专职运维人员支撑

二、核心技术选型范围

本次决策覆盖平台算力调度与GPU隔离、模型管理、训练部署、上层平台、存储 五大核心模块，所有选型遵循轻量、稳定、易运维、无侵入、低风险原则，拒绝复杂重型组件。

三、各模块技术选型与对比分析

（一）模块一：GPU隔离与算力调度（核心底座）

1. 备选方案

HAMi、Volcano vGPU、NVIDIA MIG、NVIDIA MPS

2. 优劣对比

选型维度	HAMi	Volcano vGPU	NVIDIA MIG	NVIDIA MPS
隔离级别	软件硬隔离，显存/算力双隔离，粒度1%起	软件硬隔离，显存/算力双隔离，粒度0.1卡起	硬件级隔离，无性能损耗	进程级共享，无显存隔离
硬件适配	全系列NVIDIA GPU，无限制	全系列NVIDIA GPU，无限制	仅支持A30/A100/H100等高端卡	全系列NVIDIA GPU
安装复杂度	组件多（调度器+Webhook+设备插件），部署繁琐	单Helm命令一键安装，极简部署	显卡固件配置，无额外组件	无需额外安装，原生支持
运维难度	高，日志晦涩，问题排查难，需专职K8s运维	低，社区成熟，文档完善，问题易排查	极低，官方原生，无故障风险	极低，原生支持
灵活性	极高，支持动态切分、拓扑感知	高，支持动态切分，满足多租户需求	低，切分后固定，无法动态调整	无隔离，无灵活性可言
适配场景	大型集群、有专业运维团队	中小型集群、轻量平台、无专职运维	高端卡静态资源划分、高安全场景	单租户内部测试，严禁生产使用
团队适配度	低，无运维无法支撑	高，完全匹配现有团队能力	中，受硬件限制	极低，生产存在雪崩风险

3. 选型结论

选定：Volcano vGPU

4. 选型理由

部署极简，无需专职K8s运维，平台团队可独立完成安装与维护
兼顾算力调度与GPU隔离，满足多租户、多任务无抢占核心需求
社区成熟，问题排查成本低，无不可解决的技术坑
与K8s原生兼容，Java平台可通过K8s Client无缝对接，无需额外改造
完全规避硬件限制，适配现有GPU服务器，资源利用率高

5. 淘汰方案说明

HAMi：运维复杂度高，无专职运维易出现无法排查的故障，淘汰
NVIDIA MIG：受高端卡限制，灵活性差，无法适配动态资源需求，淘汰
NVIDIA MPS：无显存隔离，单任务异常会导致集群雪崩，生产禁用，淘汰

（二）模块二：模型全生命周期管理

1. 备选方案

MLflow 3.x、Kubeflow Model Registry、自研模型仓库

2. 优劣对比

选型维度	MLflow 3.x	Kubeflow Model Registry	自研模型仓库
部署难度	极低，容器一键启动，无依赖	极高，需依赖整套Kubeflow组件	极高，需从零开发全功能
功能覆盖	满足实验跟踪、模型版本、权限、轻量血缘追踪	功能全面，但组件臃肿，耦合度高	可定制，但开发周期长、维护成本高
运维成本	极低，稳定无崩溃，无需日常维护	极高，组件易故障，需专业运维	高，需持续迭代修复
对接成本	低，提供标准REST API，Java平台无缝对接	高，需适配Kubeflow整套架构	极高，需自主开发接口与管理逻辑
轻量性	极致轻量，无冗余组件	重型，冗余组件多	按需开发，周期长

3. 选型结论

选定：MLflow 3.x

4. 选型理由

极致轻量，部署维护零成本，平台团队可独立管控
覆盖模型版本、实验跟踪、指标日志、模型注册核心需求
支持标准API对接，Java平台可轻松实现模型统一管理与轻量全链路追踪
无耦合性，不依赖其他重型组件，稳定可靠，无线上故障风险
完全符合平台与算法边界：平台管模型存储与权限，算法管模型内容

5. 淘汰方案说明

Kubeflow Model Registry：依赖整套Kubeflow，架构臃肿，无运维无法支撑，淘汰
自研模型仓库：开发周期长、成本高，无必要重复造轮子，淘汰

（三）模块三：训练与推理部署

1. 备选方案

K8s原生Job/Deployment、Kubeflow Pipeline、自研调度组件

2. 选型结论

选定：K8s原生Job+Deployment

3. 选型理由

原生支持，无需额外安装组件，兼容性拉满
训练用K8s Job，自动启停、资源隔离；推理用Deployment，稳定提供服务
Java平台通过K8s Java Client可轻松实现任务创建、状态监听、自动部署
完全适配轻量架构，无学习成本，问题易排查
仅做单机多卡训练，规避分布式训练复杂问题，团队可完全掌控

（四）模块四：上层平台开发

1. 选型结论

选定：Java后端+主流前端框架（Vue/React）

2. 选型理由

平台团队核心技术栈，开发效率高，自主可控
可轻松对接K8s、MLflow，实现全流程自动化编排
自主开发门户、任务管理、模型管理、推理服务管理、权限租户模块，完全匹配业务需求
权责清晰，平台团队全权负责上层功能开发与维护

（五）模块五：存储服务

1. 选型结论

选定：MinIO

2. 选型理由

轻量开源，容器一键部署，运维成本低
兼容S3协议，与MLflow无缝对接，用于存储模型文件、训练日志、数据集
满足平台数据存储需求，无需依赖外部存储服务，自主可控

四、整体平台架构

（一）最终技术架构

用户层：算法工程师（训练提交）、业务测评人员（模型调用）
上层平台层：Java自研平台（任务调度、流程自动化、模型管理、权限管控、前端交互）
模型管理层：MLflow 3.x（实验跟踪、模型版本、轻量血缘追踪）
算力调度层：K8s+Volcano vGPU（训练Job、推理Deployment、GPU切分隔离）
存储层：MinIO（模型、日志、数据存储）
基础设施层：GPU服务器集群

（二）核心流程

算法通过Java平台提交训练任务，配置资源参数
Java平台调用K8s创建Job，Volcano vGPU完成GPU切分与调度
训练过程中，日志与指标自动上报至MLflow
训练完成，模型自动注册至MLflow，Java平台监听完成状态
Java平台自动调用K8s创建推理Deployment，加载MLflow模型启动服务
业务人员通过平台调用推理接口完成测评，全流程可追溯

五、平台与算法团队职责边界

（一）平台团队（Java）全权负责

上层平台开发、全流程自动化编排、权限与多租户管控
Volcano vGPU、K8s、MLflow、MinIO的部署与日常维护
GPU资源调度、配额管控、任务状态监控
模型存储、版本、权限管理，全链路轻量追踪
推理服务自动部署、接口管理

（二）算法团队全权负责

模型训练/推理代码、PyTorch等框架版本、环境依赖配置
训练/推理基础镜像制作、环境调试
模型训练、超参调优、效果优化
训练任务异常、环境冲突、模型效果问题排查

（三）禁止越界事项

平台团队不介入算法代码、模型框架、环境依赖、镜像内容
算法团队不操作K8s、Volcano、MLflow等底层组件，不干预资源调度

六、风险评估与应对措施

风险类型	风险描述	应对措施
技术风险	Volcano vGPU出现调度异常，GPU分配失败	留存官方文档与社区解决方案，平台团队提前完成部署测试，预留回滚方案
运维风险	无专职K8s运维，组件故障无法排查	选用极简组件，提前梳理常见问题排查手册，避免复杂配置与二次开发
协作风险	团队职责不清，出现责任推诿	严格执行本决策书职责边界，问题按权责判定，提前同步团队与领导
性能风险	多任务并发导致GPU资源抢占	通过Volcano vGPU做显存/算力硬隔离，配置租户资源配额，限制并发任务数

七、决策总结

本次AI训推一体化平台，全部选用轻量、稳定、易运维、适配现有团队能力 的技术组件，最终选型为：Java自研平台+MLflow 3.x+K8s+Volcano vGPU+MinIO。

该架构完全规避重型组件、高运维成本、不可控技术坑，实现训练自动化、模型统一管理、推理自动部署、GPU资源隔离的核心目标，权责边界清晰，平台团队可完全自主落地与维护，无额外运维依赖，是当前团队场景下最优、最安全、最可落地的技术方案。

八、决策确认

决策事项	确认结果	确认人
整体技术架构与选型	同意	平台负责人
GPU隔离与调度选型	同意	平台负责人
团队职责边界	同意	平台、算法团队负责人
项目落地计划	同意	项目负责人
这份决策书可以直接提交领导审批、同步团队执行，专业度和实用性都拉满了。需要我帮你把里面核心选型和职责边界提炼成一页精简版，方便你快速汇报和传阅吗？