Old quant cleanup after upgrades (lp200-825b)


Keep one last-known-good; delete older quants after the eval passes.

Why this note exists in 2026

Local LLM teams waste weeks when hardware, runtimes, and policy pages disagree. This is a practical checklist you can finish in one afternoon without inventing benchmark numbers. Treat it as an operating document: every step should leave an artifact someone else can audit next week.

Shared GPUs amplify small mismatches. A creative demo that needs 24GB while the office box has 12GB free will create support tickets faster than any prompt tweak can fix. Align the story across hardware tables, install docs, and refuse policies before you scale seats.

Preconditions

Steps

  1. Define the owner and the success metric before any spend or model pull.
  2. Document the baseline so you can compare honestly after changes.
  3. Ship a pilot with a kill switch; do not scale on vanity demos alone.
  4. Capture screenshots and ticket IDs for every exception path.
  5. Review reliability and data-class compliance before declaring a win.

Pilot design

Run the pilot on a constrained model size or a single team first. Cap concurrent chats so a failure stays contained. Capture settings before and after change. If the pilot improves eval fitness—not just screenshots—expand in controlled increments and re-check VRAM headroom each time.

Failure modes to pre-write

Field notes

Handoff checklist

Hardware, software, and ops should sign the same one-pager: scope, metric, kill switch, and review date. If any team cannot name the owner in thirty seconds, the play is not ready. Revisit after the next model bump and delete steps that never changed outcomes.

References

Practical local-AI notes: local RAG guide, Ollama on Windows, budget builds.

Published by MicroAI One (本地AI 1号网), a Shenzhen team working on local LLM hardware, software and deployment.