GitHub Actions跑AI流水线？别只当CI用

矩阵策略跑超参数调优这个点我太有共鸣了，之前手动调参到崩溃，后来试着用Actions的矩阵并行跑了几个实验，确实比本地Grid Search爽太多，而且不用占自己电脑的算力。不过你说的artifact存储上限是真的烦，我跑一次小规模的超参搜索，中间产出的模型文件就快把免费额度吃光了，后来不得不自己写脚本压缩上传，或者干脆只存日志和关键指标。

self-hosted runner挂GPU我也折腾过，配置起来其实比想象中麻烦，主要是不稳定，有时候runner莫名其妙断开，整个流水线卡住，得加心跳检测和重试机制。而且Actions的执行时间限制对长时间训练任务确实不友好，超过6小时就强制中断，我后来是把训练拆成多个小任务，用workflow_dispatch触发串起来跑，勉强能绕过去。

模型版本管理和回滚这块，我现在的做法是每次训练完把模型元数据（超参、指标、训练日期）写到一个JSON里，跟模型文件一起存到同一个artifact，然后用Git tag关联。回滚的时候直接根据tag找到对应的artifact和参数配置，重新触发workflow部署。虽然有点手动，但比没有强。

说实话，对于小团队来说，GitHub Actions当轻量级调度器用确实比搭K8s划算，但真要上生产环境，artifact的存储和版本管理迟早会成为瓶颈。你们有没有试过把模型存到外部存储，比如S3或者云盘，然后Actions只负责调度和日志？我最近在调研这个方案，感觉能省不少artifact额度。

这思路挺实用的，我最近也在研究怎么用Actions跑轻量级调参。有个问题想请教下，你说到的模型版本管理和回滚，是不是得结合Git LFS或者DVC来处理？我试过直接把模型存artifact，但超出500MB就得走外挂存储，这块你们是怎么解决artifact存储上限的？

矩阵策略跑超参调优这点确实香，我之前用本地Grid Search跑个3层搜索空间，直接干到48小时，换成Actions矩阵并行，12小时就收工了。不过你说的artifact存储上限我深有体会，跑一次模型训练动不动就几百MB的checkpoint，免费额度那2GB根本不够用，后来我把模型权重直接推到Git LFS或者用wandb存，actions里只保留日志和配置文件，能省不少空间。

另外那个执行时间限制也很蛋疼，6小时上限对小模型还行，稍微大点的训练任务就得拆stage，或者搞个定时workflow续命。我试过用self-hosted runner连实验室的旧GPU工作站，稳定性确实比云上好，但网络代理和权限配置折腾了两天。

关于模型版本管理，我现在的做法是在每次训练完自动打个git tag，把超参和metrics写进commit message里，配合DVC做数据版本控制。回滚的话直接切tag重新跑action里的deploy job，但有个遗留问题：如果模型结构变了，旧版本的pipeline可能跑不起来了，这点我还在想怎么优雅处理。

小团队确实没必要硬上K8s，Actions加个self-hosted runner基本够用，成本就是电费和偶尔的artifact清理。不过你说到分布式调度，Actions的job并发数也有限制，免费版20个并发跑大规模搜索还是有点吃力，我后来试过用Celery搭了个轻量调度器，但维护起来又比Actions麻烦。所以现在折中方案是：小规模搜索用Actions，大规模切到自家的廉价GPU服务器。你们遇到artifact膨胀时是咋处理的？

确实，矩阵策略做超参调优这块我试过，比本地硬跑舒服多了，特别是搭配cache复用依赖，效率直接翻倍。不过artifact存模型确实头疼，我后来改成直接push到Hugging Face或S3，顺便绕开执行时长限制。模型版本管理我用DVC配合Actions做元数据追踪，回滚时重新触发workflow就行，虽然有点糙但够用。

这个帖子信息量挺大的，尤其是矩阵策略跑超参调优那段，我之前一直以为GitHub Actions就是跑跑测试和部署，没想到还能这么玩。不过有个疑问想请教一下——你说的模型版本管理和回滚那块没写完，是卡在什么具体问题上了？我最近也在折腾类似的事情，用Actions把训练好的模型推到Git LFS或者S3，但版本回溯特别头疼，尤其是模型文件大了之后，Actions的artifact保留时间只有90天，过期就没了，感觉不太靠谱。

