本地模型

description 中位数只有 35 字，最短的原文就是 ForeverBlog——这不是"优化空间"，是搜索展示文案根本不存在。 昨天已经做完 P0-P3 清单里的全部项，今天用户又问「如何提升曝光和流量」。同一个问题重复出现说明昨天的答案没落地。这次换了角度：不再列清单，先用数据定位真实瓶颈。 一、内容层体检（昨天没查的三项） 项目 实测 后果 description 长度 中位数 35 字，最短 6 字 SERP 理想 120-155 字，太短时 Google 自己从正文随机截一段，展示文案不可控 站内链接 0 / 112 全站孤岛，权重不流动 配图 1 / 112 无图搜流量 正文长度 中位数 2897 字 够，不动 标题长度 中位数 43 字，100/112 超 30 字 SERP 会截断，但不建议再改（昨天刚重写一轮） description 这一项最离谱——它本来是唯一能控制"搜索结果里显示哪段话"的地方，却被填成了标题的复制。 二、新工具 tools/articles ...

现象：请求成功，内容为空批量给博客的 112 篇文章重写 meta description，脚本跑了两天都正常。换到本机模型后，日志开始出现这种记录： 123[1/47] 处理中... 耗时 170.4s 返回内容长度: 0 跳过（内容为空） HTTP 200，done: true，没有任何报错，就是 message.content 是空字符串。最迷惑的地方在于它慢——一次请求跑满 170 秒才返回，看着像模型在很努力地工作，结果交了个白卷。 先怀疑的是模型没加载完、显存不够、或者 ollama 版本问题。这几个方向全查了一遍，都不是。 根因：推理 token 和正文共用同一个预算出问题的模型是 thinking 型（具备推理链能力的那种，qwen3 系列、deepseek-r1 系列都属于这一类）。这类模型生成回复时，token 消耗分两段： 推理段（reasoning / thinking tokens）—— 模型内部先想一遍 正文段（content tokens）—— 真正返回给你的答案 关键点：这两段共用 num_predict 这个上限。 当时的请求参数是 ...