1. 为什么 RTX 4060 跑 7B 模型值得单独拿出来聊RTX 4060 Laptop GPU 这张卡在本地推理圈子里其实挺尴尬的。8GB 显存算力不上不下跑 7B 模型刚好卡在能跑和跑得舒服之间的那条线上。很多人拿到笔记本第一件事就是装个 Ollama 或者 llama.cpp随便拉个 Qwen2.5:7B 或者 Llama 3.1:8B 下来一看输出速度 8.8 t/s 左右觉得也就这样了然后就停在那儿了。但实际情况是同一张卡、同一个模型调参前后差距可以拉到 10% 以上。我自己从 8.8 t/s 调到 9.7 t/s 的过程里真正起作用的不是什么玄学操作而是几个很具体的参数组合和编译选项。这篇文章就把整个调优链路拆开讲清楚包括每一步为什么这么做、哪些参数是真正影响速度的、哪些是心理安慰。先说清楚适用人群你手上有一台带 RTX 4060 Laptop GPU 的笔记本注意是 Laptop 版本桌面版 4060 的显存带宽和功耗释放不一样结论不能直接套想在本地方便地跑 7B 级别的量化模型对输出速度有要求但不想折腾太深。如果你用的是 4090 或者 A100这篇的很多结论对你参考价值有限因为瓶颈位置完全不同。关键词里提到的 llama.cpp、FlashAttention、Ollama 这几个东西我会在后面的章节里分别说清楚它们各自在链路里扮演什么角色以及哪些环节值得花时间、哪些环节不值得。2. 先搞清楚瓶颈在哪4060 Laptop 的硬件底子2.1 显存带宽才是真正的天花板很多人调参的时候盯着 GPU 利用率看觉得利用率没跑满就是没优化好。这个思路在本地推理场景下是错的。7B 模型做量化之后比如 Q4_K_M权重大概在 4GB 出头推理过程是典型的 memory-bound 任务也就是说瓶颈在显存带宽上不在算力上。RTX 4060 Laptop 的显存带宽是 256 GB/s128-bit 位宽GDDR6 等效 16 Gbps。这个数字决定了理论上限4GB 的权重每生成一个 token 至少要完整读一遍256 GB/s 除以 4GB 大约是 64 次每秒。但实际不可能达到理论值因为还有 KV Cache 的读写、激活值的搬运、以及各种 overhead。所以 8 到 10 t/s 这个区间对于 4060 Laptop 来说基本就是合理范围了。理解这一点很重要因为它直接决定了你的调参方向任何减少显存读写量的操作都可能提速任何只提升算力利用率的操作基本没用。2.2 8GB 显存能塞下什么8GB 显存要同时装下模型权重、KV Cache、CUDA context 和系统占用。实际可用大概在 7.2 到 7.5GB 之间。Q4_K_M 量化的 7B 模型权重约 4.1GB留给 KV Cache 的空间大概 2.5GB 左右。KV Cache 的大小跟上下文长度直接相关。以 Qwen2.5-7B 为例它的 KV Cache 每 token 占用大概是这样的28 层 × 2K 和 V× 4 个 KV head × 128 维 × 2 字节FP16 约 57KB per token。2.5GB 大概能撑 43000 多个 token 的上下文。听起来很多但如果你把 num_ctx 设成 32768再加上一些碎片就很容易触到上限。注意一旦显存不够llama.cpp 会自动把部分层 offload 到 CPU速度会断崖式下跌到 2-3 t/s。所以显存规划是调参的第一步不是最后一步。2.3 两个 GPU 的坑别让集显拖后腿热词里提到显卡有两个 Intel UHD Graphics 和 NVIDIA RTX 4060 Laptop GPU这个情况在笔记本上非常普遍。Windows 的默认 GPU 调度有时候会把 llama.cpp 的进程分配到集显上或者在某些混合输出模式下让数据绕路走集显。判断方法很简单跑推理的时候打开任务管理器看 NVIDIA GPU 的占用是不是接近 100%同时 Intel GPU 的占用是不是也在动。如果 Intel GPU 有明显占用说明数据在绕路。解决办法是在 NVIDIA 控制面板里把 llama-server.exe 或 ollama.exe 强制指定为高性能 NVIDIA 处理器同时在 Windows 图形设置里也做同样的指定。这个坑我踩过当时速度一直在 6 t/s 左右上不去查了半天参数最后发现是集显在中间插了一脚。3. 从 Ollama 到 llama.cpp工具链的选择逻辑3.1 Ollama 适合起步但不适合调优Ollama 的好处是安装简单、模型管理方便Windows 下双击安装包就完事。但它的默认参数是通用安全值不会针对你的具体硬件做优化。比如它默认的 num_ctx 是 2048 或 4096num_batch 也比较保守这些都会限制速度。你可以通过 Modelfile 或者环境变量去改 Ollama 的参数但能改的粒度有限。而且 Ollama 底层也是调 llama.cpp中间多了一层封装有些编译期的优化选项你控制不到。3.2 llama.cpp 直接编译才是调优的正路如果你真的想把 4060 Laptop 的性能榨出来建议直接用 llama.cpp 自己编译。Windows 下用 CMake Visual Studio 或者 w64devkit 都行关键是在编译时打开正确的 CUDA 架构选项。RTX 4060 Laptop 是 Ada Lovelace 架构计算能力 8.9。编译的时候要指定cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES89 cmake --build build --config Release -j如果你不确定自己的卡是什么架构可以用nvidia-smi --query-gpucompute_cap --formatcsv查一下。编译时不指定架构的话默认会编译多个架构的 kernel体积大不说运行时还可能选到不是最优的那个。3.3 FlashAttention 在 llama.cpp 里的实际作用FlashAttention 最早是训练侧的优化核心思路是通过分块计算减少 HBM 和 SRAM 之间的数据搬运。在推理场景下llama.cpp 里的-fa参数flash attention主要优化的是 attention 计算过程中的显存访问模式。在 4060 Laptop 上开-fa的实测效果对于 7B Q4_K_M 模型在上下文长度 4096 以内提升大概在 3% 到 5%。上下文越长提升越明显因为 attention 的显存访问占比会上升。但注意-fa在某些老版本的 llama.cpp 上跟某些量化类型有兼容性问题建议用较新的 release 版本。提示开-fa之后如果发现输出结果出现重复或乱码先关掉它排查确认是参数问题还是模型问题。4. 真正影响 t/s 的那几个参数4.1 num_batch 和 num_ubatch最容易被忽略的提速点这两个参数控制的是每次前向传播处理多少 token。num_batch是逻辑批次大小num_ubatch是物理微批次大小。在显存允许的前提下适当增大这两个值可以提升 GPU 的利用率。我的实测数据Qwen2.5-7B Q4_K_Mnum_ctx4096-fa 开启num_batchnum_ubatch输出速度 (t/s)5125128.810245129.1102410249.4204810249.6204820489.740962048显存不足回退可以看到从默认的 512/512 调到 2048/2048速度从 8.8 提到了 9.7提升约 10%。再往上调就爆显存了。这里有个细节num_batch和num_ubatch不一定要相等。一般来说num_ubatch不超过num_batch而且num_ubatch对显存的影响更直接。如果你显存紧张可以保持num_batch大、num_ubatch小这样能在有限显存下获得部分收益。4.2 num_ctx 不是越大越好很多人习惯把上下文开到最大觉得这样功能全。但 num_ctx 增大会直接增加 KV Cache 的显存占用间接压缩了 num_batch 的可调空间。在 4060 Laptop 8GB 的约束下我的建议是日常对话和代码补全num_ctx 4096 或 8192长文档处理num_ctx 16384同时把 num_batch 降到 1024超过 16384 的需求考虑用 CPU offload 或者换更小的模型实测 num_ctx 从 4096 提到 8192速度大概下降 2% 到 3%提到 16384下降 5% 到 8%。这个代价换来的是更长的上下文能力看你自己的使用场景取舍。4.3 GPU Layers 的分配策略-ngl参数控制有多少层放到 GPU 上。对于 7B 模型通常 28 到 32 层在 8GB 显存下Q4_K_M 量化一般可以全部 offload 到 GPU-ngl 99。但如果你用的量化级别更高比如 Q5_K_M 或 Q6_K或者 num_ctx 设得很大就可能需要留几层在 CPU 上。判断方法启动的时候看日志里有没有 offloaded X/Y layers to GPU 的字样。如果 X 小于 Y说明有层在 CPU 上跑速度会受影响。这时候要么降低量化级别要么减小 num_ctx要么接受部分 offload。4.4 线程数的设置别照搬 CPU 核心数-t参数控制 CPU 线程数。在 GPU 推理场景下CPU 主要负责数据预处理和后处理不需要太多线程。设成物理核心数的一半到三分之二通常比较合适。设太多反而会因为线程调度开销导致速度下降。我在这台机器上i7-13620H10 核 16 线程的实测-t 6比-t 16快了大约 0.3 t/s。这个差异不大但积少成多。5. 完整调参链路与实测对比5.1 基线配置的建立先跑一个基线把所有参数设成保守值记录速度./llama-cli -m qwen2.5-7b-q4_k_m.gguf \ -ngl 99 -c 4096 -b 512 -ub 512 -t 6 \ -n 256 -p 写一段关于本地推理的说明 \ --no-display-prompt这里-n 256是生成 256 个 token--no-display-prompt是不显示 prompt 部分方便看纯生成速度。跑三次取平均得到基线 8.8 t/s。5.2 逐步调参的记录然后按下面的顺序逐步调整每次只改一个参数观察速度变化开-fa8.8 → 9.0-b 1024 -ub 5129.0 → 9.2-b 1024 -ub 10249.2 → 9.4-b 2048 -ub 10249.4 → 9.6-b 2048 -ub 20489.6 → 9.7每一步的收益在递减但累积起来从 8.8 到 9.7 就是 10% 的提升。这个提升在体感上是能感觉到的尤其是生成长文本的时候。5.3 最终配置与稳定性验证最终用的启动命令./llama-server -m qwen2.5-7b-q4_k_m.gguf \ -ngl 99 -c 4096 -b 2048 -ub 2048 -t 6 \ -fa --host 127.0.0.1 --port 8080用 llama-server 而不是 llama-cli是因为 server 模式下可以持续跑方便做稳定性测试。连续跑 30 分钟观察速度有没有衰减显存泄漏或热降频会导致衰减。实测下来速度稳定在 9.5 到 9.7 之间没有明显衰减。注意笔记本的散热很关键。如果 GPU 温度超过 85 度会触发降频速度可能掉到 7 t/s 以下。建议垫高笔记本或者用散热底座必要时用 MSI Afterburner 把风扇曲线调激进一点。6. 那些我踩过的坑和对应的解法6.1 显存碎片导致的莫名其妙变慢有一次我改了 num_ctx 之后速度从 9.5 掉到了 6.2但显存占用看起来还没满。后来发现是显存碎片的问题llama.cpp 在启动时一次性分配 KV Cache如果分配失败会回退到更保守的策略但不一定报错。解决办法是每次改完参数后完全退出进程再重新启动不要在同一进程里反复加载不同配置。另外可以用nvidia-smi确认一下显存占用是否符合预期。6.2 模型量化格式的选择Q4_K_M 是速度和质量的平衡点但在 4060 Laptop 上Q4_0 其实更快因为计算更简单速度大概能到 10.2 t/s但输出质量下降比较明显尤其是代码生成任务。Q5_K_M 质量更好但速度会降到 8.5 左右而且显存占用更高。我的建议是日常用 Q4_K_M对质量要求高的场景用 Q5_K_M 并接受速度损失Q4_0 只在极端追求速度时考虑。6.3 Windows 下的 WDDM 显存管理Windows 的 WDDM 驱动模型会预留一部分显存给系统实际可用比标称的 8GB 少。而且不同驱动版本的预留量不一样。如果你发现同样的配置在 Linux 下能跑但 Windows 下爆显存大概率是这个原因。可以在 NVIDIA 控制面板里把CUDA - 系统内存回退设为优先使用系统内存回退这样显存不够时会用内存兜底虽然慢但不会直接崩。6.4 Ollama 和 llama.cpp 抢显存如果你同时装了 Ollama 和 llama.cpp注意 Ollama 的服务是常驻的会占用一部分显存。跑 llama.cpp 之前先确认 Ollama 没有加载模型。可以在任务管理器里看或者直接ollama stop掉当前模型。7. 关于 9.7 t/s 这个数字的实话9.7 t/s 意味着生成 100 个 token 大概 10 秒生成 500 个 token 大概 51 秒。这个速度用来做对话是够的用来做代码补全也勉强能用但如果你想要那种打字机式的流畅体验还是得靠云端或者更大的卡。不过本地推理的价值不在于速度而在于数据不出本机、随时可用、不受网络影响。在这个前提下把 4060 Laptop 从 8.8 调到 9.7算是把这张卡在 7B 模型上的潜力基本挖干净了。再往上提升要么换更好的量化方案比如 IQ4_XS但 llama.cpp 对它的支持还在完善中要么等软件层面的进一步优化。最后分享一个我常用的测试方法不要只看单次生成的速度用llama-bench跑一组标准测试这样得到的数字更可比。命令大概是./llama-bench -m qwen2.5-7b-q4_k_m.gguf -ngl 99 -c 4096 -b 2048 -ub 2048 -fa -t 6它会自动跑 prompt 处理和 token 生成两个阶段输出 pp 和 tg 两个指标。tg 就是你关心的生成速度。用这个工具做 A/B 对比比手动跑 llama-cli 靠谱得多。