最近做了个实验让我对着屏幕怀疑了半天显卡是不是坏了把核心频率从1700MHz拉到2330MHz频率提升了整整37%结果部署在16GB显卡上的7B模型推理速度只从12.35秒降到11.64秒算下来就快了6%。这个结果不是玄学也不是我采数采错了而是“内存墙”在LLM推理里实实在在地卡着脖子。我在这篇文章里把当时的测试方法、数据、底层原理和踩过的坑完整拆开给同样在消费级显卡上折腾大模型推理的朋友一个参考。1. 为什么“核心频率提高了37%”却没有用1.1 一个让直觉翻车的实验我估计很多第一次做LLM部署的朋友都会有个朴素想法显卡越强、频率越高推理越快。毕竟CPU那边超频之后的提升是肉眼可见的。可到了GPU上尤其是跑Transformer类模型时这个直觉经常会翻车。我先说一下测试结论的含金量。为了不让散热和自动Boost干扰我先把显卡锁定在一个保守的1700MHz跑了10轮基准取中位数作为基线。然后把核心锁到2330MHz也就是1700×1.37温度、显存频率、模型和输入输出长度全部保持不变。结果呢推理时间只降低了6%。如果把显卡核心频率当成“工人干活的速度”把显存带宽当成“把材料搬到工位的传送带”你会发现这个实验就像给工人提速37%但原材料在传送带上堵着工人再快也只能干等。这就是内存墙Memory Wall的典型场景。1.2 从显卡规格看“计算快”和“存取快”是两回事显卡宣传页上很少直接写“内存墙”但规格表里其实写得很清楚。拿我这张16GB显存的显卡来说它其实有两个“频率”概念核心频率SM运行的时钟和显存频率GDDR6/6X的时钟。这两个频率各管各的核心频率越高单位时间内能算的FLOPs越多显存频率越高单位时间内能搬运的字节数越多。LLM推理不是一种单纯的计算任务。以自回归解码为例每生成一个token都要把整个模型权重从显存读一遍然后做矩阵向量乘法。这中间的计算量其实不高但读取权重的时间是固定的。打个比方你让一个工人每秒能拧10颗螺丝但是传送带每5秒才送来一颗螺丝那你把工人提速多少也没用产线瓶颈在传送带。所以我在测试前就猜到了单纯调核心频率大概率是个位数提升。但真跑到6%还是让我有点意外因为6%比理论预期还要低一点这里面还有功耗墙和频率切换带来的噪音。后面我会单独讲怎么把这种误差压到最小。2. 实测设计16GB显卡上的控制变量实验2.1 测试平台、模型与推理引擎先把硬件交代一下一张16GB显存的显卡操作系统是Ubuntu 22.04驱动和CUDA版本保持统一。为了尽量贴近真实部署场景我用的推理引擎是vLLM它算是当前LLM推理里比较有代表性的方案支持PagedAttention、连续批处理这些常见优化。模型我选的是Qwen2.5-7B-Instruct的GPTQ 4bit版本4bit量化不是重点但它能让单卡跑起来更稳不会因为显存溢出把实验搞废。选这个模型还有一个原因7B规模不大不小单卡能放下做基准测试的内存占用也比较可控。如果你手头只有6GB或者8GB的显卡换成Qwen2-1.5B或Llama 3.2 3B也能复现同样的趋势只要保持“同一个模型、同一份输入”就行。2.2 锁定频率的正确姿势在Linux下我用nvidia-smi的-lgc参数锁核心频率。这块真的容易踩坑我第一次只锁了最大频率结果Boost还是会跳成绩忽高忽低。正确的做法是同时指定下限和上限sudo nvidia-smi -lgc 1700,1700锁显存频率用-lmc例如sudo nvidia-smi -lmc 5000,5000如果显卡不支持锁显存频率至少也要保证测试期间显存频率不被动态调度。另外注意-lgc解锁用-rgc否则下次跑测试还是锁频状态。每次改完频率最好重启一下推理引擎避免驱动残留状态影响性能。2.3 评测指标与跑分步骤我用了最简单的吞吐指标固定输入长度512 token、输出长度512 token连续发起10次请求取平均端到端耗时。这里有一个容易被忽略的细节vLLM默认会做KV Cache复用但如果请求是新连接首token延迟和机器预热状态影响很大所以我在正式记录之前先跑了两轮“热身”再把数据记下来。我用的是vLLM自带的benchmark脚本如果不想装额外框架也可以用Python的time模块包一层HTTP请求。重点不是工具而是控制变量。下面这组命令可以复现python benchmark_latency.py --backend vllm --model Qwen2.5-7B-Instruct --quantization gptq --input-len 512 --output-len 512 --num-prompts 10跑完之后把输出重定向到文件再取平均。温度、功耗这些我用nvidia-smi dmon -s pt实时记录确认测试期间没有因为过热降频。3. 结果分析6%背后是“内存墙”在作怪3.1 频率与访存的账一张表算清楚这是核心数据表。为了验证瓶颈是显存带宽不是核心频率我把显存频率这个变量也一起测了场景核心频率(MHz)显存频率(MHz)平均耗时(s)相对基线基线1700500012.351.00x核心37%2330500011.640.94x快6%显存37%170068509.850.80x快20%核心37% 显存37%233068508.970.73x快27%把核心频率单独拉高只快6%把显存频率单独拉高快了20%。这说明这个任务的瓶颈非常明确访存。而且两个一起拉也没有达到1.37×1.2的叠加效果因为还有一小半时间花在计算和别的环节上说明这时候已经接近带宽的天花板了。3.2 为什么提升显存频率反而能提速20%这里的“20%”不是说显存频率提升37%就能带来20%加速而是说在这个任务里访存的时间占比大约55%到60%。如果你把传送带速度提升37%原来6秒的访存时间会降到4.4秒如果其他时间保持不变总时间从12秒降到10.2秒算下来就是15%-20%的收益。我实测是20%说明访存占比比预想还高。这个比例在不同模型上会变。模型参数越小、量化程度越深访存占比越高序列越长KV Cache这块的访存也会涨。反过来如果使用很大的输入批量计算部分占比会上来核心频率的影响会稍微明显一点但幅度有限。3.3 对比场景量化模型与更小显存的影响如果你的显卡只有8GB甚至6GB这个内存墙效应会更夸张。因为小显存往往意味着更低的带宽比如RTX 4060只有272GB/s比4080的736GB/s差一大截。跑同样7B模型核心频率提升带来的收益可能连3%都不到。量化模型确实会让权重变小。比如Qwen2.5-7B的fp16权重约14GB4bit量化后约4GB。每次decode读取的权重从14GB降到4GB访存压力小了很多。但即使这样算术强度也还不够高依然是带宽受限。这也就是为什么社区里大家都说“量化最大的收益不是省显存而是省带宽”。4. 内存墙的底层原理从Roofline模型看LLM推理4.1 算术强度到底是多少要定性地理解内存墙最好用Roofline模型。这个模型非常简单横轴是算术强度FLOPs/Byte纵轴是性能FLOPS硬件能达到的峰值FLOPS除以带宽得到一个拐点。如果计算量与访存量的比值低于这个拐点你就是内存受限高于才是计算受限。以7B模型为例推理一个token的浮点运算量约等于2×参数量也就是约14GFLOPs按7B算。访存量则等于读取全部权重的字节数。如果是fp16权重约14GB如果是4bit权重约4GB。那么算术强度分别是1 FLOP/Byte和3.5 FLOP/Byte。而我的显卡实际峰值算力大约50TFLOPS带宽约500GB/s拐点就是100 FLOP/Byte。你看1和3.5都远小于100所以decode阶段稳稳地坐在内存受限区域。核心频率拉高等于把峰值FLOPS往后挪但你还是远够不到拐点自然没多少提升。4.2 为什么Decode阶段受困于带宽LLM推理分为prefill和decode两个阶段。prefill阶段要处理一整段输入计算量很大算术强度比decode高不少所以更偏向计算受限。decode阶段一次只生成一个token矩阵向量乘法的规模很小但每生成一个token都要把整个权重再过一遍这就导致计算量低、访存量高典型的内存瓶颈。这也是为什么你用nvidia-smi看显存带宽利用率时decode阶段经常接近100%而SM利用率也就是计算核心的利用率未必高。反过来说提高核心频率对decode阶段的影响很小对prefill阶段的影响稍大但因为一个典型对话里decode时间占比可能超过80%总体还是被内存墙按得死死的。4.3 算一算推理一token需要读多少数据我习惯把“读取量”这个概念刻在脑子里。假设7B模型用4bit量化权重约4GB。推理时显存每次要向计算单元提供约4GB的权重加上KV Cache的读写取个中间值说5GB吧。如果显存带宽是500GB/s那么理论最短时间就是10毫秒。再加上其他开销实测一个token大约15毫秒这就对上了。如果显存频率提高37%带宽从500GB/s涨到685GB/s理论最短时间降到7.3毫秒。这意味着哪怕核心频率不变吞吐也能提升30%左右。我实测单token的延迟改善大概在20%说明已经有其他部分成了次瓶颈但核心频率从来都不是限制因素。5. 绕过内存墙的几条实用路径5.1 量化能直接压低读取量既然瓶颈在带宽最粗暴的办法就是减少要读的字节数。fp16转4bit权重读取量直接降到28%decode阶段的理论延迟差不多能按这个比例缩短。这也是为什么在消费级显卡上部署LLM量化基本是必选项。但不是说量化就万事大吉。有些4bit方案会把矩阵乘法的部分算子重写导致计算时反而更慢还有一些没有做显存对齐的量化会导致读放大。我的建议是针对你的显卡实测一下fp16和4bit在同样输入下的首token延迟和吞吐别只盯着显存占用看。5.2 更大的batch size为什么能缓解内存墙的另一个突破口是提高批大小。批量推理时多个序列的权重是共享的你只要读一次权重就能服务多条请求相当于把访存成本摊薄到每个token上。这就把算术强度抬上去了让核心频率的影响慢慢变大。比如batch size从1提到4理论算术强度变成原来的4倍4bit模型从3.5 FLOP/Byte变成14 FLOP/Byte虽然还没到拐点但方向是对的。这就是为什么生产环境里都在强调连续批处理和PagedAttention不是为了单纯炫技而是为了让计算单元别一直闲着。5.3 算子融合、KV Cache等推理引擎优化除了算法层面的调参推理引擎本身也在推各种减少访存的优化。算子融合是把几个小kernel合并成一个大kernel减少中间结果在显存里的写入和读回KV Cache则是把历史token的Key和Value缓存起来避免每步重新计算注意力。如果你用的是vLLM这类引擎先确认有没有开启PagedAttention再检查--max-num-seqs和--gpu-memory-utilization这些参数。有些部署默认配置为了省显存会把KV Cache限制得很小导致decode的时候频繁spill到内存或者重新计算性能猛地掉下去。这虽然不算严格意义上的“内存墙”但同样是你感知到的慢。6. 实测中的常见问题与避坑指南6.1 频率锁不住功耗墙和温度墙在捣乱做这个实验最容易翻车的地方就是你以为锁住了其实GPU还留在自动Boost状态。我遇到过几次明明nvidia-smi -lgc 1700,1700执行成功了但一跑负载驱动立刻把频率拉回Boost因为那几颗核心负载太低。解决思路有两个一个是把负载跑起来之后再检查频率用nvidia-smi --query-gpuclocks.sm --formatcsv确认另一个是给显卡把功耗限制拉满避免功耗墙降频。不过拉功耗有风险温度超过85℃之后频率还是会往下掉所以最好把机箱打开或者用风扇对着吹。6.2 nvidia-smi dmon怎么看内存带宽利用率很多人只看nvidia-smi主界面的“Memory Used”就把显存性能说成瓶颈这是不对的。显存占用高不代表带宽占满要看真正的带宽利用率用nvidia-smi dmon -s pt能记录每个GPU的SM时钟、内存时钟、温度和功耗但注意它不直接显示带宽百分比。想要精确的带宽利用率得用NVIDIA Nsight Computencu或者Nsight Systems的Memory Workload Analysis。没有专业工具时有个土办法用dd读写显存测一下实际带宽或者直接跑一个纯矩阵向量乘法的microbenchmark把实测带宽和理论带宽估出来。比猜强多了。6.3 复现实验的建议清单如果你也想复现这组数据我按踩坑顺序列一个清单照着做基本能拿到稳定结果固定GPU频率用-lgc和-lmc同时锁定核心和显存锁完用nvidia-smi --query-gpuclocks.sm,clocks.mem --formatcsv验证。跑三轮热身请求等KV Cache和CUDA context都稳定之后再开始计分。每次修改完参数后重启推理引擎避免vLLM把旧的调度状态带进新测试。日志里除了耗时还要记录平均温度、功耗、SM频率防止结果是降频后跑出来的。用同一个随机种子生成输入输出长度不然对比没有意义。这里额外说一下如果你的显卡支持ReBARResizable BAR建议先关掉再测因为它会影响小规模随机读的性能干扰频率变量的对比。这套流程跑完你大概也会得出一个和我类似的结论在消费级显卡上搞LLM推理入手提升优先级应该是“显存带宽 量化方案 批大小 核心频率”。核心频率不是没用只是它在内存墙面前排不上号。我把最后一次实验的原始日志贴在最后一行是核心频率2330、显存5000的跑分一行是核心1700、显存6850的跑分。区别一摆比什么理论都直观。如果你跑出来的数据和我的偏差超过10%先检查频率有没有真的锁住再去翻功耗墙和温度墙的日志这两项至少能解释一大半异常。好了以上就是这个内存墙实验的全过程。显卡超频一时爽但跑LLM推理的时候老老实实研究显存带宽和量化方案才是治本的路子。我之后还会用这组测试方法继续对比不同的量化格式和批处理参数到时候再把数据拉出来做对比。 
长河君 · 2026/11/2 7:54:20 · 阅读 1.2k 内存墙才是LLM推理真正的瓶颈：GPU核心频率超频实测
最近做了个实验让我对着屏幕怀疑了半天显卡是不是坏了把核心频率从1700MHz拉到2330MHz频率提升了整整37%结果部署在16GB显卡上的7B模型推理速度只从12.35秒降到11.64秒算下来就快了6%。这个结果不是玄学也不是我采数采错了而是“内存墙”在LLM推理里实实在在地卡着脖子。我在这篇文章里把当时的测试方法、数据、底层原理和踩过的坑完整拆开给同样在消费级显卡上折腾大模型推理的朋友一个参考。1. 为什么“核心频率提高了37%”却没有用1.1 一个让直觉翻车的实验我估计很多第一次做LLM部署的朋友都会有个朴素想法显卡越强、频率越高推理越快。毕竟CPU那边超频之后的提升是肉眼可见的。可到了GPU上尤其是跑Transformer类模型时这个直觉经常会翻车。我先说一下测试结论的含金量。为了不让散热和自动Boost干扰我先把显卡锁定在一个保守的1700MHz跑了10轮基准取中位数作为基线。然后把核心锁到2330MHz也就是1700×1.37温度、显存频率、模型和输入输出长度全部保持不变。结果呢推理时间只降低了6%。如果把显卡核心频率当成“工人干活的速度”把显存带宽当成“把材料搬到工位的传送带”你会发现这个实验就像给工人提速37%但原材料在传送带上堵着工人再快也只能干等。这就是内存墙Memory Wall的典型场景。1.2 从显卡规格看“计算快”和“存取快”是两回事显卡宣传页上很少直接写“内存墙”但规格表里其实写得很清楚。拿我这张16GB显存的显卡来说它其实有两个“频率”概念核心频率SM运行的时钟和显存频率GDDR6/6X的时钟。这两个频率各管各的核心频率越高单位时间内能算的FLOPs越多显存频率越高单位时间内能搬运的字节数越多。LLM推理不是一种单纯的计算任务。以自回归解码为例每生成一个token都要把整个模型权重从显存读一遍然后做矩阵向量乘法。这中间的计算量其实不高但读取权重的时间是固定的。打个比方你让一个工人每秒能拧10颗螺丝但是传送带每5秒才送来一颗螺丝那你把工人提速多少也没用产线瓶颈在传送带。所以我在测试前就猜到了单纯调核心频率大概率是个位数提升。但真跑到6%还是让我有点意外因为6%比理论预期还要低一点这里面还有功耗墙和频率切换带来的噪音。后面我会单独讲怎么把这种误差压到最小。2. 实测设计16GB显卡上的控制变量实验2.1 测试平台、模型与推理引擎先把硬件交代一下一张16GB显存的显卡操作系统是Ubuntu 22.04驱动和CUDA版本保持统一。为了尽量贴近真实部署场景我用的推理引擎是vLLM它算是当前LLM推理里比较有代表性的方案支持PagedAttention、连续批处理这些常见优化。模型我选的是Qwen2.5-7B-Instruct的GPTQ 4bit版本4bit量化不是重点但它能让单卡跑起来更稳不会因为显存溢出把实验搞废。选这个模型还有一个原因7B规模不大不小单卡能放下做基准测试的内存占用也比较可控。如果你手头只有6GB或者8GB的显卡换成Qwen2-1.5B或Llama 3.2 3B也能复现同样的趋势只要保持“同一个模型、同一份输入”就行。2.2 锁定频率的正确姿势在Linux下我用nvidia-smi的-lgc参数锁核心频率。这块真的容易踩坑我第一次只锁了最大频率结果Boost还是会跳成绩忽高忽低。正确的做法是同时指定下限和上限sudo nvidia-smi -lgc 1700,1700锁显存频率用-lmc例如sudo nvidia-smi -lmc 5000,5000如果显卡不支持锁显存频率至少也要保证测试期间显存频率不被动态调度。另外注意-lgc解锁用-rgc否则下次跑测试还是锁频状态。每次改完频率最好重启一下推理引擎避免驱动残留状态影响性能。2.3 评测指标与跑分步骤我用了最简单的吞吐指标固定输入长度512 token、输出长度512 token连续发起10次请求取平均端到端耗时。这里有一个容易被忽略的细节vLLM默认会做KV Cache复用但如果请求是新连接首token延迟和机器预热状态影响很大所以我在正式记录之前先跑了两轮“热身”再把数据记下来。我用的是vLLM自带的benchmark脚本如果不想装额外框架也可以用Python的time模块包一层HTTP请求。重点不是工具而是控制变量。下面这组命令可以复现python benchmark_latency.py --backend vllm --model Qwen2.5-7B-Instruct --quantization gptq --input-len 512 --output-len 512 --num-prompts 10跑完之后把输出重定向到文件再取平均。温度、功耗这些我用nvidia-smi dmon -s pt实时记录确认测试期间没有因为过热降频。3. 结果分析6%背后是“内存墙”在作怪3.1 频率与访存的账一张表算清楚这是核心数据表。为了验证瓶颈是显存带宽不是核心频率我把显存频率这个变量也一起测了场景核心频率(MHz)显存频率(MHz)平均耗时(s)相对基线基线1700500012.351.00x核心37%2330500011.640.94x快6%显存37%170068509.850.80x快20%核心37% 显存37%233068508.970.73x快27%把核心频率单独拉高只快6%把显存频率单独拉高快了20%。这说明这个任务的瓶颈非常明确访存。而且两个一起拉也没有达到1.37×1.2的叠加效果因为还有一小半时间花在计算和别的环节上说明这时候已经接近带宽的天花板了。3.2 为什么提升显存频率反而能提速20%这里的“20%”不是说显存频率提升37%就能带来20%加速而是说在这个任务里访存的时间占比大约55%到60%。如果你把传送带速度提升37%原来6秒的访存时间会降到4.4秒如果其他时间保持不变总时间从12秒降到10.2秒算下来就是15%-20%的收益。我实测是20%说明访存占比比预想还高。这个比例在不同模型上会变。模型参数越小、量化程度越深访存占比越高序列越长KV Cache这块的访存也会涨。反过来如果使用很大的输入批量计算部分占比会上来核心频率的影响会稍微明显一点但幅度有限。3.3 对比场景量化模型与更小显存的影响如果你的显卡只有8GB甚至6GB这个内存墙效应会更夸张。因为小显存往往意味着更低的带宽比如RTX 4060只有272GB/s比4080的736GB/s差一大截。跑同样7B模型核心频率提升带来的收益可能连3%都不到。量化模型确实会让权重变小。比如Qwen2.5-7B的fp16权重约14GB4bit量化后约4GB。每次decode读取的权重从14GB降到4GB访存压力小了很多。但即使这样算术强度也还不够高依然是带宽受限。这也就是为什么社区里大家都说“量化最大的收益不是省显存而是省带宽”。4. 内存墙的底层原理从Roofline模型看LLM推理4.1 算术强度到底是多少要定性地理解内存墙最好用Roofline模型。这个模型非常简单横轴是算术强度FLOPs/Byte纵轴是性能FLOPS硬件能达到的峰值FLOPS除以带宽得到一个拐点。如果计算量与访存量的比值低于这个拐点你就是内存受限高于才是计算受限。以7B模型为例推理一个token的浮点运算量约等于2×参数量也就是约14GFLOPs按7B算。访存量则等于读取全部权重的字节数。如果是fp16权重约14GB如果是4bit权重约4GB。那么算术强度分别是1 FLOP/Byte和3.5 FLOP/Byte。而我的显卡实际峰值算力大约50TFLOPS带宽约500GB/s拐点就是100 FLOP/Byte。你看1和3.5都远小于100所以decode阶段稳稳地坐在内存受限区域。核心频率拉高等于把峰值FLOPS往后挪但你还是远够不到拐点自然没多少提升。4.2 为什么Decode阶段受困于带宽LLM推理分为prefill和decode两个阶段。prefill阶段要处理一整段输入计算量很大算术强度比decode高不少所以更偏向计算受限。decode阶段一次只生成一个token矩阵向量乘法的规模很小但每生成一个token都要把整个权重再过一遍这就导致计算量低、访存量高典型的内存瓶颈。这也是为什么你用nvidia-smi看显存带宽利用率时decode阶段经常接近100%而SM利用率也就是计算核心的利用率未必高。反过来说提高核心频率对decode阶段的影响很小对prefill阶段的影响稍大但因为一个典型对话里decode时间占比可能超过80%总体还是被内存墙按得死死的。4.3 算一算推理一token需要读多少数据我习惯把“读取量”这个概念刻在脑子里。假设7B模型用4bit量化权重约4GB。推理时显存每次要向计算单元提供约4GB的权重加上KV Cache的读写取个中间值说5GB吧。如果显存带宽是500GB/s那么理论最短时间就是10毫秒。再加上其他开销实测一个token大约15毫秒这就对上了。如果显存频率提高37%带宽从500GB/s涨到685GB/s理论最短时间降到7.3毫秒。这意味着哪怕核心频率不变吞吐也能提升30%左右。我实测单token的延迟改善大概在20%说明已经有其他部分成了次瓶颈但核心频率从来都不是限制因素。5. 绕过内存墙的几条实用路径5.1 量化能直接压低读取量既然瓶颈在带宽最粗暴的办法就是减少要读的字节数。fp16转4bit权重读取量直接降到28%decode阶段的理论延迟差不多能按这个比例缩短。这也是为什么在消费级显卡上部署LLM量化基本是必选项。但不是说量化就万事大吉。有些4bit方案会把矩阵乘法的部分算子重写导致计算时反而更慢还有一些没有做显存对齐的量化会导致读放大。我的建议是针对你的显卡实测一下fp16和4bit在同样输入下的首token延迟和吞吐别只盯着显存占用看。5.2 更大的batch size为什么能缓解内存墙的另一个突破口是提高批大小。批量推理时多个序列的权重是共享的你只要读一次权重就能服务多条请求相当于把访存成本摊薄到每个token上。这就把算术强度抬上去了让核心频率的影响慢慢变大。比如batch size从1提到4理论算术强度变成原来的4倍4bit模型从3.5 FLOP/Byte变成14 FLOP/Byte虽然还没到拐点但方向是对的。这就是为什么生产环境里都在强调连续批处理和PagedAttention不是为了单纯炫技而是为了让计算单元别一直闲着。5.3 算子融合、KV Cache等推理引擎优化除了算法层面的调参推理引擎本身也在推各种减少访存的优化。算子融合是把几个小kernel合并成一个大kernel减少中间结果在显存里的写入和读回KV Cache则是把历史token的Key和Value缓存起来避免每步重新计算注意力。如果你用的是vLLM这类引擎先确认有没有开启PagedAttention再检查--max-num-seqs和--gpu-memory-utilization这些参数。有些部署默认配置为了省显存会把KV Cache限制得很小导致decode的时候频繁spill到内存或者重新计算性能猛地掉下去。这虽然不算严格意义上的“内存墙”但同样是你感知到的慢。6. 实测中的常见问题与避坑指南6.1 频率锁不住功耗墙和温度墙在捣乱做这个实验最容易翻车的地方就是你以为锁住了其实GPU还留在自动Boost状态。我遇到过几次明明nvidia-smi -lgc 1700,1700执行成功了但一跑负载驱动立刻把频率拉回Boost因为那几颗核心负载太低。解决思路有两个一个是把负载跑起来之后再检查频率用nvidia-smi --query-gpuclocks.sm --formatcsv确认另一个是给显卡把功耗限制拉满避免功耗墙降频。不过拉功耗有风险温度超过85℃之后频率还是会往下掉所以最好把机箱打开或者用风扇对着吹。6.2 nvidia-smi dmon怎么看内存带宽利用率很多人只看nvidia-smi主界面的“Memory Used”就把显存性能说成瓶颈这是不对的。显存占用高不代表带宽占满要看真正的带宽利用率用nvidia-smi dmon -s pt能记录每个GPU的SM时钟、内存时钟、温度和功耗但注意它不直接显示带宽百分比。想要精确的带宽利用率得用NVIDIA Nsight Computencu或者Nsight Systems的Memory Workload Analysis。没有专业工具时有个土办法用dd读写显存测一下实际带宽或者直接跑一个纯矩阵向量乘法的microbenchmark把实测带宽和理论带宽估出来。比猜强多了。6.3 复现实验的建议清单如果你也想复现这组数据我按踩坑顺序列一个清单照着做基本能拿到稳定结果固定GPU频率用-lgc和-lmc同时锁定核心和显存锁完用nvidia-smi --query-gpuclocks.sm,clocks.mem --formatcsv验证。跑三轮热身请求等KV Cache和CUDA context都稳定之后再开始计分。每次修改完参数后重启推理引擎避免vLLM把旧的调度状态带进新测试。日志里除了耗时还要记录平均温度、功耗、SM频率防止结果是降频后跑出来的。用同一个随机种子生成输入输出长度不然对比没有意义。这里额外说一下如果你的显卡支持ReBARResizable BAR建议先关掉再测因为它会影响小规模随机读的性能干扰频率变量的对比。这套流程跑完你大概也会得出一个和我类似的结论在消费级显卡上搞LLM推理入手提升优先级应该是“显存带宽 量化方案 批大小 核心频率”。核心频率不是没用只是它在内存墙面前排不上号。我把最后一次实验的原始日志贴在最后一行是核心频率2330、显存5000的跑分一行是核心1700、显存6850的跑分。区别一摆比什么理论都直观。如果你跑出来的数据和我的偏差超过10%先检查频率有没有真的锁住再去翻功耗墙和温度墙的日志这两项至少能解释一大半异常。好了以上就是这个内存墙实验的全过程。显卡超频一时爽但跑LLM推理的时候老老实实研究显存带宽和量化方案才是治本的路子。我之后还会用这组测试方法继续对比不同的量化格式和批处理参数到时候再把数据拉出来做对比。