機(jī)器之心發(fā)布

為什么大模型廠商給了 128K 的上下文窗口，卻在計(jì)費(fèi)上讓長文本顯著更貴？

為什么 Claude 能 “吞下整本書”，但官方示例往往只展示幾千字的文檔？

為什么所有大模型廠商都在卷 “更長上下文”，而真正做落地的產(chǎn)品經(jīng)理卻天天琢磨 “怎么把用戶輸入變短”？

這些看似矛盾的現(xiàn)象，其實(shí)答案藏在一個(gè)長期被技術(shù)光環(huán)遮掩的真相里：

長序列，正在成為大模型應(yīng)用里最昂貴的奢侈品

在當(dāng)前主流的 Full Attention 機(jī)制下，計(jì)算開銷會隨著輸入長度平方增長，序列一長，處理就變得 “又貴又慢”（見圖 1）。針對這一核心難題，阿里 RTP-LLM 團(tuán)隊(duì)提出了一種全新的后訓(xùn)練壓縮方案：RTPurbo。在不損失模型效果的前提下，實(shí)現(xiàn)了 Attention 計(jì)算5 倍壓縮（見圖 2）。

左圖 1：長序列 Attention 計(jì)算成本瓶頸；右圖 2：RTPurbo 極大降低 Attention 計(jì)算開銷

總的來說， RTPurbo 采用了一種非侵入式的壓縮方法：通過分辨 LLM 內(nèi)部的長程 Attention Head，僅保留關(guān)鍵 Head 的全局信息，對于剩下冗余的 Head 直接丟棄遠(yuǎn)程 Tokens。這種 Headwise 級別的混合算法以其簡潔的方案設(shè)計(jì)和優(yōu)越的算子兼容性，極大地降低了大模型在長序列下的推理代價(jià)，為新一代 LLM 結(jié)構(gòu)設(shè)計(jì)提供了一個(gè)新的視角和演進(jìn)方向。

目前，項(xiàng)目模型與推理代碼已經(jīng)發(fā)布至 Huggingface、ModelScope 平臺，感興趣的讀者可以閱讀 RTP-LLM 相應(yīng)的技術(shù) blog 了解更多細(xì)節(jié)。

1. https://huggingface.co/RTP-LLM/Qwen3-Coder-30B-A3B-Instruct-RTPurbo
2. https://modelscope.cn/models/RTP-LLM/Qwen3-Coder-30B-A3B-Instruct-RTPurbo

圖 3：RTPurbo 采用混合壓縮方案，僅有少數(shù) Attention Head 使用全量 Attention）

化繁為簡，被低估的 SWA

但在真實(shí)落地中，這兩條路線都有較明顯的共性代價(jià)：一方面，它們通常強(qiáng)依賴大量后訓(xùn)練，工程實(shí)現(xiàn)與適配成本也更高；另一方面，Linear Attention 在壓縮信息后，長序列下的召回能力顯著弱于 Full Attention [1]，因此往往需要與 Full Attention 混合使用，帶來性能與加速收益的雙重上限。此外，Linear / Sparse Attention 的算子與調(diào)度設(shè)計(jì)相對復(fù)雜，也進(jìn)一步影響其在工程生態(tài)中的通用性、可維護(hù)性與一致性。也正因如此，一些前期工作 [2] 反而把目光投向看似 “簡單粗暴” 的 Sliding Window Attention（SWA），例如 gpt-oss 和 MiMo ，這在一定程度上說明 SWA 并非 “權(quán)宜之計(jì)”，而是一種可規(guī)�；瘡�(fù)用的工程選擇。

在進(jìn)一步分析現(xiàn)有 LLM 的注意力模式后，團(tuán)隊(duì)觀察到一個(gè)更細(xì)粒度的關(guān)鍵現(xiàn)象：絕大多數(shù) Attention Head 天然更偏好局部信息，只有極少數(shù) “長程頭” 能在長文本中穩(wěn)定地定位并召回關(guān)鍵關(guān)聯(lián)信息�；谶@一現(xiàn)象，團(tuán)隊(duì)提出了一個(gè)關(guān)鍵假設(shè)：

類似人類的閱讀與寫作過程，LLM 在處理長文本時(shí)，往往會先從長上下文中 “召回” 相關(guān)信息，再在相對局部的上下文范圍內(nèi)完成推理并輸出答案

換句話說，模型內(nèi)部可能只有少量 Attention Head 真正在承擔(dān) “信息召回” 的職責(zé)：它們通過注意力機(jī)制把遠(yuǎn)距離信息搬運(yùn)到當(dāng)前的 Residual Stream（信息通道）中，讓后續(xù)層可以在更局部、更高信噪比的狀態(tài)下完成推理。這也直接意味著：對于那些并不承擔(dān)長程依賴的 Attention Head，其實(shí)并不需要使用 Full Attention—— 長序列場景存在可觀的壓縮空間。

