一张表看懂本地大模型为什么跑不快：功耗墙放到 291W 也只吃 123W，瓶颈在显存与上下文

一、先说口径：一张 24 GB 卡跑 93.7 GB 的模型

没有口径的 tok/s 没有意义。下面所有数字都来自同一台机器、同一份权重、同一套启动参数，只改被测试的那一项。

• 机器：i7-14700F + Radeon RX 7900 XTX 24 GB（RDNA3，gfx1100）+ 125.6 GiB 内存，UOS 25 / Linux 6.6。
• 引擎与量化：Strata 0.1.48（HIP 后端，对应仓库 v0.2.3），Qwen3.8-Flash-Next 的 UD-IQ4_XS 权重 93.7 GB（十进制，约 87.2 GiB），原生 4-bit、三个分片。
• 默认参数：--max-context 262144、--kv k8v4、--kv-resident 32768、--vram-reserve-mib 1500、--resident-budget-gib 90、--pool-workers 7、--pcie-frac 0.35，MTP 草稿 4 个、最小接受概率 0.70。
• 测法：每档发一条 128–256 token 的生成请求（temperature 0），速度取引擎日志里自己报告的解码速率；功耗与频率每 0.2–0.3 秒从 amdgpu 的 hwmon 与 pp_dpm_* 采样。

先交代一个前提：93.7 GB 的权重装不进 24 GB 显存。引擎的做法是把一部分专家常驻显存、一部分常驻内存，剩下的按需通过 PCIe 逐层搬运——所以「显存一路吃满、命中率 90% 以上」是这个配置的正常状态，不是异常。

二、功耗墙实验：200 W 与 291 W 的输出差 0.5%

这台机器平时还有另一种吃 GPU 的负载，因此做了「省电档」和「性能档」两套配置。要回答的问题很直接：省电档留下的功耗墙，会不会把大模型的输出速度压住？同一张卡上 power1_cap 的驱动上限就是 power1_cap_max = 291 W，再往上需要打开 OverDrive 改内核参数，本次没有动。三档对照，每档测两次：

设定	第 1 次 tok/s	第 2 次 tok/s
291 W 功耗墙 + 性能档自动	63.1	65.5
200 W 功耗墙 + 性能档自动	62.4	66.2
291 W 功耗墙 + 性能档锁高频	66.3	65.1

三档的差距是 0.5%–5%，而同一配置重复测量本身就能差 8%（后文的对照组即是）。所以结论不是「200 W 略慢」，而是这三档在统计上分不出胜负：200 W 的墙根本没有被碰到。顺带一提，性能档锁高频也没有收益，反而让空闲功耗和温度白涨——日常保持自动档即可。

三、为什么只吃 123 W：满载的是「搬运」，不是「计算」

一次 49 秒的连续生成，每 0.3 秒采一次样，结果如下：

• 功耗：均值 123 W、峰值 177 W、谷值 98 W（上限 291 W）。
• 频率：核心 2,349–2,385 MHz，已经是这张卡的最高 DPM 档；显存 1,249 MHz 满档。
• 占用：gpu_busy 持续 100%，结温 72–73 °C、风扇 615 rpm。

四个读数放在一起就说明问题了：满频、满占用、却只吃四成电。AMD 的 gpu_busy 统计的是「有没有活」，不是「算术单元跑得有多满」。在这种「专家在内存、按需过 PCIe」的部署里，解码一个 token 要等的是显存带宽与 PCIe 带宽，GPU 大部分时间在等数据，动态功耗自然上不去。

对照组是预填充（也就是读提示、算子密集的那一段）：一条 34,820 token 的提示，功耗 90 分位 148 W、瞬时最高冲到 338 W——比标称的 291 W 还高一截，说明这张卡真要电的时候要得到。换句话说，「功耗低」是结果，不是限制。

四、参数扫描：九组配置里，默认那组就是最优

既然瓶颈在显存与数据搬运，那就把三个直接决定「谁进显存」的参数挨个改一遍：KV 驻留窗口（--kv-resident）、留给桌面与显示输出的显存（--vram-reserve-mib）、常驻内存预算（--resident-budget-gib）。每组都重启引擎重新加载，先发两条请求预热，再测 41k 与 131k 提示下的解码速度。

配置	41k 提示 tok/s	131k 提示 tok/s	专家命中 %
默认 · 第 1 次32,768 / 1,500 / 90	73.6	73.3	94.9
默认 · 重复测量	68.7	71.0	94.3
KV 窗口减半16,384 / 1,500 / 90	74.7	68.5	95.0
KV 窗口翻倍65,536 / 1,500 / 90	49.1	53.3	73.0
显存保留降到 1 GB32,768 / 1,000 / 90	59.6	70.4	90.4
显存保留提到 2.5 GB32,768 / 2,500 / 90	70.6	68.6	90.4
常驻预算提到 110 GiB32,768 / 1,500 / 110	66.4	68.6	89.5

