背景：我在搭一套 SDN 运维知识平台（RAG），需要在内网服务器用 Ollama 跑一个本地大模型做问答。模型选了 qwen2.5:7b-instruct。这篇把"怎么看它的日志""怎么量它的性能"，以及"这个模型到底是什么量级"一次性讲清楚——都是踩过、测过的真实数据，不是文档搬运。

一、先说结论

qwen2.5:7b-instruct 是阿里通义千问开源系列的"中杯"：70 亿参数、指令微调版、4bit 量化后 4.7GB，属于"单机就能跑"里最甜点的档位。在 RAG 架构里它只负责"读证据、组织答案"，不需要它背知识，所以 7B 是够用且合理的搭配。当前真正的瓶颈不是模型选择，而是纯 CPU 推理速度。

二、我们的部署实况（先摸清家底）

模型跑在 192.168.118.218，Ollama 以 systemd 服务托管，日志走 journald：

# 服务形态
systemctl is-active ollama    # active
systemctl is-enabled ollama   # enabled
# 关键环境变量
OLLAMA_HOST=0.0.0.0:11434
OLLAMA_MAX_LOADED_MODELS=1    # 同时只能驻留 1 个模型
OLLAMA_KEEP_ALIVE=10m         # 10 分钟不用就卸载
# 模型
ollama list
# qwen2.5:7b-instruct   4.7 GB   2 days ago

两个关键点：

• 无 GPU，纯 CPU 推理（16 核 / 62GB 内存）。所以后面所有性能数字都是 CPU 水平，别拿 GPU 机器的数据来比。
• ollama ps 当前是空的——因为 KEEP_ALIVE=10m，模型没被加载时就不在内存里。每次第一个问题要付一次冷加载时间。

三、怎么看日志

Ollama 的日志主要有三层，从外到内：

1. 服务日志（主路径，systemd 托管）

journalctl -u ollama -f                    # 实时滚动
journalctl -u ollama -n 100                # 最近 100 条
journalctl -u ollama --since "30 min ago"  # 最近半小时
journalctl -u ollama --since today --no-pager | grep -i error

日志里三类信息最有价值：

• 每个请求一行的 GIN 访问记录，自带 HTTP 总耗时，例如：

  POST "/api/generate" | 9.69s
  

• 模型加载过程：loading model via llama-server → load_tensors …，能看到冷加载耗时。

• 请求结束后的性能明细行（默认不输出，见下）。

2. 更细的调试日志

默认日志里没有逐 token 的性能明细。想要 llama_perf_context_print 这类细粒度行，开 debug：

systemctl edit ollama          # 加 Environment=OLLAMA_DEBUG=1
systemctl restart ollama        # 会中断服务几十秒，按需开启

3. 系统自己视角的日志（谁调了、花多久）

我们这套中枢（Hub）本身也记调用：216 上的 data/ops.log + data/usage/*.jsonl，里面是每次模型调用的延迟、token、成败。直接看模型管理页「运行状态 → 调用统计」页签，有 p95、失败率、按模型汇总——这是"调用方视角"最干净的监控。

四、怎么看性能

性能数据有三个视角，互相印证。

1. 驻留状态：ollama ps

显示当前加载了哪个模型、占多少内存、跑在 CPU/GPU、还能驻留多久（UNTIL 列）。空 = 没加载。

2. API 自带计时（最准的细粒度数据）

对 /api/generate 或 /api/chat 发非流式请求，响应末尾自带 4 个 duration + 2 个 count：

curl -s http://localhost:11434/api/generate \
  -d '{"model":"qwen2.5:7b-instruct","prompt":"用一句话介绍SDN","stream":false,"options":{"num_predict":60}}'

我实测了一次（非流式，num_predict=60）：

换算公式：decode 速度 = eval_count / eval_duration，prefill 速度 = prompt_eval_count / prompt_eval_duration（注意单位都是纳秒）。

3. 系统资源层

top -p $(pgrep -f 'ollama serve')   # CPU / 内存占用
free -h                             # 内存大盘

无 GPU，所以没有 nvidia-smi 可看——这是纯 CPU 机器的常态。

五、这个模型到底是什么量级

名字拆解

规模阶梯（Q4 量化后体积 / 运行内存）

参数量大致每上一个数量级台阶，能力上一档、部署成本也上一档。7B 正好卡在"第一台能认真干活的机器"：

运行内存 ≈ 模型体积 × 1.3（含上下文 KV cache）。14B 起需要专用显卡，32B/72B 进入服务器领域。

能力分布（定性评分 1–5，参考公开评测大致档位）

参数量不是均匀提升所有能力——7B 在"理解 + 表述"上已经接近大模型，但"推理 + 代码"差距明显：

六、为什么 7B 在这套 RAG 架构下够用

这是最关键的一点，也是"小模型 + 检索"对抗"大模型靠记忆"的经典设计：

• 你的知识根本不在模型里——在向量库（Qdrant，我们这边是 815 个语料 chunk）里。

• 模型的活是"读检索到的证据 → 组织成通顺回答"，也就是上表第一、二行（中文理解/摘要、RAG 答案组织），这正是 7B 的强项。

• 系统还做了规则兜底模式（rules）：即使模型不可用，也能返回带章节定位的证据清单，系统不崩。

  所以选 7B 不是"将就"，而是架构上把对参数的要求降下来了。

七、瓶颈与升级路径

当前实测 CPU decode 8.5 tok/s，一段 200 字答案要 15–20 秒——速度瓶颈在硬件不在选型。升级顺序建议：

1. 零成本：把 OLLAMA_KEEP_ALIVE 调大（如 30m 或 -1 常驻），省掉每次首问 5.9s 冷加载。218 有 62GB 内存，常驻 5GB 毫无压力。
2. 上 GPU：同模型上 12GB+ 显卡（如 3060 / 4070），速度翻数倍（通常 30–80 tok/s）。
3. 换大模型：qwen2.5:14b-instruct（量化后 ~9GB），推理和多轮明显更强；但 CPU 上会更慢（约减半），所以建议先 GPU 再换大模型。

改动 systemd 配置需 systemctl restart ollama，会中断服务几十秒——生产环境按计划确认后再动。

八、总结（要点速览）

• 部署：218 上 Ollama 为 systemd 服务，无 GPU、纯 CPU；KEEP_ALIVE=10m、MAX_LOADED_MODELS=1；模型 4.7GB 是 4bit 量化版。

• 看日志：journalctl -u ollama -f 看实时；想看逐 token 性能开 OLLAMA_DEBUG=1；系统侧用中枢 data/usage/*.jsonl 或模型管理页「调用统计」页签。

• 看性能：ollama ps 看驻留；API 非流式返回自带 load/prefill/decode 三段耗时；系统层用 top/free。

• 实测基线：冷加载 5.85s、prefill ≈68 tok/s、decode ≈8.5 tok/s、端到端 9.7s（纯 CPU）。

• 模型量级：7B = 70 亿参数、单机甜点档；强在理解/摘要/RAG 组织，弱在推理/代码。

• 够用原因：RAG 架构让知识在向量库、模型只做"读+组织"，配合 rules 兜底，7B 完全胜任。

• 升级优先级：先 KEEP_ALIVE 常驻降冷启 → 再上 GPU 提速 → 最后考虑 14B。

  一句话：7B 是"内网单机可部署"的入门甜点，配 RAG 做知识问答是标准实践；你现在卡在 CPU 速度，不在模型选型。