化拆解)
如果你這兩年一直泡在 AI 社區(qū)八成見過這個說法DeepSeek 是 Infra 仙人。第一次聽到我也覺得夸張但把他們的技術(shù)路線從頭到尾翻完我反而覺得這個詞挺精準(zhǔn)——“仙人”不是玄學(xué)而是把別人不愿意摳的系統(tǒng)級細(xì)節(jié)一個個摳到位然后反映在訓(xùn)練成本、推理速度、長上下文能力這些硬指標(biāo)上。今天我想以一名長期做訓(xùn)練/推理系統(tǒng)優(yōu)化的工程師視角把從細(xì)粒度 MoE、MLA、FP8、DualPipe、GRPO再到稀疏注意力與百萬 Token Agent 這條硬核技術(shù)線完整拆一遍聊聊每項技術(shù)解決的瓶頸是什么、為什么這么設(shè)計、以及在實際復(fù)盤中總結(jié)的經(jīng)驗教訓(xùn)。1. 為什么大家都在喊“Infra 仙人”先看全局再看單點大模型圈子里有一個常見誤區(qū)模型效果好就歸功于模型結(jié)構(gòu)模型跑得慢就歸功于框架不行。但真實情況是模型結(jié)構(gòu)、訓(xùn)練算法、并行策略、推理部署這四層早就綁死在一起了。你單獨優(yōu)化任何一層效果都可能被另一層的短板吃回去。DeepSeek 最讓我佩服的地方恰恰是它把這幾層當(dāng)成一盤棋來下模型設(shè)計階段就考慮到 KV Cache 能不能更小、專家路由能不能更均衡、通信能不能更少、強(qiáng)化學(xué)習(xí)能不能不背一個巨大的價值網(wǎng)絡(luò)?！癐nfra 仙人”這個稱呼能在社區(qū)傳開本質(zhì)上是因為大家看到了一個結(jié)果用有限的算力把模型訓(xùn)練和推理的性價比做到極致。訓(xùn)練側(cè)有 FP8 混合精度、DualPipe 這種系統(tǒng)級調(diào)度創(chuàng)新推理側(cè)有 MLA 壓縮 KV Cache、稀疏注意力減少計算量算法側(cè)有 GRPO 讓強(qiáng)化學(xué)習(xí)擺脫 critic 模型的大頭開銷。每個點單拎出來都不算天方夜譚但把它們串成一個完整的系統(tǒng)就不是拼積木這么簡單了。要理解這套系統(tǒng)你得接受一個前提真正的 Infra 優(yōu)化是每一層都為另一層讓路。所以這篇不是“DeepSeek 模型講解”也不是單一框架指南。我想帶你走一條完整的技術(shù)鏈從模型結(jié)構(gòu)怎么為推理省錢到訓(xùn)練并行怎么把利用率拉滿再到強(qiáng)化學(xué)習(xí)怎么降低顯存壓力最后落到長上下文和 Agent 場景下稀疏注意力帶來的算力杠桿。讀完之后你會發(fā)現(xiàn)所謂“Infra 仙人”并不是什么玄學(xué)而是把預(yù)算思維、瓶頸思維、調(diào)度思維刻進(jìn)了每一項技術(shù)選擇里。2. 先從模型結(jié)構(gòu)下手細(xì)粒度 MoE 與 MLA2.1 細(xì)粒度 MoE 到底細(xì)在哪MoEMixture of Experts混合專家模型的基本想法是把一個大模型拆成若干個專家子網(wǎng)絡(luò)每次輸入只激活其中一部分。表面上節(jié)約了計算量但傳統(tǒng) MoE 工程落地時總是被幾個老問題卡住專家數(shù)量少、每個專家體積大導(dǎo)致參數(shù)容量不夠路由網(wǎng)絡(luò)很容易“一邊倒”每次都選同樣的熱門專家結(jié)果熱門專家成了瓶頸冷門專家長期餓肚子訓(xùn)練時還要額外加一堆輔助損失來維持負(fù)載均衡輔助損失稍微調(diào)大又會影響模型本身的收斂質(zhì)量。細(xì)粒度 MoE 的思路是把“大而粗”的專家進(jìn)一步切成“多而細(xì)”的子專家同時額外保留一批共享專家。你可以把它類比成一個大公司原來只有幾個事業(yè)部每個事業(yè)部都臃腫不堪來了新任務(wù)只能整組上現(xiàn)在切成大量小團(tuán)隊再配上公共資源池任務(wù)來了可以靈活拼裝團(tuán)隊組合共享資源池保證基礎(chǔ)知識不被每個小團(tuán)隊重復(fù)訓(xùn)練。細(xì)粒度帶來的第一個收益是同等激活參數(shù)下專家總數(shù)大幅增加模型的知識容量明顯提高。第二個收益是路由選擇面變大負(fù)載更容易均勻輔助損失的壓力也隨之降低。第三個收益是分布式訓(xùn)練的顯存分布更均勻。做 MoE 訓(xùn)練的人都知道專家并行Expert Parallel最怕的就是某張卡上的專家被瘋狂訪問而細(xì)粒度分割讓通信和計算的熱點都更分散對大規(guī)模集群的穩(wěn)定訓(xùn)練非常關(guān)鍵。2.2 MLA給 KV Cache 做一次低秩瘦身MLAMulti-head Latent Attention多頭潛空間注意力在社區(qū)討論里是另一個高頻詞。理解它之前先想想標(biāo)準(zhǔn)多頭注意力在推理時為什么貴。大模型做生成時每個 token 都要把它的 Key 和 Value 緩存下來留給后面所有 token 做注意力計算。這段緩存叫 KV Cache。上下文越長KV Cache 越大如果輸入到了幾十萬 token光 KV Cache 就可能把一塊高端 GPU 的顯存吃掉大半。多輪對話和 Agent 場景更嚴(yán)重——歷史越攢越多顯存會持續(xù)被占用推理吞吐自然上不去。MQA 和 GQA 的解決思路是讓多個注意力頭共享同一份 K 和 V這樣能減少緩存但代價是不同頭之間的表達(dá)能力被削弱。MLA 的做法不同它不是簡單讓頭之間共享而是把 K/V 整體投影到一個低維的潛空間里緩存真正參與注意力計算時再從這個潛向量恢復(fù)出重建后的 K/V。聽起來有點繞但你可以用一個類比緩存時只存一張低分辨率縮略圖而不是原圖每次計算注意力時先用縮略圖快速做匹配篩選等需要真正讀取內(nèi)容細(xì)節(jié)時再在目標(biāo)位置放大到可用分辨率。因為潛空間維度遠(yuǎn)小于原始 K/V 維度KV Cache 的總量被明顯壓縮長上下文和多并發(fā)請求的內(nèi)存壓力都大大緩解。我在實際部署推理服務(wù)時最直接的體感是同樣的顯存預(yù)算支持并發(fā)數(shù)和上下文長度都能上一個臺階。但這里有一個容易被忽略的成本轉(zhuǎn)移MLA 把內(nèi)存壓力轉(zhuǎn)移到了“潛向量上投影重建 K/V”的計算步驟上純理論看是省了顯存實際要實現(xiàn)收益必須把上投影過程做成融合 kernel否則 CPU 和 GPU 之間的拷貝開銷會把節(jié)省全部吃回去。這也是為什么 MLA 這類模型結(jié)構(gòu)必須配套推理引擎深度優(yōu)化而不是直接套一個通用框架就能吃滿紅利。2.3 模型結(jié)構(gòu)如何反哺 Infra細(xì)粒度 MoE 和 MLA 加在一起形成了一個很有意思的組合MoE 減小了激活參數(shù)量MLA 減小了 KV Cache 量訓(xùn)練階段看模型每走一步需要的 FLOPs 更可控推理階段看單請求的顯存占用更可控。對 Infra 工程師來說這種“從源頭控制資源”的收益比后面再怎么調(diào)優(yōu)調(diào)度器都來得直接。所以學(xué)這套結(jié)構(gòu)別只看論文里的指標(biāo)提升多少更要學(xué)會問一個問題這個設(shè)計讓哪個資源瓶頸變松了細(xì)粒度 MoE 讓“專家并行”更容易做負(fù)載均衡MLA 讓“長上下文緩存”不再線性吞顯存。模型結(jié)構(gòu)的每個細(xì)節(jié)最終都要翻譯成顯存、帶寬、算力三個維度上的變化這才是 Infra 視角的模型解讀。3. 訓(xùn)練系統(tǒng)的硬核突破FP8 與 DualPipe3.1 FP8又快又省的數(shù)值格式為什么以前沒人敢用FP8 是 8 位浮點數(shù)格式。相比 FP16/BF16它的顯存占用直接減半同時新一代 GPU 硬件對 FP8 的矩陣運(yùn)算吞吐往往比 FP16 更高。這聽起來是天上掉餡餅但 FP8 真正的難點在于數(shù)值范圍非常窄一旦權(quán)重或梯度里的數(shù)值稍微大一點或者小一點就可能溢出或者直接變成 0模型收斂說崩就崩。實際操作時標(biāo)準(zhǔn)做法是把“主權(quán)重”保持在 FP32 或 BF16只把前向過程中的激活值、以及反向過程中的梯度值換成 FP8 參與計算。同時配合 per-tensor 或 block-wise 的縮放因子把小數(shù)值放大、大數(shù)值縮小讓數(shù)據(jù)盡量落在 FP8 可表達(dá)的區(qū)間里。還有一類做法是分桶保存不同敏感度的層敏感層繼續(xù)用 BF16非敏感層才用 FP8。各層學(xué)習(xí)率敏感性差異很大訓(xùn)練時不能一刀切。這里我想給一個實操提醒FP8 的收益不只是省顯存更關(guān)鍵的是通信量下降。大規(guī)模分布式訓(xùn)練中模型梯度同步的通信開銷經(jīng)常占到大頭。如果把梯度在通信前用 FP8 壓縮通信時間幾乎減半這對訓(xùn)練性價比的提升比單純算力吞吐更顯著?？纱鷥r是收斂穩(wěn)定性需要重新驗證Scale 策略稍微調(diào)不好loss 就會突然飛掉然后你很可能開始懷疑是不是數(shù)據(jù)問題實際上一查是 FP8 某個 block 的 scale 在反向傳播后期失去了動態(tài)平衡。我之前在一套 7B 尺度模型上用類似思路做混合精度跑批實驗日志里明確加了三種觀測指標(biāo)梯度范數(shù)、每層激活分布、Loss 平滑度。只要這三個指標(biāo)在 FP8 開關(guān)前后保持近一致才敢繼續(xù)把訓(xùn)練跑下去。沒有這套觀測體系就貿(mào)然壓精度大概率會栽跟頭。3.2 DualPipe雙向流水線把空轉(zhuǎn)氣泡壓薄說完了精度再談并行調(diào)度。大規(guī)模模型訓(xùn)練通常用“數(shù)據(jù)并行 張量并行 流水線并行”的組合拳。流水線并行把模型按層切成多段分到不同設(shè)備上每個設(shè)備只負(fù)責(zé)其中一段。問題也隨之而來前后向計算之間經(jīng)常要互相等待設(shè)備上一段時間無所事事這就是“流水線氣泡”。早期經(jīng)典的 1F1B 調(diào)度已經(jīng)能壓掉一部分氣泡但 DeepSeek 用的 DualPipe 進(jìn)一步做了雙向調(diào)度。傳統(tǒng)流水線把微批從前往后推像一條單行道上跑接力DualPipe 則從兩端同時往里塞數(shù)據(jù)和計算任務(wù)前向計算沿著一個方向推進(jìn)反向計算沿著另一個方向錯峰穿插讓每個設(shè)備在等待依賴的時候盡量有下一步可算。能不能用一句話理解把訓(xùn)練流水線想象成一條雙車道公路你不要等一輛車完全走完整條路才開始發(fā)下一輛而是從兩個方向同時發(fā)車讓不同路段的車流盡量重疊。DualPipe 的要點就是把計算圖里前向和后向的依賴關(guān)系排成更細(xì)粒度的交錯塊讓設(shè)備永遠(yuǎn)有活可干。從工程角度看DualPipe 最值錢的不是調(diào)度算法本身而是“調(diào)度器必須和通信算子重疊設(shè)計”的思路。它的效果還嚴(yán)重依賴模型分層和顯存預(yù)估是否準(zhǔn)確。如果某一層因為 FP8 壓縮后顯存變小你就可以塞更多微批來填充氣泡如果某一段算子過重那么反向依賴仍然會把氣泡拉回來。所以 DualPipe 與 FP8 的協(xié)同不是偶然——省下的顯存轉(zhuǎn)手就變成了更密的流水線這兩件事是捏在一起的。3.3 訓(xùn)練優(yōu)化不是單點作戰(zhàn)很多人看訓(xùn)練系統(tǒng)會陷入一個誤區(qū)到處找“最優(yōu) micro-batch size”或者“最優(yōu)并行數(shù)”好像這些參數(shù)是獨立的。但真實的訓(xùn)練優(yōu)化是一個高度耦合的過程。FP8 改變了顯存占用顯存占用又決定了流水線能塞多少微批微批數(shù)量又直接影響 DualPipe 的氣泡率氣泡率下降又讓通信時間占比上升接著你就要去優(yōu)化通信與計算重疊。每一步都是連鎖反應(yīng)。這也是為什么 DeepSeek 的訓(xùn)練系統(tǒng)方案經(jīng)常讓我覺得“難抄”單把 DualPipe 借過來但模型還是傳統(tǒng) MHA、精度還停留在 BF16那顯存根本不夠支撐雙向流水線塞更多微批收益自然打折扣。反過來單把 FP8 開啟但流水線調(diào)度不變通信量和顯存省下來也只會變成空閑顯存不會自動變成訓(xùn)練吞吐。所以我在自己的項目里一貫建議啟動任何訓(xùn)練優(yōu)化方案前先把資源預(yù)算表填清楚——每張卡的顯存里模型參數(shù)占多少、KV Cache 占多少、梯度通信占多少帶寬、計算和通信能不能重疊。預(yù)算表填完方向自然清楚。4. 訓(xùn)練算法層的革命GRPO 如何把 critic 裁掉4.1 PPO 在大模型強(qiáng)化學(xué)習(xí)中的昂貴代價當(dāng)前大模型的對齊和推理能力提升大量依賴強(qiáng)化學(xué)習(xí)。傳統(tǒng)主流的強(qiáng)化學(xué)習(xí)算法是 PPO它需要同時訓(xùn)練一個策略模型還有一個評價狀態(tài)好壞的 Critic 價值網(wǎng)絡(luò)。這個 Critic 模型往往和主模型規(guī)模相當(dāng)意味著訓(xùn)練的總顯存和計算量幾乎翻倍而且價值網(wǎng)絡(luò)很難訓(xùn)穩(wěn)定經(jīng)常引入額外的偏差。大模型訓(xùn)練昂貴的背景下你要兩個模型同時在 GPU 上跑代價是很高的。尤其在做數(shù)學(xué)推理、代碼生成這類策略優(yōu)化時我們真正關(guān)心的是“這一組答案里哪個相對更好”而不是絕對價值函數(shù)到底有多準(zhǔn)。這時候硬塞一個龐大的 Critic 模型性價比非常差。4.2 GRPO用組內(nèi)相對比較替代絕對估值GRPOGroup Relative Policy Optimization群體相對策略優(yōu)化直接把 Critic 模型砍掉了。它對同一個問題采樣出多個不同的輸出形成一個組然后根據(jù)這個組內(nèi)不同輸出的獎勵排序計算出相對優(yōu)勢。哪個回答的獎勵比組內(nèi)平均水平高它就獲得正向更新信號低于平均水平后面的更新就會相應(yīng)降權(quán)。這個思路非常符合直覺你不需要一個神準(zhǔn)的裁判來告訴你絕對能拿多少分你只需要看同樣問題的若干個回答里哪個比哪個好就能指導(dǎo)模型往好答案方向前進(jìn)。這樣做至少有三個優(yōu)勢顯存和算力消耗顯著下降訓(xùn)練穩(wěn)定度提升因為不再受價值網(wǎng)絡(luò)和策略網(wǎng)絡(luò)之間耦合的影響策略更新的方向更貼近任務(wù)實際需求。實操里 GRPO 的 key point 之一是組大小。組太小相對優(yōu)勢的統(tǒng)計噪聲太大更新不穩(wěn)定組太大一次的采樣成本暴漲。我個人的調(diào)試經(jīng)驗是從 8 到 16 的組大小起步配合 KL 散度約束防止策略更新幅度過大。另一個關(guān)鍵是把獎勵歸一化做得干凈最好在訓(xùn)練循環(huán)里把每條樣本的原始獎勵都打出來目檢分布是否合理。如果獎勵分布完全扁平GRPO 給出的信號也會很稀薄。4.3 GRPO 對訓(xùn)練基礎(chǔ)設(shè)施的隱性影響很多討論只講 GRPO 算法簡單、顯存省但沒講它對基礎(chǔ)設(shè)施形態(tài)的影響。由于不再需要為 Critic 模型分配參數(shù)存儲和通信數(shù)據(jù)并行/ZeRO 等策略的切分壓力變小顯存預(yù)算更充裕訓(xùn)練時可以把更多全局 batch size 用于采樣反過來說分批采樣場景天然適合把推理集群和訓(xùn)練集群復(fù)用起來——你把老策略模型先放到推理集群上采樣一批答案再用這些答案去訓(xùn)練更新這其實就是強(qiáng)化學(xué)習(xí)訓(xùn)練系統(tǒng)的典型流水線。GRPO 的輕量性讓這條流水線更容易搭起來不需要維護(hù)一條龐大的雙模型訓(xùn)練鏈路。對我而言GRPO 的價值不只是訓(xùn)練成本下降而是它把“一棵悲觀的價值網(wǎng)絡(luò)”從整個 RL 系統(tǒng)里拿掉讓訓(xùn)練過程更加純粹地押注在優(yōu)質(zhì)樣本和公平比較上。這種算法選擇一旦落到模型更新頻率、采樣規(guī)模的規(guī)劃里整個訓(xùn)練集群的資源利用率都會上一個大臺階。你有越多資源去采樣數(shù)據(jù)覆蓋就越充分模型就越能從相對比較中學(xué)到可靠的推理策略。5. 長上下文與百萬 Token Agent稀疏 Attention 的算力杠桿5.1 長上下文為什么成了硬骨頭大模型從幾千 token 一路卷到幾十萬、甚至百萬 token表面看是“窗口變大了”但背后的計算代價不是線性的。標(biāo)準(zhǔn)注意力機(jī)制的復(fù)雜度隨序列長度平方增長序列越長每一個新 token 都要和前面所有 token 都做一次相似度計算計算量、顯存占用、帶寬需求全都暴漲。更麻煩的是真實 Agent 場景里上下文包含的可能是多個文檔、多輪工具調(diào)用結(jié)果、歷史對話很多內(nèi)容其實是冗余的但模型只能一視同仁地全部計算。這就引出了一個尖銳問題指望把“整段上下文”塞進(jìn)模型并像讀一本書一樣逐字精讀在算力和延遲上根本不現(xiàn)實。我們真正需要的是讓模型學(xué)會選擇性注意——大部分 token 只需要被粗略處理少部分關(guān)鍵 token 才是注意力應(yīng)該聚焦的對象。5.2 稀疏注意力從全量計算到選擇性聚焦稀疏注意力的核心思想是用更便宜的方式替代全窗口上的兩兩計算。常見做法包括三類局部窗口注意力只關(guān)注附近 token適合捕捉局部語法關(guān)系全局 token 作為“記憶錨點”讓每個位置都能快速訪問文檔級關(guān)鍵信息動態(tài)選中重要 token通過可學(xué)習(xí)模塊提前判斷哪些歷史 token 對當(dāng)前查詢更重要然后只在這些 token 上做完整注意力計算。這三類方法各有取舍。局部窗口好在計算固定但信息視野太窄全局錨點能保證長程依賴但錨點本身的選擇很關(guān)鍵動態(tài)選中重要 token 最靈活但會產(chǎn)生額外的索引開銷和負(fù)載不均工程實現(xiàn)難度最大。把這三類方法組合起來往往比迷信任意單一方案更穩(wěn)妥。我自己在長文本抽取任務(wù)上測試過稀疏化的注意力版本關(guān)鍵觀察是只要保留 top 5% 的重要 token 和全局 token很多下游任務(wù)的效果并沒有明顯下降但顯存占用和生成延遲都大幅改善。這說明長文本里絕大部分 token 對當(dāng)前決策貢獻(xiàn)極弱選擇性地忽略它們反而是更符合人類閱讀習(xí)慣的建模方式。5.3 百萬 Token Agent 的推理工程配套當(dāng) Agent 的上下文接近百萬 token 時問題就不只是注意力計算這么簡單了。Agent 經(jīng)常會做多輪工具調(diào)用每調(diào)用一次工具結(jié)果就追加到上下文里下一輪又要重新掃描全部歷史。如果不做前綴緩存或者增量處理系統(tǒng)會反復(fù)對相同的長前綴做重復(fù)計算首 token 延遲被拖得很高。工程上常用的解法是前綴緩存KV Cache 復(fù)用把已經(jīng)處理過的歷史 token 的緩存保存下來新增內(nèi)容只需要從新位置繼續(xù)計算。但前綴緩存會和稀疏注意力產(chǎn)生新的耦合如果你要跳著讀某些 token緩存如何切分哪些 token 需要長期保留這其實是長上下文 Agent 系統(tǒng)最復(fù)雜的調(diào)度決策之一。另外百萬 token 不是“塞得下”就行還必須考慮生成質(zhì)量。上下文越長模型越容易淹沒在冗余信息里出現(xiàn)事實混淆或幻覺。這需要更聰明的上下文管理策略比如讓 Agent 自行維護(hù)一個外部記憶庫只把當(dāng)前最關(guān)鍵的內(nèi)容注入模型窗口窗口之外的東西由檢索模塊按需召回而不是全部堆給模型。這個思路其實已經(jīng)超越了純粹的模型層優(yōu)化進(jìn)入了系統(tǒng)架構(gòu)與算法緊密結(jié)合的地帶。6. “Infra 仙人”的真正底色全棧協(xié)同的工程文化6.1 每一項技術(shù)都不是孤島回頭看這套技術(shù)棧你會發(fā)現(xiàn)它們之間的咬合關(guān)系才是真正的護(hù)城河。MLA 壓縮了 KV Cache讓長上下文場景下顯存不再爆炸這為稀疏注意力減少了計算目標(biāo)FP8 節(jié)省了顯存和通信帶寬讓大規(guī)模 MoE 模型在有限集群里能跑得更密DualPipe 把流水線空轉(zhuǎn)壓薄又得益于 FP8 騰出的顯存GRPO 去掉 critic 模型之后強(qiáng)化學(xué)習(xí)的采樣和訓(xùn)練可以更靈活地復(fù)用推理集群。每一個單項技術(shù)都是在為其他技術(shù)創(chuàng)造更好的系統(tǒng)環(huán)境。做 Infra 時間長了會有一個體會真正的性能大殺器通常不在某個孤立的 kernel 優(yōu)化里而在多個層面的資源預(yù)算恰好同時被釋放的那一瞬間。DeepSeek 的產(chǎn)品化技術(shù)路線恰好就是不斷創(chuàng)造這種“同時釋放”的場景。6.2 工程師可以帶走的五個習(xí)慣第一從端到端資源預(yù)算出發(fā)。不要一上來調(diào)參先把顯存、帶寬、算力、時延四本賬算清楚明確瓶頸在哪里再去選技術(shù)方案。第二優(yōu)先創(chuàng)新在瓶頸資源上。別人都在省錢你也可以考慮省顯存方向別人都在加層你可以思考如何壓縮緩存。第三用調(diào)度去填滿空閑資源。DualPipe 的本質(zhì)是調(diào)度很多實際項目提升空間都藏在計算與通信的重疊里。第四訓(xùn)練穩(wěn)定性優(yōu)先于峰值吞吐。FP8 再快收斂不穩(wěn)定只會無限拉長調(diào)參時間GRPO 再省獎勵分布不合理照樣訓(xùn)不上去。第五把用戶場景焊進(jìn)架構(gòu)設(shè)計。如果你最終服務(wù)的是 Agent 和長文本場景那么 KV Cache 和稀疏注意力從一開始就要進(jìn)入模型設(shè)計清單。6.3 寫在最后不要神化要拆解我自己啃這些技術(shù)點的體會是如果只盯著一篇模型技術(shù)報告里的絢爛詞藻很容易被繞暈但如果帶著“它優(yōu)化了哪個瓶頸資源”這個問題去拆每一頁都會變成一套很清晰的資源換算題。細(xì)粒度 MoE 是在優(yōu)化參數(shù)容量和負(fù)載均衡MLA 是在優(yōu)化 KV Cache 的顯存密度FP8 是在優(yōu)化通信與存儲的字節(jié)數(shù)DualPipe 是在優(yōu)化空泡和利用率GRPO 是在優(yōu)化強(qiáng)化學(xué)習(xí)過程的算力分配稀疏注意力則是在優(yōu)化長文本下的無效計算。“Infra 仙人”不是天降奇才而是把一條很樸素的工程信條執(zhí)行到極致不浪費任何一點算力、顯存和帶寬并且敢于從模型結(jié)構(gòu)層就開始調(diào)整一切都為了讓有限資源產(chǎn)出更高智能。最后分享一個我自己正在做的小實驗在自己的長文本推理服務(wù)里把標(biāo)準(zhǔn)緩存替換成類似低秩壓縮的思路再配合簡單的前綴復(fù)用同一臺機(jī)器上的并發(fā)數(shù)已經(jīng)明顯上去了。技術(shù)史不是線性的而是由無數(shù)個這樣的小實驗和公開報告中的系統(tǒng)方案共同累積出來的。希望你看完這條技術(shù)線也能找到屬于自己的那個“預(yù)算突破口”。 DeepSeek Infra仙人：從MoE到GRPO的全棧優(yōu)化拆解
如果你這兩年一直泡在 AI 社區(qū)八成見過這個說法DeepSeek 是 Infra 仙人。第一次聽到我也覺得夸張但把他們的技術(shù)路線從頭到尾翻完我反而覺得這個詞挺精準(zhǔn)——“仙人”不是玄學(xué)而是把別人不愿意摳的系統(tǒng)級細(xì)節(jié)一個個摳到位然后反映在訓(xùn)練成本、推理速度、長上下文能力這些硬指標(biāo)上。今天我想以一名長期做訓(xùn)練/推理系統(tǒng)優(yōu)化的工程師視角把從細(xì)粒度 MoE、MLA、FP8、DualPipe、GRPO再到稀疏注意力與百萬 Token Agent 這條硬核技術(shù)線完整拆一遍聊聊每項技術(shù)解決的瓶頸是什么、為什么這么設(shè)計、以及在實際復(fù)盤中總結(jié)的經(jīng)驗教訓(xùn)。1. 為什么大家都在喊“Infra 仙人”先看全局再看單點大模型圈子里有一個常見誤區(qū)模型效果好就歸功于模型結(jié)構(gòu)模型跑得慢就歸功于框架不行。但真實情況是模型結(jié)構(gòu)、訓(xùn)練算法、并行策略、推理部署這四層早就綁死在一起了。你單獨優(yōu)化任何一層效果都可能被另一層的短板吃回去。DeepSeek 最讓我佩服的地方恰恰是它把這幾層當(dāng)成一盤棋來下模型設(shè)計階段就考慮到 KV Cache 能不能更小、專家路由能不能更均衡、通信能不能更少、強(qiáng)化學(xué)習(xí)能不能不背一個巨大的價值網(wǎng)絡(luò)?！癐nfra 仙人”這個稱呼能在社區(qū)傳開本質(zhì)上是因為大家看到了一個結(jié)果用有限的算力把模型訓(xùn)練和推理的性價比做到極致。訓(xùn)練側(cè)有 FP8 混合精度、DualPipe 這種系統(tǒng)級調(diào)度創(chuàng)新推理側(cè)有 MLA 壓縮 KV Cache、稀疏注意力減少計算量算法側(cè)有 GRPO 讓強(qiáng)化學(xué)習(xí)擺脫 critic 模型的大頭開銷。每個點單拎出來都不算天方夜譚但把它們串成一個完整的系統(tǒng)就不是拼積木這么簡單了。要理解這套系統(tǒng)你得接受一個前提真正的 Infra 優(yōu)化是每一層都為另一層讓路。所以這篇不是“DeepSeek 模型講解”也不是單一框架指南。我想帶你走一條完整的技術(shù)鏈從模型結(jié)構(gòu)怎么為推理省錢到訓(xùn)練并行怎么把利用率拉滿再到強(qiáng)化學(xué)習(xí)怎么降低顯存壓力最后落到長上下文和 Agent 場景下稀疏注意力帶來的算力杠桿。讀完之后你會發(fā)現(xiàn)所謂“Infra 仙人”并不是什么玄學(xué)而是把預(yù)算思維、瓶頸思維、調(diào)度思維刻進(jìn)了每一項技術(shù)選擇里。2. 先從模型結(jié)構(gòu)下手細(xì)粒度 MoE 與 MLA2.1 細(xì)粒度 MoE 到底細(xì)在哪MoEMixture of Experts混合專家模型的基本想法是把一個大模型拆成若干個專家子網(wǎng)絡(luò)每次輸入只激活其中一部分。表面上節(jié)約了計算量但傳統(tǒng) MoE 工程落地時總是被幾個老問題卡住專家數(shù)量少、每個專家體積大導(dǎo)致參數(shù)容量不夠路由網(wǎng)絡(luò)很容易“一邊倒”每次都選同樣的熱門專家結(jié)果熱門專家成了瓶頸冷門專家長期餓肚子訓(xùn)練時還要額外加一堆輔助損失來維持負(fù)載均衡輔助損失稍微調(diào)大又會影響模型本身的收斂質(zhì)量。細(xì)粒度 MoE 的思路是把“大而粗”的專家進(jìn)一步切成“多而細(xì)”的子專家同時額外保留一批共享專家。你可以把它類比成一個大公司原來只有幾個事業(yè)部每個事業(yè)部都臃腫不堪來了新任務(wù)只能整組上現(xiàn)在切成大量小團(tuán)隊再配上公共資源池任務(wù)來了可以靈活拼裝團(tuán)隊組合共享資源池保證基礎(chǔ)知識不被每個小團(tuán)隊重復(fù)訓(xùn)練。細(xì)粒度帶來的第一個收益是同等激活參數(shù)下專家總數(shù)大幅增加模型的知識容量明顯提高。第二個收益是路由選擇面變大負(fù)載更容易均勻輔助損失的壓力也隨之降低。第三個收益是分布式訓(xùn)練的顯存分布更均勻。做 MoE 訓(xùn)練的人都知道專家并行Expert Parallel最怕的就是某張卡上的專家被瘋狂訪問而細(xì)粒度分割讓通信和計算的熱點都更分散對大規(guī)模集群的穩(wěn)定訓(xùn)練非常關(guān)鍵。2.2 MLA給 KV Cache 做一次低秩瘦身MLAMulti-head Latent Attention多頭潛空間注意力在社區(qū)討論里是另一個高頻詞。理解它之前先想想標(biāo)準(zhǔn)多頭注意力在推理時為什么貴。大模型做生成時每個 token 都要把它的 Key 和 Value 緩存下來留給后面所有 token 做注意力計算。這段緩存叫 KV Cache。上下文越長KV Cache 越大如果輸入到了幾十萬 token光 KV Cache 就可能把一塊高端 GPU 的顯存吃掉大半。多輪對話和 Agent 場景更嚴(yán)重——歷史越攢越多顯存會持續(xù)被占用推理吞吐自然上不去。MQA 和 GQA 的解決思路是讓多個注意力頭共享同一份 K 和 V這樣能減少緩存但代價是不同頭之間的表達(dá)能力被削弱。MLA 的做法不同它不是簡單讓頭之間共享而是把 K/V 整體投影到一個低維的潛空間里緩存真正參與注意力計算時再從這個潛向量恢復(fù)出重建后的 K/V。聽起來有點繞但你可以用一個類比緩存時只存一張低分辨率縮略圖而不是原圖每次計算注意力時先用縮略圖快速做匹配篩選等需要真正讀取內(nèi)容細(xì)節(jié)時再在目標(biāo)位置放大到可用分辨率。因為潛空間維度遠(yuǎn)小于原始 K/V 維度KV Cache 的總量被明顯壓縮長上下文和多并發(fā)請求的內(nèi)存壓力都大大緩解。我在實際部署推理服務(wù)時最直接的體感是同樣的顯存預(yù)算支持并發(fā)數(shù)和上下文長度都能上一個臺階。但這里有一個容易被忽略的成本轉(zhuǎn)移MLA 把內(nèi)存壓力轉(zhuǎn)移到了“潛向量上投影重建 K/V”的計算步驟上純理論看是省了顯存實際要實現(xiàn)收益必須把上投影過程做成融合 kernel否則 CPU 和 GPU 之間的拷貝開銷會把節(jié)省全部吃回去。這也是為什么 MLA 這類模型結(jié)構(gòu)必須配套推理引擎深度優(yōu)化而不是直接套一個通用框架就能吃滿紅利。2.3 模型結(jié)構(gòu)如何反哺 Infra細(xì)粒度 MoE 和 MLA 加在一起形成了一個很有意思的組合MoE 減小了激活參數(shù)量MLA 減小了 KV Cache 量訓(xùn)練階段看模型每走一步需要的 FLOPs 更可控推理階段看單請求的顯存占用更可控。對 Infra 工程師來說這種“從源頭控制資源”的收益比后面再怎么調(diào)優(yōu)調(diào)度器都來得直接。所以學(xué)這套結(jié)構(gòu)別只看論文里的指標(biāo)提升多少更要學(xué)會問一個問題這個設(shè)計讓哪個資源瓶頸變松了細(xì)粒度 MoE 讓“專家并行”更容易做負(fù)載均衡MLA 讓“長上下文緩存”不再線性吞顯存。模型結(jié)構(gòu)的每個細(xì)節(jié)最終都要翻譯成顯存、帶寬、算力三個維度上的變化這才是 Infra 視角的模型解讀。3. 訓(xùn)練系統(tǒng)的硬核突破FP8 與 DualPipe3.1 FP8又快又省的數(shù)值格式為什么以前沒人敢用FP8 是 8 位浮點數(shù)格式。相比 FP16/BF16它的顯存占用直接減半同時新一代 GPU 硬件對 FP8 的矩陣運(yùn)算吞吐往往比 FP16 更高。這聽起來是天上掉餡餅但 FP8 真正的難點在于數(shù)值范圍非常窄一旦權(quán)重或梯度里的數(shù)值稍微大一點或者小一點就可能溢出或者直接變成 0模型收斂說崩就崩。實際操作時標(biāo)準(zhǔn)做法是把“主權(quán)重”保持在 FP32 或 BF16只把前向過程中的激活值、以及反向過程中的梯度值換成 FP8 參與計算。同時配合 per-tensor 或 block-wise 的縮放因子把小數(shù)值放大、大數(shù)值縮小讓數(shù)據(jù)盡量落在 FP8 可表達(dá)的區(qū)間里。還有一類做法是分桶保存不同敏感度的層敏感層繼續(xù)用 BF16非敏感層才用 FP8。各層學(xué)習(xí)率敏感性差異很大訓(xùn)練時不能一刀切。這里我想給一個實操提醒FP8 的收益不只是省顯存更關(guān)鍵的是通信量下降。大規(guī)模分布式訓(xùn)練中模型梯度同步的通信開銷經(jīng)常占到大頭。如果把梯度在通信前用 FP8 壓縮通信時間幾乎減半這對訓(xùn)練性價比的提升比單純算力吞吐更顯著?？纱鷥r是收斂穩(wěn)定性需要重新驗證Scale 策略稍微調(diào)不好loss 就會突然飛掉然后你很可能開始懷疑是不是數(shù)據(jù)問題實際上一查是 FP8 某個 block 的 scale 在反向傳播后期失去了動態(tài)平衡。我之前在一套 7B 尺度模型上用類似思路做混合精度跑批實驗日志里明確加了三種觀測指標(biāo)梯度范數(shù)、每層激活分布、Loss 平滑度。只要這三個指標(biāo)在 FP8 開關(guān)前后保持近一致才敢繼續(xù)把訓(xùn)練跑下去。沒有這套觀測體系就貿(mào)然壓精度大概率會栽跟頭。3.2 DualPipe雙向流水線把空轉(zhuǎn)氣泡壓薄說完了精度再談并行調(diào)度。大規(guī)模模型訓(xùn)練通常用“數(shù)據(jù)并行 張量并行 流水線并行”的組合拳。流水線并行把模型按層切成多段分到不同設(shè)備上每個設(shè)備只負(fù)責(zé)其中一段。問題也隨之而來前后向計算之間經(jīng)常要互相等待設(shè)備上一段時間無所事事這就是“流水線氣泡”。早期經(jīng)典的 1F1B 調(diào)度已經(jīng)能壓掉一部分氣泡但 DeepSeek 用的 DualPipe 進(jìn)一步做了雙向調(diào)度。傳統(tǒng)流水線把微批從前往后推像一條單行道上跑接力DualPipe 則從兩端同時往里塞數(shù)據(jù)和計算任務(wù)前向計算沿著一個方向推進(jìn)反向計算沿著另一個方向錯峰穿插讓每個設(shè)備在等待依賴的時候盡量有下一步可算。能不能用一句話理解把訓(xùn)練流水線想象成一條雙車道公路你不要等一輛車完全走完整條路才開始發(fā)下一輛而是從兩個方向同時發(fā)車讓不同路段的車流盡量重疊。DualPipe 的要點就是把計算圖里前向和后向的依賴關(guān)系排成更細(xì)粒度的交錯塊讓設(shè)備永遠(yuǎn)有活可干。從工程角度看DualPipe 最值錢的不是調(diào)度算法本身而是“調(diào)度器必須和通信算子重疊設(shè)計”的思路。它的效果還嚴(yán)重依賴模型分層和顯存預(yù)估是否準(zhǔn)確。如果某一層因為 FP8 壓縮后顯存變小你就可以塞更多微批來填充氣泡如果某一段算子過重那么反向依賴仍然會把氣泡拉回來。所以 DualPipe 與 FP8 的協(xié)同不是偶然——省下的顯存轉(zhuǎn)手就變成了更密的流水線這兩件事是捏在一起的。3.3 訓(xùn)練優(yōu)化不是單點作戰(zhàn)很多人看訓(xùn)練系統(tǒng)會陷入一個誤區(qū)到處找“最優(yōu) micro-batch size”或者“最優(yōu)并行數(shù)”好像這些參數(shù)是獨立的。但真實的訓(xùn)練優(yōu)化是一個高度耦合的過程。FP8 改變了顯存占用顯存占用又決定了流水線能塞多少微批微批數(shù)量又直接影響 DualPipe 的氣泡率氣泡率下降又讓通信時間占比上升接著你就要去優(yōu)化通信與計算重疊。每一步都是連鎖反應(yīng)。這也是為什么 DeepSeek 的訓(xùn)練系統(tǒng)方案經(jīng)常讓我覺得“難抄”單把 DualPipe 借過來但模型還是傳統(tǒng) MHA、精度還停留在 BF16那顯存根本不夠支撐雙向流水線塞更多微批收益自然打折扣。反過來單把 FP8 開啟但流水線調(diào)度不變通信量和顯存省下來也只會變成空閑顯存不會自動變成訓(xùn)練吞吐。所以我在自己的項目里一貫建議啟動任何訓(xùn)練優(yōu)化方案前先把資源預(yù)算表填清楚——每張卡的顯存里模型參數(shù)占多少、KV Cache 占多少、梯度通信占多少帶寬、計算和通信能不能重疊。預(yù)算表填完方向自然清楚。4. 訓(xùn)練算法層的革命GRPO 如何把 critic 裁掉4.1 PPO 在大模型強(qiáng)化學(xué)習(xí)中的昂貴代價當(dāng)前大模型的對齊和推理能力提升大量依賴強(qiáng)化學(xué)習(xí)。傳統(tǒng)主流的強(qiáng)化學(xué)習(xí)算法是 PPO它需要同時訓(xùn)練一個策略模型還有一個評價狀態(tài)好壞的 Critic 價值網(wǎng)絡(luò)。這個 Critic 模型往往和主模型規(guī)模相當(dāng)意味著訓(xùn)練的總顯存和計算量幾乎翻倍而且價值網(wǎng)絡(luò)很難訓(xùn)穩(wěn)定經(jīng)常引入額外的偏差。大模型訓(xùn)練昂貴的背景下你要兩個模型同時在 GPU 上跑代價是很高的。尤其在做數(shù)學(xué)推理、代碼生成這類策略優(yōu)化時我們真正關(guān)心的是“這一組答案里哪個相對更好”而不是絕對價值函數(shù)到底有多準(zhǔn)。這時候硬塞一個龐大的 Critic 模型性價比非常差。4.2 GRPO用組內(nèi)相對比較替代絕對估值GRPOGroup Relative Policy Optimization群體相對策略優(yōu)化直接把 Critic 模型砍掉了。它對同一個問題采樣出多個不同的輸出形成一個組然后根據(jù)這個組內(nèi)不同輸出的獎勵排序計算出相對優(yōu)勢。哪個回答的獎勵比組內(nèi)平均水平高它就獲得正向更新信號低于平均水平后面的更新就會相應(yīng)降權(quán)。這個思路非常符合直覺你不需要一個神準(zhǔn)的裁判來告訴你絕對能拿多少分你只需要看同樣問題的若干個回答里哪個比哪個好就能指導(dǎo)模型往好答案方向前進(jìn)。這樣做至少有三個優(yōu)勢顯存和算力消耗顯著下降訓(xùn)練穩(wěn)定度提升因為不再受價值網(wǎng)絡(luò)和策略網(wǎng)絡(luò)之間耦合的影響策略更新的方向更貼近任務(wù)實際需求。實操里 GRPO 的 key point 之一是組大小。組太小相對優(yōu)勢的統(tǒng)計噪聲太大更新不穩(wěn)定組太大一次的采樣成本暴漲。我個人的調(diào)試經(jīng)驗是從 8 到 16 的組大小起步配合 KL 散度約束防止策略更新幅度過大。另一個關(guān)鍵是把獎勵歸一化做得干凈最好在訓(xùn)練循環(huán)里把每條樣本的原始獎勵都打出來目檢分布是否合理。如果獎勵分布完全扁平GRPO 給出的信號也會很稀薄。4.3 GRPO 對訓(xùn)練基礎(chǔ)設(shè)施的隱性影響很多討論只講 GRPO 算法簡單、顯存省但沒講它對基礎(chǔ)設(shè)施形態(tài)的影響。由于不再需要為 Critic 模型分配參數(shù)存儲和通信數(shù)據(jù)并行/ZeRO 等策略的切分壓力變小顯存預(yù)算更充裕訓(xùn)練時可以把更多全局 batch size 用于采樣反過來說分批采樣場景天然適合把推理集群和訓(xùn)練集群復(fù)用起來——你把老策略模型先放到推理集群上采樣一批答案再用這些答案去訓(xùn)練更新這其實就是強(qiáng)化學(xué)習(xí)訓(xùn)練系統(tǒng)的典型流水線。GRPO 的輕量性讓這條流水線更容易搭起來不需要維護(hù)一條龐大的雙模型訓(xùn)練鏈路。對我而言GRPO 的價值不只是訓(xùn)練成本下降而是它把“一棵悲觀的價值網(wǎng)絡(luò)”從整個 RL 系統(tǒng)里拿掉讓訓(xùn)練過程更加純粹地押注在優(yōu)質(zhì)樣本和公平比較上。這種算法選擇一旦落到模型更新頻率、采樣規(guī)模的規(guī)劃里整個訓(xùn)練集群的資源利用率都會上一個大臺階。你有越多資源去采樣數(shù)據(jù)覆蓋就越充分模型就越能從相對比較中學(xué)到可靠的推理策略。5. 長上下文與百萬 Token Agent稀疏 Attention 的算力杠桿5.1 長上下文為什么成了硬骨頭大模型從幾千 token 一路卷到幾十萬、甚至百萬 token表面看是“窗口變大了”但背后的計算代價不是線性的。標(biāo)準(zhǔn)注意力機(jī)制的復(fù)雜度隨序列長度平方增長序列越長每一個新 token 都要和前面所有 token 都做一次相似度計算計算量、顯存占用、帶寬需求全都暴漲。更麻煩的是真實 Agent 場景里上下文包含的可能是多個文檔、多輪工具調(diào)用結(jié)果、歷史對話很多內(nèi)容其實是冗余的但模型只能一視同仁地全部計算。這就引出了一個尖銳問題指望把“整段上下文”塞進(jìn)模型并像讀一本書一樣逐字精讀在算力和延遲上根本不現(xiàn)實。我們真正需要的是讓模型學(xué)會選擇性注意——大部分 token 只需要被粗略處理少部分關(guān)鍵 token 才是注意力應(yīng)該聚焦的對象。5.2 稀疏注意力從全量計算到選擇性聚焦稀疏注意力的核心思想是用更便宜的方式替代全窗口上的兩兩計算。常見做法包括三類局部窗口注意力只關(guān)注附近 token適合捕捉局部語法關(guān)系全局 token 作為“記憶錨點”讓每個位置都能快速訪問文檔級關(guān)鍵信息動態(tài)選中重要 token通過可學(xué)習(xí)模塊提前判斷哪些歷史 token 對當(dāng)前查詢更重要然后只在這些 token 上做完整注意力計算。這三類方法各有取舍。局部窗口好在計算固定但信息視野太窄全局錨點能保證長程依賴但錨點本身的選擇很關(guān)鍵動態(tài)選中重要 token 最靈活但會產(chǎn)生額外的索引開銷和負(fù)載不均工程實現(xiàn)難度最大。把這三類方法組合起來往往比迷信任意單一方案更穩(wěn)妥。我自己在長文本抽取任務(wù)上測試過稀疏化的注意力版本關(guān)鍵觀察是只要保留 top 5% 的重要 token 和全局 token很多下游任務(wù)的效果并沒有明顯下降但顯存占用和生成延遲都大幅改善。這說明長文本里絕大部分 token 對當(dāng)前決策貢獻(xiàn)極弱選擇性地忽略它們反而是更符合人類閱讀習(xí)慣的建模方式。5.3 百萬 Token Agent 的推理工程配套當(dāng) Agent 的上下文接近百萬 token 時問題就不只是注意力計算這么簡單了。Agent 經(jīng)常會做多輪工具調(diào)用每調(diào)用一次工具結(jié)果就追加到上下文里下一輪又要重新掃描全部歷史。如果不做前綴緩存或者增量處理系統(tǒng)會反復(fù)對相同的長前綴做重復(fù)計算首 token 延遲被拖得很高。工程上常用的解法是前綴緩存KV Cache 復(fù)用把已經(jīng)處理過的歷史 token 的緩存保存下來新增內(nèi)容只需要從新位置繼續(xù)計算。但前綴緩存會和稀疏注意力產(chǎn)生新的耦合如果你要跳著讀某些 token緩存如何切分哪些 token 需要長期保留這其實是長上下文 Agent 系統(tǒng)最復(fù)雜的調(diào)度決策之一。另外百萬 token 不是“塞得下”就行還必須考慮生成質(zhì)量。上下文越長模型越容易淹沒在冗余信息里出現(xiàn)事實混淆或幻覺。這需要更聰明的上下文管理策略比如讓 Agent 自行維護(hù)一個外部記憶庫只把當(dāng)前最關(guān)鍵的內(nèi)容注入模型窗口窗口之外的東西由檢索模塊按需召回而不是全部堆給模型。這個思路其實已經(jīng)超越了純粹的模型層優(yōu)化進(jìn)入了系統(tǒng)架構(gòu)與算法緊密結(jié)合的地帶。6. “Infra 仙人”的真正底色全棧協(xié)同的工程文化6.1 每一項技術(shù)都不是孤島回頭看這套技術(shù)棧你會發(fā)現(xiàn)它們之間的咬合關(guān)系才是真正的護(hù)城河。MLA 壓縮了 KV Cache讓長上下文場景下顯存不再爆炸這為稀疏注意力減少了計算目標(biāo)FP8 節(jié)省了顯存和通信帶寬讓大規(guī)模 MoE 模型在有限集群里能跑得更密DualPipe 把流水線空轉(zhuǎn)壓薄又得益于 FP8 騰出的顯存GRPO 去掉 critic 模型之后強(qiáng)化學(xué)習(xí)的采樣和訓(xùn)練可以更靈活地復(fù)用推理集群。每一個單項技術(shù)都是在為其他技術(shù)創(chuàng)造更好的系統(tǒng)環(huán)境。做 Infra 時間長了會有一個體會真正的性能大殺器通常不在某個孤立的 kernel 優(yōu)化里而在多個層面的資源預(yù)算恰好同時被釋放的那一瞬間。DeepSeek 的產(chǎn)品化技術(shù)路線恰好就是不斷創(chuàng)造這種“同時釋放”的場景。6.2 工程師可以帶走的五個習(xí)慣第一從端到端資源預(yù)算出發(fā)。不要一上來調(diào)參先把顯存、帶寬、算力、時延四本賬算清楚明確瓶頸在哪里再去選技術(shù)方案。第二優(yōu)先創(chuàng)新在瓶頸資源上。別人都在省錢你也可以考慮省顯存方向別人都在加層你可以思考如何壓縮緩存。第三用調(diào)度去填滿空閑資源。DualPipe 的本質(zhì)是調(diào)度很多實際項目提升空間都藏在計算與通信的重疊里。第四訓(xùn)練穩(wěn)定性優(yōu)先于峰值吞吐。FP8 再快收斂不穩(wěn)定只會無限拉長調(diào)參時間GRPO 再省獎勵分布不合理照樣訓(xùn)不上去。第五把用戶場景焊進(jìn)架構(gòu)設(shè)計。如果你最終服務(wù)的是 Agent 和長文本場景那么 KV Cache 和稀疏注意力從一開始就要進(jìn)入模型設(shè)計清單。6.3 寫在最后不要神化要拆解我自己啃這些技術(shù)點的體會是如果只盯著一篇模型技術(shù)報告里的絢爛詞藻很容易被繞暈但如果帶著“它優(yōu)化了哪個瓶頸資源”這個問題去拆每一頁都會變成一套很清晰的資源換算題。細(xì)粒度 MoE 是在優(yōu)化參數(shù)容量和負(fù)載均衡MLA 是在優(yōu)化 KV Cache 的顯存密度FP8 是在優(yōu)化通信與存儲的字節(jié)數(shù)DualPipe 是在優(yōu)化空泡和利用率GRPO 是在優(yōu)化強(qiáng)化學(xué)習(xí)過程的算力分配稀疏注意力則是在優(yōu)化長文本下的無效計算。“Infra 仙人”不是天降奇才而是把一條很樸素的工程信條執(zhí)行到極致不浪費任何一點算力、顯存和帶寬并且敢于從模型結(jié)構(gòu)層就開始調(diào)整一切都為了讓有限資源產(chǎn)出更高智能。最后分享一個我自己正在做的小實驗在自己的長文本推理服務(wù)里把標(biāo)準(zhǔn)緩存替換成類似低秩壓縮的思路再配合簡單的前綴復(fù)用同一臺機(jī)器上的并發(fā)數(shù)已經(jīng)明顯上去了。技術(shù)史不是線性的而是由無數(shù)個這樣的小實驗和公開報告中的系統(tǒng)方案共同累積出來的。希望你看完這條技術(shù)線也能找到屬于自己的那個“預(yù)算突破口”。