K1 論文詳解

背景

近年影像生成模型流行一種做法:不再從頭訓練一個專門的 autoencoder 來把圖片壓縮成 latent,而是直接「借用」像 DINOv3 這類預訓練視覺編碼器已經學到的特徵,當作重建與 diffusion 訓練共用的 latent 空間。這類方法被稱為 representation autoencoders(RAE)。好處很直觀:預訓練編碼器本身的特徵語意豐富,能讓生成模型學得更快、更好,同時保留下游用於重建像素的能力。

但這裡有個尚未解決的細節問題:預訓練編碼器通常有很多層,到底該拿哪一層(或哪幾層)的特徵來組成這個共用 latent 空間?論文指出這是一個真實的權衡(trade-off):較淺層的特徵保留較多像素細節,重建品質(如 PSNR)較好;較深層的特徵語意更抽象,對 diffusion 生成模型更友善,生成指標(如 FID)反而更佳。過去的作法是用一套固定的「啟發式層融合」(heuristic layer fusion),例如選定某幾層做加權平均,一次訓練、一種配置,重建端與生成端被迫共用同一個「妥協」的特徵,無法同時兼顧兩者的需求。這個落差就是論文標題所說的「reconstruction-generation gap」。

方法

FuseReg 的核心想法很簡單但有效:與其為重建與生成各自挑一組固定的層來融合特徵,不如在訓練時對編碼器的層「隨機抽樣子集」。每一次訓練迭代,模型看到的可能是全部層的融合、稀疏的幾層組合,甚至只有單一層,迫使解碼器(以及後續的生成模型)學會在各種層組合下都能穩定工作,而不是只認得一種固定搭配。

論文進一步從理論上分析了這個機制為什麼有效:對層子集做隨機抽樣,本質上是在訓練目標中隱含地懲罰「跨層不一致」(cross-layer disagreement)的敏感度——也就是說,如果解碼器對於用哪一層、哪個組合來重建的結果差異很大,代表模型過度依賴特定層的特有訊息,泛化能力差;而 FuseReg 的訓練方式會直接壓低這種敏感度,讓模型學到的表徵在不同層融合下都保持一致且穩健。

這個正則化原則不只用在重建的解碼器(decoder)上,也可以延伸到 diffusion 生成端的訓練:對重建與生成兩個階段同時做層融合的隨機化正則化,讓兩邊都對層選擇具有韌性,藉此縮小前面提到的重建—生成落差,而且全程都不需要動到已經訓練好的預訓練編碼器本身。

實驗結果

實驗在 ImageNet-256 資料集上,搭配 DINOv3-L 作為視覺編碼器進行。幾個關鍵數字:

• 重建品質:單一個用 FuseReg 訓練出來的解碼器,能同時處理「全部層融合」「稀疏層融合」「單一層」三種不同的特徵組合輸入,完全不用針對每種組合分別重新訓練;而且它在這三種情境下的 PSNR,都高於那些各自針對固定融合方式專門訓練出來的解碼器。換句話說,一個模型打贏多個「專用模型」。
• 生成品質(僅換解碼器):在生成模型(RAEv2 的 DiT-XL)完全不變的情況下,只把解碼器換成 FuseReg 版本,無引導(unguided)的 gFID 就降低了 27%。這說明解碼器的層融合穩健性,能單方面地改善下游生成品質,即使生成模型本身沒有重新訓練。
• 生成品質(重建+生成聯合正則化):如果把同樣的正則化原則同時套用在重建與 diffusion 訓練兩個階段,在 DiT-Base 規模上,無引導 gFID 進一步降低 29%。

這些數字說明,FuseReg 帶來的不只是「更方便」(一個解碼器多種用途),而是實質的品質提升,無論是單獨換解碼器,還是端到端聯合訓練,都能觀察到明顯的 gFID 改善幅度。

意義

這篇論文點出一個容易被忽略但很關鍵的工程細節:當我們把預訓練視覺編碼器的特徵當作生成模型的 latent 空間時,「選哪一層」這個看似瑣碎的超參數,其實承載著重建與生成兩種目標之間的根本張力。過去的解法往往是靠經驗手動挑選或加權,本質上是一種脆弱的妥協。

