Digital Garden

The Three-Stage Pipeline and the Return of VRAM

2026-10-03 · ~5 min read · Ollama · tagging pipeline · VRAM · complete form

The endpoint of every expedition should be a manual saying “how to maintain this daily.”

Late on October 3, the “her album” tagging system finished all construction. The three-stage pipeline fully automatic, plugin v1.1 on duty, AstrBot restarted with ten plugins, TG polling normal. And the last lesson before closing, on borrowing and returning VRAM.

I. The tenant who would not leave

When the engineers inspected the machine state, they found: tagging had long finished, yet the vision model still occupied 5.1GB of VRAM without returning. Why would the tenant refuse to leave? — The tagger, to save three minutes of reload per photo, had set keep_alive: -1 (never unload) on requests. The grace was efficiency; the punishment was not leaving when done. The cure was one gentle empty request: keep_alive: "0s", and the model immediately returned the VRAM. After-count: 6.9GB of VRAM fully clear, ten plugins on duty, the whole library’s 1013 memory items in place.

II. Ollama’s implicit contract

Borrowing this incident, the engineers explained Ollama’s most counter-intuitive point thoroughly: it has no “start model” operation. The mechanism: any client sends a request to port 11434 saying “I want model X,” the daemon finds X not in VRAM, auto-loads → infers → waits five minutes after use with no one touching it, then auto-unloads. Loading is implicit, request-driven: her chat querying the knowledge base, the tagger recognizing images, casual talk in the app — all the same; no one needs to manually “turn on” a model. To see whether a model is running, a glance at ollama ps.

III. Daily zero maintenance

The user’s final question was sharp and precise: does the whole project need Ollama running all the time? Will new assets be re-tagged? The answers were two manuals:

Ollama’s weight — the daemon App must stay on (her chat’s knowledge-base retrieval uses local bge-m3 embeddings; if Ollama stops, her “memory” goes mute — no error, just dumber); but VRAM needs no resident model (second-level loading, five-minute idle auto-unload, zero burden normally). And note: daily chat does not go through Ollama at all — it goes through the local newapi gateway (port 3000) forwarding to DeepSeek/GLM upstream. Ollama serves only two things: chat-time knowledge-base embeddings, and tagging-time vision models.

The flow for new assets — drop new photos/videos into the material library’s two folders, double-click 全量打标流水线.bat: Pass 1 scans new files with 3B, Pass 2 high-temperature retries failures. Will it duplicate? Never. The code is verified: the list = material library filenames vs tag_index.json index keys; after comparison only those not in the index are processed, the 1013 already-tagged auto-skipped. Also upgraded the old 打标.bat (pointing to the obsolete single-scan script) to the v2 incremental version — now both bats work: the pipeline is fuller, single-stage quick incremental suffices for daily.

Coda

The system is now fully provisioned: daily zero maintenance (chat via gateway), increment has its rules (drop files, double-click), memory fully online (1013 items). Complete form achieved — and the true definition of “complete form” is that the master no longer needs to understand how it runs.

Real coordinates

Ollama tagging pipeline VRAM complete form

Comments

← Digital Garden