RTX 5060 Ti 16G 再升级：从”能跑”到”丝滑”，我把 35B 模型显存压到 11GB，超长上下文达到256K
⚠️ 免责声明：本文为个人量化交易系统的技术实践记录，仅用于知识分享与技术交流。文中所有数据、参数、分析均基于个人实测环境，不构成任何硬件购买建议或投资建议。市场有风险，投资需谨慎。
一、回头看：以前那篇文章，现在读起来有点脸红
我写过一篇技术记录，讲的是从核显+32GB内存，升级到 RTX 5060 Ti 16GB + 96GB 内存后跑本地大模型的体验。
当时的结论是——”能用”。
现在回头翻那篇，说实话，有点脸红。推理速度 2-4 token/s，这个数字放在今天看，基本属于”等它回复的时间够我泡杯茶”的水平。但那时候我觉得已经很好了——毕竟比起核显期那种”打字比等回复快”的日子，GPU 能跑起来本身就是胜利。
那时候的配置思路也很粗糙：模型往显存里塞，塞不下就少塞几层，实在不行就让 CPU 兜底。KV Cache 用的还是 fp16 精度，一个 32K 上下文的 KV Cache 就能吃掉将近一半显存。
说白了，以前就是——“活能活，但不太体面。”
这半年参数迭代了三轮，我从”别崩就行”的新手，变成”能省 1GB 绝不多吃 1MB”的精算师。如果你也是 16GB 显存跑本地大模型的同路人，这篇应该能帮你少踩坑。
二、现在的变化，一句话总结：显存省了 5GB
先上对比（数据全是实测，不是跑分软件那种”理想值”）：
| 维度 | 以前（初版配置） | 现在（优化后） | 变化 |
|---|---|---|---|
| GPU 显存占用 | ≈16GB（几乎爆满） | 11.3GB | ↓ 4.6GB |
| 上下文长度 | 32K | 256K | ×8 |
| KV Cache 精度 | fp16 | q4_0 | 精度略降，显存大减 |
| 推理速度 | 2-4 token/s | 46.5 token/s | ×10+ |
| 首字延迟 (TTFT) | 几秒级别 | 0.13秒 | 降了一个数量级 |
| 盘前扫描体验 | 卡顿，偶尔超时 | 丝滑，不卡 | 质的飞跃 |
核心：KV Cache 量化。 同一块显卡，显存从 16GB 爆满降到 11.3GB，上下文翻了8倍。
三、环境总览：我的真实配置
这个配置不是为了跑分，是为了干活。
硬件
- GPU：NVIDIA GeForce RTX 5060 Ti（16GB GDDR7 显存）
- CPU：Intel Core i7-14700KF（28核）
- 内存：96GB DDR5
- 系统：Windows 主机 + WSL2（Ubuntu）
软件栈
- 推理引擎：llama.cpp（llama-server）
- 模型：Qwen3.6-35B-A3B（Q4_K_M 量化，GGUF 格式，约 21GB）
- Chat Template：qwen3-tools.jinja（支持工具调用）
- CUDA：13.0 / Driver 581.29
（一开始用的 Qwen 3.5，后来才发现实际是 3.6——版本号的混乱在开源模型圈挺常见）
四、完整启动脚本（逐行解释）
下面是我现在实际在用的完整启动命令。每一个参数都不是拍脑袋设的，是踩坑踩出来的——有些坑踩了不止一次。
llama-server \
--model /home/administratorsun441621/llama-server/models/Qwen3.6-35B-A3B-Q4_K_M.gguf \
--host 0.0.0.0 --port 8081 \
--n-cpu-moe 32 \
--ctx-size 262144 \
--parallel 1 \
--batch-size 2048 \
--ubatch-size 2048 \
--flash-attn on \
--cache-type-k q4_0 \
--cache-type-v q4_0 \
--jinja --chat-template-file qwen3-tools.jinja \
--reasoning-format deepseek \
--embeddings \
--pooling mean下面拆开讲。
五、关键参数逐行拆解（大白话版）
1. --model / --host / --port
这三行没啥好说的。模型文件路径、监听地址、端口号。
踩坑记录：端口我原来用 8888，结果撞上了 WSL2 的端口排除范围（Windows 网络栈的坑），导致 llama-server 连续 12 天启动失败。改成 8081 才消停。如果你也在 WSL2 上跑，端口号千万别用 8880-8899 这个区间——别问我怎么知道的，问就是血泪。
2. --n-gpu-layers（当前未显式设置）
注意：当前实际运行中没有设置这个参数。
llama.cpp 默认会尽可能把层塞进 GPU。Qwen3.6-35B-A3B 的 Q4_K_M 量化后约 21GB，远超 16GB 物理显存，所以默认行为就是 GPU 能塞多少塞多少，剩下的放 CPU。
之前我设过 --n-gpu-layers 48 做显式上限，但后来发现 llama.cpp 的自动分配已经够用——显存稳定在 11.4GB，不需要手动限制。
教训：先用默认值观察显存和性能，有瓶颈再手动调。别盲目抄数字。
3. --n-cpu-moe 32（这是 MoE 模型独有的参数）
这是个容易被忽略但非常关键的参数。
Qwen3.6-35B-A3B 是 MoE（混合专家）架构。35B 参数听起来很大，但每次推理只激活一小部分”专家”。这就好比一个公司有 35 个部门，但每个项目只需要 3 个人参与——大部分人在”待命”。
--n-cpu-moe 32 的意思是：用 32 个 CPU 线程专门处理 MoE 专家的调度和路由。
设太大也有副作用——上下文切换开销会反噬并行收益。实测对比：设16 → CPU吃不满；设32 → 最优（CPU利用率70-80%）；设64 → TPS反而下降。28核CPU上的甜点值，不同核心数要重测。
4. --ctx-size 262144（上下文翻8倍，但显存没涨）
这个参数控制模型能”记住”多长的对话历史。256K token，粗略算就是能记住大约 20 万字的上下文。
半年前我用的是 32K。现在实际跑到 256K（262144 token），翻8倍的原因是——系统里现在有多个智能体在协作，对话历史越来越长，32K 经常不够用，一截断就丢上下文。那种正分析到一半突然”失忆”的感觉，真的让人抓狂。
但 256K 上下文不是白送的。如果不做 KV Cache 量化，256K 的 fp16 KV Cache 会吃掉 30-40GB 显存——加上模型本身，16GB 显卡直接 OOM，翻10倍都不够。
关键词就是下面这两个参数。
5. --cache-type-k q4_0 + --cache-type-v q4_0（整篇文章的核心）
这两个参数，值得单独开一节讲——因为它们是整篇文章最有价值的地方。
什么是 KV Cache？
大模型推理不是”说完上一个字忘了下一个字”。它在生成每个 token 的时候，都会把之前所有 token 的中间计算结果（Key 和 Value 矩阵）存起来，避免重复计算。这些存下来的中间结果，就叫 KV Cache。
KV Cache ≈ 模型推理时的草稿纸。
为什么需要量化？
默认 KV Cache 用 fp16 精度（每个值 2 字节），非常吃显存。量化就是把草稿从”16 位精打细算”换成”4 位够用就行”。
q4_0 能省多少？
以 256K 上下文为例：
- fp16 KV Cache：大约需要 30-40GB 显存
- q4_0 KV Cache：大约需要 2-3GB 显存
净省 27-37GB。
这就是为什么上下文从 32K 翻8倍到 256K，显存反而稳定在 11.4GB。
精度会不会明显下降？
先说结论：日常使用中 q4_0 和 fp16 的差别基本感知不到。
我做过一个对照测试：同一个缠论分析任务（读 20 日 K 线、计算中枢、判断 5 个条件），分别用 q4_0 和 q8_0 跑。
| KV Cache 精度 | 分析结果质量 | 显存占用 |
|---|---|---|
| fp16 | ★★★★★（满分） | ~16GB |
| q8_0 | ★★★★☆ | ~13GB |
| q4_0 | ★★★★ | ~11.3GB |
q4_0 的分析结果和 q8_0 几乎看不出区别，只在极个别需要非常精确的数值计算时会有轻微偏差——但这种场景在我的系统里占比不到 1%。
省 5GB 显存换来几乎无感的质量损失——这笔账怎么算都划算。
对大多数场景，q4_0 足够了——别纠结，直接上。
6. --flash-attn on
Flash Attention 用更聪明的算法做注意力计算，既快又省显存。不开的话，256K 上下文的注意力矩阵大得离谱。
必须开。别省这个开关。
7. --parallel 1
同时处理请求数。单机单用设 1 最稳。
8. 其他参数
--jinja+--chat-template-file：使用 Jinja 模板引擎渲染对话，支持工具调用格式--batch-size 2048+--ubatch-size 2048：批处理大小和内部批大小，设为一致值避免调度开销--pooling mean：启用均值池化，嵌入向量质量更好--reasoning-format deepseek：推理格式，适配多智能体协作场景--embeddings：启用嵌入向量输出（知识库检索需要）
六、显存账本
一张表看明白：
GPU 总显存：16GB
├── 模型权重（Q4_K_M）：≈8GB
├── KV Cache（q4_0，256K上下文）：≈2.3GB
├── Flash Attention 缓冲 + 其他：≈1.1GB
└── 合计（llama-server 占用）：11.3GB（实测 11578 MiB）
剩余可用：4.7GB对比旧配置（无 KV Cache 量化，fp16 KV Cache）：
GPU 总显存：16GB
├── 模型权重：≈8GB
├── KV Cache（fp16，32K上下文）：≈5GB
├── 其他：≈1GB
└── 合计：≈14GB
剩余：≈2GB（稍微波动就OOM）显存占用从 14GB 降到 11.3GB，上下文从 32K 翻到 256K。
同样的硬件，换个参数，效果天差地别。这种感觉，就像你一直以为家里网速慢是运营商的问题，结果发现是路由器没插好——又好气又好笑。
七、实际效果：从”能用”到”丝滑”
推理速度
- TTFT（首字延迟）：0.13 秒——你敲完回车，几乎没有等待就开始出字
- TPS（每秒 token 数）：46.5——读速约等于你眼睛扫过屏幕的速度
盘前扫描
盘前全 A 股扫描是我的系统日常任务里最重的一个。需要批量读取 5000+ 只股票的近期数据，逐个调用模型做缠论信号分析。
半年前：跑一半就开始卡，偶尔超时，有时候 GPU 显存撑不住直接崩掉。那种坐在电脑前等结果、结果等来一个进程崩溃的感觉，真的太熟悉了。
现在：一气呵成，全程流程。不会再出现跑着跑着就”呼吸急促”的感觉了。
日常对话
多宝的日常对话——调度、路由、文件操作这类任务——现在基本感觉不到模型在”思考”。0.13 秒的首字延迟，体感就是即时的。
八、踩坑记录（都是血泪换的）
坑1：GPU 驱动加载延迟
WSL2 开机时 GPU 驱动不是立刻可用的，加一个等待循环解决：
for i in $(seq 1 30); do
if nvidia-smi -L &>/dev/null; then
echo "GPU 驱动就绪"
break
fi
sleep 2
done坑2：WSL2 端口排除范围
前面提过了，再强调一次：8880-8899 在 WSL2 里可能被 Windows 网络栈预留，你 bind 不了这些端口。
调试这个坑花了我整整 12 天——端口明明没人用（lsof、ss 都看不到），就是 bind 不上。后来发现是 Windows 的 netsh int ipv4 show excludedportrange 里有这段。
教训：WSL2 上跑服务，优先用 8000+ 的高位端口，避开 8880-8899 和 9090。别跟我一样，为了一个端口折腾 12 天。
坑3：KV Cache 精度设多少？
q4_0 vs q8_0 vs fp16——别纠结，直接测。 结果前面贴过了：q4_0 和 q8_0 差距基本感知不到。
建议：
- 显存紧张（16GB 跑 35B 模型）→ 直接用 q4_0，别犹豫
- 显存充裕（24GB+）→ 可以用 q8_0，白嫖一点精度提升
- 精度极致场景 → fp16，但要做好显存预算
别在这个问题上纠结太久——实测比什么都强。
坑4：n-gpu-layers 不是越大越好
一开始设 999，结果显存爆炸。要找”刚好够但不爆”的值。方法：
- 从安全值开始（16GB 显卡 ≈ 20 层）
- 每次 +5 层，重启观察 nvidia-smi
- 显存稳定在 85% 以下时继续加
- 显存超过 90% → 回退到上一层
我的 48 层就是这样试出来的。这个过程有点枯燥，但值得——毕竟谁也不想半夜被 OOM 叫醒。
九、写在末尾
半年前写”能用”，是真的觉得能用。现在回头看，那时标准太低了。
现在 11.3GB 显存、256K 上下文、46.5 TPS，才算”丝滑”。半年后再看可能又要脸红。但这次应该会好一点——显存账本的数字，是实打实省下来的。
AI 量化这条路，硬件软件都在以月为单位迭代。今天的”最优配置”，明天可能就是”勉强跑”。保持折腾，保持记录。
如果你也在用类似配置，上面这些参数应该能帮你省不少时间。一起折腾，总比一个人瞎撞强。
实测环境：RTX 5060 Ti 16GB + i7-14700KF + 96GB DDR5 + WSL2 模型：Qwen3.6-35B-A3B Q4_K_M (21GB GGUF) 推理引擎：llama.cpp (llama-server) 显存占用：11.3GB（16GB 总显存，实测 11578 MiB） 上下文：256K token（262144） KV Cache：q4_0 量化 实测日期：2026-07-20