另外，self-hosted runner挂GPU，你用的是哪家的方案？我之前试过在自家服务器上搭，但网络延迟和安全配置搞得我头大，后来干脆用RunPod或者Vast.ai的临时实例配合Actions API触发，虽然便宜但每次启动都要等几分钟，小团队凑合用吧。你说的训练时间缩短40%是相对什么基准？是跟单机Grid Search比还是跟单卡顺序调参比？

还有那个执行时间限制，我记得免费版是6小时，付费版也就翻倍，大模型训练或者复杂的超参搜索跑一次可能都不够。你是拆成多个workflow接力跑，还是干脆放弃了某些长任务？如果能分享一下怎么绕过这些限制，感觉对大家帮助会很大。

矩阵策略跑超参调优这招确实好用，我这边之前试过用GitHub Actions的matrix并行跑LightGBM的网格搜索，同样的搜索空间，本地i9跑要将近6小时，Actions上开8路并行，45分钟搞定，成本才几毛钱。不过你说的artifact存储上限我太有同感了，500MB的免费限额对于模型权重文件来说简直是在开玩笑，我后来是直接切到S3或者用Git LFS做中转，靠Actions的upload-artifact只存日志和指标，模型单独推出去。

关于你提到的模型版本管理和回滚，这个在Actions里确实是个硬伤。GitHub本身不提供原生的模型 registry，我现在的做法是在workflow里加一步，用dvc或者mlflow的tracking API把模型元数据写回repo的某个json文件里，顺便打tag。回滚的时候直接切git tag，然后靠Actions的workflow_dispatch触发重新部署指定版本。虽然有点糙，但胜在轻量，比上mlflow server或者k8s那套省事多了。

self-hosted runner挂GPU我也踩过坑，最大的问题是runner的稳定性，任务跑一半runner掉线直接整条流水线废掉。后来我给runner加了supervisor做进程守护，外加心跳检测，如果连续3次心跳超时就自动重启runner实例。还有个细节，如果你用self-hosted跑长时间训练，记得把actions/checkout的fetch-depth设成1，不然光git拉历史就把时间耗完了。

说到底，GitHub Actions对于小团队确实是个被低估的调度器，尤其是那些不想碰infra又想快速验证想法的场景。但真要上生产级的ML pipeline，它的artifact管理和执行时长限制迟早会让人头疼。你那边有没有试过用nektos/act在本地模拟？我觉得这可能是平衡本地开发和云端调度的一个中间方案。

矩阵策略跑超参调优这个我试过，确实比本地Grid Search爽太多，尤其是配合self-hosted runner挂GPU，成本比租按需实例低得多。不过你说artifact存储上限这个坑，我踩过更深的——模型文件稍大一点就超限，后来被迫把模型拆成checkpoint分段上传，再配合Git LFS做增量管理，才勉强绕过去。还有那个6小时执行时间限制，训练一旦超时就自动中断，得靠断点续训才救回来，不然白跑半天。

关于模型版本管理，我现在的做法是每次训练完自动把模型元数据（超参、指标、数据hash）写进一个单独的JSON文件，跟模型artifact一起打包上传，再通过Git tag打版本标签。回滚时直接根据tag拉取对应artifact和元数据，比靠action run id去翻日志靠谱得多。但这样也麻烦，尤其是多分支并行训练时，tag命名容易乱。

另外我好奇你说的self-hosted runner挂GPU，是直接裸机跑还是用Docker？我试过裸机，环境隔离太痛苦；用Docker又遇到GPU驱动版本和CUDA兼容性问题，每次更新驱动都得重新build镜像。有没有更优雅的方案？

矩阵策略跑超参调优这个点确实戳中我了，我上周刚用类似方案跑过一次BERT的蒸馏实验，并行度拉满后，原来本地要跑两天的Grid Search，压缩到6小时出头。不过有个细节得提醒一下——Action的并发job数跟账户等级挂钩，免费版最多20个并行，如果超参空间太大，建议用策略矩阵里的max-parallel参数做限流，否则容易被限速，我踩过这坑。