FuseReg 提供了一個不需要動編碼器本身、只靠改變下游訓練方式(隨機層子集抽樣)就能同時提升重建與生成表現的方案,而且理論上有清楚的解釋(懲罰跨層不一致敏感度),不是單純的工程 trick。對於正在使用或設計 RAE 類生成系統的團隊來說,這意味著不必再為「重建優先」還是「生成優先」的固定層融合方案二選一,而是可以訓練出一個對層選擇具有韌性的系統,一次滿足兩端需求。考慮到 27%~29% 的 unguided gFID 改善幅度,且改動成本相對低(不需重新訓練或修改預訓練編碼器),這類正則化技巧很有機會被快速吸收進未來的 RAE 與 diffusion 訓練 pipeline 中,成為一個標準做法而非特例。

背景

大型語言模型(LLM)推論其實分成兩個特性截然不同的階段。第一階段是 prefill:模型一次讀入使用者輸入的整段 prompt,平行計算所有 token 的表示,這個階段是「算力受限」(compute-bound),決定了使用者感受到的第一個字出現前的等待時間(time-to-first-token, TTFT)。第二階段是 decode:模型逐一個 token 生成回覆,每次只算一個 token,但每一步都要把全部權重從顯示記憶體搬到運算單元,這個階段是「記憶體頻寬受限」(memory-bound),決定了逐字輸出的速度與吞吐量。

問題是,目前主流的量化方法(如 GPTQ、AWQ,或 llama.cpp 生態使用的 GGUF)幾乎都是「一套格式用到底」:同一組低位元權重與同一種 activation 量化策略,同時套用在 prefill 與 decode 上。但這兩階段真正需要的東西完全相反——prefill 想要能加速矩陣乘法的低精度運算格式(例如 NVFP4 這類 4-bit 浮點格式,可吃滿新一代 GPU 的 tensor core),decode 卻只在乎權重體積小、搬得快,對 activation 精度並不敏感,硬把 activation 也量化到低位元反而只是白白犧牲準確率,換不到任何速度好處。這正是這篇由 Andrei Panferov、Maximilian Kleinegger、Sweta Priyadarshi、Tijmen Blankevoort 與 Dan Alistarh(以極限量化研究,如 GPTQ 聞名)共同提出的論文所要解決的落差。

方法

作者提出「拆分量化」(disaggregated quantization, DQ):把計算格式、權重格式、乃至儲存位置,分別針對 prefill 與 decode 客製化,而不是共用一套設定。具體做法有三層:

第一,單獨拿掉 decode 階段的 activation 量化。既然 decode 本來就不是算力瓶頸,把 activation 恢復到接近全精度,幾乎不增加任何推論成本,卻能顯著挽回 decode-heavy 任務的準確率。

第二,為 prefill 額外訓練一組「運算原生」(compute-native)的權重,而不是沿用原本只為節省記憶體設計的 weight-only 量化權重。這組 prefill 專用權重採用 NVFP4 格式,可直接吃到硬體對低精度浮點運算的加速,同時準確率在 2-3 bit decode 設定下能追平甚至超越原本的 weight-only 方案。重點是,這組 prefill 權重是「外掛」訓練出來的:研究團隊直接拿現成、已釋出的 Qwen3 27B GGUF decode checkpoint,完全不去動它,只另外訓練一組搭配用的 NVFP4 prefiller。

第三,為了不讓單一裝置需要同時塞下 decode 與 prefill 兩份權重,團隊設計了「卸載式拆分 prefill」(offloaded disaggregated prefill, ODP):把 prefill 權重放在 SSD,推論時邊算邊從 SSD 串流讀取,讀取延遲被平攤到整段 prompt 的運算時間裡——prompt 越長,越能把讀取成本藏在計算背後。

實驗結果

在 Qwen 3 與 Gemma 3 系列模型上,單純拿掉 decode 的 activation 量化,就能在不增加推論成本的前提下提升 decode-heavy 任務準確率。而在極端的 1-bit decode 設定下,替已釋出的 Qwen3 27B GGUF decoder 額外訓練一顆 NVFP4 prefiller,在完全不改動原本 decode checkpoint 的情況下,MMLU-Pro 準確率提升了 32.5 個百分點,MMMU-Pro 更提升 35.3 個百分點——顯示原本 decode-only 權重直接拿去做 prefill 有多不划算。

在效能面,ODP 在 27B 模型、8K prompt 長度下,於 llama.cpp 實測 TTFT(首字延遲)較 weight-only 基準快了 1.78 倍。團隊也在 vLLM 的拆分式服務(disaggregated serving)架構下驗證了準確率表現,並進一步用「後訓練量化」(post-training quantization, PTQ,不需重新訓練)的方式,驗證這套權重格式拆分的做法可以套用到高達 2.8 兆(2.8T)參數規模的模型上,證明方法不只適用於單一 27B 案例,而是可推廣的通用配方。

