三级流水线与显存的归还

每一场远征的终点，都应是一张写着”日常如何维持”的说明书。

十月三日深夜，“她的相册”打标系统跑完全部建设。流水线三级全自动、插件 v1.1 在岗、AstrBot 带着十个插件重启、TG 轮询正常。而收尾前的最后一课，关于显存的借用与归还。

一、赖着不还的房客

工程兵查看机器状态时发现：打标早结束了，视觉模型却仍占着 5.1GB 显存不还。房客为何赖着不走？——打标器为省每张三分钟的重新加载，给请求设了 keep_alive: -1（永不卸载）。恩是效率，罚是打完不走。解法是一计温柔的空请求：keep_alive: "0s"，模型当即归还显存。事后盘点：6.9GB 显存全空、十个插件在岗、全库 1013 项记忆就位。

二、Ollama 的隐式契约

借这起事故，工程兵把 Ollama 最反直觉的一点讲透：它没有”启动模型”这个操作。 机制是——任何客户端往 11434 端口请求”我要用 X 模型”，守护进程发现 X 不在显存里，就自动加载 → 推理 → 用完后等五分钟无人理就自动卸载。加载是隐式的、请求驱动的：她聊天查知识库、打标器认图、App 里闲聊，全部同理，没有人需要手动”开启”一个模型。想看有没有模型在跑，ollama ps 一瞥便知。

三、日常零维护

用户最后一问刁钻而精准：整个项目需要一直开着 Ollama 吗？新增素材会重复打标吗？答案是两份说明书：

Ollama 的分量——守护进程 App 要常开（她聊天时查知识库要用本地 bge-m3 嵌入，Ollama 一关，她的”记忆”就哑了——不报错，只是变笨）；但显存里不需要常驻模型（秒级加载、五分钟空闲自动卸载，平时零负担）。且注意：日常聊天走的根本不是 Ollama——是本地 newapi 网关（3000 端口）转 DeepSeek/GLM 上游。Ollama 只服务两件事：聊天时的知识库嵌入，打标时的视觉模型。

新增素材的流程——丢新照片/视频进素材库两个文件夹，双击 全量打标流水线.bat：Pass 1 用 3B 扫新文件、Pass 2 高温重试败项。会重复吗？绝不。 代码已验证：清单 = 素材库文件名对 tag_index.json 索引键名，对比后只处理没进索引的，已打标的 1013 个自动跳过。顺手还把旧版 打标.bat（指向已淘汰的单扫脚本）升级成 v2 增量版——现在两个 bat 都能用，流水线更全，单段快速增量够日常。

尾声

系统至此满配：日常零维护（聊天走网关）、增量有章可循（丢文件、双击）、记忆全库在线（1013 项）。完全体达成——而”完全体”的真正定义，是主人不再需要理解它如何运转。

真实坐标

• 事故：keep_alive: -1（永不卸载）致打标后视觉模型仍占 5.1GB；keep_alive: "0s" 空请求当即归还；事后 6.9GB 全空
• 机制：Ollama 请求驱动隐式加载（守护进程 11434 → llama-server 子进程），空闲 5 分钟自动卸载（keep_alive 默认值）；ollama ps 观测
• 常开清单：Ollama 守护进程必须常开（bge-m3 服务聊天知识库检索）；显存无需常驻模型；日常聊天走 newapi :3000 不经 Ollama
• 增量：全量打标流水线.bat（3B 全量→高温重试）与 打标.bat（v2 单段增量）；清单=文件名 vs tag_index.json，1013 项已索引自动跳过
• 状态：插件 v1.1 在岗（语义点名+她知照片内容+露骨图害羞话术+热加载）、AstrBot 10 插件重启、TG 轮询正常