Ollama

一句话定位

Ollama 是面向个人本地环境的模型管理平台：下载、存储、版本管理和 API 服务 GGUF 模型，底层推理通常由 llama.cpp 承担。

它主要负责什么

模型 pull/push/list/delete 等生命周期管理。
统一本地 REST API（OpenAI 兼容接口）。
封装 llama.cpp 后端，降低启动门槛。
Modelfile 定制 prompt/system 参数。

它不负责什么

不自己定义新的量化编码格式。
不做集群级 serving：没有多副本调度、GPU 池化、autoscaling。
不替代 vLLM/SGLang 在高并发场景的角色。

在系统中的位置

用户/应用
 ↓
Ollama API（管理 + 推理入口）
 ↓
llama.cpp（底层推理引擎）
 ↓
本地 CPU/GPU

与类似工具比较

工具	定位	主要区别
llama.cpp	推理引擎	更细粒度控制、更早获得新量化支持
vLLM	服务端高并发	多用户吞吐优先，非本地便捷性优先

选择边界与排错

Ollama 把“模型文件、默认参数、API 进程和本地设备”收进一个易用入口，适合个人实验、桌面应用和低并发开发。它的便利来自封装，因此遇到性能或兼容问题时要沿链路下钻到 llama.cpp、GGUF、量化和设备 offload，而不是只调 API 参数。

排错顺序：确认实际模型 digest 与 context 参数 → 查看 CPU/GPU offload 和 batch → 观察首 token/生成速度与内存 → 再决定是否迁移到 vLLM / SGLang。

Ollama 的便利具体来自哪一层

Ollama 把“模型制品”和“运行配置”绑定起来：模型名解析到一个 digest，Modelfile 再提供基础模型、system prompt、模板和默认参数，API 进程负责加载、驻留与卸载。这样桌面应用不需要自己拼接 tokenizer、chat template 和后端启动参数；但也意味着调试时必须从模型名下钻到实际 digest、Modelfile 和底层 llama.cpp 参数，不能只看客户端请求体。

一次请求大致经历：

model name
→ digest / Modelfile
→ 模型是否已驻留（load/keep-alive）
→ tokenizer + template
→ llama.cpp prompt eval
→ decode + stream
→ keep-alive 到期或内存压力触发卸载

首 token 很慢，可能是冷加载、磁盘读取或 prompt eval，而不是 decode kernel；后续 token 很慢，才需要去看量化、offload、线程和 KV。多模型交替使用时，驻留策略会在“避免重复加载”和“释放显存给当前模型”之间取舍，模型切换时间应单独计入成本。

什么时候它不该继续留在生产路径

个人开发、桌面助手、离线脚本和低并发内网服务适合使用 Ollama，因为模型分发和 API 封装本身就是主要价值。若需求变成租户配额、请求优先级、多个副本、跨节点故障转移、精细 TTFT/TPOT SLO 或按 token 计费，Ollama 的本地平台抽象会遮住必须控制的调度状态；此时迁移到 vLLM / SGLang 并由上层 serving 管理，通常比继续包装 Ollama 更可解释。

API 兼容不等于行为兼容

即使客户端能用 OpenAI 风格 endpoint，默认模板、stop 条件、采样参数、tool calling 和流式事件仍可能不同。迁移前保存真实请求与完整响应（含 finish reason、usage、错误），用同一 digest 或明确记录模型差异做回归；否则看似“接口兼容”，实际质量和延迟变化无法归因。