Stop Merging Yourself: The Truth About Mid-Cycle Finetunes. 别再融自己了！微调模型的“套娃”困局

📌 Quick Disclaimer Before we start: This article is just my personal opinion and my own attempt to explain what I've been observing in the ecosystem. It definitely won't cover every single case out there, so take it as food for thought! 🙏

🧬 Model Inbreeding: Why Mid-Cycle Models All Look the Same

Every time a new open-source base model drops on Civitai, the lifecycle follows the exact same pattern. 🚀 In the early days, there is wild experimentation—every creator is testing raw ideas, training fresh concepts, and producing distinctly different aesthetics. Then, a few months in, we hit the mid-cycle plateau. 📉 Suddenly, you scroll through the feed and realize almost every new checkpoint produces the exact same faces, the same lighting, and the same textures. 👯‍♀️

Why does the ecosystem homogenize so fast? It isn't because the base model ran out of potential. It happens because of blind recursive merging, hidden recipes, and accidental LoRA stacking. 🥞

🎭 The Illusion of "Built From Scratch"

As @lonecatone23 recently pointed out in the community, actual checkpoint training—creating epochs, block tuning, or using a semantic vector tuner—is something incredibly few people actually do.

Yet a lot of big creators still claim they have built everything from the ground up and stated as "checkpoint trained" when that is not necessarily the case. 🤫 Take Krea 2, for example. So far, I have only seen one model that appears to have been genuinely trained from scratch. The rest seem to be hiding what they are actually doing while pretending they are better than everyone else.

To be clear, this isn't an argument about copyright or gatekeeping. 🤝 Merging and collaboration are great for the community, and not every creator has an obligation to share their secret recipe—keeping your formula private is completely fine, and disclosure should always be voluntary. However, when almost nobody shares what is already inside their checkpoint, it creates a massive technical blind spot for everyone else who merges models. 🧑‍🦯

For my own workflow, my models might incorporate a few open LoRAs, but for most of my releases, I keep 70% to 80% originally trained LoRA and content inside. 🎨 That high ratio of original training data is what keeps a model visually distinct when everything else on the platform starts blending together. ✨

💍 The "Long-Lost Sister" Problem: How Model Inbreeding Happens

💡 Just an honest tip from me: always merge from the base model, not a finetune nor a mix of someone else's finetune. It really helps the ecosystem. 🌱

Well, not to name names... 🤐 but while I was digging around on Loraholic's site, I stumbled upon something pretty nasty. Let's say Person A releases Checkpoint A V1. Then Person B takes Checkpoint A V1, merges it with their own checkpoint, and releases the result as Checkpoint B V1. 🔄

