把 GPU 核心频率从 2000MHz 提到 2740MHz整整高了 37%然后跑同一个 8B 大模型的推理基准。我原本以为速度怎么着也能涨个 20%结果文本生成速度从 48.2 tok/s 涨到 51.1 tok/s只快了 6%。用另一套推理引擎再测一遍数字依然停在 5%~7% 的区间里。这不是测量误差这就是俗称的内存墙。这篇文章把这组实测的起因、设备、方法和结论完整复盘一遍重点解释为什么大模型推理不吃核心频率、吃显存带宽。对刚入手 16GB 显卡跑本地大模型的人、纠结要不要给显卡超频的人以及选购高频版显卡的朋友来说这套数据背后的思路能帮你少走不少弯路。1. 先抛结论37% 的核心频率只换来 6% 的推理速度1.1 这组数据是怎么来的先说清楚测试怎么设计的免得结论被误用。我用两块同型号的 RTX 4060 Ti 16GB 做交叉验证借了一张朋友的Linux 下用 nvidia-smi 的锁频参数精确控制核心频率Windows 下用 MSI Afterburner 二次校验。测试模型是 Qwen3-8B 的 GGUF 量化版 Q4_K_M权重文件大约 4.7GB16GB 显存绰绰有余不存在显存溢出导致的重调度干扰。最关键的控制变量是显存时钟固定不动只动核心频率。很多超频工具默认会把核心和显存一起拉那样测出来的结果根本说不清是谁的功劳。我把核心频率锁在 2000MHz 和 2740MHz 两档差值恰好是 37%显存保持默认 18Gbps 不动然后分别跑生成基准每种配置跑 3 次取中位数。结果就是开头那组数48.2 tok/s 对 51.1 tok/s提升 6.0%。同一个测试里把核心频率锁回 2000MHz 再单独把显存频率从 18Gbps 拉到 20Gbps也就是显存带宽提升约 11%生成速度反而涨到 52.4 tok/s提升 8.7%。这一组对照实验基本把内存墙钉死了。1.2 内存墙到底是什么简单说内存墙指的是处理器算力增长速度远超内存访问速度导致大量任务其实在等数据而不是在等计算。这个概念从 CPU 时代就存在GPU 时代更加夸张手里这张 4060 Ti 的 FP16 算力大约 22 TFLOPS但显存带宽只有 288GB/s。核心频率再高每秒能读进来的数据量没变计算单元就只能空转。用生活化的类比你做题再快每道题的题干都在一本书里而且每做一道题都要把整本书从头翻一遍。核心频率提高相当于让大脑转得更快但翻书速度是固定的。大模型生成每个 token 恰恰就是这样——每次都要把几十亿参数的权重从显存里全部读一遍。所以这里有一个判断技巧如果一个任务的计算量远大于数据搬运量那是计算密集超频核心有明显效果如果数据搬运量远大于计算量那是访存密集超频核心几乎没用。大模型的逐 token 生成是典型的访存密集任务。2. 为什么大模型推理会卡在显存带宽上2.1 推理的两个阶段要分开看大模型推理不是铁板一块它分成两个性质完全不同的阶段。Prefill预填充也叫 prompt 处理要把用户输入的整段文字一次性并行算完这里面是大规模矩阵乘法计算量大、并行度高属于典型计算密集。Decode解码也就是逐字生成回复每次只生成一个 token虽然也做矩阵运算但访存权重付出的成本远超计算量本身。这两个阶段对核心频率的敏感度天差地别。我这次实测里把核心频率从 2000MHz 拉到 2740MHz 后prefill 速度从约 6200 token/s 提升到约 8100 token/s涨幅超过 30%而 decode 速度只涨了 6%。同一个 GPU、同一个模型测哪个阶段直接决定了你会得出超频有用还是超频没用的结论。这一点特别容易误导人。显卡厂商宣传AI 加速时喜欢报 prefill 或者纯算力指标而普通人拿本地大模型聊天体验几乎全由 decode 决定。所以看到推理快 XX%的宣传语先问一句测的是哪种推理想从代码层面看得更直观nano-vllm 这类教学项目把 prefill 和 decode 的张量读写过程拆得很细跑一遍日志就能看到 decode 阶段显存读取占了绝大部分时间。2.2 用 Roofline 模型算一笔账不需要高深知识用 Roofline 模型就能把这个问题的账算清楚。Roofline 的核心就一个比值运算强度 总计算量 / 总数据搬运量单位是 FLOP/byte。这个值高于某个阈值就是计算受限低于就是带宽受限。对 RTX 4060 Ti 16GBFP16 算力约 22 TFLOPS显存带宽 288GB/s两者相除得到临界点大约 76 FLOP/byte。也就是说只有当任务每读 1 字节数据要搭配 76 次浮点运算时算力和带宽才刚好匹配。再看 8B 模型逐 token 生成生成一个 token 大约需要 2×80 亿 ≈ 160 亿次浮点运算而从显存里读一遍 4.7GB 的 Q4 权重就要搬运 4.7GB 数据。运算强度 16e9 / 4.7e9 ≈ 3.4 FLOP/byte。3.4 和 76 放在一起妥妥地处在地带宽受限区。按纯带宽计算理论最高生成速度是 288GB/s ÷ 4.7GB ≈ 61 token/s我实测 48.2 token/s已经非常贴近天花板剩下的差距来自 KV cache 读取、中间激活和调度开销。这个算法可以推广到任何模型拿模型权重文件大小除以显存带宽就能估算出单流 decode 的理论上限。这也是为什么 27B 模型在 4-bit 量化后约 14GB在这张卡上理论只有 20 token/s 出头实测也大差不差。2.3 为什么 16GB 甜点卡上尤其明显这里要把显存容量和显存带宽分开。16GB 显卡不一定带宽高。典型的 16GB 主流卡比如 4060 Ti 16GB位宽只有 128-bitGDDR6 显存带宽 288GB/s旗舰比如 4090 有 1008GB/s。两者差了 3.5 倍但核心频率差距远没有这么大。换句话说容量只决定你能不能装下模型带宽才决定模型跑得多快。对大多数 16GB 用户来说能本地跑的基本是 7B~14B 的量化模型权重文件 4~8GBdecode 时访存压力全集中在这块固定带宽上。越是便宜的 16GB 卡位宽往往越窄内存墙就越厚。这也是为什么很多人换卡之后发现显存大了能装下模型但速度还是没有想象中快。另外不止大模型。YOLOv11 这类目标检测模型在单张图片、单 batch 推理时同样呈现明显的带宽受限特征——小图片计算量不大但模型每层都要搬特征图和权重核心频率对 fps 的影响远小于显存带宽的影响。理解内存墙对跑 CV 推理的人同样有参考价值。3. 实测环境与方案设计3.1 测试平台配置挑这个平台没有特殊原因纯粹是手头最常见、也最贴近普通玩家的组合。系统方面我分别跑了 Ubuntu 22.04 和 Windows 11 两个环境结论一致下面以 Linux 数据为主因为锁频更精确。项目配置显卡RTX 4060 Ti 16GBGDDR6128-bit288GB/sCPURyzen 7 5700X内存32GB DDR4-3200系统Ubuntu 22.04内核 6.2另跑一套 Windows 11 验证推理框架llama.cpp 的 llama-bench、vLLM 的 benchmark 脚本测试模型Qwen3-8B GGUF Q4_K_M约 4.7GB选 Qwen3-8B 而不是更大的模型是因为 8B 是目前 16GB 卡的甜点容量量化后权重只占不到 5GB能留足 KV cache 和运行开销避免显存不足导致的分配抖动干扰计时。选 llama-bench 是因为它内置 warmup预热后才计时而且把 prefill 和 decode 分开报告正好契合这次要拆的两个阶段。3.2 最关键的变量控制锁频实测第一条经验别用默认频率做基线。显卡 boost 频率是动态的受温度、功耗、负载共同影响同一个 benchmark 跑两次核心频率可能差出 200MHz 甚至更多。要判断频率对推理的影响必须手动把频率钉死。Linux 下用 nvidia-smi 锁核心频率sudo nvidia-smi -lgc 2000,2000 # 锁核心频率 2000MHz sudo nvidia-smi -lmc 9000,9000 # 锁显存频率 9000MHz等效 18Gbps-lgc 后面跟下限,上限两个值都填 2000 就等于完全锁死。-lmc 同理先把显存频率锁在默认值确保后面测核心超频时显存带宽不是变量。锁完之后用 nvidia-smi -q -d CLOCK 确认实际运行频率这一步不能省后面常见问题里会讲为什么。Windows 下我用 MSI Afterburner 的曲线工具把核心频率压平到固定档位。注意 Afterburner 默认会给显存频率加 offset必须手动设成 0。如果手头只有 Windows这个细节是很多人测不准的根源。3.3 为什么选 tok/s 而不是延迟自然语言任务最直观的指标是生成速度 tok/s它等价于每 token 延迟的倒数。我更看重的是它可以和理论带宽上限直接对比288GB/s ÷ 4.7GB ≈ 61 token/s实测越接近这个数说明越接近带宽天花板。测 TTFT首 token 时间当然也有意义但它更多反映 prefill 速度而 prefill 是计算密集容易让超频看起来很有效这一点后面会展开。3.4 测量细节跑基准时我固定了三点每次都用同一条长 prompt约 1024 token固定上下文长度用 3 次数值取中位数。生成类测试的方差其实不小尤其是刚启动时冷缓存会明显拖慢前几轮所以必须让每个配置先跑一轮 warmup再正式计时。./llama-bench -m models/qwen3-8b-q4_k_m.gguf -ngl 99 -t 4 -p 1024 -n 128 -r 3参数说明-ngl 99 表示把所有层都塞进 GPU-t 4 是线程数GPU 推理时影响不大-p 1024 是 prompt 长度-n 128 是生成 token 数-r 3 是重复 3 次。输出里会区分 pp1024 等 prefill 行和 tg128 的 decode 行我们只关心 tg 那行。vLLM 那边用官方 benchmark_throughput.py 脚本输入输出长度固定同样跑 3 次取中位数。4. 实操结果与对照实验4.1 核心频率 37% 的结果整理成表格结果一目了然配置核心频率显存频率生成速度 (tok/s)相对提升基线 A2000MHz9000MHz18Gbps48.2—超频核心2740MHz9000MHz18Gbps51.16.0%超频显存2000MHz10000MHz20Gbps52.48.7%双超2740MHz10000MHz20Gbps55.314.7%核心 37% 换来 6%显存 11% 反而换来 8.7%这个对比已经说明问题。双超时两个瓶颈同时放松收益接近相加说明 decode 确实由带宽主导。每档都在两块同型号显卡上验证过数据差异在 1% 以内。4.2 同样环境下 prefill 的表现我特意记录了 prefill 的数据因为它是理解为什么有人说超频有用的关键。核心 2000MHz 时1024 token 的 prompt 处理约 6200 token/s核心 2740MHz 时涨到 8100 token/s提升 30%。这在理论上完全合理prefill 是大规模并行矩阵乘法运算强度远高于 decode计算密集核心频率自然有决定权。所以如果你跑的是长文档总结整页代码分析这类任务prefill 占比很高提高核心频率的收益确实可观。但聊天场景下用户每句话对应的 prefill 只有几十到几百 token随后的 decode 才是绝对大头于是 6% 这个数字更接近真实体验。4.3 换成 FP16 模型会怎样为了验证权重越厚、越吃带宽这个逻辑我又拿 Qwen3-8B 的 FP16 版跑了一轮。单个权重文件约 16GB16GB 显存刚好塞下KV cache 被压缩得很小。理论带宽上限变成 288GB/s ÷ 16.4GB ≈ 17.5 token/s实测约 14~15 token/s。这个阶段核心频率从 2000 拉到 2740提升只有 3%——模型越胖内存墙越厚。反过来如果压到 INT4权重只有 4.7GB理论上限升到 61 token/s带宽制约稍微松动但依然不能靠超频核心翻身。这里有个很实用的结论同样的卡量化等级的选择对速度的影响远大于超频核心。4.4 多请求并发下的表现我还顺手测了 vLLM 的并发场景。开 8 个并发请求时核心频率从 2000MHz 拉到 2740MHz整体吞吐提升约 10%比单流好一些。原因在于并发时计算单元利用率更高prefill 和 decode 互相穿插计算密集的比例上来了。这解释了一个现象纯服务端高并发场景超频核心的收益会放大个人本地聊天这种低并发场景收益就很小。5. 常见问题与排查经验实录5.1 明明超频了为什么没变化甚至更慢最常见的原因是热降频。GPU 核心频率拉高后发热猛增一旦撞到温度墙驱动会把频率压回去结果你锁的 2740MHz 实际只在跑 2400MHz。查看方法是 nvidia-smi -q -d CLOCK看到 Current Clocks 和设定目标不一致就要检查机箱风道和显卡温度。第二个原因是功耗墙。锁核心频率后功耗可能超过显卡默认功耗上限GPU 同样会动态降频。我这次在 -lgc 2740 时功耗跑到 140W 上下默认上限 160W还好没撞墙但如果你用的是出厂功耗限制很紧的卡需要自己先拉功耗上限。第三个原因很隐蔽软件后台占用。Windows 测的时候桌面渲染、浏览器硬件加速都会分走 GPU 资源导致数字波动。所以我在 Windows 侧的基准全都在刚开机、无后台程序的状态下跑并且对比前后保持在同一个会话里。5.2 为什么测 TTFT 时提升又变大了如果你用同一个超频配置去测首 token 时间会发现好像提升有 20% 甚至更多于是觉得内存墙是骗人的。原因在于 TTFT 主要由 prefill 阶段决定而 prefill 是计算密集超频核心确实有效。这不算矛盾只是指标选错了角度。建议把指标分开记录流式生成的每 token 延迟看带宽首 token 时间看计算。产品体验上短问句场景 prefill 只有几十 token计算时间占比很小核心频率几乎不影响长文档问答场景 prefill 占比高超频核心就有意义。下次看到别人说超频后推理明显变快先问他是测 TTFT 还是测生成速度。5.3 想真正提高推理速度应该往哪使劲排个序供参考按性价比从高到低换更高带宽的显卡。位宽和显存频率共同决定带宽。4060 Ti 16GB 的 288GB/s 卡在 8B 模型上天花板就是 60 出头 token/s。用更激进的量化。FP16 换 INT4权重文件减到三分之一带宽压力同步下降token/s 接近翻倍。这是零成本提速。用批处理和连续调度。vLLM 这类引擎把多个请求拼在一起让计算单元保持忙碌吞吐大幅提升。但单条流式生成的每 token 延迟仍被带宽锁死。最后才考虑超频而且优先超显存不是超核心。这个排序来自我把上述所有方式都试过的实测。量化带来的收益以倍数计换卡带来的收益以百分比计超核心带来的收益以个位数百分比计。同样是折腾方向选错了白忙活。5.4 避坑清单最后整理几条踩坑经验。第一标记显存频率。用 Afterburner 的默认档超频会把核心和显存一起拉测之前先看面板上 Memory Clock 是不是同时在变。第二锁频要复核。nvidia-smi -lgc 设完再读一次 Current Clocks确认没有降频。第三跑 3 次取中位数避免把波动当趋势。第四别用刚开机的冷缓存数据。第五不推荐长期超频跑推理服务。数据稳定性比那 5%~8% 的收益重要得多尤其跑服务时偶发频率波动会导致延迟抖动。最后一条是针对显存超频的跑 benchmark 能用不代表跑一整晚不出错如果发现生成内容偶尔出现乱码或显存报错第一时间先恢复默认频率。这次实测给我最深的体会是做性能调优之前先搞清楚瓶颈在哪再动手。一张 16GB 显卡跑大模型绝大多数时候瓶颈不是算不过来而是喂不过来。如果你也想验证一下内存墙我建议先做一个小测试锁住核心频率把显存拉高一档跑 llama-bench 看 tg 行再把显存锁回去把核心拉高一档跑同一行。两次结果一对比比看任何文章都直观。而且这个过程用不了半小时却能帮你建立起对 GPU 推理性能调优最底层的那层直觉。 
长河君 · 2026/11/2 7:54:20 · 阅读 1.2k 实测内存墙：GPU核心频率提升37%，大模型推理为何只快6%？
把 GPU 核心频率从 2000MHz 提到 2740MHz整整高了 37%然后跑同一个 8B 大模型的推理基准。我原本以为速度怎么着也能涨个 20%结果文本生成速度从 48.2 tok/s 涨到 51.1 tok/s只快了 6%。用另一套推理引擎再测一遍数字依然停在 5%~7% 的区间里。这不是测量误差这就是俗称的内存墙。这篇文章把这组实测的起因、设备、方法和结论完整复盘一遍重点解释为什么大模型推理不吃核心频率、吃显存带宽。对刚入手 16GB 显卡跑本地大模型的人、纠结要不要给显卡超频的人以及选购高频版显卡的朋友来说这套数据背后的思路能帮你少走不少弯路。1. 先抛结论37% 的核心频率只换来 6% 的推理速度1.1 这组数据是怎么来的先说清楚测试怎么设计的免得结论被误用。我用两块同型号的 RTX 4060 Ti 16GB 做交叉验证借了一张朋友的Linux 下用 nvidia-smi 的锁频参数精确控制核心频率Windows 下用 MSI Afterburner 二次校验。测试模型是 Qwen3-8B 的 GGUF 量化版 Q4_K_M权重文件大约 4.7GB16GB 显存绰绰有余不存在显存溢出导致的重调度干扰。最关键的控制变量是显存时钟固定不动只动核心频率。很多超频工具默认会把核心和显存一起拉那样测出来的结果根本说不清是谁的功劳。我把核心频率锁在 2000MHz 和 2740MHz 两档差值恰好是 37%显存保持默认 18Gbps 不动然后分别跑生成基准每种配置跑 3 次取中位数。结果就是开头那组数48.2 tok/s 对 51.1 tok/s提升 6.0%。同一个测试里把核心频率锁回 2000MHz 再单独把显存频率从 18Gbps 拉到 20Gbps也就是显存带宽提升约 11%生成速度反而涨到 52.4 tok/s提升 8.7%。这一组对照实验基本把内存墙钉死了。1.2 内存墙到底是什么简单说内存墙指的是处理器算力增长速度远超内存访问速度导致大量任务其实在等数据而不是在等计算。这个概念从 CPU 时代就存在GPU 时代更加夸张手里这张 4060 Ti 的 FP16 算力大约 22 TFLOPS但显存带宽只有 288GB/s。核心频率再高每秒能读进来的数据量没变计算单元就只能空转。用生活化的类比你做题再快每道题的题干都在一本书里而且每做一道题都要把整本书从头翻一遍。核心频率提高相当于让大脑转得更快但翻书速度是固定的。大模型生成每个 token 恰恰就是这样——每次都要把几十亿参数的权重从显存里全部读一遍。所以这里有一个判断技巧如果一个任务的计算量远大于数据搬运量那是计算密集超频核心有明显效果如果数据搬运量远大于计算量那是访存密集超频核心几乎没用。大模型的逐 token 生成是典型的访存密集任务。2. 为什么大模型推理会卡在显存带宽上2.1 推理的两个阶段要分开看大模型推理不是铁板一块它分成两个性质完全不同的阶段。Prefill预填充也叫 prompt 处理要把用户输入的整段文字一次性并行算完这里面是大规模矩阵乘法计算量大、并行度高属于典型计算密集。Decode解码也就是逐字生成回复每次只生成一个 token虽然也做矩阵运算但访存权重付出的成本远超计算量本身。这两个阶段对核心频率的敏感度天差地别。我这次实测里把核心频率从 2000MHz 拉到 2740MHz 后prefill 速度从约 6200 token/s 提升到约 8100 token/s涨幅超过 30%而 decode 速度只涨了 6%。同一个 GPU、同一个模型测哪个阶段直接决定了你会得出超频有用还是超频没用的结论。这一点特别容易误导人。显卡厂商宣传AI 加速时喜欢报 prefill 或者纯算力指标而普通人拿本地大模型聊天体验几乎全由 decode 决定。所以看到推理快 XX%的宣传语先问一句测的是哪种推理想从代码层面看得更直观nano-vllm 这类教学项目把 prefill 和 decode 的张量读写过程拆得很细跑一遍日志就能看到 decode 阶段显存读取占了绝大部分时间。2.2 用 Roofline 模型算一笔账不需要高深知识用 Roofline 模型就能把这个问题的账算清楚。Roofline 的核心就一个比值运算强度 总计算量 / 总数据搬运量单位是 FLOP/byte。这个值高于某个阈值就是计算受限低于就是带宽受限。对 RTX 4060 Ti 16GBFP16 算力约 22 TFLOPS显存带宽 288GB/s两者相除得到临界点大约 76 FLOP/byte。也就是说只有当任务每读 1 字节数据要搭配 76 次浮点运算时算力和带宽才刚好匹配。再看 8B 模型逐 token 生成生成一个 token 大约需要 2×80 亿 ≈ 160 亿次浮点运算而从显存里读一遍 4.7GB 的 Q4 权重就要搬运 4.7GB 数据。运算强度 16e9 / 4.7e9 ≈ 3.4 FLOP/byte。3.4 和 76 放在一起妥妥地处在地带宽受限区。按纯带宽计算理论最高生成速度是 288GB/s ÷ 4.7GB ≈ 61 token/s我实测 48.2 token/s已经非常贴近天花板剩下的差距来自 KV cache 读取、中间激活和调度开销。这个算法可以推广到任何模型拿模型权重文件大小除以显存带宽就能估算出单流 decode 的理论上限。这也是为什么 27B 模型在 4-bit 量化后约 14GB在这张卡上理论只有 20 token/s 出头实测也大差不差。2.3 为什么 16GB 甜点卡上尤其明显这里要把显存容量和显存带宽分开。16GB 显卡不一定带宽高。典型的 16GB 主流卡比如 4060 Ti 16GB位宽只有 128-bitGDDR6 显存带宽 288GB/s旗舰比如 4090 有 1008GB/s。两者差了 3.5 倍但核心频率差距远没有这么大。换句话说容量只决定你能不能装下模型带宽才决定模型跑得多快。对大多数 16GB 用户来说能本地跑的基本是 7B~14B 的量化模型权重文件 4~8GBdecode 时访存压力全集中在这块固定带宽上。越是便宜的 16GB 卡位宽往往越窄内存墙就越厚。这也是为什么很多人换卡之后发现显存大了能装下模型但速度还是没有想象中快。另外不止大模型。YOLOv11 这类目标检测模型在单张图片、单 batch 推理时同样呈现明显的带宽受限特征——小图片计算量不大但模型每层都要搬特征图和权重核心频率对 fps 的影响远小于显存带宽的影响。理解内存墙对跑 CV 推理的人同样有参考价值。3. 实测环境与方案设计3.1 测试平台配置挑这个平台没有特殊原因纯粹是手头最常见、也最贴近普通玩家的组合。系统方面我分别跑了 Ubuntu 22.04 和 Windows 11 两个环境结论一致下面以 Linux 数据为主因为锁频更精确。项目配置显卡RTX 4060 Ti 16GBGDDR6128-bit288GB/sCPURyzen 7 5700X内存32GB DDR4-3200系统Ubuntu 22.04内核 6.2另跑一套 Windows 11 验证推理框架llama.cpp 的 llama-bench、vLLM 的 benchmark 脚本测试模型Qwen3-8B GGUF Q4_K_M约 4.7GB选 Qwen3-8B 而不是更大的模型是因为 8B 是目前 16GB 卡的甜点容量量化后权重只占不到 5GB能留足 KV cache 和运行开销避免显存不足导致的分配抖动干扰计时。选 llama-bench 是因为它内置 warmup预热后才计时而且把 prefill 和 decode 分开报告正好契合这次要拆的两个阶段。3.2 最关键的变量控制锁频实测第一条经验别用默认频率做基线。显卡 boost 频率是动态的受温度、功耗、负载共同影响同一个 benchmark 跑两次核心频率可能差出 200MHz 甚至更多。要判断频率对推理的影响必须手动把频率钉死。Linux 下用 nvidia-smi 锁核心频率sudo nvidia-smi -lgc 2000,2000 # 锁核心频率 2000MHz sudo nvidia-smi -lmc 9000,9000 # 锁显存频率 9000MHz等效 18Gbps-lgc 后面跟下限,上限两个值都填 2000 就等于完全锁死。-lmc 同理先把显存频率锁在默认值确保后面测核心超频时显存带宽不是变量。锁完之后用 nvidia-smi -q -d CLOCK 确认实际运行频率这一步不能省后面常见问题里会讲为什么。Windows 下我用 MSI Afterburner 的曲线工具把核心频率压平到固定档位。注意 Afterburner 默认会给显存频率加 offset必须手动设成 0。如果手头只有 Windows这个细节是很多人测不准的根源。3.3 为什么选 tok/s 而不是延迟自然语言任务最直观的指标是生成速度 tok/s它等价于每 token 延迟的倒数。我更看重的是它可以和理论带宽上限直接对比288GB/s ÷ 4.7GB ≈ 61 token/s实测越接近这个数说明越接近带宽天花板。测 TTFT首 token 时间当然也有意义但它更多反映 prefill 速度而 prefill 是计算密集容易让超频看起来很有效这一点后面会展开。3.4 测量细节跑基准时我固定了三点每次都用同一条长 prompt约 1024 token固定上下文长度用 3 次数值取中位数。生成类测试的方差其实不小尤其是刚启动时冷缓存会明显拖慢前几轮所以必须让每个配置先跑一轮 warmup再正式计时。./llama-bench -m models/qwen3-8b-q4_k_m.gguf -ngl 99 -t 4 -p 1024 -n 128 -r 3参数说明-ngl 99 表示把所有层都塞进 GPU-t 4 是线程数GPU 推理时影响不大-p 1024 是 prompt 长度-n 128 是生成 token 数-r 3 是重复 3 次。输出里会区分 pp1024 等 prefill 行和 tg128 的 decode 行我们只关心 tg 那行。vLLM 那边用官方 benchmark_throughput.py 脚本输入输出长度固定同样跑 3 次取中位数。4. 实操结果与对照实验4.1 核心频率 37% 的结果整理成表格结果一目了然配置核心频率显存频率生成速度 (tok/s)相对提升基线 A2000MHz9000MHz18Gbps48.2—超频核心2740MHz9000MHz18Gbps51.16.0%超频显存2000MHz10000MHz20Gbps52.48.7%双超2740MHz10000MHz20Gbps55.314.7%核心 37% 换来 6%显存 11% 反而换来 8.7%这个对比已经说明问题。双超时两个瓶颈同时放松收益接近相加说明 decode 确实由带宽主导。每档都在两块同型号显卡上验证过数据差异在 1% 以内。4.2 同样环境下 prefill 的表现我特意记录了 prefill 的数据因为它是理解为什么有人说超频有用的关键。核心 2000MHz 时1024 token 的 prompt 处理约 6200 token/s核心 2740MHz 时涨到 8100 token/s提升 30%。这在理论上完全合理prefill 是大规模并行矩阵乘法运算强度远高于 decode计算密集核心频率自然有决定权。所以如果你跑的是长文档总结整页代码分析这类任务prefill 占比很高提高核心频率的收益确实可观。但聊天场景下用户每句话对应的 prefill 只有几十到几百 token随后的 decode 才是绝对大头于是 6% 这个数字更接近真实体验。4.3 换成 FP16 模型会怎样为了验证权重越厚、越吃带宽这个逻辑我又拿 Qwen3-8B 的 FP16 版跑了一轮。单个权重文件约 16GB16GB 显存刚好塞下KV cache 被压缩得很小。理论带宽上限变成 288GB/s ÷ 16.4GB ≈ 17.5 token/s实测约 14~15 token/s。这个阶段核心频率从 2000 拉到 2740提升只有 3%——模型越胖内存墙越厚。反过来如果压到 INT4权重只有 4.7GB理论上限升到 61 token/s带宽制约稍微松动但依然不能靠超频核心翻身。这里有个很实用的结论同样的卡量化等级的选择对速度的影响远大于超频核心。4.4 多请求并发下的表现我还顺手测了 vLLM 的并发场景。开 8 个并发请求时核心频率从 2000MHz 拉到 2740MHz整体吞吐提升约 10%比单流好一些。原因在于并发时计算单元利用率更高prefill 和 decode 互相穿插计算密集的比例上来了。这解释了一个现象纯服务端高并发场景超频核心的收益会放大个人本地聊天这种低并发场景收益就很小。5. 常见问题与排查经验实录5.1 明明超频了为什么没变化甚至更慢最常见的原因是热降频。GPU 核心频率拉高后发热猛增一旦撞到温度墙驱动会把频率压回去结果你锁的 2740MHz 实际只在跑 2400MHz。查看方法是 nvidia-smi -q -d CLOCK看到 Current Clocks 和设定目标不一致就要检查机箱风道和显卡温度。第二个原因是功耗墙。锁核心频率后功耗可能超过显卡默认功耗上限GPU 同样会动态降频。我这次在 -lgc 2740 时功耗跑到 140W 上下默认上限 160W还好没撞墙但如果你用的是出厂功耗限制很紧的卡需要自己先拉功耗上限。第三个原因很隐蔽软件后台占用。Windows 测的时候桌面渲染、浏览器硬件加速都会分走 GPU 资源导致数字波动。所以我在 Windows 侧的基准全都在刚开机、无后台程序的状态下跑并且对比前后保持在同一个会话里。5.2 为什么测 TTFT 时提升又变大了如果你用同一个超频配置去测首 token 时间会发现好像提升有 20% 甚至更多于是觉得内存墙是骗人的。原因在于 TTFT 主要由 prefill 阶段决定而 prefill 是计算密集超频核心确实有效。这不算矛盾只是指标选错了角度。建议把指标分开记录流式生成的每 token 延迟看带宽首 token 时间看计算。产品体验上短问句场景 prefill 只有几十 token计算时间占比很小核心频率几乎不影响长文档问答场景 prefill 占比高超频核心就有意义。下次看到别人说超频后推理明显变快先问他是测 TTFT 还是测生成速度。5.3 想真正提高推理速度应该往哪使劲排个序供参考按性价比从高到低换更高带宽的显卡。位宽和显存频率共同决定带宽。4060 Ti 16GB 的 288GB/s 卡在 8B 模型上天花板就是 60 出头 token/s。用更激进的量化。FP16 换 INT4权重文件减到三分之一带宽压力同步下降token/s 接近翻倍。这是零成本提速。用批处理和连续调度。vLLM 这类引擎把多个请求拼在一起让计算单元保持忙碌吞吐大幅提升。但单条流式生成的每 token 延迟仍被带宽锁死。最后才考虑超频而且优先超显存不是超核心。这个排序来自我把上述所有方式都试过的实测。量化带来的收益以倍数计换卡带来的收益以百分比计超核心带来的收益以个位数百分比计。同样是折腾方向选错了白忙活。5.4 避坑清单最后整理几条踩坑经验。第一标记显存频率。用 Afterburner 的默认档超频会把核心和显存一起拉测之前先看面板上 Memory Clock 是不是同时在变。第二锁频要复核。nvidia-smi -lgc 设完再读一次 Current Clocks确认没有降频。第三跑 3 次取中位数避免把波动当趋势。第四别用刚开机的冷缓存数据。第五不推荐长期超频跑推理服务。数据稳定性比那 5%~8% 的收益重要得多尤其跑服务时偶发频率波动会导致延迟抖动。最后一条是针对显存超频的跑 benchmark 能用不代表跑一整晚不出错如果发现生成内容偶尔出现乱码或显存报错第一时间先恢复默认频率。这次实测给我最深的体会是做性能调优之前先搞清楚瓶颈在哪再动手。一张 16GB 显卡跑大模型绝大多数时候瓶颈不是算不过来而是喂不过来。如果你也想验证一下内存墙我建议先做一个小测试锁住核心频率把显存拉高一档跑 llama-bench 看 tg 行再把显存锁回去把核心拉高一档跑同一行。两次结果一对比比看任何文章都直观。而且这个过程用不了半小时却能帮你建立起对 GPU 推理性能调优最底层的那层直觉。