腾讯HY- WU要捅模型天花板：让模型每次任务都生成个新大脑

作者 ｜ 董道力
邮箱 ｜ dongdaoli@pingwest.com

你有没有过这样的经历，同样的模型，别人都在说多么好用，而你用下来不如预期。

GPT-5 刚出来的时候，benchmark 全面领先，但大批用户吐槽它没人味。写东西僵硬，失恋安慰不如老款 GPT-4o，重度用户直接说它"距离成为一块石头也不远了"。

OpenAI 的应对方式就是多训几个模型，写代码的、通用能力的、适合对话的。

这背后藏着一个根本问题：一套参数做不好所有事。

过去三年，AI 行业花了几千亿美元训练大模型，参数量从几十亿卷到几千亿。但有一件事很少有人停下来想：不管模型多大，微调之后，它处理每一个用户请求时用的都是同一套固定参数。任务一多、方向一矛盾，这套参数就被迫在互相冲突的需求之间妥协，每件事都在打折扣。

腾讯混元团队 3 月 6 日发了一篇技术报告 HY-WU，想挑战这个限制了今天大模型能力的天花板：当任务足够多样甚至互相矛盾时，不存在一套参数能同时把所有事做好。这是个结构性的死胡同，跟训练充不充分没关系。

如果他们的解法被验证是对的，大模型可能又要出现个新范式。

1

一套参数服务不了所有人

预训练好的大模型是个通才，什么都懂一点，但在具体任务上不够精。

要提升表现，需要在特定任务数据上再训练一轮，也就是所谓的微调。全量微调要调所有参数，成本很高。2022 年出现的 LoRA 换了个思路，不动原来的参数，在旁边加一小组新参数，只训练这一小组。参数量不到原模型的 1%，效果却接近全量微调，很快成了行业标配。

但 LoRA 也好，全量微调也好，都没有改变一个事实：调完之后参数就固定了，所有请求共用同一套。

如果你有生图经历就明白，每次运行都要加载对应的 LoRA。选错 LoRA 很容易产生不可名状的图片。

混元在报告里举了个更极端的例子，一个模型可能要同时处理"修复老照片"和"做旧照片"，前者让模糊变清晰，后者让清晰变模糊。一套固定参数同时学这两件事，两边都凑合。

报告分析了 60 种编辑任务、12000 个样本做了梯度分析去验证这个猜想，结果的确如预期，不同任务对参数的调整方向经常相反，硬塞到一套参数里会互相抵消。

那给每种任务单独训练一套参数？冲突是避免了，但会过度特化，而且任务需求是无穷的，每个都匹配的话，存储和管理成本撑不住。

RAG 之类的检索增强也帮不上忙，它能改变模型"看到了什么"，但改变不了模型"怎么处理信息"。当任务核心是变换规则而不是缺失事实时，塞再多上下文也没用。

传统方法把适配理解为"在参数空间里找一个最佳点"，但任务多样且矛盾的时候，这个点不存在。

1

现场生成参数

我们再来看混元的 HY-WU 是怎么做的。

传统方案都是"静态参数记忆"，把新知识压进一个固定点，推理时所有请求共用。HY-WU 换了一种记忆方式，报告叫它功能性记忆，不找空间中固定的参数点，而是训练一个参数生成器，每次收到具体输入，实时合成一套专属参数，用完即弃。模型记住的不是某一组固定权重，而是"什么条件下该生成什么样的权重"这个映射关系。

同样用生图举例，当模型接收到你想要老照片修复，就会训练个高清、提高饱和度的参数，当接收到生成老照片，则训练个对立的参数。

具体来看，HY-WU 分了三步，为了方便理解，我们可以把 HY-WU 看作是一个裁缝，为每个需求定制参数。

第一步，量体。

一个视觉语言编码器同时看输入图片和文字指令，搞清楚两件事：这张图是什么样的，用户想对它做什么。这些信息被压缩成一组条件特征，相当于客人的身材数据和款式偏好。

第二步，裁衣。

条件特征送入一个 8B 参数的 Neural Network Transformer。这个 Transformer 跟平时见到的不太一样，它输出的不是文字或图片，而是一整套 LoRA 权重，共 0.72B 参数。