為了驗(yàn)證這一假設(shè)，團(tuán)隊(duì)設(shè)計(jì)了一個(gè)直觀的對比試驗(yàn)：

1. 方案一：只有 15% 的長程頭使用 Full Attention，剩余 85% 使用 SWA；
2. 方案二：15% 的長程頭使用 SWA，剩余 85% 使用 Full Attention。

如表 1 所示，盡管方案二保留了 85% 的 KV cache，但是其長文能力仍然顯著劣于方案一。

表 1：方案一只用 15% 的 Full Attention，長文效果顯著優(yōu)于方案二

進(jìn)一步地，在不做任何微調(diào)的情況下，方案一在長文本指標(biāo)上也非常有競爭力（表 2），幾乎無損：

表 2：方案一不經(jīng)過訓(xùn)練，在 Ruler 上無損

不過，在某些特定的長文任務(wù)上，未經(jīng)微調(diào)的壓縮模型仍會出現(xiàn)明顯的性能退化（見表 3）。其根源在于：壓縮前后注意力模式的直接切換會對模型輸出造成一定擾動，需要額外訓(xùn)練來 “消化” 這種變化。

表 3：方案一在特殊 benchmark 上仍然存在顯著負(fù)向

因此，為實(shí)現(xiàn)更接近 “無損” 的壓縮，團(tuán)隊(duì)進(jìn)一步提出了一個(gè)面向 RL 后模型的壓縮訓(xùn)練范式：在不依賴高質(zhì)量標(biāo)注數(shù)據(jù)的前提下，僅通過輕量級微調(diào)，就能顯著提升壓縮后模型在長文任務(wù)上的表現(xiàn)。

自蒸餾，從根本上解決數(shù)據(jù)問題

當(dāng)前主流 LLM 通常采用 “預(yù)訓(xùn)練 + 后訓(xùn)練 + RL” 的訓(xùn)練范式，如果直接使用長文 SFT / 預(yù)訓(xùn)練語料進(jìn)行續(xù)訓(xùn)，會帶來兩方面挑戰(zhàn)：

1. RL 后模型在經(jīng)過 SFT 會出現(xiàn)過擬合甚至災(zāi)難性遺忘，損傷短文本任務(wù)上的原有能力（見表 4）；
2. 高質(zhì)量的長文本語料難以獲取。

表 4：Qwen3-30B-A3B-Instruct RL 后模型繼續(xù) SFT 會過擬合，造成災(zāi)難性遺忘

為解決這兩點(diǎn)，RTPurbo 使用 “模型自蒸餾” 作為關(guān)鍵訓(xùn)練策略：讓壓縮后的模型對齊原模型輸出，從而同時(shí)化解數(shù)據(jù)與能力保留問題：

1. 僅對模型自身的輸出進(jìn)行對齊，避免依賴特定領(lǐng)域的問答數(shù)據(jù)，從而確保短文本下游指標(biāo)基本無損；
2. 只需使用長文本預(yù)訓(xùn)練語料即可完成訓(xùn)練，使模型快速適應(yīng) headwise 稀疏的工作模式。

實(shí)測中，僅使用約 1 萬條 32k 長度的預(yù)訓(xùn)練語料（訓(xùn)練時(shí)間小時(shí)級），RTPurbo 就能讓長文任務(wù)表現(xiàn)與原模型持平。

結(jié)果對比

在長文本測試場景下，RTPurbo 僅保留約 15% 的 Attention Heads 使用 Full KV cache，壓縮后的 Qwen-Coder-Plus、Qwen3-30B-A3B-Instruct 在多項(xiàng)長文指標(biāo)上可與未壓縮模型齊平，充分驗(yàn)證了壓縮后模型的精度保障。

更重要的是，這種壓縮并非以犧牲通用能力為代價(jià)。在多項(xiàng)短文本（通用）Benchmark 上，采用自蒸餾范式訓(xùn)練后的模型并未出現(xiàn)性能衰減，原有對話、推理和代碼理解等能力都得到了良好保留。

這表明，RTPurbo 不僅是一種單一模型的 “特定優(yōu)化技巧”，而是一套具有良好可遷移性和通用性的長序列加速方案，可為更大規(guī)模、更多架構(gòu)的 LLM 提供高性價(jià)比的推理加速路徑。

從大模型可解釋性到 LLM 壓縮

早期可解釋性工作 [3] 已指出：模型內(nèi)部存在很強(qiáng)的 “召回” 機(jī)制，一部分特定 Attention Head 能穩(wěn)定定位前文相關(guān)信息。團(tuán)隊(duì)成員的前期工作 [2] 也觀察到這些 Head 在長文場景仍保持類似行為。

