改进后问题得到了解决。
首先是git上的流程图
注意t5-v1_xxl-encoder-bf16，hfmirror上搜的时候有一个看着名字很相似的t5-v1_1-xxl-encoder-gguf，然而并不是这个。。是这个https://hf-mirror.com/city96/t5-v1_1-xxl-encoder-bf16/tree/main
再有就是下图，上述工作流最好不要用分块vae。。。换成vae后问题消失。用xl和1.5习惯性用了分块vae。
8gb显存，32gb的内存schnell 3qs,最简单的工作流cfg1,步数5~10，1536x1536就到内存极限了。明天试controlnet

我没怎么用过xl，我只用过1.5和flux。经过我实测，dev fp8（comfyOrg版）版本速度比gguf版本的更快（Q6和Q4），按理来说，精度更低的Q6Q4速度应该更快才对。
我是4060ti 16G的显存，我最开始用的就是dev fp8（comfyOrg版），一张1024*1024的图，需要50多秒。但我感觉像是占用了内存条，所以我想换精度更低的gguf版本，希望只用显存来提升速度（不开显存优化）。结果试了Q6和Q4，不使用“显存优化”的话，加了lora之后依然会报显存不足，而且Q4的时间也不比dev fp8更快，那我还用gguf干嘛！
现在我就用dev fp8（comfyOrg版），然后开启显存优化。16G的内存感觉不够用，打算升级32G

controlenet，一言难尽。。。比较麻烦。。。最后还遇上虚空问题（明明回收站里是空的，但是电脑里看不到，disgenius也看不到，但是c盘的recyle回收站占了空间，everything能搜到。关键是sd居然认到存在文件还能执行？本来是zoe不是有一个.pt的文件要下载吗？其实我其他sd里有，所以我就想直接删了，复制一个。但是却发现everything里C:\$Recycle.Bin\S-1-5-21-2822533700-3907265573-3324224465-1001\$RF62T8X 删不掉，明明清空了回收站。以前我记的回收站一清，这个就消失了来着。。关键机子里看不到这个文件，但是sd居然能有指针什么的正常运行depth预处理？最后解决办法是网上搜到的把桌面回收站的属性，调成直接删除文件，然后把那个C:\$Recycle.Bin\里需要删除的回收站（好几个来着选对应的那个）删除好像是自动清空来着，一开始不敢删，所以去搜百度的。然后再改回来？吓得我以为系统有bug了。。几个gb的文件，占着地方，看不见还删不了。也不是System Volume Information），模型什么的都保存了，唯独唯独忘记保存工作流了。。。好在其实也不复杂，就是测试出的一些参考参数，挺费劲的。。。
再有就是不知道为什么，这个新装的秋叶包，更新到最新后，每次点一键启动后，就会弹出安装的框，但是好像断网也能安装，C:\Users\用户名\AppData\Local\Temp里面也出现pip之类的文件夹，然后又消失。。。那个框是一闪而过，结束就关闭的，也没法保存。还会出现一些类似tmpjx3zkx72cacert.pem的文件。。
说回controlnet，ipadapter没试。。好像报错。canny,depth,hed，这三个很占显存。。虽然也很占内存。内存情况不同有接近32gb的也有接近48gb的，也有奔到七十几gb的最后只能强行关闭。。
xlab的controlnet。。。我主要参考b站的一些视频。但是吧，也有报错的。。
schnell latent 预处理器分辨率
depth q3 20 1 3.5 1.0 1.0 1520x1008 768
canny q3 20 1 2.0 1.0 1.0 1520x1008 768
canny q3 20 1 5.8 1.0 1.0 1520x1008 768
canny q3 20 1 5.8 1.0 1.0 760x504 768
canny q2 15 1 3.5 1.0 1.0 760x504 512
canny q2 15 1 3.5 1.0 1.0 1024x1024 512
幸好记了一部分在txt上。
controlnet总结下来，很费时间，效果也不好。。步数越高能好，但是短的512x512也得1分钟到几分钟。。
假如1024x1024上到40步，保不齐得几十分钟。。10步等了六百多秒？记不清了。
效果也很一般。。肢体确实感觉能好一点，以及一部分细节也不错。但是整体效果，不好说，可能是提示词或者我设备不行步数没开太大，20步没有满意的。。反正不咋地吧，远没有显卡高负荷高温运算那么久带来的效果，至少和文生图相比的话。。wd-v1-4-moat-tagger-v2的反推。。因为这个controlnet，感觉小图不如大图，推荐写的好像就是1024x1024来着？
有一个schnell、dev、dev-fp8的选项，不能选schnell。会报错。但是Unet gguf可以选schnell的q系列。。bf16。
节点git上给的那个flux1-dev-fp8，我只能说我的机子带不动。。。好像512x512,10步等了六百多秒的就是这个？效果还不咋地。。浆糊一样。。
再有，不确定是分块vae的问题，因为vae也崩了一次。。但也只崩了一次。建议出图的时候别瞎点鼠标。。没准可能就触发什么通道占用？之类的。。反正看不懂DSA?

重新装一遍，进行测试一小部分。。参考https://www.bilibili.com/video/BV1DrsueAE9M/?spm_id_from=333.880.my_history.page.click&vd_source=eae410cf8897f74d0a3bce12782f8fd5
2070s8gb显存 32gb内存
步数越大速度越慢，效果越好。我只测试了80步，80步只是个门槛。。20步惨不忍睹。。
768*1024
20步一个是flux1-dev-fp8(11gb)540秒，一个q5.gguf是119秒。前者cpu占的多，占50%，后者几乎没有占。显卡一个50度，一个80度。
速度相差约等于5倍。
经测试，单纯文生图的情况下，步数和时间成正比关系。。步数翻一倍，时间也几乎翻一倍。
flux1-dev-fp8(11gb)k采样高级，ruler simper(用时和normal大概几乎一样),80步用时2103秒。。接近35分钟。768*1024分辨率。
牺牲显卡长期工作的情况下，也得除以五，预估7分钟。但其实我觉得上限远不止80。。。80只是图片人物比较正常。如果要出高质量的图，可能起码得160起步。。。
看各位配置了。。用前者160步的情况下，预估需要70分钟。后者至少15分钟（猜测，未必对。回头测更正）。但是后者倒地与前者质量相差多少未知。只能说低步数下各有千秋。。高步数我没测后者。。

不行。。。dev q5.gguf，经测试中途报错。这就是我说的显卡高负荷容易报未知错误。。
不是有人问有什么风险吗？未知错误？看下图。和之前截图的vae分块差不多的问题。

但是如果照目前的状况。。之前测controlnet只最多测了20步，80步用慢的，估计得挂机一个上午，几个小时来出一张768x1024的图？。。

本来想续传的，用save latent和load latent，但好像不太行。。。只有gguf奏效，但是vae上可能会有点问题，有点饱和的，背景细节简化的感觉。而dev-fp8+ksampler会变成图生图，cfg从1增大到5，会增大一点点点点细节和饱和度？并且增大步数可以改善手部等细节？

gguf是gguf大模型专用的，还得搭配它专用的加载器，这一套是给小显存用的。
没错，你8g就属于小显存

clip选择BF16格式似乎只对30系显卡才是合适的，之前的显卡不支持BF16，还要转换成FP16来运行，白浪费时间，那不如直接选FP16。40系显卡支持FP8了，选FP8似乎更好点。而20系及之前的显卡，虽然可以选FP16，但也可以选Q8来节省读盘时间和显存，应该也不会有明显影响，当然无论哪种显卡都可以选更低位数的量化。