在本地运行大模型时，“能启动”并不等于“运行高效”。同一个模型、同一套硬件，仅调整上下文、批处理和 CPU 线程配置，就可能改变首字延迟、提示词处理速度、内存占用与并发稳定性。本文围绕 NUM_CTX、NUM_BATCH 与 NUM_THREAD，给出一套可复现、不过度依赖经验值的 Ollama 调优方法。🚀
一、先明确三个参数分别优化什么
1. NUM_CTX：控制上下文窗口
num_ctx 决定模型一次推理能够访问的上下文 token 数量。窗口越大，越适合长文档摘要、代码分析、知识库问答和多轮对话，但同时需要更多内存或显存。Ollama 官方也明确指出，增大上下文会提高模型运行所需的内存，具体配置还应考虑模型自身支持的最大上下文长度，参见 上下文长度说明。
因此，num_ctx 并不是越大越好。普通聊天若实际输入很短，盲目配置超长窗口只会增加资源压力；处理长文档时设置过小，则可能导致较早内容被截断或模型无法充分利用完整提示词。更稳妥的做法是从任务需要出发，例如先用 4096 或 8192 进行测试，再根据真实输入长度逐步上调。📚
2. NUM_BATCH：影响提示词处理吞吐
num_batch 可以理解为提示词预填充阶段一次处理的 token 批量。适当增大该值，通常有利于提升长提示词的处理效率和硬件利用率；但批量越大，运行时临时内存需求也可能越高，显存紧张时容易出现加载失败、内存不足或系统抖动。
调节时应重点观察“提示词处理速度”，而不能只看回答阶段每秒生成多少 token。对于短对话，增大 num_batch 的收益可能并不明显；对于 RAG 检索结果拼接、长代码输入和文档总结，它通常更值得优化。建议采用 128、256、512 等递增档位压测，但不要把这些数字视为所有设备通用的固定答案。⚙️
3. NUM_THREAD：决定 CPU 侧并行度
num_thread 控制推理使用的 CPU 线程数，主要影响纯 CPU 推理以及部分由 CPU 承担的计算。线程太少会让处理器利用不足，线程太多则可能引入上下文切换、缓存竞争和内存带宽压力，因此逻辑线程数并不一定是最佳值。
实践中可以先从 CPU 物理核心数附近开始测试，再分别降低或提高线程数。若模型主要由 GPU 执行，num_thread 的影响通常没有纯 CPU 场景那么明显，此时应同时确认模型是否发生 CPU 卸载。可使用 ollama ps 查看 PROCESSOR、CONTEXT 等运行信息，避免把“模型部分落到 CPU”误判为线程配置问题。🔍
二、用 Modelfile 固化配置
如果希望每次启动都使用相同参数，可以创建 Modelfile。其核心内容可写为：
FROM 你的模型名称
PARAMETER num_ctx 8192
PARAMETER num_batch 512
PARAMETER num_thread 8
保存后执行 ollama create 模型别名 -f Modelfile，再通过 ollama run 模型别名 启动。需要检查最终配置时，可执行 ollama show 模型别名 --modelfile。Modelfile 的 PARAMETER 语法与 num_ctx 定义可查看 Ollama 官方 Modelfile 文档。
如果通过 API 调用模型，也可以在请求体的 options 对象中传递运行参数。官方接口还会返回 prompt_eval_count、prompt_eval_duration、eval_count 和 eval_duration 等统计字段，可用于区分提示词处理时间与文本生成时间，详见 Generate API 说明。
三、推荐的阶梯式调优流程
- 固定变量：保持模型、量化版本、提示词、输出长度和后台负载不变。
- 先调 num_ctx：以能够覆盖真实任务为目标，不直接追求模型宣称的最大窗口。
- 再调 num_batch：从较保守的批量开始递增，记录提示词处理耗时和峰值显存。
- 最后调 num_thread：围绕物理核心数测试多个档位，观察吞吐、延迟与 CPU 占用。
- 重复测试：区分首次模型加载与已加载状态，避免缓存和加载时间干扰结果。
每组配置至少记录首字延迟、提示词处理速度、生成速度、内存或显存峰值以及是否出现异常。若只有单用户交互，应优先降低响应延迟；若是批量摘要或 API 服务，则更应关注整体吞吐与稳定性。📊
四、常见误区与排查重点
- 上下文直接拉满：模型支持长上下文，不代表当前硬件适合始终按最大值运行。
- 批量越大越快：超过硬件承载范围后，收益会下降，还可能触发内存不足。
- 线程等于逻辑核心数：超线程并不保证线性加速，物理核心数附近往往更值得优先测试。
- 只测一次：模型加载、温度、后台进程和输入长度都会造成结果波动。
- 只看生成速度：长提示词任务还必须比较 prompt evaluation 阶段，而不是只关注输出 token 速度。
调优的核心不是寻找一组“万能参数”，而是在任务长度、响应延迟、吞吐量和资源上限之间找到可持续的平衡点。
总结
NUM_CTX 决定模型能处理多长的上下文，NUM_BATCH 影响提示词批处理效率，NUM_THREAD 调节 CPU 并行度。正确顺序是先确定必要的上下文，再逐步增加批量，最后围绕 CPU 物理核心测试线程数。配合固定测试样本、API 统计字段、系统资源监控和多轮复测，才能得到适合当前模型与硬件的配置。对于 Ollama 性能优化而言，可测量、可回退、可复现，比照搬他人的参数更重要。✅