與此同時(shí)，在 [4] 中，作者指出 Softmax 本身在長序列存在熵增的問題。更具體的，隨著序列變長，每個(gè) Token 的注意力不可避免的變得更加彌散（信噪比降低），如下圖所示：

圖 4：Attention 在長序列下存在信噪比下降的問題

因此，為了避免遠(yuǎn)程信息干擾模型本身的推理能力，LLM 內(nèi)部實(shí)現(xiàn)了一種非常巧妙的機(jī)制：

• 多數(shù) Head 只處理局部信息，以獲得更高信噪比；
• 少數(shù) Head 負(fù)責(zé)從遠(yuǎn)處 “召回” 關(guān)鍵信息并搬運(yùn)到當(dāng)前位置，使后續(xù)層能在局部范圍內(nèi)完成推理。

這與 RTPurbo 的 headwise 設(shè)計(jì)高度一致：把 “全局召回” 能力集中保留給少量關(guān)鍵 Head，其余 Head 則用工程收益更穩(wěn)定的 SWA 來承載。

RTP-LLM：RTPurbo 在長文上的極致性能優(yōu)化

圖 5：RTPurbo HeadWise Attention 性能加速結(jié)果，圖上結(jié)果僅使用 15% 的 Full Attention

RTPurbo 按固定比例劃分 SWA Head 與 Full Head 雖然直觀有效，但工程上必須解決一個(gè)問題：不同 Head 計(jì)算模式與計(jì)算量不一致，會導(dǎo)致負(fù)載不均衡，影響 GPU 并行效率與端到端吞吐。

為此，RTP-LLM 圍繞該不均衡在算子層與框架層做了針對性優(yōu)化，核心包括：

• Full Attention Head 的 PTX 級優(yōu)化：對仍需全量計(jì)算的 Full Head 深入 PTX 指令層，利用 gmma::mma_async_shmA 等異步拷貝與矩陣乘指令提升效率；融合 IO warps 與 P/V 計(jì)算階段，優(yōu)化 Ping-Pong 流水與調(diào)度，減少空轉(zhuǎn)等待。
• 稀疏度感知的負(fù)載均衡調(diào)度：針對 Tail Latency，采用稀疏度感知動態(tài)調(diào)度（如反向拓?fù)渑判颍�，�?yōu)先分配重 tile 給 SM，使各 SM 更同步完成任務(wù)，降低尾延遲、提升吞吐。
• SWA 的高效實(shí)現(xiàn)：避免傳統(tǒng) SWA 常見的 “三段式 KV 拼接” 或 “Custom Mask” 做法（訪存與調(diào)度開銷大），通過重塑數(shù)據(jù)布局與計(jì)算路徑減少冗余訪存與額外算子開銷。
• 用 CP（Context Parallel）替代 TP（Tensor Parallel）：在 headwise 稀疏場景下，TP 易導(dǎo)致算力利用率低且不夠靈活；采用 CP 讓單卡完成全部 head 的 attention 計(jì)算，提高 GPU 利用率，并通過計(jì)算 - 通信重疊降低通信開銷。

綜合以上優(yōu)化，RTP-LLM 能將 Attention 稀疏帶來的理論收益穩(wěn)定、可復(fù)現(xiàn)地轉(zhuǎn)化為端到端加速；在 256k 長序列下實(shí)現(xiàn)單算子最高 9× 加速（見圖 5，圖中僅 15% Head 使用 Full Attention）。

團(tuán)隊(duì)介紹

RTP-LLM 是阿里巴巴智能引擎團(tuán)隊(duì)自研的高性能大模型推理引擎，支持了淘寶、天貓、高德、餓了么等核心業(yè)務(wù)的大模型推理需求。智能引擎源自阿里巴巴搜索、推薦和廣告技術(shù)，是阿里 AI 工程領(lǐng)域的先行者和深耕者。團(tuán)隊(duì)專注于 AI 工程系統(tǒng)的建設(shè)，主導(dǎo)建立了大數(shù)據(jù) AI 工程體系 AI?OS，持續(xù)為阿里集團(tuán)各業(yè)務(wù)提供高質(zhì)量的 AI 工程服務(wù)。

RTP-LLM 項(xiàng)目已開源，歡迎交流共建： https://github.com/alibaba/rtp-llm

參考文獻(xiàn)：

[1]: Repeat After Me:Transformers are Better than State Space Models at Copying.

[2]: RazorAttention: Efficient KV Cache Compression Through Retrieval Heads

[3]: In-context Learning and Induction Heads

[4]: 蘇建林，“注意力機(jī)制真的可以集中注意力嗎？”，https://www.spaces.ac.cn/archives/9889