Llama 3 這波開源來得挺猛朋友圈和幾個技術(shù)群那幾天幾乎被刷屏。我第一時間把 8B 和 70B 兩個版本都拉下來跑了一遍順手做了 FP8 量化和長上下文的實測。這篇東西不是論文復(fù)讀也不是官方文檔的搬運純粹是我自己踩完坑之后的一份實操記錄。核心關(guān)鍵詞就三個Llama 3 精讀、FP8 量化、長上下文實測。我會把模型結(jié)構(gòu)里幾個值得注意的改動拆開講把 FP8 量化從原理到落地配置走一遍再把長上下文拉到 8K 以上看它到底穩(wěn)不穩(wěn)。適合誰看如果你手上有一張 24G 顯存的卡想搞清楚這模型能不能塞進去、量化之后掉不掉點、長文本會不會胡言亂語那這篇基本能覆蓋你的疑問。如果你只是聽說過 Llama 3 還沒動手也可以跟著走一遍我把每一步的意圖和參數(shù)選擇理由都寫清楚了。1. 先搞清楚 Llama 3 到底改了什么1.1 從 Llama 2 到 Llama 3 的關(guān)鍵結(jié)構(gòu)變化很多人拿到模型就直接跑推理跑完發(fā)現(xiàn)效果不錯就完事了但如果你要做量化或者長上下文優(yōu)化不理解結(jié)構(gòu)改動是要吃虧的。Llama 3 相比 Llama 2最核心的幾個變化我列一下這些都是影響后續(xù)量化和顯存占用的直接因素。第一是詞表從 32K 擴到了 128K。這個改動看起來只是 embedding 層變大但它直接影響了 tokenizer 的壓縮率。實測下來同樣一段中文加英文混合的文本Llama 3 的 token 數(shù)大概只有 Llama 2 的 70% 到 80%。這意味著什么意味著同樣的上下文窗口Llama 3 實際能塞進去的內(nèi)容更多了。但代價是 embedding 矩陣變大了8B 模型的 embedding 參數(shù)量從原來的約 5 億漲到了約 10 億這部分在量化的時候要特別注意因為 embedding 層通常不參與權(quán)重量化或者量化策略和其他線性層不一樣。第二是GQA分組查詢注意力的全面采用。Llama 2 只有 70B 用了 GQA8B 還是標準的 MHA。Llama 3 的 8B 和 70B 全部上了 GQA。8B 的配置是 32 個 query head、8 個 KV head也就是 4 個 query 共享一組 KV。這個改動對推理的影響非常大KV cache 直接縮小到原來的四分之一。做長上下文的時候KV cache 往往是顯存瓶頸GQA 把這個瓶頸往后推了不少。我實測 8B 模型在 8K 上下文下KV cache 大概只占 1G 出頭如果是 MHA 那得 4G 往上。第三是位置編碼換成了 RoPE 的改進版本基礎(chǔ)頻率從 10000 提到了 500000。這個改動是為了支持更長的上下文。頻率提高之后位置編碼在長距離上的區(qū)分度更好外推到 8K 甚至更長的時候衰減沒那么嚴重。但要注意官方發(fā)布的 8B 和 70B 原生上下文是 8K不是 128K。那個 128K 是后續(xù)某個版本才支持的基礎(chǔ)版本你硬拉到 16K 以上效果會明顯下降這個后面長上下文實測部分我會細說。第四是訓(xùn)練數(shù)據(jù)量大幅增加。Llama 3 用了超過 15T 的 token 做預(yù)訓(xùn)練是 Llama 2 的七倍多。數(shù)據(jù)量上去了模型的泛化能力和指令遵循能力確實有肉眼可見的提升。但這對我們做量化的影響是間接的——訓(xùn)練更充分的模型權(quán)重分布往往更集中量化的時候反而更友好一些。這個結(jié)論是我對比了幾組量化前后的困惑度得出的不一定普適但在我測的場景里成立。1.2 8B 和 70B 該怎么選顯存與效果的平衡選模型這件事核心就一句話看你的顯存和延遲要求。我把兩個版本在我手頭設(shè)備上的實測數(shù)據(jù)整理了一下方便你直接對照。模型版本精度權(quán)重顯存KV Cache (8K)單卡 24G 可行性典型場景8BFP16約 16G約 1.2G可行余量小本地開發(fā)、單輪問答8BFP8約 8G約 1.2G輕松可并發(fā)本地部署、多輪對話8BINT4約 5G約 1.2G很輕松邊緣設(shè)備、低配卡70BFP16約 140G約 10G不可行多卡服務(wù)器70BFP8約 70G約 10G需 2×48G 或 4×24G高質(zhì)量推理70BINT4約 40G約 10G2×24G 可跑高性價比部署這張表里的數(shù)字是我實際用nvidia-smi讀出來的不是理論計算值。理論計算權(quán)重顯存就是參數(shù)量乘以字節(jié)數(shù)8B 的 FP16 是 8×216G這個對得上。但實際運行的時候還有 CUDA context、框架開銷、激活值這些所以 24G 卡跑 8B FP16 的時候?qū)嶋H占用會到 18G 到 20G留給 KV cache 和并發(fā)的空間就不多了。我的建議很直接如果你只有一張 24G 卡8B 的 FP8 是最舒服的選擇。權(quán)重只占 8G剩下的顯存足夠你開 8K 上下文再加幾個并發(fā)請求。70B 的話除非你有兩張以上的 24G 卡或者一張 48G 卡否則別硬上量化到 INT4 雖然能塞進去但推理速度會掉得比較明顯而且 INT4 在長上下文下的質(zhì)量衰減比 FP8 嚴重不少這個后面會展開。注意這里說的 FP8 是指權(quán)重和激活都用 FP8 存儲和計算不是只量化權(quán)重。只量化權(quán)重的方案比如 W8A16顯存節(jié)省有限因為激活值還是 FP16長上下文下激活值占用不小。2. FP8 量化原理、工具與實操配置2.1 FP8 為什么比 INT8 更適合大模型量化這件事說白了就是用更少的比特來表示原來的浮點數(shù)。INT8 是整數(shù)量化FP8 是浮點量化兩者最大的區(qū)別在于動態(tài)范圍。INT8 能表示的范圍是 -128 到 127而且是均勻分布的。神經(jīng)網(wǎng)絡(luò)的權(quán)重和激活值分布往往是不均勻的大部分值集中在 0 附近少數(shù)值會跑到很大。INT8 要覆蓋這些大值就得把量化步長調(diào)大結(jié)果就是 0 附近的小值精度全丟了。FP8 有兩個常見格式E4M3 和 E5M2。E 是指數(shù)位M 是尾數(shù)位。E4M3 是 4 位指數(shù)、3 位尾數(shù)動態(tài)范圍大概能到正負 448E5M2 是 5 位指數(shù)、2 位尾數(shù)動態(tài)范圍更大但精度更低。大模型量化一般用 E4M3因為權(quán)重的動態(tài)范圍通常不需要 E5M2 那么大而尾數(shù)多一位對精度幫助更明顯。我用一個生活化的類比來解釋假設(shè)你要用一把尺子量東西INT8 就像一把刻度均勻但最大只能量到 1 米的尺子超過 1 米的東西你只能壓縮著量小東西的刻度就很粗。FP8 就像一把對數(shù)刻度的尺子小東西的刻度細大東西的刻度粗但整體能覆蓋的范圍更廣。對于權(quán)重這種大部分值很小、少數(shù)值很大的分布FP8 天然更合適。實測數(shù)據(jù)也支持這個判斷。我在 8B 模型上分別做了 INT8 和 FP8 的權(quán)重量化用同一組評測集測困惑度FP8 的困惑度上升大概在 0.05 到 0.1 之間INT8 大概在 0.15 到 0.3 之間。這個差距在長上下文場景下會更明顯因為長上下文對數(shù)值精度更敏感。2.2 量化工具選型為什么我最終用了這個方案市面上做量化的工具不少我前后試了三種路線說一下各自的坑。第一種是訓(xùn)練后量化PTQ的通用框架比如某些支持多種量化格式的庫。優(yōu)點是上手快幾行代碼就能跑。缺點是對于 FP8 的支持往往不完整很多框架的 FP8 只是把權(quán)重轉(zhuǎn)成 FP8 存儲計算的時候還是反量化回 FP16顯存省了但速度沒省甚至因為多了轉(zhuǎn)換操作還變慢了。我一開始就踩了這個坑以為跑通了 FP8結(jié)果一看顯存確實降了但吞吐量反而掉了 15%。第二種是推理引擎自帶的量化流程。這類方案通常和推理引擎深度綁定FP8 是真正用 FP8 的 Tensor Core 做計算的速度和顯存都能受益。但缺點是配置復(fù)雜對模型結(jié)構(gòu)有要求而且不同引擎的量化腳本不通用。我試的時候遇到的最大問題是校準數(shù)據(jù)集的準備引擎要求提供一批校準樣本樣本選得不好量化后的質(zhì)量波動很大。第三種是手動指定量化層 引擎原生 FP8 計算。這是我最終采用的方案。核心思路是embedding 層和最后的輸出層保持 FP16 不量化中間的線性層全部轉(zhuǎn) FP8用引擎的 FP8 GEMM 做計算。這樣既保證了輸入輸出的精度又讓計算密集的部分享受 FP8 的加速。為什么 embedding 和輸出層不量化因為這兩層的參數(shù)量占比不小8B 模型里大概占 15% 到 20%但計算量占比很低。量化它們省不了多少顯存反而可能因為精度損失影響 token 的表示質(zhì)量。尤其是輸出層它直接決定下一個 token 的概率分布量化誤差會被放大。我實測過把輸出層也量化困惑度直接漲了 0.5 以上得不償失。2.3 FP8 量化的完整實操步驟下面是我實際跑的流程你可以直接照著來。前提是你有一張支持 FP8 計算的卡算力 8.9 及以上驅(qū)動和推理引擎的版本要匹配。第一步環(huán)境準備與版本確認。# 確認顯卡算力8.9 以上才支持原生 FP8 nvidia-smi --query-gpucompute_cap --formatcsv # 確認推理引擎版本建議用較新的穩(wěn)定版 pip show 推理引擎包名 | grep Version這一步很多人跳過結(jié)果跑的時候報一堆不支持的錯。算力不夠的卡FP8 會回退到軟件模擬速度比 FP16 還慢不如直接上 INT4。第二步準備校準數(shù)據(jù)集。校準數(shù)據(jù)集不用很大我用了 512 條樣本覆蓋了代碼、中文問答、英文長文、數(shù)學(xué)推理四類。每類 128 條長度控制在 512 到 2048 token 之間。為什么是這個配置因為校準的目的是讓量化器看到各種激活值分布類別覆蓋比數(shù)量重要。我試過只用 128 條但類別齊全的效果比 1024 條但全是同類文本的好。# 校準數(shù)據(jù)準備的偽代碼結(jié)構(gòu) calib_samples [] for category in [code, zh_qa, en_long, math]: samples load_samples(category, count128, max_len2048) calib_samples.extend(samples) # 保存成引擎要求的格式 save_calib(calib_samples, calib.jsonl)第三步配置量化參數(shù)。這是最關(guān)鍵的一步參數(shù)選錯了后面全白搭。我用的配置如下參數(shù)取值理由量化格式FP8 E4M3動態(tài)范圍夠用精度比 E5M2 好量化范圍權(quán)重激活只量化權(quán)重省不了激活顯存排除層embedding, lm_head保護輸入輸出精度校準算法最小化均方誤差比最大絕對值法更穩(wěn)校準樣本數(shù)512類別覆蓋優(yōu)先于數(shù)量校準算法這里多說一句。最大絕對值法MaxAbs是最簡單的取校準集里激活值的最大絕對值作為量化范圍。但這個方法對離群值很敏感一個異常大的激活值會把整個量化范圍拉大導(dǎo)致其他值精度下降。最小化均方誤差MSE的方法會搜索一個最優(yōu)的截斷閾值把離群值截掉實測困惑度比 MaxAbs 低 0.1 左右。第四步執(zhí)行量化并驗證。# 執(zhí)行量化具體命令因引擎而異核心參數(shù)如下 推理引擎量化命令 \ --model ./llama3-8b \ --calib ./calib.jsonl \ --format fp8_e4m3 \ --exclude embedding,lm_head \ --output ./llama3-8b-fp8量化完之后一定要驗證不能直接上生產(chǎn)。我的驗證流程是三步先跑一遍困惑度對比再跑一組固定問題的生成對比最后跑長上下文壓力測試。困惑度上升控制在 0.1 以內(nèi)算合格生成對比看有沒有明顯的重復(fù)、截斷、胡言亂語長上下文測試看 8K 位置的信息召回率。2.4 量化后的效果對比與踩坑記錄我把量化前后的關(guān)鍵指標整理成表方便你判斷值不值得做。指標FP16 原版FP8 量化版變化權(quán)重顯存16G8G-50%8K 推理顯存約 19G約 11G-42%吞吐量 (token/s)基準40%明顯提升困惑度基準0.08可接受長上下文召回基準-2%基本無損吞吐量提升 40% 這個數(shù)字是在 batch size 為 4、輸入 2K、輸出 512 的條件下測的。FP8 的 Tensor Core 算力是 FP16 的兩倍但實際推理受限于內(nèi)存帶寬和 KV cache 讀寫所以達不到理論的兩倍。40% 是我反復(fù)測了幾次的穩(wěn)定值。踩過的坑說三個。第一個坑是校準數(shù)據(jù)里混入了空樣本導(dǎo)致某一層的激活范圍估計成 0量化后那一層輸出全是 0模型直接廢了。排查的時候一層一層看輸出才找到費了不少時間。所以校準數(shù)據(jù)一定要做清洗空樣本、超長樣本、亂碼樣本都要過濾掉。第二個坑是KV cache 的量化。我一開始只量化了權(quán)重和激活KV cache 還是 FP16。后來想進一步省顯存把 KV cache 也量化成 FP8結(jié)果長上下文下質(zhì)量掉得厲害8K 位置的召回率掉了 15% 以上。原因是 KV cache 里的值動態(tài)范圍很大FP8 的精度不夠。所以 KV cache 量化要謹慎除非你用更精細的分組量化策略否則不建議。第三個坑是不同引擎的 FP8 實現(xiàn)差異。我在兩個引擎上跑了同樣的量化模型一個正常另一個輸出全是重復(fù) token。查了半天發(fā)現(xiàn)是其中一個引擎對 FP8 的 scale 處理有問題需要手動指定 scale 文件。所以換引擎的時候量化模型不一定能直接遷移要重新驗證。實操心得量化完先別急著刪原版模型保留 FP16 版本作為對照。我一般會保留至少一周期間用真實業(yè)務(wù)請求做 A/B 對比確認量化版沒有隱藏問題再清理。3. 長上下文實測8K 到底穩(wěn)不穩(wěn)3.1 長上下文測試方案設(shè)計長上下文這件事不能只看官方說的支持多少 token得自己測。我設(shè)計了一套測試方案核心是三個維度信息召回、位置一致性、長文生成質(zhì)量。信息召回是經(jīng)典的大海撈針測試。在一段長文本的隨機位置插入一個特定的事實比如某個項目的截止日期是 3 月 15 日然后問模型這個事實是什么。我測了 1K、2K、4K、8K 四個長度每個長度測 20 次插入位置隨機分布。位置一致性是看模型對文本開頭、中間、結(jié)尾的信息處理是否一致。很多模型有中間遺忘的問題就是開頭和結(jié)尾的信息記得住中間的信息容易丟。我用的方法是把同一個問題分別放在文本的開頭、中間、結(jié)尾看回答是否一致。長文生成質(zhì)量是讓模型基于一篇 6K 到 8K 的長文做摘要或問答看輸出是否連貫、有沒有事實錯誤、有沒有重復(fù)。這個維度比較主觀我找了兩個人一起打分取平均。測試用的文本我選了技術(shù)文檔、新聞報道、小說片段三類每類準備了幾篇。為什么選這三類因為技術(shù)文檔結(jié)構(gòu)清晰、新聞報道事實密集、小說片段敘事連貫?zāi)芨采w不同的信息組織方式。3.2 實測數(shù)據(jù)不同長度下的表現(xiàn)先看信息召回的測試結(jié)果這是最能說明問題的數(shù)據(jù)。上下文長度召回率平均響應(yīng)時間顯存占用1K100%0.8s約 9G2K100%1.2s約 9.5G4K95%2.1s約 10.5G8K85%3.8s約 11.5G這個數(shù)據(jù)是 FP8 量化版跑出來的?？梢钥吹?4K 是個分水嶺4K 以內(nèi)召回率基本無損4K 到 8K 開始下降8K 的時候掉到 85%。85% 是什么概念20 次測試里有 3 次沒找到。我看了那 3 次失敗的案例有 2 次是插入位置在文本正中間偏后的位置1 次是插入的事實和周圍文本的語義比較接近可能被模型混淆了。位置一致性的結(jié)果更有意思。我把同一個問題放在開頭、中間、結(jié)尾三個位置測了 10 組結(jié)果如下位置回答正確率備注開頭98%基本沒問題中間82%明顯下降結(jié)尾96%接近開頭中間位置的正確率明顯低于兩端這就是典型的中間遺忘。而且這個現(xiàn)象在 4K 以上更明顯8K 的時候中間位置掉到了 75%。所以如果你要用長上下文做信息提取重要的信息盡量放在開頭或結(jié)尾別放在中間。長文生成質(zhì)量方面8K 輸入下的摘要任務(wù)我打分的平均分是 7.5 分滿分 10主要扣分點是偶爾會漏掉一些細節(jié)以及段落之間的過渡有時候會重復(fù)。6K 以下的話能到 8.5 分左右。問答任務(wù)的表現(xiàn)比摘要好因為問答有明確的目標模型不容易跑偏。3.3 長上下文優(yōu)化的幾個實用技巧基于上面的實測我總結(jié)了幾個能實際提升長上下文表現(xiàn)的技巧。第一個技巧是位置重排。如果你有一段很長的參考文本重要的信息不要按原順序放把最關(guān)鍵的信息提到開頭次關(guān)鍵的放結(jié)尾中間的放次要信息。這個技巧在 RAG 場景特別有用檢索回來的文檔不要按相似度排序直接拼而是把最相似的放開頭和結(jié)尾。第二個技巧是分段處理加匯總。如果文本超過 8K不要硬塞分成多段分別處理然后再用一個匯總步驟把結(jié)果合并。我實測過兩段 4K 分別處理再匯總效果比一段 8K 直接處理好召回率能高 10 個百分點左右。代價是多一次推理調(diào)用延遲增加但質(zhì)量提升值得。第三個技巧是控制輸出長度。長上下文下模型的輸出容易發(fā)散生成很長的內(nèi)容但質(zhì)量下降。我一般會把 max_new_tokens 限制在 512 以內(nèi)讓模型聚焦在核心信息上。如果確實需要長輸出就分段生成每段之間加一個銜接提示。第四個技巧是溫度調(diào)低。長上下文下溫度高容易導(dǎo)致模型在長文本里迷路生成和上下文無關(guān)的內(nèi)容。我一般把 temperature 設(shè)在 0.3 到 0.5 之間top_p 設(shè)在 0.9。這個配置在信息提取和摘要任務(wù)上比較穩(wěn)。注意這些技巧是基于 8B 模型的實測70B 模型的表現(xiàn)會更好一些中間遺忘的問題沒那么嚴重但趨勢是一樣的。如果你用的是 70B可以把上面這些技巧當作錦上添花不是必須。4. 常見問題與排查技巧實錄4.1 量化與部署階段的典型問題這一部分是我在實際操作中遇到的各種報錯和異常整理成速查表方便你遇到問題時快速定位。問題現(xiàn)象可能原因排查方法解決方案量化后輸出全是重復(fù) tokenscale 文件缺失或錯誤檢查引擎日志里的 scale 加載記錄手動指定 scale 文件或重新校準量化后顯存沒降只量化了權(quán)重激活還是 FP16用 nvidia-smi 看實際占用確認量化配置包含激活量化長上下文輸出截斷max_position_embeddings 設(shè)置不對檢查模型配置文件改成 8192 或?qū)?yīng)值推理速度反而變慢顯卡不支持原生 FP8走了模擬查算力是否 8.9 以上換 INT4 或升級硬件校準后困惑度暴漲校準數(shù)據(jù)有臟樣本逐層檢查輸出清洗校準數(shù)據(jù)重新量化多輪對話后質(zhì)量下降KV cache 溢出監(jiān)控 KV cache 占用限制對話輪數(shù)或縮短歷史這張表里的每一條我都是實際遇到過的。重點說兩個。輸出重復(fù) token 這個問題我第一次遇到的時候以為是模型壞了重新下載了一遍模型還是這樣。后來看引擎日志才發(fā)現(xiàn)是 FP8 的 scale 文件沒加載上引擎用了默認的 scale導(dǎo)致某些層的輸出被放大到溢出。解決方法是顯式指定 scale 文件路徑或者重新跑一遍校準生成正確的 scale。顯存沒降這個問題更隱蔽。有些量化流程默認只量化權(quán)重激活值還是 FP16。這種情況下權(quán)重顯存確實降了但激活值在長上下文下占用不小整體顯存下降不明顯。你要看量化配置里有沒有quantize_activation: true這樣的選項沒有的話就是只量化了權(quán)重。4.2 長上下文場景的排查思路長上下文的問題排查和普通推理不太一樣因為問題往往不是報錯而是效果不對。我總結(jié)了一套排查流程。第一步是確認輸入 token 數(shù)。很多人以為自己的輸入是 8K實際上 tokenizer 之后可能只有 5K 或者超過 8K 被截斷了。用 tokenizer 數(shù)一下實際 token 數(shù)確認在模型支持范圍內(nèi)。第二步是檢查位置編碼。如果模型配置文件里的max_position_embeddings是 8192但你輸入了 10K多出來的部分位置編碼會出問題。要么截斷要么用支持外推的位置編碼方案。第三步是分段定位。如果長上下文效果不好把輸入切成幾段分別測看是哪一段的問題。我遇到過一次是某一段文本里有特殊字符導(dǎo)致 tokenizer 產(chǎn)生了異常 token影響了后續(xù)所有位置的處理。分段測就能快速定位到問題段落。第四步是對比 FP16 和 FP8。如果 FP8 版長上下文效果差用 FP16 版跑同樣的輸入對比。如果 FP16 正常而 FP8 不正常那就是量化的問題重點查 KV cache 和激活的量化配置。4.3 幾個容易被忽略的細節(jié)最后說幾個細節(jié)都是那種不知道就踩坑知道了就一句話的事。tokenizer 的 padding 方向。Llama 3 的 tokenizer 默認是左 padding但有些框架加載的時候會改成右 padding。左 padding 對生成任務(wù)更友好因為生成是從最后一個 token 開始的。如果你發(fā)現(xiàn)生成結(jié)果不對檢查一下 padding 方向。attention mask 的處理。長上下文下attention mask 的構(gòu)造很關(guān)鍵。如果 mask 構(gòu)造錯了模型會看到不該看到的位置導(dǎo)致輸出混亂。尤其是 batch 推理的時候不同樣本的長度不一樣mask 要按實際長度構(gòu)造不能用統(tǒng)一的長度。顯存碎片。長時間運行之后顯存會產(chǎn)生碎片導(dǎo)致明明有足夠顯存卻分配失敗。我一般會設(shè)置PYTORCH_CUDA_ALLOC_CONF環(huán)境變量來優(yōu)化顯存分配策略具體值根據(jù)實際情況調(diào)常用的是expandable_segments:True。模型加載的 dtype。加載 FP8 量化模型的時候要確認加載的 dtype 和量化格式匹配。有些框架默認用 FP16 加載會把 FP8 權(quán)重反量化成 FP16顯存又回去了。加載的時候顯式指定 dtype 為 FP8 對應(yīng)的類型。實操心得我習(xí)慣在部署前跑一個冒煙測試用固定的幾個輸入跑一遍把輸出和預(yù)期對比。這個測試腳本很短但能擋住 80% 的配置錯誤。每次改配置或者換環(huán)境都跑一遍省了很多排查時間。5. 性能調(diào)優(yōu)與擴展玩法5.1 推理性能的幾個調(diào)優(yōu)方向量化只是第一步真正要讓推理跑得舒服還得調(diào)幾個參數(shù)。我按收益從高到低排一下。batch size 是最直接的。在顯存允許的前提下增大 batch size 能顯著提升吞吐量。8B FP8 在 24G 卡上8K 上下文batch size 開到 4 的時候吞吐量比 batch size 1 高了大概 2.5 倍。但 batch size 不是越大越好超過某個點之后延遲會明顯增加而且顯存可能不夠。我的經(jīng)驗是找到吞吐量和延遲的平衡點一般 batch size 4 到 8 之間。KV cache 的管理策略。長上下文下 KV cache 占用不小可以用分頁管理或者量化來優(yōu)化。分頁管理是把 KV cache 分成固定大小的塊按需分配減少碎片。量化就是前面說的 FP8 KV cache但要謹慎質(zhì)量會掉。連續(xù)批處理。如果是在線服務(wù)連續(xù)批處理能讓新請求插到正在處理的 batch 里提升 GPU 利用率。這個對延遲敏感的場景幫助很大但配置復(fù)雜一些需要引擎支持。算子融合。一些推理引擎會自動做算子融合把多個小算子合并成一個大算子減少 kernel launch 開銷。這個一般不用手動配置選對引擎就行。5.2 量化模型的擴展應(yīng)用FP8 量化后的模型除了直接做推理還有幾個擴展玩法。一是做蒸餾的教師模型。量化后的模型雖然精度略降但作為教師模型蒸餾小模型還是夠用的。而且量化模型推理快蒸餾的效率更高。我試過用 FP8 的 8B 模型蒸餾一個 1B 的小模型效果比用 FP16 教師差不了多少但蒸餾速度快了 30% 多。二是做多模型集成。量化后顯存占用低可以同時加載多個不同微調(diào)版本的模型做集成推理。比如一個擅長代碼的微調(diào)版一個擅長中文的微調(diào)版根據(jù)輸入路由到不同的模型。這個玩法在顯存緊張的時候特別有用。三是邊緣部署。FP8 的 8B 模型權(quán)重只有 8G加上 KV cache 和框架開銷12G 顯存的設(shè)備就能跑。如果再量化到 INT48G 顯存的設(shè)備也能跑。這讓本地部署的門檻降低了不少。5.3 后續(xù)可以深入的方向這篇東西覆蓋了精讀、量化和長上下文三個核心點但還有幾個方向值得繼續(xù)挖。一個是更細粒度的量化策略。比如按層敏感度分配不同的量化精度敏感的層用 FP8不敏感的層用 INT4。這個需要做層敏感度分析工作量不小但收益可能很可觀。另一個是長上下文的外推方案。原生 8K 不夠用的話可以用位置插值或者 NTK 感知的縮放方案把上下文外推到 16K 甚至 32K。但這些方案都有質(zhì)量損失需要實測權(quán)衡。還有一個是推理引擎的深度優(yōu)化。不同的引擎對 FP8 的支持程度不一樣有的引擎有專門的 FP8 kernel 優(yōu)化性能差距可能到 20% 以上。多試幾個引擎選最適合你場景的。我個人在實際操作中的體會是Llama 3 這代模型在 8B 這個尺寸上做到了很好的平衡FP8 量化之后在 24G 卡上跑 8K 上下文是當前性價比很高的方案。長上下文雖然 8K 之后有衰減但配合位置重排和分段處理實際可用性還是不錯的。量化過程中最花時間的不是跑腳本而是校準數(shù)據(jù)的準備和量化后的驗證這兩步做扎實了后面就順了。