读这张表只要抓住两个对照：

• KV 窗口翻倍是唯一明确的倒退：命中率从 94% 掉到 73%，两条上下文长度各掉 25%–30%。原因很直接——KV 缓存多占的显存是从专家槽里抠出来的，专家进不来就要走 PCIe，多出来的那点 KV 省下的搬运还不够赔进去的。
• 其余四组都在噪声内或有明确代价：KV 减半在 41k 略高、131k 低 6.5%；显存保留降到 1 GB 在 41k 掉 20%（59.6 对 73.6），是把余量压太紧、页缓存和分配抖动的代价；常驻预算 110 GiB 没有任何收益。

所以这张卡上的默认三件套 32,768 / 1,500 / 90 不是「先这么放」，而是实测最优。参数优化不是免费的按钮，在这类「显存装不下模型」的部署里，任何一个参数多吃一口显存，都会从专家槽里扣回来。

五、两套速度：预填充和解码要分开看

热态下的完整曲线（默认配置，两次测量的区间）：

提示长度	预填充 tok/s	解码 tok/s
约 8,400 token	1,075	72.9–79.2
约 41,700 token	1,225	68.7–73.6
约 133,300 token	1,506	71.0–73.3

两点值得注意。一是长上下文没有出现想象中的「断崖」：从 8k 到 131k，解码只差 5% 左右，预填充反而随长度略升（分块与并行吃得更满）。二是预填充慢一个数量级、解码快但也不等于交互速度——读一条 13 万 token 的材料要 88 秒，之后每写一个字 70 tok/s，这是两个必须分开报的数。

六、三个会让测量结果翻倍的陷阱

这一节是本篇最该被同行拿去用的部分：同一套配置，测量方式不同可以差出 20 倍。

• 冷启动：引擎刚起、专家缓存是空的，8k 提示的第一条请求只有 58.2 tok/s（命中 76.6%）；发两条请求把它捂热之后，同一条请求是 72.9 tok/s（命中 93.6%）——差 25%。刚启动就测速，得到的不是这个配置的成绩，是加载进度。
• 前缀缓存：同一个提示发第二次，引擎直接命中缓存，预填充从 7.8 秒变成 0.2 秒（等效 37,827 tok/s）。拿这种数字当预填充性能，能报出一个大十倍的假成绩；测预填充必须每次用没发过的提示。
• 并发污染（最贵的一个坑）：同一台机器上并行跑一个 4 倍放大的视频超分任务时，34.8k 提示的解码掉到 3.6 tok/s；把 GPU 让出来之后，41.7k 提示是 83.9 tok/s——23 倍差距。当时差点据此得出「32k 之后有 KV 断崖」的错误结论。归因方法很土但有效：读 /proc/<pid>/fdinfo 里的 drm-engine-* 计数，就能看出是哪个进程在占 GPU 引擎。

七、给同类机器的六条建议

• 先别怀疑功耗墙：对比 power1_cap 与 power1_cap_max，两个值相等就是「已经放到最大」，再纠结也不会有收益。
• 满频 + 低功耗 = 在等数据：看到「占用 100%、频率满载、功耗只有四成」，正确结论是负载是带宽型，不是被限速。
• 先做重复测量的基线：同一配置两次能差 8%，任何小于这个幅度的「优化」都还在噪声里。
• 新起引擎先预热两条，再交给 agent 或再测速。
• 测预填充换新提示，测解码可以用同一提示（但要知道它在吃缓存）。
• 测速前确认卡是干净的：视频处理、渲染、另一个推理进程都会让成绩失去意义。

数据来源：本站实测，2026-10-27，Radeon RX 7900 XTX 24 GB + i7-14700F + 125.6 GiB 内存，UOS 25 / Linux 6.6，Strata 0.1.48（HIP，gfx1100；开源仓库 v0.2.3），Qwen3.8-Flash-Next UD-IQ4_XS 93.7 GB，上下文 262,144，--kv k8v4。功耗、频率、温度取自 amdgpu 驱动 hwmon 的 power1_average 与 pp_dpm_sclk/mclk，0.2–0.3 秒采样；速度取引擎日志自报的解码速率。所有参数扫描均重启引擎重新加载、预热后测量，原始记录与复测脚本留存可复跑。本文仅转述公开信息与自测数据，不评判任何企业与产品，不构成投资建议。

返回行业动态列表（共 127 条）→