你说self-hosted runner挂GPU，训练时间砍40%倒是合理，但artifact存储上限那个确实头疼。我现在的折中方案是：把训练中间产物直接推S3或者OSS，只把最终模型权重和log存成artifact，这样既能突破500MB的硬限制，又方便后续版本回溯。不过你这帖子没展开说模型版本管理的问题，我猜你是在纠结怎么跟Git LFS或者DVC联动吧？我试过把DVC的remote挂到GitHub Releases上，配合Actions的workflow_dispatch触发器做手动回滚，效果还行，就是每次回滚得重新拉一遍数据集，体感上比K8s那套rollback要慢。

另外你说它是个廉价的分布式调度器，这个比喻我太认同了。我们小团队之前为了省成本，用Actions做定时训练的cron job，配合矩阵策略做多组实验的并行分发，运维成本几乎为零。但有个隐患——Action的执行时间最长6小时，跑大模型训练肯定不够，得自己切checkpoint续跑。我写了个简单的状态机逻辑，用GitHub的Issue comment做断点续传的信号，算是勉强绕开了这个限制。你那边有没有更好的解法？

矩阵策略跑超参调优这个思路确实香，我试过用GitHub Actions做随机搜索，配合self-hosted runner挂GPU，效率比本地硬跑高出一大截。不过artifact存储和6小时超时限制是真坑，小模型还好，大模型训练一半超时直接白给。模型版本管理这块，我目前是打完训练后自动上传到DVC或者Hugging Face Hub，再在Action里用tag关联commit，回滚时直接切tag重跑，算是勉强能应付。

矩阵策略跑超参调优这招确实香，我之前也是看了篇博客试了下，把Grid Search拆成几个job并行跑，速度直接起飞。不过有个坑要提一下——Actions的并发数是有限制的，免费版一跑多就排队，而且artifact存模型文件多了还得手动清，不然很快爆上限。我后来换了个思路，把每次调优的结果用Git LFS存到仓库里，再配合一个简单的Python脚本做版本对比，虽然麻烦点但至少没存储焦虑了。

self-hosted runner挂GPU这个操作我也搞过，但稳定性是个问题，Runner隔三差五断连，得写个watchdog脚本自动重启。另外你说模型版本管理和回滚，这个我目前是用Docker镜像打tag的方式来处理的，每次训练完把模型和对应的代码环境打包成一个镜像，推到自己搭的Registry里，回滚就换镜像tag。虽然有点重，但至少比依赖Actions的artifact靠谱。

不过话说回来，GitHub Actions做分布式调度确实挺适合小团队的，尤其是那种训练任务不频繁、不想自己维护K8s的场景。我现在的做法是把它当触发器用——代码push触发预训练，跑完自动把结果推到Hugging Face Hub上，再触发一个webhook通知团队。省心是省心，但真要搞大规模训练或者需要实时监控的，还是得老老实实上K8s。你们有没有遇到过Actions执行时间超限的问题？我有些长训练任务一跑就超6小时，最后只能切分到多个workflow里接力跑。

这帖子说到点子上了。GitHub Actions当分布式调度器用这个思路，我最近也在折腾，确实比想象中能挖的坑多。矩阵策略跑超参调优这块，我试过配合optuna或者ray tune，直接并行十几个job，比本地单机Grid Search爽太多了，尤其是一些小规模模型，省时间又省心。

不过你说artifact存储上限和action执行时间限制，这俩真的是硬伤。我上次跑一个训练任务，模型checkpoint稍微大点，artifact就报超限，最后得切到外部存储，比如S3或者自家nas，绕一圈。执行时间的话，如果模型训练超过6小时，就得拆成多个workflow接力，或者用self-hosted runner挂GPU自己控制超时，不然直接给你kill掉，血亏。

另外我补充一个坑，就是依赖环境的一致性。Actions每次跑都是全新环境，pip install装包装半天，特别是torch那些大包，浪费不少时间。后来我改成用缓存或者pre-build docker image，稍微好点。但self-hosted runner又得维护环境一致性，各有各的麻烦。

模型版本管理这块，你话没说完，我猜是想说回滚或者多版本对比？我现在用DVC或者wandb来管，配合GitHub Actions的workflow触发，每次训练完自动记录参数和指标，然后生成个summary push到仓库，或者发到slack通知。不过回滚的话，确实还没找到特别优雅的方案，目前只能手动切commit再rerun workflow。

感觉这方向小团队用确实香，但得接受它是个“廉价”方案，稳定性、持久化、权限管理都差点意思。有没有更好的实践？比如怎么优雅地处理长时间任务和超大模型存储？求分享。

