很多人下载了一个 1.5B 量级的 DeepSeek 本地模型，跑起来后发现既不会写复杂代码，也答不准专业问题，就以为白装了。其实这类小模型的定位本来就窄：它胜在能塞进普通笔记本、响应快、可以离线常驻，适合做分类、抽取、改写、打标这类短平快的活。这篇把「什么任务交给它、什么任务别为难它」讲清楚，并给出选量化档、估显存、验效果的具体步骤。
很多人下载了一个 1.5B 量级的 DeepSeek 本地模型，跑起来发现既不会写复杂代码，也答不准专业问题，就以为白装了。其实这类小模型的定位本来就窄：它胜在能塞进普通笔记本、响应快、可以离线常驻，适合做分类、抽取、改写、打标这类短平快的活。把它当全能助手用，失望是必然的；把它当流水线上一个便宜工位用，反而能长期跑下去。
这篇只讲一件事：把「什么任务交给它、什么任务别为难它」说清楚，再给出选量化档、估内存、验效果的具体动作。判断标准全部围绕你自己的真实样本，不围绕别人嘴里的效果。
先划边界：1.5B 这个体量能扛什么、扛不动什么
小模型的强项是把一句话按你给好的规则处理成另一句话，弱项是「想」。凡是需要它自己推导多步、记住长上下文、调用大量世界知识的问题，都不该放进它的任务队列。判断方法很朴素：拿你真实的十条任务样本喂进去，只要能稳定过七成，就算适合你的场景；错得没规律、每次错的地方都不一样，那就别硬调。
- 能扛的：短文本分类打标、字段抽取、格式转换、简单改写润色、关键词与摘要、固定话术问答、本地脚本里的字符串处理
- 扛不动的：多步推理、长文档理解、复杂代码生成、需要大量世界知识的事实问答、多轮长对话的上下文保持
- 边界场景：单轮短问短答可以，多轮里只要前后文一长就容易丢线索，得靠程序把上下文压短再喂
- 不适用的情况：任务本身要求逐字准确，比如合同条款、数字核算、医疗法律结论，小模型只能做初筛，结论必须人工复核
量化档位怎么挑：按内存和速度倒推，不按参数好看挑
量化档位不是越高越好，而是够用就好。先看机器内存上限，再定档位：内存紧张的机器选更激进的低比特量化，内存宽裕就选接近原始精度的档位。低比特通常换来更小的体积和更快的加载，代价是在长句和生僻表达上更容易出错，做抽取类任务时尤其要复测一遍。
| 机器情况 | 优先考虑 | 主要风险 |
|---|---|---|
| 内存紧张、只跑单任务 | 低比特量化档位 | 长句与生僻表达容易出错 |
| 内存中等、任务偏抽取 | 中等比特档位 | 速度与准确率之间要找平衡点 |
| 内存宽裕、要长期常驻 | 接近原始精度的档位 | 占用大，可能挤掉其他常驻进程 |
| 多任务并发 | 先拆进程再谈档位 | 并发下内存峰值比单测时高很多 |
- 先跑通流程用最低档位把任务链路跑起来，确认输入输出格式对得上，先不追求准确率
- 再复测准确率用同一批真实样本对比相邻档位，记录哪类样本开始出错，而不是只记一个总数
- 最后定档把出错的样本类型列出来，如果集中在你最在意的任务上就升档，否则维持不动
- 查具体口径每档占多少内存、对应的文件名怎么写，到 /models/deploy 核对当时的数字，术语混乱时到 /ai-dict/category/tech 对照
按场景过一遍清单：哪些活交给它最划算
小模型的价值不在单次回答多漂亮，而在可以无限次重跑还不心疼。所以最划算的场景是「量大、规则清晰、错了能重来」的活。反过来，单次就要定生死、错了没人复核的活，别交给它。
- 批量打标与清洗
- 给几千条客服对话贴标签、把杂乱 CSV 字段规整成统一格式，出错也能批量重跑
- 本地隐私场景
- 数据不能出内网的文本预处理、日志归并、敏感信息初筛，比调云端接口更省心
- 常驻小工具
- 做成命令行脚本、本地输入法补全、会议记录关键词提取，随开随用不依赖网络
- 开发流水线辅助位
- 写正则、生成测试样例、翻译注释这类碎片任务，当便宜的打字员用，别当架构师用
举个例子：一家 5 人小团队每天要处理几百条用户反馈，先让小模型把反馈分成若干类并抽出关键字段，人工只复核被标为「疑似投诉」的那一小部分。这个流程里小模型是过滤器，不是决策者。
怎么把它接起来并验证真的有用
接起来的核心不是装什么框架，而是把「调用、采样、复核」三步定死。用本地推理工具起服务，再用脚本或客户端调它的本地接口；具体端口和调用方式见 /tools 里的本地工具说明。先跑通一条最小请求，再跑十到二十条真实样本，记录错误类型——是漏抽、格式跑偏还是答非所问，按类型收窄任务范围。
# 示意：先发一条最小请求，确认服务通了再放量
curl -s http://127.0.0.1:PORT/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"messages":[{"role":"user","content":"把这句话里的公司名抽出来：示例文本"}]}'- 效果不行时，先改提示词：限定输出格式、给两个示例、把任务拆成只做一步，再考虑换更大的模型
- 顺序反了会白花硬件钱：多数「答不准」其实是提示词没把任务说死，不是模型太小
- 记录错误类型：格式问题靠约束输出解决，知识问题只能换模型，推理问题只能拆步骤
- 涉及授权与商用的判断，到 /safety 核对许可边界，别默认本地跑就等于能商用
- 拿不准要不要继续投入时，先到 /rankings 看同类本地工具的口碑走势，再决定要不要留这条链路
常见问题
1.5B 的本地模型能不能替代在线大模型干活？
替代不了，它是分工作用。在线大模型擅长推理、长文和开放问答，本地小模型擅长短、重复、格式固定的批处理任务。合理做法是把简单任务下沉到本地跑以省调用量，把难任务留给线上。判断标准就看这条任务能不能用固定规则描述清楚。
普通笔记本能不能跑得动 1.5B 的本地模型？
多数近几年的笔记本在低比特量化下都能跑，差别在速度和内存占用：有独显更顺，纯 CPU 也能出结果只是慢。具体到你机器的内存和显存够不够，按量化档位对一遍 /models/deploy 的测算口径，比听别人说「够用」靠谱。
跑起来效果很差，是该换模型还是该调用法？
先调用法。小模型对提示的格式很敏感，把输出格式写死、给一两个示例、把长任务拆成单步任务，往往能救回来一大截。如果调整后错误仍然没规律，说明任务超出这个体量，再考虑换更大的本地模型或走线上接口。