意義

這篇論文挑戰了「一個模型只能配一套量化設定」的既有假設,指出只要把 prefill 與 decode 的硬體瓶頸拆開看,就能用幾乎零額外成本換到準確率與速度的雙贏。這對當前越來越極端的使用情境特別有意義:長 context 的 RAG、工具呼叫屬於 prefill-heavy,而長串 chain-of-thought 推理輸出則是 decode-heavy,兩者對量化的需求本就不同,拆分量化提供了針對性的解法。

實務上,ODP 搭配 SSD 串流的做法,也讓在消費級硬體、甚至邊緣裝置上跑動輒數十億到兆級參數的模型變得更可行——不必犧牲太多準確率就能塞進有限的顯示記憶體。隨著 NVFP4 這類原生低精度格式逐漸成為新一代 GPU 硬體的標準配置,像 GGUF、AWQ 這類量化生態系統,以及 vLLM、llama.cpp、SGLang 等推論框架,未來很可能會把「分別提供 prefill 與 decode 兩份 checkpoint」變成標準做法,呼應近年生產環境中 prefill/decode 拆分部署(如 DistServe 一類架構)的趨勢——只是這次拆分的對象,從硬體資源進一步下探到了量化格式本身。

背景

訓練基礎模型(foundation model)最耗人力、也最容易被忽視的一環,不是算力,而是「把雜亂文件與影片變成乾淨訓練資料」的前處理管線。這類管線有一個典型結構:每一筆「父」資料(例如一份 PDF、一支影片)會被展開成一串「子」資料(例如版面區塊、影格、字幕片段),而且子資料的數量是輸入相關且長尾分布的——有的文件只切出 3 個區塊,有的切出 300 個。要讓 GPU 吃滿,系統必須把來自不同父項目的子項目混在一起打包成批次(batch),同時還得記得每個子項目屬於哪個父項目、順序是第幾個、有沒有處理完、結果該送回哪裡。

問題在於,現有的分散式資料處理框架(論文中特別對照的是 Ray Data 與 Daft)要嘛把平行化藏在「粗粒度 job」背後,讓使用者完全看不到、也管不了中間的父子結構;要嘛把資料攤平成「flat records」丟出來,逼迫應用程式自己去重建誰是誰的孩子、順序是什麼、怎麼把結果收攏回父項目。這在文件解析(如 MinerU、Docling 這類版面辨識加 OCR 的複雜多階段管線)和影片處理管線裡特別痛苦,因為這些管線常常是「一父多子、多階段、子項目彼此依賴」的樹狀甚至鏈狀結構,一旦某個子任務失敗,還牽涉到「要不要連坐、能不能讓其他父項目繼續跑」的問題。

由北大等機構(OpenDCAI 專案)16 位作者聯合提出的 RayOrch,正是針對這個「血緣關係(lineage)在分散式執行中被丟失」的痛點而設計的程式設計模型與執行引擎。論文於 2026 年 9 月投稿到 arXiv(編號 2609.18703),分類在分散式與平行運算(cs.DC),程式碼已開源在 GitHub 的 OpenDCAI/RayOrch。

方法

RayOrch 的核心構想,是讓「父子關係」變成系統的一等公民,而不是應用層要自己維護的隱藏狀態。具體來說,它包含以下幾個關鍵機制:

1. 有序、可變基數的展開與對應收攏(ordered variable-cardinality expansions and matching gathers)。 開發者在程式裡宣告「一個父項目會展開成一組子項目」(expansion),以及對應的「把子項目結果收回父項目」(gather)。編譯器會靜態驗證每一對 expansion/gather 是否匹配,避免執行期才發現資料對不上。

2. Runtime 追蹤完整血緣資訊。 執行引擎會記錄每個子項目屬於哪個直接父項目(immediate parents)、子項目的成員關係(child membership)、不可變的序號(immutable ordinals,即該子項目在父項目展開序列中的固定位置),以及每個項目的終止狀態(terminal state)。這意味著即使子項目在不同 GPU、不同時間點被亂序處理完,系統仍然知道怎麼把它們按原本順序拼回去。

