复读机的诅咒：五百错误的三日捕获

炼丹炉最凶险的事故，从来不是炉灭，是炉火燃着，丹药却重复着同一句咒语。

十月三日，“她的相册”二期工程——照片内容索引——正式点火。全库 736 张照片等着被打上语义标签，让”发张穿裙子的”这种点名成为可能。没人料到，这一仗会是一场跨越三日、三易模型的长征。

一、安装与第一滴血

按老规矩手动 blob 下载（绕开代理的假 IP 与 Ollama 的安检），qwen2.5vl:7b——5.97GB、五层加一配置——哈希逐一过堂。冒烟测试艳惊四座：两张照片，标签精准（“女生，校服，机场，排队”/“女人，内衣，胸部”），尺度判定正常工作，86 秒首张、12 秒续张。736 张，预计两小时半。 ascent 已经开始。

然后时间到第 16 张，全线 timeout。

二、显存的债

真相：7B 完整需要 13.8GB 显存（含视觉上下文），8G 卡只装下 5.1GB——剩下 8.7GB 溢出到 CPU 内存爬。前三张的快只是模型加载的窗口期。换 qwen2.5vl:3b（3.2GB）——桌面还在挤显存（Chrome、Steam、QQ、Docker、Hermes、Ninja 全在），Ollama 只抢到 5GB，3B 塞进去仍溢出一指节。压上下文到 2048 勉强不溢。

接着换了一批更邪门的错误：500，128 张连爆。 高分辨率照片的图片 token 超出抢救出来的上下文。上下文提到 4096、发送前自动缩图到 1280px——同一批照片还在 500。样本文件本身没问题（78KB、962×1280 的正常 JPEG）。直接复现失败调用，把 500 的响应体打出来——

token repeat limit reached

真凶落网：3B 模型在特定照片上陷入复读机循环——小视觉模型的常见痼疾——被 Ollama 的防复读护栏一刀斩落报 500。

三、参数的牢笼

工程兵不信邪，做了一组决定性实验：对同一张顽固的 2017 年照片换参数（更高温度 + 更小图 + 换提示词）——四种参数组合全部触发同一个复读循环。结论冷酷：这是模型级缺陷，调参救不了。顺带数据还揭示了一桩冤案：7B 当年的”超时”原来是代理栈的幻觉，7B 本身在这张照片上是能干活的。

四、512 像素的破局

真正的破局点来得像个冷笑话：把图缩到 512px，3B 成功标注了此前必败的照片——而且质量极好（“女性自拍，白色校服清纯型，比V手势”）。循环触发器就是高分辨率图片的 token 处理；而打标根本不需要原始分辨率，512px 完全够用。但有极少数照片（2025-06-18 系列）在 512px 下仍触发循环——于是有了最终形态：三级流水线——3B 全量扫 → 高温调参重试败项 → 7B 长超时兜底残兵，全自动链式执行。

收尾还抓到一条暗鬼：一个旧版打标进程居然还活着（早前那次 taskkill 静默失败了），清场重来——修复后第一张，正是此前被宣判死刑的 2017-01-03，7 秒标注成功。

插叙：底线一问

长征途中工程兵还立了一次军威：素材库里有 2014~2016 年的照片，若含她未成年时期的影像，按底线不能进发送池。用户的回答干净利落：那些日期只是凑数的别人的图，全是成年内容——底线问题，问过才能放下。

真实坐标

• 模型：qwen2.5vl:7b（6GB，哈希过堂）与 3b（3.2GB）双版本入 Ollama
• 三里：7B 需 13.8GB 显存（8G 卡装 5.1GB）→ 3B 溢出一指节（桌面应用分显存）→ 500 潮
• 真凶：token repeat limit reached——3B 在特定照片陷复读循环，Ollama 防复读护栏斩落
• 实验：四种参数组合全败 → 模型级缺陷；7B 当年”超时”系代理幻觉
• 破局：512px 缩图（循环触发源是高分辨率 token 处理；打标无需原分辨率）
• 终态：三级流水线（3B 全量 → 高温重试 → 7B 兜底）；修复后 2017-01-03 七秒过堂
• 底线：2014~2016 照片经确认全为成年内容，无排除；插件的”重新打标”后门保留