本地小模型：新手 3 步把敏感文件留在自己电脑

如果你的合同、病历、薪酬表或客户报价单不敢直接传云端，本地小模型现在已经能扛住大部分初审工作。下面这套 3 步方案，包含硬件门槛、模型选型和验收标准，照着做当天就能跑通。

先判断：这件事值不值得放本地

三个信号里满足两个再动手：

1. 数据不能出内网（合同、病历、薪酬、客户名单）；

1. 调用量稳定且大（每天几百次以上，云端按量计费会肉疼）；

1. 需要离线可用（工厂、出差、内网机房）。

反过来，如果只是偶尔问几句、任务依赖最强推理、或者必须联网查最新信息，本地跑只会让你更累。

第一步：先算内存账，别先下模型

本地推理的瓶颈几乎永远在内存（显存），不是 CPU 核心数。按 4bit 量化的经验值估算：

• 4B 模型 ≈ 3GB

• 8B 模型 ≈ 5~6GB

• 14B 模型 ≈ 9~10GB

• 32B 模型 ≈ 20GB 上下

再额外留 2~4GB 给系统和长上下文——上下文越长，KV 缓存越吃内存。16GB 内存的笔记本老实做 8B 以内；32GB 可以试 14B；想跑 32B，最好有 24GB 显存的卡。

工具层不用纠结：习惯命令行就用 Ollama 或 llama.cpp，想要图形界面用 LM Studio，多模型切换和本地 API 都是现成的。关键要求只有一条——必须暴露 OpenAI 兼容接口，这样你后面接自己的脚本几乎零改动。

第二步：选模型看三件事，别看排行榜

1. 中文与领域适配：先拿你真实的一页合同或一份报表丢进去问，比看任何榜单都有用。

1. 上下文长度：要喂整份文档，至少 32K。很多模型标称 128K，但长上下文下质量衰减明显，实测为准。

1. 结构化输出能力：要它稳定吐出金额、日期、甲乙方这些字段的 JSON，不会稳定出 JSON 的模型会让你写一堆解析代码。

量化等级从 Q4_K_M 起步：体积小一半、质量掉得不多；如果发现专业术语开始识别错，再升到 Q5/Q6，代价是内存和速度。

第三步：让模型读你的文件，而不是你粘贴

别每次手动复制粘贴。搭一个最小可用的本地 RAG：

• 解析：PDF 先走文本层提取，扫描件走本地 OCR；

• 分块：按条款或小节切，每块 500~800 字，带上文件名和页码元数据；

• 检索：本地向量库起步即可，文件量少于几百份时，关键词检索往往就够用；

• 提示词：明确要求「只依据给定片段回答，标注来源页码，找不到就说找不到」。

这里最容易被忽略的是拒绝回答的能力。本地小模型天生爱编，必须把「无依据就说不确定」写成硬规则，并在验收环节专门测它。

验收：用 20 条真问题打擂台

跑通不等于能用。从历史文件里挑 20 条你已知答案的问题，分成三类：能直接检索到的、需要跨两份文件的、故意不存在的（考幻觉）。记录三件事：正确率、平均耗时、错误类型。

经验阈值：可直接检索类正确率 ≥ 90%，跨文件类 ≥ 70%，不存在的问题必须 100% 回答「不知道」。达不到就先别上线，别拿同事的真实文件当小白鼠。

边界：什么时候该认输回云端

三类任务交回云端更划算：需要最新外部信息（联网检索）、需要长链条推理（复杂法律论证、代码重构）、峰值流量波动大（本地扩容不现实）。

实际落地中最常见的组合是：本地做初筛和脱敏，云端做深度分析。比如本地模型先把合同里的敏感字段打码、抽出条款要点，再把脱敏后的片段送云端做深度比对——既守住了隐私底线，也没放弃能力上限。