在本地部署大模型时，单次推理顺畅并不代表系统能够承受多人同时访问。Ollama 进入高负载后，常见现象包括首 Token 延迟上升、请求长时间排队、显存突然耗尽，以及服务返回 503。要解决这些问题，不能只追求“并发数越大越好”，而要同时控制入口流量、模型并行度、上下文长度和模型驻留数量。🚀
一、先理解 Ollama 的并发处理机制
Ollama 的并发主要分为两个层次：一是同时加载多个模型，二是同一个模型并行处理多个请求。当内存或显存不足以加载新模型时，请求会进入队列，等待已有模型空闲并被卸载。对于 GPU 推理，新模型通常需要能够完整放入可用显存，才适合与其他模型同时驻留。具体机制可参考 Ollama 官方 FAQ。
这意味着吞吐瓶颈不一定来自算力不足。如果业务频繁切换模型，模型加载与卸载可能占用大量时间；如果同一模型并发过高，上下文缓存又会快速消耗显存。因此，优化前应先判断业务属于“单模型高并发”还是“多模型混合调用”。
二、使用关键参数建立第一道保护
- OLLAMA_NUM_PARALLEL：控制每个模型能够同时处理的最大请求数。提高该值可能增加吞吐，但内存需求会随并行数和上下文长度增长。
- OLLAMA_MAX_QUEUE：控制服务繁忙时允许排队的最大请求数。队列已满后，新增请求会被拒绝，而不是无限等待。
- OLLAMA_MAX_LOADED_MODELS：限制同时驻留的模型数量，可减少多模型争抢显存导致的频繁换入换出。
- OLLAMA_KEEP_ALIVE：控制模型在请求结束后继续驻留的时间，适合减少热门模型的重复加载。
- OLLAMA_CONTEXT_LENGTH：设置默认上下文长度。上下文越大，占用的内存通常越多，不应为了“保险”盲目拉高。
在 Linux systemd 环境中，可以执行 systemctl edit ollama.service，在 Service 配置段写入环境变量，例如将并行数设为 2、队列上限设为 64，并限制同时加载的模型数量。保存后执行 systemctl daemon-reload 和 systemctl restart ollama。参数名称和平台配置方式应以 官方配置说明 为准。
三、不要把 Ollama 内部队列当成流量治理系统
内部队列只能防止请求立即失败，却无法识别用户优先级、任务成本和业务超时。更稳妥的方案是在 Ollama 前增加应用层队列或反向代理，主动限制同时进入推理阶段的请求数量。这样可以在请求尚未占用模型资源前完成削峰。🛡️
- 为每个用户或 API Key 设置并发上限，避免单个调用方占满全部槽位。
- 为请求设置最大等待时间，超时后及时返回“系统繁忙”，不要让连接无限挂起。
- 将短对话、长文生成、Embedding 等任务拆分到不同队列，防止长任务阻塞轻量请求。
- 对可重试请求采用指数退避，并加入随机抖动，避免服务恢复时出现重试风暴。
- 设置整体队列长度和单用户队列长度，形成双重背压。
队列的目标不是容纳所有请求，而是在资源边界内维持可预测的等待时间。
四、通过上下文和输出长度换取有效吞吐
同一模型的并行请求会共同增加上下文相关的内存需求。官方说明指出，所需内存会受到 OLLAMA_NUM_PARALLEL 与 OLLAMA_CONTEXT_LENGTH 共同影响。因此，将并行数从 1 提高到 4，并不意味着吞吐一定提高到原来的四倍，反而可能因为显存不足而发生 CPU 卸载或请求排队。
实战中应按接口设置合理的输入上限和输出上限。例如，普通问答无需使用超长上下文；摘要任务应在进入模型前清理无关历史；开放式生成则要限制最大输出 Token。还可以对固定系统提示词进行统一管理，减少重复、冗长的提示内容。上下文配置以及显存影响可查看 上下文长度文档。
五、让热门模型保持驻留，减少冷启动
如果请求集中在一个主模型上，可适当延长 OLLAMA_KEEP_ALIVE，避免模型刚卸载就再次加载。对于低频模型，则不宜长期驻留，以免挤占热门模型所需的显存。多模型业务可以根据访问频率划分实例，让不同 Ollama 进程或不同 GPU 分别服务固定模型，减少动态切换。
运维时可使用 ollama ps 检查模型是否完全运行在 GPU 上。若 PROCESSOR 显示模型部分落在 CPU，通常意味着显存规划需要调整。此时优先减小上下文、降低并行度或更换更小的量化模型，而不是继续增加队列长度。
六、用指标找到真实瓶颈
Ollama API 响应提供 total_duration、load_duration、prompt_eval_count、prompt_eval_duration、eval_count 和 eval_duration 等指标，流式请求会在最终完成片段中返回相关数据，详见 API 使用指标文档。
- load_duration 偏高：模型冷启动或频繁换入换出，应优化驻留策略。
- prompt_eval_duration 偏高：输入过长，应缩短上下文或清理历史消息。
- eval_duration 持续增长：生成速度受到模型规模、硬件或并发竞争影响。
- 队列等待时间偏高：入口并发超过稳定处理能力，应限流、扩容或拆分任务。
- 503 数量增加：队列已接近或达到上限，需要检查突发流量与重试策略。
七、推荐的压测与调参顺序
- 固定模型、上下文长度和输出长度，先测单并发基线。
- 逐步增加并发数，记录吞吐、首 Token 延迟、整体延迟和显存占用。
- 找到延迟开始明显恶化的位置，将生产并发上限设置在拐点之前。
- 模拟突发流量，检查队列是否能够削峰，以及超时和拒绝是否符合预期。
- 最后再测试多模型切换，确认模型加载不会拖垮主业务。
压测请求应尽量接近真实业务，特别是输入长度、输出长度和流式响应方式。只用一句短提示测试出的并发能力，通常不能代表长文总结或代码生成场景。📊
总结
Ollama 高负载优化的核心，是让请求量始终处于硬件能够稳定处理的范围内。先通过 OLLAMA_NUM_PARALLEL、OLLAMA_MAX_QUEUE 和模型驻留参数建立资源边界，再利用应用层限流、分级队列、超时控制和重试退避管理流量，同时持续观察加载耗时、Token 处理速度、队列等待和显存状态。真正有效的吞吐优化，不是把并发参数调到最大，而是在吞吐、延迟、稳定性和资源成本之间找到可持续的平衡点。
