Ollama 本地部署与管理¶

Ollama 用于在本机或轻量服务器下载、运行和管理模型。它把模型拉取、运行、量化模型管理和本地 API 封装为简单命令，适合开发验证、个人知识库和低到中等并发的内部工具。

什么时候用 Ollama¶

适合：开发人员本机、PoC、少量用户的局域网服务、快速切换不同模型、使用 GGUF/Modelfile 定制行为。

不适合：大量并发、严格的 P95 延迟/SLA、需要深入调度多卡高吞吐的生产推理平台。这些场景优先评估 vLLM 或其他专用服务引擎。

基本使用¶

# 拉取并运行模型
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# 查看本地模型、当前已加载模型
ollama ls
ollama ps

# 停止模型，释放内存
ollama stop qwen2.5:7b

ollama ps 的 PROCESSOR 能帮助判断模型是在 GPU、CPU，还是 CPU/GPU 混合加载。模型只有完全进入 GPU 显存时，通常才能获得更好的响应速度和并发能力。

Docker 部署示例¶

Linux NVIDIA GPU 主机需要 Docker 可访问 GPU。以下示例将模型卷持久化，并把端口只绑定在本机；如需对外提供服务，应通过反向代理、鉴权和网络策略暴露。

docker run -d \
  --name ollama \
  --restart unless-stopped \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

docker exec -it ollama ollama run qwen2.5:7b

如果使用系统服务，Linux 上可通过 systemctl status ollama 确认服务状态；修改环境变量后需要按部署方式重启服务。

用 Modelfile 固化行为¶

Modelfile 不会训练新模型，而是以基础模型、系统提示词、参数、模板或 LoRA Adapter 创建一个可复用的本地模型条目。

FROM qwen2.5:7b
PARAMETER temperature 0.2
PARAMETER num_ctx 8192
SYSTEM """
你是内部技术助手。只基于提供的资料回答；不确定时明确说明。
"""

ollama create ops-assistant -f Modelfile
ollama run ops-assistant
ollama show --modelfile ops-assistant

将 Modelfile 提交到 Git；不要把 API Key、真实密码或业务敏感上下文直接写进去。Modelfile 官方参考

关键资源参数¶

项目	影响	建议
上下文长度	越长可读取更多历史/RAG 内容，但需要更多内存。	按任务设置，不要因模型支持长上下文就默认拉满。
并行请求	同时处理更多用户，但上下文内存会随并行数增长。	先压测，再调整 `OLLAMA_NUM_PARALLEL`。
模型常驻时间	减少重复加载带来的首次响应慢，但占用内存。	高频模型可延长 `OLLAMA_KEEP_ALIVE`；低频模型及时卸载。
同时加载模型数	方便多模型服务，但争抢 GPU/内存。	设置 `OLLAMA_MAX_LOADED_MODELS`，避免峰值 OOM。
模型目录	模型文件通常很大。	用 `OLLAMA_MODELS` 放到有足够容量的受控数据盘。

Ollama 的并行请求会扩大上下文内存占用：所需 RAM 与 OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH 相关。增加上下文或并发前，要看 ollama ps、GPU 显存和真实响应延迟，而不是只看是否能启动。官方 FAQ

常见问题与排查¶

现象	检查与处理
响应很慢	`ollama ps` 看是否落到 CPU 或混合卸载；检查模型大小、上下文和并发。
首次请求慢	模型正在加载；对高频模型用 `keep_alive` 预热，但注意内存占用。
OOM / 服务被杀	降低上下文或并发，减少同时加载模型，选更小/更低量化模型。
浏览器/其他主机无法访问	默认应仅本机使用；如确需开放，设置监听地址/反向代理并加鉴权与访问控制。
模型占满磁盘	`ollama ls` 清点模型；删除不用的模型，或将 `OLLAMA_MODELS` 迁移至数据盘。

与 RAG 的组合¶

Ollama 可以运行生成模型，也可以运行 Embedding 模型；但 RAG 的文档解析、向量库、检索、重排和评估仍需要独立设计。小型本地知识库可用 Ollama + 向量库快速验证；并发或长上下文需求增长后，再将生成服务平滑迁移到 vLLM。