一個“降延遲”的開關，爲什麼會讓你更卡？
類似於英偉達的Reflex技術，Anti-Lag 不提升幀率，它只是讓 CPU 停下來等 GPU。
當 CPU 本來就有富餘時，這一等換來的是更跟手的操作；當 CPU 已經喫滿時，這一等就是從渲染線程嘴裏搶時間——平均幀沒變，幀生成時間卻開始抖，於是你感覺到開啓後反而不跟手——甚至在CPU壓力大的情況下直接卡到1幀，聲音還在放，畫面卻半天不動。
如果你在 AMD 驅動裏打開過 Anti-Lag，大概遇到過兩種截然相反的體驗：
在一些遊戲裏它讓甩槍更跟手，在《影之刃零》或《戰地 6》裏它卻讓畫面一頓一頓，甚至還不如關掉。
《影之刃零》：UE5 的CPU性能消耗，加上D加密
無論我個人還是羣友、以及黑盒評論區裏都可以看到對low幀波動的聲討，我的9850x3d 有時候也會卡到不能動（特別是CG播放、大場景切換的時候），low幀更是無規律觸底，平均low也奇低：龐鎮等區域只有30+，什麼地方能60+沒有規律
很多玩家反應荒行子戰鬥結束後開地板直接卡飛，其實A卡和N卡都有這個情況，Reflex開關對此沒有影響，Anti-Lag關閉卻能明顯改善。
· 着色器編譯 首次啓動要編譯着色器，有玩家反饋長達數十分鐘，這段時間 CPU 是滿的、，遊戲中也有着色器編譯
· 渲染線程 戰鬥場景裏粒子、毛髮、Lumen 光照同時壓上來，CPU 渲染線程成爲短板；
· 反篡改 帶 D加密，進程本身的校驗開銷不小，且對注入類改動更敏感；
· 幀生成 同時提供幀生成開關，而幀生成恰恰是 Anti-Lag 最容易算錯的場景。
四件事疊加，正好把 Anti-Lag 最不擅長的條件湊齊了：CPU 喫緊、幀生成開啓、還帶反篡改保護。這時候再開驅動級 Anti-Lag，等於在一個已經排滿的隊列前面，又加了一個等待點。
之前的《戰地 6》也遭過此難
《戰地 6》的問題更典型。它天生喫 CPU ，玩家裏的共識是：大多數機器在它上面都是 CPU 瓶頸，網格質量（Mesh Quality）和高保真物件數量是最喫 CPU 的兩項。
它的畫質菜單裏有一個“未來幀渲染”開關，作用是讓 CPU 提前多提交幾幀，用延遲換幀率穩定性。這跟 Anti-Lag 的設計目標正好相反。
如果兩樣都開，你實際上是在讓兩個控制器搶同一個方向盤。表現就是：幀數看着還行，但鏡頭轉動和開火時的頓挫感明顯，甚至在菜單裏都能感到不跟手。
爲什麼會有排隊？
因爲 CPU 和 GPU 是兩條彼此獨立的生產線。CPU 算完一幀遊戲邏輯可能只要 8 毫秒，GPU 畫完一幀卻要 12 毫秒。如果嚴格規定“算完一幀才允許畫下一幀”，CPU 就會有一大半時間閒着。於是引擎和驅動默認允許 CPU 提前跑——手上同時壓着兩三幀還沒畫完的指令。
這叫預渲染隊列（frames in flight）。它是純粹的吞吐優化：讓 GPU 永遠有活幹，幀率更穩、更不容易掉。代價就是延遲——你的按鍵排在隊列末尾，必須等前面那幾幀先畫完。
Anti-Lag 到底是什麼：三代技術，一條主線
按照 AMD 在 GPUOpen 上的官方描述，Anti-Lag 1 是“純驅動側技術，在驅動處理遊戲圖形命令時插入一段精心計算的延遲，使 CPU 幀與 GPU 幀對齊”；Anti-Lag+ 試圖把這段延遲的插入點搬進遊戲代碼內部；Anti-Lag 2 則把這件事做成了 SDK，讓遊戲開發者自己編譯進遊戲。
三代的目標完全一致：壓住 CPU，別讓它搶跑。差別只在“在哪裏壓”。
Anti-Lag+：越界的失敗
2023 年 10 月，Adrenalin 23.10.1 把 Anti-Lag+ 推給了《CS2》。它的實現方式是 detour 引擎的 DLL 函數——也就是修改遊戲進程裏那些函數的入口。從技術上看，這是一次“注入 + 改寫”，與作弊器常用的手法在行爲特徵上高度重合。
結果是 VAC 大面積誤封。Valve 在 10 月 13 日公開警告玩家不要開啓，AMD 在 10 月 17 日發佈 23.10.2 全局關閉該功能，Valve 在 10 月 19 日開始回滾封禁。整個過程不到十天。
這次事故說明的道理很直接：DLL注入遊戲是被大多數遊戲的反作弊不允許的
Anti-Lag 2 的進步
2024 年 5 月，AMD 與 Valve 合作，在《CS2》裏首發了 Anti-Lag 2 預覽版；同年 9 月，SDK 在 GPUOpen 以開源形式放出。區別在於：這次的代碼是遊戲開發者自己編譯進去的，不是驅動在運行時改的。插入點選在“遊戲採樣輸入之前”，這是整條管線裏最靠前、也最有效的位置。
對玩家來說，這意味着一個很實用的判斷方法：Anti-Lag 2 只會出現在遊戲自己的設置菜單裏。驅動裏那個開關管不到它，反過來，遊戲菜單裏有“Anti-Lag 2”字樣，說明這家廠商做了正經集成。
爲什麼開了反而更卡
這是全文的核心。需要先說明：Anti-Lag 在合適的場景下確實有效，但它的機制決定了，在另外一些場景下它會反過來傷害體驗。以下五個機制，通常不會單獨出現，而是疊加發生。
機制一：延遲是“主動等待”，等待就要佔資源
延遲不會憑空產生。要壓住 CPU，就必須讓它在一個循環裏等。這類等待在實現上通常是忙等（spin-wait）——線程不休眠，反覆檢查“GPU 畫完沒有”。這樣做精度最高，因爲一旦掛起再喚醒，時間精度就沒了。但代價是：等待期間，這個線程仍然佔着一個 CPU 核心的時間片。
在 GPU 瓶頸的機器上，CPU 本來就閒，佔着無所謂。但在 CPU 已經喫滿的機器上，這份被“空轉”消耗掉的時間，正好是從渲染線程和遊戲邏輯線程嘴裏搶來的。你省下了 10 毫秒延遲，卻可能讓某一幀的渲染晚了 30 毫秒。
機制二：卡頓是節奏問題，不是平均幀問題
玩家感知到的“卡”，絕大多數時候不是平均幀低，而是幀時間不均勻。
一秒鐘 60 幀，平均每幀 16.7 毫秒。如果這 60 幀裏有 55 幀只用了 14 毫秒、剩下 5 幀卻要 50 毫秒，平均幀依然接近 60，但你會非常清楚地感到“一頓一頓”。這就是爲什麼評測要看 1% Low，要看幀時間曲線，而不是隻報一個平均幀。
Anti-Lag 直接作用在幀提交的節奏上。當它的等待時長與遊戲實際的管線節奏不匹配時，本來均勻的提交間隔會被切成不均勻的段落——平均幀沒變，幀時間曲線卻開始長毛刺。這是“開了 Anti-Lag 反而更卡”最常見的成因，也是最難在參數上看出來的成因。
機制三：和遊戲自己的節奏管理打架
現代 3A 遊戲幾乎都有自己的幀率管理體系：引擎層的幀率上限、渲染線程與 RHI 線程的調度、動態分辨率、幀生成，以及“未來幀渲染”這類主動加深隊列的選項。
機制四：幀生成開啓時的錯位
幀生成（FSR FG、DLSS FG、AFMF）會在兩張真實幀之間插入插值幀。對 Anti-Lag 來說，麻煩在於它必須知道“這一幀是不是插值出來的”，否則對齊會算錯。
AMD 自己的 SDK 文檔就專門寫了這件事：啓用 FSR 幀生成時，需要額外調用 MarkEndOfFrameRendering 與 SetFrameGenFrameType，還要往 DXGI 交換鏈裏寫入一段帶特定 GUID 的私有數據，Anti-Lag 才能正確工作。
驅動層的 Anti-Lag 1 沒有這層信息。它看到的是“每一幀”，無法區分真假。於是在開啓幀生成時，它的節流點會落在錯誤的位置——這正是虛幻引擎 5 遊戲裏最容易出問題的地方。
真正有效的場景
把上面幾條反過來，就是 Anti-Lag 的舒適區：GPU 是瓶頸、幀率本來就高、CPU 有富餘、沒開幀生成、遊戲也沒有內置的低延遲方案。五個條件同時滿足時，它的收益是實打實的。
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
