5.3 进阶调优策略

5.3 进阶调优策略

本节摘要：基线测量（5.2）之后，真正能榨出体验的四个杠杆是：驻留策略（别让模型反复加载）、上下文管理（KV 缓存瘦身）、并行与批量（吞吐换延迟）、量化与层数微调（容量与带宽的平衡点）。本节逐个给出配置写法与适用前提。

杠杆一：驻留策略——最便宜的性能优化

冷加载一次 7B 模型要几秒到十几秒，70B 更是以分钟计。让常用模型常驻，收益远超任何硬件微调。三个粒度：

# 进程级：服务启动时全局生效
OLLAMA_KEEP_ALIVE=24h OLLAMA_MAX_LOADED_MODELS=2 ollama serve

# 请求级：单个调用覆盖全局设置
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b", "prompt": "ping", "stream": false,
  "keep_alive": -1
}'

# 会话级验证驻留状态与到期时间
ollama ps
​

-1 永不卸载（独占机器的服务推荐），0 用完即走（内存紧张的多人机器），中间值按使用节奏定。OLLAMA_MAX_LOADED_MODELS 在 Apple Silicon 上默认 3、其他平台默认 1——两个模型交替使用的场景务必确认这项，否则每次切换都重付加载成本。代价也要清楚：常驻即常驻内存，32GB 机器同时驻留两个 14B 会挤压系统，先算容量账（5.1）。

杠杆二：上下文管理——KV 缓存瘦身

num_ctx 默认 2048，做长文本必须调大，但每翻一倍，KV 缓存内存也近似翻倍，且预填充耗时线性增长。策略有三。

其一，按任务定窗口，不全局拉满：短问答 2048 够用，长文档摘要给 8192-16384。Modelfile 里固化：

FROM qwen2.5:7b
PARAMETER num_ctx 8192
​

其二，KV 缓存量化。开启 Flash Attention 后把缓存压到 q8_0（精度损失可忽略）甚至 q4_0（有损，先测质量）：

OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve
​

其三，历史裁剪。API 调用方自己裁 messages：保留 system 与最近 N 轮，更早的对话用一次模型调用压成摘要塞回去。这套"滚动摘要 + 近期原文"是长对话的标准做法，比硬扛 32k 窗口又快又省。

杠杆三：并行与批量——吞吐的来源

Ollama 0.2 起支持环境变量级的并行控制：OLLAMA_NUM_PARALLEL 允许同一模型同时处理多个请求（共享同一份权重，代价是每个并发槽都要有独立的 KV 缓存空间），OLLAMA_MAX_QUEUE 决定排队上限，OLLAMA_SCHED_SPREAD 让多个模型摊到多张卡上。

# 单卡服务允许 4 路并发、排队 200
OLLAMA_NUM_PARALLEL=4 OLLAMA_MAX_QUEUE=200 ollama serve
​

离线批处理则走另一条路：OLLAMA_BATCH_SIZE（默认 512）控制 CPU 后端的批大小，GPU 跑批更多受益于并行请求的合并。判断该不该开并发看 5.2 的测量：单请求 decode 利用率不满（比如 60%）时并发能提总吞吐；已经打满的话，并发只会摊薄每个人的速度。多用户场景的典型配方是"NUM_PARALLEL=2~4 + 前端排队限流"，单用户低延迟场景反而保持 1 路并行最稳。

杠杆四：量化档位与层数微调

量化选择已在 2.2 讲过原则，这里补一条调优视角：同模型两档量化跑一次 5.2 的探测脚本，若 t/s 差距大而质量差距小（用你自己的评测集判断，哪怕只有二十个问题），果断取低档。显存临界时的层数实验同理——--numgpu 从全层数往下试，找"全入显存的最大模型档"：

# 8B 全 33 层；显存不够时试试少给几层
ollama run llama3.1:8b --numgpu 20 --verbose "基准测试"
ollama run llama3.1:8b --numgpu 26 --verbose "基准测试"
​

在 6GB 卡上经常出现的最优解是"7B-Q4 全入"而非"13B-Q3 半入"：层数溢出造成的 PCIe 往返，损失往往大于小一档模型的精度差。

环境变量速查与调优顺序

动手顺序建议：先定驻留（免费）、再定量化与层数（一次性）、然后按并发压力开并行（需测量）、最后才考虑上下文手段（滚动摘要属于应用层设计）。每改一项跑一次 5.2 的探测脚本记录基线，避免"调了八个参数，不知道哪个在起作用"。

最后补一条容易被忽略的"软调优"：提示词本身就是性能参数。上下文越长，预填充越慢、KV 缓存越大，把系统提示词从两千字压到三百字，长会话的每轮延迟都会受益；要求"回答不超过五行"这类输出长度约束，直接减少解码工作量。先做这类零成本的收敛，再动环境变量，事半功倍。同理，让模型"先列要点再展开"的两段式生成虽然多一次调用，但每段的上下文都更短，总耗时往往反而更低，这是很多人实测后才肯信的反直觉结论。

性能之外，下一章转向"拿模型做事"：RAG 检索增强、Agent 工作流与多模态三个高级应用场景的完整落地路径。