小模型与本地模型

"小"要用字节说，而不是用形容词说。

参数量是标题数字；真正决定它能不能在你机器上跑起来的，是量化后的文件大小。权重通常以 16 位训练，再为本地服务压缩——8 位、4 位甚至更低——用一点质量换来大量显存。

• 常见默认的 4 位量化（形如 Q4_K_M 的标签），大约落在每十亿参数 0.6 GB。一个 8B 模型约是 5 GB 的文件；一个 30B 模型约是 18 GB。
• 你需要的显存是这么多再加上 KV 缓存，而后者随上下文长度与并发数增长。把模型挤出显卡的，往往是长上下文而不是权重本身。
• 统一内存机器（Apple 芯片）有益地模糊了这条线——预算是系统内存，所以一台 32 GB 的笔记本能跑动 12 GB 独显跑不动的模型。
• 低于大约 4 位之后，质量退化就不再细微了。一个被重度量化的大模型未必强过一个轻度量化的小模型；请在你自己的任务上实测，别想当然。

小型本地模型真正擅长的那些活儿。

把你的流水线按调用量排序，你通常会发现排在最前面的都是窄而重复、规格明确的任务——这正是小模型能胜任的画像：

• 嵌入。最明确的胜利，因为开源模型在这里不只是"够用"——它们是领先的。Qwen3-Embedding 位居多语言 MTEB 榜首，高于主流托管接口；BGE-M3 是 MIT 许可的多语言主力，一次前向即产出稠密、稀疏与多向量三种表示；EmbeddingGemma 与 nomic-embed-text 则能在远不到 1 GB 的占用下从容运行。对本地知识库而言，这几乎是你最不该为之付 API 费用的组件。
• 重排序。一个交叉编码器，对五十个候选段落逐一与查询打分，每次搜索都要调用。小、本地，而且是多数检索栈中单点收益最高的一次质量升级。
• 路由与分类。该用哪个工具、哪个索引、什么语言、是否在范围内、是否该拒答——几百个 token 进去，一个标签出来。
• 抽取与规范化。把文档里的字段抽进一个 schema、对实体做去重、在入索引之前清洗文本。
• 出站前的脱敏。用一个本地模型在任何内容被送往托管 API 之前剥掉标识信息——这是一项只需一个小模型、无需与厂商谈判的隐私控制。

它们仍然输的地方，而且差得不近。

对天花板保持诚实，才让混合架构站得住脚：

• 长程智能体工作。二十步的工具调用循环是小模型崩掉的地方——不是拒绝执行，而是漂移、重复一个已经失败的调用，或者把目标弄丢。误差跨步骤累积，于是每步一点点小差距，会变成每任务一大段差距。
• 硬推理与长上下文。标称 12.8 万的上下文窗口，不等于在 12.8 万 token 上都可用的召回；小模型退化得更早也更陡。
• 世界知识的广度。参数更少意味着记住的事实更少。当你把答案接地到检索出的文档上时，这一点没听上去那么要紧——这也正是"一个好的本地知识库让小型本地模型变得可行"的又一个理由。
• 对抗性输入下的稳健性。面对提示词注入，指令遵循能力撑得更差。别把小模型放到"不可信文本与危险工具之间唯一一道防线"的位置上。

那些不出现在价格对比表里的成本。

"买完硬件就免费"按 token 算是真的，按系统算则具有误导性。你接手的是：

• 一道吞吐天花板，取代了一张账单。一台机器只服务固定数量的并发请求，而高负载下的失败模式是排队，不是更高的账单。能批处理的都批起来；嵌入是极易并行的，交互式生成不是。
• 服务本身就是一套系统。Ollama 与 llama.cpp 是单人上手的坡道；多用户共享 GPU 时你会转向 vLLM 或 SGLang，而 MLX 是 Apple 芯片的路线。它们是不同量级的运维承诺——参见服务与访问。
• 升级带来的折腾。开源权重模型进步很快，而换模型并不免费：提示词会漂移，而对嵌入模型来说，一次更换会让你整个索引作废。
• 评测从可选变成必需。用托管的前沿模型时，你可以吃它通用能力的红利。而"降配"只有在你能测出质量没掉的前提下才安全——所以一个小小的评测集，才是这笔成本节省真正的前置条件。

相关阅读：如何为用例选模型提供逐任务的检查清单，开源权重 vs 闭源模型讲许可维度，本地优先检索把硬件预算从头到尾算了一遍。