在本地运行大模型时，推理卡顿、输出为空、服务突然退出或 GPU 未生效，往往不能只靠“重启试试”解决。Ollama 的日志能够记录请求处理、模型加载、硬件识别和运行时异常等信息。本文将从日志分级、平台配置和排查顺序三个方面，给出一套可直接执行的快速诊断方法。🔍
一、先理解 Ollama 的日志“分级”方式
需要注意的是，Ollama 当前主要通过 OLLAMA_DEBUG 环境变量控制是否输出额外调试信息，并未提供类似部分日志框架那样完整的 TRACE、DEBUG、INFO、WARN、ERROR 自定义等级配置。因此，实际运维中可将日志按用途划分为以下四类，而不是把它们误认为可直接设置的官方日志级别。
- 运行信息：服务启动、监听地址、模型加载和请求处理等常规记录。
- 警告信息：资源不足、部分计算回退、参数不理想或兼容性提示。
- 错误信息：模型文件读取失败、请求失败、端口冲突、运行时崩溃等。
- 调试信息：启用 OLLAMA_DEBUG 后出现的附加细节，适合分析硬件识别和底层推理问题。
日常使用建议保持默认日志输出；只有在故障复现阶段才开启调试模式，问题定位完成后及时关闭，避免大量日志干扰观察。Ollama 的日志位置和调试方法可参考官方故障排查文档。
二、不同系统如何查看与开启日志
Linux 与 systemd 服务
如果 Ollama 作为 systemd 服务运行，可使用以下命令持续观察日志：
journalctl -u ollama --no-pager --follow --pager-end
需要开启调试信息时，执行 sudo systemctl edit ollama.service，在覆盖配置中加入：
[Service]
Environment="OLLAMA_DEBUG=1"
保存后执行 sudo systemctl daemon-reload 和 sudo systemctl restart ollama。修改环境变量后必须重启服务，否则新配置通常不会进入现有进程。Linux 服务配置示例可查看Ollama Linux 文档。
macOS、Windows 与容器环境
macOS 的日志通常位于 ~/.ollama/logs，其中 server.log 主要记录服务端运行情况，app.log 侧重图形应用相关信息。Windows 可在运行窗口输入 explorer %LOCALAPPDATA%\Ollama 打开日志目录；启用调试前，应先从托盘退出正在运行的 Ollama，再设置 OLLAMA_DEBUG 并重新启动应用。
Docker 环境的日志默认进入容器标准输出和标准错误流，可执行 docker logs --follow 容器名称 查看。若通过终端直接运行 ollama serve，日志会直接显示在当前终端。容器反复重启时，应先检查退出前的最后几十行，而不是只查看重新启动后的信息。🐳
三、推理异常的快速排查顺序
- 确认服务是否可用：先检查 Ollama 进程或 systemd 服务状态，再确认默认服务端口是否正在监听。如果日志出现 address already in use，应查找占用端口的进程，避免重复启动多个服务实例。
- 确认模型是否完整：执行 ollama list 检查目标模型是否存在。若拉取中断、存储空间不足或模型文件损坏，可重新拉取模型，并同时检查模型目录权限与磁盘剩余空间。
- 确认模型实际运行位置：推理过程中执行 ollama ps，查看 PROCESSOR 列。该列可以帮助判断模型运行在 GPU、CPU，还是由两者共同承担，具体说明见官方常见问题。
- 核对上下文与内存：长提示词、大上下文和并发请求都会增加显存或内存压力。如果日志在模型加载或分配缓存阶段停止，应先降低上下文长度、减少并发，并测试较小模型。
- 排查硬件运行库：日志中的 CUDA、ROCm、Metal、AVX 或 CPU 回退信息十分关键。GPU 未被使用时，应检查驱动、硬件兼容性、容器设备映射和进程权限，而不是直接认定模型本身有问题。
四、按异常表现定位关键日志
请求成功但输出为空
先判断调用方是否正确读取了流式响应。Ollama API 可能逐段返回内容，如果客户端只等待单个普通 JSON 对象，就可能表现为无输出或解析失败。随后检查请求体中的模型名称、prompt、stream 和 options 参数，并用最简短提示词直接调用，排除上层框架影响。
首次推理很慢或持续卡顿
首次运行可能包含模型加载过程，但持续卡顿通常还需检查内存交换、CPU 占用、显存不足和上下文设置。日志若显示模型部分加载到 CPU，应结合 ollama ps 判断是否发生混合计算。此时可优先选择更小的量化模型、关闭其他占用显存的程序，再比较推理速度。⚙️
服务崩溃或自动重启
重点截取崩溃前后的连续日志，并同步记录 Ollama 版本、操作系统、模型名称、启动方式和硬件信息。Linux 上还可检查 systemd 的退出码与系统内核日志；如果刚升级后才出现异常，应核对当前版本的变更和兼容要求，不要在缺少证据时随意替换驱动或删除全部模型。
五、建立可复用的日志采集规范
建议每次故障都保存五类信息：故障发生时间、完整复现步骤、请求参数、服务日志片段和硬件资源状态。对外提交日志前，应删除提示词中的敏感业务内容、用户名、访问令牌、内部地址和文件路径。日志过长时，可保留异常前后必要上下文，不要只复制最后一条报错，因为真正原因可能出现在更早的模型加载阶段。
总结
Ollama 推理异常排查的核心不是盲目开启全部调试信息，而是按照“服务状态、模型完整性、运行设备、资源容量、请求参数”的顺序逐层缩小范围。默认日志适合日常观察，OLLAMA_DEBUG 适合临时复现复杂故障；结合 journalctl、docker logs、ollama ps 和系统资源监控，通常能够较快判断问题位于服务、模型、硬件还是调用端。✅
