最近工作中的时候遇到了这样一个问题，出于一些原因我们需要部署一个flux模型，我使用huggingface pipeline将这个模型跑通之后，在公司内网搭建了一套简易的api供其他项目的一些模块调用，之后要上传gitlab的时候 ，我发现存在一个很大的问题，由于工作场景中需要将模型完全上传，但是这个模型本体整个文件有50GB以上，尽管我们的gitlab是转门调整过上传文件的尺寸上限的，可以传几个GB的文件，但对于flux模型还是不太够用，于是我开始调查相关的解决方案。
LLM告诉我一般的方法是使用LFS，这个功能我很快通过LLM学习并运用到当前项目上， 尽管有一些warning，但是实测是能正常上传和下载大文件的。我称之为第一版，将其部署在一台机器上并提供了服务。
之后我面临另一个问题， 项目中用到的是flux-fill的模型，但是随着项目发展，后面越来越多的需要用到flux-dev的模型来进行文生图，按理说只要将flux-dev也加到项目中就好了，但是实际测试中显示，flux-fill模型和flux-dev的使用会互相冲突，一个模型使用时，换用另一个模型需要加载很长时间，因此不得不考虑两个模型拆开来放到两个独立的项目中分开部署到两台不同的机器上。但是这让我感觉很不爽，毕竟他们本来应该是一个项目中的类似的功能。因此考虑许久后结合GPT4o的建议，我又将项目做了重构，不再用LFS上传模型，而是采用使用时下载模型的设计方式，这样在一个项目内就可以根据配置文件选择可以提供何种api，并在初次调用的时候下载模型，不会有无意义的空间占用。这个版本我称之为第二版。
好景不长，第二版刚刚提交之后，项目就遭到了质疑，我的导师认为这样的设计会导致每次部署都要向huggingface那个不可靠的服务器去下载模型，会影响项目的可用性，这点我自己也深受其害，所以也能理解。于是我不得不放弃这个思路，重新回退到第一版，将其重命名为pro分支。回退后flux-dev的接口无法使用了，但是之后flux-dev的需求依然存在，必须想办法把相关的api重新提供出来。这时我又投向了开始时考虑过的另一种解决方法，就是把两个模型作为git的两个分支，使用哪个模型就下载对应的分支，这样还是在同一个项目内，也不用下载多余文件。
按照这一思路，我又从第一版的pro分支上做了改造，之后分出来两个新的分支fill和txt2img，并且合并了第二版的main分支，使其看起来相对简洁，且每个分支都很直观。这个可以称为第三版。
我想这大概是目前能提供的最好的解决方法，为了实现优雅而简洁的开发和部署，投入了非常多的精力。尽管还有一些问题，比如说，我在我的电脑上开发的时候不需要使用模型文件，那么整个项目应该在clone时避免下载lfs文件，这个操作可以通过设置来实现，可是model虽然没有下载，但是当前的.git文件达到了惊人的30GB，这应该是某个环节中有错误的上传操作，但是由于此前的操作过多，很难搞清楚是哪一步的问题，还要想办法将这部分的历史记录清除，这样才能达到最终的状态。
后日谈：
又过一周后，我抽空开始调查.git的压缩方法，因为GPT-4o告诉我这部分并不是必须的，于是我将fill分支的.git/object的文件删除后提交到远程，但是当我重新拉取项目，.git又变成了30GB，GPT的说法是lfs还存在于历史中，之后我又按照它的指示将lfs从历史中排除，重写了历史，历史因此将fill独立成一条全新的分支路线，之前的提交都被复制了一份，在graph里看着非常难受，但这还好说，当我再次拉取项目时，lfs完全没有了（这是自然），于是我再次问了grok和claude-sonnet，它们的意见和GPT-4o难得的出现了冲突，想要下载lfs文件，就必须有庞大的.git，但是本机不需要的话可以删除.git/object，也不影响正常使用，情况大致就是这样。最后我还是找到txt2img分支，强制覆盖了远程仓库，好在只有我在上面工作。之后将本机的项目也删除后重新拉取，删除掉.git/object，一切正常了,真是实践出真知。当前阶段的项目功能都完善了，AI绘画要放一放了，短时间内也不会回来，以后有问题再说吧。