你可以理解为，它根据身材数据现场算出了一套裁剪方案。收到"修复老照片"的请求，裁出来的是偏向增强细节的参数；收到"做旧照片"，裁出来的方向完全相反。整个过程在 80B 的基座模型上只需几秒。

第三步，上身。

生成的 LoRA 插入基座模型，执行编辑。基座模型始终不动，每次推理只是临时换一套 LoRA，用完就丢。

HY-WU 还解决了一个工程上的难点。基座模型每层的 LoRA 形状不同，论文设计了一套基于 LoRA rank 的锚定切块方案，把不同形状的矩阵统一裁成相同大小的 token，让生成器能像处理文字序列一样逐个生成参数块。

架构搞定了，接下来是怎么训练这个生成器（裁缝）。

之前的超网络方法有点像先让 100 个裁缝各做一件样衣，收集起来当模板，再训练一个新裁缝去模仿这些模板。

HY-WU 跳过了收集模板这步。训练是端到端的，生成器根据输入生成一套 LoRA，装进基座做编辑，看编辑效果好不好，把反馈传回来调整生成器。不需要预收集 checkpoint，不需要存储 LoRA 权重库。几百万次迭代之后，生成器从最初的随机输出，慢慢摸索出了针对不同输入该生成什么样的参数。

1

HY-WU 的效果如何

人工偏好评估里（GBS），HY-WU 对主流开源图片编辑器的胜率在 67%到 78%。对闭源商业模型也有优势，对 Seedream 4.5 胜率 55.6%，对 GPT Image 1.5 胜率 55.5%。只是略低于 Nano Banana 系列。

跑分之外，有一个问题需要回答：HY-WU 的提升到底来自哪里？是因为多了一个 8B 的生成器带来了更多参数，还是因为"根据输入定制参数"这个机制本身？

论文设计了两个实验来拆解这个问题。

第一个实验，把生成器对大量样本生成的 LoRA 全部取平均值，得到一套"均码 LoRA"，然后固定用这套均码来处理所有请求。生成器还在，参数量一个没少，但每个请求拿到的 LoRA 都一样了。相当于裁缝还在，但不管谁来都给同一个尺码。结果：性能立刻掉回基线，跟没有 HY-WU 差不多。

第二个实验，生成器照常工作，但把输入条件随机打乱，A 的图片配上 B 的指令去生成 LoRA。生成器还在动态生成，但生成的参数跟实际输入对不上了。相当于裁缝还在量体裁衣，但把张三的尺寸用在了李四身上。性能同样不行。

通过两个实验，验证了参数多不多不是重点，关键是每个输入能拿到跟自己匹配的那套参数。

1

改变模型发展的下一个范式？

回顾大模型发展史，真正改变行业走向的技术节点并不多。

2017 年的 Transformer 架构奠定了基础。2022 年的 LoRA 解决了微调成本问题，让适配大模型不再是大厂专利。MoE 打破了"参数越多推理越慢"的限制，通过路由机制让模型在保持大参数量的同时只激活一部分。思维链让模型学会了"分步推理"，o1 和 R1 系列靠它在数学和编程上取得了突破性进展。

这些技术有一个共同点：它们各自解决了模型"怎么建"或"怎么想"的问题。但有一个问题始终没人动过，模型建好之后，面对不同用户、不同任务，怎么用同一套参数给出差异化的最优响应？

行业的默认答案是，训更多模型。大厂的模型名字一只手数不过来，开源社区里 LoRA 权重库堆了几万套。

HY-WU 切入的正是这个空白。MoE 在模型内部做路由，HY-WU 在模型外部做路由。

当然，现在说 HY-WU 能达到 MoE 或思维链那样的行业影响力还为时过早。它目前只在图片编辑上验证过。而接下来他们也提出了多个未来的探索方向，包括对记忆的“新旧”的处理，对容量分配的处理，能不能有更通用的接口，从图片到视频和 Agent的更广泛的应用等。

模型的进化不只是"更大"或"更会想"，还应该包括"更懂得因人而异"。如果后续能在语言模型、视频生成、Agent 等场景复现类似的效果，它有可能成为继 MoE 之后，下一个范式转换。

点个“爱心”，再走 吧