@Grayson-Ren
我自己测试了一下--pool-workers参数的问题：
pool-workers decode t/s 相对默认
17（默认） 129.4 基准
15 128.1 -1.0%
13 129.3 -0.1%
11 128.2 -0.9%
9 126.7 -2.1%
7 123.4 -4.6%
长提示词 b15k/b32k（warm）：预填充 917 全在 ±3% 内无趋势；解码差异与各轮 MTP 命中率（6282%）强相关，是投机噪声。 多样低命中（~87.5%）pass2 解码均值：17→74.7、11→75.0、9→72.9。
结论：
在11-17 之间解码无差异，≤9 才明显变慢。
默认 17（=18 物理核 −1 + host 线程，正好占满物理核、无 SMT 超订）已是最优/并列最优。你用11的收益更像其特定平台/配置（缓存命中率、内存时序）所致，不一定普遍，其他有兴趣的朋友也可以自己测试对比一下！
给大家提个醒，如果是7900XTX，暂时就保留在0.1.39版本（24G显存也不要开多并发），因为最新的0.1.40速度并没有提升而且如果你开并发时会直接挂起死掉，这应该是个BUG，要等官方更新了！以下是我实测的结果：
配置 b15k(15K) 结果
0.1.40 + parallel:2 挂起 GPU 挂起，稳定复现
0.1.40 + parallel:2 + STRATA_RING_BYTES=0 挂起 仍挂起
0.1.40 + parallel:1 1578 正常但比 0.1.39 慢 ~7-8%
0.1.40 + parallel:1 + STRATA_WMMA_GEMM=1 1411 更慢（上游默认关是对的）
挂起特征：reading the prompt (batched): waiting for the GPU ... no progress for 60s（issue #29）→ released the verify window's GPU waits (#267) → 引擎自停 exit -6。0.1.40 的批量提示路径在 gfx1100 上有回归，b15k 每次必挂、b32k 不挂。
官方 release 也明说 AMD 基本未测（只测了 gfx1151）。
起因：想用最小代价验证"多核 CPU 对 MoE 推理有没有帮助"。E5 v3 洋垃圾很便宜（我为这个测试专门去买了一颗2699V3，花了50元），就陆续换了 6 核 → 14 核 → 18 核试。实测结论：6 核换 14 核值得（提升明显），14 核再换 18 核不值得（数据持平，而且更耗电）。
| 指标 | 14C/28T（E5-2683 v3） | 18C/36T（E5-2699 v3） | 变化 |
|---|---|---|---|
| 15K 预填充 | 1563.7 t/s | 1559.0 t/s | 持平 |
| 32K 预填充 | 1613.9 t/s | 1608.3 t/s | 持平 |
| 短提示解码 | 45.0 t/s | 46.0-49.3 t/s | 仅 +2~9% |
| 15K / 32K 解码 | 42.1 / 55.6 | 45.5 / 49.7 | 波动内 |
| CPU | 核心/线程 | TDP | 短提示解码 | 15K 预填充 | 结论 |
|---|---|---|---|---|---|
| E5-1650 v3 | 6C/12T | 140W | 25.6-29.4 t/s | 968-975 t/s | 起点 |
| E5-2683 v3 | 14C/28T | 120W | 45.0 t/s | 1563.7 t/s | 值得换：解码 +55~75%、预填充 +60% |
| E5-2699 v3 | 18C/36T | 145W | 46-49 t/s | 1559.0 t/s | 不值得：几乎无提升，TDP 反升 25W |
（Strata 的 CPU 线程池默认 = 物理核数 − 1：6 核 5 个 worker、14 核 13 个、18 核 17 个。6 核那档同时叠加了旧引擎/mmap 模式/当时双通道内存，不宜单独归因 CPU，但"6→14 核大幅提升"的方向是明确的。）
| 指标 | 引擎 0.1.34 | 引擎 0.1.38 | 变化 |
|---|---|---|---|
| 15K 预填充 | 1559.0 t/s | 1723.5 t/s | +10.6% |
| 32K 预填充 | 1608.3 t/s | 1776.5 t/s | +10.5% |
（数据均为本机实测：7900 XTX 24G + X99 + DDR4-2133 四通道；不同平台/驱动会有差异，仅供参考。）
我的实际用下来的感觉就是qwen3.8-flash-next不能用iq3xxs，必须得用iq3s这个版本，它的能力比q4-27b要强！具体测试题目你们可以参考我发到本坛的贴子，而且在多轮修改中iq3s都能比较精准解决问题！
附我上讲的几道测试AI大模型编程能力的经典题目：
Q1：强约束指令遵循句子生成测试（这题很容易让一些模型陷入无限循环思考,特别是qwen3.8-27b这个开了思考时，能做对的模型极少）
输出10个以汉字数字结尾的句子，且按照顺序一到十，语句要通顺有意义，且倒数第二个字不能重复且不能是"第"，"是"，"为"
Q2：鹈鹕土星环骑自行车SVG测试（此题能比网上的直线骑行要难，特别是转弯能做对的也很少，qwen3.8-flash-next能基本一次做对，qwen3.8-27b-4bit完全做不动，也改不好）
请生成一段独立完整的 16:9 纯 SVG 动画：一只鹈鹕骑着自行车，车轮旋转，鹈鹕踩动脚踏，沿着土星环轨道进行 360° 环形骑行。鹈鹕和自行车结构清晰。在椭圆轨道的左右极端转弯处，动作必须自然平滑，不能出现车身倒立或瞬间闪现掉头。只输出 SVG，无外部资源。注意：实现后只做基本语法检查，不能查看渲染后结果进行调整。
Q3：复合弓射箭SVG测试（很少有做对的模型，复合弓要不拿反，要不没有双弦，拉弦时双轮转动方向要不一致，人物拉弓两手经常画错，射出的箭不能命中靶心，没有命中时靶心时的动态效果等错误）
生成独立完整、不引用外部图片的16:9的 SVG 动画。画面是人物拉开复合弓，滑轮同步转动；松开弓弦，箭按抛物线飞行，最后命中靶心。所有图形全部用 SVG 绘制，只输出 SVG 代码，不要多余文字。注意：实现后只做基本语法检查，不能查看渲染后结果进行调整。
Q4：MACOS浏览器内操作系统（计算器显示不全，计算不对，3D太空游戏错误就更多了，画成平面不是立体的，无法用键盘操作，子弹乱射等）
参考macOS最新操作系统，创建一个现代、有着精美桌面和UI的浏览器内操作系统（命名为"AISniper OS"）。要求包含系统状态弹窗（如 Wi-Fi、系统健康度）、时钟、底部快捷栏、主题切换功能，并内置可交互的 3D 太空射击游戏，底部快捷栏应该有Finder，计算器，设置、命令行终端和太空射击游戏。最后要注意：实现后不要用无头浏览器等进行UI等其他验证，直接交付
Q5：3D 赛车游戏（车子造型不对，跑不在轨道，障碍物堵塞车道，不能加速向前，整个画面不清晰等）
使用 HTML、CSS 和 JavaScript，创建一个以汽车为主角的 3D 赛伯朋克风格无限跑酷游戏。网页必须通过 Canvas 或 Three.js 渲染出一条沿纵深无限延伸的赛道，核心交互要求实现摄像机视角随着弯曲赛道实时左右平滑晃动的追踪动效，以及汽车切换赛道时的高灵敏度物理避障反馈；赛道上必须动态刷新各种障碍物，且页面顶部需内置一个能随着行驶距离和避障表现实时渲染、不被遮挡的高清动态计分板。最后要注意：实现后不要用无头浏览器等进行UI等其他验证，直接交付
有兴趣的你们可以自己测试模型的能力！我们不光要看速度，关键还得看它是否能真正干活！
分类：AI硬件
标签：7900xtx、x99、内存通道、ddr4、qwen-flash、strata
一句话：同一张 7900 XTX，硬件上做三件便宜事（内存双通道→四通道、CPU 6 核→14 核、加一张亮机卡让 XTX 的 24G 全部用于计算），再换用 Strata 引擎，单卡 24G 本地大模型辅助编程就从"能玩"变成了"有生产力"。
硬件党先看：本文最有价值的不是软件配置，而是三个便宜且立竿见影的硬件点——
三项叠加 + 引擎优化后，单卡 24G 实测：预填充 1460-1614 tok/s、解码 40-55 tok/s，还能看图、跑 262K、切无审查。下面给出每一步的实测数据。
| 部件 | 型号 | 备注 |
|---|---|---|
| GPU | AMD RX 7900 XTX 24G（Navi31） | 计算主力 |
| 亮机卡 | AMD R7 240/340 2G | 只接显示器，见 1.4 |
| CPU | Intel Xeon E5-2683 v3（14C/28T @2.0G） | 原为 E5-1650 v3（6C/12T） |
| 内存 | 64G DDR4-2133（4×16G，四通道） | 原为双通道，见 1.2 |
| 存储 | NVMe 512G 专用数据盘（ext4） | 模型/Pack 全放这里 |
| 系统 | Linux + ROCm 10.0（/opt/rocm） | 系统 ROCm 直接编译，无需 TheRock |
![四通道内存的完整插法]
![内存通道 A1 和 B1]
![内存通道 C1 和 D1]
Vulkan0=R7 200、Vulkan1=7900 XTX，启动显式指定计算卡）。![7900 XTX 与亮机卡]
| 阶段 | 硬件 + 引擎 | 模型 | 15K 预填充 | 短提示解码 | 15K / 32K 解码 |
|---|---|---|---|---|---|
| A | 6C/12T + 双通道 + llama.cpp | AD-4.27bpw | 120-142 | 10.3 | 8.4 / - |
| B | 6C/12T + 双通道 + Strata 0.1.28（mmap+pageable） | IQ3_XXS | 968-975 | 25.6-29.4 | 34-43.5 / - |
| C | 14C/28T + 四通道 + Strata 0.1.34（arena） | IQ3_XXS | 1477 | 47.0 | 39.5 / 48.3 |
| 特性 | 说明 | 对我们的意义 |
|---|---|---|
| 125B MoE / 6B 激活 | 48 层，512 专家、每 token 激活 10+1 | 计算量小，权重总量大 |
| 51B n-gram 表（PLE） | 每层预测性嵌入，本质是稀疏查表，不参与矩阵乘 | 每 token 只随机读约 2.7KB，可常驻 SSD（mmap + TENSOR_READ_LAZY 懒加载） |
| GDN + QSA 混合注意力 | 3/4 层是 Gated DeltaNet 线性注意力（状态恒定），1/4 层是 QSA 稀疏注意力 | KV 极小：220K int8 KV 仅约 3G，不需要 KVMem 换页 |
| 4B MTP 草稿头 | 自带投机解码 | 解码吞吐提升（本机接受率 60-87%） |
| 原生 262,144 上下文 | 官方支持 | 配合小 KV，长会话便宜 |
核心：正是"51B 表在 SSD + KV 极小"，让 64G 内存的消费级平台能跑 176B 存储量的模型。
| 指标 | llama.cpp（主线 ROCm） | Strata（HIP） |
|---|---|---|
| 专家执行方式 | CPU 层与 GPU 层顺序执行 | CPU 专家池与 GPU 并行 |
| GPU 专家缓存 | 无 | 有（热专家自动缓存） |
| 大块预填充 | 普通 | 8K 大块 |
| MTP 投机 | qwen4exp 无 MTP 图 | 内置 |
| 15K 预填充 | 120-142 tok/s | 1460-1614 tok/s |
| 短提示解码 | 10.3 tok/s | 40-47 tok/s |
| 262K 上下文 | 可加载 | 可加载（KV 流式更省显存） |
| 视觉 | 支持（mmproj） | 官方 HIP 不支持 → 自己补（第 7 节） |
| 量化适配 | 任意 GGUF | GSQ-RCO / compat-bf16 打包 |
结论：llama.cpp 是"能跑"，Strata 才是"能用"；10 t/s 的锅主要是引擎（顺序执行），当时双通道内存又雪上加霜。
| 档位 | 来源 | 体积 | 用途 |
|---|---|---|---|
| IQ3_S | ISTA-DASLab GSQ-RCO（官方） | 83.6G | 编程/复杂任务主力 |
| IQ3_XXS | ISTA-DASLab GSQ-RCO（官方） | 75.8G | 长上下文/速度备选 |
| SC117 IQ3_S（无审查） | 官方 GSQ-RCO + 144 个消融张量移植 | 83.9G | 需要无审查时 |
核心经验：只认官方发布或社区反馈好的；来源不明的消融/微调版，很多下载下来就是坑。
| 模型（Flash-Next 125B） | 来源/类型 | 体积 | 实际结果 |
|---|---|---|---|
| AD-4.27bpw-Q4_K_M-M64 | AtomicChat（社区，SSD-PLE 设计） | 94.5G | llama.cpp 可跑、质量好、有视觉；但引擎慢（10 t/s）；后删除 |
| IQ3_S | ISTA-DASLab（官方 GSQ-RCO） | 83.6G | 最可靠，编程主力 |
| IQ3_XXS | ISTA-DASLab（官方 GSQ-RCO） | 75.8G | 可靠，长上下文备选 |
| Orca 无审查 IQ3_XXS | orcarouter（整模微调，门控仓库） | 85.2G | 需 HF token 才能下；能跑但编程明显弱；删 |
| RVN 消融 IQ4_XS | 0bserverx（重度消融） | 97.5G | 能跑但编程弱、且慢 20-25%（专家大 40%）；删 |
| SC117 消融 IQ3_S | SC117（官方量化 + 消融张量移植） | 83.9G | 速度=官方 IQ3_S、无审查；当前第 3 档 |
| huihui 消融 UD-Q4_K_XL | huihui-ai（社区） | 111G | 未下：AMD 提示词内核 NVIDIA-only、无视觉 |
| mradermacher 无审查 i1 | 社区（Orca 基） | 90G+ | 未下：同 Orca 基，编程弱 |
| windowsxp / UltimateIntent 消融 | 社区 | 98-119G | 未下：体积过大，64G 内存装不下 |
| Baekpica SSD-PLE MQ-Q5 | 社区 | 83.3G | 未下：需专用 ds4 loader，不通用 |
| Navin AD-4.27 | 社区（Orca 基） | ~95G | 未下：同 Orca 基 |
| jimmy31chen RVN IQ3_S Strata 版 | 社区 | 88.9G | 未下：新仓未验证（备选） |
| 模型（27B，早期项目） | 来源/类型 | 体积 | 结果 |
| --- | --- | ---: | --- |
| Qwen3.8-27B-UD-Q4_K_M | unsloth UD（官方基座） | 16.4G | 27B 日常主力 |
| Swift-1.5-27B-Uncensored IQ4_XS | 社区（编程特化无审查） | 14.25G | 27B 无审查可用 |
| DFlash2-Q4_K_M（草稿） | 社区 | 1.14G | 投机解码草稿 |
选型四条铁律
| 指标 | IQ3_S | IQ3_XXS | SC117 IQ3_S（无审查） |
|---|---|---|---|
| 体积 | 83.6G | 75.8G | 83.9G |
| GPU 专家槽 | 8903 | 10505 | 8700 |
| 15K 预填充 | 1460 t/s | 1477 t/s | 1564 t/s |
| 32K 预填充 | 1552 t/s | 1566 t/s | 1614 t/s |
| 短提示解码 | 40.8 t/s | 47.0 t/s | 45.0 t/s |
| 15K 解码 | 44.8 t/s | 39.5 t/s | 42.1 t/s |
| 32K 解码 | 43.6 t/s | 48.3 t/s | 55.6 t/s |
| 视觉 | 支持 | 支持 | 支持 |
| 无审查 | 否 | 否 | 是 |
（解码数值随草稿接受率波动，同题对比即可；预填充为冷启动首次读取。）
| 优化 | 本机实测 | 收益 |
|---|---|---|
| WMMA 内核（gfx11 矩阵核，PR #260） | IQ3_XXS 15K：698-774 → 968-975 | +35~39% |
| hipBLASLt 本机调优表（38 行，回退 0 次） | 612 → 737 | +20% |
| pinned 专家 arena（替代 mmap+pageable） | IQ3_XXS 15K 1071 → 1452；32K 1124 → 1571 | +36% / +40% |
| kv-resident + resident-cpu-experts + 静态 profile | 短提示解码 25.2 → 29.4 | +15% |
| 采样固定 0.6/0.95/20 | 思考死循环 → 正常收敛 | 决定可用性 |
| 引擎升级 0.1.34 | 客户端 5 秒断开 → 立即 cancel=True |
不再空烧 GPU |
--mtp-window 65536 |
采用（社区实测长上下文有效；本机未单独 A/B） | - |
tools/hip/tune_hipblaslt.cpp 在本机现场生成 38 行表（覆盖官方全部形状），实测回退 0 次，预填充 +20%。cudaHostRegister PORTABLE）后预填充 +36%。--kv-resident 32768（32K 在显存，其余进内存）+ 静态专家 profile + --adapt-every 0。temperature 0.6 / top_p 0.95 / top_k 20 解决。--mtp-window 65536（长上下文草稿接受率不再掉）。--vision + GENI 协议，视觉是独立助手进程（llama.cpp mtmd）。tools/vision 用 CPU 模式单独编译出 strata-vision，配置里加 --vision 和 vision 块。三套模型都能识图，且不占显存。ple_key 类型补丁（让消融量化能加载）blk.1.ple_key.weight 是 IQ3_XXS/IQ4_XS 类型，引擎原生路径误判，报 incompatible matrix blk.1.ple_key.weight。native_dense.cpp 的 eligible() 只接受 type 42（Q2_0），其余走 compat-bf16 打包的 BF16 回退。官方 GSQ-RCO 的 ple_key 本就是 BF16，不受影响。| 坑 | 现象 | 结论 |
|---|---|---|
| 用 llama.cpp 跑 | 只有 10 tok/s | 换 Strata（主因是顺序执行） |
| 内存只插双通道 | CPU 满载在等内存 | 先插满四通道 |
| unsloth 预编译 fork | 同模型只有 3.55 tok/s | CPU 路径慢 3 倍，弃用 |
| 官方主线 WMMA 只支持 gfx12 | gfx1100 没有矩阵核 | 手动合并 gfx11 WMMA |
| hipBLASLt 表不全 | 大量回退、预填充腰斩 | 本机现场生成完整表 |
| 专家模式用 mmap+pageable | 预填充只有一半 | 改 pinned arena |
--prefill 2048 |
403 tok/s（对比 968） | 保持 auto（8K） |
--pool-workers 10（超线程） |
变慢 | 用默认（物理核−1） |
| ngram-mod 投机 | 自由生成无增益 | 保留无害，不必强求 |
| KVMem | 对本模型无意义 | KV 本就极小，Strata 已内置流式 |
fork hip-gfx1100 |
A/B 解码反而更慢 | 上游 + 自合并已足够 |
| huihui UD-Q4_K_XL | AMD 提示词内核 NVIDIA-only、无视觉 | 不选 |
| RVN IQ4_XS | 消融+量化双重损伤，编程弱且慢 | 已删；要无审查选 SC117 |
| 标签与实际档位不一致 | opencode 以为 236K、服务端只有 131K，请求被拒 | 启动器按档位同步窗口 |
| 下载来源不明的消融/微调版 | 编程弱、格式不兼容、门控 401、需专用 loader | 只认官方或社区验证版（见 4.3） |
| 用整模微调的无审查版当编程主力 | 编程能力明显下降 | 选"官方量化 + 消融张量移植"（SC117） |
三合一启动器：一个菜单切换三套配置（IQ3_S / IQ3_XXS / SC117），自动停旧服务、启动新服务、打开页面、同步 opencode 默认模型；带桌面快捷方式。
局域网网关：监听 0.0.0.0:8180，不校验 API key，单并发；第二个人访问立即收到 503 + 中文提示（含当前阶段与已运行秒数）+ Retry-After，而不是静默排队。本机 8080 直连不受限。
opencode 适配：每个模型独立声明窗口；启动器切档时只改对应模型的窗口，不会互相覆盖；全局自动压缩预留 64K，长会话自动总结，不撞服务端上限。
SSD 上的 PLE：分片设计把 51B n-gram 表单独放一个分片（28.8G），配合懒加载常驻 SSD，不占内存。
核心启动参数（Strata）
--pack <pack 目录> --native <shard1> --ple-gguf <含 PLE 的分片>
--expert-profile data/expert-profile.bin --expert-cache auto
--prefill auto --spec 4 --spec-min-p 0.5 --mtp <mtp/rt>
--max-context 262144 --kv int8 --kv-resident 32768
--mtp-window 65536 --adapt-every 0
--vision --vram-reserve-mib 1024
环境：STRATA_HIPBLASLT_TUNING=<本机 38 行表>
采样：temperature 0.6 / top_p 0.95 / top_k 20
用到的仓库/资源
Niko1221/Strata（0.1.34；gfx11 WMMA 来自 PR #260）ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF（IQ3_S / IQ3_XXS）SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUFQwen/Qwen3.8-Flash-Next（官方 mmproj BF16）致谢：hipBLASLt 调优表与 gfx11 WMMA 是社区贡献；坛内 Strata/AMD 主题帖给了大量参数参考。本文所有数据均为本机实测，不同硬件/驱动会有差异，仅供参考。
本文由本人整理，数据来自本机实际测试日志。欢迎交流指正。
这个方案不错！谢谢提供思路！
现在编辑不了了，如果需要的话看怎么发给坛主或版主给补充上，谢谢！
19-21的图好像是被限制了，论坛发贴好像是一次性传图太多会被限制！后面等限制解除后我再编辑补一下吧！不过已经基本不影响核心的内容！
摘要：在 Windows 环境下使用 X99 + 7900 XTX 跑本地大模型（如 Qwen 27B / Qwen3.8），很多朋友实测只有 10~12 tok/s，且首 Token 经常卡顿数分钟。大家普遍误以为是 AMD Windows 驱动不给力、Vulkan 优化差或是 E5 CPU 瓶颈。
但实际上，最底层的根因在于主板默认将显卡死死锁在了 256MB 的 Small BAR 窗口中，导致模型在运行时产生海量的缺页中断与通信阻塞。
本文记录如何在 Windows 下基于华南 X99 原厂 BIOS 自行注入 ReBarDxe 补丁，零成本安全开启 Resizable BAR，实测使 Qwen 27B 的 Token 生成速率从 12.69 tok/s 暴涨到 37.55 tok/s，Prompt 预填充从 200 tok/s 飙升至 820 tok/s，真实编程任务首 Token 延迟由 4 分钟骤降至 19 秒。
| 核心指标 | 开启 ReBAR 前 (256MB 锁死) | 开启 ReBAR 后 (当前实测) | 提升幅度 |
|---|---|---|---|
| Token 生成速率 (Decode) | 12.69 tok/s (78.8 ms/token) | 37.55 tok/s (26.6 ms/token) | +195.9%（翻了近 3 倍！） |
| Prompt 预填充速率 (pp512) | 200 ~ 300 tok/s | 820.21 tok/s | +200% ~ 300% |
| Prompt 预填充速率 (pp2048) | 150 ~ 220 tok/s | 803.78 tok/s | +260% |
【01_基准实测数据对比表.png】
在实际 Agent 复杂编程与多轮推理任务中，不仅是单纯的跑分提升，端到端体验更是天壤之别：
首 Token 响应极其艰难，平均等待时间长达 4分0秒，推理速度仅为 12 tok/s。
【
02_开启前DeepSeek实测首Token卡4分钟12tok.png】
首 Token 平均等待时间缩短为 19.7秒（提速超 12 倍），平均生成速率稳定达到 32 tok/s。
【03_开启后DeepSeek实测首Token降至19秒32tok.png】
在后续多轮迭代与缓存命中状态下，首 Token 进一步降至 4.4秒，整体 500K tokens 生成吞吐保持在 31 tok/s，任务圆满交付。
【04_DeepSeek真实编程任务交付完成.png】
RX 7900 XTX 占用率拉满 100%，专用显存占用 21GB/24GB，整体发热与功耗平稳。
【
05_任务管理器RX7900XTX满载21GB显存.png】
【06_CPU-Z主板与BIOS参数.png】
从 CPU-Z 查验本机参数：
ReBarDxe.ffs 补丁再刷回。耗时不到 3 分钟，成功率 100%，完全保留所有板载外设和温控配置！ReBarDxe.ffs 及 ReBarState.exe。以管理员身份打开 CMD，进入存放工具的目录，执行导出命令：
fptw64.exe -bios -d stock_2022.bin
看到绿色提示 FPT Operation Passed，即在当前目录下成功导出了 8MB 的完整原装底包 stock_2022.bin。
【
07_FPTW64导出备份原版BIOS.png】
双击打开 UEFITool 0.28.0，点击 File -> Open image file... 打开刚刚导出的 stock_2022.bin。
【
08_UEFITool打开原版BIOS.png】
展开左侧的目录树，找到体积最大的那个 Volume（Full size 约 510000h / 5.3MB 的 DXE 驱动卷）。
【
09_UEFITool定位最大DXE卷.png】
展开该卷，滑动至该卷的最底部一个 File 条目（例如 GUID 为 A0327FE0-1FDA-...），在其上点击右键，选择 Insert after...。
【
10_UEFITool右键Insert_after插入驱动.png】
在弹出的文件选择框中选择 ReBarDxe.ffs。此时列表中会在该项之后新增一条带 Insert 标记的 ReBarDxe。
【
11_UEFITool成功插入ReBarDxe驱动.png】
点击软件左上角 File -> Save image file...，将修改后的固件另存为 rebar_bios.bin。当弹出提示是否打开保存的文件时，选择“否”即可。
在管理员权限的 CMD 中，执行刷回命令：
fptw64.exe -bios -f rebar_bios.bin
写入和校验过程大约需要 15~30 秒，终端最终输出：
Verifying Flash ... 100% complete.
RESULT: The data is identical.
FPT Operation Passed
出现 FPT Operation Passed 即表示写入完全成功。
【
12_FPTW64刷回修改后BIOS.png】
刷写前状态回顾：未修改前，GPU-Z 中 Resizable BAR 为 Disabled。
【
13_刷写前GPU-Z显示Resizable_BAR未开启.png】
重启进入主板 BIOS 实操设置（关键步骤实拍）：
重启电脑连续按 Del 键进入 BIOS 设置界面；
切换到顶部的 Advanced 菜单，找到并回车进入 PCI Subsystem Settings：
【14_BIOS设置_Advanced进入PCISubsystem.jpg】
将其中的 Above 4G Decoding 设置为 [Enabled]（开启 4G 显存寻址）：
【15_BIOS设置_开启Above4GDecoding为Enabled.jpg】
按 ESC 返回 Advanced 菜单，找到并回车进入 CSM Configuration：
【16_BIOS设置_Advanced进入CSMConfiguration.jpg】
将 CSM Support 设置为 [Disabled]（必须彻底关闭兼容支持模块，强制纯 UEFI 引导）：
【17_BIOS设置_关闭CSMSupport为Disabled.jpg】
按键盘 F10 键，在弹出的 Save configuration and exit? 提示框中选择 [Yes]，保存配置并重启电脑。
【
18_BIOS设置_F10保存配置并退出重启.jpg】
进入系统激活无限显存映射：
ReBarState.exe；32（代表 2^32 MB，即 Unlimited BAR 无限制显存尺寸）并按回车；Successfully wrote ReBarState UEFI variable 即可关闭窗口。
【20_ReBarState输入32写入UEFI变量成功.png】
Enabled！
希望这篇实测与教程能帮到同样在 X99 平台上使用 7900 XTX / 7900 GRE 或类似 AMD 显卡玩大模型折腾的朋友！