矩阵策略跑超参调优这块确实是个好思路，我最早也是在GitHub Actions上这么干的，但后来发现一个问题——它那个并行度其实受限于你账户的并发Job数限制，免费版只有20个，就算Pro版也就60个左右，超参搜索空间稍微大一点就得排队。而且artifact存储上限对模型产出来说太要命了，一个稍微复杂点的模型权重文件动辄几百兆，存几轮迭代就爆了，我后来被迫把模型上传到S3或者NAS上，Actions只做触发和编排。

你提到的self-hosted runner挂GPU我也踩过坑，主要问题有两个：一是runner的自动扩缩容你得自己写脚本，不然闲置时候机器还在跑；二是网络环境不一致，本地挂载的路径、依赖版本经常跟CI环境打架，我后来干脆把整个环境封装成Docker镜像，runner只拉镜像跑，省了很多头疼的事。

关于模型版本管理和回滚，我的做法是用DVC加Github Releases，每次训练完把模型文件用DVC推到一个独立的对象存储里，然后在Release里打tag，回滚的时候直接checkout对应的commit和DVC的lock文件。这样虽然多了一步操作，但至少比裸存artifact靠谱。不过你说的没错，这套方案本质上是把K8s的活硬塞给CI平台，简单场景够用，复杂了还是得老老实实上Kubeflow或者MLflow。

矩阵策略跑超参确实是个好思路，我试过把Grid Search拆成30个并行job，比单机快太多了。不过artifact存储坑是真的深，免费额度500MB训练一次就炸了，后来我把模型checkpoint直接推到S3才解决。另外模型版本管理这块，我用DVC配合Git LFS勉强能跑通，但回滚时环境依赖经常打架，有没有更轻量的方案能分享下？

矩阵策略跑超参调优这个点确实被低估了，我团队去年拿它做过一次大规模的NAS搜索，把搜索空间切成碎片扔到不同runner上，体感上比用Optuna本地调参快了一个量级。但有个现实问题——GitHub Actions的job并发数是跟付费plan走的，免费版20个并发一上强度就卡脖子，self-hosted runner虽然能绕开，但维护成本和网络稳定性又是新坑。

artifact存储上限那个我深有体会，模型checkpoint动不动就上G，5GB的免费额度根本扛不住。后来我们用了折中方案：只存最佳模型的权重和训练日志，中间产物直接推到S3或者minio，action里只保留一个轻量的元数据文件。动作执行时间限制的话，6小时对于大模型训练肯定不够，但如果是小模型或者微调场景，配合缓存机制把训练数据预处理结果存下来，勉强能跑通。

关于模型版本管理和回滚，我踩过的坑是action rerun时如果依赖外部存储，版本号容易乱。后来用dvc或者mlflow把模型hash和action run ID绑定，回滚时直接通过workflow dispatch指定commit或tag，逻辑清晰多了。小团队确实没必要上K8s，但如果你长期跑流水线的话，建议在action里加个健康检查逻辑，runner挂了能自动重试或者切到备用节点，不然半夜训练断了第二天才发现心态容易崩。

矩阵策略跑超参调优这个点确实香，我之前用本地grid search跑一次要半天，切到Actions上并行省了至少三分之二时间。不过artifact存储上限是真的烦，模型一大了就得自己搭对象存储中转。模型版本管理这块我是用DVC配合git lfs搞的，回滚直接切commit再重跑对应workflow，虽然笨但还算稳，你们有没有更优雅的方案？

矩阵策略跑超参调优这个确实香，我之前试过用Actions同时跑十几个超参组合，比本地排队快多了。不过self-hosted runner挂GPU的话，网络和存储的瓶颈也挺头疼的，尤其artifact超过10G就得走外部存储了。模型版本管理我后来是结合DVC做的，把checkpoint和metrics推到S3，actions里只存个指针，能绕开限制。

这个帖子确实点出了一个被很多人忽视的方向——GitHub Actions的边界远不止CI/CD那点事。我最近半年一直在折腾类似方案，把Actions当成轻量级ML编排引擎来用，踩了不少坑也攒了些心得，正好借这个帖子展开聊聊。

