8G显存也能起飞？llama.cpp深度调优：稳跑64k上下文，从133到996 Tokens/s

部署方法见文章：

【我的配置】显卡: 3050 8G | 内存: 32G DDR4 | CPU: i3-12100

• 为什么显存没占满，速度却掉到了脚脖子？

• 为什么 CPU 线程拉满，性能反而缩水 50%？

• 本期视频带你实测 RTX 3050 8G 在运行 Qwen 3.5 9B 时的性能极限。

• 通过《三体》3 万字压力测试，深度拆解上下文长度、KV Cache 量化、Batch Size 以及 CPU 线程对推理速度的真实影响。

• Token 速度其实要分两段看： 输入速度 (Prompt Processing)：AI 在“读”文档。它是并行的，所以很快。在 32k 模式下我跑出了 941 tok/s，这决定了处理 3 万字长文档的预热时间。 输出速度 (Token Generation)：AI 在“写”回复。它是串行的，一个字一个字吐，受显存带宽限制。我这套配置稳定在 25 tok/s 左右

【核心调优结论】

1. 8G 显存黄金平衡点：32k 上下文--ctx-size

2. 64k 极限模式：必开缓存量化 --cache-type-k/v q4_0

3. 预处理加速：调大吞吐量 --batch-size 远比增加 CPU 线程有效

优化方案1：上下文增减测试：

上下文测试方法：

使用《三体》（第一部）‌截取部分：

在16k的位置（1.2万字），插入一段不相关文字：“注：本项目进场道路补偿标准为每平米 500 元。”

然后让ai问答：“请在整篇文档中找出关于‘进场道路补偿标准’的具体描述。”

在32k的位置（2.4万字），插入一段不相关文字：“注：本项目业主是住建局”

然后让ai问答：“请在整篇文档中找出关于‘本项目业主’的具体描述。”

对比图表（上下文：32k vs 64k）

问题：为什么同样的文档，上下文从 32k 改成 64k，速度竟然慢了 7 倍？

因为你撞到了“显存性能悬崖”。

• 32k 模式（满速起飞）： 模型加缓存一共 7GB，刚好塞进 3050 的 8GB 显存。数据跑在 224GB/s 的高速公路上，30多秒就能处理完 3 万字。

• 64k 模式（性能掉帧）： 缓存翻倍到了 2GB，总占用瞬间顶到了 8GB 显存的天花板。

• 发生了什么？ 哪怕溢出 1MB，Windows 也会把数据挤进系统内存。带宽直接从 224G 暴降到 50G。

• 结论： 这就像法拉利被迫下了高速、进了泥泞小路。带宽的断崖式下跌，才是性能缩水 7 倍的元凶。

优化方案2：开启 KV Cache 缓存量化（黑科技）

在不改变 --ctx-size 64k 的前提下，加入以下参数： --cache-type-k q4_0 --cache-type-v q4_0

• 预期效果： 它能把 2GB 的缓存空间压缩到 1GB 左右

• 对比结果： 你会发现 64k 模式下， 会从 133 tok/s 回升到接近 535 tok/s，因为它把原本溢出到内存的部分重新塞回了显存

对比图表（缓存量化：关闭 vs 开启）

建议： 对于 8G 显存用户，32k 是“黄金平衡点”；如果非要上 64k增加上下文长度，必须开启 KV 缓存量化。

测试过程图片：

问题2 为什么显卡占用不到 30%，显卡在偷懒吗？

• 很多人看到任务管理器中 GPU 利用率只有 30% 左右，就以为显卡没跑满。

• 真相： 大模型推理是带宽受限任务。3050 的核心算力远超其显存读取速度。核心在 0.1 秒内算完了一组数据，却要花 0.9 秒等待显存把下一组权重“搬”过来。

• 结论： 占用率低不代表不努力，而是“路太窄，车太快”。

优化方案3： 提升吞吐量

1. Batch Size：预处理的“传送带”

在 llama.cpp 中，这两个参数控制 AI 读 3 万字《三体》的速度。

• --batch-size (默认 2048)： 逻辑批处理。它决定了系统一次性尝试处理的最大 Token 数。

• --ubatch-size (默认 512)： 物理批处理。这是真正发给 GPU 核心计算的每一份“数据包”的大小。

优化思路：

• 提升吞吐量： 既然 3050 核心占用才 30%，说明它确实很闲。尝试调大这两个值，让它一次多吃点。

• 测试方案： 设置 --batch-size 4096 --ubatch-size 1024

对比图表（吐量：默认 vs 提升）

效果： 64k 模式下那个 535 tokens/s 的速度进一步提升到996+，时间从68s缩小到40s，因为 GPU 的并行能力被更充分地利用了。

提示： 调大这两个值会额外占用显存，在 64k 极限模式下，如果显存已经见底，调大参数可能导致崩溃或强制进入极慢的共享内存模式。

优化方案4：CPU 端的配合

即便全显卡运行（-ngl 99），CPU 依然负责数据的调度和批处理。

• --threads 与 --threads-batch：专门负责 PP 阶段的 CPU 协作。适当调高可以减少 GPU 等待 CPU 分发任务的时间

• 对于 i3-12100（4 核 8 线程），尝试设置：--threads 4 --threads-batch 6

对比图表（CPU：默认 vs 开启）

结果：负优化，时间增加了20s，速度降低了470tokens

避坑指南：为什么 CPU 线程不是越多越好？

在 -ngl 99 全显存模式下，性能逻辑会发生巨变。

• GPU 是主力： 扛下了几乎所有的矩阵运算。

• CPU 是调度员： 只负责打包数据和最后发指令。

强行开启多线程，会触发“线程竞争”。 CPU 为了在不同任务间切换，浪费了大量时间在“内耗”上，这就是上下文切换开销。

打个比方： 指挥官带的随从越多，内部开会的时间就越长，反而耽误了给前线发命令。 最终建议： 对于全显卡运行，少即是多。默认设置或者低线程运行，往往比强行拉满快得多。

.\llama-server.exe `
  --model Qwen3.5-9B-UD-Q4_K_XL.gguf `
  --mmproj mmproj-F16-9B.gguf `
  --alias "unsloth/Qwen3.5-9B-GGUF" `
  --ctx-size 32768 `
  --temp 0.7 `
  --top-p 0.8 `
  --top-k 20 `
  --min-p 0.00 `
  --port 8080 `
  --n-gpu-layers 99 `
  --flash-attn auto `
  --reasoning off