前陣子騰訊混元放出 Hy4 Preview 的消息時我身邊的算法群和工程群又熱鬧了一輪。核心關注點其實就一句話從 Hy3 的 295B 到 Hy4 Preview 的 770B這不是簡單把參數量往上翻一倍多而是模型底座、推理代價和應用邊界的同步變化。再加上近期“2D 轉 3D”這類生產力場景頻頻出現在各家 Demo 里很多非算法崗的朋友也跑來問我這個變化到底意味著什么。這篇東西不是官方文檔的復述更多是我從評測、壓測和業(yè)務落地角度做的一些觀察和推算。先說結論Hy3 適合大多數已經跑通的文本密集型任務Hy4 Preview 則更像是沖著“復雜多模態(tài)理解 高成本高價值生產任務”去的。如果你只想做輕量客服、常規(guī)知識庫問答Hy3 那檔規(guī)模往往夠用但如果你要處理長文檔、復雜指令、圖片與三維資產生成這類重活Hy4 Preview 的架構優(yōu)勢會體現得非常明顯。下面我把整個鏈路拆開聊。1. 先說清楚這次“架構躍遷”到底在聊什么1.1 Hy3 與 Hy4 Preview 的定位差異很多人把 Hy3 和 Hy4 Preview 理解成“舊版”和“新版”的關系我一開始也這么以為但實際測下來發(fā)現它們更像是兩條產品線Hy3 是通用文本大模型雖然也有多模態(tài)擴展但核心能力還是集中在理解、生成、邏輯推理和知識問答上。Hy4 Preview 則明顯往“多模態(tài)生成 空間理解”方向走了尤其是 2D 轉 3D 這類任務的亮相說明它不只是多學了幾個任務而是在表征層面加入了更多視覺空間信息。換句話說Hy3 的 295B 是一個經過了大量真實場景打磨的通用底座工程上相對成熟對顯存和推理時延的要求也更可控。Hy4 Preview 的 770B 則是在通用能力基礎上把視覺、3D、長上下文和多步工具調用這些能力揉到了一起。這種定位差異決定了它們的適配場景完全不同。1.2 為什么用“躍遷”而不是“升級”我比較反感動不動就說“跨越式升級”但這次從模型結構角度看確實更像一次躍遷。原因主要有三點一是參數規(guī)模上了一個新的量級。295B 到 770B雖然很多人會拿“MoE 總參數大有水分”來質疑但總參數變大意味著可用的專家組合、知識容量和注意力頭容量都更寬裕。尤其對于長尾知識、多語種、復雜推理類任務參數容量帶來的提升不是線性的而是會在某些難度區(qū)間形成質變。二是能力的組合方式變了。Hy3 時代你要做文生圖可能要外接一個擴散模型要做 3D 資產又要再接一套重建流程。Hy4 Preview 給我的感覺是它試圖在一個模型內完成更多“從理解到生成”的閉環(huán)。這樣帶來的好處不只是少幾個接口而是理解任務的目標可以直接影響生成結果不需要在多個模型之間反復傳遞中間表示。三是工程代價完全不在一個量級。這里說的“躍遷”也包括負面意義上的躍遷。770B 的部署成本和推理成本比 295B 高出一大截如果模型沒有帶來足夠的生產力提升那這筆賬大概率是算不過來的。1.3 誰最該關注這次變化先給讀者做個定位方便大家決定要不要繼續(xù)往下看。如果你是大模型應用層的開發(fā)者正在做知識庫問答、Agent、長文檔分析我建議你重點看第 2 章和第 5 章。如果你負責推理平臺或者模型部署重點看第 3 章的顯存和配置推算。如果你做的是 AIGC 工具尤其是圖片轉 3D、生成式設計這類重視覺任務那第 4 章應該對你有參考價值。如果你是老板或者技術管理者想判斷要不要升級到新模型我建議先看完第 6 章的選型速查表再決定預算怎么花。2. 從 295B 到 770B參數背后的能力邊界發(fā)生了什么變化2.1 更大的總參數到底買到了什么業(yè)內對“參數膨脹”一直有爭議因為在一個 MoE 架構里總參數量大不等于每次推理都激活這么多參數。以常見的稀疏專家模型為例總參數里大部分是各個專家的權重真正每次計算只路由到其中的一部分專家。Hy3 的 295B 和 Hy4 Preview 的 770B實際激活參數可能并不會同步翻倍這是為什么有人會說“總參數字面上漲意義不大”。但從我的測試經驗看總參數仍然非常關鍵。一個直覺類比是一個公司可以有很多不常出面的專家雖然每處理一個項目只調幾個專家過來但專家?guī)煸酱竽芨采w的疑難雜癥就越多。Hy4 Preview 的專家數量大概率比 Hy3 更多專家分工也可能更細所以在多語種、垂直領域術語、復雜代碼、多模態(tài)對齊這些方面它能兜住的邊緣情況明顯更多。我做了個很土的測試把一堆長尾產品手冊、方言口語對話、帶噪聲的掃描件丟給兩個模型做信息抽取。Hy3 已經表現不錯但在一些極不規(guī)范的表述上會“一本正經地胡編”Hy4 Preview 在面對同樣輸入時明顯更傾向于引用原文或者承認信息不足而不是硬給一個看似完整的答案。這就是大參數容量帶來的“知識邊界感”也就是模型能意識到自己不知道什么。2.2 架構上可能動了哪些“看不見的地方”由于 Hy4 Preview 還沒有完全公開技術報告級別的細節(jié)我下面這部分是基于實測和行業(yè)對新一代 MoE 模型的通用觀察做的推斷不一定和官方最終描述完全一致但方向大概率不會偏太多。第一路由策略應該做了調整。295B 規(guī)模的 MoE 通常會把輸入路由到少數幾個專家但太大參數的模型如果還沿用粗粒度路由容易出現專家負載不均衡甚至某些專家淪為“死專家”。Hy4 Preview 給我的感受是它在不同任務上的行為一致性更高了這背后很可能是用了更細粒度的專家切分或者引入了額外的負載均衡約束。第二共享專家和專用專家的配比可能有變化。一類是幾乎所有 token 都會經過的共享專家負責通用語法、句法、基礎邏輯另一類是各管一攤的專用專家負責代碼、數學、多語種、視覺。Hy3 時代這種分工已經存在但 Hy4 Preview 的高參數量允許它塞入更多專用專家同時不犧牲共享專家的基礎能力。這也是為什么它在通用對話和垂直任務上同時有不錯表現。第三視覺和空間表征可能不再只是“把圖片切塊后當成文本 token”來處理。傳統(tǒng)多模態(tài)模型會把圖片經過一個 vision encoder 轉成若干向量再拼進文本序列這種方式對理解一張圖是夠用的但對“生成 3D 資產”這類任務是不夠的。因為 3D 重建需要的是連續(xù)的幾何信息、深度和視角關系而不是離散的語義標簽。Hy4 Preview 的 2D 轉 3D 能力能落地說明它在架構層面大概率加入了更接近三維重建的表征模塊。這一點如果后續(xù)開源細節(jié)出來非常值得單獨寫一篇拆解。第四KV Cache 的管理策略更重了。參數量變大通常伴隨著層數、注意力頭數的增加這會直接推高 KV Cache 的顯存占用。Hy4 Preview 如果還想做長上下文那就必須在注意力機制上做文章比如引入某種形式的跨層 KV 共享、滑動窗口注意力或者更激進地壓縮歷史 token 的緩存。從我拿到的上下文行為來看它在超長文檔中前文遺忘的現象比 Hy3 輕很多這明顯不是靠蠻力堆顯存能實現的。2.3 上下文能力與多模態(tài)輸入的連鎖影響參數規(guī)模變大之后上下文長度也會跟著成為一個重點指標。原因很簡單一個更大的模型如果能讀完整本產品手冊再做回答那它的生產價值遠高于只能讀摘要的模型。Hy4 Preview 在長文檔上的優(yōu)勢實測下來不只是“記得住開頭”而是能夠把散布在文檔不同章節(jié)的信息交叉引用起來這一點對法律文書、論文綜述和復雜項目報告類任務尤其重要。多模態(tài)輸入也會進一步“吃掉”上下文空間。一張高分辨率圖片如果被轉成幾百個 token那一次對話塞入十張圖可能就已經是幾萬 token 的消耗。Hy3 時代多模態(tài)輸入常常需要提前壓縮或者裁剪否則很容易超過窗口上限。Hy4 Preview 在這方面給我的感覺是它在輸入壓縮上做了更多工作圖片和文本的 token 配比更合理不會出現“一張圖占掉半屏”的情況。這個變化對生產系統(tǒng)有個直接好處你可以在一次請求里同時放入“參考圖片 技術規(guī)格 約束描述”讓模型一次性輸出一個結構化方案。這在 2D 轉 3D 場景里非常重要因為用戶經常需要提供多視角參考圖再附加材料和風格要求。如果上下文窗口不夠大就得把輸入的圖片分辨率降得很低最終生成物的細節(jié)自然也會受影響。3. 部署視角把 770B 跑起來需要付出什么3.1 顯存需求怎么算很多團隊看到 770B 的第一反應是“我連模型都裝不下”。這個直覺沒錯但要分情況看。如果使用 BF16 精度保存全部權重參數量每 1B 大約需要 2GB 顯存那么 770B 的權重就要約 1540GB折合下來至少需要 11 張 H200141GB 版本才放得下。如果換成 FP8 量化權重占用可以降到約 770GB8 張 H200 才能勉強裝上。但權重只是第一步。推理過程中還需要預留中間激活值和 KV Cache。KV Cache 的占用和序列長度、batch size、層數、注意力頭配置強相關粗略估算公式是KV Cache 占用 2 × 層數 × KV 頭數 × 頭維度 × 序列長度 × 每元素字節(jié)數舉個例子假設一個模型是 32 層、8 個 KV 頭、每個頭維度 128用 FP16 存 KV那么每個 token 大約要占 128KB。如果同時處理 16 個用戶、每個用戶上下文 32K token那么 KV Cache 總量大約是 16 × 32K × 128KB 64GB。這個規(guī)模已經不能忽視了。Hy4 Preview 如果想開很長的上下文KV Cache 的優(yōu)化能力基本決定了它能不能在真實業(yè)務里跑起來而不是只能作為離線評測玩具。3.2 我建議的中小團隊部署配置如果你所在的團隊不想一上來就建一個幾十卡的大集群我建議按下面的優(yōu)先級來規(guī)劃。第一版先別追求最長上下文和最大并發(fā)目標應該是“能穩(wěn)定把模型跑起來”。就現在的存儲和顯存情況FP8 量化是性價比很高的選擇推薦配置可以按照“權重占用 預留 30% 到 50% 的 KV Cache/激活空間”來算。如果用 H200 141GB 的卡單機 8 卡總顯存約 1128GBFP8 權重約 770GB剩下的約 358GB 留給 KV Cache單用戶 32K 級別的短會話場景基本夠用。但如果你的場景是幾十個用戶同時長文本對話就需要擴到 16 卡甚至更多。如果你只能用 A100/H 系列但單卡顯存只有 80GB那 8 卡也才 640GB連 FP8 權重都放不下。這種情況下要么上 INT4 量化要么接受更低的并發(fā)和更短的上下文。我的建議是別硬撐直接上多機方案或者用 Tensor Parallelism 把模型切到更多卡上。張量并行雖然會引入通信開銷但 770B 這種規(guī)模本身就沒法靠單卡解決所以一定要在框架層規(guī)劃好“切分粒度”。3.3 實測下來的關鍵推理參數經驗值在投入生產之前下面幾個參數我建議你優(yōu)先調溫度temperature。Hy4 Preview 的生成傾向比某些高隨機性的模型更穩(wěn)定但溫度開太高仍然會破壞結構化輸出。做數據抽取、JSON 生成、代碼補全時溫度建議壓在 0.2 以下做創(chuàng)意文案和概念設計時再放寬到 0.7 到 0.9。上下文截斷策略。別天真地以為“模型窗口是 128K 就真的能喂?jié)M 128K”。實際測試中長上下文的性能會隨長度衰減而且推理延遲和 KV Cache 占用會急劇上升。生產環(huán)境建議把系統(tǒng)指令、參考文檔、歷史消息分層管理超過閾值的部分做摘要壓縮而不是一股腦塞進去。批量大小batch size。MoE 模型在 batch size 比較大的時候如果專家分布不均衡部分卡會變成熱點從而拖慢整體速度。你需要通過觀察每張卡的實際利用率來判斷要不要降低并發(fā)。這個問題在 295B 的 Hy3 時代也存在但到 770B 后會被放大因為單卡需要承載的專家權重更多了。輸出長度上限。很多人容易忽略輸出長度對推理延遲的影響。Hy4 Preview 在長輸出任務上比如生成文章、3D 構建指令本身就能寫很長但如果你不設上限模型可能在一個無意義的追問里無限展開。建議業(yè)務側把 max_tokens 控制在一個符合任務預期的范圍內比如客服回復 512長文寫作再開到 4096。4. 生產力落地Hy4 Preview 為什么能扛起 2D 轉 3D 這類重活4.1 2D 轉 3D 的本質從視覺理解到空間生成最近“Hy4 2D 轉 3D”這個功能討論度很高很多人把它當成一個娛樂向玩法拿一張二次元圖片試了試就完了。但如果從生產力角度去理解2D 轉 3D 其實是一個非常典型的“高復雜度多模態(tài)任務”它要求模型同時具備三個能力準確識別圖片里的物體類別和邊界推斷圖片中沒有直接畫出來的背面、側面和深度關系把推斷結果轉化為可被渲染引擎使用的幾何數據。Hy3 那個量級能不能做其實也能做一部分但在復雜物體、遮擋區(qū)域和材質推斷上很容易翻車。Hy4 Preview 的 770B 參數為這個任務提供了更大的幾何先驗容量。你可以把它理解成模型見過足夠多的“同一個物體的多視角圖片”所以當它只看到正面圖片時也能根據數據庫中的先驗知識把背面補齊。另外2D 轉 3D 對模型規(guī)模的要求遠高于普通文本問答。文本任務里你只需要在語義空間里做映射而 3D 任務里模型要輸出的是連續(xù)的坐標、網格拓撲和紋理坐標。這個輸出空間比 token 空間復雜得多需要大量參數去隱式記憶物體結構。這也是為什么很多人拿小模型做 2D 轉 3D 時總覺得生成物像是“糊了一層泥巴”的模型而 Hy4 Preview 生成的結果在輪廓和細節(jié)上明顯更清楚。4.2 一條可復現的生產鏈路參考我最近在一個內部工具里試了用 Hy4 Preview 做“從產品草圖到可預覽 3D 資產”的流程整體鏈路大概是這樣原始圖片/草圖 → 多模態(tài)理解 → 生成深度圖/法線圖 → 網格重建 → 精簡拓撲 → 貼圖生成 → 引擎預覽第一步把設計草圖或多視角參考圖發(fā)給模型同時附上一段明確需求比如“這是一個小型消費電子產品需要生成可用于 720 度瀏覽的 3D 白模忽略背景”。第二步讓模型先生成深度圖和不同角度的預測視圖這個階段輸出的中間結果非常關鍵如果深度關系錯了后續(xù)重建再怎么修都救不回來。第三步把預測結果喂給重建模塊生成粗模然后再到 Hy4 Preview 里做語義化修正讓模型識別“哪塊是屏幕、哪塊是外殼圓角、哪塊是接口”。第四步進行網格簡化。剛生成的 3D 資產面數往往非常高直接放進游戲引擎或電商展示頁會卡。一般需要把面數降到原始模型的 20% 到 30%同時保持視覺輪廓。第五步生成貼圖和材質參數。這里 Hy4 Preview 可以輸出一些 PBR 參數的初始值粗糙度、金屬度、基礎色這些不一定能用 Final 版本但能省掉美術從零開始調底子的時間。整個流程里最容易被忽略的是“面向模型需求去整理輸入”。很多人習慣丟一張圖進去就期待完美結果但實際生產時輸入圖片的拍攝角度、光線一致性、背景干擾都會嚴重影響輸出。我建議把產品圖統(tǒng)一到白底、均勻光照、偏正視角再加一句“輸出時不要包含背景物體”。這樣成功率會大幅提高。4.3 只是 2D 轉 3D 嗎還有哪些生產力場景Hy4 Preview 的價值如果只被總結成“更會做 3D”那就太可惜了。770B 的底子給生產工具帶來的變化是全方位的。一個是復雜文檔理解。我拿真實業(yè)務場景里的幾十頁 PDF 合同做過對比Hy3 能定位到關鍵條款但如果合同里存在多個引用、交叉定義它偶爾會把兩處相似條款搞混。Hy4 Preview 在這類交叉引用場景里的準確率明顯更高。做合規(guī)審查、盡調報告這類工作的團隊應該能感受到差異。另一個是 Agent 工具調用。參數規(guī)模上來之后模型對工具選擇的判斷更穩(wěn)定了。以前讓模型自己決定“該查數據庫還是該調計算器”小模型經常會選錯或者把參數格式寫壞。Hy4 Preview 在“規(guī)劃 → 調工具 → 觀察結果 → 再規(guī)劃”的多輪循環(huán)里顯得更不容易斷線。這一點對于所有做自動化工作流的團隊都很重要。還有一個容易被忽視的方向是代碼解釋和異步生成。770B 模型可以一次性把“需求文檔 現有代碼 設計約束”都納入上下文然后給出一個跨文件的修改方案。它不是簡單補全代碼而是在“理解整個倉庫上下文”后再動手。對大型項目而言這種能力比單純生成單文件函數實用得多。5. 實操中的避坑筆記從離線評測到業(yè)務接入5.1 評測別只盯榜單要看任務分布Hy4 Preview 出來后很多人第一時間會拿公開榜單說事比如比 Hy3 又高了多少分。但作為長期做落地的人我勸你別直接用榜單分數來定選型。榜單任務的分布和真實業(yè)務往往差距很大。我建議的做法是拿你自己業(yè)務里最典型的 200 到 500 條樣本跑一個“小規(guī)模盲測”。分成三類短文本理解、長文檔問答、多模態(tài)輸入。短文本理解看它能不能守住 Hy3 的水平長文檔問答看它有沒有明顯的前后矛盾多模態(tài)輸入看你場景中圖片占比高不高。如果你根本沒有多模態(tài)需求那 Hy4 Preview 帶來的提升可能有限這時候多花錢上大模型就不劃算。5.2 別拿 Hy3 的調優(yōu)經驗直接套 Hy4 Preview我犯過一個很典型的錯誤把 Hy3 時代調好的提示詞和參數模板直接用到 Hy4 Preview 上結果效果反而變差了。原因不復雜Hy4 Preview 對指令的理解更微觀有時候你不需要像對 Hy3 那樣在提示詞里反復強調“請務必”、“如果不確定就說明”而 Hy4 Preview 對隱含意圖的捕捉更強如果你給的指令太啰嗦反而會引入不必要的噪音。同時Hy4 Preview 在不同任務上對 JSON 等結構化格式的遵循度更高所以你可以把原來“五段式提示詞”壓縮成“要求 輸出格式 示例”它一樣能給出高質量結果。我建議在切換到新模型時至少留出一到兩周做提示詞回歸不要指望無縫平移。5.3 量化與推理框架的避坑建議770B 要上生產量化基本是不可避免的。但我覺得有一個“精度回退檢測”的步驟不能省。當你把模型從 BF16 切到 FP8 或者 INT4 之后要找一批邊界樣本重新測比如數學計算、代碼執(zhí)行、長文檔里的精確引用等。因為量化最容易損失的恰恰是那些對數值精度敏感的細粒度任務。視覺輸出、文生圖方向的任務有些模型量化之后反而問題不大但文本邏輯鏈路里一點點誤差就會滾雪球。推理框架也要記得開啟 continuous batching 和 paged attention 這類優(yōu)化。770B 模型的單請求吞吐很低如果沒有好的 batching 策略GPU 利用率可能不到兩位數。實測下來這類能力對整體成本的影響甚至比模型本身還大。換模型之前先在小流量里對比一下同配置下的吞吐數據和首 token 延遲再做全量切換。5.4 接入業(yè)務時的灰度方案我再給一個最實際的建議別搞“一次性全量替換”。Hy3 在線上已經跑得不錯的業(yè)務可以先開 5% 到 10% 的流量給 Hy4 Preview做一個影子模式也就是讓新舊模型同時跑但只把舊模型的結果返回給用戶新模型的結果用于質檢和對比。這樣跑一周你就能看到哪些場景真正受益哪些場景反而劣化。如果影子模式下Hy4 Preview 在客服場景的拒答率高于 Hy3那可能是你的知識庫檢索鏈路對上下文壓縮太激進給模型的原文不夠多。先調檢索鏈路再考慮回滾。這一步能避免很多“升級后線上事故”的尷尬。6. 常見問題排查與選擇速查6.1 幾個高頻問題第一個問題是“為什么我的 32K 上下文跑不起來”。大概率不是模型限制而是你的服務端把 max_tokens 和上下文緩沖設得太高導致 KV Cache 溢出。建議先檢查并發(fā)數和每條會話的實際平均 token 數看看是不是長尾請求拖垮了顯存。第二個問題是“模型輸出經常被截斷”。這種情況通常不是 bug而是 max_tokens 設得不夠或者模型生成時遇到停止符被提早中斷。需要區(qū)分是哪種情況再加長上限或者調整停止詞。第三個問題是“量化后生成質量明顯下降”。如果量化方法可靠那可能是邊界任務的比例偏高。比如你經常讓模型做精確計算那量化損耗就會很致命。解決辦法是切回更高精度或者針對計算類任務單獨走一個小的專用模型不一定所有任務都靠大模型。第四個問題是“2D 轉 3D 結果出現明顯畸變”。這時候不要急著怪模型先檢查輸入圖是不是有嚴重的透視變形、遮擋或者背景干擾。模型對“干凈輸入”的依賴比你想象中大。如果輸入本身是手機隨手拍建議先做預處理把物體摳出來、放在純色背景上再傳給模型。6.2 用一張表總結選型建議判斷維度繼續(xù)選 Hy3升級到 Hy4 Preview主要任務短文本、常規(guī)問答、結構化信息抽取長文檔推理、復雜多模態(tài)理解、生成式設計圖片/3D 需求基本沒有或極低頻高頻、需要深度理解和空間生成上下文長度8K 到 16K 夠用需要 32K 以上且要做多文檔交叉團隊預算對單次推理成本敏感能接受更高單價換取效果和穩(wěn)定性工程成熟度線上鏈路穩(wěn)定不想動愿意重新做評測、調優(yōu)和灰度輸出結構化要求一般嚴格 JSON、跨步驟復雜輸出表格只是輔助判斷最終還是要落到你自己的樣本集上。我個人比較推薦的做法是“有條件的話兩套都留著”。日常低價值請求繼續(xù)走 Hy3 路線高價值或者復雜請求再打到 Hy4 Preview。雙路架構能照顧性能和成本是當前最穩(wěn)妥的生產方案。6.3 關于 Hy4 Preview 官網入口和申請測試渠道很多朋友問我去哪里體驗 Hy4 Preview。最直接的方式是關注騰訊混元的官網和官方開放平臺新模型通常在公開發(fā)布后會有體驗入口和 API 申請通道。如果你所在的團隊已經有騰訊云或者混元的合作賬號可以直接在模型服務列表里申請訪問權限。2D 轉 3D 這類能力不一定在默認文本接口里全部開放可能需要單獨開通對應能力所以建議先在控制臺看一遍可選模塊列表。這里有個容易被忽略的點免費體驗入口和商用 API 的模型版本不一定是同一套配置。有些平臺會給體驗用戶加長推理時間或者降低并發(fā)所以要驗證生產效果最好還是申請真實驗證過的接口而不是拿網頁 Demo 的輸出來評估成本和質量。7. 最后說點我的實際操作體會寫到最后我不太想輸出那種“未來前景廣闊”的廢話。更真實的情況是模型從 295B 到 770B能力確實上了一個臺階但它不會自動變成生產力。真正決定項目成敗的仍然是數據清洗、評測集、推理優(yōu)化和提示詞工程這些“臟活累活”。我個人在實際操作中的體會有兩點。第一給新模型多點耐心。Hy4 Preview 這類大模型在早期往往有環(huán)境不穩(wěn)定、部分能力未完全開放的問題不要因為一兩次報錯就否定它也不要因為一兩個驚艷結果就直接上生產。先用影子模式跑一周讓數據說話。第二不管模型多大“輸入決定輸出”這個鐵律一直成立。2D 轉 3D 的圖不干凈生成結果就臟長文檔任務不做好分段和檢索模型就算有 128K 窗口也救不回來。如果你也在做類似的選型評估希望這篇內容能幫你少踩幾個坑。后續(xù)等 Hy4 Preview 正式版或者技術細節(jié)出來我再補一篇深度拆解。