当 Ollama 从个人电脑上的模型试用工具变成面向团队的推理服务后，“接口能返回结果”已经不足以说明系统运行正常。响应突然变慢，可能来自模型冷加载、上下文增长、并发排队、显存不足、CPU 回退或 GPU 降频。要快速区分这些问题，需要把 Ollama 的推理数据、主机资源和 GPU 状态统一采集到 Prometheus，再通过 Grafana 建立可关联分析的监控视图。🔍
一、先确定监控架构
一套实用架构可以分成四层：业务请求经过应用或指标代理访问 Ollama；指标代理把推理结果转换成 Prometheus 指标；Node Exporter、cAdvisor 和 DCGM Exporter 分别采集主机、容器及 NVIDIA GPU 数据；Prometheus 定时抓取所有指标，Grafana负责查询、展示和告警。
Ollama API 响应本身包含推理用量字段，但部署时不要默认其服务端已经提供 Prometheus 格式的通用指标端点。更稳妥的做法是在调用层埋点，或使用经过审查的社区指标代理。
Ollama 的生成与对话接口会返回 total_duration、load_duration、prompt_eval_count、prompt_eval_duration、eval_count 和 eval_duration，时间字段单位为纳秒；流式请求的统计值位于 done 为 true 的最后一个数据块中。字段定义可查看 Ollama 用量文档。这些数据足以计算总延迟、加载耗时、输入处理速度和输出生成速度。
二、设计真正有用的推理指标
建议按照请求、延迟、吞吐和资源四个维度设计指标：
- 请求量：使用 Counter 记录成功、失败、超时及取消次数，并按 model、endpoint、status 等低基数标签区分。
- 请求延迟：使用 Histogram 记录总耗时、模型加载耗时、提示词处理耗时和生成耗时，以便计算 P50、P95、P99。
- Token 吞吐：累计 prompt_eval_count 与 eval_count，并用 eval_count 除以 eval_duration 得到输出 Token 每秒。
- 并发与排队：使用 Gauge 记录正在执行的请求数和应用队列长度，区分“模型算得慢”与“请求等得久”。
- 资源状态：采集 CPU、内存、磁盘读取、GPU 利用率、显存占用、温度和功耗。
标签中不要放 prompt、用户 ID、会话 ID 或请求 ID，否则会造成时间序列基数快速膨胀，也可能泄露敏感内容。延迟分布优先使用 Histogram；其桶可以在 Prometheus 中聚合并计算分位数，原理可参考 Prometheus Histogram 文档。📊
三、完成 Prometheus 接入
指标代理需要暴露一个 /metrics 地址，并把 Ollama 返回的纳秒转换为秒。对于流式响应，代理必须持续透传内容，只在读到最终数据块后更新计数器和直方图，避免破坏首 Token 体验。生产环境还应记录请求开始时间，从而补充客户端观察到的端到端延迟和首 Token 延迟。
Prometheus 的抓取配置至少包含 ollama-exporter、node-exporter 和 dcgm-exporter 三个任务。抓取间隔可先采用 15 秒或 30 秒，再根据故障发现速度与存储成本调整。配置完成后，应在 Prometheus Targets 页面确认目标状态为 UP，并直接检查 /metrics 中的计数器是否随推理请求增长。若使用 Docker Compose，容器之间应通过服务名通信，不能把 localhost 误认为宿主机或其他容器。
没有条件开发代理时，可以评估 Ollama Metrics Sidecar 等社区方案，但上线前应检查维护状态、镜像来源、指标语义、流式响应兼容性和安全边界，测试后固定版本，不建议直接长期使用 latest 标签。
四、构建 Grafana 诊断看板
Grafana 中先添加 Prometheus 数据源，再建立“概览、推理、资源、模型”四行面板。概览展示 QPS、错误率、P95 延迟和当前并发；推理行展示模型加载时间、输入 Token 每秒、输出 Token 每秒及 Token 数量；资源行并排展示 CPU、内存、GPU 利用率、显存和温度；模型行按 model 对比延迟与吞吐。Grafana 已内置 Prometheus 数据源，配置方式可参考 Grafana 官方说明。
经典直方图计算 P95 时，可使用 histogram_quantile(0.95, sum by (le, model) (rate(ollama_request_duration_seconds_bucket[5m])))。请求速率可使用 sum(rate(ollama_requests_total[5m]))，错误率则用失败请求速率除以全部请求速率。查询窗口应大于抓取间隔，避免曲线断点和短时抖动。
五、用指标关联定位瓶颈
- load_duration 升高：通常先检查模型是否频繁装卸、keep_alive 设置是否过短，以及显存是否容纳多个模型。
- eval_duration 上升且 GPU 利用率接近饱和：说明生成阶段是主要瓶颈，可降低并发、缩短输出上限，或选择更适合当前硬件的模型与量化版本。
- GPU 利用率不高但 CPU 很忙：检查是否发生部分 CPU 推理、预处理开销过高或内存带宽受限。
- 显存接近上限并伴随延迟抖动：重点排查上下文过长、多模型常驻和并发请求造成的显存压力。
- 队列增长而单次推理耗时稳定：计算能力未必异常，真正问题是到达速率超过服务能力，应实施限流、排队上限或横向扩展。
- GPU 温度升高、时钟下降且吞吐持续降低：可能存在散热或功耗限制，需要结合 DCGM 指标检查，而不是仅重启 Ollama。
六、设置可落地的告警
告警阈值不要照搬他人环境，应先基于同一模型、量化方式、上下文长度和硬件建立基线。建议覆盖服务不可达、持续错误率上升、P95 延迟偏离基线、队列持续增长、显存逼近容量、GPU 高温以及抓取目标失联。告警需要设置持续时间，避免模型首次加载或短时批量请求触发无效通知。⚠️
总结
Ollama 性能监控的关键不是堆积面板，而是建立“请求负载—推理阶段—系统资源”的因果链。通过调用层提取 Ollama 用量字段，使用 Prometheus 保存可聚合指标，再在 Grafana 中关联延迟、Token 吞吐、队列和 GPU 状态，就能把“推理变慢”进一步定位为冷加载、生成饱和、资源回退、显存压力或并发排队。最后用真实压测建立基线并逐步调整告警，监控体系才能真正服务于容量规划和故障排查。✅