先说你提到的矩阵策略跑超参调优，这个我深有体会。我之前在做一个时序预测模型，需要调优的维度包括窗口大小、LSTM层数、学习率和dropout率，如果用本地单机Grid Search，按照3x3x3x3的组合就是81次训练，每次跑完得3小时，总计243小时，根本不可能在合理时间内完成。后来用Actions的矩阵策略，配置成include模式，每次跑一个组合，并行度拉到理论上限20个job（免费用户同时只能跑20个），实际完成时间压缩到了4轮次左右。这里有个关键技巧：矩阵展开后，每次训练的输出要单独用artifact存储，并且命名规则里带上参数哈希值，否则后续对比时根本分不清哪个artifact对应哪组参数。我当时的做法是在run步骤里把参数写入一个metadata.json，和模型权重一起打包，这样下载后能直接解析出超参组合和对应的验证指标，方便后续筛选。

关于self-hosted runner挂GPU，你提到训练时间缩短40%，这个数据其实偏保守了。在大部分深度学习场景下，GPU加速比CPU快一个数量级是常态。我自己组了一台双卡3090的机器，挂成self-hosted runner，跑ResNet50的迁移学习，单次训练时长从CPU的6小时压缩到22分钟。但这里有个血泪教训：runner的隔离性问题。如果你把宿主机直接注册成runner，多个job同时执行时会抢占GPU显存，导致OOM崩溃。解决方案是每个job启动前用nvidia-smi检查显存占用，如果低于阈值就等待，或者更优雅的做法是用Docker容器封装环境，在actions-runner里启动容器时通过--gpus '"device=0"'这样的参数做显存绑定，配合矩阵的job索引实现容器级别的显存隔离。我现在的做法是在工作流里先执行一个check-gpu步骤，用Python脚本轮询显存，确认空闲再往下走，虽然增加了少量等待时间，但避免了训练中途挂掉的惨剧。

artifact存储上限和执行时间限制确实是硬伤。免费版500MB的artifact存储，对于模型权重动辄几百MB甚至上GB的场景来说，跑几次就满了。我的妥协方案是：artifact只存训练过程的中间产物，比如loss曲线图、最佳checkpoint的SHA256摘要、超参配置等轻量内容，真正的模型权重和数据集直接推到Hugging Face Hub或S3。在工作流里用huggingface_hub的Python SDK上传，配合token认证，比artifact灵活得多。执行时间限制方面，免费版是6小时，我遇到过几次超时的情况，后来用分阶段策略解决：把长任务拆成多个workflow_run事件触发。比如第一阶段跑数据预处理（2小时），完成后触发第二阶段训练（4小时），第三阶段评估（1小时）。每个阶段单独一个workflow文件，用workflow_run的workflow字段串联。虽然增加了配置复杂度，但突破了单次执行时间限制，而且每个阶段失败后可以单独重跑，不必全部重来。

你提到的模型版本管理和回滚问题，这正是当前方案最薄弱的环节。GitHub Actions本身不提供模型版本管理能力，只能靠外部工具补。我试过两种方案：第一种是结合DVC，把模型文件加入DVC跟踪，在Actions里执行dvc push到S3，同时生成一个版本标签提交到Git仓库。这样每次训练后，Git仓库里记录的是.dvc文件（指向S3上的模型快照），而S3上保留所有历史版本。回滚时只需要checkout到历史commit，然后dvc pull即可。但DVC有个坑：它和Git深度绑定，如果你的训练流程里同时修改了代码和数据，dvc status会检测到变化并自动触发重新缓存，容易造成版本混乱。我的经验是严格分离代码变更和模型变更——代码提交单独走PR，模型训练只更新.dvc文件。第二种方案是MLflow，更轻量但需要自建tracking server。我试过在Actions里启动MLflow server作为service容器，但免费版不支持service容器，只能自建runner。后来改用mlflow的本地文件存储模式，在工作流里每次训练生成一个mlruns目录，训练结束后把整个目录打包成artifact。回滚时下载对应artifact，用mlflow models serve加载。但这种方式对artifact存储消耗很大，一个实验几十个run下来，mlruns目录容易膨胀到几百MB。目前我倾向于DVC方案，因为它天然适合Git工作流，团队协作时模型变更能被review，这是MLflow做不到的。