3. Per-Call FIFO Ready Queues。 這是實際做批次打包的機制:針對每一個函式呼叫(per call),系統維護一個先進先出的「就緒佇列」,把來自不同父項目、但已經準備好要處理的子項目集中起來,批次送進 GPU,藉此在保留父子關係的前提下,依然能做到跨父項目的高效批次化。

4. 依「宣告的成員關係與序號」而非「批次邊界或完成順序」來重建結果的 gather。 傳統系統很容易因為批次打包或非同步完成順序把資料順序打亂;RayOrch 的 gather 不依賴「這批是誰、誰先做完」,而是依賴編譯器驗證過的宣告式成員關係與序號來重組,因此父項目可以「一旦所有必要的子項目都變成終止狀態,就立刻繼續往下走」,不必等整批或整個 job 完成。

5. Typed parent-scoped failures(有型別、父項目範圍的失敗處理)。 當某個子任務失敗時,系統只會抑制(suppress)同一個失敗父項目底下「還沒被派送」的其他兄弟子任務,而不會波及其他無關的父項目——換句話說,一份文件解析出錯,不會拖累其他還在正常處理的文件或影片。

整體而言,RayOrch 提供的是一套「宣告式管線 + 血緣感知執行引擎」,讓使用者用接近序列展開/收攏的直覺方式寫程式,而把批次化、順序重建、局部失敗隔離這些髒活都交給 runtime。

實驗結果

論文在 NVIDIA H20 GPU 叢集上進行評測,測試對象包含文件解析管線 MinerU、Docling,以及一條影片處理管線,並與兩個業界常見的分散式資料處理框架 Ray Data 與 Daft 做對照。主要數字如下:

• 擴展性(scaling): 在把 MinerU 管線從 4 張 GPU 擴展到 64 張 GPU 時,RayOrch 達到 15.14 倍的加速比;在把影片處理管線從 8 張 GPU 擴展到 64 張 GPU 時,達到 7.82 倍的加速比。這代表系統在 GPU 數量增加 16 倍(4→64)與 8 倍(8→64)的情境下,吞吐量的擴展效率相當接近理想線性,證明其批次打包與排程機制沒有在大規模並行時出現明顯瓶頸。

• 端到端時間對比: 在 MinerU 管線上,RayOrch 相較 Ray Data 減少了 13.1% 的端到端處理時間,相較 Daft 更減少了 29.0%;在 Docling 管線上,相較 Ray Data 減少了 16.0% 的端到端時間。

這些數字合起來說明兩件事:第一,RayOrch 在「規模擴大」時的效率損耗遠低於典型系統(接近線性擴展);第二,即使在固定規模下,單純因為血緣感知的批次化與局部失敗隔離設計,就能比現有主流框架省下一到三成的實際運算時間,這在動輒要處理數百萬份文件、數十萬支影片的資料前處理場景中,是相當可觀的成本節省。

意義

對做基礎模型訓練資料的團隊來說,RayOrch 點出了一個長期被忽視、卻真實存在的「隱形稅」:資料前處理管線裡的父子關係管理。過去業界要嘛犧牲平行度(用粗粒度 job 包裝一切),要嘛犧牲工程可維護性(讓應用程式自己拼湊 lineage),RayOrch 提出的「宣告式 expansion/gather + runtime 血緣追蹤」路線,展示了「细粒度平行」與「結構化語意」其實可以兼得——這對於文件、影片這類本質上就是樹狀/序列展開結構的資料尤其關鍵。

更值得注意的是「typed parent-scoped failures」這個設計:在真實世界的資料清洗中,壞資料、壞格式幾乎是常態,一份文件解析失敗絕不該拖垮整個叢集的吞吐量。這種局部容錯機制,加上編譯器靜態驗證 expansion/gather 配對,讓整套系統在工程上更接近「先天安全(safe by construction)」,而不是靠事後除錯去堵漏洞。

從更宏觀的角度看,隨著多模態、長文件、長影片訓練資料的需求持續上升,「如何把異質、長尾、依賴輸入的資料結構,高效率地映射到同質化的 GPU 批次運算單元上」,將會是資料基礎設施層一個持續被重新發明的問題。RayOrch 開源(GitHub: OpenDCAI/RayOrch)並在 H20 叢集上實測出 15 倍以上的擴展加速比,為這個問題提供了一個具體、可驗證、而且已在真實文件/影片管線上跑通的參考答案,值得任何自建資料前處理管線的團隊參考其「血緣控制的多粒度資料流」設計理念。