ollama/ollama: 本地模型运行时与资源治理¶
不要把 Ollama 简单看作一个下载模型的工具。在架构视野中，它是本地模型 Serving 的运行时（Runtime），负责解决模型拉取、生命周期管理、GPU/内存调度与统一接口暴露。
1. 核心运行时链：从 API 到 Runner¶
本地 Serving 的挑战不在于模型是否会回答，而在于资源与模型状态的同步。
- 模型元数据管理 (Manifest)：管理本地模型库的版本、分层（Layers）与配置。工程直觉：确保“模型已存在”是调用链的第一步，避免请求时才触发 GB 级的静默拉取。
- 加载与缓存 (Loader/Cache)：决定权重何时装载进内存/显存。理解冷启动延迟：第一次请求往往伴随着模型加载过程，P95 延迟会因此飙升。
- 执行后端 (Runners)：针对不同的硬件（CPU/Metal/CUDA）调用对应的推理引擎（如 llama.cpp）。它是性能受力点，直接决定了吞吐上限。
2. 统一 API 的防腐价值¶
Ollama 提供了类 OpenAI 的 REST API 接口。
- 屏蔽底层细节：宿主应用无需关心底层用的是什么计算框架或量化格式。
- 流式输出 (Streaming)：原生支持流式响应，方便接入后端的长连接处理链路。
3. 工程防腐：本地 Serving 的现实与幻想¶
- 资源竞争：本地运行时不像云端可以无限弹性。多模型并发请求会导致显存溢出（OOM）或频繁的权重换入换出（Swapping），这在架构设计中必须作为硬约束。
- 治理缺失：Ollama 解决了“能跑通”，但不负责“权限、审计、多租户”。这些逻辑必须由宿主系统在调用 Ollama 之前闭环。
4. 常见误区与失效模式¶
- 盲目追求大参数：在显存不足的环境下硬跑 70B 模型，导致 Runner 频繁退化到 CPU 推理，系统时延不可控。
- 忽略冷启动开销：在对时延敏感的同步请求中，没有预热（Preload）机制，导致用户体验断崖式下跌。
- 日志黑盒：宿主只看到一个
500 Internal Server Error，而没能区分是“模型未找到”、“资源不足”还是“推理超时”。
5. 排查顺序：从资源到效果¶
- 查模型状态：模型是否已完整下载？版本是否对应？
- 查资源占用：当前显存/内存是否打满？Runner 是否因为并发过高而在排队？
- 分析首字延迟 (TTFT)：高延迟是因为模型正在加载（加载耗时），还是因为推理本身慢（推理耗时）？
- 查接口契约：API 参数（如
num_predict,stop）是否被底层 Runner 正确接住并执行？
结论： 本地模型运行时是“受限环境”下的权衡产物。好的设计应通过预热机制对抗冷启动，通过资源监控预防 OOM，并将本地模型视为一个随时可能不可用的、带状态的后端服务。