关于在Actions里跑大规模训练是否划算，你算的2小时临界点我基本认同，但具体要看GPU类型。如果用免费提供的ubuntu-latest runner（只有CPU），成本确实比租专用实例高——因为CPU训练效率低，按执行时间计费其实更贵。但如果用self-hosted runner挂自己的GPU，成本主要是电费和硬件折旧。我算过自己那台双卡3090，满载功耗约700W，按国内电价0.6元/度算，每小时电费0.42元，加上硬件折旧（按3年残值30%算），每小时总成本约1.5元。而租用AWS的p3.2xlarge（单卡V100）按需价格是3.06美元/小时，差距近15倍。所以对于小团队，如果已有闲置GPU硬件，self-hosted runner的经济性碾压云服务。但有个隐性成本：维护runner的运维精力。我刚开始时每周要处理两三次runner掉线问题，后来用docker-compose编排runner容器，配合watchdog脚本自动重启，才算稳定下来。

从行业趋势看，GitHub Actions正在模糊CI/CD和MLOps的边界。但说实话，GitHub官方对ML场景的支持还停留在很初级的阶段。比如artifact的过期策略不够灵活，不能针对文件类型设置不同的保留期限（模型权重想永久保留，日志只想保留7天）。再比如缺乏对GPU资源的原生调度，还是得靠self-hosted runner自己折腾。我注意到GitHub最近收购了Pull Panda，但收购案和ML关系不大。倒是GitLab的Auto DevOps已经支持模型部署到Kubernetes，还集成了MLflow。GitHub Actions如果想在ML赛道站住脚，至少需要提供：1）内置的artifact版本管理，支持按标签或commit回溯模型文件；2）GPU runner的官方支持，甚至提供免费的GPU额度（哪怕每周几小时）；3）与Hugging Face或MLflow的原生集成，一键发布模型到Hub。

最后分享一个我觉得很有潜力的玩法：用Actions做模型监控的数据收集。我把训练好的模型部署到云端后，写了一个定时触发的workflow，每天从生产环境拉取预测结果和真实标签，计算指标漂移（如PSI、KL散度），如果超过阈值就自动触发重新训练。这个workflow不依赖任何外部调度器，完全靠GitHub Actions的schedule事件和cron表达式。目前跑了两个月，稳定性和准确性都还不错。具体实现是用Python的scikit-learn计算分布指标，结果推送到一个GitHub Issue里作为监控报告，如果指标异常就用issue的label标记“retrain_needed”。这样整个监控和告警闭环都在GitHub生态内完成，对团队协作非常友好。

当然，这个方案也有天花板。当模型数量超过10个、训练频率超过每天一次时，Actions的并发限制和artifact管理会变成瓶颈。到时候要么升级到GitHub Enterprise，要么迁移到专门的MLOps平台。但对于起步阶段的小团队，Actions确实提供了一个零成本的ML工程化入口——你不需要懂K8s，不需要维护Jenkins，甚至不需要一个正经的服务器，只需要一个GitHub账号和一份yaml配置，就能跑起一套完整的AI流水线。这种低门槛正在吸引越来越多非纯技术背景的人参与进来，比如数据科学家可以直接在PR里看到模型指标变化，产品经理通过GitHub Issue跟踪模型版本。从这个角度看，Actions对AI工程化的推动意义可能比技术本身更大。

矩阵策略跑超参调优这个思路确实香，我之前也试过用GitHub Actions并行跑不同的模型配置，省了本地排队的时间。不过你提到的artifact存储上限和运行时长限制，我后来只能用外部存储加断点续传来绕开，有没有更好的方案？另外模型版本管理那块，你是直接靠git tag还是用了DVC之类的工具？

矩阵策略跑超参调优这招确实香，我之前拿它试过网格搜索，并行度拉满比单机快了好几倍。不过artifact存储上限真的烦，大模型checkpoint动不动就超限，后来我改用self-host

ed runner直接挂NAS才算解决。模型版本管理这块，我目前是结合dvc把元数据存git，实际文件放s3，actions里再加个模型注册步骤，虽然麻烦但至少能回滚。你们有更好的方案吗？

矩阵策略跑超参调优这点确实香，我之前用本地Grid Search跑一次要一宿，换Actions并行后两小时搞定。不过self-hosted runner挂GPU那个网络配置折腾了我两天，后来发现直接用官方提供的GPU runner镜像能省不少事。模型版本管理这块我目前是搭了个MinIO当中间存储，配合DVC做版本追踪，虽然麻烦点但至少不会丢中间结果，你们有更好的方案吗？