Then Person A comes across Checkpoint B and thinks, "WOW, this is exactly my type!" 😍 (Well, of course it is—Person B literally merged Person A's checkpoint into it. 😂) So Person A decides to merge Checkpoint B back into their own model, creating Checkpoint A V2.

Since they both set their checkpoints to "no merges allowed," they would NEVER think they are merging their own checkpoint. 🙈 And the LoRAs kept stacking and stacking... 📈

It's just as dramatic as finding out your wife is actually your long-lost sister AFTER you've already married her 😱, and the kids (the resulting models) will have high health and genetic risks. 🧬⚠️

🧮 The Math Behind Over-Baked Weights

When checkpoints get recursively merged like this, the same popular LoRAs get baked into the ecosystem dozens of times over. 🔥 You end up with "same-face syndrome," fried contrast, plastic skin textures, and broken prompt adherence—not to mention that external LoRAs suddenly stop working properly. 💥

@Loraholic recently shared hard numbers showing just how widespread this is:

💬 "One major problem is that this practice puts LoRAs in a bad spot. I have scanned 272 checkpoints the last few days, and 128 of them have Realism Engine v3 by @razzz baked into the models. So if people use that LoRA themselves, they can end up with the LoRA at way above 1.0 strength without even knowing it. And users will think its the LoRAs fault. For example FinePorn v3 FIX has Realism Engine V3 baked in at 0.5 strength, so if you use Realism Engine V3 at 1.0 on that checkpoint you will probably get a pretty bad image since you practically using the LoRA at 1.5..."

When nearly half of the scanned checkpoints secretly share the exact same baked-in LoRA weights 📊, it is no mystery why every mid-cycle model starts looking identical—and why applying your favorite LoRA on top of a new checkpoint suddenly ruins the output.

🛠️ How We Can Fix It (And Where Civitai Can Step In)

We don't need to force creators to give up their secret recipes to solve this. Instead, we can tackle model homogenization from two angles:

✅ Voluntary Transparency & Base-Model Merging: If you are a merger, try starting from the clean base model rather than stacking finetunes on top of finetunes. And if you are comfortable sharing which public LoRAs are already baked in, doing so helps downstream mergers avoid accidental double-stacking and helps users know which LoRAs they don't need to add in their prompts. 📝

🔍 A Native LoRA Weight Detector on Civitai: Right now, dedicated community members like Loraholic and @lonecatone23 have to spend their own Buzz downloading checkpoints just to scan them and build third-party databases from scratch 💸. Civitai could easily step in and build an automated LoRA weight detector directly into the platform just like Loraholic did. Because Civitai already hosts all the checkpoint and LoRA files on their servers, they already have the entire database needed to run weight comparisons natively. 🖥️ Even if a creator wants to keep their exact recipe private, Civitai could automatically warn a user when they try to apply a LoRA that is already baked into a checkpoint ⚠️, or give mergers a heads-up before they accidentally marry their own model's long-lost sibling. 😂

If we want open-source model lifecycles to stay fresh, diverse, and creative past the mid-cycle mark, we have to stop blindly recycling the same weights—and start paying attention to what is actually under the hood. 🚗🔧

📌 免责声明：本文仅代表我个人的观点，只是我试图从自己的视角去解释目前观察到的社区现象，肯定无法涵盖所有情况，大家当成抛砖引玉、理性探讨即可！ 🙏

🧬 模型“近亲繁殖”：为什么中期大模型全都撞脸了？

每次 Civitai 上发布一个新的开源底模（Base Model），它的生命周期几乎都在重复同一个剧本。🚀 刚出来的那段时间可谓百花齐放——大家都在尝试新思路、训练新概念，产出的画风各有千秋。但只要过上几个月，到了生命周期的中期，瓶颈就来了。📉 当你刷着模型列表时，会突然发现几乎所有新出的大模型（Checkpoint）都在生成一模一样的脸、一模一样的光影，甚至连皮肤质感都如出一辙。👯‍♀️

为什么整个生态同质化得这么快？真不是因为底模的潜力被榨干了，罪魁祸首其实是盲目的“套娃式融合”、藏着掖着的配方，以及不知不觉中的 LoRA 权重无限叠加。🥞

🎭 “从头训练”的幻觉

正如社区里的 @lonecatone23 最近指出的那样，真正意义上的大模型训练——跑 Epoch、做分层调优（Block Tuning）或者用语义向量调优——真正去干这些苦活的人少之又少。

但很多头部创作者依然喜欢号称自己的一切都是“从零开始独立训练”的，事实却往往并非如此，很多模型写着“Checkpoint Trained"但是其实都是 "Checkpoint Merge"。🤫 就拿 Krea 2 来说，到目前为止，我只看到过一个模型是真的像从头训练出来的。剩下的大部分都在藏着掖着自己实际的套路，同时还要摆出一副比所有人都高明的姿态。

先把话说明白，我今天不想谈什么版权纠纷或者道德绑架。🤝 模型融合（Merge）和社区共创本身是件好事，而且没有任何创作者有义务公开自己的独门配方——想保留点商业机密完全没问题，公开配方永远应该是自愿的。但问题是，当几乎所有人都不透露自己的大模型里已经塞了什么东西时，就会给其他做模型融合的人挖下一个巨大的技术盲区。🧑‍🦯

拿我自己的工作流来说，我的模型有时也会融入一些开源的 LoRA，但在我发布的绝大部分模型里，我都保持了 70% 到 80% 自己原创训练的 LoRA 和素材。🎨 正是这种高比例的原创训练数据，才能保证当整个平台的模型都开始“撞脸”时，我的模型依然能保持一眼就能认出来的独特质感。✨

💍 “娶了失散多年的亲妹妹”：模型近亲繁殖是怎么发生的

💡 给大家分享一个我个人的肺腑之言：做融合时，永远要从最干净的底模（Base Model）开始融，千万不要拿别人的微调模型（Finetune）或者别人融出来的模型去二次融合。这对整个生态真的太重要了。 🌱

我就不点名道姓了……🤐 前阵子我在 Loraholic 的网站上扒数据时，撞见了一件相当离谱的事。假设创作者 A 发布了大模型 A V1。接着创作者 B 拿了 A V1，跟自己的模型融了一波，改头换面发布为大模型 B V1。🔄

过了几天，创作者 A 刷到了大模型 B，心里一惊：“卧槽，这画风也太对我的胃口了吧！” 😍（废话，能不对胃口吗？B 里面本来就融了 A 自己的模型！😂）于是 A 高高兴兴地把大模型 B 又融回了自己的模型里，发布了大模型 A V2。

因为这俩人都把自己的模型权限设置成了“禁止融合（No merges allowed）”，谁都没往外说，所以他们做梦都想不到，自己居然在融自己的模型！🙈 结果就是，里面的 LoRA 权重像叠 buff 一样越叠越厚、越叠越炸……📈

这剧情有多狗血呢？就好比你结了婚之后才发现，自己老婆居然是失散多年的亲妹妹 😱——这么“近亲繁殖”下去，生出来的孩子（最终融出来的模型）能没有严重的基因缺陷和健康风险吗？🧬⚠️

🧮 权重“过熟”背后的数学账

当大模型像这样被反复“套娃”融合时，市面上那几个热门的 LoRA 就会被翻来覆去地烤进整个生态圈里几十次。🔥 最终的结果就是严重的“千人一面”、对比度过曝炸裂、皮肤像塑料一样假，提示词也不听使唤了——更别提当你自己再去挂载外部 LoRA 时，画面直接崩盘。💥

@Loraholic 最近晒出了一组硬核数据，直接揭开了这种现象有多普遍：

💬 “这种做法最大的问题就是把 LoRA 推到了一个很背锅的境地。过去几天我扫描了 272 个大模型，发现其中居然有 128 个都在里面偷偷融进了 @razzz 制作的 Realism Engine v3。如果用户在不知情的情况下自己又挂载了这个 LoRA，实际生效的权重就会远远超过 1.0。生出来的图崩了，用户还会觉得是 LoRA 本身做得烂。举个例子，FinePorn v3 FIX 这个模型里已经以 0.5 的权重内置了 Realism Engine V3，如果你在这个大模型上再用 1.0 的权重去挂 Realism Engine V3，你大概率会得到一张惨不忍睹的废图，因为你实际上把权重开到了 1.5……”

当市面上将近一半的大模型都在暗地里共享同一套内置的 LoRA 权重时 📊，也难怪到了中期所有模型看起来都跟一个模子刻出来的一样——更难怪你把平时最好用的 LoRA 往新模型上一挂，出图效果当场翻车。

🛠️ 我们该怎么破局？（Civitai 官方其实可以出手）

要解决这个问题，我们并不需要强迫创作者交出自己的独家配方。相反，我们可以从两个方向来打破这种同质化僵局：

✅ 自愿透明化与坚持从底模融合： 如果你平时也做模型融合，请尽量从干净的官方底模开始，不要在别人的微调模型上继续“叠罗汉”。同时，如果你愿意顺手公布一下模型里已经烤进去了哪些公开的 LoRA，不仅能帮后面的融合者避开“近亲繁殖”的坑，也能让普通玩家知道写提示词时不需要再重复挂载哪些 LoRA。📝

🔍 Civitai 官方推出原生的 LoRA 权重检测器： 目前，像 Loraholic 和 @lonecatone23 这样热心的社区成员，只能自掏腰包花着大量的 Buzz 去下载那些抢先体验的大模型，只为了挨个扫描它们、从零搭建第三方数据库 💸。其实 Civitai 官方完全可以出手，像 Loraholic 那样直接在平台内部做一个自动化的 LoRA 权重检测器。毕竟所有的模型文件和 LoRA 权重本来就存放在 Civitai 自己的服务器上，官方手里有着现成的全量数据库，在后台跑个权重比对简直轻而易举。🖥️ 就算创作者想给自己的配方保密也没关系，Civitai 完全可以在不公开具体配方的情况下，当用户试图挂载一个模型里已经内置的 LoRA 时弹出一个“权重冲突预警” ⚠️，或者给做融合的创作者提个醒，免得大家一不小心又娶了自己模型“失散多年的亲妹妹”。😂

如果我们希望开源模型的生命周期在走过中期之后，依然能保持新鲜感、多样性和创造力，我们就必须停止盲目地反复回锅同一套权重——是时候看清引擎盖底下到底装了些什么了。🚗🔧