騰訊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 之后，下一個范式轉換。

點個“愛心”，再走 吧